← 返回闯关手册

Eval：有了「什么叫好」，为什么还不能放心上线？

核心内容速览

• Eval = 决策机制：一次评测必须预先回答「这个结果支持哪个产品决定」，否则评测做完没人知道该干嘛。
• 一次完整 Eval 的七个组成部分：任务集、被测对象快照、运行环境、评分标准、裁判、判定规则、后续动作——缺任何一环，结论都不可复现。
• 上线门禁思维：把评测结果接到发布流程里——红线触发阻断、低分触发返修、Unknown 触发人工复核，而不是「平均分涨了就好」。
• 被测对象要快照：模型版本、Prompt、检索库、工具配置任一变化，上一轮的评测结论就失效了。

适合谁 · 怎么用

适合读完 a01（Rubric）之后接着读，两者是「标准」与「机制」的组合。读完后检查你手头的评测：七个组成部分里缺了哪几个？最常见的缺口是「后续动作」——评测报告写完没人执行。

闯关自测

先合上原文在心里作答，再点开对照。全对 = 本篇真正通关。

Q1　一次完整的 Eval 由哪七个部分组成？

任务集、被测对象快照、运行环境、评分标准、裁判、判定规则、后续动作。缺任何一环，评测结论都不可复现。

Q2　「Eval 是决策机制」和「Eval 是打分」的区别是什么？

打分的产出是数字，决策机制的产出是动作：发布、返修、转人工还是阻断。如果评测做完不知道下一步干什么，它就是一次无效评测。

Q3　为什么被测对象需要「快照」？

模型版本、Prompt、检索库、工具配置任何一项变化，上一轮结论就失效。快照让评测可复现、可回归。

以下为原文全文

上方为本站原创导读，下方为原文完整收录，便于对照阅读。

团队为市场研究 Agent 写好了一套评分量规（Rubric），选出 20 个研究任务，让 v1.2 和 v1.3 分别生成报告，再由业务专家按同一套标准评分。新版本平均高出 3.4 分。负责人看完问了一句：「高了 3.4 分，就能上线吗？」

这算不算 Eval？当然算。用固定任务测试系统，再按明确标准比较结果，本身就是一套最小 Eval。真正的问题是：这 3.4 分足以支持发布新版本吗？20 个任务能代表真实业务吗？两位专家的打分一致吗？再跑一次，结果会反转吗？报告写得好但引用打不开，算通过吗？

Eval 不是一种评测方法，而是一套用证据判断 AI 系统是否值得发布、采用或继续改进的机制。

一、先把关系摆正：质量标准是 Eval 的标准层

Rubric 是一份判分说明书：告诉评价者看哪些方面、用什么证据判断、怎样区分优秀与不合格。但一次完整评测还会遇到许多有明确答案的问题，不必让人或模型阅读判断，用更直接的方法反而更可靠：

• 分类标签是否正确 → 核对标准答案；
• JSON 格式是否合规 → 程序验证；
• 代码能否工作 → 运行单元测试；
• 订单是否退款 → 检查数据库状态；
• 推理是否完整、建议是否有价值 → 交给 Rubric、模型或专家判断。

Eval 是整个评测活动；Rubric 是开放质量的标准与评分工具。

二、Eval 的起点不是「怎么打分」，而是「要做什么决定」

同一套市场研究 Agent，因为目的不同而需要完全不同的 Eval：选择模型时比较质量、成本和延迟；发布新版本时检查回归；排查投诉时定位失败环节；高风险业务还要验证红线能否被发现和阻断。

常见评测决策有四类：

1. 能力判断：系统会不会完成某类任务？
2. 版本选择：A 和 B 哪个更适合当前业务？
3. 发布门禁：新版本能否上线，有没有不可接受的退步？
4. 问题诊断：失败发生在哪里，下一轮应该改什么？

目的不同，样本、证据和结果都会变化。用于模型选型的平均分，不能直接充当发布门禁。因此设计 Eval 时最先写下的不应是「用哪个 Judge」，而是：这次评测最终要支持哪个决定？

三、一套完整 Eval，至少连接七个部分

综合 OpenAI、LangSmith 和 Anthropic 的实践，一套完整 Eval 至少包含七部分：

1. 评测决策：支持选型、发布、诊断还是风险判断；
2. 被测对象：具体到模型、Prompt、知识库、工具和工作流版本；
3. 评测任务：用哪些真实、边界和高风险场景测试；
4. 运行协议：环境如何准备，同一任务跑几次，哪些条件保持一致；
5. 观察证据：最终输出、执行过程、环境结果，还是成本与延迟；
6. 评价方式：规则、参考答案、程序、Rubric、模型 Judge 或人工；
7. 结果与动作：怎样汇总、比较、处理证据不足，并触发发布、返修或阻断。

Eval = 决策问题 + 被测版本 + 测试任务 + 运行协议 + 观察证据 + 评价方式 + 结果动作

四、以市场研究 Agent 为例，一次 Eval 怎样成立？

假设要决定 v1.3 是否可以替代 v1.2。先写清决策条件：新版本要提升研究质量，不能增加伪造引用，成本不能超上限。再固定任务和模型、Prompt、知识库、工具配置，在相同环境中运行，保存报告、引用、工具记录、耗时和成本。然后不同评价方式分工：程序检查链接、日期、字段和成本；参考答案检查关键内容覆盖；模型按质量协议判断推理完整性和决策价值；业务专家抽样复核并处理红线与争议。

最终输出的不是一个总分，而是一份版本判断：哪些任务两个版本都通过；哪些能力明显改善；哪些旧问题没变化；哪些原本通过的任务出现回归；是否触发红线或证据不足；质量提升是否值得增加的成本。

如果 v1.3 报告更完整却更容易使用过期来源，团队得到的不该是「新版本高 3.4 分」，而应是：「暂不全量替换；先修复来源时效性，再对失败任务回归。」这才是一次能支持产品决定的 Eval。

五、为什么有质量标准和分数，结论仍可能不可信？

• 任务选偏了：20 个样本都来自简单场景，高分只说明擅长简单任务——评测集设计问题；
• 评价者不稳定：专家分歧大，或 Judge 偏爱长答案——Judge 与人工校准问题；
• 只看最终文本：回复看似完成，实际没调用必要工具或没改变环境状态——观察对象问题；
• 只运行一次：同一模型对相同任务可能产生不同结果，一次高分无法说明稳定通过；
• 评完没有动作：结果没进入发布门禁、回归集和失败修复，Eval 就只是一份报告，而不是产品机制。

六、用一页画布设计第一套 Eval

普通团队不必先建平台。选择一个具体决策，填完下面七行，就得到第一版评测设计：

评测要支持的决定：
被测系统与版本：
测试任务及其来源：
运行次数与固定条件：
需要保存的证据：
每类证据的评价方式：
通过、返修、复核和阻断规则：

填完后检查三个问题：① 这套 Eval 的结果能否直接支持最初的产品决定？② 每个结论能否追溯到具体任务、运行记录和评价证据？③ 修改系统后，能否在相同条件下重新运行并发现回归？如果都是「能」，团队已经拥有了一套最小但完整的 Eval。

真正的评测能力，不是掌握某个评分技巧，而是知道应该用什么证据，回答哪个产品问题。