多轮对话时，RAG反复做重复召回，模型层与Milvus层分别如何解决？

做 RAG 的团队，基本都会在多轮对话上吃过亏。

前几轮还表现不错，到了第四、五轮，AI 开始重复自己的历史回答内容。比如用户追问细节，系统把已经给过的段落又搜了一遍，换个说法再输出一遍。

其实，这其中的问题不出在模型，而是因为检索系统没有记忆。每一轮对话，它都当作第一次在检索。

这篇文章从阿里通义团队的多模态检索框架 VimRAG 的一个具体发现切入，聊聊多轮 RAG 里重复召回这个问题，以及用 Milvus 在工程侧落地的解法。

01 

多轮对话后，检索系统在干什么？

RAG 的链路很简单：用户提问 → 检索文档 → 喂给模型 → 生成回答。单轮场景下没什么问题。

多轮对话一进来，情况就变了。用户的第三个问题往往是对第一个问题的追问，第五个问题可能换了个角度重问第二个。每一轮，检索模块都会重新搜一遍，结果同一批文档被反复召回。

这不是偶发的。阿里通义团队在 VimRAG 的实践里测了三种记忆管理方式——传统的把所有历史拼在一起的做法，随着轮次增加，无效检索次数急剧上升；改成每轮总结历史的方式，结果其实也差不多，因为总结会丢细节，AI 还是记不住自己搜过什么。

AI 没有变笨，是它没有记忆。

这个问题带来的影响，有以下几个：

用户最先感知到的是重复。问了三轮，发现 AI 在绕圈子，对话通常就在那里终止，这种问题通常不会报错，但是会带来用户体验的降级。

Token 成本是第二个问题。VimRAG 的对照数据：传统方式平均每轮消耗 15.8k tokens，引入选择性记忆后只需 2.7k，差了近 6 倍。多轮对话的复利效应让这个缺口持续放大，用户量越大越明显。

最后是一个反直觉的结论：重复内容越多，回答质量反而越低。模型的注意力是有限的，冗余信息把关键线索稀释了，多搜不等于搜得更好。

最重要的是，训练 RAG 系统时，如果不区分哪些检索步骤真正有用、哪些是无效重复，直接用最终答案对错打分，会出现信号污染。

一个正确答案的路径里，可能有一半检索步骤是废的，但因为最终答案对了，这些废步骤也拿到了奖励；一个错误答案的路径里，可能有几步检索找到了真正有价值的信息，但因为最后推理出了错，这些有效检索也被一起惩罚了。

这就像考试只看总分不看过程。抄对答案的学生被表扬，认真解题但算错一步的学生被批评。

针对这个问题，VimRAG 的训练侧解法叫 GGPO（图引导策略优化）：用图结构追踪每一步检索的贡献，找到从起点到正确答案的关键路径，只奖励路径上的步骤，把偏离路径的冗余屏蔽掉。基于这个方案，无效检索次数和 token 消耗都显著下降。

02 

不动模型，怎么在检索层把重复干掉？

VimRAG 在推理阶段有自己的去重机制——多模态记忆图（MMG），用 DAG 图结构记录每轮推理走过的路径，天然避免重复访问同一信息节点。但MMG 需要配套 VimRAG 的完整训练方案，没有微调过模型的团队几乎实现不了。

但基于Milvus ，我们可以有三条更简单的路径，在检索层直接处理重复的召回。

路径一：expr not in排除历史 ID

最直接的做法。维护一个consumed_ids列表，每轮检索后把命中的 chunk ID 追加进去，下一轮带上expr过滤：

from pymilvus import MilvusClient

client = MilvusClient(uri="http://localhost:19530")

consumed_ids = ["doc_001", "doc_017", "doc_042"]

res = client.search(

    collection_name="rag_chunks",

    data=[query_vector],

    limit=5,

    filter='doc_id not in ["doc_001", "doc_017", "doc_042"]',

    output_fields=["doc_id", "text"]

)

这一层解决的是跨轮次的历史排除——AI 在第三轮不会再搜到第一轮已经召回过的文档。

这里值得说清楚一件事：not in在 Milvus 内部不是逐条比对，而是用 bitset 标记被过滤的向量，在 HNSW 图遍历时直接跳过这些节点。Milvus v2.5.x 的版本日志里专门提到了对 NOT IN 子句的性能优化，包括 SIMD 加速的 bitset 操作。但有一个临界点要注意：当consumed_ids列表很长、过滤率极高时，Milvus 会自动从图遍历降级到暴力扫描——图索引失效了，延迟会明显上升。这是为什么第四节要设滑动窗口的真实原因，不只是一个经验建议。

路径二：group_by_field做单次检索内的去重

expr not in能排除历史文档，但解决不了另一个问题：同一篇文档的不同 chunk 在语义上高度相似，一次检索可能同时命中同一文档的三个段落，这三个 chunk 会同时出现在结果里，占掉limit=5里的三个名额。

Milvus 的group_by_field参数解决的就是这个。在search()时传入group_by_field="doc_id"，Milvus 会保证每个文档 ID 最多返回一个 chunk，自动选取该文档下相关性最高的段落：

res = client.search(

    collection_name="rag_chunks",

    data=[query_vector],

limit=5,

    group_by_field="doc_id",

    output_fields=["doc_id", "text"]

)

这一层是无状态的——不需要维护任何跨轮次的列表，在查询时直接保证结果多样性。

路径三：两者组合，覆盖完整的去重链路

group_by解决单次检索内的文档级重复，expr解决跨轮次的历史重复。两个一起用，才是这个场景下完整的解法：

res = client.search(

    collection_name="rag_chunks",

    data=[query_vector],

    limit=5,

    group_by_field="doc_id",

    filter='doc_id not in ["doc_001", "doc_017", "doc_042"]',

    output_fields=["doc_id", "text"]

)

第一个参数保证这一轮结果里不出现来自同一文档的多个 chunk，第二个参数保证历史轮次已经用过的文档不再出现。

这两个功能合起来，能覆盖 VimRAG 在推理侧解决的重复访问问题——但没有覆盖 GGPO 在训练侧解决的信用分配问题。

但这本质上是两件不同的事：一个在改训练信号，一个在改检索输入。能用工程手段在推理侧处理的，先用工程手段处理掉，不一定每个团队都需要走到重训模型那一步。

03 

真正部署时，这几个地方容易翻车

最小可行方案是上一章节的三层组合，生产落地还有几个细节绕不过去。

去重记录的粒度怎么选

用了group_by_field="doc_id"之后，每次检索最多返回每篇文档的一个 chunk。但consumed_ids列表应该记什么——是doc_id还是chunk_id？

两种选择对应两种策略。记doc_id，下一轮整篇文档都不会再出现，适合知识库文档之间独立性强、每篇文档只有一个核心信息点的场景；记chunk_id，只排除用过的段落，同一文档的其他段落下一轮还可以召回，适合长文档、每个段落信息密度差异大的场景。

两种都是合理选择，取决于你的知识库结构。大多数企业知识库文档之间独立性强，记doc_id更安全。

滑动窗口大小压测后定

前面解释了not in列表过长时 Milvus 会从图遍历降级到暴力扫描。滑动窗口的 N 值不是一个可以拍脑袋的数字——N 太小，早期召回过的文档又出现了；N 太大，过滤性能开始退化。实际值要在你的数据规模和查询量下压测出来，不同场景差异很大。

状态存储别只放内存里

多轮对话通常是无状态的 HTTP 请求，consumed_ids列表不能只活在内存里，进程重启就没了。存在 Redis 里，按session_id隔离，对话结束后设 TTL 自动清理。这不是可选的优化，是方案能跑通的前提。

什么时候关掉去重

用户明确说“再给我看看刚才那个”的时候，需要临时关掉。在意图识别层做区分——追问细节和要求新信息是两种不同的意图，不能用同一套处理逻辑。

这套方案能覆盖什么，不能覆盖什么

group_by+expr两层组合，解决的是推理侧的重复问题：同一次检索里不出现来自同一文档的多个 chunk，跨轮次不重复召回历史文档。

但有一件事它做不到：它不知道某个 chunk 被召回后模型是否真正用到了它，更不知道它对最终答案的贡献有多大。VimRAG 的 MMG 能追踪每个检索节点对答案的实际贡献度，精度在这一层上更高。

如果业务对检索准确性要求很高，VimRAG 的完整方案值得研究。如果优先要一个改动量小、能快速上线的解法，group_by+expr+ Redis 这套组合够用。

04 

写在最后

多轮 RAG 里的重复召回不是一个显眼的故障，但会严重影响用户的实际交互体验。

工程上，我们的最小改动方案是：给文档加 ID 字段，search()时带上group_by_field保证单次结果不重复，跨轮次用expr not in排掉历史文档，consumed_ids存在 Redis 里按 session 隔离。改动分散在几个地方，每一步都独立生效，不需要一次全上。

当然这个方案在RAG场景中不是必须的。什么时候不需要做？比如知识库很小、用户绝大多数是单轮交互、或者对话很少超过三轮。这几种情况下，重复召回的影响不足以支撑引入额外的状态管理复杂度，先不动。等多轮对话占比上来、或者留存数据开始出现第三四轮的明显断崖，再回来做这件事，时机更对。

作者介绍

Zilliz黄金写手：尹珉

文章来自于"Zilliz"，作者 "尹珉"。