RAG接入MCP后，检索质量反而下降了，是哪里出了问题？

这问题我也踩过，MCP多工具并行检索看着高大上，但子查询切分逻辑如果没做相关性加权，合并时很容易把强相关结果稀释掉。可以试试改成先按query意图路由到单一工具，或者给每个子查询结果加个分，按原query的embedding相似度重排再合并。另外bge对长文档切块敏感，MCP如果自动把段落再拆细了，召回漂移会更明显，建议检查下工具返回的文本块大小是不是和向量化时一致。

我之前也踩过类似的坑，MCP多路召回后直接拼结果确实容易把主题打散。你可以试试在合并前加一层重排，用cross-encoder或者rrf融合，别让子查询结果平权堆在一起。另外子查询拆得太碎也会丢原文，最好限制下拆分粒度，或者保留一路原始query直查向量库兜底。

子查询拆太碎确实容易丢主题，试试让MCP先做一轮粗排再合并，别各搜各的。

我之前也踩过类似的坑，感觉问题大概率出在MCP那层的query拆分和结果合并上，而不是RAG本身不行。你把一个完整query拆成多个子查询分头去搜，每个工具返回的top-k其实是各自视角下的局部最优，合并的时候如果没有一个统一的rerank或者加权策略，主题散掉几乎是必然的。尤其文件系统和数据库这两个源，语义分布差异挺大，bge-large-zh-v1.5对数据库那种结构化短文本的匹配本来就不如对段落文本敏感，混在一起排更容易把真正相关的那段挤下去。可以试试先让MCP只做路由，判断该走哪个工具，而不是无条件拆成多路并行，或者合并阶段加一个cross-encoder重排，把原始query和每段召回再算一次相关性。另外子查询的粒度也值得看看，拆得太细会丢上下文，拆得太粗又等于没拆。我现在更倾向于把MCP当成工具调度层，检索主链路还是自己控制，不然中间多一层抽象，调参和排查都变得很别扭。

我也踩过这个坑，MCP把query拆成子查询分别去文件系统和数据库搜，最后合并时缺少统一的rerank环节，主题散掉太正常了。你试试在合并结果后加一层重排序，用原来的query跟所有召回片段再算一次相似度，把跑偏的压下去。另外MCP那边的tool编排最好别让它自由拆query，给个明确的检索策略，比如先走文件系统再补数据库，不然子查询之间没有主次，最匹配的原文很容易被稀释掉。

我踩过类似的坑，问题多半出在合并环节而不是MCP本身。多路子查询各自召回后如果直接拼一起，没有统一打分和去重，主题肯定散，最相关的那段容易被淹没。建议给每个子查询结果加个加权融合，或者干脆先用原始query走一遍主检索，MCP只做补充召回。另外bge这类模型对query改写比较敏感，拆得太碎反而丢语义，可以试试让MCP少拆几路。

我之前也踩过这个坑，MCP拆子查询再合并的做法在文档问答里确实容易翻车，因为每个工具返回的片段各自为政，缺少统一的rerank环节。建议你在合并后加一层cross-encoder重排，或者干脆让MCP只负责路由，别让它决定最终返回哪些段落。另外bge-large配MCP的query改写可能语义漂移了，可以先对比下改写前后的召回差异。

我之前也踩过这个坑，MCP的tool编排默认是并行拆query然后各搜各的，合并时又没有做重排，主题散掉太正常了。你可以试试在MCP那层加个rerank步骤，或者干脆让文件系统工具的召回权重高一点，数据库那边只做补充。另外bge-large-zh对短子查询其实不太友好，拆太碎反而丢语义，不如限制下子查询数量。

MCP拆子查询再合并确实容易把主题带偏，试试限制并行工具数或者加个重排？

刚入门，这个对我帮助很大。

我之前也遇到过类似问题，后来换了方案。

这个思路不错，收藏了。

你这个情况大概率是MCP把query拆得太碎了，子查询各自为战，召回的结果自然就散了，最后合并那步又没做重排或去重，最匹配的原文被淹掉很正常。我之前也踩过类似的坑，后来在tool编排里加了个聚合层，先让各工具返回带分数的候选，再统一用cross-encoder重排一遍，效果明显回来了。另外可以试试别让MCP自动拆query，改成先判断走文件还是数据库，单路检索反而更稳。bge-large-zh本身没问题，问题多半出在编排策略上。

我猜问题出在MCP那层把query拆得太碎了，bge-large-zh对短查询的语义表达能力本来就弱一些，拆完再分别召回，主题自然就散了。建议你试试让MCP只做路由不做拆分，原始query直接进向量检索，工具调用结果当补充而不是主召回源。另外合并阶段加个rerank，用原始query对多路结果统一打分，能救回不少漏掉的原文。你这情况大概率是编排策略的锅，不是RAG和MCP本身不兼容。

这个问题的根子可能不在MCP本身，而是多路召回后的融合策略没做好。你让MCP把query拆成子查询分别搜，每个工具返回的top-k直接拼在一起，没有统一的rerank或者分数归一化，主题散是必然的。我之前的做法是子查询召回后先过一层cross-encoder重排，再按原始query做一次相关性过滤，漏原文的情况能改善不少。另外bge-large-zh对短子查询的语义表达能力会打折，拆得太碎反而丢信息，可以试试只拆必要维度或者让MCP保留原始query走一遍全量检索兜底。