重塑 Agent 度量衡：基于 LLM-as-a-Judge 的离线评估体系与实践

1. 背景：Agent评估的困境与需求

1.1 从单轮问答到Agent

当前的AI外呼已经从传统的一问一答的FAQ模式（如基础外呼bot）演进为AI Agent模式，复杂的业务场景要求Agent必须同时具有两种能力：

• FAQ（知识解答） ：精准理解并生成回应用户疑问的话术；
• SOP（流程执行） ：严格遵循预设的业务策略推进对话，针对用户的具体需求进行自主规划（planning） 并在合适的时机传递正确的参数来调用合适的工具，通过执行工具（action） ，切实解决用户诉求。

1.2 为什么需要Agent 评测

随着ai外呼对话复杂度的提升，Agent系统不可避免的需要进行不断的技术迭代（如：持续优化prompt、扩充RAG知识库、或者替换底层的基座模型等）。在这一过程，我们需要构建一套可量化的度量标准：

• 防范功能退化（Regression）： 确保每一次局部的策略调优或知识库更新，没有导致系统其他核心能力下降（避免“修好 20 个 Badcase，却搞坏了 80 个 Goodcase”的盲目迭代）。
• 量化迭代收益（Optimization）： 在更换基座模型或部署方式时，通过明确的数据指标来证明新版本确实优于老版本，从而为架构选型提供客观的决策支撑。

1.3 缺乏高效可靠的量化指标

传统的大模型（LLM）评测，侧重于静态检验单次输出的“正确性、流畅度与合规性”。而 Agent 作为一个具备调用外部工具与自主决策能力的系统，我们评测的对象也应该作出改变：

• 我们不仅仅评估 “最终结果” ：回复话术是否符合策略设定，是否能达成业务目标；

• 还要校验 “中间过程” ：能否在正确时机触发正确的工具、传递给API的参数是否正确等。

1.4 破局点：引入LLM-as-a-Judge

为了应对量化Agent质量的诉求、解决量化指标的缺乏，我们的方案是引入LLM-as-a-Judge，构建一套客观、高一致性的自动化Agent评估引擎。

2. 行业调研：LLM-as-a-judge

3. 方案设计：场景定制化

前面提到复杂的业务场景要求Agent必须同时具有两种能力——FAQ和SOP。在大车ai外呼场景下：

• FAQ——ai客服的话术回复能力；
• SOP——策略设定好的推进流程、工具调用能力。

在日常迭代中：

基础模型（LLM）的优化不仅会影响SOP——遵循prompt推进流程，调用工具；因为基础模型理解能力的差异，也会影响FAQ——即使完全相同的prompt和参考话术，也可能给出完全不同的答案。

在基础模型不变，仅仅是Harness（非LLM）优化时，基础模型的理解能力保持稳定，因此我们只需要验证SOP。

3.1 基础模型（LLM）优化场景的评测

3.1.1 Reference-based + GSB混合方案

1. 为什么不能单独使用 Reference-based？

reference-based只能判断在对应业务场景下，线上模型和候选模型是否“正确”，但无法在两个“正确”的回复中判断“更优”话术。换言之，候选模型100%正确并不代表候选模型具备与线上模型相当（或更优）的话术回复能力。

2. 为什么不能单独使用 GSB（线上 vs 候选 双盲对比）？

GSB 虽然能够判断话术的“优劣”，但是无法决策回复是否“正确” 。即使候选模型与线上模型胜率相同，但是我们无法得知候选模型是否以牺牲业务事实的“准确性”换来表面上“更优”的回复。

我们通过将reference-based和GSB方案结合在一起，在“正确”的前提下，选择“更优”回答：

1. 第一关：Reference-based（回归拦截）： 确认候选模型在goodcase中未发生退化，确保能力有保障。
2. 第二关：GSB（细节寻优）： 在验证“正确性”后，针对话术细节等主观维度进行对比，最终决策出更优模型。

2. 具体方案

步骤	step1：Reference-based方案——防范功能退化	step2：GSB方案——量化迭代收益
评估指标	迭代前后的语义一致率	Win rate（新模型 vs baseline）
打分逻辑	设计明确的评分标准，统计输出发生退化的占比	采用 GSB (Good/Same/Bad) 体系，统计 Win Rate
核心prompt骨架

3.2 Harness（非LLM）优化场景的评测实践

3.2.1基于reference-based的评测方案

不同于基础模型（LLM）优化时需要“优中选优”，Harness 的迭代通常是为了修复明确的业务缺陷（Badcase）。此时不再适合使用GSB方案：

• 追求“确定性达标”而非“主观偏好” 核心关注工具调用与 SOP 遵循等客观事实判定（对或错），而非话术体感；
• 聚焦“功能纠错”而非“能力演进” 优化目标明确为纠正错误逻辑。只需要确认迭代后没有失去已有的遵循能力。

3.2.2 具体方案

目前我们仅尝试了针对Agent最终结果的评估：Reference-based方案（方案同上文所述）。

不过，一旦进入更复杂的工具调用场景，只盯着最终回复，也就是最终结果，很多中间环节的逻辑偏差其实很容易被遮住。眼下的问题在于，离线仿真环境还不完善，同时也拿不到中间过程的数据。因此，后续会在离线仿真环境中引入judge模型，专门评估这些中间过程，用更白盒的方式检查 Agent 的意图分析是否准确、API 传参是否合规，并进一步验证 Agent 的 planning-action 循环（中间过程）是否真正符合策略要求。

4. 实践：评估手段实现和效果

在实际使用过程中，我们发现了一个关键问题：“ 即使有了完整的 Prompt 框架，选择了能力强的judge模型 ，评估结果仍然可能不可靠—— LLM-as-a-judge存在系统性偏见。 ”

4.1 系统性偏见消除

在实际应用中，我们发现judge模型的打分经常与人类预期不一致，导致结果不可信。

因此在使用LLM-as-a-judge方法时，我们采用了“judge模型选型”和“工程消除偏见”两个方法消除系统性偏见带来的评估结果不可信。

4.1.1 Step 1：judge模型选型

在大车外呼场景下，我们测试的是Qwen3 235B（选择了 DeepSeek V3.2作为judge模型）后续有其他可使用的能力更强的模型也会进行尝试。

选择能力更强的模型作为judge模型不仅仅是因为“评估”任务本身的难度，我们使用DeepSeek评估Qwen也是为了消除 “自我偏好” ，这也是消除系统性偏见的策略。

4.1.2 Step 2：系统性偏见消除

前文提到的在大车外呼场景下我们对评测逻辑的拆解：

正是为了消除系统性偏见中的 “风格偏见”

4.2 大车-提估转场景效果

为验证LLM-as-a-judge方案的可靠性，我们在整个迭代周期与最终验收阶段，始终将人工标注结果作为基准（Ground Truth）。在促估转场景下测试了：底层大模型整体切换，推理引擎切换，回归测试三个使用场景，均获得了极高的收益：

• 极高的一致性 在提估转场景的测试中，我们的评估引擎与人工标注高度对齐，验证了大模型评估标注的可信度：

  • 推理引擎切换： 模型与人工评估的一致率达到 97% 。
  • 回归测试： 模型与人工评估的一致率达到 98% 。

• 极致的效率释放 传统的评测方案占用了大量宝贵人力，通过将评估任务交给大模型，彻底释放了评估人力

  • Reference-based方案： 过去人工离线评估的速度极限约为 100 case/小时。交由大模型引擎后，100 个 case 的评测被压缩至 5 分钟以内。
  • GSB方案： 虽然目前受限于底层 DeepSeek 接口的并发调用配额限制，大模型跑完 100 个 case 的物理耗时拉长到了 5 小时（人工需 1 小时）。但核心质变在于：可以利用晚上闲时时间使用机器，全程实现了 0 人工干预。

5. 未来规划

目前我们的离线评测主要聚焦于Agent的最终回复。下一步，我们将向更深处探索，构建更全面的评估能力。

1. 引入轨迹与日志评估：引入完整的 Agent 执行轨迹（Trajectory）与日志（Trace） ，实现对中间过程的精准度量。

2. 自动化评测Planning-Action循环：建立仿真测试环境，自动评估Agent在复杂决策链中每个“思考-行动”步骤的合理性。

3. 要真正把“评测-归因-修复”这套闭环跑起来，关键就在于把评估结果和问题根因分析（归因）直接打通。换句话说，不能只停留在“发现有问题”这一步，而是要顺着大模型的中间输出和工具调用日志一路往下查，准确锁定问题到底出在哪儿——究竟是意图理解跑偏了、API传参出错了，还是基模本身出现了幻觉。这样一来，评测系统的价值就不只是“报错”，而是能够进一步给出有针对性的策略/Prompt 优化建议，最终把“评测-归因-修复”真正闭成一个可落地的业务闭环。

作者：AI应用组 ｜余嘉慧、吴立薪、万勇韬

附录

大模型偏见

文章验证大模型都有偏见