企业知识库接入生成式AI后，怎样用评测集识别检索与回答问题

企业知识库接入生成式 AI 后，最容易出现一种误判：用户说“答案不对”，项目负责人就直接去调整模型或提示词。实际上，问题可能根本不在回答环节，而在于系统没有找到正确的资料。把“检索不到”和“模型答错”分开，是评估内部问答项目是否可靠的第一步。

先把一次问答拆成两个问题

典型的 RAG知识库问答，大致经过“用户提问—检索相关资料—模型参考资料生成答案”这条链路。评测时不能只看最后一句话是否通顺，而要分别检查两个环节。

第一个问题是：系统有没有找到回答所需的资料？如果相关制度、流程或产品说明根本没有进入检索结果，模型即使语言能力很强，也只能猜测、泛化，或者直接表示无法回答。这属于检索问题。

第二个问题是：系统已经找到了正确资料，模型有没有准确理解并据此回答？如果证据中明确写着某项流程，回答却遗漏条件、混淆适用范围，甚至加入资料中没有的结论，这才是回答问题。

这一区分会直接影响复盘方向。检索问题通常要回看文档质量、切分方式、问题表达和召回结果；回答问题则要检查证据引用、生成约束和答案组织。两者混在一起，优化很容易变成反复调整模型，却没有解决真正的瓶颈。

评测集不要从想象中的问题开始

基础评测集应尽量来自真实使用场景，而不是由项目成员凭空编写一批“看起来合理”的问题。可以从已有的客服记录、内部咨询、搜索日志、工单或试运行期间的用户提问中抽样，再补充少量容易被忽略的边界问题。

抽样时，不要只保留标准、完整、措辞清楚的问题。真实用户可能会使用简称、口语、错别字，也可能把多个条件放在同一个问题里。评测集如果全是规范问法，系统上线后遇到真实表达就可能表现失真。

问题还应覆盖不同的信息类型。比如，既要有能够在单份文档中直接找到答案的问题，也要有需要对照多个资料的问题；既要测试现行规定，也要测试带有时间条件的问题；既要包含普通员工可以查看的内容，也要包含不应被越权返回的内容。

评测集不必追求数量庞大，但要能代表项目最重要的业务风险。与其堆积大量重复问题，不如保留那些能够暴露资料缺失、版本冲突、引用不全和权限错误的样本。

一条样本至少要记录什么

每条评测样本都应包含问题本身，以及用于判断结果的参考信息。参考信息不一定要写成唯一标准答案，但必须足以说明“什么内容算正确”。

建议为样本记录以下内容：

• 用户问题及其来源场景；




• 问题涉及的主题、部门或知识范围；




• 期望命中的文档或资料片段；




• 参考答案、必要要点或允许的答案范围；




• 资料的有效时间和版本关系；




• 用户角色及其可访问范围；




• 是否允许回答“不确定”或“当前没有可用依据”。

其中，“期望命中的文档或资料片段”非常重要。没有这项信息，评测人员只能凭最终答案猜测系统是否检索正确，无法准确定位问题发生在哪一层。

对于开放性较强的问题，可以采用“关键事实要点”的方式标注。例如，答案必须包含适用对象、申请条件和办理路径，但具体措辞可以不同。这样既能避免把评测变成文字比对，也能防止模型用一段流畅话术掩盖关键信息缺失。

用分层结果识别检索故障

评测时，最好先单独查看检索结果，再查看模型最终回答。可以为每条样本标记以下几种状态：

如果参考资料没有被召回，哪怕最终答案碰巧正确，也不能把这条样本记为完整通过。它可能只是模型凭借已有知识或语言推断给出了相似表述，遇到更复杂的问题时仍然会失败。

反过来，如果正确资料已经排在检索结果中，但答案遗漏了限制条件，或者引用了资料没有支持的内容，就应归入生成和回答环节。这样的记录比简单写“回答错误”更有用，因为后续处理方向已经比较明确。

五类基础指标要覆盖哪些风险

召回完整性

召回完整性关注“该找到的内容有没有找到”。对于一个问题，可以先标出回答所需的关键证据，再检查这些证据是否进入检索结果。若只命中标题相似、但缺少具体条件的片段，不能算作完整召回。

这项评估尤其适合发现同义词、简称、跨文档关联和复杂问法带来的问题。它也能帮助负责人判断，问题究竟是知识库里没有资料，还是资料存在但没有被系统找到。

答案准确性

答案准确性不是看语言是否顺滑，而是核对事实、条件、范围和结论。对于政策、流程和内部规定，少掉一个适用条件，可能就会改变实际含义。

评测人员应将答案拆成若干可核对的事实点，分别判断正确、缺失、错误或无法确认。这样可以区分“整体方向正确但不完整”和“核心结论错误”这两类问题。

引用依据

有引用不等于有依据。需要检查引用的资料是否真的支持对应结论，引用位置是否与回答内容相关，以及回答是否把多个片段中的信息拼接成了资料并未表达的结论。

如果系统无法找到足够依据，较稳妥的表现应是明确说明信息不足、需要进一步确认，而不是用确定语气补全未知内容。

时效性

企业资料会发生更新，评测集应保留带有时间背景的问题，例如“现行规定”“最新流程”或“某版本之后的要求”。标注时要明确哪些资料已经失效，哪些资料优先级更高。

复盘时，如果答案引用了旧文件，即使旧文件内容曾经正确，也应记录为时效性问题。这个问题不能简单归因于模型，因为根因可能是资料更新、版本标识或检索排序没有被正确处理。

权限隔离

权限问题不能只用普通问答样本验证。评测集应设置同一问题由不同角色提问的情况，检查系统是否会因为问题相同而返回超出权限范围的内容。

对于无权访问的资料，正确表现不是“尽量回答”，而是遵守访问边界，并以合适方式说明无法提供相关信息。权限隔离应单独记录，不能被其他维度的高分抵消。

标注和复盘要避免两个陷阱

第一个陷阱是只给整条答案打一个“对”或“错”。这种标注太粗，无法说明是资料缺失、引用错误、答案遗漏还是权限违规。至少应同时记录检索结果是否合格、答案是否合格，以及失败原因。

第二个陷阱是让单个人凭感觉完成全部标注。涉及制度、流程和权限的问题，最好由熟悉业务资料的人确认参考依据，再由另一位评测人员核对系统结果。出现分歧时，不要急着修改答案，而要先回看标注是否清楚、资料是否存在版本冲突。

每轮复盘都可以把失败样本按原因归类：知识库缺少资料、相关资料未被召回、召回片段不完整、引用与结论不匹配、模型理解错误、资料已过期，以及权限边界失守。下一轮评测继续保留这些样本，才能判断改动是否真的改善了问题，而不是只让新问题看起来更好。

让评测集成为持续检查工具

评测集不是上线前的一次考试，而应成为知识库和问答系统的回归检查工具。资料结构、版本内容、检索策略或生成方式发生变化后，都应重新查看高风险样本。

项目负责人可以先建立一组覆盖核心场景的基础集，再逐步加入线上真实失败案例。对于同一问题的不同表达，也应保留部分变体，用来观察系统是否只会处理标准问法。

最终要关注的不是一个漂亮的总分，而是失败分布：系统主要漏掉了哪些资料，哪些回答经常缺少引用，哪些内容容易受到旧版本干扰，哪些角色存在越权风险。只有把这些问题拆开，评测结果才会从“AI好不好用”的模糊印象，变成可以指导知识整理、检索优化和回答约束的具体依据。