检索结果重复时如何做去重和来源合并

RAG 应用里最容易被忽略的噪声，不是“搜不到”，而是同一份资料被切成多个片段后反复命中。直接把 top-k 全塞给模型，会浪费上下文，也会让同一个结论在排序里被重复加权。更稳的做法是：先用稳定的 source_id 做同来源去重，再把保留下来的 chunk_id、最高分和文本范围合并成证据组；不同来源即使语义相近，也先保持独立，遇到冲突时不要静默覆盖。

官方地址：https://platform.openai.com/docs/

先把重复分成三种，不要一上来做相似度

一组检索命中至少有三类重复：同一 chunk_id 被重复返回，这是结果层重复；同一文档的相邻片段分别命中，这是上下文重叠；不同文档讲了同一事实，这是跨来源相似。前两类可以通过结构化字段稳定处理，第三类必须保留来源差异。

建议先把返回值统一成下面这几个字段。字段名不必照搬，但语义要固定：

用来源标识做第一轮去重

第一轮只解决“一个来源出现多次”的问题。每个 source_id 建一个组，组内按分数降序排列；取最高分片段做代表文本，同时保留其余 chunk_id。如果相邻片段之间确实互补，可以拼接，但要限制字符数，避免一个长文档吞掉所有候选。

下面的纯数据函数展示了最小实现。它没有调用模型，输入只是检索器已经返回的字典列表：

from collections import defaultdict

def group_hits(hits, max_chunks=3):
    # 同一来源只建立一个证据组，避免重复命中重复占用上下文。
    groups = defaultdict(list)
    for hit in hits:
        source_id = hit.get("source_id")
        chunk_id = hit.get("chunk_id")
        if not source_id or not chunk_id or not hit.get("text"):
            # 缺少定位字段的结果无法审计，直接留给上游修复。
            continue
        groups[source_id].append(hit)

    merged = []
    for source_id, items in groups.items():
        # 最高分作为代表片段，其他片段只在上限内随组保留。
        items.sort(key=lambda item: float(item.get("score", 0)), reverse=True)
        chosen = items[:max_chunks]
        merged.append({
            "source_id": source_id,
            "chunk_ids": [item["chunk_id"] for item in chosen],
            "max_score": chosen[0]["score"],
            "text": "\n".join(item["text"] for item in chosen),
        })
    # 组间仍按最高分排序，交给 rerank 或生成器继续处理。
    return sorted(merged, key=lambda item: item["max_score"], reverse=True)

这里的关键不是代码量，而是两个边界：去重键是 source_id，不是 text；合并结果仍带着原始 chunk_ids。如果上游没有稳定来源标识，应先在入库时写入文档 ID、版本或 URL 的规范化值。OpenAI 的 vector store file 支持保存结构化 attributes，可以把这类来源元数据作为索引对象的一部分管理。

合并后保留证据链，排序才不会失真

同来源合并后，排序分数也要重新解释。不要把 3 个片段的分数相加，否则一个文档只因切片更多就会压过其他来源。实践中可保留 max_score，另加 source_count、chunk_count 和可选的 conflict 标记。

例如 8 条命中最终得到 3 个证据组：文档 A 有 3 个片段，文档 B 有 2 个，文档 C 有 3 个。排序时使用每组最高分；生成上下文时按组输出，并在组内保留有限的片段顺序。这样既减少重复，又不会让模型误以为同一来源被多个独立来源支持。

跨来源相似内容只做第二轮检查。若 A 文档和 B 文档表述相同，可以在展示层折叠，但证据组里仍保留两个 source_id。若内容对应不同版本、地区或权限，就算文本很像，也应标记为冲突或条件差异，交给重排器和生成提示共同处理。

什么时候不应该合并

有三种情况宁可多给一个来源：第一，来源的更新时间或版本不同；第二，文本包含权限、地区、套餐等条件；第三，两个片段分别提供定义和例外。强行合并会让上下文变短，却把答案变得不可解释。

上线前至少记录四个指标：去重前命中数、证据组数、覆盖的 source_id 数量、被标记为冲突的组数。若组数突然降到很低，先检查来源规范化是否把不同文档错误映射成了同一个 ID；若组数几乎不变，再看切片策略和检索器是否返回了重复内容。

常见问题

可以直接按 text 哈希去重吗？

可以作为同一片段的兜底，但不能替代 source_id。不同来源可能有相同句子，按文本哈希会丢掉来源覆盖信息。

同一来源的片段应该全部拼起来吗？

不应该。按最高分保留代表片段，再限制性保留相邻或互补片段；长文档全部拼接会重新制造上下文噪声。

去重后还需要 rerank 吗？

需要。去重解决的是重复占位，不代表组间相关性已经最优；rerank 仍应根据查询和证据组文本重新排序。

发现两个来源结论不一致怎么办？

保留两个 source_id，记录冲突和版本条件，把判断交给明确的业务规则或生成阶段，不要在去重函数里静默覆盖。