前言：AI导购浪潮下，重塑芝麻租赁的场景化体验

当前，AI导购已成为电商与服务平台竞相追逐的新风口。从淘宝的“AI万能搜”到京东的“京言”，再到美团的点餐助手，行业巨头们都在积极探索如何利用大模型技术，将传统的货架式体验升级为更智能、更具交互性的顾问式服务。

然而，在芝麻租赁这一独特的长周期、重决策场景中，挑战尤为严峻。用户面对的不仅是商品，更是一份包含租金、押金、服务条款的复杂合约。传统的电商导购模式在此显得力不从心，我们发现三大核心痛点亟待解决：

1.需求难匹配： 从摄影发烧友到露营新手，不同租客的关注点天差地别。平台缺乏对这些差异化需求的精准识别与服务。

2.决策效率低： 关键信息散落在商品详情各处，用户为了解一份合约细则，不得不在“信息海洋”里艰难筛选，决策门槛高、耗时费力。

3.服务太被动： 面对“公司年会需要一套投影设备”这类场景化需求，平台只能提供标准化的商品列表，无法给予主动、顾问式的打包建议。

尽管行业内已有诸多尝试，但它们大多仍聚焦于快消品或标准化服务的推荐。将芝麻租赁从一个简单的“商品陈列货架”升级为一个能提供垂直化、主动式服务的“专业租赁顾问”，是一次极具创新性的探索。

为此，我们将AI导购智能体“租赁小不懂”定位为用户的“专属租赁顾问”，致力于打造一种全新的场景化租赁体验，其核心是贴切、沉浸、信任：

• 贴切： 针对不同人群，提供定制化的交互与方案。
• 沉浸： 整合全网信息，提供一站式、无缝的决策辅助。
• 信任： 清晰展示服务条款与用户反馈，扫除决策疑虑。

要实现这一愿景，我们的AI导购必须在复杂租赁意图理解、平台原生服务无缝调用以及租赁场景化知识构建这三大挑战上取得突破。这驱使我们走上了一条通过Tool-Use（工具调用）与强化学习来打造新一代AI导购的探索之路。

AI导购的“理想”与“现实”

理想中的AI导购

在电商与租赁场景中，一个理想的AI导购应如同一位经验丰富的金牌销售。以我们的项目“租赁小不懂”为例，它的定位是站在芝麻租赁货架旁的7x24小时AI租赁顾问，核心使命是解决用户在租赁全程中遇到的“租前决策难、租中履约烦、租后维权慢”三大核心痛点。我们希望用户只需通过几轮自然对话，AI助手就能精准洞察其深层需求，并娴熟地调用商品搜索、比价、知识库查询等内部工具，最终给出完美的解答和商品推荐。

现实中的骨感与挑战

然而，在项目初期（2025年7月），我们发现理想与现实之间存在巨大鸿沟。早期的技术方案，无论是基于多Agent（Multi-Agent）的架构，还是单纯依赖监督微调（SFT）的训练方式，在复杂的导购场景中都显得力不从心。

架构之痛： 我们最初采用当时主流的“多智能体”串行链路（Query → Rewrite → Planning → Retrieval → Agent）。这带来了两个严重问题：

• 耗时长： 各模型独立冷启动，导致P99首字耗时高达5.1秒，用户体验极差。
• 功能重叠： 不同Agent（如知识问答专家、导购专家）间存在能力重叠，例如都需要“全网搜”功能。这使得训练和部署成本随Agent数量线性增加。

模型能力边界

为什么我们的场景更复杂？在租赁场景中，一次成功的推荐需要多次工具调用（涉及几十个工具参数）。相比通用场景，我们的业务对toolcall精度要求极高。

通用ToolCall场景（如天气查询）

用户：今天北京天气怎么样？
模型：weather_search(city="北京") → 返回天气数据 → 回答用户

特点：

• 单步决策，工具选择明确
• 参数简单（城市名）
• 失败后果轻微（没有后续链路）

租赁导购场景（复杂多步决策）

用户：我想租个相机去西藏旅游，要轻便又能拍星空

需要多步工具调用，下一步依赖上一步的结果：

1. knowledge_search("西藏旅游 相机 轻便 拍星空") → 了解需求背景；

2. search_db(商品类型="相机", 品牌="", 型号=["xxx", "xxx"]...) → 初步搜索；

3. search_db(商品类型="相机", 品牌="") → 扩大搜索范围（如果没搜到品）；

4. 拿到商品列表(商品列表=[...]) → 最终推荐；

我们的商品搜索工具包含20+个参数维度，而通用toolcall通常只有2-3个参数：

{
  "product_type": "相机",           // 商品品类
  "brand": "索尼",                 // 品牌  
  "models": ["A7C", "A7III"],      // 具体型号
  "key_features": ["轻便", "高感光度", "夜景强大"], // 关键特征
  "price_range": {"min": 80, "max": 150}, // 价格区间
  "rental_duration": "15天",       // 租期
  "service_guarantees": ["免赔保障", "租期质保"] // 服务保障
  // ... 还有10+个参数
}

在深入调研后，我们发现问题的根源远比想象的要深。这不仅仅是训练方法的问题，更是当前所有大模型在Tool-Use能力上共同面临的原生天花板。

在权威的Tool-Use基准测试TauBench中，与我们导购场景最接近的“Retail”（零售）领域的评测结果：

• 即便是业界最顶尖的模型，其“开箱即用”的Tool-Call能力也远非完美。 以表现最好的Claude-Sonnet-4.5为例，其一次性成功率（Pass^1）仅为84.7%。这意味着接近20%的情况下，无法正确地规划和执行工具调用。
• 随着尝试次数的增加，成功率会急剧下降（如Pass^4成功率更是跌破了70%）。

这个数据解释了我们遇到的困境：我们所依赖的“基座模型”本身就不是一个完美的执行者。因此，仅靠SFT这种“模仿式”的训练，不仅难以弥补基座模型的原生缺陷，反而更容易让模型在不确定的决策点上产生“幻觉”。

• 调用幻觉： 模型会虚构不存在的商品ID，或在无需调用工具时强行触发。

• 内容幻觉： 模型会过拟合训练数据中的特定内容，脱离实际知识库，凭空生成答案。

这些问题严重影响了AI导购的可靠性，让我们更加坚定对整体技术栈进行一次彻底的重构。

破局之道：从多Agent到“One-Model + Tool-Use”的架构演进

架构的“断舍离”

为了解决上述问题，我们首先对系统架构进行了调整。核心思想是：放弃多Agent划分，将所有能力沉淀为一系列原子化的工具（Tools），由一个统一的大模型（One-Model）根据上下文进行动态决策和调用。

我们采用了经典的ReAct（Reasoning and Acting）范式，整个交互流程变为一个灵活的循环：「思考需要什么工具 -> 决定如何调用 -> 观察工具返回结果 -> 决定最终响应还是继续调用」。

React ToolCall示例

我们将原先分散在各个Agent中的能力，统一抽象为超过15种原子化工具，例如：

• 商品召回工具
• 全网搜
• 自运营种草知识检索
• 租赁内部知识检索
• 商品对比工具
• 物流查询
• 订单查询
• 商品详情卡片
• 追问卡片
• 更多商品卡片
• 视频卡片
• ......

工具设计的巧思

我们没有创建大而全的“万能工具”，而是将导购任务拆解为一系列原子化的操作。

例如，一个完整的“商品推荐”流程，可能被拆解为：

• knowledge_search: 用于理解用户提到的非标术语（如“拍Vlog用的相机”）。
• web_search: 用于获取最新的产品评测或小红书种草内容。
• search_db: 基于明确的参数（如品牌、价格区间）在商品库中进行精确召回。

虽然工具要原子化，但过度拆分会导致模型决策链条过长，并可能引发不必要的并发调用，增加系统负载和延迟。因此，我们遵循效率优先的原则，对功能相似或存在互斥关系的工具进行合并。

一个典型的例子就是知识源检索工具的设计。在导购场景中，模型需要查询多种知识来源：

• 域内知识： 租赁平台的规则、活动、售后政策等。
• 域内视频：支付宝视频好的相关视频。
• 域外知识： 全网的产品评测、小红书的种草内容、通用百科等。

如果将它们设计成internal_search和external_search多个独立的工具，模型在面对一个模糊问题时（如“租相机去旅游有啥需要注意的？”），可能会并发调用两个工具，既浪费了计算资源，也增加了模型在多个返回结果中做信息整合的难度。

我们的解决方案是：将它们合并为单个工具，通过参数进行区分。

{
  "name": "knowledge_search",
  "description": "用于搜索知识库获取信息。根据问题类型选择合适的知识域(domain)。",
  "parameters": {
    "query": "搜索的关键词",
    "domain": {
      "type": "string",
      "enum": ["internal_kb", "web", "xiaohongshu"],
      "description": "知识域选择：'internal_kb'用于平台规则，'web'用于全网搜索，'xiaohongshu'用于生活方式和产品种草。"
    }
  }
}

当然，query和domain可以是一个组合，这样同一个工具可以指定多个不同知识域的不同搜索关键词。

与行业方案不同，我们工具调用的步骤不是固定的。

模型会根据当前步骤拿到的信息决定下一步的工具调用/最终响应。

立竿见影的效果

架构升级带来的收益是立竿见影的，最直观的体现就是性能的大幅提升。通过将多个小模型合并为一个大模型，我们砍掉了冗余的串行调用链路，首字响应耗时从平均5.1秒锐减至1.2秒，为后续更复杂的算法优化和更流畅的用户体验铺平了道路。

核心算法优化：用两阶段强化学习，教模型“学得会、用得对”

架构升级解决了“通路”问题，但要让模型真正“智能”，还必须解决算法的“大脑”问题。

为什么SFT不够好

我们深入分析了SFT在Tool-Use场景中的根本性缺陷：

• 学习信号稀疏： 在导购对话中，真正的工具调用token（如<tool_call>及其参数）占比极低，模型在SFT阶段难以从海量自然语言中有效学习到稀疏的工具调用逻辑。
• 只学格式，不学策略： SFT倾向于让模型死记硬背调用格式，但无法教会它“何时调用、调用哪个、以及如何根据返回结果进行下一步决策”的策略。

受到业内前沿研究（如ToolRL）的启发，我们意识到必须转变训练范式：从“格式模仿”彻底转向“结果验证”，让奖励（Reward）成为模型学习的一切示范。

我们的解法：Rule based + LLM-as-Judge

我们设计了一套两阶段强化学习（RL）流程，结合了规则与AI裁判：

• 第一阶段：格式强化（Rule-Based Reward）

• 目标： 快速教会模型稳定、正确地调用工具，杜绝低级格式错误。
• 方法： 我们编写了一系列严格的规则，对模型生成的工具调用语法、参数格式进行校验。例如，如果模型幻觉出<itemCard>商品卡片但并未调用search_db工具（搜索商品的工具），就会得到一个极低的格式分。通过这种方式，模型很快就学会了遵守工具调用的“语法纪律”。
• 第二阶段：回答优化（LLM Judge Reward）

• 目标： 在格式正确的基础上，教会模型生成内容更优质、语义更准确、更具吸引力的回复。
• 方法： 我们引入了一个轻量级的、4B参数的LLM-as-Judge作为“裁判”。它会综合上下文、人工标准答案以及模型回复，从准确性、完整性、生动性等多个维度进行综合评估，并给出一个0-1之间的奖励分数。
• “裁判”不靠绝对精度

1.零温度封闭 prompt 压制幻觉；

2.用精度换速度，4B 参数量，单卡 32 sample/s；

3.4B 在 Qwen-Bench 语义等价子集（单句级，≤64 token）上 F1 ≈ 0.94；

4.RL 只关心相对排序，不关心绝对值。

核心优化：稀疏奖励难题

正如前面所述，我们的Tool-Use RL训练面临的核心挑战是奖励信号极度稀疏。在多步复杂决策链中，模型往往因为第一步的微小失误，导致整个决策链无法获得正向奖励，从而陷入探索困境。

具体表现为：

• 模型首次搜索失败后，难以自发学会"换个关键词再搜一次"的策略；
• 在高温度采样下，多个样本均未能触发有效搜索，reward均为最低值-1；
• 关键决策点的探索不足导致整体性能受限；

因此，toolcall部分的token需要更大的探索步长。为此，我们探索了对GSPO的改进。

我们在标准GSPO框架基础上，引入了区域差异化的clip策略：

标准GSPO目标函数：

改进的混合GSPO目标函数：

其中区域特定的clip范围定义为：

在自然语言生成中，我们通常将每个token的生成视为一个动作。在Tool-Use场景中，有些token属于工具调用部分，有些则是自然语言部分。我们的创新点在于对工具调用部分的token和自然语言部分的token使用不同的裁剪范围。

假设我们将整个生成的token序列划分为两个部分：工具调用区域（包括工具名称和参数）和自然语言区域。我们为工具调用区域设置一个较大的裁剪范围 ，而为自然语言区域设置一个较小的裁剪范围 。那么，对于每个token，根据它所在的区域，我们选择相应的裁剪范围。

这样做的原理是：工具调用部分的决策对任务成功至关重要，而且工具调用的空间较大，需要更多的探索，因此我们允许更大的更新步长。而自然语言部分相对稳定，我们希望保持较小的更新以避免不必要的波动。

我们快速验证了80steps，发现reward全极值的情况大幅度下降（横坐标是step，纵坐标是reward为-1的个数）。

当然，放大 clip 只是给模型「更长步子」去探索，如果 advantage 估计不准，这些大步就会直接踩到错误方向，导致策略震荡或塌陷。我们需要持续观察KL并且优化更准确的reward model，来获得更稳定的训练结果。

为进一步保险，防止同batch内的不同类型样本会互相干扰（toolcall和非toolcall），我们把同 batch 的轨迹按“含工具调用 / 纯语言”拆成两个 replay pool，采样时保持 pool 内比例 1:1，但 loss 计算仍用同一 forward。

实践成果：数据与案例的双重验证

数据会说话（量化结果）

离线评测

经过两阶段RL训练后，模型的能力得到了显著提升。在一份包含805例样本的评测集中，我们观察到：

• 模型准确率： 整体正确率从88.32%提升至91.55%（+3.23%）。其中，最关键的参数错误率下降了2.11%，格式幻觉问题优化了0.87%。
• 业务与性能指标： 在实际业务评测中，模型的完整推荐成功率在非3C品类上实现了+14.93%的飞跃，同时端到端响应耗时从2850ms优化至100ms。

线上评测

业务结果

效果看得见（质化案例）

持续探索：性能压榨与未来方向

克服MoE训练瓶颈：从93秒到9.4秒的接近十倍加速

为进一步降低服务成本和延迟，我们还对MoE（Qwen3-Next-80B-A3B）模型进行了深入探索。Qwen3-Next主要创新和改进点在高稀疏度的MoE架构、复杂的混合注意力机制（Gated DeltaNet + Gated Attention），而这两者叠加后对也训练-推理一致性和强化学习稳定性有了更高的要求。MoE架构本身带来的路由不稳定性和专家负载不均衡是训练中的核心挑战之一。而当它与线性注意力等机制结合时，这些问题会进一步放大，这也是为什么需要从GRPO转换到GSPO。

• 训练效率低下，采用主流的Deepspeed Zero3方案进行训练，单次迭代耗时高达93秒，这对于需要快速迭代的模型开发是不可接受的。 Zero3策略将模型参数、梯度和优化器状态全量切分到不同GPU，导致节点间产生了巨大的通信开销，严重拖慢了训练进程。
• 训练负载严重不均，我们观察到，前10%的“活跃专家”处理了超过50%的输入Token，而后30%的“懒惰专家”仅处理了5.7%的Token，大量GPU资源被闲置，模型学习效率低下。

为了解决这些问题，我们引入并精细调优了Megatron的6维并行训练策略（TP+PP+DP+SP+CP+EP)。举例，在一个包含8机64卡A100的集群中，我们将并行策略配置为TP=4, PP=8, EP=2, DP=1，成功地将计算和通信负载均匀地分布到整个集群。一个“热门专家”的计算，首先被TP=4拆分成4份，然后它所在的专家组可能被EP=2拆到2个不同的GPU节点，最后这些计算又嵌入在PP=8的流水线阶段中。这样，一个原本可能压垮单个GPU的热点，被成功分解成了多个可管理的小任务，分布到多个计算单元。通过上述组合，几乎集群中的每一张GPU都被赋予了明确的计算任务（要么是TP的一部分，要么是PP的一个阶段，要么是EP的一个专家子集），计算和通信很自然地达到了一个平衡状态。

最终，训练速度提升了接近10倍，极大地加速了模型的研发和迭代周期。

实现MoE推理降本：显存占用降低40.6%

在推理部署阶段，我们的核心目标是在保证精度的前提下，最大限度地降低显存占用（保持与原Qwen3-32B通用的推理资源4XL20）。然而，我们同样遇到了两个棘手的挑战：

1.框架局限性： 当时主流的AWQ等量化框架并不支持我们所使用的QwenNext模型架构。

2.兼容性问题： MoE模型特有的专家路由（Gating）机制与标准的量化流程存在冲突，直接套用会导致严重的精度损失。

我们参考了QwenNext的开源量化recipe，选择了部分层进行量化（e.g. 标准 self-attn.o_proj和MoE expert 的 up/down/gate），跳过了路由和线性注意力这类参数量不大但容易掉点的层。

效果显著：在保持了99.5%模型精度的前提下，成功将推理显存占用降低了40.6%。在不改变推理资源的基础上，线上模型成功从Qwen3-32B迁移到Qwen3-Next-80B-A3B.

总结

回顾“租赁小不懂”的实践之路，我们通过架构升级与算法创新，成功打造了一款更可靠、高效的智能导购助手。这不禁让我们思考：在AI浪潮下，究竟需要多少人的团队，才能真正落地一个应用？

我们的答案并非一个具体的数字，而是一种模式：小而精、各司其职且协作高效。一个规模不大但成员各有所长的团队，能最大限度地减少沟通成本和内部摩擦，将所有精力聚焦于共同的目标，这正是许多创新项目能够快速取得突破的关键。

这种聚焦也体现在我们的技术选型上。我们引入的每一项新技术，都不是为了追赶时髦或盲目跟风，而是为了解决一个真实存在的问题——无论是模型的“幻觉”，还是那零点几秒的延迟。

来源  |  阿里云开发者公众号

作者  |  初影