登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  科技周边 >  人工智能

RAG 多路检索结果如何去重合并:来源优先级、分组与引用回填

来源:17golang原创

时间:2026-08-29 10:48:11 208浏览 收藏

关键词检索和向量检索各自返回了正确段落,合并后的 RAG 上下文却有两份几乎相同的内容,最后一个来源还没有引用标记。这个症状不是“检索越多越好”,而是融合层没有定义去重键、来源优先级和引用回填规则。

多路 RAG 要先给结果补上稳定的 doc_idchunk_id,再由 mergeResults 去重、groupBySource 分组,最后让 attachCitation 把来源回填到上下文。

要点速览
  • 不同检索器返回同一片段时,应按文档与分块身份去重,而不是按整段文字猜相似。
  • 来源优先级要在合并前固定,否则排序结果会随检索器返回顺序漂移。
  • 分组后的结果仍要保留原始 chunk_id,引用回填才不会指向错误文档。
  • 回归测试至少覆盖重复片段、同文档相邻片段和不同来源同标题三种情况。

先确认重复发生在检索器之间

一次请求通常有两路输入:keyword_search 擅长精确词,vector_search 擅长语义相近。排查时把来源写进每条记录,先看重复来自哪两路,不要只对最终字符串做去重。

keyword_hits = keyword_search(question)
vector_hits = vector_search(question)
merged = mergeResults(keyword_hits, vector_hits)
grouped = groupBySource(merged)
context = attachCitation(grouped)

稳定的结果对象至少应包含 doc_idchunk_idsourcescore。其中 chunk_id 比正文摘要更适合做去重键,因为同一段内容的摘要格式可能随检索器变化。

RAG 多路检索从 keyword_search 和 vector_search 进入 mergeResults、groupBySource、attachCitation 的融合链路

用稳定身份去重,再处理来源优先级

最小可用实现是按 (doc_id, chunk_id) 建索引。遇到同一个分块时保留优先级更高的来源记录,同时合并可审计字段,不能只保留第一次出现的对象。

SOURCE_PRIORITY = {"official": 3, "internal": 2, "web": 1}

def mergeResults(keyword_hits, vector_hits):
    index = {}
    for item in keyword_hits + vector_hits:
        key = (item.doc_id, item.chunk_id)
        old = index.get(key)
        if old is None or SOURCE_PRIORITY[item.source] > SOURCE_PRIORITY[old.source]:
            index[key] = item
    return list(index.values())

这里的优先级只是示例规则,不代表所有业务都应把 official 放在最高位。关键是把规则写成配置并记录命中的选择结果。若两条记录身份不同但正文高度相似,应保留两条并在分组阶段标记“同主题”,不能把可能互相补充的片段误删。

mergeResults 按 doc_id 和 chunk_id 去重并依据 source 优先级保留记录

分组后再回填引用,避免来源漂移

去重完成后,把结果按 source 或文档集合分组,生成上下文时保留每个片段的身份。attachCitation 应使用原始 doc_idchunk_id 生成引用,不要根据拼接后的段落序号反推来源。

def attachCitation(groups):
    blocks = []
    for source, items in groups.items():
        for item in items:
            citation = f"[{item.doc_id}:{item.chunk_id}]"
            blocks.append({"text": item.text, "source": source,
                           "citation": citation})
    return blocks

这样即使排序策略改变,引用仍跟着片段走。日志建议记录 input_countdedup_countgroup_count 和每个引用的身份;正文内容只进入受控的上下文,不要把完整敏感文档写入普通日志。

相关问题与回归边界

只按正文字符串去重可以吗?

不稳妥。空格、切片标点或清洗规则变化都会让同一分块看起来不同。优先使用稳定的 doc_idchunk_id

同一文档的相邻分块要合并吗?

不要默认合并。相邻分块可能分别包含定义和例外条件;应先保留身份,再依据上下文预算和相邻关系做可解释的拼接。

为什么引用会指向错误来源?

常见原因是去重后重新编号,却用新序号回查旧数组。让 attachCitation 直接读取每条记录的 doc_id 和 chunk_id,就能避免这种漂移。

把多路融合变成可回归的工程步骤

准备三组固定样例:两路命中同一 chunk、同一文档的相邻 chunk、不同文档但标题相同。分别核对 mergeResults 的保留结果、groupBySource 的分组数量,以及 attachCitation 是否保留原始身份。只有这些证据都对得上,才适合继续把结果送进模型上下文。

多路检索的价值不在于把所有命中都塞进提示词,而在于让每条片段的来路、取舍和引用都能解释。把融合拆成三个节点,问题就从“答案偶尔串源”变成可以定位的状态变化。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>