RAG+AI Agent做多轮对话，上下文检索总丢关键信息怎么办？

我之前也踩过这个坑，后来发现关键不在检索本身，而是得先做查询改写。你那句“运费谁出”单独丢给检索肯定只抓“运费”，得让模型结合历史把它重写成“退货产生的运费由谁承担”，再拿去搜，命中率完全不一样。重排序也可以加一层，但优先级没改写高。另外chunk重叠32有点小，多轮场景下上下文本来就碎，可以试试按语义切而不是死磕固定长度。

试试查询改写，把“运费谁出”补成“退货的运费谁承担”再检索，会好很多。

我之前也踩过这个坑，拼历史对话确实不太行，语义会被稀释。后来改成先用LLM把“那运费谁出”改写成完整问题再检索，效果立竿见影。另外重排序那步加上bge-reranker也很有用，能救回不少被chunk切碎的关键信息。还有个思路是用Agent做query规划，把多轮意图显式拆出来再分别检索，比单纯堆历史靠谱。

试试查询改写，把“运费谁出”补成“退货的运费谁承担”，再检索就准多了。

你这个场景我太熟了，之前做售后Agent也踩过一模一样的坑。核心问题不在检索本身，而是多轮里的指代和省略没被还原成独立查询，像“那运费谁出”单独扔给检索器，它当然只认运费。我的做法是加一层查询改写，用小模型把当前问题结合最近两三轮历史重写成完整问句，比如变成“退货流程中运费由谁承担”，再去检索，命中率立马不一样。拼接历史再检索确实容易语义稀释，历史越长噪声越大，还挤占token，不如只保留关键实体和意图做压缩。重排序也值得加，先粗召回20条再用bge-reranker精排，能把真正相关的顶上来。至于换框架，我觉得先别急着动，LangChain或者自己写个轻量Agent都能解决，问题在检索链路设计而不是框架本身。另外chunk 512对客服场景偏大，试着降到256左右，重叠拉高一点，边界信息保留会更好。

有没有更详细的教程推荐？

学到了，感谢分享！

这个问题我踩过，多轮对话里“那运费谁出”这种指代和省略特别容易翻车，光靠拼历史确实治标不治本。我的经验是查询改写优先级最高，让一个小模型先把当前问题改写成自包含的独立查询，比如补成“退货流程中运费由谁承担”，再拿去检索，效果立竿见影。但改写也有坑，改写过头会引入原对话没有的假设，得加个校验或者让改写模型保留原词。另外重排序值得加，用bge-reranker对召回结果按“与完整对话意图的相关性”重排，比单纯向量相似度稳不少。chunk 512重叠32其实偏小，退货这类流程知识容易被切碎，可以试试按语义分段或者加大重叠。还有个思路是给Agent加个会话级记忆槽，把“当前主题=退货”显式存下来，检索时做元数据过滤，比纯语义匹配靠谱。换框架倒不至于，LangChain或LlamaIndex都能实现，关键是把查询改写和记忆管理这两层补上。你试过用LLM做指代消解吗，那个对“那运费谁出”这种短追问特别管用。