第 7 章 AI 评测：从“看起来不错”到“可以验收”
7.1 Demo 为什么总是效果很好
演示通常挑选已知问题、干净数据和理想路径。模型回答流畅，人们很容易把语言上的自信当成结果上的可靠。
真实业务却包含错别字、信息缺失、模糊表达、旧版本、无权限内容和从未见过的例外。系统不仅要在会回答时答对，还要在不知道时承认不知道，在风险过高时交给人。
因此，AI 项目的验收不能只看功能是否完成，也不能由项目团队现场挑几道题。评测要把“感觉不错”变成可以重复、比较和解释的证据。
7.2 从真实任务建立测试集
有效的评测集应来自实际工作，而不是由开发者凭空编题。可以从历史工单、客服对话、业务文档、专家案例和试用反馈中抽取样本。
样本要覆盖常见任务，也要保留容易失败的少数情况。只按出现频率抽样，可能忽略低频但高风险的操作；只收集困难问题，又无法反映日常体验。
每条样本至少需要输入、预期结果或评价标准、来源、业务类别和风险等级。开放性任务不一定有唯一答案，但必须知道怎样区分可接受、需修改和不可接受。
测试集还要与开发数据分离。团队反复针对同一批问题调试，会逐渐适应答案，却不代表系统能够处理新问题。
7.3 不只测试“答对”
企业 AI 至少需要覆盖几类情况。
正向用例验证常见任务能否正常完成。反向用例验证信息不足、问题无关或不应回答时，系统能否拒绝或要求补充。边界用例覆盖极长输入、格式错误、模糊表达和罕见情况。
权限用例检查不同身份是否只能取得允许的信息。安全用例尝试通过诱导、伪造指令或恶意文档绕过限制。人工接管用例验证系统是否能识别高风险和低置信度情况，并把上下文完整交给人。
还要测试依赖失败：知识库暂时不可用、外部接口超时、模型返回异常格式时，系统能否给出可理解提示，而不是静默产生错误结果。
7.4 确定性指标与人工评价
结构化任务适合自动判断。例如分类是否正确、字段是否完整、引用是否存在、权限是否越界、响应是否超过时限。
总结、建议和对话等开放任务通常需要人工评价。评价者不能只问“喜欢不喜欢”，而要依据清晰维度：事实是否正确，是否覆盖关键点，是否引用可靠，表达是否可执行，是否违反边界。
人工评价最好采用等级和具体失败标签，而不是单一总分。两个答案都得 3 分，一个可能遗漏事实，另一个可能表达冗长，修复方式完全不同。
对于重要场景，应让多名业务专家评价一部分相同样本，以检查标准是否一致。如果专家之间分歧很大，说明验收规则本身还没有定义清楚。
7.5 应该关注哪些指标
不同项目指标不同，但可以分成四层。
模型与任务指标包括正确率、召回率、完整性、拒答质量和工具选择成功率。系统指标包括延迟、可用性、错误率、调用成本和恢复时间。
安全指标包括越权率、敏感信息泄露、危险操作拦截率和人工接管率。人工接管并非越低越好；高风险任务中，正确接管是系统成熟的表现。
采用与业务指标包括活跃用户、使用频率、建议采纳率、处理时长、返工、收入、成本和风险变化。
技术指标好而采用率低，说明系统没有进入流程或用户不信任；采用率高而业务结果不变，说明可能选错了问题。评测必须最终连接业务结果。
7.6 建立失败分类
平均分会隐藏很多信息。一个系统准确率从 80% 提高到 85%，并不能说明最危险的问题是否解决。
更有价值的是建立失败分类。例如：未检索到资料、检索到旧版本、模型误解问题、引用与结论不一致、工具参数错误、权限过滤失败、缺少人工确认、用户输入信息不足。
每次评测都记录失败属于哪一类，团队才能知道应该修数据、检索、提示词、工具还是流程。失败分类也会逐渐成为项目最有价值的资产之一。
7.7 每次变化都可能带来退化
更换模型、修改提示词、更新知识库、调整切分方式或新增工具，都可能改善一部分任务，同时破坏另一部分任务。
因此，重要变更发布前要重新运行核心评测集。高风险用例必须全部通过，普通用例可以根据目标设定最低标准。结果与上一版本比较后，才能决定是否上线。
生产环境中的新失败还要持续回到测试集。评测不是上线前的一次考试，而是系统持续学习的记忆。
7.8 客户必须拥有独立验收证据
如果测试问题和预期答案全部由交付团队准备，就容易出现自测自证。客户应参与定义业务标准，并保留一部分未向开发团队开放的验收样本。
验收前还要约定样本范围、评价人、通过阈值、重大错误定义和争议处理方式。开放任务不可能追求百分之百一致，但安全红线和关键业务错误必须单独约束。
评测结果也不能脱离运行条件。测试数据、模型版本、知识版本、提示词和系统配置都应记录，否则同一个分数无法重现。
本章小结
AI 评测不是为模型打一个总分，而是建立持续可重复的证据：系统在哪些任务上有效，会以什么方式失败，发生变化后是否退化，以及这种表现能否支持业务使用。
当系统准备进入生产，评测只是护栏之一。身份、权限、安全、合规和故障恢复，决定它能否在企业环境中被真正信任。