RAG里Agent多轮查询后上下文爆炸，大家都是怎么处理的？

试试query改写吧，把历史关键信息揉进当前问句再检索，能省不少token，上下文压力也小。

这个坑我太熟了，当时做客服问答Agent差点被上下文撑死。后来我把策略拆成两层：第一层是query改写，用LLM把“他们的毛利率”这种指代还原成“A公司2023年财报中的毛利率”，同时只把改写后的query喂给检索器，不塞历史原文，相关性立马稳了。第二层是记忆压缩，每轮对话结束后让LLM把历史信息浓缩成一个动态的“业务摘要”，比如“用户关注A公司财报，特别在意毛利率和现金流”，下次检索时把摘要和当前query拼接，这样既保住指代又不占太多token。但要注意摘要别越滚越长，我设了个上限，超过就强制丢弃最老的信息，或者用向量存摘要做二次检索。还有个土办法，就是给每轮检索结果打时间戳，最后拼接时按相关度排序再截断，别按时间顺序硬塞，实测能省不少context。另外你试过把历史query单独建一个循环缓冲区吗？只保留最近三到五条，但每条都做指代消解后再存，比纯截断效果好很多。核心思路是别让LLM去历史里找线索，而是把线索提炼好再给它。

我们之前也踩过这个坑，后来改成把历史对话先做一轮轻量级的query改写，只提取当前问题里需要的实体和指代，再跟原始query拼一起检索。比如“他们的毛利率”会先解析出公司名再搜，效果比硬塞历史好不少。另外检索结果回来后会做个重排，只保留跟当前问题最相关的top3，context窗口压力小很多。目前试下来多轮对话稳定性还行，但指代太模糊的时候还是会翻车，同求更稳的记忆压缩方案。

我之前做类似项目也踩过这坑，后来是把历史query先过一遍轻量级改写，只提取当前问题里的指代实体和意图，再拼上最近一轮的有效信息去检索。上下文窗口那边，我习惯给历史对话设个token预算，超出就把早期轮次压缩成摘要存起来，这样既不丢关键指代，也不会让chunk被噪声干扰。不过摘要生成本身也有延迟成本，你要是对实时性要求高，可以试试用向量库里存对话状态，动态取相关记忆。

我们之前也踩过这个坑，后来是把历史query先做一轮轻量改写，比如把“他们的毛利率”补全成“A公司2023年毛利率”，只把改写后的当前query送检索，历史原文不进向量检索。上下文那块给LLM只保留最近两轮的必要摘要，不然真的会被无关chunk带偏。

不过摘要做得太狠又容易丢关键指代，我现在在试分层记忆，长期事实存向量，短期对话状态单独维护，检索的时候只带跟当前意图强相关的记忆片段。你们有试过把历史query按实体关系拆开存吗？感觉对多跳追问可能比单纯截断更稳。

我们也踩过这个坑，后来改成用LLM先做一步query改写，把“他们的毛利率呢”这种指代补全成独立query，再去检索，历史就不需要全塞进去了。另外检索完可以加个轻量rerank，只留top3 chunk，context压力小很多。记忆压缩那块可以试试把历史对话摘要成一句事实，比原始对话省token也不容易丢指代。

我们之前也踩过这个坑，后来在检索前加了一层query改写，用LLM把“他们的毛利率”补全成“A公司毛利率”，只拿改写后的query去检索，历史对话不直接进检索器。历史上下文单独做摘要压缩，每轮只保留跟当前问题相关的实体和意图，塞给生成模型时控制在一定token内。这样指代能保住，检索相关性也不会被稀释。你可以试试把“改写”和“检索”解耦，别让历史query直接参与向量匹配。

我们之前也踩过这个坑，后来改成先用小模型把指代消解掉再检索，比如“他们的毛利率”直接改写成“A公司毛利率”，历史query就不往里塞了。另外检索结果用rerank卡个阈值，别一股脑全塞给LLM，留够空间给回答。记忆压缩的话可以试试把历史对话总结成结构化slot，比纯截断稳很多。