RAG接入MCP后检索结果反而变差了，是路由策略的问题吗？

遇到过类似的坑，工具描述里塞太多关键词反而误导模型，它会把文本匹配当万能解。建议把SQL工具的description写成“查询结构化事实（精确时间、数字、状态），当问题含明确实体字段时优先用”，然后few-shot示例比schema调整更管用。另外别指望纯靠提示词搞定路由，DeepSeek对这种细粒度判别本来就弱，加个轻量分类器先判断“事实型vs模糊型”再决定调哪个工具，比让Agent自由发挥稳得多。

工具描述这块确实容易踩坑，我之前也遇到过类似情况。光靠MCP的schema让模型自己选，对“上线时间”这种强结构化意图经常失灵，向量库的语义相似度太容易骗过路由了。后来我在工具描述里硬塞了反例，比如SQL工具写明“查具体时间、数字、状态字段优先用这个”，效果好了不少。不过说实话，多工具场景加个轻量意图分类兜底更稳，别全指望模型自己判断。温度0.2已经够低了，问题不在采样上。

工具描述写清楚适用场景比调温度管用，我加了个轻量意图分类先筛一遍，路由准多了。

工具描述太关键了，我之前也踩过这个坑。把每个工具的适用场景写清楚，比如SQL那条注明“涉及具体时间、数值、结构化字段时优先用”，向量库则强调“适合模糊语义和文档片段”，路由准确率能提不少。另外光靠描述不一定够，我后来加了个轻量意图分类先过一遍，再让模型决定调哪个工具，效果比纯靠schema稳很多。DeepSeek温度0.2已经挺低了，问题大概率还是出在工具边界描述不够互斥。

温度低不代表路由准，工具描述太模糊模型只能瞎猜，加个轻量意图分类兜底更稳。

工具描述太糙模型肯定乱选，建议给每个工具加几句“什么时候该用我”的说明，再不行就上意图识别兜底。

工具描述写得太"技术"了模型反而不好判断，建议把每个工具能回答什么问题直接写进description里，比如SQL那条就明确写"查询具体数值、时间、状态类事实"，向量库写"适合开放性问题、文档摘要"。光靠schema优化可能不够，多工具场景下加个轻量意图分类层兜底会更稳，先分类再路由，DeepSeek本身也能干这活。温度0.2其实影响不大，路由错多半是工具边界模糊导致的。

这个坑我也踩过，把检索封装成MCP之后准确率不升反降，当时挺懵的。后来发现核心问题不在温度，而是工具描述写得太“技术化”了，比如向量库描述里全是“语义相似度、embedding”这类词，模型根本不知道啥时候该用它。你问“上线时间”这种带明确字段和时间属性的问题，SQL工具的schema里如果没把“时间、日期、项目名”这些关键参数标清楚，模型就会倾向于选那个看起来啥都能答的向量库。我现在会在工具描述里直接写“当问题涉及具体数值、时间、状态字段时优先调用”，效果比调温度明显。另外多工具路由确实容易翻车，我后来加了一层很轻的规则兜底，命中时间/数字类的query直接强制走SQL，剩下的才交给模型选。DeepSeek本身指令遵循还行，但工具一多就容易飘，schema里参数别搞太复杂，能扁平就扁平。你们现在工具数量大概几个？超过四五个的话光靠描述可能真压不住。

我这边也是先加了一层意图识别兜底才稳住的，光靠工具描述让模型自己路由太看运气了。

我也踩过这个坑，工具描述写得太抽象模型真的会乱选。后来我把每个工具的适用场景和反例都塞进description里，比如SQL那条直接写“涉及具体时间、数值、状态字段时优先用”，向量库那条写“仅用于模糊语义检索”，路由准确率明显上来了。schema参数也别偷懒，字段名和示例值写清楚，模型对参数含义的理解会好很多。不过多工具场景下光靠描述还是不稳，我现在是描述优化加一层轻量意图分类兜底，两条腿走路才踏实。