RAG 检索结果为什么要先去重再交给生成模型：从候选文档到引用上下文

RAG 问答里最容易被忽略的一步，不是把向量检索接上，而是决定哪些候选文档真的值得进入上下文。相同文档的不同切片如果直接拼接，模型看到的往往是重复证据，真正有用的来源反而被挤出窗口。

先按稳定的 documentID 去重，再按相关性和 token 预算组成引用上下文；去重不是为了让结果好看，而是为了让生成模型看到更少、更独立、更容易核验的证据。

重复切片为什么会让 RAG 答案变窄

一次检索可能返回同一份产品手册的多个相邻 chunk。它们的向量距离都很近，却未必提供三条独立证据。若 topK 取 8，而前 6 个结果都来自 documentID 为 doc-17 的手册，后面的故障排查文档就没有机会进入上下文。

这会带来两个具体后果：一是提示词中重复出现相同条件，二是引用列表看起来很长，实际来源却只有一个。评估时不要只看检索相似度，还要看最终上下文包含了多少个独立 documentID。

从候选文档到引用上下文的最小数据流

把流程拆成三个真实节点：retrieveCandidates 取得候选切片，dedupeByDocumentID 保留每份文档最有代表性的片段，buildContext 再按预算生成 引用上下文，最后交给 生成模型。

func answer(question string) (string, error) {
    candidates := retrieveCandidates(question)
    unique := dedupeByDocumentID(candidates)
    context := buildContext(unique, 6000)
    return 生成模型(question, context)
}

这里的 6000 只是一个示例预算，不代表所有模型的固定上限。工程上应把预算作为配置，并在日志中记录候选数、去重后文档数和最终片段数，便于解释一次答案为什么变短。

去重时保留哪一个片段

不要按数组顺序盲目保留第一条。可以先按相似度降序排列，同一个 documentID 只保留最高分片段；若业务需要连续上下文，则保存相邻 chunk 的范围，但仍只让该文档占用一次来源配额。

来源标题和 documentID 要一起传递，不能在去重时只留下纯文本。后续生成引用链接、展示“来自哪份资料”或回放检索时，都需要这个稳定标识。

候选很多时，相关性和来源多样性怎么取舍

来源多样性不能变成“每份文档只取一条”的机械规则。若问题明确针对某一份 API 手册，应允许该手册占更多上下文；但这种例外要由查询意图或来源权重触发，而不是因为相邻 chunk 恰好排在前面。

三种常见实现坑

只按文本完全相同去重

相邻切片通常有不同文本，却来自同一 documentID。只做字符串去重会漏掉来源重复，应该把 documentID 作为主键，文本哈希只能作为辅助证据。

先截断再去重

先取前 5 个切片再去重，可能把预算全消耗在一份文档上。顺序应是候选排序、来源去重、再按 token 预算截断。

把引用信息丢在生成前

如果 buildContext 只拼正文，模型即使答对也难以解释出处。建议每段上下文保留短标题、documentID 和正文，并在最终响应中返回引用数组。

上线前用一组可回放指标验收

至少记录四个数字：候选切片数、去重后的 documentID 数、进入引用上下文的片段数、生成模型实际收到的 token 数。把它们和答案的引用数量放在同一条 trace 中，才能区分“检索没找对”与“上下文装不下”。

离线评估时可以准备含有重复切片、同义改写和跨文档冲突的问答集。验收不只看命中率，还要检查引用是否来自实际进入上下文的 documentID，避免模型引用了检索阶段见过、却已被预算截掉的片段。

相关问题

RAG 去重应该按 chunk 还是 documentID？

通常按 documentID 控制来源重复，再在同一来源内部选择最相关或连续的一组 chunk。

去重后文档太少怎么办？

先检查检索范围和切片策略，不要直接放宽到重复来源；必要时增加独立来源召回，再重新排序。

引用上下文一定要放完整原文吗？

不一定。保留能支撑结论的片段、标题和稳定来源标识即可，关键是让回答可以回溯验证。

小结

RAG 的上下文装配本质上是一条数据流：retrieveCandidates 找候选，dedupeByDocumentID 控制来源重复，buildContext 依据预算保留证据，最后才交给 生成模型。把这几个边界记录下来，答案质量和问题定位都会比单纯调高 topK 更可控。