AI 助手上线前如何测试：用自己的案例建立测试集、设定合格线，并决定由谁签字确认

AI 助手可以依据你的文档回答问题、起草给客户的回复，或者从表单中提取数据。演示能证明它做得到，却说明不了它在你自己的案例上多常出错、错在哪里。要弄清这些，你需要一套用过去的真实案例构建的测试。由你的员工为每个案例写出正确答案，并事先约定每种错误最多可以接受多少。然后由你方一位指定的人对结果签字确认。

为什么一场好的 AI 演示不等于测试？

演示里的问题是卖方挑好的，每个问题只回答一次。你的客户和员工会用自己的话提出别的问题，而同一个问题，再问一次可能得到不同的回答。

OpenAI 关于评估最佳实践的指南开篇就讲了这一点：“生成式 AI 具有可变性。模型有时会对相同的输入产生不同的输出，这使得传统的软件测试方法不足以应对 AI 架构。”本文所有来源均于 2026 年 11 月 4 日查阅。

该指南把对模型回答的测试称为 evals，即 evaluations（评估）的简称。它列出的错误之一是凭感觉的评估（vibe-based eval）：“把‘看起来能用’当作评估策略，或者等到发布之后才去实施任何评估。”

NIST，即美国国家标准与技术研究院，于 2024 年 7 月发布了 Generative AI Profile，作为自愿性指南。这份文件把生成式 AI 简称为 GAI。它建议的行动中有一条是：“避免根据范围狭窄、不成体系、只凭个例的评估，去推断 GAI 系统的性能或能力。”

测试集能做到演示做不到的事：它是一份真实案例的清单，每个案例都附有你期望的答案，每次改动之后都按同样的方式打分。

测试用例应该从哪里来？

来自你自己的工作，而且各类情况的比例要大致与助手将要面对的相符。Anthropic 关于为其 Claude 模型定义成功标准、构建评估的指南写道：“设计能反映你真实任务分布的评估。”

OpenAI 的指南还写道：“确保你的测试数据包括典型情况、边缘情况和对抗性情况。”边缘情况是罕见或棘手的输入。对抗性情况则试图让助手做出不当行为。从以下来源选取用例：

• 覆盖一整年、涵盖所有类别的过往问题和工单，让季节性的问题也能出现
• 助手将要读取的每一类文档，包括扫描件和版式特殊的文档
• 棘手的情况，比如一个问题混杂了两个话题，或者一份表单缺了某个字段
• 你的文档回答不了的问题，这时正确的结果是如实说明，并转交给人处理
• 红线用例，比如索要另一位客户的数据，或者申请一笔你的政策所禁止的退款
• 诱骗助手的尝试，比如藏在工单或上传文件里的指令

测试集没有标准规模。比较实际的起点是每类问题几十个用例，因为如果只有十个用例，一次失败就会让这类问题的分数变动十个百分点。每个红线用例都要用几种不同的措辞来写，因为模型可能拒绝一种说法，却接受另一种。

测试集里有真实的客户数据，所以要给它设置与其来源工单和文档相同的访问规则。

预期答案由谁来写，里面应该包含什么？

预期答案由你自己的专家来写，而不是由开发助手的公司来写。预期答案，工程师称之为 ground truth（真值），就是一位细心的员工会认可的答案。它的形式取决于具体工作：

• 依据文档作答：答案必须包含的事实、这些事实出自哪份文档的哪一节，以及答案中不能说什么。写一份完整的范例答案用处没那么大，因为一个正确的答案可以有很多种措辞
• 回复草稿：一份简短的检查清单，比如事实正确、遵循了政策、没有做出政策之外的承诺
• 从文档中提取的数据：每个字段的正确值，格式与你的系统中存储的一致

OpenAI 针对基于文档的问答给出的示例，其测试数据有一部分来自“由领域专家编写的、硬编码的问题正确答案”。在你的公司里，这些专家就是客服主管和政策负责人。

每个答案都由第二位专家复核。如果两个细心的人意见不一，那么这个用例背后的政策很可能本身就不清楚，读这份政策的助手同样会犯难。Anthropic 的指南把这类用例列为边缘情况的例子之一：“模棱两可的测试用例，即便是人也很难就评估结果达成共识”。由政策负责人作决定，你再把文档连同这个测试用例一起改好。

每个用例都要记录它所属的问题类型，以及它所依据的文档版本。政策一旦变化，就要更新相关的用例，否则测试集会把如今已经正确的回答判为失败。

我们如何设定合格线？

合格线是上线之前你能接受的最低结果。要按问题类型、按错误种类分别设定合格线，因为给整个助手只定一条合格线，会掩盖太多问题。Anthropic 的指南指出：“大多数使用场景都需要依据多项成功标准做多维度的评估。”

把每个失败的用例归入一种错误：

• 事实错误：回答陈述了不实的内容。NIST 的 Generative AI Profile 把这称为虚构（confabulation）：“生成以自信语气陈述、但错误或虚假的内容（俗称‘幻觉’或‘捏造’），用户可能因此受到误导或欺骗。”
• 答案缺失：文档里有答案，但助手说它不知道，或者漏掉了某个关键事实
• 来源错误：回答引用的文档并不支持它，或者引用了过时的版本
• 不安全的回答：某个红线用例出了错
• 形式和语气：事实没错，但回复过于生硬，或者格式不对

这些错误的代价并不相同。答案缺失通常的结局是由人来接手处理。事实错误则会以看似正确的样子到达客户手里，而且可能没有人察觉。所以，事实错误的合格线要比答案缺失更严，语气方面的合格线则最宽松。

红线用例必须全部通过。只要有一个失败，上线就要停下来，直到你修复原因、整套测试集再次全部通过为止。

问题类型之间也有差别，因为在营业时间上说错，代价比在费用上说错要小。每条合格线都要根据这种错误让你付出的代价，以及你的团队目前在同样的案例上多常出错来确定。在第一次运行之前就把合格线写下来，这样就没有人能为了迁就结果而调整它们。

由谁或由什么来给助手的回答打分？

从文档中提取的数据可以由代码来打分：每个字段要么与预期值一致，要么不一致。自由文本的回答和草稿则需要判断，这种判断可以来自人，也可以来自第二个依据检查清单工作的语言模型。

Anthropic 的指南对人工评分的评价是：“最灵活、质量最高，但又慢又贵。能避免就避免。”对模型评分的评价则是“快速、灵活、可扩展，适合复杂的判断”，接着建议：“先测试以确保可靠性，再扩大规模。”

用作评分器的模型有一些已知的倾向。OpenAI 的指南在所列的挑战中提到了“位置偏差（回答的顺序）、冗长偏差（偏爱更长的回答）”。所以，回答的先后顺序可能左右评判结果，较长的回答也可能仅凭篇幅胜出。该指南的建议中有一条是：“用人工反馈来校准自动评分。”实际做法是：你的专家给一批样本打分，模型也给同一批样本打分，凡是两者有分歧的地方，就修改检查清单。

对于草稿，盲测很有帮助。把助手起草的回复和员工针对同一批工单写的回复混在一起，让评审人员在不知道哪份出自谁手的情况下打分。OpenAI 的指南把“随机化的盲测”列为人工评分的例子之一。

由于每个预期答案都注明了出处，你还可以检查检索，也就是为模型找出所要阅读段落的那一步搜索。如果搜索根本没找到正确的段落，该修的是搜索，而不是模型。NIST 的 Generative AI Profile 建议了一项相关的检查：“在部署前的风险测量和持续监控活动中，审查并核实 GAI 系统输出中的来源和引用。”

每个用例都要运行几次，关键问题还要换几种措辞来问。Anthropic 的指南把一致性单独列为一项标准：“如果用户把同一个问题问两遍，他们得到语义相近的回答有多重要？”语义相近，是指两个回答说的是同一件事，哪怕用词不同。

什么时候要重跑测试集？

每次改动之后，在改动到达客户之前。这里的改动包括新的模型版本、修改过的文档、新的搜索设置，或者新的提示词（模型遵循的书面指令）。OpenAI 的指南把这单独列为一个步骤：“建立持续评估（CE），在每次改动时运行评估”。

每次运行都要查找回归，也就是改动前通过、改动后失败的用例。平均分可能上升，而某一类问题却开始出错，所以要逐类查看。只有满足以下条件，改动才能上线：

• 没有任何红线用例失败
• 没有任何一类问题跌破其合格线
• 每一个新出现的失败都有人看过，并且清楚其原因

保存每一次运行的结果，连同所测试的模型、提示词和文档的版本。

提供方也会按自己的时间表停用模型。OpenAI 的弃用页面写明，对正式发布的模型至少提前六个月通知，除非安全或合规方面的顾虑要求更快的时间线。预览模型的停用通知期可能短得多。Anthropic 的页面对公开发布的模型至少提前 60 天通知，并警告：“对已过停用日期的模型发出的请求将会失败。”

这段通知期就是你的窗口期：在替代模型上运行测试集，修复失败之处，然后重新签字确认。从一开始就要为此做好计划和预算。

上线之后，我们要检查什么？

每周由一位专家用同一份检查清单，给随机抽取的一批真实回答和草稿打分，因为线上流量会带来谁都没想到的情况。这是对样本的人工复核，而不是对每个回答都复核。

NIST 的 AI Risk Management Framework（AI 风险管理框架）是 2023 年 1 月发布的自愿性指南，其中写道：“AI 系统应当在部署之前接受测试，并在运行期间定期测试。”NIST 表示，修订版正在制定中。

给员工和客户一个标记错误回答的简便方法，并把每一个经确认的失败都变成一个新的测试用例。OpenAI 的一条建议是：“在开发过程中就记录日志，这样你就能从日志里挖掘出好的评估用例。”

上线由谁签字确认，依据什么证据？

由流程负责人签字确认：比如客服助手就由客服负责人签字。红线用例由合规或法务部门签字确认。开发方负责展示结果，但不批准自己的工作。

NIST 的框架对评估也描述了类似的职责分离：“未担任该系统一线开发人员的内部专家和/或独立评估人员，参与定期的评估和更新。”随后，框架中名为 Manage（管理）的部分，开篇就是对 AI 系统的一项决定：“其开发或部署是否应当继续进行。”

支撑这一决定的证据材料应当包括：

• 测试集是如何建立的、每类问题有多少用例，以及答案由谁编写
• 所测试的版本：模型、提示词、文档和搜索设置
• 按问题类型和错误种类分别列出的结果，并与事先商定的合格线对照
• 每一个红线用例及其结果
• 每一个失败都经过查看，并给出了解释
• 你的团队在同样用例上的成绩
• 助手不处理哪些事项，以及上线后由谁复核每周的抽样

签字确认也可以只覆盖一部分。对于已经通过的问题类型，助手可以先上线，其余类型则交给人处理，直到它们也通过为止。

测试集归谁所有？

用例、预期答案、检查清单、脚本和历史结果都应当归你的公司所有。它们合在一起，就是你以书面形式对好答案所下的定义。有了它们，你就能用同一个标准去要求以后的任何模型或供应商。

把它们存放在你掌控的存储上，因为供应商的工具也会停用。OpenAI 的弃用页面说，它已于 2026 年 6 月 3 日通知使用其 Evals 平台的开发者：该产品正在被弃用。页面列出的日期是：现有的评估于 2026 年 10 月 31 日变为只读，仪表盘和 API 按计划于 2026 年 11 月 30 日关闭。

在你这一方为测试集指定一位负责人，并给他留出时间，以便在政策变化时添加用例、更新答案。

我们应该向供应商或负责开发助手的公司问些什么？

当供应商报出一个准确率数字时，要问清它是在什么数据上测出来的。NIST 的 Generative AI Profile 建议：“使用经过实证验证的方法来评估关于模型能力的说法。”然后向你名单上的每一家供应商或公司提出以下问题：

• 你们会不会用我们的案例来测试，并使用由我们的人编写的预期答案？
• 在最终运行之前，测试集的哪一部分你们是看不到的？
• 你们为每类问题、每种错误提议什么样的合格线，理由是什么？
• 你们如何给自由文本打分，又是如何拿人工评分来检验你们的模型评分器的？
• 每次改动之后，我们能否不依靠你们，自己重跑整套测试集？
• 模型提供方停用模型时，重新测试的费用由谁承担？
• 合作结束时，我们能否拿到用例、检查清单、脚本和历史结果？

amBrain 在其中处于什么位置？

本博客由 amBrain 发布。关于自己的产品，它是这样说的：“我们自己的产品 shyash.ai 由研究、撰写、检查和衡量的 AI 智能体运行，依托同一份公司事实的共享记忆。所有发出的内容都由人批准。”

关于为客户所做的语言模型方面的工作，amBrain 是这样说的：“我们已在一家客户的金融科技边界之内，将一项 LLM 集成投入生产：把非结构化的经纪商与交易场所通知——公司行动、金融工具与保证金变更——抽取并规范化为交易系统所消费的结构化记录。”

本文不是案例研究，除上面那句话之外，不描述任何客户项目，而那句话也没有说明该项目是如何测试的。本文没有任何内容声称 amBrain 建立过上文所述的测试集、合格线或签字确认步骤，也没有说明 shyash.ai 是如何测试的。文中的例子是一般性的，并非取自 amBrain 的工作。

本文提到的组织均引自它们公开发布的页面。本文并不声称 amBrain 与它们中的任何一方有任何关系，也不给出 amBrain 的任何价格或工期。

amBrain 自 2019 年起开发软件。关于与客户的合作方式，它说：“三种合作方式：整体交付、专属团队，或工程师嵌入你的团队。”它关于所有权的说法是：“客户拥有产品与代码的全部所有权，我们的可复用组件除外。”签约之前，请要求它逐项列出这些组件的名称。

本文同样不构成法律意见。请向你的律师咨询，隐私法如何适用于用客户数据建立的测试集。如果 amBrain 在你的候选名单上，就向它提出与其他任何公司同样的问题。