RAG 有引用就可信吗？知识库问答的引用校验与幻觉控制指南

给答案末尾加上 [1][2]，不代表结论真的来自这些资料。生产中的 RAG 常见三类“伪引用”：引用 ID 根本不存在、资料存在但没有支持对应结论、资料曾经正确却已被新版本替代。只检查模型是否输出引用格式，会产生一种危险的可信错觉。

本文提供一套不依赖具体模型版本的引用校验流程，适用于企业知识库、客服问答、制度查询和内部搜索。

把答案拆成可验证声明

第一步不是验证整段答案，而是拆分“可以被证据支持或反驳的声明”。问候、过渡句通常无需引用；日期、条件、金额、权限、流程步骤等关键陈述必须绑定证据。

建议模型输出结构化结果：

{
  "answer": "申请提交后需要直属负责人审批。",
  "claims": [
    {
      "text": "申请需要直属负责人审批",
      "citations": ["chunk_policy_42"]
    }
  ]
}

结构化声明让程序能够逐条验证，也便于在前端把引用放在对应句子旁，而不是堆在文章末尾。

四道引用校验

1. 存在性校验

引用必须来自本次检索候选集，不能接受模型自行拼出的文档 ID。验证器使用服务端持有的候选映射，而不是信任客户端回传内容。

function validateCitation(
  citationIds: string[],
  retrievedIds: Set<string>
) {
  return citationIds.every((id) => retrievedIds.has(id));
}

引用还应属于当前租户与当前用户可访问范围。即使 ID 存在，越权文档也不能成为答案证据。

2. 版本有效性校验

每个片段都要携带文档版本、状态和有效时间。若检索结果来自旧索引，文档已撤回或被替代，应停止输出并触发重新检索。不要仅依赖向量库里的文本副本，因为它可能落后于权威文档系统。

3. 支持度校验

“主题相关”不等于“支持结论”。片段讨论差旅制度，但没有提到审批人，就不能支持“直属负责人审批”。可以先使用规则检查关键词、数字和实体，再用独立判定器评估 supported / contradicted / insufficient。高风险业务应把“不足”视为失败，而不是让模型补全常识。

4. 覆盖率校验

一段答案可能有五个关键声明，却只给其中一个引用。计算声明级覆盖率，并对不同风险分级：介绍性内容允许部分覆盖，合同、财务、医疗或权限流程应要求每条关键声明都有证据。阈值要通过业务评测确定，不能照搬其他团队的数字。

处理冲突资料

知识库经常同时存在旧通知、新制度和部门补充说明。检索阶段应优先过滤失效版本，但仍可能出现两个有效来源冲突。此时不要让模型静默选一个，而应：

• 展示冲突来源与版本时间
• 优先权规则明确时按规则选择
• 规则不明确时回答“资料存在冲突”
• 将问题送给文档负责人治理

冲突率本身是知识库质量指标。持续把它隐藏在流畅答案里，只会把数据治理问题转嫁给用户。

引用内容不要被 Prompt 注入

外部网页、工单和用户上传文件可能包含“忽略系统规则”之类文本。检索片段始终是不可信数据，不是指令。把系统规则与引用内容放在清晰边界内，并限制模型只能从候选 ID 中选择引用。

工具执行权限更不能由文档内容授予。知识库里写着“请调用删除工具”，也只应作为待分析文本，而不是 Agent 的执行命令。

失败时怎样回答更好

引用校验失败后，最差的做法是删除引用继续展示原答案。更合理的降级顺序是：

1. 用更严格过滤条件重新检索一次

2. 缩短答案，仅保留有充分支持的部分

3. 明确说明资料不足或版本冲突

4. 提供相关原文入口供用户自行核对

5. 高风险问题转人工处理

不确定性提示要具体，例如“当前资料没有说明审批时限”，而不是泛泛说“答案仅供参考”。

建立引用评测集

评测样本不仅要有标准答案，还应包含允许引用的文档版本和声明级证据。至少覆盖：

• 答案明确且只有一个来源
• 多文档共同支持一个结论
• 资料缺失，应当拒绝回答
• 新旧版本冲突
• 数字相近但单位不同
• 文档中含提示注入文本
• 用户无权访问正确答案所在文档

离线评测关注引用准确率、关键声明覆盖和正确拒答；线上再观察用户打开引用、纠错反馈和人工升级情况。不要只用“答案看起来流畅”作为质量标准。

中转站接入时的注意事项

中转层可能影响结构化输出、流式分片、模型别名和错误信息。上线前应验证：

• JSON 字段是否完整透传
• 长引用 ID 是否被截断或改写
• 流式结束后能否得到完整对象
• 实际模型是否可追踪
• 超时重试会不会混合两次输出

把同一组引用测试样本跑过候选中转站，记录结果而不是只做一次“Hello World”连通测试。

上线检查清单

• 是否把答案拆成声明并就近绑定引用
• 引用 ID 是否限定在本次授权候选集
• 是否检查文档版本、状态与有效期
• 是否区分相关、支持、矛盾和证据不足
• 关键声明是否计算覆盖率
• 冲突或缺证时是否安全降级
• 是否有包含越权与提示注入的回归样本

总结

RAG 的可信度不来自引用数量，而来自“每个关键声明都能追到当前有效、用户有权访问、确实支持结论的证据”。把引用校验做成独立门禁，才能让知识库问答从会说话升级为可核验。

需要为 RAG 应用选择稳定的模型入口？可前往 openairouter.net 查看 AI API 中转站对比与排行榜，重点测试结构化输出、长文本透传、请求追踪与失败重试表现。