企业知识建设完成后，最常见的验收方式是现场问几个熟悉的问题。演示很顺利，却不一定说明员工日常可用：问题可能太容易，答案可能来自模型常识，引用也可能没有真正支持结论。
建议围绕真实任务建立题集，不只检查答案是否“像那么回事”，还要检查对象是否匹配、规则是否现行、来源是否支持、权限是否正确，以及该回业务系统时有没有回去。
题集应覆盖不同失败方式
| 题型 | 示例任务 | 主要检查 |
|---|---|---|
| 直接查找 | 找出现行技术说明 | 能否找到正确页面 |
| 条件判断 | 某型号在指定工况下是否适用 | 是否保留限制条件 |
| 跨资料关联 | 整理某项目的要求与负责人 | 对象关系是否正确 |
| 版本冲突 | 旧纪要与新规则不一致时怎么办 | 是否采用有效依据 |
| 权限差异 | 不同岗位查询同一受限事项 | 是否遵守共享边界 |
| 实时回源 | 查询当前待处理数量 | 是否查原系统完整记录 |
| 信息缺失 | 资料未给出关键参数 | 是否承认缺口并提出补充项 |
题目来自实际工作更好。可以从重复咨询、交接卡点、错误答复和常见资料冲突中收集，避免只让实施团队出自己最擅长的题。
每道题需要一份可复核的判分依据
标准答案不一定是一段固定文字，更适合列出必须回答的事实、不能遗漏的条件、可接受的来源和禁止出现的结论。回答风格可以不同，但关键依据应一致。
比如“该产品能否用于某环境”这道题，判分不能只看是否回答“可以”。应要求型号一致、环境参数匹配、限制条件完整，并引用对应版本。若缺少参数，合理结果可能是提出一个明确问题，而不是强行给出肯定结论。
把错误分到可以修复的位置
未检索到正确页面，优先查索引与查询方式；找到了却读错条件，检查上下文回读与推理；引用的文档本身过时，需要知识维护；读到了不应访问的资料，需要修权限；把搜索结果当成全量统计，需要改任务路由。
如果所有错误都归结为模型能力，就很容易反复更换模型，却没有处理真正的业务资料问题。验收记录应包含问题、实际回答、使用来源、错误类型、修复负责人和复测结果。
一个总准确率会掩盖关键问题
可以分别报告答案正确、引用有效、版本正确、应回源任务执行和权限违规等结果。权限越界或把错误型号用于技术判断，即使只出现一题，也不能被大量简单题的高分掩盖。
例如，一套假设的验收题包含基础查找与高风险判断。如果基础题全对，高风险判断仍会漏条件，平均分可能很好看，业务却不能放心使用。题集应按任务风险分组，并为关键项单独设通过条件。
保留一部分未参与调优的问题
公开题可以帮助团队定位问题，但验收不能只有开发过程中反复调过的同一批题。应由业务负责人保留未公开题，覆盖相似但不相同的产品、对象或条件，检验系统能否理解规则，而非记住演示答案。
复测也不宜只重复相同问法。可以换一个简称、补充一项限制条件、使用另一个岗位身份，或让原系统中的状态发生变化，观察知识服务是否仍然给出正确结果。
最终交付应留在企业内部
题目、判分规则、来源版本和历史结果，是企业持续维护知识的重要资产。新文档发布、连接器调整或模型更换后，可以针对受影响题型复验，不必每次重新凭印象判断。
最后还应完成一次真实交接任务：让普通员工用知识服务处理自己当天的工作，记录仍需要找同事补充的内容。相关组织方式见公司全貌与实时查数分工，建设范围见企业知识中枢。
更多同主题内容见企业 AI Agent 落地专题。
