Eval Beyond Benchmark

公开 Benchmark 的三宗罪：污染、饱和、Construct Gap

背景与原理

三个机制让公开分数和生产可靠性脱钩：

• 污染（Contamination）：MMLU、HumanEval 这种存在多年的公开集，几乎必然以某种形式进过新模型的预训练 / 后训练语料。更隐蔽的是 SWE-bench——对 Verified 子集的分析发现，约三分之一的 issue 把修复方案直接写在了 issue 描述或评论里，模型「抄」而不是「解」，分数因此虚高。
• 饱和（Saturation）：顶部模型挤在 88%–92% 这种天花板区间，benchmark 失去区分度——分数差落进噪声，你无法据此判断 A 比 B 在你的场景更好。
• Construct Gap：benchmark 测的是 target 的代理，不是 target 本身。HumanEval 测「补全一个独立函数」，你的活是「在 50 万行 repo 里跨文件改一个 bug」。研究发现，把 SWE-bench 的长 GitHub issue 换成真实用户那种简短模糊的提问，同一模型相对成功率掉 20–40%。

底层是 Goodhart 定律：一个指标一旦成为优化目标，就不再是好指标。整个行业在朝公开 benchmark 过拟合，分数涨而真实能力的相关性逐年衰减。

实战示例

把「能不能信这个 benchmark」做成一张 30 秒诊断表，贴在选型文档里：

# 看到一个亮眼分数，先问这 4 个问题
1. 这个集合公开多久了？     > 1 年 → 大概率污染，分数打折
2. 顶部模型分数差多少？     < 3pp → 落进噪声，别据此选型
3. 任务形态像我的吗？       单函数/选择题 ≠ 多轮 agent / 长 repo
4. 评分 oracle 严吗？       弱测试集会放过「看起来对」的错答

# 任何一条不过关 → 这个分数不能用来做生产决策

从生产 Trace 反向造 Eval Set

背景与原理

Hamel Husain 在《Your AI Product Needs Evals》里反复说的一件事：失败的 AI 产品几乎都败在没有评估体系，而能用的评估体系起点小得惊人——几十条真实样例 + 一个 scorer 就能跑。关键不是「多」，是分布匹配：你的 eval 输入要长得像生产输入，否则分数再高也是自欺。

方法叫 error analysis / open coding：抽一批真实 trace，逐条人工读输出、给失败贴标签（不是先定 rubric，是先看数据再归纳 failure mode）。EvalGen 论文（Shankar et al. 2024）把这种现象命名为 criteria drift——你需要标准来打分，但恰恰是打分的过程帮你定义标准。所以 eval 不是写一次的静态文档，是和数据共同演化的。

实战示例

# 从生产日志反向造 eval set 的最小 pipeline
import json, random

# 1) 分层采样：别只抽成功的，按 failure 信号过采样
traces = load_prod_traces("2026-05")
hard = [t for t in traces if t.thumbs_down or t.retried or t.fallback]
sample = random.sample(traces, 60) + random.sample(hard, 40)  # 故意偏向难例

# 2) open coding：人工读 + 贴 failure 标签（先看数据，后定 rubric）
#    例：wrong_tool / hallucinated_field / ignored_constraint / too_verbose

# 3) 冻结成带 ground-truth 的 eval 集，存进版本库
for t in sample:
    eval_set.append({"input": t.input, "context": t.context,
                     "expected": human_label(t),     # 你标的，不是模型标的
                     "slice": t.category})           # ← §3 切片要用
json.dump(eval_set, open("evals/v1.json", "w"))

注意第 1 步的过采样难例：生产里 95% 是简单请求，若按自然分布抽，eval 会被简单样例稀释，掩盖关键失败。eval 集要刻意偏向你最怕出错的地方。

Slice-Based Eval：聚合分数会骗你

背景与原理

这是真实场景 eval 里最反直觉、也最值钱的一条。一个「90% 通过」的 agent，可能在「退款类请求」上是 95%、在「改地址类请求」上只有 45%——而改地址恰好是你最高频或最高风险的场景。聚合分数把这种分布内的灾难平均没了。

解法是 slice-based evaluation：按有业务意义的维度切片，分别报告每个切片的分数，盯住最差的那个而不是平均的那个。切片维度通常来自 §2 open coding 出的 failure mode，或者业务类别、输入长度、语言、用户分群。这也是对抗 Goodhart 的天然手段——你优化聚合分时很容易牺牲一个小切片去换大盘，分切片就让这种交易无所遁形。

实战示例

from collections import defaultdict

def sliced_report(eval_set, run_agent, scorer):
    buckets = defaultdict(lambda: [0, 0])   # slice -> [pass, total]
    for ex in eval_set:
        ok = scorer(run_agent(ex), ex["expected"])
        b = buckets[ex["slice"]]
        b[0] += int(ok); b[1] += 1
    # 关键：按分数升序打印，最差的切片顶在最上面
    rows = sorted(((s, p/n, n) for s,(p,n) in buckets.items()),
                  key=lambda r: r[1])
    for s, acc, n in rows:
        flag = "  ⚠️ 门槛线下" if acc < 0.8 else ""
        print(f"{s:<22} {acc:5.0%}  (n={n}){flag}")

# 输出示例：聚合 90%，但最差切片才 45% —— 这才是该修的地方
# change_address        45%  (n=20)  ⚠️ 门槛线下
# multi_intent          63%  (n=15)  ⚠️ 门槛线下
# refund                95%  (n=30)
# ── aggregate ──       90%

上线门槛应该挂在最差切片上（「每个切片 ≥ 80% 才放行」），而不是聚合均值。一个被聚合掩盖的 45% 切片，往往就是上线后用户投诉的源头。

Agentic Eval：评估轨迹而非答案

背景与原理

传统 benchmark 一问一答测一次；真实 agent 是多轮、调工具、和（可能误导的）用户来回交互的轨迹。两个范式转移：

• 从 outcome 到 trajectory：只看最终答案对不对，会放过「答案蒙对了但工具调用顺序全错」的脆弱轨迹。要评估中间步骤——调了哪些工具、有没有违反 policy、有没有多余动作。
• 从 pass@1 到 pass^k（一致性）：τ-bench（Yao et al. 2024）提出 pass^k——同一任务连续跑 k 次全部成功的概率。论文里 SOTA 函数调用 agent 单任务成功率已不到 50%，而 retail 域 pass^8 跌破 25%。这个落差就是「demo 能跑」和「生产可靠」之间的鸿沟。它的评分方式也很硬核：不看对话措辞，比对最终数据库状态和标注目标状态是否一致。

对个人 / 小团队，照搬 τ-bench 的两个思想就够：用 state-based 评分（验证副作用，不验证措辞）+ pass^k 一致性（同任务多跑几次看稳不稳）。

实战示例

def pass_hat_k(task, run_agent, check_final_state, k=8):
    # pass^k：连续 k 次「全部」成功才算稳；任一次失败即 False
    return all(check_final_state(run_agent(task)) for _ in range(k))

def check_final_state(result):
    # state-based：只验证副作用，不在乎它话怎么说
    return (db.get("order#123").address == "new addr"
            and not charged_extra_fee())     # 还要验证「没干坏事」

# 轨迹合规检查：流程对不对，不止结果对不对
def check_trajectory(trace):
    if "refund" in trace.tools_called and not trace.asked_confirmation:
        return "VIOLATION: 退款前没走确认"    # policy 违规
    return "ok"

对 agent，「跑一次成功」毫无意义——pass^8 才是上线信号。一个 pass@1=80% 但 pass^8=30% 的 agent，意味着平均每三个用户就有两个会在某一轮撞上失败。