RAG+Agent架构下，多轮对话历史到底该不该进向量库？

个人觉得对话历史不该一股脑塞进向量库，query改写加滑动窗口是更稳的路子。我之前试过把最近两轮的关键实体抽出来拼到当前query里，召回效果比纯重写好不少。至于embedding混存，建议单独建个短期记忆索引，设个TTL自动清，不然历史语义真会把知识库的向量空间带偏。你们有没有试过用LLM直接判断指代然后生成伪query？有时候比规则改写靠谱。

对话历史真别直接拼，噪声太大我踩过坑。现在做客服场景是先跑一轮轻量指代消解，只把改写后的query拿去做检索，历史本身不进向量库，单独放个内存buffer滑窗存最近三轮就够用了。重写这步确实容易飘，可以加个阈值，改写置信度低就退回原文。另外历史embedding跟知识库混存会干扰相似度分布，建议分两个索引，线上查完再merge结果。

对话历史别塞向量库，用LLM重写query时限定只补指代，别让它自由发挥。

我们之前也踩过这个坑，后来干脆把对话历史和知识库向量分开存，检索时只把历史做指代消解和query重写，不直接拼进向量搜索。滑动窗口加轻量重排序确实有用，但窗口别开太大，三四轮就够，不然噪声压过信号。你说的重写语义飘，可以试试用few-shot约束输出格式，或者干脆让LLM只做指代替换别自由发挥。历史embedding单独存一个collection，别跟知识库混，不然召回真的会乱。

这个问题我也踩过坑，说点实际感受。把对话历史直接拼进query再检索，基本等于往索引里灌噪声，尤其是历史里出现过相似词但不同意图的时候，召回结果会跑偏得很离谱。我现在更倾向于先做一轮轻量的query改写，但不是让LLM自由发挥，而是限定它只做指代消解和省略补全，比如“那第二个方案呢”改成“XX产品的第二个方案是什么”，这样检索目标明确很多。历史embedding我是不建议跟知识库混在一个索引里的，污染太严重了，检索分数会被历史里那些高频但无意义的对话拉偏。我自己的做法是知识库一个collection，对话记忆单独存，检索时先走知识库，记忆模块只用来做query重写和结果重排的上下文补充。滑动窗口+重排序确实有用，但窗口别开太大，三轮左右就够了，再长反而引入旧意图干扰。另外重写后的query最好跟原始query做一次相似度校验，差太多就回退到原始query，不然真的会很飘。