为非确定性 AI 功能编写验收标准

你的工程团队已经开发文档摘要生成器三个月了。规范要求：“摘要生成器应返回准确的摘要。”你发布了它。用户抱怨摘要有一半时间是错误的。事后分析显示，在发布前没有人能以可测试的方式定义“准确”的含义。

这是 AI 功能开发的标准轨迹，之所以会发生，是因为团队将为确定性软件构建的验收标准模式，套用到了本质上是概率性的系统上。由 LLM 驱动的摘要生成器没有单一的“正确”输出 —— 它有一系列的输出分布，其中一些是可以接受的，另一些则不然。二元的通过/失败规范无法映射到分布上。

这个问题不仅是哲学上的，它还会导致切实的痛苦：功能发布时质量门槛模糊，回归测试在用户发现之前难以察觉，产品和工程团队在功能是否“完成”上无法达成一致，因为没有人规定对于随机系统来说，“完成”意味着什么。这篇文章将介绍真正有效的模式。

为什么“应返回准确结果”不是一个规范

传统的验收标准源于一个系统要么执行、要么不执行的世界。给定一个有效的 HTTP 请求，端点返回 200。给定一个特定的输入，函数返回预期的输出。这些规范直接转化为产生二元结果的自动化测试。

由 LLM 驱动的功能并非如此工作。同一个问题问两次，你可能会得到两个不同的答案。问一千次，你会得到一个分布。在该分布中，有些回答是好的，有些是坏的，大多数处于中间位置。问题不在于该功能是否返回了正确的结果，而在于在什么条件下，多大比例的结果是可以接受的，以及随着输入分布的变化，这个比例如何维持。

“准确”也存在定义问题。对于摘要生成器来说，准确是指与源文档的事实一致吗？简洁吗？涵盖了要点吗？没有幻觉出原文中没有的细节吗？这些标准中的每一个都是不同的维度，每个维度的测量方式也不同，而且它们有时会发生冲突。简洁的摘要可能会忽略细微差别；完整的摘要可能会包含用户不需要的材料。将所有这些都归结为“准确”，会导致团队中的每个工程师产生不同的理解。

第一步是分解：将针对特定功能的“好”定义分解为不同的、可衡量的维度。摘要生成器的规范可以将事实一致性（无幻觉主张）、覆盖率（包含关键点）、简洁性（源文档低于 2,000 字时，摘要低于 150 字）和语气（中性、专业）分开。每个维度都需要自己的标准和测量方法。

评估阈值合约 (Eval Threshold Contracts)

一旦有了可衡量的维度，你就可以编写评估阈值合约 —— 这是验收标准的 AI 模拟物。其结构是：这个指标，通过这种方式测量，在这个测试集上，应该以这种置信度达到这个阈值。

一个具体的例子：“事实一致性得分，通过使用 LLM 评委将提取的主张与源文档进行交叉引用来衡量，在包含 200 个示例的黄金数据集上应超过 0.85，且 95% 置信区间的下限应高于 0.82。”

该合约指定了你要测量的内容（事实一致性）、方式（基于 LLM 的主张提取和验证）、数据（固定的黄金数据集）、通过阈值（0.85）以及可接受的不确定性（置信区间下限高于 0.82）。工程师可以实现这个测试，在 PR 上运行它，并获得清晰的信号。

阈值水平取决于上下文。法律文档审查工具需要事实一致性高于 0.95，且置信区间较窄。用于总结会议记录的内部工具可能接受 0.80。重要的是，阈值是明确的，在开发开始前就已写下，并在发布前由产品和工程团队达成一致，而不是在收到投诉后才进行争论。

统计校准在这里非常重要。在 20 个示例上设置 0.90 的阈值意义不大 —— 置信区间太宽，以至于你无法判断你的功能是 0.85 还是 0.95。实际指导建议：对于失败成本较高的功能，使用 300-500 个示例并使用自助法（bootstrap）计算置信区间。对于低风险的内部工具，可以使用 50-100 个示例，并明确承认你接受了更多的不确定性。样本大小的选择应作为权衡后的深思熟虑被记录下来，而不是含糊处理。

错误预算（Error budgets）与阈值配合得很好。与其将规范定义为“必须达到 0.90”，不如将其定义为“在最多 10% 的情况下允许失败”。这种框架自然地映射到运维思维中 —— 已经习惯于使用运行时间错误预算的团队会发现，将相同的概念应用于 AI 功能质量是非常直观的。

基于示例的行为规范

阈值合约能告诉你某个功能何时在整体上通过，但它们无法告诉你哪些行为是必须的或被禁止的。基于示例的规范通过将需求锚定到特定实例来填补这一空白。

一个客户支持机器人的行为规范可能如下：给定一条包含取消请求的消息，响应必须确认该请求，确认取消流程，且不得向上下文中标记为高流失风险的用户提供留存折扣。这是一个具体的、可测试的行为 —— 你可以运行它，根据标准评估输出，并得到一个明确的答案。

黄金数据集大规模地编码了这些示例。一个构建良好的黄金数据集涵盖了预期的输入分布（常见情况）、边缘情况（罕见但重要）、对抗性案例（旨在破坏功能的输入）以及边界条件（功能可能失效的决策边界附近的情况）。每个示例都应有明确的预期行为 —— 不是单一的正确输出，而是一组任何可接受的输出都必须满足的标准。

构建一个有用的黄金数据集需要大多数团队都会跳过的自律。数据集应该在你最终确定功能之前构建，而不是从已有的实现中逆向推导。它应该至少由功能团队以外的一个人审核，以捕捉团队潜意识中带入的假设。它应该包含从实际用户分布中提取的案例，而不仅仅是团队觉得容易编写的案例。此外，随着生产环境中发现新的失败模式，它应该随时间不断增长。

黄金数据集中最有价值的示例是对抗性案例。这些是专门设计用来暴露失败模式的输入：触发幻觉的边缘情况、利用设计不佳的标准进行博弈的输入、功能在技术上正确但在实际中毫无用处的案例。对抗性示例很难系统地生成 —— 最好的方法是将人工红队测试与自动化扰动（转述输入、替换实体、重新排序上下文）相结合，以找到功能崩溃的边界条件。

在不假装 AI 是确定性的情况下定义“完成”

上述验收标准模式为你提供了可以写在工单上的具体内容。但还存在一个更大的流程问题：构建 AI 功能的团队通常不知道何时可以发布，因为他们缺乏关于“完成”的共同思维模型。

确定性功能有一个明确的定义：所有测试通过，所有验收标准满足，即告完成。AI 功能需要一个更细致的模型，因为你总是在覆盖范围、置信度和成本之间进行权衡。更多的示例意味着更好的置信度，但评估成本更高。更严苛的阈值意味着更少的回归，但开发周期更长。一个 0.92 的功能可能已经好到可以发布；一个 0.89 的功能可能值得再次迭代 —— 但只有在你开发前而非开发后就阈值达成一致，这些数字才有意义。

一个实用的做法是在开发过程中定义三个检查点。第一个是最低可行质量基准 —— 无论进度压力如何，你都不会发布的底线。这会被写入规范。第二个是目标质量基准 —— 你在现有时间和资源下追求的目标。第三个是理想基准 —— 用于未来的迭代。写下这三个基准可以防止常见的失败模式：即当所有人都以为是在追求目标质量时，团队却以最低可行质量发布了产品。

发布后的质量也应提前规定。AI 功能的退化方式与传统功能不同：随着用户发现使用产品的新方法，输入分布会发生偏移；数据源会过时；模型行为会随着供应商的更新而漂移。规范应包括监控阈值 —— 降至该质量水平以下时，功能将被撤回或优雅降级 —— 以及评估频率（每周针对黄金数据集运行评估，每月审查生产样本）。

在实践中有效的测量方法

你主要有三种工具来衡量 AI 功能的质量：自动化无参考指标、LLM-as-judge 评估和人工评分。每种工具都适用于流程的不同阶段。

自动化无参考指标既快速又便宜。ROUGE、BERTScore 和类似的指标在不需要基准参考的情况下测量输出属性（长度、词汇量、语义相似度）。它们对于捕捉极端情况下的回归非常有用 —— 例如输出过短、语义不连贯或与历史基准截然不同的情况。但对于细微的质量问题，它们提供的信号较弱，并且可能会被那些学会了刷高分但在实际表现中并不出色的功能所利用。应将它们作为 CI 中的快速门禁，而不是主要的质量信号。

LLM-as-judge 评估使用另一个模型根据评分量表对你的功能输出进行打分。如果做得好，它与人类判断的一致性可达 80-85%，并且能以低成本扩展到数千个示例。如果做得不好，它会引入系统性偏差，从而削弱质量信号 —— 模型更倾向于较长的输出，更倾向于符合自己风格的输出，并且在训练分布之外（如医疗和法律领域是常见的失败点）表现较差。关键实践包括：使用比生成模型能力更强的评委模型；提供带有示例的详细评分量表，而不是仅要求给出一个简单的数字评分；要求评委在评分前解释其推理逻辑；并在生产环境中信任评委之前，先在校准集上针对人工评分验证评委的准确性。

人工评分仍然是最终的标准参考。你无法完全避开它 —— 你的黄金数据集需要人工标注的示例，你的 LLM 评委需要一个带有历史人工标签的校准集，并且对生产样本的定期审计也需要人工审核。目标是在最关键的地方（校准、高风险边缘情况、黄金数据集构建）使用人工评分，而在其他地方实现自动化。

对于规范中的每个维度，在编写阈值之前选择合适的测量工具。“事实一致性”需要一个能够针对源文档核实主张的评委 —— 简单的嵌入相似度指标无法捕捉到幻觉出的专有名词。“响应简洁度”可以通过计算单词数自动测量。“语气适当性”则需要人工评分员或经过良好校准的评委。测量方法是规范的一部分，而不是留给团队决定的实现细节。

组织层面的问题

AI 验收标准的大多数摩擦并非源于技术，而是组织架构问题。产品经理使用确定性软件的词汇编写需求文档（Spec），因为那是他们熟悉的领域。工程师接受模糊的文档，因为他们习惯在实现过程中解决质量问题。双方都没有一套讨论概率性质量（Probabilistic Quality）的通用框架，因此质量决策是在含糊且不一致的情况下做出的。

解决方案是让需求模板显式化。能够可靠交付 AI 功能的团队通常会使用结构化的文档格式，迫使质量问题在前期就得到解答。一个极简版本：针对每个面向用户的行为，明确 (1) 关注哪个维度的质量，(2) 如何测量，(3) 最低可接受阈值，以及 (4) 评估的样本量。这可能只需多花 30 分钟编写，却能节省上线后多轮的争论。

此外，将质量关卡（Quality Gate）与行为规范（Behavioral Spec）分离也有所帮助。行为规范描述功能应该做什么；质量关卡规定了发布的衡量阈值。只要两者都在开发开始前编写，而不是在实现后再推导，它们可以由不同的人负责——产品经理负责行为规范，工程团队负责质量关卡。

最难打破的模式是“事后设置阈值”：团队构建功能，在某些示例上测量质量，然后编写该功能已经通过的验收标准。这在 AI 领域等同于在写完代码后才编写测试——它无法验证任何东西。阈值需要在看到结果之前，根据具体用例实际所需的质量水平来设定，而不是根据当前实现所达到的水平来校准。

结论

非确定性 AI 功能需要与其概率本质相匹配的验收标准。这意味着将“好”分解为可衡量的维度，编写具有明确样本量和置信区间的评估阈值契约，在发布前构建涵盖真实输入分布的黄金数据集（Golden Datasets），并在开发前而非发布后就测量方法达成一致。

其基本原则与确定性软件的优秀文档编写一致：让标准足够明确，以至于两名工程师在独立阅读后，会对功能是否通过做出相同的判断。不同之处在于，对于 AI 功能，“相同的判断”意味着就统计阈值及其测量方式达成一致——而不是对确切的输出结果达成一致。

做到这一点的团队在交付 AI 功能时争论更少，能更早发现回归问题，并避免以“我们以为它工作正常”开头的复盘。投入被前置到了需求定义阶段，而这正是成本最低的地方——而不是在发布时才发现问题，那时的代价最高。