重塑 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的参数是否正确等。

在AI外呼的复杂交互场景下，Agent 面对的是泛化且不可预测的多轮对话。传统的测试方案已经无法满足迭代的需求。

测试方案	存在问题	示例
正则匹配	正则匹配规则无法覆盖所有相同语意的回复。	"5米2及以上的车型是一口价" 和 "货拉拉的大货车都是一口价" 语意是一致的，但是传统规则匹配方案会判定为不一致
人工评测	极度耗时（约800/人天），且面对长对话时，人工判定标准容易被个人主观影响。	比如按照参考答案回答更好还是结合用户需求回答更好 - 参考答案：您在选车时，点击车型图可以看到详细的车厢长宽高和载重，以此来匹配您的货物，你可以多切换车型看看哪个合适呢。 - 实际回答：钢琴这种大件物品确实需要特别注意。您考虑用多大的车呢？5米2以上的车型应该都能装得下，您可以根据实际需求选择合适的车型。您现在就来下单好吧！

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

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

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

在实践前，我们对行业主流的评估手段进行了调研与对比，了解业界如何利用LLM-as-a-judge加速指导迭代。

在大车ai外呼场景下，我们可以将需要评估Agent的场景分为：基础模型（LLM）优化、Harness（非LLM）优化。

基础概念：

Agent = LLM + Harness

LLM：纯粹的文本输入/输出，自身不能直接操作外部世界。它的职责是基于上下文进行语义理解、意图识别，并生成对应的回复内容或输出调用工具的指令

Harness：负责将 LLM 包装成具有自主行动能力的 Agent。它包含系统 Prompt 模块、RAG 知识库检索模块、以及与外部环境交互的工具调用执行器。

评估场景	评估对象	评估手段	核心机制	具体方案
基础模型（LLM）优化	Agent的最终结果	无参考打分 (Reference-free / Point-wise)	提供详细的评分维度或检查单（Rubric），不提供任何参考答案，让`judge模型`直接对单次输出打分（如1-5分）或做二分类判断（如Yes/No）。	/
		有参考对齐 (Reference-based)	提供"黄金参考答案 (Golden Answer/Ground Truth)"，强制`judge模型`比对当前输出与参考答案的核心事实和语义一致性。	在Gemini迭代时，Google在如GPQA、MATH、MMLU、MTOB、Natural2Code等公开benchmark上进行测试，验证模型能力。
		双盲对抗 (Pairwise / GSB)	`judge模型`同时接收版本 A 和版本 B 的输出，进行盲测对比，直接输出胜者（Win/Tie/Loss）	在Gemini迭代时，Google对比迭代前后模型输出在输出质量、指令跟随、输出语气等方面"谁更好"，称为Auto SxS（side by side）。
	Agent的中间过程	动态轨迹评估 (Agent-as-a-Judge / Trajectory Eval)	在离线仿真环境中运行Agent进行多轮交互，`judge模型`最终对整条对话轨迹（Trajectory）和业务结果进行打分。	/
harness（非LLM）优化	Agent的最终结果	无参考打分 (Reference-free / Point-wise)	提供详细的评分维度或检查单（Rubric），不提供任何参考答案，让`judge模型`直接对单次输出打分（如1-5分）或做二分类判断（如Yes/No）。	Anthropic制定了详细的安全规则，确保模型不会输出带有潜在危险的内容（如化学/生化武器的生产）
		有参考对齐 (Reference-based)	提供"黄金参考答案 (Golden Answer/Ground Truth)"，强制`judge模型`比对当前输出与参考答案的核心事实和语义一致性。	Anthropic指出应该在迭代过程中进行回归测试，要求在线上goodcase上几乎达到100%通过，防止发生退化
		双盲对抗 (Pairwise / GSB)	`judge模型`同时接收版本 A 和版本 B 的输出，进行盲测对比，直接输出胜者（Win/Tie/Loss）	/
	Agent的中间过程	动态轨迹评估 (Agent-as-a-Judge / Trajectory Eval)	在离线仿真环境中运行Agent进行多轮交互，`judge模型`最终对整条对话轨迹（Trajectory）和业务结果进行打分。	Anthropic构建了沙盒环境 (Sandbox environment) 并使用大模型审查系统 (LLM-based Auditing System) 对中间的 API 调用链进行逐行审查。

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

需要注意的是，虽然Google和Anthropic针对不同的评估场景和评估对象都提供了相应的评估手段，但是无法直接应用在大车外呼场景：

大车ai外呼场景是针对特定业务场景的，直接通过公开的benchmark无法衡量Agent在指定业务场景下的表现

Google和Anthropic以及其他业界解决仅定义了通用的评估手段，缺乏多种方案如何协作的评估细节，无法直接应用

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

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

在日常迭代中：

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

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

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

3.1.1 Reference-based + GSB混合方案

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

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

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

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

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

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

具体方案

步骤	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模型的打分经常与人类预期不一致，导致结果不可信。

在做GSB时，我们交换两个输出的位置，judge模型总是倾向于选择位置靠前的输出。经过实践和查阅文献，我们确认了judge模型本身存在严重的系统性偏见（Systematic Bias），系统性偏见的存在直接导致了大量结果与人类评估结果不一致，造成评估结果不可信。
经过深入的排查与查阅文献，所有大模型都天然存在偏见问题，可参考附录，来源：《 Judging the Judges: A Systematic Study of Position Bias in LLM-as-a-Judge 》

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

4.1.1 Step 1：`judge模型`选型

核心原则： 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的最终回复。下一步，我们将向更深处探索，构建更全面的评估能力。

引入轨迹与日志评估 ：引入完整的 Agent 执行轨迹（Trajectory）与日志（Trace） ，实现对中间过程的精准度量。
自动化评测Planning-Action循环：建立仿真测试环境，自动评估Agent在复杂决策链中每个"思考-行动"步骤的合理性。
构建"评测-归因-修复"闭环 ：将评估结果与问题根因分析（归因）直接关联，通过分析大模型的中间输出和工具调用日志，精准定位问题源头（是意图理解偏差、API传参错误、还是基模幻觉）。最终，让评测系统不仅能"发现错误"，还能输出定向的策略/Prompt 优化建议，真正实现"评测-归因-修复"的业务闭环。

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

附录

大模型偏见

文章验证大模型都有偏见