自动为 AI 智能体输出打分

在 AI 智能体的质量保障体系中，确定性测试长期占据主导地位：断言工具是否被调用、参数是否正确、返回值是否符合预期。然而，这类测试存在一个根本性盲区——它们无法判断最终呈现给用户的自然语言回答是否准确、完整、符合政策要求。一个客服智能体可以在工具层面表现完美，却在回复中遗漏关键的退款期限，而没有任何测试会捕捉到这个问题。

LLM-as-a-Judge 的核心思路是引入第二个模型专门承担评分职责。候选模型负责完成原始任务并生成输出，裁判模型则只负责依据开发者预先编写的评分标准对该输出进行打分，两者角色严格分离。研究人员 Zheng 等人在 2023 年的论文中指出，裁判模型存在自我增强偏差、位置偏差和冗长偏差，因此应尽量避免让同一模型同时担任候选和裁判，并且只向裁判提供其评分所需的可见输出和工具结果，而非候选模型的内部推理过程。

评分模式上，LLM 裁判支持三种主要形式：逐点评分（Pointwise）针对单个输出按标准打分，适合在 CI 中设置质量门槛；成对比较（Pairwise）同时提交两个候选输出进行对比，适合跨模型或跨版本的横向评估；基于参考的评分（Reference-based）则在提供可信参考答案的前提下检验事实覆盖率。评分标准的写法至关重要：「引用了 14 天退款窗口且未自行发明例外情形」是有效的标准，而「听起来很有帮助」则过于模糊，无法产生一致的评分结果。

OpenRouter 的 Ori Eval 框架将裁判模型的集成流程标准化。开发者通过 setupJudge 函数在独立模型上创建评分智能体，再用 autoEvals 函数将候选运行结果与评分标准进行比对。整个评估文件以 TypeScript 编写，由 Bun 测试运行器执行。Ori 在每次运行时固定使用同一个 harness 和模型配置，确保评估环境的一致性；若需跨模型比较，则为每个候选模型单独启动一次运行，最终汇总分数、耗时和成本数据供开发者参考。

在适用场景的边界上，LLM 裁判并非万能替代品。JSON 结构验证、算术计算、工具参数断言等可直接检查的结果，仍应使用模式验证器、计算器和单元测试处理。对于必须始终阻止某个动作的关键策略规则，确定性测试应作为唯一执行层，裁判模型只负责审计最终回答的质量，而不应成为策略执行的唯一保障。两者分工明确，才能构建既严格又灵活的评估体系。

评估成本的管控同样不可忽视。在生产环境中对每一条输出都运行裁判模型会带来显著的额外开销，常见的应对策略包括：对生产样本进行随机抽样评估、在 CI 中仅对关键测试用例启用裁判、以及为评分任务选用参数量更小的轻量模型。将裁判评分结果与人工标注的小型样本集进行定期校准，也是保持评估可靠性的重要手段，可以及时发现裁判模型本身的漂移或偏差。

要点

• 确定性工具测试与 LLM 裁判评分应互补使用，前者覆盖可精确验证的行为，后者覆盖开放式自然语言输出的质量。
• 裁判模型与候选模型必须分离，且裁判只应看到候选的可见输出，而非其内部推理，以保证评分独立性。
• 有效的评分标准需具体可操作，能够被人工一致应用，模糊的主观描述无法产生可重复的评分结果。
• 逐点、成对、基于参考三种评分模式各有适用场景，应根据评估目标选择合适的模式。
• 通过抽样、选用轻量裁判模型并定期与人工标注结果校准，可在保证评估质量的同时有效控制成本。