AI 项目怎么验收：测试集、准确率口径与转人工率

传统软件项目的验收相对明确：按需求清单逐项测试，功能能用就算通过。AI 项目不一样，同一个问题换种问法，回答可能就不同；今天测得好好的，知识库更新后可能又答错。如果合同里只写了「准确率达到 X%」而没有定义怎么测，验收时双方很容易各执一词。更好的做法是在项目启动时就把验收方法定下来。

一、验收标准要在开发前商定

AI 项目的验收标准至少要回答三个问题：

• 用什么题来测：测试集的来源、数量、覆盖范围；
• 怎么判断对错：什么样的回答算正确、部分正确、错误；
• 在什么条件下测：使用哪个版本的知识库、哪个模型、哪些配置。

这三点在需求阶段写进文档，比验收时临时争论要高效得多。标准不必一开始就完美，可以先定一个版本，在试运行期间根据实际情况修订，但修订要双方确认。

二、测试集怎么建

测试集是 AI 验收的基础，质量比数量更重要。建立测试集的实用方法：

1. 优先从真实数据中取题：历史客服记录、工单、内部群聊里的高频问题，比凭空想出来的题更有代表性；
2. 覆盖不同类型：常见问题、长尾问题、需要多步推理的问题、需要调用业务系统的问题；
3. 包含「不该回答」的题：超出业务范围的、知识库里没有答案的、涉及敏感话题的，用来测试拒答和转人工；
4. 包含变体问法：同一个问题用口语、错别字、缩写、方言表达各问一遍；
5. 每道题配标准答案或判分要点，由业务人员而不是开发人员编写；
6. 测试集与开发调优使用的数据分开，避免「背答案」。

数量上，与其追求几千道题，不如先做一两百道覆盖全面、有标准答案的题，再随着上线后收集的真实问题持续扩充。

三、准确率的口径：先定义什么叫「对」

「准确率」是最容易产生分歧的指标，因为它的计算方式有很多种。定义口径时需要明确：

• 判分等级：建议至少分为「正确」「部分正确」「错误」「正确拒答」「错误拒答」几类，而不是只有对错两种；
• 分母是什么：是所有问题，还是只算应该回答的问题；拒答的题怎么计入；
• 谁来判分：人工判分最可靠但成本高，可以用模型辅助预判、人工复核抽样；
• 什么算严重错误：给出错误的价格、错误的政策、编造不存在的产品，这类错误应单独统计，哪怕只有一次也需要处理。

一个实用的做法是分开报告几个指标，例如「应答题正确率」「拒答准确率」「严重错误数」，而不是合成一个总分。一个总分很高但有严重错误的系统，比总分略低但从不乱答的系统风险更大。

四、拒答与转人工：不会就说不会

对企业来说，AI 答错比不答更糟糕。因此验收时要专门考察系统「知道自己不知道」的能力：

• 知识库里没有答案时，能否明确说明并引导转人工，而不是编造；
• 涉及退款、投诉、合同条款等高风险问题时，是否按规则转人工；
• 用户明确要求人工服务时，能否顺畅转接并带上对话记录；
• 转人工的触发条件是否可以由业务人员在后台调整。

转人工率本身不是越低越好。上线初期较高的转人工率是正常的，说明系统在谨慎处理不确定的问题；随着知识库完善，再逐步降低。

五、除了准确率，还要测什么

• 响应速度：首字出现时间和完整回答时间，在高峰并发下是否稳定；
• 引用与出处：知识库类应用能否标注回答来源，方便用户核实；
• 权限：不同身份的用户是否只能查到自己有权看的内容；
• 安全：面对诱导、提示词注入、不当请求时的表现；
• 一致性：同一问题多次提问，答案是否基本一致；
• 成本：单次对话的平均模型调用消耗是否在预期范围内。

六、上线后的运营指标

验收通过只是起点。上线后建议持续跟踪以下指标，并定期复盘：

• 问题解决率：用户问完没有转人工、没有重复追问的比例；
• 转人工率及转人工原因分布；
• 用户反馈：点赞、点踩及文字反馈；
• 未命中问题：知识库中找不到答案的问题清单，这是补充知识库的直接来源；
• 抽检正确率：每周从真实对话中抽样人工判分。

每次更新知识库、更换模型或修改提示词后，都应该用测试集跑一遍回归测试，确认没有把原来答对的题改错。

七、验收清单

• 测试集已由业务方确认，包含应答题、拒答题和变体问法；
• 判分等级和计算口径已书面确定；
• 严重错误的定义和处理方式已明确；
• 转人工规则和触发条件已配置并测试；
• 性能、权限、安全测试已完成；
• 回归测试流程已建立，并交接给运营人员；
• 上线后的监控指标和复盘周期已约定。

AI 项目的验收不是一次考试，而是建立一套能持续衡量效果的方法。测试集和判分口径，是项目最重要的交付物之一。

大乐网络在 AI 客服、企业知识库和智能体项目中，会与客户一起建立测试集，并把回归测试工具作为交付的一部分。如果你正在准备 AI 项目的验收，可以先从整理一百道真实问题开始。