RAG 引用溯源设计：让每个结论都能回到证据，而不是附一串链接

许多 RAG 产品会在答案底部放几个“参考资料”，但用户仍无法判断哪句话由哪份材料支持。更糟的是，模型可能根据一段无关 chunk 生成看似合理的结论，再把同一批资料全部列成引用。可验证的引用需要把结论、证据片段和源文档版本连成明确关系。

先定义什么需要证据

不是每个连接词都要脚注，但事实性主张、数字、政策要求、配置步骤和时间敏感结论必须能回到证据。生成阶段可以要求模型为每个 claim 输出引用的 chunk ID；也可以先把候选段落编号，再让模型只能引用编号。无论实现方式如何，模型不应自由编造 URL。

引用粒度应小到能支持具体断言。指向整本手册或整页文档，对用户排查没有帮助。至少保存 chunk 的标题、文本偏移、源文档版本和检索分数；展示时给用户一个可展开的原文片段，并突出与当前 claim 对应的句子。

一条合法的 chunk ID 不等于引用正确。可以对答案做两层检查：第一层验证每个引用存在、当前可访问、属于本次检索候选；第二层评估 claim 与证据是否蕴含或冲突。高风险场景优先使用规则或人工复核，例如金额、权限、法律条款和生产操作步骤。

如果答案包含没有引用支持的事实，系统应选择删除、降级为不确定表达，或明确告诉用户“现有资料不足以确认”。把无证据答案包装得更流畅，只会提高错误信息的说服力。

源文档更新后，旧答案里的引用可能指向过期版本。引用记录需要携带 documentVersion 和 chunk hash；展示时若当前版本已变化，标记“来源已更新”并触发重新检索或重新生成。不要静默把旧偏移映射到新文档，因为段落位置相同不代表语义相同。

当源文档被删除或用户失去权限时，引用也必须失效。用户看到一个无法打开的引用时，应该得到清楚解释，而不是 404 或绕过权限的公开链接。证据存储、检索索引和引用服务要共享同一个文档生命周期。

收集用户对引用的反馈：是否相关、是否足以支持结论、是否过期、是否难以理解。把差引用样本回流到检索评测集，区分是召回没有找到正确资料、rerank 排错了、模型没有使用证据，还是文档本身表达不清。这样引用不仅增加信任，也会成为提升 RAG 质量的观测信号。

好的引用体验让用户可以从答案回到原文、从原文回到版本和权限边界。它把“相信模型”变成“检查证据”，这正是企业级知识助手最重要的产品差异。

用户需要知道哪部分是原文事实，哪部分是系统根据多个来源做出的归纳。可以把直接引用、汇总结论和不确定提示以不同样式呈现，并允许用户展开每个 claim 的证据。不要用一串统一脚注掩盖推断关系，尤其在技术排障、政策解释和数据分析中，证据粒度会直接影响用户是否敢据此行动。

对引用覆盖率建立发布门槛：高风险任务中的关键 claim 必须都有可访问证据；普通说明允许少量无引用的过渡句，但不能包含新的事实。定期抽样由人工判断引用是否真正支持结论，将不支持、过期和难以理解三种反馈分别统计。这样引用系统不会只追求“每段有链接”，而会持续提高证据质量。

在数据模型中把回答、claim、chunk、源文档版本和权限快照分开存储。这样某个文档更新或被撤销时，可以精确找出受影响的答案和缓存，而不是全量清空。对于审计要求高的系统，保留生成时的证据快照 hash，使后来的人能判断当时引用的是哪一版资料。

上线前抽取一组答案，让不了解实现的人只凭引用验证结论。若 reviewer 仍需猜测“这条链接为什么在这里”，说明引用结构还没有达到用户可验证的标准。

对于跨多个来源的比较结论，显示每个来源支持的维度，而不是假装一份文档支持全部判断。比如价格来自产品页、限制来自政策页、技术步骤来自 Runbook，就应分别标注。清晰的证据分工会让用户更容易发现缺失信息，也能防止系统把多个部分正确的资料拼成一个整体错误的结论。