# 答应客户“永远不出错”，AI 项目就会输在验收

> 错多少是产品决策：写代码前就和客户约定哪些错误可以接受、在哪套数据上衡量。

原文: https://fdetimes.net/zh/guides/define-ai-acceptance-criteria-with-clients/

设想这样一个场景：你和一家物流公司第二次开会。对方想用 LLM 自动分类投诉邮件，运营负责人用一句话概括了需求：“分类每次都必须正确，不能出错。”

如果你点点头就回去写代码，这个项目多半已经失败了。三个月后验收时，只要有一封邮件分错，客户就可以说系统没达到要求，而你手里没有任何书面约定能反驳。

对前线部署工程师（FDE）来说，AI 项目最难的往往不是提示词，也不是数据管道。系统注定会出错，在这个前提下，怎样和客户就“成功”的含义达成一致，才是最难的。本文讲的就是怎样在写第一行代码之前做到这一点。

## 为什么“永远正确”不是标准

软件工程师习惯了单元测试：测试变红就是 bug，有 bug 就要修。Hamel Husain 为团队提供 LLM 产品评测方面的咨询，他指出 LLM 评测不同：评测套件不必 100% 通过。OpenAI 的评测指南也提到，正是因为 AI 系统具有不确定性，才需要评测。

Husain 更重要的观点是：需要多高的通过率是产品决策，取决于你愿意接受哪些错误。所以客户说“不能出错”时，正确的回答不是“做不到”，而是接着问：哪些错误绝对不能接受，哪些可以容忍？

**要点:** AI 系统可以多久出错一次，是产品决策，不是技术决策。

Anthropic 关于成功标准的文档提出了四项要求：标准必须具体、可衡量、可实现、与场景相关。它举的例子很简短：不要写“性能良好”，要写“情感分类准确”。

“永远正确”在这四项里有两项不合格：在有限样本上没人能衡量它，也没有哪个模型能做到。

## 先读真实失败案例，再选指标

常见的做法是打开一份现成的指标清单，挑出准确率和 F1，也许再加一个“有用性”评分。Husain 提醒，这种自上而下的做法往往让人去衡量容易衡量的东西，而不是用户真正在意的东西。

他建议反过来做：先分析真实数据中的错误，再针对观察到的具体失败模式写测试。至于规模，他建议从约 100 条 trace 开始找错误。需要验证 LLM 评审（LLM judge）时，每种失败模式标注 100 到 200 个样例。

放到这家物流公司身上，就是请对方提供 100 封去除了个人信息的真实投诉邮件，用你的原型跑一遍，再和一位客服人员一起看结果。假设你们发现了三种失败模式。

第一，“延迟送达”邮件被归为“信息咨询”。第二，货物损坏的索赔邮件被归为“延迟送达”。第三，威胁采取法律行动的邮件没有升级给主管。

这三种失败的严重程度差别很大。把“延迟送达”和“信息咨询”搞混，客服花几分钟把邮件挪到正确的队列就行。漏掉一封法律威胁邮件，则可能演变成法律事件。单一的准确率数字掩盖的，恰恰就是这类信息。

## 一套验收标准示例

Anthropic 建议同时在多个维度上设定标准。其中一个维度是错误严重程度，例如“90% 的错误只是带来不便，而非严重错误”。

延迟也在清单上。在安全性方面，Anthropic 给出了一个数字明确的标准：在 10,000 次运行中，被内容过滤器标记为有害的输出少于 0.1%。

注意这条标准的写法：有阈值，有样本量，有衡量工具。邮件项目的标准也应该照这个模板写。下表中的数字仅作示例，实际要换成你和客户商定的数字：

| 维度 | 标准 | 衡量数据 |
|---|---|---|
| 整体分类 | 至少 92% 的邮件分到正确类别 | 500 封由客户确认标注的邮件 |
| 错误严重程度 | 至少 90% 的错误只是“分错队列” | 同一批 500 封邮件中的错误 |
| 法律威胁邮件 | 法律威胁测试集中的邮件一封不漏 | 150 封已标注的法律威胁邮件 |
| 延迟 | 邮件进入队列前完成分类 | 预发布环境日志 |

现在按第一行算一下。每天 1,000 封邮件，92% 的准确率意味着约 80 封分错。如果其中 90% 只是分错队列，每天还剩约 8 个严重错误。

你要摆到桌面上的问题是：“每天会有 8 封重要邮件分错。你们团队能接受吗？还是需要加一道人工审核？”

这个问题把一种模糊的担忧，变成了可以实际讨论的业务选择。它也符合 Husain 对通过率的看法：通过率是关于哪些错误可以接受的产品决策，所以客户方的产品负责人必须参与决定。

那“一封不漏”这一行呢？只有在范围窄、固定且足够大的测试集上，绝对阈值才有意义，这样结果才不是靠运气，比如示例表中的 150 封邮件。如果系统做不到，办法是加人工审核，而不是悄悄降低标准。

## 下一个项目的五个步骤

第一步：把每条模糊需求改写成带数字的句子。OpenAI 的指南在设计评测时也是从这个问题开始的：成功是什么样子？

第二步：要真实数据，和客户方的领域专家一起读约 100 条 trace。用他们的语言记录失败模式，而不是机器学习术语。

第三步：按严重程度给每种失败模式排序，再从准确率、严重程度、延迟和安全性等多个维度设定标准。

第四步：确认阈值可以实现。Anthropic 强调，指标不应超出当前前沿模型的能力，并且应以基准测试或你自己做过的实验为依据。做出承诺之前，先用原型在测试集上跑一遍，这样谈判时手里有基线数据，而不是凭感觉。

第五步：让客户签字确认标准，然后把评测自动化。OpenAI 建议建立持续评测，每次改动后都运行评测，并用人工判断来校准自动评分。

## 常见陷阱

第一个陷阱是把阈值从一个项目照搬到另一个项目。Anthropic 指出，引用准确性对医疗应用可能至关重要，对闲聊机器人则没那么重要。适合邮件分类的 92% 阈值，未必适合总结病历。

第二个陷阱是只有一个总体数字。准确率看起来不错，也可能藏着严重的失败模式。至少要有一条关于错误严重程度的标准，再为客户最担心的那种失败单独设一条。

第三个陷阱是自己挑测试集。如果标注是你做的，验收时客户就有理由不信任结果。请客户方的人确认标注，至少覆盖严重失败的测试集要这样做。

最后一个陷阱是把标准当成签一次就归档的文件。提示词会变，模型会变，输入数据也会变。只有每次变化后都重跑评测，标准才有意义。

在岗位描述中看到“define success metrics with customers”或“build evals”这类说法时，指的就是这项能力。简历上要写具体：商定了哪些阈值，在多少样本上衡量，客户根据这些数字做了什么决定。

本周练习：挑一个你正在做的 AI 功能，照上表写一套四行的标准，每行都有阈值、样本量和衡量方法。然后试着回答：“每天可以接受多少个严重错误？”如果答不上来，这就是下次开会要问客户的问题。

**本周动手试试:**

- 从你正在做的 AI 功能中取 100 条真实输出，逐条阅读，按失败模式给错误打标签。结束时统计哪种失败模式出现得最多。
- 把当前某个工单里的一条模糊需求，改写成带数字、测试数据集和错误阈值的标准。
- 把简历上的“构建了一个聊天机器人”，换成一句话：说明你如何与客户商定验收标准，并构建评测来检验。

## 信源

- [Define success criteria and build evaluations](https://platform.claude.com/docs/en/test-and-evaluate/develop-tests)

- [Your AI Product Needs Evals](https://hamel.dev/blog/posts/evals/)

- [Evals: Doing Error Analysis Before Writing Tests](https://hamel.dev/notes/llm/officehours/erroranalysis.html)

- [Q: How many examples do I need for an eval?](https://hamel.dev/blog/posts/evals-faq/how-many-examples-do-i-need-for-an-eval.html)

- [Evaluation best practices](https://developers.openai.com/api/docs/guides/evaluation-best-practices)