RAG系统接入MCP后检索质量反而下降了，大家有遇到吗？

这问题太真实了，我们当时也栽在这上面。MCP那层tool schema一旦写得太宽泛，模型就容易把query里的核心实体给拆散了，尤其多轮对话时上下文一拼，召回直接跑偏。后来我们干脆把原始query和改写后的query同时传给检索，再按相关性分数做加权融合，比单纯调topk稳多了。另外工具描述里最好把检索意图写死，比如明确“基于问题原文精确匹配”，不然模型真会自由发挥。

学到了，感谢分享！

我们团队也踩过类似的坑，后来发现问题出在MCP的tool描述上——模型会把query里的关键词拆给不同参数，反而把核心语义切碎了。现在我们把改写逻辑放在tool外部，直接用原始query做向量检索，MCP只负责调度数据源，效果稳多了。另外你提到的多轮上下文稀释，我们试过在tool输入里强制拼接最近两轮用户原话，别让模型自己总结，召回率涨了大概15%。你可以先检查下tool schema里有没有给参数加明确约束，比如“必须保留原始问句完整文本”这种描述。

这问题我太有同感了，之前我们团队接MCP的时候也栽在同样的坑里。我感觉核心问题不在embedding或者topk，而是你那个tool schema把查询意图给框死了——MCP的tool调用本质上是个“二次决策”过程，模型得先理解你描述的参数语义，再决定怎么填，这中间一旦有歧义，原始query的语义就被改写成了工具视角的“伪query”。我后来试了个笨办法，把tool描述写成“直接透传用户原始问题，不做任何扩展”，然后强制系统在调用RAG工具前先输出一个“意图摘要”字段，结果召回反而稳了。另外多轮上下文这块，我建议别把整个历史都塞给MCP，而是先用一个轻量模型做“核心问题抽取”，只把当前轮和最近一次有效指代喂进去，不然模型很容易被无关历史带偏。还有一个细节，如果你们是多数据源，tool schema里那个“数据源选择”字段最好给个默认值，不然模型每次都会纠结选哪个，反而干扰检索。你现在是每个工具对应一个独立向量库，还是所有数据源揉在一个库里？这俩的tool参数写法差别挺大的。

这个现象我遇到过，而且当时比你还头大。我后来排查发现，问题往往不在RAG本身，而是MCP那层tool schema把用户query“翻译”得太机械了——尤其是多轮对话，模型可能只取了最近一轮的文本，历史上下文全被丢掉了，这跟你说的“稀释”完全对得上。我现在的做法是，在MCP的tool描述里明确要求“必须携带完整对话历史摘要”，而不是让模型自己决定传什么参数，效果会稳很多。另外查询改写这块，我建议你试试在进入MCP之前先做一次独立的query理解，把意图拆成“检索主体”和“约束条件”，再塞给tool调用，这样比依赖模型临场发挥靠谱。至于topk和阈值，说实话调参治标不治本，因为问题出在输入侧，你输入都是歪的，召回再调也白搭。还有个坑是tool schema写得太泛，比如只写“search_knowledge_base”，模型就容易自作主张填一些奇怪的filter，你试着把参数说明写死成“必须返回与query语义最相近的5个chunk，禁止额外过滤”。最后想问下，你那边MCP是直接暴露给LLM自由调用，还是走了固定的pipeline？如果是前者，建议先锁死调用流程，排查一下到底是哪一步把原始意图带偏了。

tool schema确实会影响路由，试试把query改写逻辑从MCP里拆出来，直接拼原始上下文再过向量库。

这问题我也踩过，多轮对话时别让MCP碰意图提取，只做数据源路由，召回前自己拼历史再检索。

这问题太真实了，MCP的tool schema里检索参数写太细反而容易把query搞乱，试试把改写逻辑放外面。

工具描述写太宽泛模型确实会乱选参数，建议把每个tool的输入约束死一点。查询改写我直接砍了，保留原始query反而更稳。

这个问题太真实了，我们之前也踩过类似的坑。后来发现MCP那层tool schema写得越细，模型越容易把用户原话“翻译”成参数，反而丢了口语里的隐含指代，特别是多轮里那种“刚才说的那个”直接就没影了。我现在是把查询改写和上下文压缩放在MCP调用之前，让模型先基于历史对话生成一个独立query再喂给检索，效果比靠tool描述硬扛稳很多。另外建议你把topk调低一点，然后看下是不是MCP返回的chunk排序被tool输出格式干扰了，有时候模型会自作聪明重排。

tool schema最好把query改写逻辑直接写进去，别让模型自由发挥，我试过固定模板效果稳很多。

遇到过类似的情况，而且我们当时比你更惨，召回率直接掉了十几个点。后来排查下来，问题主要出在MCP的tool调用把query做了隐式改写，尤其是多轮对话里，模型会把历史上下文压缩成一段summary再传给检索，这玩意儿特别容易丢失关键实体，反而把原始意图给带偏了。我觉得你可以先别急着调topk和阈值，重点检查一下tool schema里的参数描述，比如是不是让模型误以为需要做query改写，而实际上你希望它直接透传原始query。我们后来在schema里明确写了“不要改写，直接使用用户最新输入”，效果就稳定多了。另外，如果MCP允许自定义预处理逻辑，建议在工具内部把多轮拼接的逻辑改成只取最近一轮加少量核心历史，别全塞进去。还有一个坑是embedding模型对长文本的敏感度，如果MCP返回的chunk本身带了tool的包装信息，比如JSON字段名或者额外元数据，这也会干扰向量计算，最好在检索前剥掉这些外层结构。你试试看，如果还不行，可能得对比一下MCP内部的检索参数是不是被tool调用时的默认值覆盖了，我们当时就发现它对topk有hidden default，直接改代码才解决。

说实话你这个现象我太熟了，之前我们接MCP的时候也栽在查询改写这步上。问题往往不在embedding或者topk，而是MCP的tool调用把原始query拆解成了“工具能理解的参数”，但这个过程丢失了用户口语里的隐含意图，尤其多轮对话里上一轮的关键实体和否定关系很容易被吞掉。我后来是强行在tool schema里加了一个“原始问题原文”的字段，让模型必须把这个原封不动传给RAG检索那步，而不是只传改写后的结构化参数，召回质量立刻稳了不少。另外你提到tool描述，这个确实关键，我建议把检索参数描述成“宽松匹配用高topk，精确查找用低阈值”这种带场景的说明，不然模型经常瞎调参。还有个坑是MCP返回chunk后你又做了一次重排，如果重排模型和原来向量检索的相似度分布不一致，反而会拉低相关性。想问下你那边MCP的tool是把多个数据源合并成一个接口暴露给模型，还是每个源单独一个tool？我感觉这俩的上下文拼接策略差别还挺大的。

tool schema确实会影响参数选择，但你这情况更像query改写环节丢了上下文，试试把原始对话历史直接拼进检索词里。

这问题我太有同感了，MCP那层tool call确实容易把query搞“脏”，尤其多轮对话时历史信息一拼，原始意图直接被冲淡。我当时是直接砍掉MCP里的查询改写，让RAG拿原始user query去检索，然后把tool描述写得更死板一点，只允许传“最终问题”字段，效果反而稳了。你可以试试看是不是tool schema里参数太灵活，模型自己加了太多戏。

tool schema确实影响很大，模型选错参数直接带偏召回。你要不试试把query改写逻辑挪到MCP外面？

遇到过类似情况，后来发现问题是MCP把query包装成tool call时，模型会自作主张去“理解”一遍原始输入，反而把关键实体给丢了。我现在的做法是绕过工具描述，直接在tool input里塞完整的对话历史加当前问题，让检索端自己处理意图，效果比让模型改写稳定不少。另外你提到tool schema，确实值得检查下参数名和描述，我之前光把topk写成k，模型就老传错值，检索质量直接崩了。

同感，这个问题我们团队也踩过。MCP本质上是个工具调度层，它引入的query改写和上下文压缩逻辑，对RAG这种对原始语义敏感的任务来说，确实容易把关键实体或限定词给“优化”掉。我之前调试时发现，MCP默认的tool schema里如果只写“检索相关文档”，模型会倾向于把多轮对话里的指代词直接替换成显式名词，但替换后的表述反而跟知识库里的原文表述对不上，向量距离自然就远了。

后来我试了个土办法：在MCP的tool描述里强制要求“保留用户原句中的所有修饰成分和否定词”，并且把改写后的query和原始query做双路召回，最后用重排模型合并结果。效果比单靠调topk稳定多了，尤其对那种“除了A以外的B”之类的复杂意图。另外，你提到的工具描述确实很关键，我建议把每个参数的含义写得更“笨”一点，比如明确说“不要提取隐含意图，只做字面切割”，这样模型反而不会乱发挥。

还有个坑是上下文窗口，MCP如果自动把历史对话压缩成摘要再传给RAG，那摘要里的信息密度根本不够做相似度匹配。我现在是把最近的2轮原始对话直接拼接，不经过任何总结，虽然token开销大点，但召回相关性明显回升。你可以看看是不是这个环节出了问题。

这问题我太有共鸣了，之前我们接MCP的时候也栽在查询改写上。MCP的tool调用本质上是把自然语言拆解成结构化参数，但这个过程中模型很容易把用户的核心意图“翻译”歪，尤其多轮对话里，历史的指代和省略信息根本没法通过单个tool call完整传递。我后来是直接把完整的对话历史压缩成一段“意图摘要”塞进tool的description里，而不是让模型自己去推断，召回稳定了不少。

另外工具描述真的会背锅，我之前写得太简略，模型经常把“检索”和“查询”当成两个不同动作，导致它自己发明参数。现在我把每个参数的可选值、默认行为、甚至负面案例都写进去，明显感觉选参靠谱了。

还有个偏方，就是别让MCP直接走向量检索，而是让它先调一个“查询解析”工具，把query拆成多个子查询再并行召回，最后在RAG侧做rerank。虽然多了一步，但召回质量比之前硬接强多了。你们有没有试过把embedding阈值调低，然后靠rerank模型兜底？我试下来比调topk更稳。

我之前也踩过类似的坑，后来发现问题多半出在tool schema上——如果描述里没强调“保留原始query语义”，模型很容易自作主张去提炼关键词，结果把意图搞没了。你可以试试在MCP那层把原始query和改写后的query拼一起再检索，或者干脆让tool只负责路由，不碰查询改写。另外多轮上下文这块，建议显式把最近两轮对话单独传给tool，别全塞进去，不然信息一多反而稀释重点。

大概率是MCP的tool schema把query意图带偏了，试试在描述里强制要求原样传递用户query再拼接上下文。