最近在搭一个客服Agent,用的RAG方案。目前做法是把用户query和检索到的文档一起丢给LLM,但多轮对话一长就出问题:用户说“那第二个方案呢”,系统完全不知道指代什么。我试过把对话历史拼进query再检索,结果召回的全是历史里的噪声,相关性反而变差。也试过单独维护一个记忆模块做重写,但重写后的query跟原文语义差太多,检索结果很飘。想请教各位,实际生产里多轮对话的上下文是怎么跟RAG结合的?是单纯拼历史,还是先做指代消解再检索?有没有更工程化的做法(比如滑动窗口+重排序)?另外,对话历史的embedding要不要单独存?跟知识库的向量混在一起会不会污染索引?
楼主
20天前
RAG+Agent架构下,多轮对话历史到底该不该进向量库?
请 登录 后发表回复
全部回复
共 22 条
2楼
5天前
个人觉得对话历史不该一股脑塞进向量库,query改写加滑动窗口是更稳的路子。我之前试过把最近两轮的关键实体抽出来拼到当前query里,召回效果比纯重写好不少。至于embedding混存,建议单独建个短期记忆索引,设个TTL自动清,不然历史语义真会把知识库的向量空间带偏。你们有没有试过用LLM直接判断指代然后生成伪query?有时候比规则改写靠谱。
3楼
4天前
对话历史真别直接拼,噪声太大我踩过坑。现在做客服场景是先跑一轮轻量指代消解,只把改写后的query拿去做检索,历史本身不进向量库,单独放个内存buffer滑窗存最近三轮就够用了。重写这步确实容易飘,可以加个阈值,改写置信度低就退回原文。另外历史embedding跟知识库混存会干扰相似度分布,建议分两个索引,线上查完再merge结果。