企业AI验收要交付可复跑的评测证据

企业 AI 系统能不能交付，不能只看供应商挑出来的几道演示题。这篇文章用一个 HR 制度问答案例，给出了三种验收办法：提前固定评测集，逐项验证技术组件的贡献，再单独检查系统是否会拒绝不该回答的问题。

最有用的地方，是作者展示了一次「加了组件反而退步」的过程。不过，文中的样本数量、实验方式和指标口径也有缺口。它适合拿来搭验收框架，还不足以直接充当采购标准。

先固定考题，才能知道系统有没有变好

评测集（eval set）就是提前准备好的问题和标准答案。每次修改系统，都用同一批题检查结果，避免这次问得简单、下次问得复杂，最后只能凭感觉判断。

作者在 HR 制度问答项目里，既准备了正常问答，也放入了应该拒答的问题，例如询问个人工资、如何开假病假条，以及其他公司的制度。这些问题检查的不只是知识是否正确，还包括系统有没有越过业务边界。

验收既要考系统会不会回答，也要考它知不知道何时停下。

但原文有一个必须指出的问题：作者说评测集有 64 条，随后列出的是 52 条问答和 8 条应拒答，合计只有 60 条。剩余 4 条是什么，没有交代。实际采用这套方法时，应先把题目数量和分类对齐，否则后面的正确率也不好核算。

加了检索组件，为什么正确率反而下降

作者给出的端到端正确率变化如下。端到端，就是从用户提问到最终答案，把整条处理链路一起验收。

配置变化	端到端正确率
v0 框架默认配置	0.67
加入按章节切分	0.80
加入关键词/向量融合，但中文分词有 bug	0.78
修好中文分词	0.81
加入地区/版本元数据过滤	0.83
加入拒答和表格查表	0.98

按章节切分，是让同一章节的内容尽量保留在一起；关键词/向量融合，是把字面匹配与语义匹配结合起来；元数据过滤，则先用地区、版本等条件缩小资料范围，减少拿错制度的机会。

这组数据最有价值的地方是 0.80 到 0.78 的回退。理论上能改善检索的组件，实际接入后可能因为实现问题拖后腿。作者将这次退步归因于中文分词失效，修复后分数升到 0.81。

不过，文中展示的更接近「逐步加组件的对照」。严格验证某个组件的独立贡献，还可以从完整系统里单独移除它，再看分数如何变化。

最后一步也有归因问题：拒答和表格查表一起加入，正确率从 0.83 升到 0.98，无法知道两项各贡献了多少。原文没有给出拆分结果。

总正确率之外，为什么还要单看拒答

作者报告，v0 的拒答准确率为 0.00，8 个不该回答的问题全部得到了回答；v1 达到 0.88，剩下 1 条是「食堂今天有什么菜」这样的歧义问题，被标为已知不足。

这里的 0.88，与 8 条中正确拒答 7 条的比例相符。但原文没有完整定义指标，也没报告正常问题被错误拒答的比例。因此，仅凭这个数字，还不能判断系统是否在「敢答」和「该拒绝」之间取得了平衡。

拒答也不总等于直接说不能回答。对于食堂菜单这类问题，合理行为取决于系统职责、是否接入当天菜单，以及是否需要追问具体园区。原文没有说明这些前提，所以把它保留为歧义样本，比强行宣布已经解决更可信。

我的判断

我赞同作者把验收前置：先约定题目和答案，再讨论技术方案，能让优化有共同尺度。与只看演示相比，这套做法更容易暴露退步；与只看一个总分相比，单独检查拒答更能看清业务边界。

但这些数字仍是单个项目的实测报告。原文没有说明标准答案如何判定、是否重复测试，也没说明是否另有未参与调优的验收题。反复围绕同一批题修改系统，存在只把这批题做好的可能。

作者称「不该答却答了」危险十倍，这是经验性强调，没有给出风险对照数据。不同问题的后果也不同，询问其他公司制度与索取个人工资，不能简单按同一种风险处理。

同样，作者说没有消融实验就永远发现不了分词 bug，也过于绝对。日志、检索结果检查和专项测试同样可能发现问题。逐项对照的价值，在于更容易发现退步并缩小排查范围。

能拿来做什么

• 给制度或文档问答系统先建一份固定题单，逐条记录标准答案、适用地区和版本，以及应该回答、拒答还是澄清；先核对样本总数，再计算指标。
• 修改切分、检索或过滤逻辑时，每次只改一个主要变量，保留修改前后的分数和失败题目。出现类似 0.80 降到 0.78 的情况，先查实现，再讨论方案是否有效。
• 验收时分别统计正常问题答对多少、越界问题拒对多少，以及正常问题被误拒多少。把歧义问题和已知不足列出来，让交付边界可以被检查。