前几天我一个同事去面三面嘛被问到一个看起来挺基础的问题。面试官问他RAG在单轮问答和多轮问答里面推理过程有什么区别他当时脑子里第一反应就是多轮不就是把历史对话拼接到prompt里面然后再走一遍检索加生成嘛。然后他就这么回答了。面试官笑了笑说嗯这是最表层的理解然后接着追问了三四个问题。他才发现自己漏掉的东西实在是太多了。查询到底该怎么改写啊要不要重新检索啊历史怎么管理啊答案怎么保证前后一致啊……这些东西根本不是拼历史三个字就能概括得了的。面完之后他跟我吐槽越想越不甘心。我俩干脆就把这块知识彻底啃了一遍整理成这篇文章。也算是帮大家避个坑吧。如果面试官问你这个问题的话千万别只回答拼接历史对话这个答案说出来基本就等于交白卷了。真正的答案是什么呢多轮RAG它不是单轮RAG的简单叠加而是从无状态的一次性任务变成了有状态的序列决策问题。下面就把这中间的差异掰开揉碎来讲清楚。先说结论单轮RAG的推理链嘛就是一条直线。问题 → 检索 → 生成 → 回答多轮RAG就要多绕好几道弯了。问题 历史对话 ↓是否需要重写(指代消解/补全信息) ↓改写后的独立查询 ↓是否需要重新检索 ↓ 是 ↓ 否 检索 复用历史检索结果/上文 ↓ ↓ └──────────┬──────────────┘ ↓ 生成带一致性约束 ↓ 更新对话历史/记忆 ↓ 回答多出来的这几道工序包括查询改写、检索必要性判断、上下文管理、一致性维护这些才是多轮RAG真正的难点所在。下面来逐个拆解一下。✦ ✦ ✦一、查询理解从直接用到先重构在单轮场景下面呢问题本身就是完整的、自包含的直接拿原始query去检索就行了。比如说用户问RAG中的检索器一般用什么模型。这个语义是完整的没有歧义直接去检索就好。但是多轮场景下就不一样了。轮1 用户RAG中的检索器一般用什么模型轮1 助手常用的有BGE、E5、GTE等双塔embedding模型...轮2 用户那生成端呢轮3 用户它和第一种比有什么优势轮2用户说的那生成端呢你字面上去检索生成端这个词的话几乎查不到什么有效内容。因为它省略了主语和真实意图嘛。所以必须先把它重写成RAG中的生成端一般用什么模型轮3就更麻烦了。“它和第一种都是指代需要结合前两轮的内容才能把它重写成BGE模型和E5模型相比有什么优势”这一步通常叫做查询重写也就是Query Rewriting。有两种做法。一种是用规则或者小模型来做指代消解。比较轻量但是遇到复杂的指代就容易出错。另一种是让LLM来做query rewriting。把完整的对话历史喂给LLM让它输出一个独立完整的查询。效果会更好但是会多一次LLM调用的延迟和成本。这一步要是做不好的话后面的检索就全盘皆输了。这是多轮RAG里面最容易翻车的环节。✦ ✦ ✦二、检索必要性判断不是每轮都要查来看个例子。轮1 用户介绍一下Transformer的注意力机制轮1 助手检索生成介绍了Q/K/V计算方式轮2 用户能不能用更通俗的话再讲一遍轮2这种换个说法或者换个角度重讲的追问其实是不需要重新检索的。直接基于轮1已经检索到的文档或者说轮1的回答本身来做二次生成就行了。重新检索反而有可能召回不相关的内容还浪费检索开销。但是下面这种情况就需要重新检索了。轮2 用户那BERT和它有什么区别这里引入了一个新的实体叫BERT原来检索到的结果里面大概率是没有的所以必须触发新一轮的检索。所以说多轮RAG系统里面通常会加一个路由判断步骤可以用规则也可以让LLM做个二分类。先判断一下这一轮到底是需要检索新的知识呢还是复用已有的上下文就够了✦ ✦ ✦三、上下文管理历史会发胖假设对话进行到第10轮了你直接把10轮的原始问答加上每轮检索到的文档全部塞进prompt的话很容易就超出上下文窗口了。而且大量的无关信息会稀释模型的注意力导致生成质量下降。这个就是常说的lost in the middle问题。常见的有三种处理方式。第一种是滑动窗口。就是只保留最近N轮的原始对话更早的直接丢弃掉。第二种是摘要压缩。把原始的历史通过LLM做一个摘要把2000字压缩成100字左右。原始历史10轮2000字 ↓ LLM摘要用户先了解了RAG检索器和生成器的基本模型选型 目前正在讨论BGE和E5的优劣对比100字第三种是检索历史本身。就是把每一轮的问答也存进向量库里面新问题来了不是无脑地塞入全部历史而是也去检索历史中相关的几轮。这样即使对话很长也只取相关的片段。本质上就是套娃嘛既检索文档库也检索对话历史库。✦ ✦ ✦四、生成阶段多了一致性检查单轮的坑呢就是只需要管这一次的答案是不是准确、有没有幻觉就行了。多轮还有一个额外的坑就是前后矛盾的问题。轮2 助手BGE模型是智源研究院发布的......轮7 用户你之前说的那个模型是谁发布的轮7 助手若重新检索命中了不同版本的文档E5模型是微软发布的...如果轮7检索命中的E5的文档而不是BGE的比如说查询改写出错了“那个模型被消解错了指代对象那就会产生答非所问而且跟自己历史发言矛盾的回答。用户体验上比单轮的一次性错误还要糟糕因为看起来就像是AI记性差、前后不一致”。解决的办法通常是在生成的时候把历史回答也作为约束条件放进prompt里面明确要求说如果本轮问题跟历史提到的实体相关的话要保持指代和结论的一致性。✦ ✦ ✦五、误差传播滚雪球效应这是多轮独有的、也是最麻烦的一个问题。我们来完整看一遍这个链路。轮1 用户李四是哪年出生的 → 检索准确回答1985年轮2 用户那他是哪里人 → 查询重写错误他被消解成了另一上下文中偶然出现的人名 → 检索到错误文档 → 回答张三山东人答非所问且实体错乱轮3 用户他现在多大了 → 基于轮2已经错误的上下文继续推理 → 错误被放大可能给出张三的年龄也可能把两人信息混在一起单轮系统里面一次查询错了的话用户重新问一次就能纠正了互相不影响。但是多轮系统里面呢上一轮的错误会成为下一轮改写和检索的输入。如果没有纠错机制的话错误就会像滚雪球一样越滚越大。所以说比较严谨的多轮RAG系统会加两道保险。一个是置信度检测。如果检索结果和改写后的query相关性得分很低的话就主动去澄清而不是硬答。比如说反问一下您是指李四还是张三另一个是每轮独立验证。生成答案之后用检索到的文档反向去验证答案里面的实体、事实是不是真的能在文档里面找到支撑。相当于一个轻量的fact-checking环节。✦ ✦ ✦写在最后回头看那场面试的话拼接历史对话这个回答本身是没错的。但是它只说对了最表层的操作完全没有触及到问题的核心。真正能体现你有没有做过多轮RAG工程实践的是下面这几点。你有没有意识到查询需要重写而不是直接拿原始问题去检索。你知不知道不是每一轮都要重新检索判断检索必要性能省掉大量的无效开销。你会不会处理历史发胖的问题是用滑动窗口、摘要压缩还是二次检索。你有没有考虑过生成结果的跨轮一致性避免前后矛盾。你知不知道多轮里面的错误会滚雪球式地传播要不要加纠错和置信度检测机制。用一句话来总结的话单轮RAG做的是静态的语义理解多轮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%免费】