AI 产品上线前，先测评测器自己

astaxie 推荐了 Sergii Makarevych 的一篇长文，主题是开发 Agent 如何做好评测。文章不轻，写给工程师、产品经理和 CEO，但它先给了一个很朴素的场景：一个卖自行车和露营装备的网店，有个客服助手，拿 80 张客服工单跑评测，其中 20 张调参，60 张只用于报告。60 张测试回复里，34 张通过。这个数字比演示视频有用。

有网友在转发下说，最该被这篇文章教育的是批准采购的人。他们看 demo 只问能不能做，不问错了谁兜。另一个回复更具体：通过率不是发布门禁，要写清楚哪套数据、什么分数、谁能在评审器放行坏答案时叫停。这个提醒很实在。LLM 产品的成本大头常在人工复核和返工，token 只占一部分。

评测要让尺子可信

eval 是可重复的测试，用可信任的数字告诉系统是否做了想要的事，改动变好还是变坏。语言模型失败方式不同。普通软件要么工作要么崩溃，语言模型会给出流畅、自信、格式正确但可能错误的答案。读一个答案说明不了下 100 个。评测把 demo 里看着行，换成 60 个关心 case 通过 70%，误差 12 点，新版本没有可测提升。

一个 eval 四步：收集输入和标准答案；跑系统留输出；用 grader 打分，grader 可以是代码规则、模型评审、人；把分数变成一个带误差条的数字，和上一版比。grader 本身也是系统的一部分，必须测。一个和人类只有 60% 一致的评审模型，会告诉你产品没问题，实际有问题。

一张工单里，代码规则和模型评审看到的不同

Level 0 例子是一张退款工单。triage 正确判成 returns，回复引用退货章节，提到 5 个工作日和 15% restocking fee。两个代码规则都过：引用章节、包含必需要点。模型评审问有没有手册没说的内容，判失败，因为编了最多 15 个工作日的总宽限。两张便宜检查说没问题，评审抓到一个会发给客户的编造数字。规则看形式，评审看语义，不能互相替代。

先读一百条输出，再写 grader

在写自动 grader 前读输出。60 条测试回复的失败分类：通过 34，missing_required_fact 15，unsupported_claim 12，wrong_section_retrieved 8，did_not_answer 5，wrong_value 2，over_promise 1。刚过一半。最大问题在缺事实和编造，不在格式。这个列表就是 grader 的规格，按频率建。跳过读输出，团队会给不发生的失败建 grader，数字好看，漏掉真问题。

代码 grader 便宜、确定，也瞎

代码规则适合标签、格式、必需要点、禁用词。triage accuracy 0.700，macro F1 0.697，说明错误分散。回复里 max_words_150 只有 17% 通过，应用太啰嗦，不需要 judge 就能发现。必需要点检查能用零成本抓住最大失败类型。相似度能发现变化，不能判断对错，embedding similarity AUC 0.709。只有 11.7% 回复通过所有代码检查，但代码检查没抓到任何编造声明。规则看不到意义。

模型评审要像分类器一样验

LLM-as-judge 能读语义，也有语言模型失败模式。问法要具体：每个失败类型一个 yes or no 问题，要求引用证据，给它上下文。Cho 等 2026 的 Ask, Don't Judge 在摘要任务上发现，把评分拆成具体错误的是非题，比整体打 1 到 5 分更接近人类。一个塞了三处事实错误的摘要，整体评审给 5.0，问题式评审给 1.57。提示里堆更多指令，评审还会变差。

作者手标 60 条回复，再跑评审：参考通过 34，评审通过 42，36 条一致，60%，坏回复抓到 10/26，kappa 0.15。60% 听起来能接受，其实不行。全判通过也有 57% 一致，因为大多数回复通过。kappa 校正偶然一致。0.6 才适合让评审卡发布，0.8 才适合无人监督。这个评审宽松，漏掉一半多坏回复。补救办法是在 dev set 上加失败示例、缩窄问题、给 gold facts。missing fact 问题能修到可用，unsupported claim 没修好，交给专门检测器。

评审偏差已知：位置偏差，交换顺序会翻盘；长度偏差，长答案赢；自我偏好，同家族评审给自己风格高分；满意度不等于任务成功，只看聊天记录的评审分不清 agent 是否真把事办了；换评审模型会换赢家。缓解不贵：两个顺序都评，只有都赢才算赢；长度控制；用不同家族评审；给评审看工具调用和最终数据库状态；记录评审模型版本。

GAUGE 审计值得单独看。25 个 agent、约 3700 条 transcript，接近相等时把更差 agent 推上线 31%，只看聊天满意度 AUC 0.49，看工具调用、认证、任务解决 AUC 0.73。可靠性更多取决于给评审什么证据，评审模型强弱排在后面。

数字要带误差条，比较要配对

60 条工单 triage accuracy 0.700，95% CI [0.583,0.817]。诚实的说法应该写成：准确率大概在 58% 到 82%，最可能 70%。第二版 prompt 检索更多章节，评审通过率还是 0.700，差异 0，CI [-0.117,+0.117]，没真实差异，留 v1。配对比较区间更窄，因为同一张工单在两版下评分，难度抵消。McNemar 问每张工单：v2 在 v1 输的地方赢了吗，还是只是交换。这里交换了，v2 在 14% case 上退化。整体通过率一样，产品对有些客户更好，对有些更差。

60 条 case 能可靠检测的最小差异约 12 个百分点。5 点退化看不见。低于检测下限要加数据，别换更聪明测试。测 20 个 prompt 变体挑最好，会有一个靠运气好 10 点。要么校正多重比较，要么新 case 确认。

分阶段评，别把 RAG 和 agent 混成一锅

RAG 要先评检索再评写作。hit@2 0.93，recall@2 0.88。18 条失败回复里，1 条检索失败，17 条写作失败。一行数字能省一周工程。写作评忠实度、答案相关性、上下文精度。RAGAS 给出 context relevance 0.855，faithfulness 0.737，和手写 grader 讲同一个故事，交叉验证让数字可信。

Agent 要评最终状态和路径。数据库最后对不对，有没有重复退款，有没有越权操作。τ-bench 用模拟用户、策略规则和最终状态检查。AgentLens 说明只看结果会高估能力，因为 agent 可能靠运气或退化路径到达正确状态。每个任务跑多次，pass@k 看能力，pass^k 看可靠性。客服 agent 要 pass^k。示例 agent pass^3=0.75。τ²-bench 发现需要和活跃用户协调时 pass^1 掉约 20 点。可靠性要单独测：跨运行一致性、对扰动鲁棒、能否预知失败、危害有界。15 个前沿模型两年能力涨，可靠性只涨约六分之一。成本也要测：agentic 任务 token 比聊天多约一千倍，同一任务同模型成本可差 30 倍，模型自己预测成本相关性最多 0.39。按每次正确结果成本排序，别只看准确率。

公共 benchmark 是选引擎，不能替车上路

benchmark 是固定公共题集，MMLU、GSM8K、SWE-bench、τ-bench 等。它们用来短名单模型。GSM8K 同一开放权重模型换两种 prompt 格式，0.686 和 0.746。分数是模型、prompt、harness、版本的四元组，不能当成模型固有属性。污染真实且不均匀，GSM1k 重建题后有些模型家族掉 8 点。饱和很快，60 个常用 benchmark 约一半高度饱和，SWE-bench Verified 两年从约 40% 到 80% 以上。Zeng 和 Papailiopoulos 2026 的矩阵 84 模型 133 benchmark 近似秩二，两个因子解释 90% 以上变化，五个选好的 benchmark 能预测其余 128 个到约 4 点内。选引擎够用，发现具体失败模式还要自己的 eval。

落地：三道节奏，一个门禁，四个数字

Hamel Husain 的三层节奏：每次提交跑代码 grader、schema 检查、必需要点，免费；每次改 prompt、模型、检索，跑测试集上的模型评审和检测器，加人工抽样，几美分到几美元；上线后做真实流量 A/B。教程的 CI 门禁在通过率比基线 0.70 掉超过 3 点时失败。它只是大退化的绊线，不能当保证，因为 60 条 case 的检测下限约 12 点，5 点退化能走过去。门禁要写明检测下限。

上线后抽样真实流量，便宜 grader 跑全量，贵 grader 跑一片，画趋势。GAUGE 的校准再信任适合贵门禁：先用可验证 ground truth 做一次全审计，知道便宜评审门禁在哪个区域和现实一致，只在那个区域用，模型、评审、模拟器或领域一变就重审。

成本不是借口。完整 60 张工单 A/B 是 121 次评审调用，约四美分。所有模型调用按 prompt、数据版本、recipe 缓存，重跑变文件读取，教程从缓存重跑零调用。

负责人要的一页四个数字：产品通过率及区间，评审与人工标签一致率，检测下限，上次改动中变差的 case 比例。缺一个，另外三个都不够有意义。

工具观察

文章最后列了工具和 approach，强调是观察不是推荐。Inspect AI 适合一条完整流水线，lm-evaluation-harness 适合可复现跑公共 benchmark，promptfoo 适合 YAML 测试和 CI，DeepEval 适合 pytest 风格单测，RAGAS 适合 RAG 三件套，Langfuse、Phoenix、LangSmith、Braintrust 各有取舍。回复里有人直接说 Braintrust sucks for evals。工具热度不等于适配，先看它解决哪个评测环节，再看数字是否可交叉验证。

原文链接在这里：Evals: how to know whether an AI system actually works。如果只记一句：演示里看着行，和 60 张真实工单过 34 张，是两件事。AI 产品上线前，先测评测器自己。