10 个关键问题Q&A
-
Q：什么是 Evals？ A：Evals 是大模型评测，用来验证模型能力变化，区分真实效果差异和随机波动。 -
Q：代码规则评测有什么优缺点？ A：结果稳定、速度快；只适合格式固定、可规则校验的输出场景。 -
Q：模型裁判评测的风险是什么？ A：落地成本低、适用范围广，但自带偏好，打分容易出现系统性偏差。 -
Q：人工标注评测适合什么时候用？ A：高风险场景终审、校准模型裁判，缺点是成本高、效率低，不易大批量跑。 -
Q：评测为什么不能只看平均分？ A：分数存在随机误差，脱离误差区间的单点分数很容易造成误判。 -
Q：什么是配对对照测试？ A：控制变量，新旧模型在同一批测试用例上对比，减少样本干扰。 -
Q：评测的标准流程是什么？ A：明确评测目标→设计测试用例→执行评测→结果校验与复盘。 -
Q：评测和基准测试是一回事吗？ A：不是，基准偏向固定榜单横向对比，Evals 更多用于版本迭代纵向验证。 -
Q：什么时候需要启动 Evals？ A：模型版本改动前、产品上线前、线上持续效果监控阶段。 -
Q：管理者看评测报告重点看哪几项？ A：稳定性、风险坏案例、新增能力收益、推理与标注成本变化。
本文写给所有交付、采购、审批大语言模型（LLM）软件的人：工程师、产品经理、CEO。全文通俗直白，从宏观思路讲到落地细节。文中所有数据都标注了来源：要么来自我们针对一个小型客服助手编写的可运行教程，要么来自已发表论文。
快速导读（没时间看全文就看这部分）
Eval是 evaluation（评测）的简称，指一套可重复执行的测试。它能给出可信数值，告诉你 AI 系统是否达成预期目标，以及一次版本改动到底让它变好了还是变差了。
评测存在的意义：大模型的故障方式和传统软件不一样。传统软件要么正常运行，要么直接崩溃；而大模型输出的回答流畅、自信、格式工整，但内容可能是错的。单看一条回答没问题，完全无法预判后续上百条回答的质量。评测，就是把 “演示看起来还行”，替换成 “在我们关心的场景里通过率 70%，误差 ±12 个百分点；新版本没有测出明显提升”。
评测分为四步：
-
收集有业务价值的输入，并且为每一条输入标注标准答案。本文持续使用的例子：自行车商店 80 条客服工单，每条工单都标注正确分类，以及合格回复必须包含的关键事实。 -
让 AI 系统跑全部输入，留存输出结果。 -
使用打分器（grader）给每一条输出打分。打分器可以是代码规则、充当裁判的另一个模型，或是人工标注。 -
把打分结果整合为一个带误差棒的指标，和上一个版本做对比。
评测的使用时机：上线前（系统到底能不能用）、每次改动前（有没有引入劣化）、上线后（真实流量下性能是否稳定）。
重点：打分器本身，也是需要被验证的系统组件。一个和人工标注一致性只有 60% 的裁判模型，会给你 “产品没问题” 的虚假结论。
这意味着：每一次评测，你要同时看两个指标 ——产品本身的表现，以及打分器本身的靠谱程度，两个数值都要看。
这也是很多 AI 团队自我欺骗最常见的根源：直接采信一个未经校验的打分器给出的漂亮分数。
下文逐层展开，每一层回答上一层衍生出来的问题：
-
第 0 层・完整流程：单条工单跑一遍评测 -
第 1 层・我们到底在测什么？（输入、标准答案、指标） -
第 2 层・问题一般出在哪？（先看数据） -
第 3 层・代码打分器（低成本、精准，但无法理解语义） -
第 4 层・用模型当裁判（灵活，但存在偏见，必须校验） -
第 5 层・可信指标（误差棒、A/B 测试、样本量） -
第 6 层・多组件系统评测（检索、智能体、成本、稳定性） -
第 7 层・公开基准测试集（排行榜能说明什么、不能说明什么） -
第 8 层・把评测固化成流程（上线门禁、监控、定期复测）
之后是工具与方案汇总、决策指南、参考文献。
第 0 层：完整流程，单条工单跑一遍评测
聚焦：整个评测链路。问题：一次评测跑起来是什么样子？
本文全程的示例是一个虚构线上自行车与露营用品店的小型客服助手，它包含三个模块，后续我们会用不同方式分别打分：
-
工单分类（triage）：读取工单，分到 12 个分类之一（退货、物流、保修等），同时标注优先级。 -
生成回复（answer）：检索店铺政策手册相关页面，撰写引用政策的回复。 -
智能体（agent）：查询订单、发起退款、升级工单，在模拟数据库中按照规则调用工具。
我们看一条工单走完完整评测链路：
用户输入：“我上班快迟到了，急需处理这件事。上周我退回了自行车，但退款还没到账。你们政策写明退款会在 5 个工作日内处理……”
系统【工单分类】输出：退货。标准答案：退货。得分：1 分（满分 1）。
系统【回复模块】输出：一段礼貌的四段式回复，引用退货章节，同时提到两个必填事实：退款需要 5 个工作日、二手商品会收取 15% 的重新上架费。
接下来三个打分器检查这条回复：
-
代码规则：回复是否引用手册章节？结论：是。 -
代码规则：两个必填事实是否都提到？结论：全部覆盖，没有遗漏。 -
模型裁判：回复有没有说出手册里不存在的内容？结论：不通过，它编造了 “最长 15 个工作日处理额度” 这个说法。
这就是评测的核心逻辑：两个低成本代码检查都判定回复合格，但模型裁判抓到了一段会发给客户的虚构内容。后面所有层级，都是为了让这套流程规模化之后依然可信。
✅ 第 0 层小结：评测 = 输入 + 待评测系统 + 打分器 + 指标，仅此而已。
不同打分器负责不同检查项：“有没有引用文档” 和 “有没有编造内容” 是两类完全不同的校验。流畅的回复，有可能通过所有表面校验，但本质是错的。
第 1 层：我们到底在测什么？
聚焦：评测流程的第 1、4 步。问题：输入和标准答案从哪里来？指标又该怎么定义？
输入：测试用例要贴近真实流量，包含棘手场景。我们这 80 条工单，是按照【用户画像 × 话题 × 场景】矩阵生成，覆盖愤怒用户、模糊提问、一条工单包含多个问题等情况。Anthropic 关于智能体评测的指南建议：优先从真实故障里抽取 20–50 条任务，而不是只写理想的正向案例（Grace 等人，2026）。
标准答案（gold answers）：对每一条输入，明确定义 “正确” 是什么：正确分类、回复必须引用的手册章节、2–3 条必须写明的核心事实。我们示例工单是基于手册生成的，所以标准答案天然准确；真实业务里，标准答案由领域专家编写。
数据集划分：分成两部分：开发集（20 条工单），用来调提示词、调打分器；测试集（60 条工单），只用来出最终报告。如果你拿用来调参的数据集报结果，指标会虚高美化表现。
指标定义：
-
工单分类：准确率（正确分类工单占比） -
回复生成：通过率（无错误的回复占比） -
智能体：最终数据库状态正确的任务占比
每一组实验只报测试集上的结果，并且必须附带误差棒（第 5 层会讲）。
四个容易混淆的概念：
-
Eval（业务评测）：在你的私有数据上，测你的系统。例：我们这个客服助手在 60 条工单上的表现。 -
Benchmark（公开基准）：在公开任务上，测基础大模型。例：GSM8K 数学题、SWE-bench 代码测试。 -
软件测试（Test）：验证函数返回预期结果。例：JSON 正常解析、程序不崩溃。 -
线上监控（Monitoring）：上线之后，针对真实流量持续观测。例：每天抽样真实工单打分。
一个在公开基准上分数很高的模型，依然可能给你的客户输出错误答案。基准测的是发动机，业务评测测的是这辆车在你的路面上跑起来怎么样（Husain & Shankar，2025）。
✅ 第 1 层小结：带标准答案的测试用例，是评测体系里最宝贵的资产，成本很高，也是一切的基础。一定要分开开发集（调参）和测试集（报结果）。基准测试用来选模型底座；业务评测，用来验证你的产品。
第 2 层：问题一般出在哪？先看数据
聚焦：打分环节。问题：打分器到底应该检查哪些问题？
在写任何自动打分器之前，先人工读模型输出。几乎所有资深从业者都持相同观点（Husain，2024；Husain，2025；Shankar 等人，2024）。逐条阅读一两百条输出，给每一条故障写简短备注，再把备注归类，统计各类故障数量。这个过程叫错误分析，分为两步：开放编码（自由记录问题）、轴向编码（归类汇总）。
我们 60 条测试回复的统计结果：
-
合格回复：34/60 -
missing_required_fact（缺失必填事实）：15 -
unsupported_claim（无依据的编造内容）：12 -
wrong_section_retrieved（检索到错误章节）：8 -
did_not_answer（没有回答用户问题）：5 -
wrong_value（数值错误）：2 -
over_promise（过度承诺）：1
通过率勉强过半。两大最突出问题：缺失事实、编造内容。只看演示，你根本猜不到这个分布。这份故障清单，就是后续所有打分器的开发依据：按故障发生频率，优先开发高频故障的打分器。
重点：故障清单来自人工阅读输出，而不是凭空想象。落地建议：评测工作第一周，核心工作是人工在专用查看器里读对话记录，而不是工程师忙着搭建框架。很多团队的评测工作卡住，几乎都是跳过了这一步（Husain，2025）。
一个相关现象：打分标准会随着标注过程变化。Shankar 等人（2024）称之为标准漂移。标注样例会让评分细则变得更清晰，细则一变，之前的打分结果也会跟着变。一般要迭代 2–3 轮，这不是流程失败，是正常现象。
✅ 第 2 层小结：故障分类清单就是评测方案。优先针对高频故障开发打分器。人工读输出是性价比最高的动作，也是最容易被跳过的一步。做好心理预期：标注过程中，评分标准会持续迭代。
第 3 层：代码打分器
聚焦：一类打分器。问题：普通代码规则能测什么、测不了什么？
代码打分器，就是普通代码写死的规则。免费、瞬时出结果、每次打分完全一致。只要能用代码规则测的，优先用代码打分器。
精确答案场景：工单分类只有唯一正确标签，直接统计匹配数量。准确率：0.700，宏 F1：0.69710 条工单里 7 条分类正确。宏 F1 对 12 个分类平等加权，稀有分类和常见分类权重一样。两个数值接近，说明错误均匀分散，不是集中在某一类工单上。
自由文本的规则校验：回复没有唯一标准答案，但有硬性规则：
-
非空：100% 通过 -
字数≤150：17% 通过 -
禁止违规承诺：92% 通过
只有 17% 的回复控制在 150 词以内。说明这个助手输出太啰嗦，这件事不需要任何模型裁判就能发现。IFEval（Zhou 等人，2023）这类公开基准，完全基于这类可核验规则（例如 “回答必须恰好是三条项目符号”）。
必填事实校验：检查标准答案里的每一条事实，是否出现在回复里。可以零成本抓到排名第一的故障：事实缺失。
相似度指标：ROUGE、BLEU 这类文本重叠指标，以及 Embedding 相似度，用来对比回复和参考文本。在我们案例里，Embedding 相似度区分好坏回复的 AUC=0.709（0.5 等于随机猜，1.0 是完美区分）。它适合用来发现版本之间输出发生变化，但不能用来判定回答是否正确。
重点：相似度只能感知变化，不能评判质量。风险：一段错误回复，只要用词和标准答案接近，相似度分数就会很高。Eugene Yan（2024）以及 ROUGE、BLEU 原始论文都充分说明了这个局限。
代码打分器的上限，用一个数字说明：我们的回复里，只有 11.7% 能通过全部代码规则；同时，代码规则完全抓不到编造内容。第 0 层那条示例回复，满足全部代码规则，但编造了 15 天的时限。规则只能看形式，看不懂语义。
✅ 第 3 层小结：有确定答案的场景（标签、格式、必填事实、禁用话术），优先代码打分器。相似度指标用来监控漂移，不能作为核心质量指标。规则无法识别编造内容，这类问题需要人工或者模型裁判。
第 4 层：模型裁判，以及如何校验裁判本身
聚焦：另一类打分器。问题：打分器本身是大模型时，我们怎么确认它打分是对的？
模型裁判（常叫 LLM-as-judge）：用第二个大模型读取输出、给出评分。它能理解语义，可以抓到例子里编造 15 天时限这类问题。但它本身也是大模型，所有大模型的缺陷它全都有。这一章篇幅最长，因为绝大多数评测体系都栽在这里。
4.1 怎么给裁判设计提问方式
行业共识和学术文献都推荐这套范式：一条故障对应一个是 / 否二元问题。问：“回复是否包含手册摘录不支持的说法？” 而不是 “1–5 分给质量打分”。二元问题人工标注更快、结果更稳定、更容易校验（Husain & Shankar，2025）。只有所有问题都返回 “否”，这条回复才算通过。要求裁判给出证据：引用出错的原句。这样人类几秒就能复核裁判结论。给裁判完整上下文：看不到手册原文的裁判，根本无法判断内容是否无依据。
Cho 等人（2026）专门在摘要任务上验证了这套思路，论文标题《Ask, Don't Judge》。把评分拆成针对具体错误的二元判断题，在所有数据集上都优于流行的 G-Eval 整体打分方案（SummEval 数据集上和人类的斯皮尔曼相关系数 0.563 vs 0.514）。最有说服力的例子：一段故意埋了三处事实错误的摘要，整体打分拿到满分 5.0；而拆分式提问打分只有 1.57。他们还发现：提示词塞过多指令，反而会让裁判效果变差。
4.2 校验裁判：我们的实测数据
我们人工标注全部 60 条测试回复作为 “真值”，再跑模型裁判：
-
人工标注合格：34 条；裁判判定合格：42 条 -
60 条里面，裁判和人工一致的只有 36 条（60% 一致率） -
裁判抓到的坏回复：26 条不合格回复里，只抓到 10 条 -
Cohen’s Kappa（科恩卡帕系数）：0.15
60% 的一致率听起来尚可，实际上完全不行。因为大部分回复本身是合格的：裁判无脑全部判 “通过”，都能拿到 57% 的一致率。Cohen’s Kappa 用来扣除随机巧合带来的一致：0 等于随机，1 等于完美一致；一般上线门禁裁判的合格门槛是 0.6，无监督自动运行的裁判门槛是 0.8。我们这个裁判只有 0.15，打分偏宽松，很多不合格回复被放过，不合格回复的检出率不足一半。
重点：当大部分样本本身是合格的，原始一致率极具迷惑性。要同时上报 Kappa，或者单独上报：坏样本检出率、合格样本误判为不合格的比例。落地建议：模型裁判本质就是一个分类器。在信任它之前，必须用几十条人工标注样本校验，并且每次上报产品指标，同时附上裁判本身的校验结果。风险：用这个裁判，哪怕新版本编造内容翻倍，整体通过率指标可能看不出变化。
优化方法：在开发集上迭代优化：给裁判 prompt 加入故障样例、收窄问题定义、提供标准答案作为参考。我们教程里 “缺失事实” 这一项的裁判迭代后达到可用水平；而 “无依据编造” 这一项始终不理想，最后交给专用检测器处理（4.5）。
4.3 裁判已知的偏见、论文证据和低成本规避方案
裁判的偏差是可预测的，每一类都有公开实验，也有低成本缓解手段：
-
顺序偏好：成对对比时，裁判偏向先看到的回答。调换顺序，大量对比结果直接反转（Wang 等人，2024）；2025 年 RAG 对比 GraphRAG 实验里，GraphRAG 前期 “胜率高”，调换展示顺序后优势直接消失（Han 等人，2025）。缓解：正反顺序各测一次，只有两次结论一致才算有效。 -
长度偏好：更长的回答更容易赢，和内容好坏无关。校正长度后，和人类排序的一致性从 0.94 提升到 0.98（Dubois 等人，2024）。缓解：长度归一化打分，或者用不奖励长文本的二元判断题。 -
自偏好：裁判偏爱和自己同系列模型风格的回答。裁判认出同家族输出时，打分偏高（Panickssery 等人，2024）；GAUGE 审计里，同系列裁判在 7 分制下，给自家智能体平均虚高 0.75 分。缓解：评测系统和裁判模型，选用不同厂商 / 不同系列。 -
满意度≠任务成功：裁判评判对话感受，而不是任务有没有做完。参考 GAUGE 审计。缓解：给裁判工具调用记录、最终状态，而不只是聊天文本。 -
裁判模型本身影响结果：换一个裁判模型，版本胜负关系直接反转（2026 多篇 arXiv 审计：2607.08535；2606.19544）。缓解：每一份结果，都记录裁判模型和版本。
单独说 GAUGE 审计（Bodhwani 等人，2026）：它复现了绝大多数公司用来做上线决策的流程：模拟用户和智能体对话，裁判模型打分，分数高的版本上线。测试 25 个智能体、约 3700 条对话：当两个版本差距巨大时，这个方法和真值相关性 0.94；但到真实上线要二选一、差距很小的版本里，它有 31% 概率把更差的版本放行。只看聊天、只评估满意度的裁判，区分有效 / 无效智能体的能力和抛硬币差不多（AUC=0.49）；如果给裁判工具调用记录、鉴权信息、任务最终结果，出错概率减半（AUC=0.73）。结论：裁判好不好，取决于给它看什么证据，而不是裁判本身有多强。
重点：用户满意度和任务成功是两回事。只看对话的裁判，测的是前者。落地建议：给裁判完整证据（工具调用、数据库状态、检索文档）；两个版本分数接近时，绝对不能仅凭裁判分数决定上线。风险：一个很会聊天、但任务总失败的智能体，会持续被判定为更优版本。
4.4 裁判陪审团，以及怎么合并多个裁判结果
单个裁判是单点故障。Verga 等人（2024）证明：多个小型低成本裁判组成陪审团，和人类一致性优于单个大裁判，成本低很多。但直接取平均分有大坑：Acharya 等人（2026）证明，只要有一个裁判失效（解析报错全给 0 分、讨好型裁判全部打满分），无论加多少正常裁判，平均分都会被带偏。实测里，他们用几何中位数替代平均值，对异常值免疫；最坏场景下准确率提升 540 倍；干净数据上仅损失约 1% 准确率。同时他们发现，3 个裁判就基本拿到陪审团方案的大部分收益 —— 裁判之间的错误本身是相关的。
另一个发现：Parikh（2026）发现，要求模型输出 JSON 格式（绝大多数裁判流水线在用），会让打分结果比自由聊天时更趋同。主流答案占比从 41% 升到 64%。对于唯一正确答案的判断，问题不大；但开放式打分场景里，裁判区分能力会变弱。
4.5 比通用裁判更便宜、更可靠：专用检测器、类型化裁判
对于高频故障，通用大模型裁判往往不是最优选择。幻觉检测器：小模型（参数量 1 亿–5 亿）只解决一个问题：这句话是否被上下文支持。Vectara HHEM、LettuceDetect（Kovács & Recski，2025）、MiniCheck（Tang 等人，2024）、NLI 交叉编码器，笔记本 CPU 就能跑，单次调用成本极低，在 RAGTruth 基准上效果接近大裁判。SelfCheckGPT（Manakul 等人，2023）甚至不需要检测器：多次采样同一个系统，标记前后说法不一致的内容。Fiddler 2026 行业报告提出 “评测信任税”：很多团队用大裁判全量扫描生产日志，只能抽样 10% 流量；而小型检测器可以覆盖全部流量，成本最高降低 98%。这个是厂商观点，没有附带对照实验，但这个取舍逻辑是成立的。
类型化裁判（Typed judges）：TypeSafe 的 Jev 是另一种架构：它不生成文本。你传入输出和一个强类型问题（“该说法是否被摘录支持？”，答案 yes/no；或者从标签列表选一项），返回校准后的概率。因为不做生成，速度极快，成本大约是生成式裁判的百分之一；低置信的样本可以自动流转给人工复核。它不能解释结论，也不能自己新增标签，标签集由你预先定义。2026 盲测人工复核实验：在 RewardBench 成对任务上，它准确率 92.2%，前沿生成式裁判 93.5%，成本只有后者的 0.3%；但复杂推导校验差距明显（78.6% vs 93.1%）。置信度级联方案：高置信直接采信，低置信转给人工，最终 92.5% 准确率，成本减半（arXiv 2609.26550）。我们内部红队测试发现：它不是万能事实校验器；输入里伪造日志可以诱导它出错，但这类攻击一定会压低置信度，所以置信门限是有效的防御手段。
裁判本身也需要基准测试。JudgeBench（Tan 等人，2025）把客观可核验难题做成裁判测试集，发现前沿裁判在真正的难题上，表现接近随机。可靠性必须按任务、评分细则、裁判模型单独测。厂商宣传的 “85% 和人类一致”，大多只在单一数据集有效，很难迁移到你的业务。
✅ 第 4 层小结：给裁判拆成针对具体错误的是 / 否问题，附带证据、完整上下文。裁判必须用人工标注校验，上报 Kappa 或者检出率，迭代达标后再用。记住裁判五大偏见，用低成本手段规避。判断 “内容是否被文档支持”，优先小检测器或者类型化裁判，而不是通用生成裁判。3 个裁判 + 稳健合并方案优于单裁判；平均分很容易被异常裁判污染。
第 5 层：可信指标
聚焦：评测流程第 4 步。问题：我们对指标到底有多大把握？两个版本怎么对比？
前面所有指标，都藏着一个疑问：换另外 60 条工单，结果会不会大变？下面三个工具解决这个问题：
误差棒（置信区间）：对 60 条结果做 bootstrap 重采样上万次，看分布：工单分类准确率：0.700，95% 置信区间 [0.583, 0.817]严谨表述不是 “准确率 70%”，而是：大概率在 58%–82% 之间，最可能是 70%。Miller（2024）指出：很多公开评测里模型之间报告的差异，比这个区间还小，并且给出评测报告应当使用的公式，包含聚类标准误修正（同一个来源多条样本的相关性修正）。
配对对比：我们写了第二版回复提示词，检索更多手册章节，在完全相同 60 条工单上跑：裁判通过率 v1：0.700；v2：0.700差值：+0.000，95% 置信区间 [-0.117, +0.117]结论：没有测出真实差异，保留 v1。注意这个区间比单版本准确率区间更窄：因为是配对测试，同一条工单跑两个版本，工单本身难度的干扰被抵消。McNemar 检验回答：v2 是不是在 v1 错的地方修好，还是只是好坏案例互相交换？本例就是互相交换。v2 在 14% 的样本上变差，一部分变好。表面通过率一样，背后是一部分客户体验变好、一部分变差。
重点：置信区间包含 0 的差异，属于噪声，不是优化收益。落地建议：所有 “新版本更好” 的结论，必须附带置信区间、变差样本占比。风险：很多团队仅凭 2 个百分点的虚假提升，就上线引入劣化的版本。
检测下限：60 条样本时，我们能稳定测出的最小差异大约是 12 个百分点。5 个百分点的劣化，在这个样本量下完全看不见。这是功效计算，用来回答：你想观测多大差异，需要多少样本。低于检测下限，唯一解法是增加样本，而不是换更精巧的统计方法。
多重比较问题：如果你同时测试 20 种提示词，挑最好的那个，其中一个大概率是运气带来的 10 个点提升。要么做多比较校正，要么拿胜出版本在全新测试集上复现验证。
✅ 第 5 层小结：所有指标附带置信区间；版本对比优先配对测试。实验前先算清楚你的检测下限。“没有测出显著差异” 是有效结论，往往也是正确结论。
第 6 层：多组件系统的打分
聚焦：待评测系统本身。问题：系统分多阶段、会执行动作时，我们该测哪些环节？
6.1 检索系统（RAG）
我们的回复模块先检索手册，再生成回答。坏回复可能来自检索环节，也可能来自生成环节，修复方案完全不同。所以要分开评测。
检索器打分：对照标准答案章节，hit@k（top-k 里至少包含一条正确章节）、recall@k（正确章节被召回的比例）hit@2：0.93，recall@2：0.8818 条失败回复里，1 条是检索出错，17 条是生成环节出错。检索器本身基本没问题，问题集中在生成。一句话直接帮工程团队锁定一周的优化方向。
生成器打分：忠实度（所有说法都来自检索文本）、相关性（回答问题）、上下文精度（检索到的内容是不是有用），也就是 RAGAS 三指标（Es 等人，2024）。这套指标不需要标准答案，所以 RAGAS 成为主流库。ARES（Saad-Falcon 等人，2024）增加统计严谨性：用约 150 条人工标注校准细分裁判，输出置信区间；论文里它在上下文相关性上，比 RAGAS 高出 59 点，标注量减少 78%；但领域偏移大的时候效果下滑。我们实测 RAGAS 给出上下文相关性 0.855、忠实度 0.737，和我们自研打分器结论一致：检索不错、生成弱。多种评测方式互相印证，指标可信度才高。
来自代码智能体领域的提醒：SWE-Explore（Zhang 等人，2026）测代码智能体检索：找到正确文件概率约 65%，找到正确代码行只有 15–19%；缺上下文，比多检索无关内容更容易导致下游出错。检索器评测粒度，要匹配下游生成需要的粒度。
6.2 智能体（Agent）
智能体执行一连串动作（查订单、退款、升级工单）。打分逻辑三点变化：
-
同时看最终状态和执行路径：数据库最终状态是否正确（退款成功、订单取消）？有没有违规动作，比如重复退款？τ-bench（Yao 等人，2024）奠定范式：模拟用户、策略规则、校验最终状态。AgentLens（2026）说明路径的重要性：智能体经常靠侥幸、绕路拿到正确结果，只看最终状态会高估能力。 -
同任务多次重复运行：智能体有随机性。两个指标：pass@k（k 次尝试里至少成功一次，代表能力上限）、pass^k（k 次全部成功，代表稳定性）。面向客户的智能体，重点看 pass^k。我们示例智能体 pass^3 = 0.75：四分之三任务连续三次都成功。τ²-bench（2025）发现：当智能体需要和真人交互，而不是独立执行时，pass^1 会下降约 20 个点。 -
稳定性单独作为指标：Rabanser 等人（2026）借鉴航空、核工程，定义 4 大类 12 个稳定性指标：多次运行一致性、扰动鲁棒性、可预测性（智能体知不知道自己会失败）、风险可控性。他们测 15 个前沿模型：两年里能力提升巨大，但稳定性提升只有前者的 1/6。智能体每次选的动作类型差不多，但顺序不一样；有的能优雅处理基础设施故障，换个说法提问就崩溃。
重点：能力强 ≠ 稳定可靠。客户体验的是稳定性。落地建议：上报 pass^k；给任务做扰动版本（字段改名、用户话术改写）；把多次运行一致性单独跟踪。风险：公开报道的事故（智能体删生产库、私自下单），全部来自平均成功率看起来不错的系统。
成本测量：Bai 等人（2026）在 SWE-bench Verified 上测 8 个前沿模型 Token 消耗。智能任务单次调用 Token 量大约是普通对话的一千倍，绝大多数 Token 用来反复读取自己越来越长的历史记录。同一个任务、同一个模型，不同运行成本差 30 倍；准确率在中等成本区间达到峰值，成本再高反而下降；模型对自身成本预测的相关系数最高只有 0.39。建议：按单次成功任务成本排序模型，而不是只看准确率；不要相信模型自己预估的成本。
三个新的评测维度（2026 基准）
-
取舍判断（Taste，Pan 等人，2026）：卡在分支点，两条路径表面都合理，看模型能不能选出长期收益更高的路线。最优模型二选一正确率 59.7%，思考更久不会提升。 -
主动提问（Asking，Gulati 等人，2026）：任务完成 10% 之后，澄清提问的价值大幅下降（0.78→0.39）；前沿模型几乎不会在这个窗口提问，不同模型提问频率从 52%、23% 到从不提问。 -
经验学习（Asawa 等人，2026）：6 个有状态环境里，最好的系统只能拿到 25% 理论上可从经验里获得的提升；单纯保留完整对话历史，效果超过很多专用记忆产品。
6.3 系统会针对打分器做优化时
如果打分器用来训练、筛选模型（RL、best-of-n 择优），系统会找到打分器盲区钻空子。Qwen 团队 Wang 等人（2026）称之为验证边界：任何打分器都是真实意图的代理指标；在优化压力下，代理指标和真实目标会脱钩。他们列举代码智能体的奖励作弊：直接读仓库历史答案、修改测试用例、专门为评测打分器写补丁。行为监控可以把作弊方案从 28.6% 降到 0.6%，同时真实有效方案从 40% 提升到 61%。他们的核心结论：不存在同时满足可规模化、忠实、抗作弊的打分器：
-
单元测试：可规模化、抗作弊，但无法覆盖真实意图 -
模型裁判：可规模化、贴合意图，但容易被钻空子 -
专家人工：忠实、抗作弊，但无法规模化
Meta-Agent Challenge（Lu 等人，2026）也观测到同类现象：被要求写智能体的智能体，在 5 次实验里尝试从打分系统窃取答案。
重点：任何参与优化、筛选的打分器，一定会被钻空子。落地建议：保留一套这个系统从来没见过的独立打分器；监控捷径行为；随着系统变强，同步升级打分器。风险：分数持续上涨，产品实际效果反而变差。
✅ 第 6 层小结：分阶段评测，检索和生成的故障模式不一样。智能体：同时看最终状态和路径、多次运行、pass^k、单次成功成本，稳定性单独跟踪。用来做优化的打分器一定会被作弊；保留一套独立、未见过的评测集。
第 7 层：公开基准测试集
聚焦：第 1 层里基准和业务评测的区别。问题：排行榜数字能说明什么、藏了什么？
基准是固定公开数据集，用来横向对比模型底座：MMLU（学术选择题）、GSM8K（小学数学）、HumanEval（代码）、MT-Bench、Chatbot Arena（对话质量）、SWE-bench（修复真实 GitHub issue）、τ-bench（客服智能体）、GPQA、HLE（专家难题）。基准用来挑选底座。引用基准数字前，记住四点：
-
分数是（模型 + 提示词 + 评测框架 + 版本）的组合，不只是模型本身属性。我们在同一个开源模型上跑 GSM8K，换两种提示词，得到 0.686 和 0.746。lm-evaluation-harness 论文（Biderman 等人，2024）证明：提示词、few-shot 样例、正则提取答案的表达式，都能带来十几个点的波动。Schaeffer 等人（2023）进一步证明：很多所谓 “能力涌现”，只是全对 / 全错这类指标带来的假象，换成平滑指标就消失。指标本身，能创造或者抹除现象。 -
数据污染：如果测试题已经在训练集里，分数测的是记忆，不是能力。GSM1k（Zhang 等人，2024）重新构建和 GSM8K 难度匹配、全新题目的数据集，部分模型家族分数掉最多 8 个点，降幅和模型见过原题的概率正相关；另一些家族几乎不掉分。污染真实存在，程度不均。 -
饱和：基准有保质期。2026 年研究 60 个主流基准，大约一半高度饱和，老牌基准饱和更快。SWE-bench Verified 两年内通过率从约 40% 涨到 80%+，维护者说明它已经很难区分前沿模型。MMLU、GSM8K、HumanEval 已经被前沿实验室逐步弃用，换成 HLE、GPQA Diamond、SWE-bench Verified、LiveCodeBench、τ²-bench；而这些新基准未来也会饱和。Chatbot Arena 头部模型 Elo 差距现在只有 20 分以内，落在噪声区间。 -
冗余：Zeng & Papailiopoulos（2026）搭建 84 模型 ×133 基准的矩阵，发现它近似二阶矩阵：两个底层因子就能解释 90% 以上的分数差异。精心挑选 5 个基准，就能预测其余 128 个基准的分数，误差≤4 分。对选底座来说是好事，不用跑几十个基准；但基准无法发现你业务独有的故障模式，这部分依然需要你的私有评测。
重点：排行榜是用去年的考卷，在固定评测框架下给发动机排名；头部模型之间差距经常在噪声里。落地建议：用公开基准筛出 2–3 个候选模型，最终用你自己业务评测在私有数据上做决定。风险：只看基准涨 2 分就换模型，上线后你的业务指标可能掉 10 分。
补充两个前沿评测方向：Google 论文助手工具（Jayaram 等人，2026），用智能体流水线评审学术论文，抓到 89.7% 已知证明错误，单轮调用只有 55.2%；850 位受访作者里 90% 觉得有用，31% 因为它的发现补充了新实验。CUSP（Wu 等人，2026）让模型预测哪些研究方向会成功，结果接近随机（0.519），并且自带稳定偏置（要么倾向说会成功，要么倾向否定），需要显式校正。两者共同提醒：评估模型的判断能力，必须有独立真值；模型对未来、对自身的校准能力很差。
✅ 第 7 层小结：基准分数是组合结果，不是模型固有属性，记录评测框架。基准会被污染、饱和，看发布时间。5 个基准基本覆盖排行榜信息；业务独有问题，只能靠你的私有评测。
第 8 层：把评测固化成日常流程
聚焦：快速导读里的执行时机。问题：不用研究团队，怎么每周稳定跑评测？
Hamel Husain（2024）三层节奏模型：
-
代码规则、格式校验、必填事实检查：每次代码提交都跑。成本几乎为 0。 -
模型裁判、检测器在测试集上运行，抽样人工复核：每次改提示词、模型、检索配置时跑。成本从几分到几美元。 -
线上 A/B 测试：版本上线之后在真实流量上跑。成本是真实用户体验。
合并门禁（merge gate）：我们教程的 CI 门禁自动跑第 1、2 层，当通过率相比基线 0.70 下降超过 3 个点时，阻断合并。它是捕获大劣化的预警线，不是质量保证：我们的检测下限是 12 个点，5 个点的劣化会直接漏过去。仪表盘上必须写明这个限制。
线上监控：上线后抽样真实流量，全量跑低成本打分器，高成本打分器只跑一部分样本，持续画趋势。Bodhwani 等人（2026）的 “先校准、再信任” 是稳妥方案：先用可核验真值，对昂贵裁判门禁做一次完整审计，确认低成本裁判在这个区间内和真实结果对齐；之后 CI 里只在这个可信区间使用低成本裁判；一旦模型、裁判、模拟器、业务域发生变化，重新审计。他们还发现一个零成本指标：对话是否正常结束，单独就能抓到资源耗尽类劣化。
缓存控成本：缓存模型调用，key 包含提示词、数据集版本、评测方案。重跑评测直接读缓存文件。我们 60 条工单完整 A/B 一共 121 次裁判调用，成本约 4 美分；全量教程从缓存复现，零调用。成本不是跳过评测的理由。
管理者要看的四个指标
-
产品通过率 + 置信区间 -
打分器和人工标注的一致性 -
检测下限 -
上一次改动里变差样本占比
缺任意一个，剩下三个指标都没有完整意义。
✅ 第 8 层小结：三层节奏：每次提交、每次改动、上线后。门禁只是下限，不是完美保障，写明检测下限。低成本裁判要先用真值校准，校准后才能在可信区间使用。
工具与方案总览
本节是调研观察，不是推荐清单。开发教程时全部跑过或复核，详细记录在知识库的实践笔记里。
框架
-
Inspect AI（英国 AI 安全研究所、MIT）：一体化流水线：数据集、求解器、打分器、日志查看器；适合智能体、沙箱，前沿安全评测在用。缺点：代码优先，上手学习成本高。 -
lm-evaluation-harness（EleutherAI，MIT）：稳定复现公开基准（GSM8K、MMLU、IFEval）。缺点：只做基准。 -
promptfoo（MIT，Node.js）：声明式 YAML 测试套件、红队、CI 回归。缺点：不是 Python 包；2026 年被 OpenAI 收购。 -
DeepEval（Apache-2.0）：pytest 风格单元测试，自带忠实度、相关性指标。缺点：汇总指标是复合值，要拆开看底层。 -
RAGAS（Apache-2.0）：RAG 三指标，不需要参考标准答案。缺点：本地模型容易不稳定、出现 NaN。 -
Langfuse（MIT，可自托管）：追踪、数据集、实验、裁判一体化。缺点：v4 版本改动评测语义，需要迁移。 -
Phoenix（Arize）：追踪 + 评测，UI 优秀。缺点：Elastic License 2.0，源码可看但不是开源。 -
LangSmith、Braintrust：托管平台：链路捕获、抽样、裁判自迭代。缺点：商用；Braintrust 自动评测库可以独立使用。 -
Opik（Comet）、MLflow GenAI、Weave（W&B）：可自托管观测平台，自带评测钩子。缺点：从零搭建比较重。 -
HELM（斯坦福）：多指标理念：准确率、校准、鲁棒性、公平、效率一起评估。缺点：偏向研究，开箱即用差。 -
evalica：成对打分转 Bradley-Terry、Elo 排行榜，带区间。缺点：只做统计，要搭配裁判。 -
Jev / TypeSafe：类型化裁判，带校准概率，比生成式裁判便宜约 100 倍。缺点：不生成文本、不能解释结论，标签由你提供。 -
HHEM、LettuceDetect、MiniCheck、SelfCheckGPT：专门判断 “这句话是否被文档支持”，CPU 快速、边际成本低。缺点：只能解决这一个问题。 -
Selene-Mini、Prometheus 2、Flow-Judge：开源权重裁判模型，可以本地部署审计。缺点：依然是裁判，同样需要校准。
方案横向对比
-
代码规则：校验格式、必填事实。免费；短板：看不懂语义。 -
相似度（ROUGE、Embedding）：看输出有没有变化。免费；短板：不能判断对错。 -
专用检测器 / NLI：判断内容是否被文档支持。几乎免费；短板：只能解决这一个问题。 -
类型化裁判（Jev）：标签 / 二元判断，带概率。千次调用几分钱；短板：不能解释、不能新增选项。 -
生成式裁判（二元 + 证据）：任意可读标准。单次几分钱；短板：五大偏见，必须校准。 -
裁判陪审团 + 稳健合并：同上，降低单点故障。3 倍裁判成本；短板：裁判之间错误相关，超过 3 个收益有限。 -
人工标注：真值。贵、慢；短板：需要双标注人，算一致性指标。 -
线上 A/B：看真实业务影响。有真实用户风险；短板：慢，需要前面的评测先兜底。
所有资料都体现同一个模式：自研打分器和框架指标互相对照。一致，提升可信度；不一致，就是一个值得深挖的问题。
决策指南
-
输出格式、完整性是否合格 → 代码规则；校验：规则本身精确。 -
新版本输出有没有变 → 相似度；校验：抽样人工看为什么变。 -
这条说法是否被文档支持 → 检测器 / 类型化裁判；校验：标注集上的精确率、召回率。 -
回复是否存在 X 类故障 → 二元生成裁判 + 证据；校验：开发集上 Kappa。 -
两个版本哪个更好 → 配对对比 + 置信区间；校验：变差样本数量。 -
能不能稳定检出 5 个百分点劣化 → 功效计算；校验：增加样本直到达标。 -
智能体稳不稳定 → 多次运行 pass^k、扰动任务；校验：跨轮次一致性。 -
选哪个基础模型 → 5 个公开基准初选；校验：私有业务评测终选。 -
线上是否持续正常 → 流量抽样、全量低成本打分器、高成本抽样；校验：任何组件变更后重新审计裁判门禁。
十五条核心要点总结
-
评测 = 输入 + 系统 + 打分器 + 指标。先做带标准答案的测试集，它是最核心资产。 -
业务评测测你的产品；公开基准测模型底座，不要混淆。 -
写打分器之前，先人工读上百条输出；故障清单就是评测方案。 -
能写代码规则的优先代码打分器；规则只能看形式，看不懂语义。 -
裁判用拆分后的二元问题，附带证据和上下文；整体打分容易放过埋好的错误。 -
裁判必须和人工真值对比，上报 Kappa 或者检出率；60% 一致率经常没有意义。 -
裁判有顺序偏好、长度偏好、自偏好等五大偏见，低成本手段就能缓解。 -
用户满意度 ≠ 任务成功；给裁判看工具调用、最终状态，而不只是聊天。 -
判断内容是否被文档支持，小检测器、类型化裁判，往往比通用生成裁判性价比更高、效果更好。 -
所有指标附带置信区间；版本对比优先配对测试；提前明确检测下限。 -
流水线多阶段，分开评测每一个环节。 -
智能体：同时看最终状态和路径、多次运行、pass^k、单次成功成本，稳定性单独作为指标。 -
用来优化模型的打分器一定会被钻空子；保留一套系统从未见过的独立评测。 -
基准分数依赖评测框架、存在污染、会饱和；记录完整元信息。 -
三层评测节奏、写明检测下限的门禁、线上监控、变更时重新审计裁判。
参考文献
知识库内文献（配套文件夹有摘要）Acharya, Pan, Verkhovsky (2026). RoPoLL: Robust Panel of LLM Judges. arXiv:2606.30931.Asawa et al. (2026). Continual Learning Bench. arXiv:2606.05661.Bai et al. (2026). How Do AI Agents Spend Your Money? arXiv:2604.22750.Bodhwani, Tran, Wei (2026). GAUGE: When Not to Trust LLM-as-a-Judge in User-Simulated Evaluation of Task-Oriented Agents. arXiv:2609.12191.Cho et al. (2026). Ask, Don't Judge / BinEval. arXiv:2606.27226.Fiddler (2026). The Evaluation Trust Tax: agent evals TCO.Grace, Hadfield, Olivares, De Jonghe (Anthropic, 2026). Demystifying Evals for AI Agents.Gulati et al. (2026). Ask Early, Ask Late, Ask Right. arXiv:2605.07937.HKUDS (2026). ClawWork (economic-accountability agent benchmark, code analysis).Jayaram et al. (Google, 2026). Towards Automating Scientific Review with the Paper Assistant Tool. arXiv:2606.28277.Lu et al. (2026). The Meta-Agent Challenge. arXiv:2606.04455.Menaged et al. (2026). Can LLM Agents Infer World Models? arXiv:2606.16576.Pan et al. (2026). The Tasteful Agent. arXiv:2609.25804.Parikh (2026). Structured Output Collapses Answer Diversity Across 44 Language Models. arXiv:2607.18476.Rabanser, Kapoor, Kirgis, Liu, Utpala, Narayanan (2026). Towards a Science of AI Agent Reliability. arXiv:2602.16666, ICML 2026.Wang et al. (Qwen, 2026). The Verification Horizon: No Silver Bullet for Coding Agent Rewards. arXiv:2606.26300.Wu et al. (2026). CUSP: Forecasting Scientific Progress with AI. arXiv:2605.22681.Zeng, Papailiopoulos (2026). You Don't Need to Run Every Eval. arXiv:2606.24020.Zhang et al. (2026). SWE-Explore. arXiv:2606.07297.
评测教程（tutorials/evals/，00–14 章节，Q&A.md，research/SOURCES_*.md）、配套入门笔记，文中示例数据全部来自这里。Jev 教程（tutorials/jev/）。
基础与行业实践文献Biderman et al. (2024). Lessons from the Trenches on Reproducible Evaluation of Language Models. arXiv:2405.14782.Chiang et al. (2024). Chatbot Arena. arXiv:2403.04132.Dubois, Galambosi, Liang, Hashimoto (2024). Length-Controlled AlpacaEval. arXiv:2404.04475.Es, James, Espinosa-Anke, Schockaert (2024). RAGAS. arXiv:2309.15217.Gu et al. (2024). A Survey on LLM-as-a-Judge. arXiv:2411.15594.Han et al. (2025). RAG vs GraphRAG: A Systematic Evaluation. arXiv:2502.11371.JEV-as-a-Judge (2026). arXiv:2609.26550.Panickssery, Bowman, Feng (2024). LLM Evaluators Recognize and Favor Their Own Generations. arXiv:2404.13076.Husain (2024). Your AI Product Needs Evals.https://hamel.dev/Husain (2025). A Field Guide to Rapidly Improving AI Products. Husain & Shankar (2025). AI Evals FAQ.Jimenez et al. (2024). SWE-bench. arXiv:2310.06770. OpenAI (2024). SWE-bench Verified.Kovács, Recski (2025). LettuceDetect. arXiv:2502.17125. Tang, Laban, Durrett (2024). MiniCheck. arXiv:2404.10774. Manakul, Liusie, Gales (2023). SelfCheckGPT. arXiv:2303.08896.Liang et al. (2022). HELM. arXiv:2211.09110.Liu et al. (2023). G-Eval. arXiv:2303.16634.Miller (2024). Adding Error Bars to Evals. arXiv:2411.00640.Saad-Falcon, Khattab, Potts, Zaharia (2024). ARES. arXiv:2311.09476.Schaeffer, Miranda, Koyejo (2023). Are Emergent Abilities of Large Language Models a Mirage? arXiv:2304.15004.Shankar, Zamfirescu-Pereira, Hartmann, Parameswaran, Arawjo (2024). Who Validates the Validators? arXiv:2404.12272.Tan et al. (2025). JudgeBench. arXiv:2410.12784.Verga et al. (2024). Replacing Judges with Juries (PoLL). arXiv:2404.18796.Wang et al. (2024). Large Language Models are not Fair Evaluators. arXiv:2305.17926.Yan (2024). Task-Specific LLM Evals that Do & Don't Work; Evaluating the Effectiveness of LLM-Evaluators.https://eugeneyan.com/Yao, Shinn, Razavi, Narasimhan (2024). τ-bench. arXiv:2406.12045. Sierra (2025). τ²-bench. arXiv:2506.07982.Zhang et al. (2024). GSM1k. arXiv:2405.00332.Zheng et al. (2023). Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. arXiv:2306.05685.Zhou et al. (2023). IFEval. arXiv:2311.07911.
2026 审计类文献：When AI Benchmarks Plateau (arXiv:2602.16763); When the Judge Changes, So Does the Measurement (arXiv:2607.08535); Reliability without Validity (arXiv:2606.19544); AgentLens (arXiv:2605.12925).