做 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(urihttp://localhost:19530) consumed_ids [doc_001, doc_017, doc_042] res client.search( collection_namerag_chunks, data[query_vector], limit5, filterdoc_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 会同时出现在结果里占掉limit5里的三个名额。Milvus 的group_by_field参数解决的就是这个。在search()时传入group_by_field“doc_id”Milvus 会保证每个文档 ID 最多返回一个 chunk自动选取该文档下相关性最高的段落res client.search( collection_namerag_chunks, data[query_vector], limit5, group_by_fielddoc_id, output_fields[doc_id, text] )这一层是无状态的——不需要维护任何跨轮次的列表在查询时直接保证结果多样性。路径三两者组合覆盖完整的去重链路group_by解决单次检索内的文档级重复expr解决跨轮次的历史重复。两个一起用才是这个场景下完整的解法res client.search( collection_namerag_chunks, data[query_vector], limit5, group_by_fielddoc_id, filterdoc_id not in [doc_001, doc_017, doc_042], output_fields[doc_id, text] )第一个参数保证这一轮结果里不出现来自同一文档的多个 chunk第二个参数保证历史轮次已经用过的文档不再出现。这两个功能合起来能覆盖 VimRAG 在推理侧解决的重复访问问题——但没有覆盖 GGPO 在训练侧解决的信用分配问题。但这本质上是两件不同的事一个在改训练信号一个在改检索输入。能用工程手段在推理侧处理的先用工程手段处理掉不一定每个团队都需要走到重训模型那一步。03真正部署时这几个地方容易翻车最小可行方案是上一章节的三层组合生产落地还有几个细节绕不过去。去重记录的粒度怎么选用了group_by_fielddoc_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_byexpr两层组合解决的是推理侧的重复问题同一次检索里不出现来自同一文档的多个 chunk跨轮次不重复召回历史文档。但有一件事它做不到它不知道某个 chunk 被召回后模型是否真正用到了它更不知道它对最终答案的贡献有多大。VimRAG 的 MMG 能追踪每个检索节点对答案的实际贡献度精度在这一层上更高。如果业务对检索准确性要求很高VimRAG 的完整方案值得研究。如果优先要一个改动量小、能快速上线的解法group_byexpr Redis 这套组合够用。04写在最后多轮 RAG 里的重复召回不是一个显眼的故障但会严重影响用户的实际交互体验。工程上我们的最小改动方案是给文档加 ID 字段search()时带上group_by_field保证单次结果不重复跨轮次用expr not in排掉历史文档consumed_ids存在 Redis 里按 session 隔离。改动分散在几个地方每一步都独立生效不需要一次全上。当然这个方案在RAG场景中不是必须的。什么时候不需要做比如知识库很小、用户绝大多数是单轮交互、或者对话很少超过三轮。这几种情况下重复召回的影响不足以支撑引入额外的状态管理复杂度先不动。等多轮对话占比上来、或者留存数据开始出现第三四轮的明显断崖再回来做这件事时机更对。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】