构建企业知识库的质量评测集，关键不在于凑齐多少题目，而在于让评测能真实反映知识库在具体场景下的可用性。常见误区是把评测等同于解析成功率或索引数量，但这些指标无法回答一个核心问题：当用户带着真实需求发问时，系统能否找到正确依据、避开过期内容、并清晰给出来源。因此，评测集应由场景反推，而不是先追求规模。
以客服知识问答为例，构建评测集的第一步是明确用户到底会问什么、哪些制度或产品资料可作为依据、内容更新由谁负责，以及哪些问题必须转人工处理。只有锚定这些边界，才能选出有代表性的测试问题，而不是用抽象样例掩盖真实盲区。
评测集应覆盖的维度
一份面向 AI 应用的评测集，至少要能检验以下几类能力，并与数据治理环节对应：
- 完整性：场景所需主题和关键文件是否覆盖，重要章节是否被漏提。
- 准确性与一致性：返回内容是否与原文一致，术语、指标和版本口径是否存在冲突。
- 时效性：命中结果是否标注生效时间与失效状态，是否混入过期版本。
- 可追溯性：答案能否回到原始来源、文件版本和加工过程。
- 权限适配性：数据是否只向有权限的用户和应用开放，有无越权返回。
这些维度不是并列的检查项，而是层层递进的判断链。一个答案即使内容正确，如果来自过期版本或越权文件，仍应判定为不合格。
用真实业务问题做验收
评测的执行方式，是选取真实业务问题进行检索测试，逐条检查结果是否找到正确依据、是否混入过期内容、是否越权返回、来源是否清楚。对于 RAG 知识库，返回结果最好携带来源信息，便于评测人员核验，而不是只看一段无法追溯的生成内容。
更重要的是，评测中暴露的问题要能被准确归因。业务人员需要区分这究竟是数据问题、权限问题还是应用配置问题，再把对应缺陷送回治理环节修正。例如版本混乱属于数据层面，越权返回往往指向权限校验未进入调用链。只有归因清晰，评测才能驱动改进，而非停留在打分。
评测集也不是一次性产物。源文件更换、撤回或失效后，相关测试用例和预期答案需要同步调整，否则评测本身也会引用旧内容。建议明确评测责任人与复核周期，让评测随知识库持续演进，逐步沉淀为可复用的质量基线，而不是项目验收时临时拼凑的一次性清单。