当智能体需要调用的工具数量从几个膨胀到上百个，让大模型直接决定用哪个接口往往会出错。工具检索RAG通过把工具和用户问题都转成向量，再用相似度计算找出最相关的几个候选，从而把选择范围缩小，再由模型做最终判断。这种方式既能应对工具频繁变动，也能降低误调概率。
什么是工具检索RAG
工具检索RAG是检索增强生成在工具调用场景下的具体落地。传统做法把工具名称、参数写进提示词，模型靠上下文去猜。工具少时尚可，一旦工具库扩大到百级，提示词塞不下，模型也记不准。RAG思路是把每个工具的描述、适用场景、参数 schema 先建成向量索引，用户提问时先检索再生成。
举个例子，系统里有天气查询、汇率换算、订单退款等一百多个工具。用户说“帮我看看昨天买的鞋能退吗”，检索模块会从索引里找出订单查询、退款政策、售后规则这几个工具，而不是把翻译或地图工具也塞给模型。这样模型看到的候选变少，决策质量自然提高。
核心流程怎么走
工具侧索引构建
第一步是整理工具元数据。每个工具要有清晰的功能说明、触发例子、参数定义。比如退款工具可写成：用于处理已支付订单的退货退款，需要订单号与原因。把这些文本用嵌入模型转成向量，存进向量库。索引质量直接决定后续召回效果，描述模糊就会导致搜不到。
实际项目中，很多团队会给工具打上业务标签，如售后、物流、支付，检索时先按标签粗筛，再做语义细排。这种混合检索比纯向量更稳定，尤其当工具名称相似时，标签能挡掉大量无关项。
用户侧检索与排序
用户语句同样向量化，和工具向量算余弦相似度，取前K个。K一般设五到十，太少可能漏掉正确工具，太多又让模型分心。拿到候选后，可再用一次轻量重排模型，把最匹配的排到第一。
排序不能只看相似度。有的用户问法简短，向量偏淡，这时要结合历史对话补上下文。例如前一句在查订单，后一句说“退了”，检索就应偏向退款类工具，而非泛泛搜“退”字。
模型最终决策
把候选工具的描述和参数交给大模型，让它选一个或多个并填参。因为候选已准，模型很少瞎编。若置信度都低，可回退到通用问答或提示用户补充信息，避免硬调错工具。
在百个工具场景下，这一层还能加一道校验：调用前检查必填参数是否齐全，缺了就先问用户。这样整体链路从检索到执行都有兜底，不会卡在半路。
和传统规则路由比有什么优势
老系统常用关键词或正则路由，比如句子含“天气”就调天气接口。工具少时好用，工具多了规则会打架，维护人也崩溃。RAG靠语义，新加工具只需写描述入库，不用改路由代码。
下面的表列出了两者常见差异：
| 对比项 | 规则路由 | 工具检索RAG |
|---|---|---|
| 新增工具成本 | 改代码加分支 | 写描述入索引 |
| 泛化能力 | 仅匹配既定说法 | 理解同义表述 |
| 百工具表现 | 规则冲突多 | 检索收敛候选 |
| 维护负担 | 随工具线性增长 | 接近恒定 |
落地要注意的坑
嵌入模型选不好，向量区分度低，搜出来一堆近似工具。建议用已在业务语料上微调过的模型，或至少用较新的通用中文嵌入。另外工具描述要由懂业务的人写，避免技术黑话。
还有检索阈值问题。相似度低于某值就该认为无合适工具，别勉强返回。可设两级阈值：高阈值直接调，低阈值交模型判断，极低则拒答。这样用户不会因为调错工具得到荒谬结果。
工具检索RAG不是替模型包办一切，而是把大海捞针变成碗里挑珠，让人和模型都轻松。
小结
面对上百工具，靠记忆或规则都撑不住。工具检索RAG用向量检索先把范围缩到可控，再让模型精细决策，兼顾准确与灵活。只要索引写清、阈值合理，即便工具天天增删，系统也能稳稳选对。