RAG 证据冲突处理：当检索结果相互矛盾时如何停止编造结论

“有引用”不等于“答案正确”。同一问题可能检索到旧版本的运行手册、新版本的产品文档、不同租户的策略副本，以及一段没有发布日期的讨论记录。若模型把它们混在一起生成流畅结论，用户看到的只是一个看似自信的错误答案。

证据冲突应在生成前被显式识别。每个检索片段除了正文，还需要来源类型、版本、发布时间、适用范围、权限标签、作者或发布者、内容哈希和撤销状态。没有这些元数据，系统无法可靠区分“历史记录”和“当前规则”。

先排序可信度，再判断是否能合并

排序策略不应只依赖向量相似度。通常优先级应包括：当前租户或项目的权威配置，高于通用文档；已发布且版本明确的规范，高于未验证讨论；新版本在明确替代旧版本时优先；与用户权限和问题范围匹配的资料优先。这个顺序必须因领域而异，例如法律、医疗和财务内容还需要更严格的来源治理。

即使两个来源都可信，也不代表可以合并。若一个说配额为 100、另一个说为 500，系统要判断它们是否指不同套餐、不同时间或不同区域。无法消解时，答案应展示冲突和所需澄清，而不是隐含地选择数字较大的那个。

用结构化声明检测冲突

对于关键事实，把片段转换成可比较的声明：主体、谓词、对象、单位、时间范围和适用范围。例如 plan=pro, max_requests=1000/day, effective_from=2026-07-01。相同主体和谓词、重叠时间与范围、不同对象时即可标记为冲突候选。模型可以帮助抽取候选，但最终比较逻辑应可测试。

claim A: project=x, retention=30d, source=policy-v3
claim B: project=x, retention=90d, source=policy-v4
resolution: B supersedes A after 2026-06-01

对非结构化技术解释，不必强行做知识图谱，但至少保留“支持结论的片段集合”。生成器只能基于同一组兼容证据回答；若证据之间存在未解决冲突，则切换到澄清或引用式摘要模式。

回答应反映不确定性

当冲突可通过时间或范围消解时，答案要把条件说出来，例如“对于 2026-07 后创建的项目，当前策略为 30 天；旧项目可能仍适用 90 天”。当不能消解时，明确告知用户发现了两个不一致来源，并给出来源、时间和下一步验证方法。这样的回答看起来没有一锤定音，却比虚构确定性更有价值。

对于会触发写操作的 Agent，未解决冲突必须阻断执行。比如两个来源对删除保留期不一致，系统应要求人工确认或查询权威配置，而不是选择更激进的动作。把“证据不足”升级为状态而不是一句提示词，有助于避免高风险自动化。

通过回放样本校准策略

建立一组包含版本替代、租户差异、发布时间缺失和真实矛盾的评估集。每次调整排序或模型后，检查系统是否选对权威来源、是否错误合并冲突、是否在无法判断时成功澄清。线上还要监控冲突率、用户追问率和引用点击率；若某类数据经常冲突，问题可能在上游内容治理而不是 RAG 本身。

上游内容撤销应立即影响回答资格

冲突处理离不开内容生命周期。文档被撤销、政策被替代、数据源发现错误或权限范围改变后，相关片段必须从可回答集合中移除，而不是只降低一点相似度。索引管道需要消费撤销事件，更新内容状态并让缓存和引用页面同时失效。对于无法立即删除的分布式索引，查询层应维护撤销列表作为最后一道保护。

验证时可故意撤销一条曾被高频引用的文档，检查旧答案是否仍会引用它、缓存是否被清理、冲突检测是否提示新版本。若系统只能在下次全量重建后才停止使用旧证据，内容治理仍然存在危险窗口。把撤销、替代和权限变更当作一等检索事件，才能让引用真正具有时效性。

冲突升级需要明确责任人

当系统无法自动裁决冲突时，不能只把问题留在日志里。把冲突送入按领域分流的审核队列，并附上来源、适用范围、检测规则和建议选项。审核结论应更新权威内容或规则，而不是仅关闭一次告警；否则同一个矛盾会在下一次查询中重复出现。

延伸阅读

• RAG 引用溯源
• RAG 文档新鲜度 SLO
• RAG 元数据过滤