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

说实话我也踩过这个坑，MCP的tool编排默认是并行分发，子查询各自为政，合并时没有做rerank或者相关性过滤，主题发散是必然的。建议你试试把MCP当做一个“路由器”，只用来定位数据源，检索逻辑还是走你原来的单query+embedding流程，而不是让它拆query。另外可以检查一下MCP返回结果有没有带score，如果有，合并时按score加权再做一次重排，能救回不少漏掉的片段。

说实话我也踩过类似的坑，MCP那层工具调度会把原始query拆得七零八落，bge这种稠密检索本来对长文档的局部语义就敏感，子查询一多反而稀释了主意图。你可以试试不拆query，直接把整个问题丢给最相关的那个工具，或者给MCP加个路由规则，让文件系统优先处理内部文档问答。另外合并结果时建议按相似度分数做加权，别简单拼接，不然主题漂移很难避免。

MCP拆子查询确实容易丢上下文，试试别让工具自己编排，主查询带上原始query强制召回再rerank。

说实话这问题我踩过一模一样的坑，MCP多工具并行会把query拆碎，但bge这种向量模型对完整语义更敏感，拆开反而丢了上下文。建议你先别急着全量切MCP，试试只把文件系统挂进去，数据库还是走原来的embedding，或者把子查询结果做一次rerank再合并。另外检查下MCP工具描述写得太宽泛的话，模型容易把query分发到无关工具，导致主文档被挤掉。

我也踩过类似的坑，先说结论：问题大概率不在MCP本身，而在你让MCP“做决定”的粒度上。bge-large-zh-v1.5对长文档的语义切分本来就敏感，MCP把query拆成子查询后，每个子查询的向量空间和原query的意图中心偏移了，合并时如果没有按相关性权重做重排，最匹配的片段被淹没是必然的。我现在的做法是，MCP只负责“路由”和“调度”，不直接改query，每个工具内部还是用原始query去检索，最后在聚合层用RRF（倒数排名融合）或者带阈值的相似度过滤，效果比直接让MCP拆词好很多。另外你提到文件系统和数据库两个工具，它们返回的文本结构差异很大，合并前最好做一下归一化，比如统一截断长度、去掉表格噪音，不然排序模型会无所适从。还有个小细节，MCP的工具描述里如果写了“搜索”这种泛化词，模型容易把子查询拆得更碎，改成“精确匹配文件名”和“全文检索段落”这种明确指令，召回率会稳一些。最后想问你，MCP的tool结果返回后，你有没有做二次rerank？我试过直接拼topk，效果很飘，后来加了个cross-encoder重排才稳下来。

说实话我觉得问题大概率出在MCP的tool编排上，而不是RAG和MCP天生不兼容。bge-large-zh-v1.5本身对中文长文档的向量表达挺稳的，你直接调embedding接口时是单query全量召回，语义空间是连续的，但MCP把query拆成子查询后，每个工具各自为政，向量检索的全局一致性就被打破了。我猜你合并结果时可能用的是简单的拼接或者加权，没做rerank，所以那些跨工具但语义相关的片段就被挤掉了。

我遇到过类似情况，后来发现关键在子查询的拆分粒度。MCP里的文件系统工具和数据库工具返回的文档结构差异很大，文件系统里可能是整段文本，数据库里可能是结构化字段，直接用同一套相似度阈值去过滤，很容易把最匹配的原文误伤。你得给每个工具单独调阈值，甚至针对不同工具定制query改写规则，比如文件系统用更保守的拆分，数据库用更聚焦的关键词。

另外，你有没有检查MCP的上下文窗口对检索结果的影响？它可能在传递子查询结果时做了截断，导致长文档的尾部信息丢失，而bge模型对长文本的全局语义捕捉本来就依赖完整输入。我之前用MCP接ES时，发现它默认只回传top-k条，但没保留原始文本的段落边界，害得我二次拼接时错位了。

我的建议是，先别急着怀疑结合方式，把MCP的tool调用日志拉出来，看看每个子查询实际返回了什么，对比一下直接embedding的召回列表，差距在哪一目了然。如果确认是合并策略的问题，可以加一个lightweight的cross-encoder做rerank，或者干脆让MCP只负责工具调度，检索部分还是走你原来的pipeline，别让协议层干预太多。

说实话你这问题我上周刚踩完坑，最后排查下来发现不是MCP本身的问题，而是tool编排时把query拆得太碎了。MCP的subquery机制默认会按意图切分，但内部文档问答这种场景，query往往带着强上下文依赖，硬拆成“文件搜索”和“数据库查询”两个独立动作，反而把原本连贯的语义切断了。

我当时是把MCP的subquery开关关掉，改成让每个tool先拿完整query跑一遍top-k召回，再做结果级的rerank，效果立刻回来不少。你用的bge-large-zh-v1.5本身对长query更友好，但MCP一旦拆词，向量化时每个子句都变成孤立片段，主题漂移几乎是必然的。

另一个坑是合并策略，你现在的做法是直接拼结果对吧？建议试试按工具类型加权，比如文件系统里命中的段落权重给0.7，数据库字段匹配给0.3，而不是简单concate。我之前用RRF（倒数排名融合）效果也比直接拼接稳，但需要调k值。

还有个思路可能更省事——MCP其实更适合当路由层，而不是检索层。你完全可以让MCP只负责判断“这问题该查文档还是查数据库”，然后把完整query丢给对应的embedding接口，别让它参与子查询生成。这样既保留MCP的调度能力，又避免语义稀释。

你要是方便的话，能不能贴一下你MCP工具定义里subquery的max_split长度？我怀疑你把它设太小了，低于某个阈值后bge的句向量质量会明显下降。另外你合并结果时有没有做去重？有时候同一个原文片段被两个工具重复召回，但排序时因为来源不同被压到很后面，反而把真正匹配的段落挤掉了。

这场景太典型了，MCP工具编排默认是并行拆解，但RAG检索吃的是相关性不是广度，建议子查询结果按得分统一重排再合并，别直接拼接。

工具编排优先级得调调，先跑主query再拿结果做子查询，不然合并时主题权重全乱了。

我碰到过几乎一模一样的情况，最后发现问题出在MCP把query拆解后，每个子查询都独立去检索，但合并时没有做相关性重排，导致主题漂移特别严重。你用的bge-large对长文档的语义捕捉其实挺稳的，但一旦拆成多段，每段单独跟query算相似度，最匹配的那段反而可能因为分数被其他子查询的结果稀释掉而落选。我当时试了个笨办法，就是让MCP只负责工具调度，检索还是走原来的单路召回，等结果出来再用一个LLM做二次过滤，效果立马回来了。另外你提到文件系统和数据库两个工具，有没有考虑过它们返回的文档粒度不一样？文件系统可能是一整篇，数据库可能是某一行字段，合并时如果没做归一化处理，向量距离直接比肯定不公平。还有一个坑是MCP的tool描述写得太泛，它自己都不知道什么时候该用哪个工具，有时候明明该去数据库查精确值，它却去文件系统里做全文搜索。你可以试试把tool的description写得更具体，比如“仅当用户提到具体编号时使用数据库工具”，这样编排策略会收敛很多。最后想问下，你MCP拆子查询的触发条件是什么？是固定拆成几路，还是根据query长度动态判断？如果是固定拆，那大概率会引入噪声，动态判断会好一些。

MCP那层做子查询拆分，本质是把一个完整语义问题切碎了，bge这种向量模型对碎片化query的编码效果会明显变差，召回率掉是正常的。我之前也踩过这个坑，后来改成先让MCP判断该走哪个工具，而不是所有工具都并行查，效果就稳多了。另外合并策略别用简单拼接，试试按相似度加权或者做个rerank，不然最匹配的片段很容易被边缘化。你那个文件系统工具如果支持路径过滤，建议先把范围缩小到相关目录再检索，比全局搜靠谱。

这坑我踩过，MCP多工具并行检索时，子查询的召回分数直接合并排序是大忌，不同工具返回的相似度分布根本不在一个量级上。建议先给每个工具单独设个召回阈值，合并前做score归一化，再按原始query的向量结果做一次重排。另外，bge对长文档切片本来就敏感，MCP拆分query后容易把上下文切碎，试试让子查询带上原文片段一起返回。

这问题我踩过类似的坑，MCP的tool编排确实容易把query拆碎，子查询各自为政反而丢了全局语义。我当时是限制MCP只做工具路由，不拆解query，用原始问题直接去检索最相关的单工具，结果召回稳定多了。另外合并结果时建议按向量相似度二次重排，别直接拼接，不然主题发散是必然的。

大概率是MCP把query拆散后丢了原始语义，合并策略直接按工具分组了，试试让子查询带权重再融合。

同感，MCP拆query这步非常容易翻车，本质上是把原来连续的语义空间强行切碎了。你可以试试子查询不做全文匹配，只用来过滤元数据或者定位文档范围，最后召回还是回归原始embedding的top结果，效果会稳很多。另外，bge-large对长文本的切块策略也很敏感，MCP工具返回的内容如果拼接顺序不对，相关性排序基本就废了，建议合并时按原文档的段落位置加权，而不是按工具响应时间。

说实话我也踩过类似的坑，MCP那套多工具并行查询看着美好，但子查询合并的权重和去重逻辑不调好，真不如单路召回稳。我后来是把RAG的向量检索设为主通道，MCP工具只做补充召回，最后用交叉编码器统一重排，保准率才回来。你那个bge-large对长文档切分本身就敏感，MCP再一拆query，主题漂移是必然的，建议先把子查询数量限制在2个以内，并且每个工具返回top-k调大再合并过滤。

说实话你这个情况我上周刚踩过一模一样的坑，后来翻了下MCP的调用日志才反应过来，问题多半出在子查询的切分逻辑上。bge-large-zh-v1.5对长query的语义保持本来就不算强，MCP一旦把原问题拆成“文件系统查关键词A”和“数据库查关键词B”，两边各自召回的结果在向量空间里根本不在一个簇，合并排序的时候自然会把最贴近原文的那段挤到后面去。我现在的做法是让MCP只做路由，不做拆分——先根据query意图判断该走哪个工具，然后整个query原样传给那个工具内部的检索逻辑，这样至少保证了向量化的主体是完整的。另外你检查下MCP的tool返回格式，是不是把不同来源的chunk直接拼在一起了？我试过在合并前按来源分别做一次相关性过滤，只保留每个工具里top3的结果再混合重排，效果比无脑拼接稳很多。还有个隐藏坑：MCP的system prompt可能会自动给query加上额外指令，比如“请从多个角度分析”，这种改写对embedding来说等于换了语义，建议在调向量化接口前把MCP的输出原样打出来看一眼。你现在召回掉的段落是不是经常出现在文件系统结果里？如果是，那大概率是路由权重配错了，我后来在MCP配置里把文件系统的优先级调低，让数据库先跑，过滤完再补文件系统，整体准确率回来了大概20%。最后想问下，你MCP里那两个工具的返回chunk长度是不是差距很大？我这边发现长度差异过大会让合并排序的score归一化出问题，你可以试试先各自归一化再合并。

这个坑我踩过，MCP多工具并行检索时，子查询的结果按相关度合并是伪命题，主题漂移太正常了。我后来是强制让MCP按优先级串行调用工具，主查询先走向量库，只有得分低于阈值才触发文件系统兜底，效果稳多了。另外你试试在tool描述里写明“返回最相关的一段原文”，别让LLM自由发挥，它有时候真会自作聪明合并得乱七八糟。

MCP的tool编排确实容易把语义割裂，尤其是多工具并行搜索时，子查询的权重分配和结果融合策略没调好，很容易把主召回给稀释掉。我之前也踩过这坑，后来改成先让主query直接走向量检索，再根据置信度决定要不要触发MCP工具，效果才稳回来。你bge对长文档切分是不是也受影响了？子查询可能把原文片段切得更碎，导致top-k里全是碎片信息。要不试试把MCP工具结果当rerank的候选池，而不是直接替换主召回？

遇到过，MCP拆query容易把语义拆碎，试试先让主查询跑完整检索，再拿top结果去调工具补充，别并行撒网。