RAG 需要跨多个文档综合回答时，如何做多跳召回、证据合并和冲突处理？｜百度算法面经解析

60 秒回答模板

我会把跨多文档 RAG 分成“找全证据”和“基于证据综合推理”两段。第一步先判断问题是否真的需要多文档，例如需要比较多个对象、串联多个时间点、同时满足多个条件，或者一个文档只给出局部事实。第二步做 query planning，把原问题拆成若干子问题或检索意图，例如实体识别、时间范围、约束条件和待比较维度；每个子问题可以生成不同 query，走向量、BM25、元数据过滤、父子索引或图关系召回。第三步不能只按单 chunk 相似度排序，而要按 evidence coverage 排序：候选集合是否覆盖所有子问题、是否来自互补文档、是否有重复内容、是否足够新、是否可信。第四步做证据组织，把 chunk 按实体、主题、时间线或论点分组，保留文档标题、段落、时间、版本和引用位置；对重复证据合并，对矛盾证据标注冲突来源和优先级。第五步再让模型生成，Prompt 里明确要求只基于给定证据回答、逐点引用来源、证据不足时说明缺口，并把综合推理过程限制在可追溯证据上。最后评估要拆成多跳召回率、证据覆盖率、引用准确率、冲突处理正确率和最终答案 faithfulness，而不是只看答案是否流畅。

考点 先判断是否需要多文档

难度 真实面经题

回答目标 让候选人能把多文档 RAG 从“多拿几个 chunk”升级为可落地的多跳检索和证据合成系统，覆盖规划、召回、重排、冲突处理、引用生成和评估闭环。

深入解析

先识别多文档意图

不是所有 RAG 问题都需要多文档推理。常见多文档场景包括横向比较多个产品或方案、把政策条款和业务案例结合、按时间线追踪变化、需要先找定义再找例外、一个问题包含多个实体或多个约束。识别这类意图后，系统才应该从单次 topK 检索切换到子问题规划和证据覆盖优化。

Query planning 把问题拆成可检索单元

跨文档问题通常不能靠一个 embedding query 找全。应抽取实体、关系、时间、指标、限定条件和比较维度，把原问题拆成多个子查询。例如“对比 A 和 B 的续费规则变化”可以拆成 A 的规则、B 的规则、变化时间、例外条款和共同指标。每个子查询独立召回，再合并成候选证据集合。

召回要多路互补

多文档 RAG 适合混合召回：向量召回处理语义表达，BM25 或倒排处理专有名词、编号、日期和术语，元数据过滤控制时间、部门、权限、语言和文档类型，父子索引用于小粒度命中后回填大段上下文，图关系或实体索引用于多跳扩展。目标不是单路分数最高，而是找齐回答所需证据。

重排要看证据覆盖而非单点相似

普通 rerank 往往只判断 query 与 chunk 是否相关，多文档场景还要判断候选集合是否覆盖所有子问题。可以按 coverage、互补性、来源多样性、时效性、权威性和冲突风险打分。若 topK 全是同一文档的重复段落，即使相似度高，也会挤掉其他必要证据，导致综合回答缺项。

证据组织决定生成质量

把 chunk 直接平铺给模型会增加遗漏和混淆。更稳的做法是先按实体、主题、时间线、论点或子问题分组，合并重复段落，保留每条证据的标题、章节、时间、版本、来源和 chunk id。这样 Prompt 可以明确“每个子问题有哪些证据”，模型也更容易做结构化综合。

冲突处理需要显式策略

多文档证据经常出现版本冲突、时间冲突、口径冲突或来源可信度不同。系统应优先使用更新时间更近、来源更权威、权限范围更匹配、文档状态为正式发布的证据；无法判定时不要强行合成一个确定答案，而应说明存在冲突，并分别给出来源。

上下文预算要服务推理链路

跨文档回答容易超上下文，不能简单扩大 topK。应先保留覆盖子问题的最小证据集合，再对长文档做章节摘要或父 chunk 回填；对重复证据压缩，对低置信证据降级。若模型支持长上下文，也仍然需要排序和结构化，否则长上下文会把关键证据淹没。

生成阶段必须有引用约束

最终生成要要求模型逐点依据证据回答，重要结论附来源，不能用常识补齐缺失事实。Prompt 可以要求先列 evidence table，再合成答案；对证据不足的子问题输出“不足以判断”。这能减少 hallucination，也方便后续自动检查答案中的每个 claim 是否能被证据支持。

评估要拆成检索和综合两层

多文档 RAG 的评估不能只看最终 EM 或人工主观分。检索侧看 multi-hop Recall@K、证据覆盖率、去重率、冲突证据召回率和权限误召回率；生成侧看引用准确率、claim faithfulness、冲突处理正确率、答案完整性和拒答准确率。只有拆开评估，才能知道失败是没找全、没排序好，还是生成综合错了。

易错点

只说“多召回几个文档放进 Prompt”，没有讲问题拆解、证据覆盖和去重。
把多文档 RAG 等同于 GraphRAG，忽略普通混合召回、父子索引和元数据过滤也能解决很多场景。
rerank 只按单 chunk 相关性排序，导致 topK 被同一文档的重复段落占满。
遇到证据冲突时让模型自行判断，不提供来源优先级、时间版本和不确定性表达规则。
生成答案没有引用约束，无法验证关键结论是否真的来自检索证据。
只评估最终答案流畅度，不评估多跳证据召回率、覆盖率和引用准确率。
忽略权限和版本过滤，把不该进入当前问题范围的文档也放入上下文。
把长上下文窗口当作唯一解决方案，不做结构化组织，反而增加遗漏和混淆。

面试官追问

多文档 RAG 和 GraphRAG 的区别是什么？

多文档 RAG 是问题形态和系统能力，强调跨多个文档找证据并综合回答；GraphRAG 是一种可能的实现路径，通过实体、关系和社区摘要帮助多跳扩展。不是所有多文档问题都需要图，但当实体关系复杂、路径推理明显时，图结构会更有价值。

为什么不能直接把 topK 调大？

topK 变大只增加候选数量，不保证覆盖子问题。它还可能带来重复段落、噪声证据、上下文超限和生成混淆。更合理的是做 query decomposition、覆盖率重排和证据去重，在有限上下文里放入互补证据。

多个文档结论冲突时模型应该怎么回答？

先按更新时间、来源权威性、文档状态、适用范围和权限范围做优先级判断。如果能确定应采用哪一份，就说明依据；如果不能确定，就不要编造统一结论，应列出冲突点和各自来源，并提示需要人工确认。

如何设计多文档 RAG 的离线测试集？

需要构造带 gold evidence 的样本，每题标注必须命中的多个文档或段落、每个子问题的证据、可接受答案和冲突处理要求。评估时分别计算 evidence recall、coverage、引用准确率、答案完整性和不充分证据下的拒答率。

长上下文模型能否替代多跳召回？

不能完全替代。长上下文可以减少压缩损失，但文档数量、权限过滤、时效排序、重复内容和冲突证据仍需要检索系统处理。高质量 RAG 仍要先筛选和组织证据，再交给模型综合。