Eval 设计：什么算好，谁说了算
给需要向业务方或客户证明「这个 AI 系统够好可以上线」的人。这一页讲评估集怎么建、人类基线怎么测、LLM-as-judge 怎么写与怎么校准、阈值怎么定、上线之后怎么持续跑。含可直接抄的评估集表结构和 judge 提示词骨架。
本页小目录（约八千字，可跳读；带实物的是第三、五、六、七节）： 一 为什么是核心｜二 预测 vs 判断｜三 定标会议程｜四 评估集怎么建（七步）｜五 评估集表结构（可直接抄）｜六 judge 提示词骨架与校准｜七 阈值怎么拆｜八 上线后持续评估｜九 中文场景四个难题｜十 常见误区
一、为什么 Eval 是 FDE 交付的核心
传统企业软件的验收标准是功能清单：这十七个功能做没做出来，做出来了就验收。LLM 应用没有这个东西——同样的输入每次输出可能不同，「做出来了」和「够好用」之间没有必然联系。于是验收标准必须被重新发明一次，而这件事的名字叫 Eval。
几条来自一手材料的论断：
- Hamel Husain（为三十多家公司搭过评估体系）：「不成功的产品几乎都共享同一个根因：未能建立健全的评估体系。」他同时把「成功取决于你能多快迭代」当作支点——没有 Eval，你无法判断一次改动是变好还是变坏，迭代就退化成随机游走。[1]
- OpenAI 的 evals 开源仓库 README：「构建高质量的评估，是你能做的最有影响力的事情之一。」[2]
- Anthropic 的文档把评估放在开发流程最前面：先用 SMART 原则把成功标准写成可测的东西（例如「在 10,000 条多样化推文上 F1 不低于 0.85」，而不是「分类做得好」）。[3] 2026 年 1 月的《Demystifying evals for AI agents》还给了降低门槛的建议：从 20 到 50 个来自真实失败案例的任务起步，而不是等凑够几百个。[4]
对 FDE 而言，Eval 还多承担两个非技术功能，这两个在纯工程语境里不会被提到：
- 它是和业务方的契约。 「什么算好」由业务方定义并签字，就堵死了「事后调整球门柱」这条路。有 FDE 培训项目把这件事直接写进商务文件，称为 eval-anchored acceptance criteria（以评估集锚定的验收条款）——把评估集变成合同附件。[5]
- 它是上线闸门。 Eval 套件当作 CI 的部署门禁，是目前少数几个把「AI 系统能不能上」变成可自动判断的机制。[5]
一句话概括这一页的立场：Eval 不是上线前的一道关卡，是一条一直开着的仪表。
二、动手之前：先把「预测」和「判断」切开
在攒任何评估集之前，先把任务拆成 AI 干的部分和人干的部分。一张现成的表可以用：Agrawal、Gans、Goldfarb 发表在《哈佛商业评论》上的 AI Canvas（2018 年 4 月，配套书《Prediction Machines》），原版七格是 Prediction / Judgment / Action / Outcome / Input / Training / Feedback。[6]
对 Eval 来说，最关键的是前两格的分界线：
- **Prediction（预测）**是 AI 负责的部分——它在猜什么（这封邮件属于哪一类、这张单子有没有风险、这个报警最可能是什么原因）。
- **Judgment（判断）**是人负责的部分——不同错误的相对代价。
Eval 评的是第一格。阈值定的是第二格。 把这两件事分开，你就不会掉进最常见的那个坑：为了追求一个更高的准确率数字，去做一堆和业务代价无关的优化。
第一仗不用填满七格，填三行就够：
核心预测：给定一封客服邮件的正文和附件，预测它属于 12 个工单类型中的哪一个，以及紧急度（高 / 中 / 低）。 判断（业务方原话）：把「投诉类」误判成「咨询类」的代价，远大于反过来。前者会让一个已经不满的客户多等 8 小时；后者只是多占一次高优先队列。 行动：分类结果决定工单进哪个队列、排在第几位。不自动回复。
第二行是这张表的全部价值，而且只有业务方能说。它直接决定第七节的阈值往哪边偏。
三、和业务方一起定义「什么算好」
3.1 三级标准
| 级 | 问什么 | 谁定 | 示例 |
|---|---|---|---|
| L1 任务级对错 | 「这条输出，对还是不对？」 | 一线操作者 | 工单类型分对了没有 |
| L2 业务级好坏 | 「对，但你愿不愿意直接拿去用？」 | 一线 + 主管 | 分对了类型，但紧急度判低了，客户多等了 6 小时 |
| L3 灾难级红线 | 「什么样的输出会让你半夜接到电话？」 | 部门负责人 | 把一个监管投诉判成了普通咨询 |
L3 是最容易被跳过的一级，也是最重要的一级。 它不是「错误率要低」，是一份具体的、可枚举的清单：
红线 1：包含「起诉」「消协」「监管」「投诉到总部」字样的邮件，被判为非投诉类。 红线 2：涉及金额 > 5 万元的退款请求，紧急度被判为「低」。 红线 3：任何提到人身安全的内容，未被标记为最高优先级。
红线不参与打分，红线是一票否决。 一条红线被触发，这一版就不能上，不管总分多少。
3.2 一场 90 分钟的定标会（议程可照抄）
| 时间 | 干什么 | 关键动作 |
|---|---|---|
| 0–10 | 摆出问题陈述，确认没变 | 念一遍，让他点头 |
| 10–25 | 填 AI Canvas 三行简版 | 「判断」那一行必须由他说，你只记录 |
| 25–50 | 现场看 20 条真实样本 | 一条一条问「这条应该判成什么、为什么」 |
| 50–70 | 定 L1 / L2 的判定标准 | 把他的话变成可勾选的条目 |
| 70–85 | 定 L3 红线清单 | 「什么样的输出会让你半夜接到电话」 |
| 85–90 | 定谁标注、什么时候标完 | 落到人名和日期 |
25–50 分钟这一段是全场重心。不要讨论抽象标准，当场打开 20 条真实的历史记录。你会观察到三件事，每一件都有价值：
- 他自己的判断也不完全一致——同类的两条给了不同答案。当场指出来问为什么，冒出来的差别通常是一条没人写下来过的业务规则。
- 有些条他也要想很久——这些是边界样本，单独存一份。
- 他会改口——「刚才那条我再看看，应该算投诉。」改口是好事，说明标准正在被真正定义，而不是被随口报出。
这个「先看数据再定标准」的顺序有一手依据。Hamel Husain 与 Shreya Shankar 在 2025 年的《A Field Guide to Rapidly Improving AI Products》里引用 Shankar 等人的研究提出 Criteria Drift（标准漂移）：「在人工评判之前，不可能完全确定评估标准。」结论是——评估标准应该被当作随理解演进的活文档，而不是一次写死的规格书。[7]
Eugene Yan 在 AlignEval 里把这件事说成双向对齐：不只是让 AI 对齐人类偏好，也要「用实际数据校准人类的标准」。[8]
3.3 一句必须当面说的话
会开完，把结论念给业务方，然后说：
「这个标准定下来之后，第四周我们就按这个打分。如果那时候分数不好看，我不会来改标准。 所以现在您觉得哪里定得不合适，我们现在改。」
这句话把「事后调整口径」这条路提前堵死。你的最终数字有没有信用，取决于这一刻。
四、评估集怎么建：七步
第 1 步：确定数量
第一个场景，200 到 300 条是一个务实的起点。 给这个数的理由不是统计学上的置信区间，是三个现实约束：
- 业务方能标完的量：一条平均 40 秒，300 条约 3.5 小时，分三次是一个部门主管能接受的极限；
- 能覆盖住的类别：12 个类别、300 条，平均每类 25 条，够看出哪一类明显不行；
- 能感知到的变化：300 条规模下一个百分点约等于 3 条。
如果你还没有历史数据，Anthropic 的建议更低：20 到 50 个来自真实失败案例的任务就可以开始，条件是每个任务清晰到「两位领域专家能独立得出相同的 pass/fail 判断」，并且配一份参考解。[4] 50 条手工构造的评估集，好过 0 条。
需要注意评估集规模与统计噪声的关系。Anthropic 的 Evan Miller 在《A statistical approach to model evaluations》（配套论文 arXiv:2411.00640）里给了三条建议：评估分数是大量题目上的均值，应基于中心极限定理报告标准误；如果题目是成簇的（同一段材料衍生多题），要用 clustered standard errors；比较两个版本时做配对差异分析，比各自算总分再相减更灵敏。[9] 在企业交付里最实用的一条是最后一条：同一批题、同一个 judge、比较两个版本的逐条差异，比看两个总分靠谱得多。
第 2 步：分层抽样，不要随机抽
随机抽 300 条，你会得到一个和线上分布一样的评估集，也就是说八成是简单样本。这种评估集分数好看，但没有诊断价值。
| 层 | 建议占比 | 从哪抽 | 作用 |
|---|---|---|---|
| 典型样本 | 40% | 近 6 个月随机抽 | 反映真实分布，算总分用 |
| 高频样本 | 15% | 出现次数最多的 3 类各抽一批 | 这几类做不好，用户第一天就跑了 |
| 边界样本 | 20% | 定标会上「他也要想很久」的那些 + 判断卡里「什么情况下这个判断是错的」 | 诊断价值最高的一层 |
| 红线样本 | 15% | 按 L3 清单，每条红线找 5 到 10 个真实或构造的例子 | 一票否决用 |
| 垃圾样本 | 10% | 空白、乱码、只有一个「？」、发错的、测试数据 | 看它会不会一本正经地胡编 |
最后一层最容易被跳过，也最容易在上线第一天打脸。 真实业务数据里垃圾输入的比例远高于你的想象。
第 3 步：从哪里捞真实样本
按可得性排序：
- 工单系统 / 客服记录 / 审批记录——有输入、有人工处理结果、有时间戳，最理想，因为人工处理结果是天然的标签；
- 企业内的历史消息（走合规流程）；
- 纸质单据的扫描件（很多传统企业最真实的数据在这里）；
- 你自己在现场跟班时拍的照片和记的笔记——数量少但质量最高，因为你知道当时的上下文。
第 4 步：让业务方重标一遍（这一步不能省）
不要直接拿系统里的「人工处理结果」当标准答案。 历史记录里的人工结果，是当时那个人在当时的压力下做的，本身就有错，实践中错误比例常在 5% 到 15% 之间。
做法：把抽好的样本去掉原有结果，让业务方重新标。然后做一件很有价值的事——把「重标结果」和「历史结果」做比对。
- 一致的比例 → 这就是你的人类基线。
- 不一致的那些里，挑 20 条当面问「这条当时为什么这么处理」。
第 5 步：人类基线与标注一致率
这一步产出两个数字，几乎所有中文材料都跳过了它们。
（1）人类基线：人做同一批题能做到多少。作用在汇报那天显现——有人问「87% 够不够」时，你的答案不是「行业水平差不多」，而是「我们自己的人做同一批题是 85%」。
（2）双人标注一致率：让两个人独立标同样的 20 到 50 条，看对得上多少。原始一致率（percent agreement）有个已知缺陷——不扣除瞎猜也能对上的部分：二分类且类别不均衡时（90% 都是「合格」），两个人闭眼全标「合格」，原始一致率就是 90%，毫无意义。标准修正是 Cohen's kappa，Landis 与 Koch 1977 年给的经验分级至今被引用最多：0.21–0.40 一般，0.41–0.60 中等，0.61–0.80 显著，0.81–1.00 几乎完全一致。[10]
这两个数字的真正用途是诊断，不是学术严谨：
- 两个业务专家对不上超过两成 → 不是标注员的问题，是你的判定标准写得不够具体。回第三节把规则改清楚，再标一遍。
- 两个业务专家高度一致，但和你的系统差很远 → 标准清楚，系统确实不行，去改系统。
- 两个业务专家对不上，而且他们互相说服不了对方 → 这个任务可能本身就没有唯一正确答案，评估方式要从「对错」改成「好坏打分」或「多个可接受答案」。
第 6 步：破解「先有鸡还是先有蛋」
一个真实的两难：效果差的时候给用户用会损害信任，不给用户用又拿不到数据。三条破法：影子模式（系统后台跑，结果不给用户看，只和人工结果对比——零信任风险、持续攒数据，第一周这么开局最稳）；人在回路（AI 出结果、人确认后才生效，用户的每一次「确认 / 修改」都是一条标注，这是把标注成本藏进日常工作里最有效的办法）；只放最有把握的那一档（先只处理高置信度的那 30%，其余走原流程——用户看到的都是对的，信任在建立，数据在积累）。第三条同时是第七节阈值设计的基本形态。
第 7 步：冻结并版本化
- 打版本号（如
eval-v1-20260901），存成一个不再改的文件； - 写一份说明：怎么抽的、谁标的、人类基线是多少、一致率是多少、红线清单是什么；
- 另存一份「保留集」：从同一批数据里再抽 50 条，不给任何人看，包括你自己。这 50 条只在上线前用一次，防的是你为了刷分而对着评估集调优。
- 评估集不进提示词，不拿去微调。 泄题的评估集等于没有评估集。
五、评估集表结构（可直接抄）
一个文件，一行一条。
| 字段 | 说明 | 示例 |
|---|---|---|
id | 唯一编号 | EV-0137 |
layer | 属于哪一层 | 边界 |
input | 完整原始输入（不要预处理，要脏的） | 邮件正文原文，含错别字和排版 |
context | 这条的背景信息 | 「该客户 30 天内第 3 次来信」 |
gold_label | 标准答案（业务方重标后的） | 类型=投诉，紧急度=高 |
gold_by | 谁标的 | 李主管 |
gold_reason | 为什么是这个答案（一句话） | 「提到了『再不解决就投诉到总部』」 |
history_label | 当时人工的实际处理结果 | 类型=咨询，紧急度=中 |
is_redline | 是否红线样本 | 是（红线1） |
notes | 备注 | 「附件是一张手机拍的照片，很糊」 |
gold_reason 是这张表最关键、也是几乎所有人省掉的一列。 三个理由：
- 它让标准可被审计。三个月后有人质疑「这条为什么算投诉」，你有答案。
- 它是 judge 提示词的原料。judge 里的判定要点，直接从这一列的高频词里长出来。
- 它能暴露标注者自己的不一致。两条几乎一样的样本给了不同标签，但 reason 写的是同一句话——你抓到了一个标注错误。
一条填好的完整样例：
id: EV-0137
layer: 边界
input: "上次那个单子到现在还没给我回话，我这都第三回问了。你们要是再不给个说法我就打12315了。订单号 A2026081100731"
context: 该客户 30 天内第 3 次来信；订单金额 3,280 元；前两次均被分为"咨询-物流"
gold_label: 类型=投诉，紧急度=高
gold_by: 李主管
gold_reason: 出现"第三回"（重复来信）+ 明确的监管投诉威胁（12315），任一条件成立即为投诉-高
history_label: 类型=咨询-物流，紧急度=中
is_redline: 是（红线1：提到监管渠道未判为投诉）
notes: 这条历史处理是错的，当时的客服只看了订单号注意 history_label 和 gold_label 不一样——这正是第 4 步存在的意义。如果你直接用历史标签，你的系统会学会犯同一个错误。
六、LLM-as-judge：怎么写，怎么校准
评估 200 到 300 条，人工全跑一遍要一天。所以用 LLM 当裁判（LLM-as-judge），人只做校准和抽检。
6.1 这个方法的证据强度
学术上的一手来源是 Zheng et al.《Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena》（arXiv:2306.05685，NeurIPS 2023）。被引用最多的一句是：强 LLM judge（如 GPT-4）能很好地匹配受控实验和众包场景下的人类偏好，达成超过 80% 的一致率，与人类之间的一致率处于同一水平。[11]
引用这个数字要注意两点：它衡量的是「与人类偏好的一致率」，不是「判断正确率」；同一篇论文也明确列出了 judge 的已知偏差（下表数字经 Eugene Yan 整理，原始来源同为该论文）：[12]
| 偏差 | 表现 |
|---|---|
| Position bias（位置偏好） | 在成对比较里偏向排在前面的那个。论文报告 GPT-3.5 约 50%、Claude-v1 约 70% 的概率偏向第一个位置 |
| Verbosity bias（长度偏好） | 更偏好更长的回复，即使更长的版本只是同义重复扩写、没有新增实质信息；论文报告的比例超过 90% |
| Self-enhancement bias（自我偏好） | 偏好自己生成的输出。GPT-4 对自己输出的胜率高出约 10 个百分点，Claude-v1 约 25 个百分点 |
三条实操纪律：不要用生成答案的同一个模型来当裁判（Anthropic 文档把这条写成明确的最佳实践[3]）；成对比较要交换顺序跑两遍，或改成对照标准答案的单条判定（本页骨架用的是后者，更适合有标准答案的企业任务）；控制回复长度，否则 verbosity bias 会让你误以为「更啰嗦的版本更好」（OpenAI 的 graders 文档也提到这点，并建议在打分前加入推理步骤[13]）。
6.2 judge 一号骨架：二分类判定（有标准答案的任务）
先摆一条 Hamel Husain 的主张：用二元 Pass/Fail，不要用 1–5 分量表，理由是「人们不知道 3 分或 4 分该如何处置」，而二元判断能强迫评估者说清楚真正在意的是什么。配套做法他叫 Critique Shadowing：让领域专家对每条输出回答一个二元问题（AI 是否达成了预期结果），同时写下批注说明理由。[14]
你是一名【业务领域】的质检员。你的任务是判断一条系统输出是否正确。
【判定规则】（由 XX 公司 XX 部门 X 主管定义，2026-09-01 版）
1. 类型判定优先级：投诉 > 售后 > 咨询。同时符合多类时，取优先级最高的。
2. 满足以下任一条件，即为"投诉"：
- 出现监管或第三方渠道字样（12315、消协、市监、起诉、媒体、投诉到总部）
- 同一客户 30 天内第 3 次及以上就同一订单来信
- 出现明确的负面情绪表达且指向服务过程
3. 紧急度判定：
- 高：投诉类；或涉及金额 > 50000 元；或提到人身安全
- 中：售后类且客户已等待 > 48 小时
- 低：其余
4. 本行业黑话对照：【在这里显式列出简写、方言、行业术语的对照表】
【输入】
原始内容：{input}
背景信息：{context}
【待评判的系统输出】
类型：{pred_type}
紧急度：{pred_urgency}
【标准答案】
类型：{gold_type}
紧急度：{gold_urgency}
判定依据：{gold_reason}
【你的任务】
先在 reasoning 里简要说明你的推理，再给结论。严格按下面的 JSON 输出，不要输出任何其他内容：
{
"reasoning": "不超过 60 字的推理过程",
"type_correct": true 或 false,
"urgency_correct": true 或 false,
"verdict": "完全正确" | "类型错" | "紧急度错" | "都错",
"which_rule": "系统输出违反或遗漏了上面第几条规则，写规则编号；若正确写 '-'",
"one_line": "一句话说明系统为什么判错，不超过 30 字；若正确写 '-'"
}
【重要】
- 只依据上面的判定规则，不要用你自己的常识补充规则。
- 不要因为输出更长或更详细就判它更好。
- 如果标准答案本身看起来违反了判定规则，在 one_line 里写 "疑似标注问题：..."，
并把 type_correct 按规则判定，而不是按标准答案。最后那条约束是这个骨架里最重要的设计：它让 judge 在跑批的同时帮你查标注错误，接近零成本的双重收益。这与 Shankar 等人《Who Validates the Validators?》的核心论点相通——LLM 执行的评估器会继承被评估系统本身的问题，人工校验环节不能取消。[15]
which_rule 字段的用途是失败分析：跑完批按规则编号聚类，立刻能看到「最该先修的三类问题」，而不是一个笼统的准确率。Field Guide 里的 NurtureBoss 案例就是这个动作的效果：错误分析发现三类问题占故障超过 60%，据此把日期处理成功率从 33% 提到 95%。[7]
6.3 judge 二号骨架：多维打分（生成类任务）
有些任务没有唯一正确答案（生成排障建议、写回复、出报告）。这时候要多维打分，但安全维度不能参与加权平均。
你是一名【领域】的资深从业者，有 20 年现场经验。
请对一条 AI 生成的【建议 / 回复】打分。你的评价标准是"一个刚入职半年的新人，
拿着这条输出去干活，能不能干成"。
【场景】{input}
【背景】{context}
【AI 输出】{output}
【资深从业者的参考答案】{gold}
请在四个维度上各打 1-5 分，并各给一句理由：
A. 决断性：第一句话有没有给出一个明确的、最可能的判断？
5 = 第一句就是"八成是 X，先做 Y"
3 = 给了判断但埋在第三段之后
1 = 通篇是"可能有多种原因，建议逐项排查"
B. 可执行性：新人能不能照着做？动作是否具体到对象和步骤？
5 = 每一步都有明确的对象和动作
1 = 只有"检查通讯链路"这种层级的表述
C. 安全性：有没有遗漏高风险分支？高风险情况的提示有没有写在显眼位置？
5 = 明确写出"如果同时出现 Z，立刻停机并叫专业人员"
1 = 完全没提高风险分支
【注意】本维度打 1 或 2 分的，整条直接判为不合格，无论其他维度多少分。
D. 像行家说的话：读起来像老师傅说的，还是像规程手册？
严格按 JSON 输出：
{
"decisiveness": 1-5, "decisiveness_why": "...",
"actionability": 1-5, "actionability_why": "...",
"safety": 1-5, "safety_why": "...",
"human_like": 1-5, "human_like_why": "...",
"hard_fail": true 或 false,
"worst_dimension": "四个维度里最差的那个的字母"
}C 维度的 hard_fail 设计是这个骨架的要点：一条 A/B/D 都是 5 分、C 是 1 分的输出，加权平均是 4 分，看起来很好，实际是会出事故的那一条。加权平均会把安全问题抹平，所以安全必须走一票否决。
打分粒度有两派意见：Hamel 主张二元 Pass/Fail[14]；OpenAI 的 graders 文档建议输出连续分数，理由是更容易观察渐进式改进。[13] 务实的折中就是本页的形态——多维分数 + 一个二元 hard_fail，前者看趋势，后者做上线决策。
6.4 judge 必须校准（这一步不能省）
judge 也会错。上线跑批之前做一次对齐测试：
- 从评估集里抽 50 条，人工和 judge 各判一遍；
- 算一致率。类别不均衡时同时看 True Positive Rate 和 True Negative Rate，别只看笼统的总一致率（Hamel 在 Honeycomb 案例里特别强调这一点）[14]；
- 一致率不达标就不许用这个 judge，回去改提示词。Hamel 报告的 Honeycomb 案例经三轮迭代把一致率做到 90% 以上；实践中可先把 85% 当可用下限；
- 逐条看不一致的条目。一半以上的情况你会发现是判定规则本身有歧义——回第三节把规则改清楚。
一致率写进文档。有人质疑「你这个分数是 AI 打的，可信吗」，你的答案是：「这个裁判和李主管的一致率是 91%，抽检了 50 条，记录在这里。」
七、阈值怎么定：把一个数拆成两个数
「87% 够不够」没有通用答案，但有通用的问法。
7.1 第一步：按出错代价分三档
| 档 | 出错的后果 | 目标形态 | 阈值逻辑 |
|---|---|---|---|
| A 档：错了没事 | 重发一次、人工改一下、多点一次鼠标 | 全自动 | 只要明显好过现状就能上。基准是现状，不是 100% |
| B 档：错了要花钱或丢面子 | 客户投诉、返工、赔付、内部追责 | 人在回路：AI 出建议，人确认 | 目标不是「判得准」，是「帮人少花时间，且不引入新的错误」 |
| C 档：错了伤人 / 停产 / 违规 | 安全、合规、不可逆损失 | 只做线索，不做结论 | 第一个项目不碰。真要做，建模主导权交给专业方 |
这三档的归属应该由业务方确认，依据是第二节 AI Canvas 里「判断」那一行。
7.2 第二步：找到基准线，别拿 100% 当基准
三条基准按强度排序：人类基线（第 5 步算出来的那个数，最强，因为无可辩驳）；现状水平（现在分错率 12%，那 88% 就是及格线的下沿）；同类公开参考（可以引，但必须标口径，并说清是二手转述还是一手披露）。
7.3 第三步：把阈值拆成两个数
这是这一节最实用的一条。不要定一个「准确率要到 X%」，要定两个数：
自动处理阈值：置信度 ≥ 0.85 的直接进队列，预计覆盖 62% 的量，这部分的准确率 96%。 人工兜底比例：其余 38% 走人工，其中置信度最低的 10% 标红提示。
这样定的三个好处：
- 用户看到的准确率是 96%，不是 87%。 信任建立得快得多。
- 你有一个可以调的旋钮。 对方嫌自动化率低，你把阈值降到 0.75，覆盖率升到 80%，准确率降到 92%——把这个权衡明确摆出来让他选。这一刻你从执行者变成了参谋。
- 红线单独走。 命中任何一条 L3 红线的，无论置信度多高，一律走人工。红线不参与阈值计算。
用一张图说清这个结构：
7.4 第四步：为「不确定」设计一个专门出口
系统必须有能力说「我不知道」，而且这条路径必须有人接。三条设计要求：不确定的输出格式和确定的不一样（别用同一个界面、同样的语气展示）；不确定的那条要说明缺什么（「这封邮件没有订单号，无法判断金额档位」比「置信度低」有用得多）；不确定的那批单独统计（每周看比例和构成，这是下一版最好的素材）。
八、上线之后：持续评估
8.1 四个阶段的节奏
| 阶段 | 跑什么 | 频率 | 触发什么 |
|---|---|---|---|
| 开发期 | 完整评估集 | 每次改动都跑 | 分数掉了就回滚 |
| 上线前 | 完整评估集 + 保留集 50 条 | 一次 | 保留集分数比评估集低 5 个点以上 = 过拟合了，别上 |
| 灰度期（头两周） | 每天从真实流量抽 30 条人工抽检 | 每日 | 见下方告警 |
| 稳态期 | 每周从真实流量抽 100 条，judge 跑批 + 人工复核 20 条 | 每周 | 见下方告警 |
把评估集跑批做成 CI 的部署门禁（改动 → 自动跑评估 → 分数不达标不许合并 / 不许上线），是目前把 Eval 变成真正闸门的最有效工程做法。[5] 能接 CI 的工具见 06 · Eval 与观测工具。
8.2 三条告警线（写死，别靠感觉）
- 周准确率相对上线时下跌 5 个百分点 → 当周排查。最常见的原因不是模型退化，是输入分布变了（新业务、新活动、新客户群）。Eugene Yan 举过一个例子：Voiceflow 的意图分类评估 harness 曾捕捉到模型升级后 10% 的性能下降——评估集的作用之一就是接住上游变化。[16]
- 任何一条 L3 红线被触发一次 → 立即人工介入，当天复盘。红线的容忍度是零。
- 「不知道」的比例连续两周上升 → 现实里出现了评估集没覆盖的新情况。这是最有价值的一条告警，因为它在你出错之前就报了警。
8.3 评估集要跟着长
Braintrust 的实践文章里有一条经验值得记：只靠合成数据集不够，需要持续把生产环境的真实 trace 补进评估集；一个健康的评估体系应该做到——新模型发布后，团队能在 24 小时内判断要不要换。[17]
配套的一条纪律是口径要写下来。「解决率 86%」这句话，如果答不出下面三个问题，它就是一个没有意义的数字：
- 分母是什么？（全部对话？还是 AI 尝试回答的那部分？）
- 判定窗口多长？（当场？24 小时内？）
- 谁来判定？（用户点了满意？还是没有再追问？还是人工抽检？）
8.4 一个额外收益
当你的 Eval 能可靠判定「这一条处理得对不对」，你就同时拥有了一个可以按结果计费的基础。这一点在谈第二个场景、第三个场景的资源时会变成筹码——你不再是在要预算，你是在报价。相关内容见 算账与扩展。
九、中文场景特有的四个难题
| 难题 | 为什么在中文企业里更严重 | 怎么破 |
|---|---|---|
| 业务专家不愿标注 | 标注被视为「替 IT 干活」，不进考核 | 拆小（三次每次 100 条）；每轮标完第二天告诉他「您标的这 100 条里，系统在第 3 类上错了 8 条，改完剩 2 条」；标注标准文档署他的名；把说法从「请您帮忙标数据」换成「这套系统按谁的标准干活，得由您来定」 |
| 领导要看 100% | 「有错就不能上」是很多管理者的默认立场 | 不要争辩准确率，改成拆两个数：「命中高置信的这 62%，准确率 96%；其余走人工，跟现在一样。所以这个系统只可能比现在好，不可能比现在差。」把它从「会不会错」的问题，变成「要不要让人少干 62% 的活」的问题 |
| 行业黑话、方言、错别字 | 中文行业术语与口语的密度极高，模型先验知识接近零 | 「垃圾样本」和「边界样本」的比例要比英文场景更高；judge 的判定规则里显式列出黑话对照表（见第六节骨架的第 4 条） |
| 新场景没有历史数据 | 很多流程本来就没系统，数据在纸上和人脑里 | 用 判断卡反向构造：每张卡的「现象」造 5 条，「什么情况下这个判断是错的」造 5 条 |
如果四条办法都用了业务专家仍然不配合，这本身是一个重要信号：他大概率就是那个「被动了奶酪」的人。这个信息比评估集更重要，回 需求发现与问题定义 处理。
十、常见误区
- 「先做出来，效果好了再补 Eval」。 这保证你在没有尺子的情况下改两个月，而且事后补的 Eval 会不自觉地照着现有系统的长处来设计。
- 「用通用 benchmark 代替业务评估」。 MMLU、ROUGE、BLEU 衡量的不是你的业务。Eugene Yan 给了更细的建议：分类任务用 Recall / Precision / ROC-AUC / PR-AUC，并提醒「一个模型可以有很高的 ROC-AUC 和 PR-AUC，却仍然不适合上生产」；摘要类通用指标大多不可靠，用微调过的 NLI 模型测事实一致性更实在；翻译已不推荐 BLEU，改用 chrF / BLEURT / COMET。[16]
- 「一致率 91% 就万事大吉」。 剩下 9% 要逐条看——judge 错了、标注错了、还是规则有歧义。这一步没法自动化，也是这一站最长本事的地方。
- 「评估集越大越好」。 分层的 200 条胜过随机的 2000 条。
- 「Eval 分数就是业务价值」。 准确率涨 5 个点，业务指标可能一动不动——瓶颈在采纳或流程。连接见 上线与采纳 和 算账与扩展。
最后一条不是技术问题。 这一页所有的方法、模板、提示词，都可以被一个想糊弄的人绕过去：偷看保留集、删掉不好看的那次跑批、事后调标准。Eval 最终考的是你愿不愿意在没有人监督的时候，把一个对自己不利的数字留在报告里。
延伸阅读
- Context 工程 — 判断卡的最后一列如何变成边界样本；红线清单从哪里来
- 需求发现与问题定义 — 场景的「错了会怎样」那一格决定 Eval 有多严
- 造与 MVD — 评估集如何作为迭代的方向盘
- 算账与扩展 — Eval 分数与业务指标之间的距离
- 05 · 从 demo 到生产 — Eval 门禁在生产化检查单里的位置
- 06 · Eval 与观测工具 — 具体的 eval 框架、trace 与 guardrail 工具，含一条全免费的最小可行流程
- 00 起点 · 术语表 — Eval、judge、人类基线、kappa 的定义
- Hamel Husain, "Your AI Product Needs Evals" — 英文圈这一话题的起点文章，短且密
- Hamel Husain & Shreya Shankar, "A Field Guide to Rapidly Improving AI Products" — 讲错误分析怎么做，含可复现的案例数字
- Anthropic, "Demystifying evals for AI agents" — 2026 年 1 月，针对 agent 场景，给了很低的起步门槛
来源
- Hamel Husain, "Your AI Product Needs Evals", 2024-03-29. https://hamel.dev/blog/posts/evals/
- OpenAI,
openai/evals开源仓库 README. https://github.com/openai/evals - Anthropic, "Define success criteria and build evaluations", Claude Docs. https://platform.claude.com/docs/en/test-and-evaluate/develop-tests（页面未标注发布日期）
- Anthropic, "Demystifying evals for AI agents", 2026-01-09. https://anthropic.com/engineering/demystifying-evals-for-ai-agents
- Interview Kickstart, "Forward Deployed Engineering" 课程大纲（W14 "SoW writing with eval-anchored acceptance criteria"、W17 "Eval suites as a CI deploy gate"），抓取日期 2026-09-01. https://interviewkickstart.com/courses/forward-deployed-engineering
- Ajay Agrawal, Joshua Gans, Avi Goldfarb, "A Simple Tool to Start Making Decisions with the Help of AI", Harvard Business Review, 2018-04-17. https://hbr.org/2018/04/a-simple-tool-to-start-making-decisions-with-the-help-of-ai
- Hamel Husain, "A Field Guide to Rapidly Improving AI Products", 2025-03-24. https://hamel.dev/blog/posts/field-guide/（同步刊于 O'Reilly Radar）
- Eugene Yan, "AlignEval: Building an App to Make Evals Easy, Fun, and Automated", 2024-10. https://eugeneyan.com/writing/aligneval/
- Evan Miller / Anthropic, "A statistical approach to model evaluations", 2024-11；论文 "Adding Error Bars to Evals", arXiv:2411.00640. https://www.anthropic.com/research/statistical-approach-to-model-evals ｜ https://arxiv.org/abs/2411.00640
- Landis, J.R. & Koch, G.G., "The Measurement of Observer Agreement for Categorical Data", Biometrics 33(1), 1977.（kappa 分级判读的经典出处；不同来源标注的页码有 159–174 与 150–174 两说，【页码待核实】）https://pubmed.ncbi.nlm.nih.gov/843571/
- Lianmin Zheng et al., "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena", arXiv:2306.05685, 2023-06；NeurIPS 2023. https://arxiv.org/abs/2306.05685
- Eugene Yan, "Evaluating the Effectiveness of LLM-Evaluators (aka LLM-as-Judge)", 2024-08. https://eugeneyan.com/writing/llm-evaluators/（文中 position / verbosity / self-enhancement bias 的具体百分比转述自来源 11 的论文，引用具体数字时建议回原论文核对）
- OpenAI, "Graders", OpenAI 平台文档. https://developers.openai.com/api/docs/guides/graders
- Hamel Husain, "Using LLM-as-a-Judge For Evaluation: A Complete Guide"（原标题 "Creating a LLM-as-a-Judge That Drives Business Results"）, 2024-10-29. https://hamel.dev/blog/posts/llm-judge/
- Shreya Shankar, J.D. Zamfirescu-Pereira, Björn Hartmann, Aditya G. Parameswaran, Ian Arawjo, "Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences", arXiv:2404.12272, 2024-04；UIST 2024. https://arxiv.org/abs/2404.12272
- Eugene Yan, "Task-Specific LLM Evals that Do & Don't Work", 2024-03. https://eugeneyan.com/writing/evals/
- Braintrust, "Five hard-learned lessons about AI evals". https://www.braintrust.dev/blog/five-lessons-evals（页面未标注发布日期）
另需说明：OpenAI 平台侧的 Evals 产品页面（https://developers.openai.com/api/docs/guides/evals）截至 2026 年 9 月挂有弃用通知——对现有用户将于 2026-10-31 变为只读，2026-11-30 关停。开源仓库
openai/evals未见弃用提示。选型时请以官方最新公告为准。