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

工具描述里最好把“何时用我”写具体点，比如SQL那边直接写“查项目时间线必选”，不然模型纯靠猜。

另外独立意图识别层真不是兜底，是刚需，尤其工具一多路由就飘。

工具描述里把“SQL查询”写成“查结构化数据里的精确值（如日期/金额）”，模型大概率就不会跑偏了。但说真的，多工具路由不稳时加个意图识别兜底，比调参省心多了。

工具描述里得把“何时用我”写具体，别光写功能，直接给几个典型问题示例，模型才不容易跑偏。

可以试试把SQL工具的描述改成“仅当用户明确问到具体日期、金额等结构化字段时使用”。

建议工具描述里直接给示例query，比写一堆schema管用，模型看到具体例子就知道该选谁了。

遇到过类似情况，工具描述写得再详细模型也容易瞎选，尤其DeepSeek对隐式意图的推理没那么强。你试试把工具名和描述改成“动词+宾语”的强语义格式，比如“查询项目时间信息”而不是“数据库查询”，参数schema里加枚举示例也有帮助。不过说实话，多工具路由光靠prompt真不稳，我后来加了个轻量分类器先判断问题类型再决定调哪个工具，准确率才上去，MCP更适合做执行层而不是决策层。

遇到过类似的坑，后来发现工具描述里带具体示例比纯说功能有用得多，比如在SQL工具的description里直接写“查项目时间问这种格式”，模型一下就选对了。另外你这温度0.2其实不算低，DeepSeek对工具调用的敏感度挺高的，试试0.1甚至0。不过说实话，多工具路由光靠提示词优化有点赌运气，加个轻量意图分类层做前置过滤，成本不高但稳很多，尤其你们内部知识库场景，工具边界本身就模糊。

工具描述里把时间字段和SQL强绑定，再加个few-shot示例，DeepSeek能明显少犯迷糊。独立意图层兜底成本高，先调schema试试。

工具描述里把关键词和示例问法写清楚点，DeepSeek路由会准不少。不过还是建议加个轻量意图分类兜底，纯靠模型选工具太赌运气了。

工具描述里得把SQL的强约束关键词写进去，比如“精确查询”“结构化数据”，不然模型真容易跑偏。

我试过加一层轻量意图分类兜底，成本不高，但路由准了挺多，你可以试试。

遇到过类似情况，工具描述写得再详细，模型还是容易凭表面语义瞎猜。后来我把SQL查询的description里加了具体字段名和示例问题，比如“查项目上线时间用这个”，效果好了点，但复杂query还是会跑偏。我觉得你这温度调低没用，关键得在工具选择上加个置信度阈值，低于某个值就退回固定路由，或者干脆加个轻量意图分类模型做前置判断，成本也不高。

工具描述里得把“能干什么”和“不能干什么”写死，比如SQL那边直接加个“查时间、状态类字段专用”，不然模型真会瞎蒙。

我觉得还得加个轻量级意图分类兜底，靠schema调参在边界case上太不稳了，尤其DeepSeek这种偏生成式的模型。

遇到过类似情况，MCP工具描述写得太笼统确实容易让模型乱选。你可以试试在工具描述里直接塞几个典型问题示例，比如“查项目上线时间用这个”，比单纯写参数schema管用。另外独立意图识别层我觉得挺必要的，尤其当工具数量超过3个时，靠模型自己路由稳定性真不太行。DeepSeek的话，可以试试把温度再调低点，或者给每个工具加个优先级字段，让Agent在模糊时优先选特定工具。

工具描述里得把“何时用我”写清楚，比如SQL那栏直接说“查结构化事实”，别让模型猜。

干脆加个意图识别前置过滤吧，DeepSeek路由不稳，这钱省不得。

遇到过类似情况，工具描述写得再详细也不如给几个few-shot示例管用，可以在MCP的description里塞一两条典型query和对应工具的映射。另外DeepSeek对工具选择的置信度确实偏低，我后来在路由前加了个轻量分类器做硬性过滤，只把候选工具缩小到2个再交给模型，效果比纯靠模型判断稳很多。

遇到过类似的情况，感觉问题可能不在路由本身，而是工具描述写得不够“歧视性”。比如你那个SQL工具，描述里得直接带上“查询结构化数据、项目时间、金额等精确信息”，别只写“执行SQL”，模型根本猜不到什么时候该用。另外DeepSeek对工具选择的置信度本来就一般，温度0.2也不代表它不会乱来，我后来是把意图识别拆出来先跑一遍，命中关键词再决定调哪个工具，比让Agent自由发挥稳多了。你可以试试在MCP的tool description里加几个典型的问法示例，效果比纯参数schema直观很多。

工具描述里把关键词和边界条件写死一点，比如“仅查结构化上线日期”，能明显改善路由。

另外加个轻量意图识别当兜底更稳，纯靠模型选工具还是太赌了。

遇到过类似情况，工具描述写得再详细，模型还是容易凭语义相似度瞎选。我觉得可以试试在参数schema里加个强制约束字段，比如让SQL查询工具声明“必须包含项目名称且仅用于精确匹配”，把向量库工具描述成“适合模糊语义查询”，这样模型可能更容易区分边界。另外独立意图识别层不一定是兜底，更像是给Agent装个方向盘，尤其当工具数量超过3个时，路由准确率会明显下降，你可以先统计下工具调用的混淆矩阵再决定要不要加。

工具描述写得太泛模型就瞎猜，建议把参数示例和边界条件写死，比如SQL查询必须带表名字段。

独立意图识别层还是得加，光靠schema约束DeepSeek这种模型不太够，兜底逻辑省不掉。

说实话我也踩过类似的坑，MCP工具描述写得再详细，模型在低温度下还是容易偷懒选“看起来最像”的那个。我后来把每个工具的描述里强行加了“必须确认用户明确提到XX字段才用”这种硬性约束，效果好了点，但遇到模糊提问还是白搭。你这个场景我觉着倒不一定要加意图识别层，先试试把SQL工具的示例query直接写进description里，让模型看到“上线时间”这个词就跟具体SQL模板绑定。另外DeepSeek对工具调用的置信度本来就一般，你可以在路由前加个简单的关键词预筛，命中“时间、金额、状态”这类词就直接走SQL，别让模型自由发挥。

我之前也踩过类似的坑，把检索工具暴露给Agent后，它确实会倾向于选那个“看起来最像答案”的工具，而不是真正结构化的那个。DeepSeek这种模型对工具描述里的动词和名词特别敏感，比如你写“查询项目信息”它就容易往向量库跑，改成“精确匹配项目表中上线时间字段”可能就好很多。另外参数schema别给太宽泛，把SQL查询的必填参数写得明确些，比如要求必须传项目ID或名称，模型就会更慎重。但说实话，光靠描述优化上限不高，尤其内部知识库的术语多，模型压根不知道“上线时间”是个字段而不是一段文本。我后来是加了个轻量的规则层，先正则匹配有没有“日期”“时间”这类关键词，命中就直接走SQL，纯规则不用模型，成本低还稳。你温度0.2可以再试试调低到0.1，但更关键的可能是给每个工具加一个“使用场景示例”，比如SQL那栏直接写“当用户询问具体数值、日期、状态时使用”，向量库写“当用户问概念解释、文档总结时使用”，这种显式提示比抽象描述有效得多。独立意图识别层我觉得不是必须，但如果你工具数量超过四个，顶层加个分类器确实能兜底，不过得注意别让分类器又变成新的误差源。