RAG+Agent做多轮对话时，历史记录怎么塞才不会让检索变“智障”？

试试让LLM先做query改写，把指代消解成独立问题再检索，历史只保留跟当前意图相关的片段，别全塞进去。

试试让LLM先把指代消解成独立query再检索，历史只留事实别留问题，效果会稳很多。

我踩过一模一样的坑，后来直接放弃拼历史，改成让LLM先做一步query改写，把指代和省略补全成独立问题再去检索。你可以试试用流式对话里的最近两轮加一个“当前轮”组合提示词，让模型输出“用户真正想问的完整问题”，效果比硬拼好很多。

另外历史不是越多越好，建议给每轮对话打个时间或主题标签，检索时只取跟当前query语义最相关的片段，再让LLM决定要不要追加上下文。你可以给改写加个置信度阈值，不确定时就回退到只拼当前轮，至少不会跑偏太远。

我最近也在搞这个，踩过一样的坑。后来改成先用LLM把当前问题和历史对话压缩成一个独立的“查询意图”，再拿这个去检索，效果好很多。你可以试试把历史里跟当前问题相关的实体和条件提取出来，拼成一句完整的话，别一股脑全塞进去。另外历史轮次真不是越多越好，我试过带权重的滑动窗口，最近几轮给高分，老早的只保留关键信息，这样检索漂移少多了。

我们团队之前也踩过这个坑，后来改成把历史对话先让LLM做一轮query改写，只抽当前问题对应的实体和意图，再拿改写后的query去检索，效果比直接拼历史稳很多。另外建议给历史轮次加个权重，比如最近两轮全量保留，更早的只保留关键实体，这样既不会丢上下文，也不会让老问题干扰检索。你可以试试看，改写的prompt里明确要求“忽略已解决的主题”。

先让LLM把历史对话压缩成当前问题相关的背景，再拿这个去检索，效果会稳很多。

我之前也踩过这坑，光拼历史query确实容易跑偏。后来改成先把历史对话压缩成“用户当前诉求摘要”，再和当前问题拼一起去检索，效果好很多。另外建议把指代消解单独拎出来做个步骤，直接用LLM判断哪些历史信息是当前真正需要的，别全塞进去。

还有个思路是给历史片段加时间权重，近几轮的高亮，远的就只保留实体和意图，这样检索时不会一锅烩。不过具体还得看你知识库的粒度，如果文档太长，摘要反而会丢关键细节，多试试不同方案吧。

先让LLM把指代补全成独立query再检索，历史只用来改写别直接塞。

我也踩过这个坑，全塞历史确实容易把检索带偏。后来改成先用小模型做query改写，把“那它价格呢”补全成“XX产品的价格是多少”，再拿改写后的query去检索，效果稳很多。另外历史也不是全丢，一般保留最近3-5轮加一个摘要就够了，太老的对话对当前检索基本是噪音。你们那边有没有试过让LLM先判断这轮要不要检索？有些寒暄或追问其实不用走RAG。

这个问题我踩过坑，说下我的做法。直接拼历史确实容易让检索跑偏，因为embedding会把历史里的关键词权重拉高，当前query反而被稀释了。我现在是用LLM做query改写，但只让它参考最近一两轮，把“那它价格呢”这种指代消解成完整的独立问题，再去检索。关键是改写那步的prompt要限制它别过度发挥，不然会把用户没问的东西也塞进去。另外我会在检索时给当前query更高的权重，历史只作为改写素材而不是直接参与匹配。还有个思路是做意图路由，先判断这轮是不是依赖上下文，如果是就改写，不是就直接检索。截取两轮确实不够，我一般保留最近三轮加一个摘要，摘要用LLM压缩成一句话背景。这样既不会丢上下文，也不会让老问题干扰检索。

我一般让LLM先改写query再检索，历史只给最近三四轮，效果还行。

让LLM先把“那它价格呢”改写成完整问题再检索，比硬塞历史强多了。

用LLM先把指代补全再检索，别直接拼历史，不然query里全是噪音。

这个问题我们踩过坑，后来改成先用小模型把当前query改写成一个自包含的问句，把“它”“那个”替换成历史里对应的实体，再去检索，效果好很多。直接拼历史最大的毛病就是检索器分不清主次，老问题权重太高。另外改写那步别用太贵的模型，qwen或者gpt-4o-mini就够，主要成本在延迟上。

我也被这个问题折磨过，后来改成先用小模型把“那价格呢”这类问题改写成独立query再检索，效果稳不少。不过改写模型本身也会抽风，尤其是历史里有多个人称代词的时候。现在我是改写+只取最近三轮，再加一个意图分类判断要不要带历史，感觉比硬塞强。你们有没有试过让Agent自己决定什么时候该查历史、什么时候直接检索？

试试用LLM先把“那它价格呢”改写成完整问题再检索，别直接拼历史。

我之前也踩过这个坑，全塞进去确实容易让检索跑偏，模型老盯着历史里的关键词不放。后来改成先用小模型把指代消解掉，比如把“那它价格呢”补成“XX产品的价格是多少”，再拿去检索，效果稳不少。不过改写这步也有风险，有时候会把用户原意改歪，得加个兜底逻辑。你们有没有试过把历史摘要和当前query拼一起检索？感觉比全量拼接要轻一些。

这个问题其实挺典型的，我踩过类似的坑。你说的全量历史拼接导致检索跑偏，本质上是query里掺了太多“噪声语义”，向量检索会把历史里那些高频词也当成当前意图的一部分。我现在的做法是用一个轻量LLM先做query改写，只拿最近一两轮对话加上当前问题，让它输出一个消解了指代的独立检索query，比如“那它价格呢”会改写成“XX产品的价格是多少”，然后再去检索，效果比直接拼历史好很多。但改写也有风险，有时候LLM会脑补出用户没说的实体，所以我会在prompt里明确要求“只消解指代，不要引入新信息”。另外历史记录不是完全丢掉，而是作为生成阶段的context塞给LLM，检索阶段只用改写后的query，这样检索和生成解耦，跑偏概率小很多。还有个细节是改写后的query可以保留原始query做混合检索，用RRF融合一下，召回会更稳。你们现在是用什么向量库，支不支持多路召回融合？这个方案对指代问题效果挺明显的，可以试试。

先让LLM把“那它价格呢”改写成完整问题再检索，比硬塞历史靠谱多了。

学到了，感谢分享！