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

这问题我太有同感了，之前我们团队试过把RAG挂到MCP上，结果也是召回率掉得莫名其妙。后来排查发现，MCP那层tool调用确实会改变query的原始语义，尤其是多轮对话里，模型在生成tool输入时容易把历史信息过度压缩，甚至把关键实体给吞掉，导致后续检索的向量空间对不上。我现在的做法是，在MCP的tool描述里明确要求“保留原query中的名词和数字”，同时把多轮上下文单独做一个拼接字段传进去，而不是让模型自由发挥。另外topk和阈值真不能瞎调，我们最后是拿一小组bad case反向标注，去校准tool的返回格式，比如强制让MCP返回一个结构化的“检索意图+关键词列表”，再喂给向量库。你提到的tool schema，我觉得确实可能是主因——如果描述里没写清楚“不要改写原问题，只补充上下文”，模型就会自作主张去压缩，结果就是现在的样子。还有就是，建议你对比一下不走MCP、直接走原始query的召回结果，如果差距特别大，那问题基本就锁定在查询改写环节了。

我们团队也踩过这个坑，后来发现问题多半出在tool schema对查询意图的约束上。MCP的tool调用本质是让模型做一次“决策”，如果描述里没明确说清楚什么时候该用向量检索、什么时候该用关键词，它就容易自己发挥，把原始query改得面目全非。我们现在是强制把原始用户query原样传给检索tool，同时在schema里加了一条“禁止改写”的指令，效果立马稳了不少。另外多轮上下文拼接这块，建议别一股脑全塞进去，只提取最近两轮的核心实体和意图，不然embedding真的会被稀释。

我遇到过类似情况，感觉不是MCP本身的问题，而是它把“检索”变成了一个中间步骤，模型在生成tool输入时会不自觉做“预压缩”，把关键信息丢了。你可以试试在tool描述里直接给出“返回结果必须基于原始query逐字匹配”这种强约束，另外把topk调高到20再让rerank去兜底，比单纯调embedding阈值靠谱。多轮对话的话，我们是用单独的上下文压缩模块先提炼出当前轮的核心问题，再喂给MCP，别让它自己拼接历史。

这问题我太熟了，MCP把RAG包了一层之后，query改写和工具描述其实会互相干扰。你试试把tool description里加上“保持用户原始query语义不变”这种提示，另外多轮上下文别一股脑全塞进tool参数，做个精简历史摘要再传，效果能稳不少。

我这边之前也是召回率掉得离谱，后来干脆在MCP外面先做一层查询意图判断，简单场景直接走向量检索，复杂场景才调工具，反而好了。你topk调不稳定是不是因为MCP返回的结构里带了额外字段，影响了重排？检查下返回的metadata有没有被污染。

有没有试过对比一下MCP调用前后query的embedding余弦相似度？如果偏差太大，大概率是tool schema强制要求了某些必填参数，导致模型为了填参数把原问题改写了。这种时候宁可把参数全设成可选，也别让模型自作主张加条件。

我之前也踩过这坑，后来发现主要问题出在tool schema上，MCP会把query自动拆解重组，你如果描述里没强调“保持原始意图”，它可能真给你塞进去一堆隐式参数。建议试试把上下文直接拼进tool的input里，而不是让它自己去理解，另外topk别调太高，不然噪音全进来了。

这问题太真实了，我们之前也踩过一模一样的坑。MCP那层tool call其实本质上是把query重新包装了一遍，但LLM在生成tool输入时往往会自作主张做“语义压缩”，尤其是多轮对话里，历史上下文一多，模型会把关键实体和限定词给吞掉，导致检索向量空间里query和doc的分布就对不齐了。我当时试过的最有效办法是别让MCP直接传原始query，而是把tool设计成接收“结构化检索意图”，比如拆成主体、动作、时间范围、排除项，这样LLM反而不敢乱改信息。另外你说的tool schema，确实很关键，如果描述里没强调“必须完整保留用户原句中的否定词和专有名词”，模型就很容易在改写时把“非xxx”理解成“xxx”，相关性直接就崩了。我后来还加了一步：MCP返回候选chunk后，不直接当最终结果，而是再跑一遍轻量级rerank，用原始query和候选chunk做交叉编码，相当于给MCP的粗糙结果兜底。topk和embedding阈值这东西我觉得真不是主要矛盾，你不如先抓一下MCP调用前后的query长什么样，把改写前后的query打出来看看，大概率能发现意图被稀释的具体位置，比瞎调参数有用得多。

工具描述里把检索参数写死试试，别让模型自由发挥，尤其多轮场景下改写query反而帮倒忙。

我这边是把上下文压缩成关键词再喂给MCP，效果比直接拼原始对话稳多了。

同感，MCP那层tool call对query的改写确实容易把语义带偏，尤其多轮对话里历史信息一拼，原始意图直接糊了。我现在是绕开MCP做查询改写，只让它传原始query加轻量上下文，检索逻辑放RAG内部自己处理。另外tool schema里description写得太泛也会出问题，建议把“输入参数说明”细化到字段级，比如明确“必须是用户原话，不要做任何扩展”。你试试把topk调回去，先别动embedding阈值，用最小改动对比看是不是MCP层引入的偏差。

这个问题我太有感触了，上个月我们团队接MCP也翻车了，最后排查下来发现核心问题不是embedding也不是topk，而是tool描述里把“知识库检索”写得太宽泛了。模型在调度时如果觉得这个tool能处理任何query，它就会把原始问题里的限定词（比如时间、产品线）给“简化”掉，导致检索向量空间被拉偏。后来我把一个检索tool拆成了“精确关键词匹配”和“语义模糊搜索”两个独立工具，并在描述里强制要求模型必须原样保留query中的实体和否定词，召回率才回来一些。

关于多轮上下文稀释，我试过在tool调用前单独跑一个轻量级的意图压缩模型，把历史对话里的关键约束提取出来拼进当前query，而不是让MCP自己决定传什么。效果比单纯调阈值稳定很多，你可以试试。另外检查一下MCP返回的chunk是不是做了二次重排，有时候工具内部排序逻辑会覆盖你外部设置的topk，导致看似调了参数其实根本没生效。

还有个小坑，如果你的tool schema里写了“支持模糊查询”，模型会倾向于把精确问题也模糊化处理，建议把参数描述写成“必须包含所有用户提及的专有名词”，这种指令性描述比单纯说“相关性高”要管用得多。你现在的检索链路里，MCP那层是直接透传query还是会做改写？如果会改写，建议加个日志对比原始query和改写后的差异，基本一眼就能看出意图丢失在哪个环节。

大概率是tool schema把意图切碎了，试试把原始query原样塞进检索参数里别让模型改写。

遇到过同样问题，后来在MCP里直接透传query不预处理，召回就稳了。

我们也踩过这个坑，后来发现主要问题出在MCP的tool schema太笼统，模型经常把原始query拆成好几个子调用，上下文就被切碎了。建议试试在tool描述里明确写清楚“仅在需要外部数据时调用”，同时保留一层原始query直通向量库的兜底路径。另外多轮场景下可以把对话历史压缩成一句检索意图再传给MCP，别整段塞进去。