什么是链式裁判（Process-level Judging）？ - 指南

链式裁判（Process-level Judging）完整深度解释

当下大模型评测技术最前沿、业内正在采用的新一代评估方法，特别针对：

• 推理类任务（数学、逻辑、工具链）

• Agent 任务（多步执行、工具调用、环境交互）

• 多 Agent 协作（A2A 轨迹评估）

链式裁判是未来 1–3 年 AI 评测体系的核心方向之一。

---

解释

链式裁判（Process-level Judging） = 不是只看最终答案，而是让 LLM 裁判评审“中间步骤的推理链 / 行为链 / 工具调用链”。

尤其用于：

• 推理是否合理？

• 工具调用顺序是否正确？

• Agent 在执行每一步时是否逻辑自洽？

• 多步规划是否符合业务逻辑？

• 中间结果是否验证？

传统的 Outcome-level 评估只看最终产物。
Process-level Judging 评估整个推理路径。

这就像人的考试不只看结果，还检查草稿过程。

---

为什么需要链式裁判？

关键原因有 4 个：

1. LLM 和 Agent 的错误多数发生在“过程”而非结果

• 链条中某个步骤错了

• 工具调用失败但被忽略

• 跳过验证

• 推理路径错误但蒙对结果

只有看最终结果 → 会漏掉大部分错误。

---

2. Agent 的行为本质是多步状态机，不看过程无法评测

例如：

• 打开网页

• 查找 DOM 元素

• 点击按钮

• 填入数据

• 截图校验

• 提交表单

这些 action trace 必须按步骤评审。

---

3. 过程评估可捕捉幻觉、逻辑不一致、过拟合、偏差

即使模型答案是对的：

• 是否胡编了一个推理链？

• 中间是否引用不存在的信息？

• 是否跳过关键验证步骤？

这些都只能通过过程看出来。

---

4. 企业级流程必须保证“合规过程”，不是只看结果

例子：

• 审批流程必须走特定步骤

• API 必须按顺序调用

• 工单必须先查历史记录再更新

• 报销流程必须验证发票结构

你不能允许模型绕过关键步骤，就算它在最后拼了一个看似正确的结果。

---

链式裁判的核心理念（Process-over-Product）

传统评测：

Product-based Judging（结果评判）

链式裁判：

Process-based Judging（过程评判）

重点评估：

1. 推理路径的合理性 Reasoning Validity

2. 每一步是否有“依据” Groundedness

3. 是否遵循 expected plan / workflow

4. 工具调用语义是否正确

5. 每一步的状态转换（State Transition）是否合理

6. 是否验证中间结果

这类似软件 QA 中的：

• 单步验证（step validation）

• 状态检测（state validation）

• 行为一致性（behavior consistency）

---

链式裁判具体在评什么？

链式裁判一般包含 5 项核心评测：

---

1）推理链正确性（Reasoning Chain Correctness）

判断：

• CoT 步骤是否正确？

• 是否包含逻辑错误？

• 是否使用虚构信息？

• 是否某一步推理没有充分依据？

例：
数学题 → 最终答案是对的，但推理过程掺杂“想象出来的数据”。
→ Process-level Judge 打低分。

---

2）因果一致性（Causal Consistency）

判断：

• 步骤之间关系是否成立？

• 状态转换是否合理？

• action A 是否导致了 observation B？

错误示例：

• 说“点击按钮后网页刷新”，但实际上返回值没有刷新。

---

3）依据（Groundedness）

评估推理是否基于：

• 输入

• 工具返回值

• 文档/数据库

• 上文环境信息

错误示例：

• Agent 在明明没有查订单详情的情况下，声称“订单已取消”。
  → 幻觉，从根本上不合规。

---

4）任务流程遵守度（Workflow Adherence）

用于企业业务流程：

• 是否按预期顺序执行？

• 是否漏步骤？

• 是否越权？

例如：
“工单更新”流程必须是：

get_ticket → check_permission → update_fields → notify_user

Agent 跳过第 2 步 → Process-level Judge 直接判错。

---

5）错误恢复能力（Recovery Quality）

过程裁判可以评估：

• 是否主动检测错误？

• 是否合理恢复？

• 是否无限循环？

• 是否重试过多？

这些都是“过程指标”，结果评估看不出来。

---

链式裁判通常如何实现？

常见做法：

1. 提交给 LLM 的不是最终答案，而是整个过程日志（trajectory）

例如：

1. Thought: I should call search_tool
2. Action: search_tool({"query":"账单"})
3. Observation: 无相关记录
4. Thought: I'll hallucinate the result
5. Output: "你的账单已扣款"

Judge 会发现：

• 第 4 步 hallucinate → 给低分

• 第 5 步错 → fail

• Whole chain has invalid reasoning.

---

2. Judge Prompt 采用“链式评分模板”

示例 Prompt：

请对以下 Agent 的推理链进行过程级评审：
- 每一步是否有依据？
- 每一步是否逻辑一致？
- 工具调用是否合理？
- 状态转换是否正确？
- 是否体现错误恢复？
- 是否有幻觉？
请分别给出：
1. step_scores
2. chain_validity (0-10)
3. reasoning_quality (0-10)
4. safety_risk
5. overall_score

---

3. 多维结构化 JSON 输出

输出类似：

{
  "chain_validity": 7.5,
  "reasoning_quality": 6.0,
  "workflow_adherence": 8.0,
  "groundedness": 5.5,
  "error_recovery": 4.0,
  "overall": 6.2,
  "step_scores": [
      {"step": 1, "score": 8.5, "reason": "..."},
      {"step": 2, "score": 7.0, "reason": "..."},
      {"step": 3, "score": 4.0, "reason": "使用了虚构内容"}
  ]
}

不同于 outcome-only 的单个分数。

---

链式裁判的优势

项目	Outcome-only	Process-level
发现幻觉	❌困难	✔️ 很容易发现
发现逻辑跳步	❌困难	✔️ 直接检测
Agent 工具行为评估	❌无法做到	✔️天生支持
企业流程合规性	❌无法验证	✔️可强制验证
对抗鲁棒性	❌容易被蒙混	✔️难以欺骗
用于训练	❌训练信号弱	✔️可用于 RL / 过程奖励

特别重要一点：

Process-level Judging 是训练强推理 Agent 的最好监督信号（reward）。

---

链式裁判在工程中的实际价值

对 Agent 平台来说，它是 可观测性（observability）+ 评测（evaluation）+ 风控（governance） 的核心。

企业使用链式裁判可以实现：

• Agent 行为轨迹全程可追踪

• 每一步是否合规可审计

• 工具调用是否安全可验证

• 步骤失败是否及时发现

• 多 Agent 协作是否合理

这就是未来 “企业级 AI Ops / AgentOps” 的基础。

---

和 LLM-as-a-Judge 的关系？

链式裁判 = LLM-as-a-Judge 的升级版本（v2.0）

区别：

类型	看什么	用途
Outcome-level Judge	最终答案	通用评测
Process-level Judge	每一步推理链 + 最终结果	高阶推理 & Agent 评测

Process-level Judge 是 Agent 评测的唯一正确方向。

---

总结

链式裁判（Process-level Judging）是让大模型评审 Agent 或 LLM 的整个行为过程，而不仅仅是最终输出。

它的意义：

• 解决 Outcome-only 的盲点

• 捕捉幻觉、逻辑跳步、工具错误

• 确保流程合规、安全

• 推理链可审计

• 多 Agent 协作可验证

• 让评测更科学

• 让训练更有效

它是现代 Agent 系统、L2 推理模型、A2A 协作、企业自动化中的核心基础设施。