AI 评测分数如何成为可靠的发布门槛

AI 功能的评测通过率再高，也不能直接换成上线信心。原文提出五个问题：系统常在哪里失败，测试从哪里来，谁定义好答案，什么结果会阻止发布，以及线上故障怎样变成新用例。

作者的核心判断是：可信度来自评测与真实失败、业务标准、发布流程之间的联系。对正在做 AI 助手、知识库问答或 Agent 的团队，这套问法能帮助你判断，仪表盘上的绿灯究竟有没有用。

分数能不能信，先看它测过哪些失败

AI 评测（eval）要解决的问题很具体：同一个提示词，可能产生多个看似合理的答案，不能只靠演示成功一次来验收。它至少需要代表性输入、好答案的定义、评分器，以及提示词、模型或数据变化后重新执行的达标标准。

作者引用了 Atindriyo Sanyal 在 2025 年 1 月一次讨论中的比喻：当下的评测处境，类似于 1980 年代传统软件缺少配套工具的阶段。这是对行业成熟度的判断，并非实验结论。

落到团队管理，第一步是拿出真实输出做错误分析：哪里错了，各类错误出现多少，先修占比最大的类别。Hamel Husain 对通用仪表盘的批评也落在这里：指标如果无法对应产品里的实际失败，看起来持续上涨也未必有意义。

测试集是否包含已经发生的真实失败，比一个漂亮的总分更值得追问。

生产输入应该是测试集的重要来源，历史失败尤其需要留下记录。合成用例可以补覆盖缺口，但不能替代已经确认的线上问题；公开基准也需要搭配业务专属的私有测试。

Superhuman 的 CTO Loïc Houssier 举了一个邮件查询例子：计算上个月乘坐 Waymo 的总时长。它需要分别验证邮件检索、理解「上个月」、读取时长、累加结果。只给最终答案打分，可能知道它错了，却不知道该修哪一步。

谁定义了好答案，评分的人是否一致

作者的第三个问题是：谁决定答案合格，是否有懂业务的人签字认可？

可确定的要求适合用代码检查，例如 JSON 结构、引用有效性、长度。涉及质量判断时，可以使用另一个模型充当裁判，也可以让人工审查关键样本。但评分标准由谁编写、业务专家是否认可，都应该可追溯。

这对 AI 编程功能同样有用：输出满足格式要求，并不代表它完成了用户任务。团队需要先拆清评价维度，再为各个维度选择评分方式。

人工之间也可能意见不一致。原文建议，在实际交给人工或模型裁判评分的样本上，提供 Cohen's Kappa，或同类评分者一致性指标。它试图衡量扣除偶然一致后，评分者还剩多少一致程度。

只报「两个人大部分时候判断相同」不够。若一致性很弱，应先检查规则和标签，再信任总分。原文同时提醒，Landis 和 Koch 提出的常用一致性分档，其界线也带有任意性，不能当成天然的验收标准。

另一项必须讲清的取舍是 precision 和 recall。如果把「发现真实问题」视为正类，高 precision 对应较少误报，高 recall 对应较少漏掉真实问题。产品更怕误拦正常结果，还是更怕放过错误，需要业务判断。原文没有给出适用于所有产品的默认比例。

评测必须能阻止发布，也必须接住线上故障

第四、第五个问题把评测接进工程流程：每次变更是否重跑，什么结果会阻止发布，线上失败怎样进入测试集？

作者引用 Husain 在 2024 年文章中提出的三层安排：每次代码变更执行快速自动检查，按固定节奏进行人工和模型评审，较大产品改动之后进行 A/B 测试。成本不同，执行频率也不同。

这里有个容易混淆的地方：要求变更进入评测流程，不等于每次提交都跑全量人工审核。负责人至少要知道第一层检查在哪里，以及哪条数值或策略规则会阻止合并。

原文给出了一页报告模板，把这些要求变成可以审阅的材料：

## Eval report: [feature name] · [date]
Owner: [team/person]

## Scope
- Task: [one sentence]
- Dimensions (PM-signed): [bullets]

## Dataset
- N cases: [count] · Sources: [prod failures / support / synthetic]
- Last added prod failure: [date + ticket]

## Labels & scoring
- Rubric author + SME sign-off: [names]
- Scorers: [code checks / LLM judge / human sample]
- Inter-rater: κ = [value] on [n] items ([date])

## Failure taxonomy (from error analysis)
| Category | Share of failures | Top example id |
|----------|-------------------|----------------|
| ...      | ...               | ...            |

## Release gate
- Runs on: [every prompt change / every deploy / weekly]
- Ship if: [e.g. pass rate ≥ X on set Y; category Z = 0 failures]
- Blocked releases since [date]: [count + reason]

## Production loop
- Path from incident → new test case: [link to process]

最该检查的是 Ship if 这一行：pass rate ≥ X on set Y; category Z = 0 failures 只是规则示例，X、Y、Z 都要由团队填写，不能把占位符当成现成方案。

报告还要求记录最近加入的生产失败、真正阻止过的发布，以及事故转成测试用例的路径。它帮助负责人在十分钟内检查关键依据，并在评测变化时同步更新。上季度留下的一份静态材料，无法证明今天的系统仍然可靠。

我的判断

这篇最有价值的地方，是把「模型表现怎么样」推进到「团队凭什么批准发布」。它没有要求先采购平台，而是先交代样本来源、业务标准和阻断规则，小团队也可以从文档与现有流水线开始。

但这是一套治理建议，原文没有给出某个团队实施前后的故障率、成本或交付速度对照。它引用的专家经验能帮助确定检查方向，不能证明填完报告就能降低多少风险。

一页报告也只是入口。样本是否代表生产、错误分类是否准确、模型裁判是否稳定，都需要背后的记录支撑。原文要求提供一致性指标，却没有说清应抽多少样本、κ 达到多少才能上线；这些仍需结合任务决定。

和只跑公开榜单相比，私有用例更贴近业务，但维护成本也更高。和全靠人工验收相比，分层评测更容易持续执行，前提是团队愿意维护规则，并给关键问题留出人工复核时间。

能拿来做什么

• 给现有 AI 功能整理一页评测报告，写清测试集来源、最近一次真实失败和当前发布规则；缺失的证据直接标出来。
• 做知识库问答或邮件助手时，分别检查检索、时间理解、信息提取和结果汇总，并为高频失败保留可重复执行的用例。
• 在 Node 服务或 AI 编程流水线中，先接入 JSON 结构、长度等快速检查，再按固定节奏安排模型与人工评审，明确哪类失败会阻止合并。
• 每次处理线上事故，都记录从问题到新用例的负责人和路径；涉及主观质量时，抽取共同评分样本，先核对评分标准是否一致。