9. Deterministic Evaluation：先把能确定的事情确定下来

Evaluator 技术 · 2～3 小时

学习目标

1. 掌握 Exact/Schema/AST/Regex/Numeric 等确定性评测
2. 知道什么时候绝不能优先使用 LLM Judge
3. 设计可解释的组合规则

前置知识

• 第 4～8 章
• 基本测试与数据结构知识

本章产物： 实现至少 5 类确定性 Scorer。

9.1 确定性优先

如果结果可以通过程序可靠判断，就不应先让另一个 LLM“猜”。

典型场景：

• JSON 是否满足 Schema；
• 工具名是否正确；
• 参数是否属于允许集合；
• 金额是否在数值容差内；
• SQL 是否包含禁止操作；
• 代码测试是否通过；
• 文件是否存在；
• API 响应字段是否匹配。

确定性 Scorer 的优势：

低成本
高速度
可复现
可解释
容易回归

9.2 Exact Match

适合：

• 短唯一答案；
• ID；
• 枚举；
• 严格协议字段。

不适合开放式自然语言。

def exact(actual, expected):
    return actual.strip() == expected.strip()

不要为了让 Exact Match 看起来高而过度 normalize。Normalize 规则本身也是 Evaluator 的一部分，需要版本化。

9.3 Structured Validation

Agent 输出 JSON 时建议分三层：

Syntax Valid?
    ↓
Schema Valid?
    ↓
Semantic Correct?

示例：

{
  "tool": "create_ticket",
  "priority": "P1",
  "owner": "alice"
}

JSON 合法不等于业务正确。Schema 也不能验证 owner 是否真实存在。

9.4 Numeric Evaluator

数值任务需要显式容差：

abs(actual - expected) <= abs_tol + rel_tol * abs(expected)

不要依赖字符串完全一致，例如 0.3 与 0.3000。

9.5 AST / Parser-based

对于：

• SQL；
• Python；
• Function Call；
• 表达式；

优先解析成结构后再比较。

例如 Function Calling：

tool name
argument names
argument values
types
parallel calls

比比较 JSON 字符串稳定。

9.6 Execution-based

很多时候最强的 deterministic scorer 是：

执行结果。

例如代码：

patch
  ↓
unit tests
  ↓
integration tests

Terraform：

config
 ↓
validate
 ↓
plan

Agent 评测应尽可能接近真实有效性。

9.7 Composite Rule

推荐：

success = (
    schema_ok
    and required_state_ok
    and forbidden_state_ok
    and policy_violation_count == 0
)

而不是：

score = mean([schema, state, policy])

9.8 本章实验

为同一个输出同时写：

1. Exact Match；
2. JSON Schema；
3. Semantic Checker；

观察它们分别能发现哪些错误。

9.9 验收问题

• 为什么 JSON Schema PASS 不代表 Task Success？
• AST 比字符串比较强在哪里？
• 哪些条件应该做 Hard Gate？

本章依据

1. Establishing Best Practices for Building Rigorous Agentic Benchmarks — Zhu et al., 2025
2. Evaluating Large Language Models Trained on Code — Chen et al., 2021