京东面试官：多轮 RAG 为什么越聊越蠢？
这课接着拆多轮——售后客服里用户先问手机退货，又切到电脑保修，系统还带着"退货"去查电脑保修条款，怎么救？
先把术语翻成人话
history：之前几轮聊过的内容
current query：当前这一问
query rewrite：把指代补成完整问题
context：喂给模型的资料
session trace：整段对话的逐轮记录
一、面试现场
面试官提问
“多轮RAG为什么越聊越蠢？”
京东：多轮对话一面。候选人答了三分钟，思路是"把所有历史一起丢给模型"。面试官追了一句："用户已经从手机切到电脑了，retrieval query 用什么？"候选人卡住了。这道题看似在问历史压缩，实际在考你能不能区分"当前意图"和"历史上下文"——retrieval 走前者，生成才看后者，混成一锅就是答非所问。
直接回答：跑偏是历史污染了当前问，只认当前意图加硬约束。
二、大多数人怎么答的
典型翻车回答
“多轮对话只要把聊天历史全部塞进 prompt，模型自然能理解上下文。”
带历史有一半对——"那这个呢"这类指代确实需要补上下文。但不能把所有历史都塞进检索 query，历史越长，旧主题越容易抢走当前意图。500 轮匿名客服样本里，全量历史检索的跑偏率 18%，只继承硬约束后降到 7%。
多轮 RAG 的主语永远是当前问题——历史只保留用户明确确认过的硬约束（订单号、产品名、地区），其余的旧结论、闲聊、已改口内容都要丢；否则旧主题会反向抢走检索方向。
三、深度解析（判断框架）
我会把"多轮 RAG"拆成四个判断点：四个对象分开、检索只继承硬约束、rewrite 要可降级、任务切换要重置。
判断 1：四个对象必须分开——别揉成一个长 prompt
原始历史、当前 query、检索 query、生成 context 是四样东西：检索 query 只该带当前意图；生成 context 才需要历史细节；原始历史保留全文但不直接进检索。把这四样揉成一个长 prompt，就是"越聊越蠢"的根。关键在于：trace 里把这四样分四列存，bad case 一眼能看出是哪一环把意图带歪了。
判断 2：检索 query 只继承"硬约束"，不继承旧结论
硬约束 = 用户明确给过、且没改口的事实（订单号、产品名、地区、时间范围）。旧的检索结果、上一轮的结论、闲聊、已改口内容——全丢。我认为：与其让 LLM 自由改写历史，不如先做槽位抽取（slot filling）把硬约束抽成结构化字段，再拼成检索 query——可控、可审，比"信任改写模型"稳得多。
判断 3：history-aware rewrite 收益大、风险也大，必须可降级
收益是指代消解（“那这个呢” → “电脑保修条款怎么算”）；风险是把旧主题误带进来。
坑：改写后的rewrite_query跟current_query的实体重叠太低（说明用户其实换了话题），就降级为"只用当前问题检索"——宁可少补，不可乱补。截至 2026-05-12，LangChain 的 history-aware retriever 默认会把全部历史拼给改写 LLM，企业场景一般要自己加这个降级闸。
判断 4：任务切换必须重置历史
识别三类信号——“换个问题 / 刚才说错了 / 命名实体跟上一轮完全不重叠”，命中就把检索侧历史清空，只留当前问题。售后从"手机退货"切到"电脑保修"，旧的"退货"必须断掉，否则系统会拿"退货"去检索保修条款，跑偏率立马蹿上去。
排查顺序：先看检索 query 拼成了什么，再看历史该丢的丢没丢，最后看召回本身。trace 五列（turn_id/current_query/rewrite_query/retrieved_doc_ids/dropped_history）先有，再谈自动化。80% 的多轮 bad case 不是模型理解不了，是检索 query 拼错了——而你根本没存它拼成了什么。
四、面试官追问链
追问 1
“用户说’那这个呢’，query rewrite 应该补哪些历史？”
只补"指代指向的那个实体"，不补整段历史。“那这个呢"前一轮在问"电脑保修要不要钱”，“这个” = 电脑保修，rewrite 成"电脑保修的费用怎么算"就够了。不该补：再前面问过的"手机退货"、闲聊、上一轮的答案文本。
修复路径：改写 prompt 里只给"最近 1-2 轮 + 已抽取的硬约束槽位"，不要把整段对话史灌进去；改写完做一次实体校验——rewrite_query里出现的实体必须在"最近两轮 + 槽位"里能找到来源，找不到就丢掉。
追问 2
“为什么把全量历史放进检索 query 会降低召回？”
检索是按"query 向量跟文档向量的相似度"排序的。全量历史一拼，query 向量被一堆旧主题的词稀释——本来"电脑保修条款"该跟保修文档最像，现在混进了"手机 / 退货 / 订单号 / 客套话"，相似度被拉平，相关文档排不到前面。匿名样本里全量历史检索的hit@5明显低于"当前问题 + 硬约束"，跑偏率从 7% 涨到 18%。
定位方法：同一批 query 跑两版检索（全量历史 vs 当前+硬约束），对比 hit@k 和人工标注的相关性，差距一拉开就知道是历史在拖。
追问 3
“多轮 RAG 怎么做 session trace？”
按session_id把每一轮串起来，每轮记五样：turn_id/current_query/rewrite_query/retrieved_doc_ids/dropped_history（这轮丢掉了哪些历史）。排障时顺着 session 往回看：是 rewrite 把意图写歪了（看rewrite_query）、还是历史该丢没丢污染了检索（看dropped_history）、还是检索本身召回差（看retrieved_doc_ids）。我的优先顺序是：先保证rewrite_query一定落库（最常被漏的一列），再补dropped_history，最后才上自动的"跑偏检测"。
五、多轮跑偏排查实战
场景：售后客服 RAG，用户从"手机退货"切到"电脑保修"，系统还带着"退货"去检索，连续两轮答非所问。下面是一次完整的改造，每步先给动作、再给结果。
STEP 1 · 标记当前意图
每轮先判断是不是延续上一轮：意图切换信号（“换个问题” / “刚才说错了” / 命名实体跟上一轮完全不重叠）命中就重置检索侧历史。
↳ 结果：售后从手机退货切到电脑保修时，"退货"不再被带进检索。
STEP 2 · 抽取可继承的硬约束
用槽位抽取把订单号、产品名、地区、用户已确认事实抽成结构化字段，只有这些进 rewrite，其余历史一律不进 retrieval query。
↳ 结果：检索 query 短而准，hit@5 回升。
STEP 3 · 检索前审查 rewrite
rewrite_query跟current_query的实体重叠太低，就降级为"只用当前问题检索"。宁可少补，不可乱补。
↳ 结果：用户换话题时不再被旧主题污染。
STEP 4 · 留 session trace
每轮存turn_id/current_query/rewrite_query/retrieved_doc_ids/dropped_history五列。
↳ 结果：bad case 一眼定位是 rewrite 跑偏、历史污染还是召回差。
↳ 改造数字
匿名客服样本 500 轮复盘（示意口径）：全量历史检索跑偏率18% → 7%；"用户改口未识别"占剩余跑偏 case 的31%。没动模型，靠"检索只认当前意图 + 硬约束"和任务切换重置救回来。
我的判断
我的优先顺序是：先把检索 query 跟生成 context 拆开（最便宜、最见效），再做硬约束槽位抽取，最后才上 history-aware rewrite——而且必须带"实体重叠太低就降级"的闸；rewrite 没有降级闸，宁可不上。
六、本课总结
一句话总结
多轮 RAG 越聊越蠢，不是模型突然变笨，是历史压缩 / query 改写 / context 选择把当前意图污染了——检索只认当前问题加用户确认的硬约束，旧话题该丢就丢。
面试锦囊
先说：跑偏的根是"四个对象（历史 / 当前 query / 检索 query / 生成 context）混成一锅"——检索 query 只该带当前意图。
再说：检索 query 只继承硬约束（订单号 / 产品名 / 地区），旧结论、闲聊、已改口内容全丢；history-aware rewrite 收益是指代消解、风险是带歪意图，必须带"实体重叠太低就降级"的闸；任务切换信号命中就重置历史。
最后补：session trace 每轮存current_query/rewrite_query/retrieved_doc_ids/dropped_history，bad case 一眼定位是 rewrite 跑偏还是历史污染。
判断 checklist
□ 检索 query 和生成 context 是不是分开拼的？
□ 进检索 query 的只有硬约束、没有旧结论和闲聊吗？
□ history-aware rewrite 有没有"实体重叠太低就降级"的闸？
□ 任务切换信号（换个问题 / 说错了 / 实体不重叠）有没有触发历史重置？
□ session trace 里有没有 rewrite_query 和 dropped_history 两列？
别再踩的坑
□ 把全量历史直接拼进检索 query——旧主题稀释 query 向量，召回掉、跑偏涨。
□ 用一个长 prompt 把历史 + 当前问题 + 检索结果全揉一起——分不清谁污染了谁。
□ history-aware rewrite 不设降级闸——用户换话题时被旧主题带歪。
□ 不存 rewrite_query——出 bad case 根本不知道系统拿什么去搜的。
适合谁 / 不适合谁 / 该怎么做
适合谁：已经有多轮客服、知识库问答或企业助手的团队，优先排这类"旧主题污染当前问题"的 case。
不适合谁：单轮检索还没稳定、连current_query和召回文档都没落库的团队，先别急着堆 history-aware rewrite，越早自动改写越容易把锅藏深。
该怎么做：已经在线的团队先把rewrite_query落库（最常漏的一列），跑一周看跑偏 case 集中在哪个环节；再拆检索 query 和生成 context；最后才上槽位抽取和 rewrite 降级闸。原型 demo 一开始就别让检索 query 跟生成 prompt 共用一个字符串，面试表达就用"当前问题是主语"收束，再举手机退货 → 电脑保修和跑偏率 18% → 7% 的数字。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～