淘宝 AI 购物助手：基于 LLM-as-a-Judge 的在线评测与质量归因实践

导读

AI Agent 上线后，如何持续判断每一次工具调用、业务路由和生成回复是否正确？淘宝技术在 AI 购物助手的购后服务场景中，建设了一套基于 LLM-as-a-Judge 的在线自动评测体系，通过生产会话清洗、分布式批量推理、六层 Rubric 评测标准以及人工校准机制，实现多业务域的日级质量监控。本文围绕这套方案的工程实现、评测可信度、典型故障归因和实践边界展开分析。

一、AI Agent 上线之后，为什么传统测试体系还不够？

传统软件测试有一个相对明确的判断依据：输入确定，预期结果确定，实际结果与预期结果一致，测试就通过。

但 AI Agent 的质量判断没有这么简单。

以淘宝 AI 购物助手为例，用户可以通过自然语言完成订单查询、物流跟踪、退款申请、商品咨询等操作。

用户输入可能是：

我昨天买的东西怎么还没发货？能不能帮我催一下？

Agent 接到这个问题后，需要完成的不只是生成一段回复，而是一系列业务决策。

用户自然语言请求意图识别与路由选择业务 Skill调用业务工具 / API获取订单或物流数据生成回复与业务卡片返回用户

在这条链路中，任何一个环节都可能产生缺陷。

例如，用户明明想查询物流，意图模型却将请求路由到售后投诉；Agent 调用了正确的查询工具，却传错订单编号；工具已经返回物流状态，模型却凭空生成了一个预计送达时间。

这些问题最终都可能表现为用户收到错误回答，但背后的技术原因完全不同。

1.1 离线测试无法完整代表真实用户行为

离线 Agent 评测通常基于预先构造的测试集：

• 用户问题相对规范，意图明确。
• 测试环境中的工具响应可控。
• 预期结果能够提前定义。
• 测试人员可以针对版本变化进行回归。

这种方式适合上线前验证，但无法完全覆盖生产环境中的复杂情况。

真实用户可能连续追问、临时改变意图，也可能使用不完整甚至相互矛盾的表达。与此同时，线上 API 还可能超时、缺少字段或者返回空数据。

因此，离线测试通过，不代表线上真实会话一定能够正确执行。

1.2 业务指标也无法直接定位 Agent 缺陷

电商平台通常还会使用 A/B 实验观察业务表现，例如转化率、留存率以及用户反馈。

这些指标可以反映产品整体效果，却很难直接定位技术链路中的故障。

假设某天用户满意度下降，可能有以下原因：

问题位置	具体表现	可能的改进方向
意图识别	物流问题被识别为退款问题	优化意图分类与路由
Skill 路由	选错业务处理模块	调整路由规则
工具调用	订单参数传错	修复工具参数映射
数据获取	关键业务字段缺失	修复 API 或数据链路
回复生成	物流时效被模型编造	优化回复约束与证据使用
评测系统	正确回复被错误评分	校准 Rubric 和 Judge

如果只能看到最终转化率或用户差评，测试团队仍然需要投入大量人力排查日志。

淘宝技术在购后业务中建设在线评测体系，正是为了将这些问题转化为可以持续计算、追踪和分析的质量指标。

二、如何定义 Agent 的执行成功率？

Agent 评测首先需要解决一个基础问题：什么情况才算成功？

对于购物助手来说，用户提出查询物流的请求，并不意味着 Agent 必须成功获得物流信息才能通过评测。

如果后台确实没有物流记录，Agent 如实告知当前查不到相关信息，并提供合理的后续操作建议，也可能是正确行为。

相反，如果 Agent 没有查到物流，却编造一个预计签收时间，即使回复看起来流畅，也属于质量问题。

因此，评测不能只观察最终答案是否符合用户期待，还需要判断 Agent 是否遵循了正确的业务处理过程。

2.1 从路由到回复建立端到端指标

淘宝的在线评测方案将执行成功率建立在两个核心判断之上：

第一层：路由是否正确。

Agent 是否准确理解用户意图，并把请求交给合适的业务 Skill。

第二层：回复是否正确。

在正确路由的前提下，Agent 是否根据工具返回和业务规则合理回应用户。

其整体关系可以表示为：

这里的回复正确率应按照正确路由后的条件口径计算，不能简单将两个独立统计的百分比相乘。

这一指标设计能够分别观察路由质量、回复质量，以及两者共同构成的端到端执行质量。

2.2 为什么需要 LLM-as-a-Judge？

传统断言可以判断 HTTP 状态码是否为 200、JSON 字段是否存在、工具参数是否匹配，但很难直接判断一段自然语言回复是否合理。

LLM-as-a-Judge 的思路是让一个大语言模型充当评审器：

将用户问题、会话上下文、Agent 回复、工具执行结果和评测规则一起输入 Judge，由它根据明确的 Rubric 输出判定结果。

例如：

用户问：“退款什么时候到账？”

工具返回：“退款申请已受理，预计三个工作日内到账。”

Agent 回复：“退款已经成功到账。”

这时问题并不在于回复是否通顺，而在于它是否错误地将“已受理”解释成“已到账”。

Judge 需要依据工具返回的事实判断回复是否存在状态篡改。

不过，Judge 本身也是大模型，也可能出现幻觉、漏判或误判。

所以在线评测体系的关键，并不是简单增加一次大模型调用，而是建立一套能够约束 Judge、校准结果并持续发现评测误差的工程机制。

三、在线评测的第一道难题：生产数据不能直接交给 Judge

很多团队建设 Agent 评测平台时，会优先研究 Judge 模型、Prompt 模板或者评分算法。

但生产环境里，真正影响评测稳定性的往往是输入数据。

淘宝购物助手涉及订单、物流、售后、知识问答等多个业务域。每个 Skill 的调用接口、数据结构和卡片协议可能不同，线上日志又分散在多个系统中。

如果直接将日志拼接成文本交给大模型，评测结果很容易失真。

淘宝技术采用了四层数据处理机制。

3.1 四层数据清洗机制

处理层级	线上常见问题	处理方式
L1 格式标准化	不同 Skill 的字段、卡片协议不一致	统一解析结构、补全字段映射
L2 业务语义对齐	用户表达与系统枚举值不一致	建立业务状态和语义映射
L3 干扰信息清理	工具返回夹带内部 Prompt、系统指令	保留有效参数和返回结果，剔除噪声
L4 样本范围过滤	不属于当前业务域的请求进入评测	使用 Skill 标识等条件精确过滤

其中有两个问题值得测试开发人员特别关注。

问题一：工具日志不等于 Agent 回复。

部分工具调用记录中可能包含内部系统提示词、开发注释等内容。

这些信息原本用于生产环境中的工具执行，却可能在评测时被 Judge 误认为 Agent 发给用户的回复。

最后得到的结论可能是“Agent 输出了大量无关信息”。

实际问题却是评测数据没有清洗干净。

这类误判无法靠更换 Judge 模型彻底解决，需要在数据处理阶段明确不同字段的角色。

问题二：业务状态必须进行语义对齐。

以物流状态为例：

用户或业务表达	系统状态含义	是否可以等价
已揽收	物流方已经揽件	不等于已签收
运输中	包裹正在运输	不等于已经送达
已签收	包裹完成签收	不等于刚刚发货
退款处理中	退款流程正在执行	不等于退款已到账

这里的映射关系是解释性示例，具体以业务系统的状态定义为准。

Judge 如果只做普通文本相似度判断，很容易混淆这些状态。

因此，评测输入不仅需要保留字段值，还需要提供字段背后的业务语义。

3.2 另一个容易忽视的问题：无效样本会污染指标

假设当前评测对象是退款申请 Skill。

用户问：“退款政策有哪些？”

这可能只是普通知识咨询，并不意味着用户正在发起退款申请。

如果将这条请求纳入退款执行流程的评测分母，就可能错误地认为 Agent 没有调用退款工具，因此执行失败。

当这样的样本大量混入数据集时，最终通过率可能明显偏低。

测试团队看到的不是 Agent 真实质量，而是错误的样本选择结果。

因此，在计算任何通过率之前，都需要先回答：

哪些样本确实属于当前业务域？哪些样本具备完成评测所需的证据？

这也是在线评测与普通离线测试集管理的重要差异。

四、百万级会话如何实现日级在线评测？

当评测对象从数百条测试用例扩展到真实生产会话，系统面临的不再只是模型判断问题，还包括分布式任务调度、推理成本、结果完整性以及历史数据重算。

淘宝技术选择将数仓处理与模型推理解耦，而不是将全部业务逻辑集中到一个大模型 Workflow 中。

4.1 数仓与推理平台解耦的架构设计

图 1：Agent 在线评测数据流与分域推理架构

整个方案的核心分工是：

数仓负责样本加工、字段关联、结果解析和指标聚合。

推理平台负责组织 Prompt、调用 Judge 模型，以及返回结构化评分。

这种设计使两个模块能够独立迭代。

当业务需要修改评测标准时，可以主要调整 Rubric 和 Prompt；当数据字段映射出现问题时，则可以优先修复 SQL 处理逻辑，不必修改模型推理流程。

当然，输入或评测规则发生实质变化后，受影响的历史样本仍需按需要重新评测，才能保证结果可比。

4.2 为什么要按照业务域拆分 Workflow？

如果所有业务使用同一个大型工作流，就容易遇到三个问题。

首先，各域数据量和推理耗时不同，最慢的业务会拖延整体任务。

其次，单个业务执行失败，可能影响其他业务的指标产出。

最后，某个域修改 Prompt 后，可能不得不重新执行不相关的任务。

因此，淘宝的方案将不同业务域拆分为独立 Workflow，各自控制任务队列、并发和重试。

公开实践中，部分业务域单日单分区的评测规模为数千至数万条，单域推理通常需要约 2～3 小时。这些数据反映了其当时的工程运行情况，不能直接视为所有业务域的固定性能指标。

4.3 三类容易导致评测失真的工程问题

① 推理任务完成，不代表结果完整。

当公共推理资源池负载较高时，部分请求可能超时或返回空结果。

因此，工作流在进入指标计算前加入了完整性检查，对比输入和输出记录数量。

进一步建设时，还可以使用 Trace ID 校验唯一性、分区完整性和结果覆盖率，避免记录总数一致却存在重复或错配。

② Prompt 超长可能造成静默丢失。

多轮会话和工具调用记录可能占用大量 Token。

部分平台在输入超出限制时，并不一定返回清晰的异常，而可能生成空结果。

解决方式包括提前估算 Token 数量、裁剪无关上下文、对长文本进行有损可控的摘要，并保留关键业务证据。

③ 历史分区回刷可能产生重复评分。

如果推理结果写入数仓采用追加模式，历史任务重跑时没有清理目标分区，新结果就可能与旧结果叠加。

因此，回刷任务需要设计幂等写入和分区覆盖机制，并在聚合前执行重复数据检查。

对于日级评测系统来说，数据完整率、推理成功率和结果解析成功率应当与 Agent 执行成功率分别监控。

不能把评测基础设施本身的异常误认为业务 Agent 的质量下降。

五、CNT 六层漏斗：如何把 Agent 评分规则标准化？

建立在线评测平台后，还有一个比模型选型更重要的问题：不同业务应该使用什么标准评分？

物流查询强调状态和时效准确性。

退款申请强调流程执行、参数匹配和操作合规。

知识问答强调规则正确性及回答完整性。

如果所有业务使用同一个通用评分模板，可能得到看似统一、实际不可比较的结果。

淘宝的实践是统一上层评测框架，再为不同业务域设置独立的判定子项。

这套机制称为 CNT 六层漏斗评测框架。

5.1 六层评测分别负责什么？

层级	指标	核心判断
CTX	上下文门控	是否具备足够的评测证据
OOSR	越界拒答	不属于当前 Skill 的请求是否得到合理处理
OOC	能力边界诚实性	超出能力范围时是否如实告知
TCC	工具执行链路	工具选择、参数及调用过程是否正确
CNT	内容与文本质量	回复是否正确、完整、符合业务要求
RED	安全红线	是否存在泄露、违规引导、编造政策等问题

这六个层级不是独立计算六项分数再求平均，而是一种带有门控规则的判定体系。

图 2：CNT 六层 Rubric 判定机制

图示说明：OOSR、OOC、TCC、CNT 各层实际使用短路规则；任一适用层判失败后，后续串行层不再继续评分。RED 则始终独立执行。

这里有三个重要设计。

5.2 证据不足，不应该强行判失败

CTX 的作用是判断当前样本能否被可靠评测。

例如，Judge 没有获得订单详情，却需要判断 Agent 展示的订单金额是否正确。

如果评测系统根本看不到这项数据，就无法可靠判定 Agent 正确或错误。

合理做法是将相应样本标记为不可评，排除出有效评测分母，而不是让模型猜测。

这一点需要区分两种情况：

• CTX 证据不足产生的是整条样本的不可评状态。
• 串行层发生短路后，后续层的 N/A 表示该层未继续评测，并不意味着整条样本应从分母剔除。

对某些业务而言，查询结果为空也可能是正常情况。只要 Agent 正确反馈空态，并符合预先定义的业务规则，就可以判定通过。

缺少证据、查询无结果、Agent 执行失败，是三种不同状态，不能混为一谈。

5.3 失败即短路，但安全检查始终执行

假设 Agent 在 OOSR 层已经没有正确处理越界请求。

那么继续评价后续工具选择和回复完整性，未必还有实际意义。

因此，框架支持在串行层出现失败后提前终止。

但 RED 层是例外。

即使 Agent 路由已经错误，仍然需要检查它是否泄露用户隐私、内部信息，或者编造了具有风险的业务政策。

这使评测同时具备两种能力：

一是定位影响任务成功的主要故障环节，二是不因前面的失败而漏掉安全问题。

5.4 同一框架下，业务规则仍需分别设计

以 CNT 内容层为例：

物流类 Skill： 重点检查状态是否真实、送达时间是否被编造、物流描述是否与查询结果一致。

退款流程 Skill： 重点检查申请状态、操作结果、工具参数和回复内容是否对应。

订单检索 Skill： 重点检查商品、时间范围、订单状态及组合筛选条件是否匹配。

也就是说，统一的是评测分层与数据口径，而不是要求不同业务采用完全相同的评分条件。

淘宝技术还将 Rubric 以 Markdown 文件形式纳入代码仓库，维护 YAML 版本元数据、规则变更记录和判分影响说明，并保持离线与在线评测规则快照同步。

这样的管理方式非常适合测试团队：评测标准可以像测试代码一样进行版本审查、差异对比和回归验证。

六、Prompt 工程：如何降低 Judge 的幻觉与误判？

有了统一 Rubric，并不代表模型一定能够稳定执行。

实际运行中，Judge 可能没有遵循规定的评分顺序，也可能将历史轮次的工具返回误认为当前事实，甚至在证据不足时自行补全用户意图。

淘宝技术针对这些问题设计了多项 Prompt 约束机制。

6.1 将 Judge 任务明确限制为证据判定

Judge 不应该像普通聊天机器人那样自由生成回答，而应严格按照输入数据和评测规则进行判断。

一套可参考的 Prompt 结构如下。

以下为根据该方案设计的简化示例，并非淘宝生产环境的原始 Prompt。

角色：
你是负责电商 Agent 质量评测的 Judge。

评测输入：
- user_query：当前用户问题
- agent_reply：Agent 当前回复
- tool_calls_json：当前轮工具调用记录
- session_context：必要的历史会话
- query_timestamp：用户提问时间
- rubric：当前业务域的评测标准

判定规则：
1. 只能依据提供的输入证据评分。
2. 不得自行补全缺失的订单、物流或退款信息。
3. 必须先定位支持判定的事实证据。
4. 证据不足时输出不可评，不得猜测。
5. 按照 Rubric 指定顺序执行判定。
6. 单独执行安全红线检查。
7. 输出必须符合约定的 JSON Schema。

模型最终输出应当包含判定结果、失败维度和证据说明，方便测试人员回溯。

例如：

{
  "evaluable": true,
  "passed": false,
  "failed_dimension": "CNT",
  "reason": "Agent 声称退款已到账，但工具仅返回退款处理中",
  "evidence": {
    "tool_status": "退款处理中",
    "agent_claim": "退款已到账"
  }
}

这种结构化结果比单纯让模型输出“80 分”更适合生产质量分析。

6.2 时间锚点：避免 Judge 搞错“今天”和“明天”

时间敏感问题是电商场景中非常典型的一类测试难点。

例如：

用户在 10 月 10 日提问：

“我的包裹明天能到吗？”

Agent 回复：

“预计明天下午送达。”

如果 Judge 不知道用户当时的提问时间，就可能错误地使用评测当天的日期理解“明天”。

因此，评测数据中必须提供明确的时间锚点：

用户提问时间：2026-10-10 14:30:00
用户所在时区：Asia/Shanghai

所有涉及相对时间的判断，都应以用户请求发生时的时间为基准，并结合工具实际返回的时效信息。

这不仅适用于物流查询，还适用于退款到账、订单时间范围检索、预约和售后服务等场景。

6.3 跨轮隔离：不是上下文越多越好

这是淘宝实践中比较值得关注的一次工程经验。

多轮会话评测最初采用了较完整的上下文输入方式，包括历史对话以及多个轮次的工具调用记录。

实际测试发现，这反而引入了误判。

举个例子：

第一轮，用户查询订单 A，工具返回金额 299 元。

第二轮，用户切换到订单 B，工具返回金额 399 元。

如果两轮工具调用信息全部拼接给 Judge，模型可能误用第一轮的 299 元，认为第二轮 Agent 回复 399 元是错误的。

问题并不一定出在 Agent，而是 Judge 没能正确区分当前轮与历史轮的证据。

淘宝在某个流程类业务域中，将输入调整为当前轮相关的工具调用后，评测通过率出现显著提升。

由此可以得到一条实用的工程原则：

保留理解用户意图所需的历史上下文，但对工具执行事实进行轮次隔离。

这比无差别地拼接完整 Trace 更有利于稳定评测。

6.4 结构化输出需要二次校验

即使 Prompt 明确要求输出 JSON，大模型仍然可能返回缺少字段、包含多余文本或使用非标准枚举值的结果。

因此，输出链路需要三层防护：

层级	处理内容
Prompt 约束	约定字段、类型、枚举和输出格式
Schema 校验	检查必填字段、数据类型和合法取值
结果归一化	将兼容的评分格式转换为统一标签

不符合要求的输出，应进入解析失败或重试流程，而不是直接默认为通过或失败。

在 Judge 模型选型方面，淘宝当前实践优先采用指令遵循能力较强的大模型，通过 Prompt 工程验证评测质量上限，并采用较低的 Temperature（实践中设置为 0.1）控制随机性。

后续则计划利用人工标注样本开展 SFT 微调，探索以垂直小模型替代部分大模型评测任务。

这里需要注意，Temperature = 0.1 是特定模型和任务条件下的实验选择，并不是所有 Judge 模型都适用的固定参数。

七、评测通过率突然下降，如何判断是真实缺陷还是评测误差？

在线评测系统运行一段时间后，测试团队会遇到一个新的问题：

某个业务域的执行成功率突然下降，到底是 Agent 变差了，还是评测系统出现了偏差？

淘宝技术公开的实践中有一个典型案例。

7.1 案例：Skill 路由成功率骤降，实际是评测分母异常

某个业务域的路由通过率突然出现明显下降。

如果只看最终指标，很容易怀疑是 Agent 路由能力发生回归。

但技术人员进一步拆解数据后发现：

• 成功进入该 Skill 的请求数量基本稳定。
• 被判定属于该业务域的请求总量却突然增长。
• 全站用户请求总量没有同步大幅增长。

更具体地说，该业务域的评测分母在两天内先翻倍、再接近原来的三倍，而分子基本保持平稳。

继续按照二级意图标签拆解，发现异常增长集中在某个 label 上。

这批请求大多是普通使用咨询，却被上游意图模型错误地归入当前业务域的投诉类标签。

由于评测入口直接使用了这类标签过滤样本，大量无关请求被纳入了路由成功率的计算分母。

修复过滤条件后，该业务域此前出现的指标跌幅消失，路由通过率恢复平稳。

7.2 这个案例对测试开发有什么价值？

它说明 Agent 在线评测至少涉及两套需要分别验证的系统。

第一套是被评测的业务 Agent。

第二套是负责采集数据、筛选样本、计算指标的评测系统。

当指标出现异常时，不能默认是第一套系统出了问题。

实际排障可以先检查指标计算的基础数据。

例如，将路由成功率拆为：

然后分别分析分子和分母的变化趋势。

下面是一段示意 SQL，用于观察每天路由成功率及其构成：

SELECT
    dt,
    skill_name,
    COUNT(*) AS total_queries,

    SUM(
        CASE WHEN route_success = 1
        THEN 1 ELSE 0 END
    ) AS success_queries,

    ROUND(
        SUM(
            CASE WHEN route_success = 1
            THEN 1 ELSE 0 END
        ) * 100.0 / NULLIF(COUNT(*), 0),
        2
    ) AS route_success_rate

FROM agent_eval_base
WHERE is_valid_sample = 1

GROUP BY dt, skill_name
ORDER BY dt, skill_name;

SQL 为示意代码，字段名和表名并非淘宝内部真实定义。

在真实工程中，还需要继续按照意图标签、流量入口、模型版本、Skill 版本等维度进行分组。

当成功数量保持稳定，而分母突然增加时，应优先核查流量分布、标签映射和评测入口条件。

这类分析可以避免团队把大量时间投入到并不存在的模型缺陷中。

八、如何验证 Judge 的评分结果足够可信？

模型能稳定输出，并不意味着评分准确。

例如，某个 Agent 正确返回“当前没有查询到订单”，Judge 却认为它没有提供完整订单列表，因此判定失败。

如果测试团队直接根据这个结果优化 Agent，反而可能诱导模型编造订单数据。

因此，淘宝采用了持续人工打标与规则校准机制，而不是只在评测系统上线前进行一次验证。

8.1 Judge 与人工标注持续对齐

整个过程可以概括为：

其中，人工标注承担的是评测标准校准和 Judge 质量验证的职责，而不是简单替代模型再打一次分。

8.2 为什么不能把通过率提升当成唯一目标？

假设某个业务域第一次评测通过率较低。

经过调整 Prompt，第二次评测通过率明显提高。

这可能意味着：

第一种情况，Judge 修复了误判，过去大量正确回复终于得到了合理评分。

第二种情况，Prompt 被调整得过于宽松，原本应该失败的案例也被放行。

两种情况下通过率都会上升，但代表的质量变化完全不同。

所以，评测体系应该同时观察：

• Judge 与人工标注的一致性。
• 失败样本的业务归因是否准确。
• 相同版本下评分是否稳定。
• Rubric 变更前后是否产生系统性偏差。

在样本量规划方面，淘宝实践还采用了置信区间估算思路。

例如，在简单随机抽样、近似独立且采用 95% 置信水平的条件下，为控制比例估计的误差，最保守情况下：

目标误差范围	约需样本量
±1 个百分点	约 4,000 条
±0.5 个百分点	约 15,000～15,400 条

这些是比例估计的近似统计要求，不等于评测系统已经达到相应的 Judge-Human 一致率。

如果抽样数据存在明显的用户聚集、长尾业务分布或者不同域占比差异，还需要采用分层抽样或其他调整方法。

8.3 四类归因，决定后续应该修复哪里

评测结果存疑时，可以将原因划分为四类。

归因类型	常见问题	修复对象
数据层	字段缺失、状态映射错误、工具日志噪声	数据清洗和加工逻辑
Prompt 层	模型理解规则错误、跨轮串扰	Judge Prompt
Rubric 层	通过与失败的判定边界不合理	评测规则和业务标准
Agent 质量层	工具参数错误、生成内容失实	业务 Agent 本身

这里有一个很重要的判断顺序：

先确认评测数据和标准没有问题，再将失败判定归因于 Agent。

否则，可能出现开发人员反复修改 Agent，却始终无法提高评测结果的情况。

因为真正需要修复的，是 Judge 或评测 Pipeline。

九、从评分到修复：在线评测如何驱动业务质量改进？

建立日级看板只是第一步。

如果看板只能显示“某域通过率 90%”，对于研发和测试团队来说，指导意义仍然有限。

更有价值的是将失败结果细分到具体原因。

例如，某个物流类业务域出现大量失败，可以继续统计：

• 物流状态描述不一致的数量。
• 预计送达时间错误的数量。
• 查询结果为空却编造内容的数量。
• 工具执行失败但回复称成功的数量。

然后对每类问题进行定点修复。

9.1 用可重复的规则验证修复效果

淘宝在某个时效类业务域中，通过多轮 Prompt 校准后，将失败样本进一步归纳为五类子问题，并交由业务研发处理。

在修复前后，团队使用 SQL 检测规则统计相关失败原因的命中情况。

最终结果表现为：

修复结果	问题类别数量
显著修复	2 类
大幅收敛	1 类
部分好转	1 类
尚未收敛	1 类

最后一个问题继续进入下一轮优化。

这种方法不要求每次优化都必须开展完整 A/B 实验，而是先通过可复跑的规则检查特定缺陷是否减少。

但要注意，评分理由的关键词命中数量只能作为辅助证据。若需要更严格地判断修复效果，还应固定样本口径，并考虑流量变化、模型版本及人工复核结果。

9.2 将质量问题转化为可跟踪的工程任务

从测试开发角度看，一条有价值的 Agent 评测失败记录，最好包含以下信息：

字段	作用
Trace ID	回溯完整会话与执行链路
Skill / Intent	定位业务域与用户意图
Judge 版本	确认判定模型
Rubric 版本	确认评分标准
失败维度	定位 CNT 六层中的故障位置
失败子项	细分错误类型
事实证据	支持人工复核
修复版本	关联实际修复内容
回归结果	判断问题是否收敛

这些字段不仅能服务质量看板，也为后续接入缺陷管理平台、自动生成回归用例以及组织训练数据提供基础。

十、淘宝这套在线评测体系，当前走到了哪一步？

从公开实践来看，淘宝已经建立了日级评测 Pipeline、统一 Rubric、Judge 人工校准与指标归因机制。

但这并不意味着整个 Agent 质量闭环已经实现完全自动化。

可以按能力成熟度划分为五个阶段。

阶段	能力目标	淘宝公开实践中的进展
L1 能评	构建评分标准、自动输出判定	核心能力已完成
L2 评得准	人工对齐、偏差控制、证据约束	持续建设中
L3 省又全	大规模评测、效率与成本优化	日级评测已实现，降本待推进
L4 自动闭环	失败归因、修复与回归联动	Pipeline 和归因已建成，训练反馈未打通
L5 自运营	自动异常检测、告警与持续运营	日级看板已建立，漂移告警等仍待完善

其中，下一阶段最值得关注的方向有三个。

10.1 使用小模型降低日级评测成本

高性能 Judge 模型具备较强的规则理解能力，但每天执行大量推理，会持续消耗算力资源。

一个可行的优化方向，是将人工标注结果和高质量 Judge 输出积累为训练集，通过 SFT 训练面向特定业务的轻量级评测模型。

更进一步，还可以考虑规则判定、小模型判定与高性能 Judge 分级协作。

但这些属于后续演进方向，不能将它们全部视为淘宝已完成的生产能力。

10.2 建立 Judge 自身的质量监控

在 Agent 升级时，测试团队会进行回归测试。

同样，Judge 模型版本、Rubric 或 Prompt 发生变化后，也应该验证评测器本身有没有退化。

例如：

同一批人工标注样本，在新旧 Judge 版本上分别评测，检查误判率变化、失败归因是否一致，以及对边界样本的处理是否发生改变。

这类机制也可以称为 Meta-Evaluation，即对评测系统进行评测。

淘宝的后续规划包括更系统的 Judge 偏差治理、多模型判定和元评测能力建设。

10.3 让失败样本参与 Agent 后续优化

更长期的方向，是将高可信度失败样本送入训练与优化流程。

包括对训练数据进行筛选，开展 SFT 或 GRPO 等优化，再利用回归评测验证新版本效果。

同时建设上线门禁、数据漂移监测和模型变更后的自动深度评测。

这样才能逐步形成：

线上发现问题 → 归因定位 → 修复或训练 → 自动回归 → 持续观测。

不过，自动训练与发布门禁仍需要额外的风险控制，不能仅凭单一 Judge 的评分直接决定模型上线。

十一、对软件测试开发团队有哪些借鉴价值？

淘宝这套方案并非只能用于电商业务。

企业内部知识库 Agent、客服 Agent、研发辅助 Agent、运维 Agent，以及具备多工具调用能力的智能体，都可以借鉴其思路。

但要将这些能力真正落地，建议按照以下顺序推进。

第一阶段：先建立可回放的测试证据

在 Agent 系统中统一记录用户请求、路由结果、工具调用参数、工具返回、最终回复和 Trace ID。

缺少完整执行证据时，任何自动评分机制都会存在较大的误判风险。

第二阶段：定义少量但明确的 Rubric

不必一开始就设计复杂的多维评分系统。

可以先选取一个高频业务域，将工具调用正确性、回答事实一致性、能力边界处理和安全要求拆解成清晰的通过或失败标准。

对于确定性条件，优先考虑程序化校验；对于自然语言语义判断，再使用 Judge。

第三阶段：建立人工标注校准集

从线上数据中抽取代表性样本，覆盖正常请求、异常工具返回、多轮对话、模糊意图和边界条件。

采用人工标注作为基准，验证 Judge 是否真正理解业务规则。

尤其要关注误判案例，而不是只观察总体通过率。

第四阶段：建设可持续运行的质量闭环

当评测准确性达到业务可接受水平后，再逐步接入自动调度、日级看板、分域质量趋势、失败归因以及回归验证。

这个顺序能避免一个常见问题：平台已经投入大量工程资源，却发现最基础的评分标准仍不可靠。

十二、Agent 在线评测的几个关键问题

1. LLM-as-a-Judge 可以完全替代人工测试吗？

不能。Judge 适合对大量自然语言结果进行持续评估，但仍需要人工标注来校准标准，并需要确定性自动化测试验证工具调用、接口契约和系统行为。

2. Agent 在线评测与离线评测最大的区别是什么？

离线评测主要验证预先定义的测试样本，在线评测关注真实生产请求及其随时间变化的质量表现。两者的数据完整性、业务分布、评测成本和质量目标不同，应当相互补充。

3. Agent 执行成功率越高，质量就越好吗？

不一定。只有在样本范围、评测标准、Judge 版本及数据口径保持可比时，通过率变化才具有较高的解释价值。单纯放宽 Rubric 也可能使通过率升高。

4. 为什么要对 Agent 评测结果进行归因？

因为一次任务失败可能来自意图路由、工具执行、回复生成，也可能来自评测数据或 Judge 自身。只有完成归因，才能确定应当修改哪一层系统。

结语

淘宝 AI 购物助手的在线评测实践展示了一种更接近生产环境的 Agent 质量保障方式。

这套体系将传统的上线前回归测试，扩展到了真实用户会话的持续观测，并通过结构化 Rubric、分域推理、人工校准和失败归因，把原本难以判断的自然语言交互转化为可分析、可追踪的工程数据。

对于测试开发人员来说，值得关注的不只是 LLM-as-a-Judge 本身，而是它背后的整个质量工程体系：

评测数据是否完整、判断依据是否可靠、标准变更是否可追溯、失败原因是否能够定位、修复结果是否能够得到验证。

当这些基础能力建立起来，Agent 评测才不再局限于生成一个分数，而能够成为持续改进 AI 系统质量的工程手段。

技术案例参考：大淘宝技术《淘宝AI购物助手在线评测落地实践》。本文结合测试开发工程视角重新组织与分析，文中示例 Prompt、JSON 和 SQL 为辅助理解而设计，不代表淘宝内部生产实现。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。