最近在折腾MCP,给本地知识库接了个向量数据库(用的Qdrant),配合embedding模型做RAG。单轮问答效果还行,但一旦对话轮次超过5-6轮,或者用户提问里包含前几轮提到的实体,检索出来的chunk就跑偏了。我目前是把历史对话拼接后一起embedding再查,不知道是不是这个策略有问题?感觉上下文一长,向量空间里语义就被稀释了。有没有大佬遇到过类似情况?是应该对历史对话做压缩/摘要,还是改用混合检索(比如BM25+向量)更稳?另外MCP server这边有没有什么推荐的中间层处理方案?刚入门,求指点,别喷。
楼主
2026-08-16
MCP+向量数据库做RAG,上下文一长检索质量就崩,有办法救吗?
请 登录 后发表回复
全部回复
共 64 条
2楼
2026-09-20
历史对话别直接拼,先摘要再检索,混合检索也加上,稳很多。
3楼
2026-09-21
拼接历史对话再embedding确实容易把语义搞糊,越拼越像一锅粥。我一般只拿最近一两轮加上当前问题去查,再单独用LLM把更早的对话压成一句摘要带进来,效果好不少。混合检索也值得上,实体类的query靠BM25兜底比纯向量靠谱。MCP那边可以在server里加个query改写层,先让模型把指代消解掉再检索。
4楼
3天前
刚入门,这个对我帮助很大。
5楼
3天前
把整段历史拼起来再embedding确实容易稀释语义,越聊越糊是正常的。我一般只保留最近一两轮原文,更早的做摘要或者抽取实体单独存,查询时用实体去boost对应chunk。混合检索挺值得上,BM25对专有名词和实体命中比纯向量稳很多,尤其是你这种带前文实体的提问。MCP这边可以在server里加一层query rewrite,先让模型把指代消解成独立问题再送去检索,效果会明显好一截。