RAG+Agent框架下，多轮对话后知识库检索结果漂移怎么破？

试试把第一轮的关键实体抽出来拼进当前query，比整段历史靠谱，成本也低。

我们这边是直接限定第二轮只查退款相关子库，意图识别比改写query稳多了。

这个问题我最近刚好也踩过类似的坑，尤其是Chroma这种纯向量检索的，历史对话一拼进去，embedding平均化之后关键实体权重全被稀释了。我的做法是干脆把多轮检索拆成两步，先用一个轻量级意图分类模型判断当前追问是对全局政策还是对上一轮实体细节的补充，然后决定是重新检索还是基于上一轮结果的局部过滤。另外重排这块我试过用cross-encoder对召回切片和“改写后的query”做联合打分，比单靠向量相似度靠谱不少，但确实对延迟敏感。你提到的LLM改写不稳定，我怀疑是prompt里没显式强调“保留实体和约束条件”，比如“退款”这种核心词得强制保留，不然改写模型容易自由发挥。还有个偏方是给每个切片打上会话标签，检索时用metadata过滤掉跟当前意图不相关的文档块，这样即使query漂移，召回范围也被锁死了。你现在这个场景如果客服对话轮次普遍比较短，我觉得先意图识别再决定检索范围可能是投入产出比最高的路径，毕竟改写和重排的调参成本都不低。

试试先意图分类再决定要不要带历史，比硬拼query靠谱，重排也能兜底。

我们生产里是压缩关键轮次信息回填query，成本低且漂移少，你可以试试。

我之前也踩过这个坑，后来是把历史对话用LLM单独抽成结构化意图和关键实体，再拼到检索query里，比直接塞原文好很多，不过成本确实高。现在生产上用的是轻量级改写加一层规则兜底，比如检测到“到账”这类词就强制关联最近提到的退款单号，效果稳定不少。

其实重排策略我试过，能缓解但治标不治本，核心还是得让检索范围带上明确的约束条件。你那个意图识别再决定检索范围的思路我觉得挺对，可以试试先分几个大类走不同索引，比硬靠Embedding理解多轮上下文靠谱。另外Chroma那边可以试试按会话维度做metadata过滤，有时候比改写更省事。

我们之前也踩过这个坑，后来把对话历史做了个轻量级压缩，只保留当前话题相关的实体和意图，再拼进query，效果比全量拼接稳不少。不过最终还是上了意图识别那步，先判断用户是不是在追问上一轮，是的话就缩小检索范围到对应文档集，召回率提升挺明显的。你那个query改写延迟高，可能是prompt太重了，试试让模型只输出改写后的query，不加任何解释。

多轮漂移本质上是embedding对上下文敏感度不够，重排只能救急。我们后来干脆把历史对话转成结构化槽位，比如用户提到的政策类型、时间点、金额这些关键字段，检索时优先匹配槽位再补充语义，成本比每次让LLM改写低多了。如果你用的是Chroma，可以试试按时间戳给切片分组，追问时强制带上前一轮的文档ID做过滤。

我是直接放弃了拼历史进embedding，改成先用LLM做一个极简分类，判断当前query是全新问题还是追问。追问的话就取上轮命中的top5切片做关键词交集，再拿去检索，效果出奇好，而且只多花一次小模型调用的延迟。你那个重排策略有用的话可以分享下具体怎么做的吗？我们试过cross-encoder但太慢了。

你这问题我们当时也卡了很久，最后是用了混合检索，向量召回和BM25并行

试过把历史对话按窗口截断后单独embedding再加权融合，效果比直接拼query稳一些，你可以试试。

重排是真有用，但得先把候选集扩到20+再精排，不然漂移了也救不回来。

我们之前也踩过这个坑，后来是把历史对话压缩成带权重的实体和意图标签，再拼到query里做二次检索，比直接拼全量历史稳很多。重排模型确实能救回来一部分，但得控制好候选集数量，不然延迟扛不住。你那个LLM改写不稳定的问题，我们试过用更小的模型专门做改写，配合规则兜底，成本能降一半，你要不试试？