你们的AI通过率，可能只是评分器在点头

Sergii Makarevych 写过一篇给工程师、产品经理和 CEO 看的 evals 清单。它把 AI 产品评估里最容易被跳过的一步放在最前面：先证明你的评分器值得信。

Eval 说白了是一条可重复的测试：给系统一批输入，拿输出和标准答案比，最后得到一个带误差范围的数字。原文用一家自行车店的客服助手做例子：80 张工单，20 张拿来调提示词和评分器，60 张只用来报告。triage 分错类、回复缺事实、编造政策、退款 agent 把数据库改错，分别算不同的分。

这四步听着普通，坑在细节。输入要像真实流量，包含愤怒客户、含糊问题、多问题工单。每条输入旁边要写清楚正确长什么样：分类标签、必须引用哪一节手册、必须说出哪两三个事实。原文的判断很硬：带标准答案的输入是整个流程里最贵的资产，框架和仪表盘都排在后面。

先读输出，再写评分器。原文团队在 60 条测试回复里数出：34 条通过，15 条缺必需事实，12 条无依据声明，8 条检索错章节，5 条没回答问题。这个失败清单就是后面所有评分器的规格。第一周该干的事很土：读一百到两百条输出，逐条写失败笔记，再归组计数。跳过这一步，团队很容易为不存在的失败写评分器，得到一个让人安心的数字。

代码评分器便宜、快、稳定，适合有确定答案的检查：分类标签、字数、禁用承诺、必需事实是否出现。它的盲区也清楚。原文里只有 11.7% 的回复通过所有代码规则，可代码规则没抓到编造声明。一个客服回复编出“最多 15 个工作日的总额度”，格式、引用、必需事实都过了，模型裁判才发现问题。规则看形式，看不到意义。

模型裁判能读语义，但它自己也会错。原文用手工标注的 60 条回复校准裁判：原始一致率 60%，看起来还行；Cohen's kappa 只有 0.15。一个对所有回复都说 pass 的裁判也能拿到 57% 的原始一致率，因为大部分回复本来就通过。更麻烦的是裁判的已知偏好：偏袒第一个出现的答案、偏袒长答案、偏袒自家模型风格，还容易把聊得舒服当成任务完成。缓解办法不复杂：二选一时交换顺序，用二值问题加证据，换不同模型家族的裁判，把工具调用和最终状态一起给它看。先拿几十条人工标注测裁判，报告 kappa 或坏答案抓取率，再让它参与发布决策。

数字要带误差条。原文的 triage 准确率是 0.700，95% 置信区间 [0.583, 0.817]。两个版本的回复通过率都是 0.700，差值 +0.000，区间 [-0.117, +0.117]，结论是没有可测差异。60 条测试集的检测下限约 12 个百分点，5 个点的回退在这个样本量下看不见。还有一个常被忽略的账：总体通过率没变，不代表没有客户变差。原文 v2 在 14% 的 case 上回退，同时在其他 case 上变好。发布前该问的是哪些 case 变差了，不能只看总分。

Agent 要分开评。最终数据库状态对不对，路径允不允许，任务跑三次是不是三次都成。原文用 pass^k 衡量可靠性，pass@k 衡量能力。客服场景里 pass^3 比曾经成功一次更接近用户体感。成本也要算，agentic 任务 token 消耗可能是聊天回合的千倍，同一任务同一模型不同运行能差 30 倍。按每次正确结果的花费排模型，比只看准确率更接近生意。

公开 benchmark 用来筛引擎，不负责证明你的产品能上线。同一个模型换 prompt 格式，GSM8K 能从 0.686 变到 0.746；benchmark 会污染、会饱和，榜单前几名常在噪声里。原文的建议是拿五个 benchmark 缩小候选，再用自己的 eval 决定。

落地节奏可以很朴素：每次提交跑代码检查和格式检查；每次改提示词、模型、检索，跑测试集上的模型裁判和抽样人工复核；上线后采样真实流量，便宜评分器跑全量，贵评分器跑切片。CI 门槛写明检测下限，别把 3 个点的门槛说成能抓 5 个点的回退。

评论区有几条补充比原文还刺耳。有网友说，一个能读的通过率不等于发布门槛，要写清楚哪套集、多少分、评分器放行坏答案时谁叫停。有网友提醒，先拿已知答案测裁判，裁判连简单题都打不稳，后面全是噪声。还有网友补了一条工程细节：裁判调用失败时，很多框架直接把这条从平均值里丢掉，数字照样好看。原文作者 Sergii Makarevych 的清单已经够长，这几条正好补上组织里的责任缺口。

来源：Sergii Makarevych 原文。图中清单也来自同一篇文章。