简介：从“文本评分”升级为“轨迹评分”，对比 LLM-as-Judge 与规则/人工评估的差异、适用边界与选型思路，并给出 Rubric 设计、偏置校准与结构化输出的落地要点，帮助团队构建可回放、可量化、可定位的评测闭环。

LLM-as-Judge 与规则评分怎么选：从结果评分到轨迹评分的最佳实践

agent-">一、对比背景：为什么 Agent 评估不能只靠“看答案”

构建一个“能用工具、能跑流程”的 AI Agent，在今天并不困难：接入模型、封装工具、串起工作流，几天就能跑通一个 Demo。真正困难的是回答一个问题——它到底可靠吗？

Agent 的质量不等于“回答写得好”，而取决于它在真实环境里能否稳定完成任务：理解对、计划对、工具用对、参数填对、失败能恢复、长期交互不跑偏、成本可控且可审计。这就把评估从一个“文本打分问题”变成了一个“系统工程问题”。

在工程实践中，评估手段大致可以分成两类：一类是规则/精确匹配/人工评估这类确定性或半确定性方法，另一类是LLM-as-Judge这类以模型作为评判者的方法。两者并非替代关系，而是各有适用边界。本文围绕这两种评估范式展开对比，并重点讨论 LLM-as-Judge 落地时的 Rubric 设计、偏置校准与结构化输出要点。

二、对象定义：两种评估范式分别是什么

规则评分 / 精确匹配 / 人工评估

规则评分：通过预设断言（assertion）判断，例如“最终答案是否包含订单号”“工具调用参数是否与预期 schema 一致”“是否在规定轮次内完成”。
精确匹配：将输出与标准答案逐字或按语义阈值比对，适合答案空间收敛的任务。
人工评估：由标注人员按评分表打分，适合主观性强、样本量可控的场景。

LLM-as-Judge

用一个（或多个）大模型作为“裁判”，依据给定的评分标准（Rubric）对 Agent 的输出或轨迹进行打分、排序或给出判定理由。
可以是单点评分（pointwise）、两两对比（pairwise）、也可以是带参考标准的打分（reference-based）。

轨迹评分（Trajectory Evaluation）

不论用哪种裁判，评估对象都从“最终回复文本”扩展到“整条轨迹”：多轮对话 + 每一步工具调用 + 参数 + 中间状态。
轨迹需要可回放、可量化、可定位，才能支撑定位到具体是“理解偏差”“工具选择偏差”还是“参数填充偏差”。

三、相同点：它们解决的是同一类问题

目标一致：都是要把“Agent 是否可靠”从主观感受变成可比较、可回归的量化信号。
都需要评分口径：规则评分需要定义断言集，LLM-as-Judge 需要定义 Rubric，本质都是把业务目标拆解为可判定的维度。
都服务于 EDD 闭环：离线评估 + 影子流量 + 灰度门禁 + 生产监控 + 自动回归，两种方法都可以嵌入其中任一环节。
都受非确定性影响：同一输入可能产生不同轨迹，因此两者都需要在数据集和统计口径上做重复采样与聚合，而不能只看单次结果。

四、核心差异分析

4.1 判定依据：确定性规则 vs 概率性判断

规则评分依赖显式断言，结果可复现、可解释；LLM-as-Judge 依赖模型推理，天然带有概率性。前者在“参数是否填对”“是否调用了正确工具”这类硬性检查上更稳，后者在“语气是否得体”“计划是否合理”这类软性判断上更灵活。

4.2 覆盖范围：收敛答案 vs 开放输出

精确匹配只适合答案空间收敛的任务。客服、销售、助理类 Agent 的成功往往是“在约束下完成目标并让用户满意”，输出空间巨大，必须引入更贴近业务目标的指标与规则。LLM-as-Judge 正是在这种开放输出空间下才有明显优势。

4.3 成本结构

规则评分：开发期人力成本高（要写断言），运行期成本极低。
人工评估：运行期成本最高，难以规模化。
LLM-as-Judge：开发期成本中等（写 Rubric），运行期有推理成本，需评估 token 开销与延迟。

4.4 稳定性与偏置

LLM-as-Judge 存在已知偏置：位置偏置（偏好某个位置的答案）、长度偏置（偏好更长的回答）、自我偏好（偏好与自身风格相近的输出）、格式偏置（被排版影响判断）。规则评分几乎没有这类问题，但会因断言设计不当而漏判“形式上通过、实质上错误”的情况。

4.5 可定位性

轨迹评分要求能定位失败点。规则断言天然给出“哪一条断了”；LLM-as-Judge 若只输出一个总分，定位能力弱，因此必须做结构化输出：分维度、分步骤给分并给出理由。

4.6 对比表格

维度	规则评分 / 精确匹配	人工评估	LLM-as-Judge
判定依据	显式断言	人判断	模型按 Rubric 判断
可复现性	高	中	中（需控温、控提示）
开放输出适配	差	好	好
运行成本	低	高	中
规模化能力	强	弱	强
偏置风险	低	中（主观）	高（位置/长度/自我偏好）
失败定位	强（断点明确）	中	依赖结构化输出
适合环节	回归门禁、参数校验	冷启动校准、争议样本	离线评估、灰度对比、生产抽检

五、LLM-as-Judge 落地三要素

5.1 Rubric 设计：把业务目标拆成可判定维度

Rubric 不是“给个分”，而是把目标分解成维度 + 判定标准 + 分档描述。以客服 Agent 为例，可拆为：意图理解准确性、工具选择正确性、参数填充正确性、约束遵守（如不越权承诺）、失败恢复能力、最终任务完成度。

每个维度给出 0/1 或 1–5 的分档，并写明“什么情况给几分”。维度之间尽量正交，避免一个错误在多个维度重复扣分。

5.2 偏置校准：让裁判更接近人类判断

位置偏置换位：两两对比时交换 A/B 顺序各评一次，取一致结果或标记为不一致样本。
长度偏置控制：在 Rubric 中显式声明“长度不作为评分依据”。
自我偏好缓解：使用与生成模型不同的模型做裁判，或使用多裁判投票。
与人工对齐：抽样一批样本由人工打分，计算裁判与人工的一致性，作为裁判是否可用的前提。

5.3 结构化输出：让分数可定位、可聚合

要求裁判输出结构化结果，而不是一段自然语言。示意性伪代码：

{
  "trajectory_id": "case_001",
  "dimensions": [
    {"name": "intent_understanding", "score": 1, "reason": "正确识别退款意图"},
    {"name": "tool_selection", "score": 1, "reason": "先查订单再退款，顺序正确"},
    {"name": "param_filling", "score": 0, "reason": "订单号少一位"}
  ],
  "step_scores": [{"step": 1, "score": 1}, {"step": 2, "score": 0}],
  "final": {"task_completed": false, "overall": 0.67}
}

结构化输出带来三个好处：可聚合到系统级指标、可按步骤定位失败、可做跨版本回归对比。

六、典型场景选择

参数校验、工具调用合规、回归门禁：优先规则评分，快、稳、便宜。
主观体验、计划合理性、对话质量：优先 LLM-as-Judge，配合人工抽样对齐。
开放式任务的批量离线评估：LLM-as-Judge 为主，规则断言做兜底。
冷启动阶段：先小样本人工评估建立 Rubric 与基准，再迁移到 LLM-as-Judge 规模化。
高风险场景（资金、权限）：以规则与人工双重把关，LLM-as-Judge 仅作辅助信号。

七、选型建议与使用边界

不要二选一：把规则评分当“硬门禁”，把 LLM-as-Judge 当“软信号”，两者互补。
先定轨迹 schema，再选裁判：没有统一的轨迹日志，任何评估都无法定位。
裁判本身要被评估：定期做裁判与人工的一致性校验，避免“用一个不确定去评估另一个不确定”。
关注成本与延迟：裁判推理会随轨迹长度增长，需要在采样率和维度数量上做权衡。
边界意识：LLM-as-Judge 不适合单独用于高风险决策；规则评分不适合评估开放式的满意度与语气。

八、迁移与注意事项

从纯规则评分迁移到“规则 + LLM-as-Judge”混合体系时，需要注意：

数据与日志：先补齐可回放的轨迹日志，否则无法做步骤级评分。
口径一致性：Rubric 版本要纳入版本管理，避免不同批次评分口径漂移。
权限与合规：轨迹中可能含用户敏感信息，裁判调用链需做数据隔离与最小化。
稳定性：裁判模型或提示词变更等同于评估体系变更，需重新做一致性校验。
回归风险：指标口径变化会让历史基线失效，迁移时要并行跑一段时间做双轨对比。

九、总结

Agent 的评估要从“文本评分”升级为“系统工程问题”：目标分解、数据集工程、组件与系统级指标，以及贯穿开发到上线的闭环治理。规则评分与 LLM-as-Judge 并非对立，而是分别适配“硬性校验”和“软性判断”两类需求。落地 LLM-as-Judge 的关键，在于把 Rubric 设计成可判定的维度、把偏置校准成可度量的过程、把输出约束成可定位的结构化结果。最有效的团队会采用评价驱动开发（EDD）：离线评估 + 影子流量 + 灰度门禁 + 生产监控 + 自动回归，让评估真正成为 Agent 可靠性的基础设施，而不是一次性的打分动作。

LLM-as-Judge 与规则评分怎么选