《Retrieval Models Aren’t Tool-Savvy》论文详细分析报告这篇论文的核心观点可以概括为一句话通用检索模型并不天然擅长“工具检索”而工具检索质量会直接影响大模型工具调用任务的最终成功率。论文提出了一个专门面向工具检索任务的基准TOOLRET包含 7,615 个检索任务和 43,215 个工具文档并进一步构建了一个包含 20 万级训练样本的TOOLRET-train用于提升检索模型在工具场景下的能力。论文标题中的 “Retrieval Models Aren’t Tool-Savvy” 其实非常准确作者想证明不是把 BM25、BGE、E5、ColBERT、NV-Embed 这些强检索模型直接搬过来就能解决工具检索问题。一、论文研究背景大语言模型要完成复杂任务往往不能只靠自身参数知识。它需要调用外部工具例如 Web API、代码函数、数据库接口、搜索接口、图像处理函数等。问题在于真实场景中的工具数量非常多模型不可能一次性把所有工具说明都塞进上下文。因此在工具调用之前必须先做一步从大规模工具库中检索出和用户任务相关的候选工具。以往很多工具调用数据集会提前给模型一个人工标注好的小工具集比如每个任务给 10 到 20 个候选工具。这样做方便评测模型“会不会调用工具”但弱化了一个更真实、更关键的问题如果没有人工提前筛好工具大模型能不能从几万甚至几十万个工具中找到正确工具这正是本文切入的问题。作者指出真实应用中的工具检索具有两个难点。第一工具文档和用户查询之间的词面重叠很低用户可能说“帮我查附近能买青柠的超市”但工具文档可能写的是local grocery search API或某个具体 endpoint第二工具之间功能相近但边界不同例如都是搜索工具但有的支持语言筛选有的不支持有的是医疗搜索有的是新闻搜索。因此工具检索不仅是普通的语义匹配问题还需要理解工具功能、参数约束和任务需求之间的细粒度关系。二、论文主要贡献这篇论文主要有三个贡献。第一作者提出了TOOLRET这是一个专门用于评估工具检索能力的异构基准。它整合了 30 多个已有工具调用相关数据集最终形成 7.6k 检索任务和 43k 工具文档。每个检索任务都被统一成类似传统 IR 基准的格式输入是 query标签是 target tools工具本身有对应的文档描述。第二作者系统评估了多类检索模型包括 BM25、Contriever、GTR、ColBERT、E5、BGE、GTE、NV-Embed、MonoT5、BGE-reranker、Jina-reranker、RankGPT 等。实验发现即使是在 MTEB 等传统检索榜单上表现较强的模型在 TOOLRET 上的表现也明显不足。比如在无 instruction 的设置下表现较好的 NV-Embed-v1 平均 NDCG10 也只有 33.83。第三作者构建了TOOLRET-train一个大规模工具检索训练集。它来自 ToolACE、ToolBench、APIGen 等主流工具学习数据集包含 20 万级训练实例。训练样本包括 query、instruction、target tools 和 negative tools。实验证明用 TOOLRET-train 训练后的检索模型不仅检索指标提升也能进一步提升 ToolBench 上工具调用 LLM 的 Pass Rate。三、TOOLRET 数据集构建过程TOOLRET 的构建过程可以分成三步数据收集、数据采样、instruction 构造。首先是数据收集。作者从工具调用领域已有数据集中收集 query-tool 对包括 ToolBench、ToolACE、APIGen、ToolLens、API-Bank、ToolAlpaca、ToolE、TaskBench、Gorilla、CRAFT、RestGPT、AutoTools 等。论文附录中的表格列出了各数据集来源、query 数量和工具数量其中 ToolBench 的多个子集共享一个包含 13,000 多个工具的工具集。其次是数据采样。由于不同数据集规模差异很大直接合并会导致某些数据集占比过高。作者使用NV-Embed-v1对任务进行编码再用 K-means 聚类进行任务采样尽量保留任务多样性。同时作者手动检查并合并重复或重叠的工具集最终得到 43,215 个工具。第三是 instruction 构造。TOOLRET 不只提供 query还为每个 query 增加一个 instruction用来模拟“带任务说明的检索”。具体做法是先由 3 名 NLP/IR 背景专家人工写 100 条 seed instruction然后使用 GPT-4o 通过 in-context learning 自动为每个任务生成 instruction。生成后的 instruction 会经过人工质量检查包括是否和原 query 相关、是否描述目标工具特征、是否覆盖所有目标工具、是否存在幻觉。这里需要注意一个细节作者的 instruction 是target-aware的也就是说生成 instruction 时会参考目标工具信息。这能让 instruction 更贴近工具功能但也带来一个值得讨论的问题如果 instruction 过度暴露目标工具特征评测可能会比真实用户查询场景更容易。因此论文同时设置了w/o inst.和w/ inst.两种评测模式分别观察只有 query 时和 queryinstruction 时的检索效果。四、TOOLRET 的数据特点TOOLRET 的工具文档主要分为三类。第一类是Web API通常以 OpenAPI 或 JSON 结构描述包含接口名称、参数、返回字段、请求方式等。第二类是Code Function也就是代码函数级别的工具例如 Python 函数、深度学习库函数、数学计算函数等。第三类是Customized App即自然语言描述的自定义应用或工具格式更自由。从规模上看TOOLRET 包含 7,615 个检索任务其中 Web API 任务 4,916 个Code Function 任务 950 个Customized App 任务 1,749 个工具总数为 43,215其中 Web API 工具 36,978 个Code Function 工具 3,794 个Customized App 工具 2,443 个。平均 query 长度为 46.87 tokens平均 instruction 长度为 43.43 tokens平均工具文档长度为 174.56 tokens。和传统 IR 数据集相比TOOLRET 的一个关键特点是query和目标工具文档之间的词面重叠非常低。论文用 ROUGE-L 计算 query 和 target tool documentation 的重叠度TOOLRET 只有 0.06而 NQ 是 0.31MSMARCO 是 0.34HotpotQA 是 0.11MTEB 是 0.27。这说明工具检索不能主要依赖关键词匹配而更依赖模型对“任务意图—工具功能—参数约束”的语义理解。五、论文中使用的模型说明这篇论文并不是提出一个单一的新模型而是提出一个 benchmark并在上面评测大量检索模型。模型大体可以分为六类。第一类是稀疏检索模型代表是 BM25s。BM25 主要依赖关键词匹配和词频统计它不真正理解语义但在很多检索任务中依然是强基线。本文发现在工具检索中 BM25 有时并不比复杂稠密模型差这反过来说明很多 dense retriever 并没有真正掌握工具语义。第二类是单任务稠密检索模型包括 GTR、Contriever、ColBERTv2 和 COLT。GTR、Contriever、ColBERTv2 通常在 MS-MARCO 等传统检索数据上训练COLT 则是已有工具检索方向的方法。它们通常采用双塔或类似结构把 query 和文档分别编码成向量然后计算相似度。但工具检索要求模型理解工具功能边界因此传统 dense retriever 迁移过来后效果并不理想。第三类是多任务 embedding 模型包括 all-MiniLM-L6-v2、E5 系列、BGE 系列、GTE 系列、GTE-Qwen2-1.5B-instruct、E5-Mistral-7B、GritLM-7B 和 NV-Embed-v1。这类模型通常在多个检索、匹配、问答或指令检索数据上训练泛化能力较强。论文中表现最突出的检索器之一是 NV-Embed-v1尤其在 w/ inst. 设置下效果较好。第四类是Cross-Encoder Re-ranker包括 MonoT5、mxbai-rerank-large-v1、jina-reranker-v2-base、bge-reranker-v2-m3、bge-reranker-v2-gemma。与双塔模型不同Cross-Encoder 会把 query 和候选工具文档放在一起编码因此理论上能做更细粒度的相关性判断。但它只能重排初始召回出来的候选工具如果第一阶段没有召回正确工具reranker 也无法补救。这也是本文中重排序提升有限甚至下降的重要原因。第五类是LLMreranking agent主要是 RankGPT 框架使用 Mixtral-8x22B、GPT-3.5-turbo-0125、GPT-3.5-turbo-1106 等大模型作为排序器。这种方法让大模型阅读候选工具并判断排序模拟工具选择过程。但实验说明直接让通用 LLM 做工具重排也不一定能系统性解决工具检索问题。第六类是下游工具调用LLM主要包括 GPT-3.5 和 ToolLLaMA。它们不是检索模型而是用来评估“检索结果会不会影响最终工具调用任务”。作者在 ToolBench 上把官方 oracle 工具集替换成检索模型找出的工具再观察 GPT-3.5 和 ToolLLaMA 的 Pass Rate。结果显示检索质量下降会明显拖累最终任务成功率。六、实验设置与评价指标论文使用四个主要检索指标。NDCGK衡量排序质量正确工具排得越靠前分数越高。RecallK衡量 top-K 结果中召回了多少目标工具。PrecisionK衡量 top-K 结果中有多少是正确工具。CompletenessK是工具检索中特别重要的指标只有当一个任务所需的所有目标工具都出现在 top-K 中时才记为 1否则为 0。对于多工具调用任务来说Completeness 比 Recall 更严格因为只找到一部分工具可能依然无法完成任务。实验有两种输入设置。第一种是w/o inst.模型只使用 query 做检索。第二种是w/ inst.模型使用 query 和 instruction 的拼接结果做检索。结果显示加入 instruction 后大多数模型都有明显提升尤其是本身经过 instruction tuning 的 embedding 模型如 NV-Embed-v1、E5-Mistral、GTE-Qwen2 等。七、主要实验结果分析从无 instruction 的结果看现有检索模型在 TOOLRET 上整体表现偏低。即使是 NV-Embed-v1 这样的强 embedding 模型平均 NDCG10 也只有 33.83Completeness10 为 32.12。BGE-large-en-v1.5 的平均 NDCG10 为 23.02BM25s 为 22.32说明强 dense retriever 并没有在工具检索中形成压倒性优势。加入 instruction 后整体指标明显提高。例如 NV-Embed-v1 的平均 NDCG10 从 33.83 提升到 42.71Completeness10 从 32.12 提升到 43.41GTE-Qwen2-1.5B-instruct 在 w/ inst. 设置下平均 NDCG10 达到 45.96bge-reranker-v2-gemma 的平均 NDCG10 达到 47.52Completeness10 达到 48.90。这个结果说明工具检索不仅需要 query还需要更明确的任务说明或检索意图描述。不过重排序模型的表现并不是一味更强。论文指出当使用 MonoT5 对 NV-Embed-v1 召回结果重排时平均 NDCG10 反而从 33.83 降到 28.92。原因在于重排序强依赖第一阶段召回结果如果召回阶段没有把正确工具放入候选集合后续 reranker 无法“凭空找回”正确工具。这对工具检索系统设计有很强启发第一阶段召回能力非常关键不能只依赖后处理重排。TOOLRET 与 MTEB 的相关性实验也很有意义。Figure 5 显示模型在 TOOLRET 和 MTEB retrieval subset 上有一定正相关Pearson 系数为 0.790但 Spearman 系数只有 0.441。这说明传统检索能力对工具检索有帮助但不能完全代表工具检索能力。换句话说一个模型在 MTEB 上强不等于它真的“懂工具”。八、论文所有插图说明Figure 1工具检索性能与工具调用成功率的关系。这张图位于论文首页是整篇文章的动机图。横轴是 IR 模型的 Recall10纵轴是 GPT-3.5-turbo 的 Pass Rate。图中有一条 oracle 水平线表示使用人工预标注工具集时的通过率大约为 64.2。下面不同点代表使用 E5、BGE、ColBERT 等检索模型召回工具后的通过率。图中最关键的信息是当把官方标注工具集换成检索工具集后任务成功率明显下降哪怕检索模型本身并不弱。这说明工具检索不是一个可有可无的前置步骤而是会直接影响 agent 最终表现的关键模块。Figure 2query与目标工具文档之间的 ROUGE-L 重叠分布。这张图展示了 TOOLRET 中输入 query 和目标工具文档之间的词面重叠。横轴是 ROUGE-L 分数纵轴是密度。大部分样本集中在很低的重叠区间说明用户查询和工具文档之间经常没有明显相同词。对于普通关键词匹配模型来说这会造成困难对于 dense retriever 来说也要求模型具备更强的语义对齐能力。结合 Table 2 可以看出TOOLRET 的平均 ROUGE-L 只有 0.06远低于 NQ、MSMARCO 和 MTEB。Figure 3query、instruction 和工具文档长度分布。Figure 3 由三个子图组成分别统计 query length、tool documentation length 和 instruction length。query 大多比较短符合真实用户输入习惯工具文档大多在 200 tokens 以下和传统文档检索中的 chunk 长度类似instruction 长度集中在几十个 tokens起到补充任务意图的作用。这张图说明 TOOLRET 不是长文本检索任务而是短 query 对结构化或半结构化工具文档的精准匹配任务。Figure 4生成 instruction 与人工 seed instruction 的 ROUGE-L 重叠。这张图用于检验 GPT-4o 生成的 instruction 是否只是简单复制人工 seed instruction。横轴是生成 instruction 和 100 条人工 seed instruction 之间的最高 ROUGE-L 重叠纵轴是密度。分布显示不少生成 instruction 和 seed 的重叠不高说明 GPT-4o 生成的 instruction 具有一定多样性。它支撑了作者关于 instruction construction 可扩展性的论点。Figure 5TOOLRET 与 MTEB 检索子集上的模型表现相关性。这张散点图横轴是模型在 TOOLRET 上的得分纵轴是模型在 MTEB retrieval subset 上的得分。图中给出 Pearson coefficient 0.790Spearman coefficient 0.441。它表达的是TOOLRET 和传统 IR 任务有一定关联但排序并不完全一致。某些传统检索模型在 MTEB 上表现不错但到了工具检索任务上就明显下降。因此工具检索需要专门 benchmark不能只用传统 IR 榜单代替。Figure 6检索模型训练前后与下游 Pass Rate 的关系。Figure 6 是本文最重要的结果图之一。它包含 6 个子图上排是 GPT-3.5 在 ToolBench-G1、G2、G3 上的结果下排是 ToolLLaMA 在三个子集上的结果。横轴是 NDCG10纵轴是 Pass Rate。图中箭头表示经过 TOOLRET-train 训练后IR 模型从原始点移动到改进点。整体趋势很清楚检索指标提升后下游工具调用成功率也随之提高。它把“工具检索质量”和“最终 agent 能不能完成任务”连接起来是论文结论中最有说服力的一张图。Figure 7附录中的 TOOLRET 与 MTEB 相关性补充图。Figure 7 出现在附录中本质上是对 Figure 5 所讨论问题的补充展示继续说明 TOOLRET 和传统 IR benchmark 之间存在相关性但工具检索仍然具有额外难度。它的作用不是提出新结论而是增强主文中“传统 IR 能力不能完全代表工具检索能力”的论证。此外论文附录还有Algorithm 1它不是普通图表而是 instruction 自动构造的伪代码。流程是输入人工 seed instruction、强 LLM 和任务集合初始化 instruction pool每次从池中采样若干示例用 GPT-4o 通过 in-context learning 生成新 instruction再把新 instruction 加回池中最后经过启发式过滤得到高质量 instruction。这个算法解释了 TOOLRET 的 instruction 是如何规模化生成的。九、TOOLRET-train 与训练方法TOOLRET-train 是作者进一步提出的大规模训练集。它包含 205,826 个检索任务平均 query 长度 52.87 tokens平均 instruction 长度 46.72 tokens平均工具文档长度 163.52 tokens平均每个 query 有 2.31 个目标工具。论文正文中多处提到使用 NV-Embed-v1 为每个 query 检索 negative tools并设置 K10但 Table 7 又写的是每个 input query 有 5 个 negative tools。训练目标类似对比学习或 softmax ranking loss。对于一个 query 和 instruction 拼接后的输入模型要提高 target tools 的相似度同时压低 negative tools 的相似度。公式中I ⊕ q表示 instruction 和 query 的拼接sim()表示输入和工具文档之间的相似度。训练时学习率设置为 5e-5。作者还做了消融实验去掉 instruction 只用 query 训练也能提升但不如 instructionquery 的训练效果说明 instruction 对工具检索训练确实有帮助。十、论文结论本文最后得出的结论很明确工具检索是工具调用LLM的关键瓶颈。现有通用 IR 模型虽然在传统检索任务中表现强但并不等于它们可以直接解决工具检索问题。工具检索要求模型理解任务意图、工具功能、参数要求、工具之间的细粒度差别以及多工具组合需求。TOOLRET 的价值在于它把原来被很多工具调用 benchmark 弱化的“工具选择前置步骤”单独拿出来评测并证明这个步骤会直接影响下游 agent 的 Pass Rate。TOOLRET-train 的价值在于它进一步证明工具检索模型可以通过专门数据训练获得明显提升而这种提升可以传导到最终工具调用任务上。十一、这篇论文的不足第一TOOLRET 是从多个已有数据集合并而来的存在潜在的 one-to-many 问题。也就是说对于某个 query原数据集标注的工具是 ground truth但合并后的大工具库中可能存在其他功能相近、同样可以解决任务的工具。如果评测只认可原始标签就可能低估某些模型的合理检索结果。作者在讨论部分承认了这个问题并认为真实场景下模型仍需要区分“最合适的工具”。第二instruction 是通过 target-aware 策略生成的这在评测设计上有一定争议。它能帮助模型更明确地理解任务需求但也可能让 instruction 携带过多目标工具特征。对于真实用户场景用户通常不会提供这么准确的工具功能描述。因此w/ inst. 的结果可以看作“理想增强查询”下的表现而 w/o inst. 更接近原始用户查询检索。第三论文主要关注英文文本工具检索没有深入处理多语言、多模态工具检索问题。工具调用场景中很多工具可能涉及图像、音频、视频、地理位置、数据库模式、权限说明等复杂信息仅靠文本检索还不够。第四论文强调了检索对下游 Pass Rate 的影响但仍主要采用 retrieval-then-calling 的一次性流程。真实 agent 场景中模型可能边规划、边检索、边调用工具即 interleaved retrieval-and-calling。论文也把这一点作为未来方向提出。十二、对图结构增强工具检索研究的启发这篇论文对“图结构增强工具检索”方向非常有参考价值。它证明了一个基本前提工具检索确实是瓶颈而且不是普通语义检索可以完全解决的瓶颈。因此在工具之间构建关系图用共现关系、参数依赖关系、语义互补关系来增强检索是有研究必要性的。对你的研究来说可以重点吸收三点。第一评估指标不能只看 RecallK还应该加入 CompletenessK因为多工具任务中“找全工具”比“找到一个工具”更重要。第二不能只做离线检索指标最好进一步观察检索结果对工具调用成功率的影响例如 oracle toolset、baseline retriever、graph-enhanced retriever 三者对比。第三TOOLRET 强调工具之间有细粒度功能差别这正好可以转化为图结构中的边共现边刻画任务中经常一起出现的工具语义互补边刻画功能上可组合、参数上可衔接、流程上可前后依赖的工具。可以说这篇论文不是在做图检索但它为图结构增强工具检索提供了很好的问题依据现有检索器不够 tool-savvy而工具图有机会把“工具之间的结构性知识”补进去。一些补充1、这里的 instruction 是什么在这篇论文里instruction 不是模型训练时的系统提示词也不是工具文档本身而是作者额外给每个检索任务生成的一段“检索说明”。原始 query 可能很短比如transcribe this audio to text 把这段音频转成文字但检索模型只看到这句话时可能不知道应该重点找什么工具。于是作者额外生成一个 instruction大概像retrieve tools that process audio inputs to produce accurate textual transcriptions aligned with the user requirements 检索能够处理音频输入并根据用户需求生成准确文本转录结果的工具也就是说query是用户原始需求instruction 是对这个需求的检索意图解释。它告诉检索模型“你不要只按关键词搜而要找具备某类功能的工具。”论文明确说instructional information retrieval 就是在 input query 之外再配一个 instruction用来指导 IR 模型检索目标信息。放到 TOOLRET 中instruction 的作用就是帮助检索模型更清楚地理解这个任务到底需要什么类型的工具。所以无 instruction 时NV-Embed-v1 的平均 NDCG10 只有 33.83说明即使强检索模型只看原始 query也很难准确理解工具需求。论文也指出TOOLRET 中 query 和 target tools 的词面重叠很低因此模型不能简单依赖关键词匹配。2、NV-Embed-v1 K-means 为什么可以保留任务多样性这里的逻辑是这样的。作者收集了很多数据集但有些数据集特别大而且里面可能有很多重复或相似任务。如果全部保留评测会有两个问题第一计算成本太高第二某些类型的任务占比过大会让 benchmark 不均衡。所以作者先用NV-Embed-v1把每个任务 query 编码成向量。这个向量可以理解为任务的“语义坐标”。语义相似的任务在向量空间中距离更近语义差异大的任务距离更远。然后用K-means聚类。K-means 会把这些任务分成若干簇每个簇大致代表一种任务类型或语义区域。最后作者从每个簇中随机抽取一个任务。这样做的好处是不是从所有任务中随机抽样而是从不同语义簇里各抽一个避免抽到一堆高度相似的任务。举个简单例子。假设一个数据集里有 500 个任务其中 300 个都是“天气查询”100 个是“翻译”100 个是“图片处理”。如果直接随机抽样天气类任务可能占很多。但如果先聚类再从每个簇里抽样就更容易保留天气、翻译、图片处理等不同任务类型。所以它能保留任务多样性的关键在于先按语义相似性分组再从不同组里采样。论文中也写到作者对每个数据集使用 NV-Embed-v1 编码任务再用 K-means 在文本 embedding 上聚类并从每个 cluster 中随机采样一个任务。3、target-aware 是什么意思target-aware可以拆开看target 目标工具也就是 ground-truth toolsaware 知道、感知、参考。所以target-aware instruction construction的意思是作者在生成 instruction 时不只是看用户 query还会参考这个 query 对应的目标工具信息。普通 instruction 生成可能是这样的输入query输出instruction而 target-aware 是输入query target tools输出instruction这样生成出来的 instruction 会更准确地描述“应该检索什么工具”。例如用户 query 很短只写了convert audio to text如果不看 target tool模型可能只能生成泛泛的说明。但如果看到目标工具是某个 speech-to-text API那么生成的 instruction 就会更明确地强调“audio input”“text transcription”“accurate transcription”等功能特征。这就是 target-aware 的核心生成检索说明时利用了目标工具的信息让 instruction 更贴近正确工具的功能。不过这也有争议。因为真实检索场景中我们通常不知道 target tools。如果已经知道 target tools再生成 instruction就有一点“参考答案参与出题”的味道。所以我前面说w/ inst. 的结果更像是“理想增强查询”场景而 w/o inst. 更接近真实用户原始查询场景。论文中写到作者先让专家写 100 条 seed instructions再用 GPT-4o 作为 instruction generator通过 in-context learning 为每个任务生成 instruction而且这个 instruction 用来连接 query intent 和 target tools 的功能。4、w/o inst. 和 w/ inst. 分别是什么这两个是论文中的两种评测设置。w/o inst.是without instruction的缩写意思是“不使用 instruction”。模型输入只有 query输入 query例如query: convert audio to text模型直接拿这个 query 去检索工具。w/ inst.是with instruction的缩写意思是“使用 instruction”。模型输入是 query 和 instruction 拼接起来输入 query instruction例如query: convert audio to text instruction: retrieve tools that process audio inputs to produce accurate textual transcriptions然后模型用这段更完整的文本去检索工具。论文原文也明确说明w/o inst. 中模型只使用 query 作为输入w/ inst. 中模型使用 query 和 instruction 的拼接结果作为输入。这样可以分析 instruction 对检索效果的影响。可以简单理解为w/o inst. 用户原话检索 w/ inst. 用户原话 检索意图解释后再检索5、MTEB、Pearson 系数、Spearman 系数是什么MTEB全称是Massive Text Embedding Benchmark可以理解为一个大型文本向量模型评测基准。它不是单一数据集而是一组任务集合用来评估 embedding model 在检索、分类、聚类、语义相似度等任务上的能力。论文这里关注的是MTEB retrieval subset也就是 MTEB 里面和检索相关的那部分任务。作者把模型在 TOOLRET 上的表现和在 MTEB retrieval subset 上的表现做相关性分析想看一个问题传统检索 benchmark 上强的模型在工具检索 benchmark 上是不是也强Figure 5 的结论是有一定关系但不是完全一致。Pearson 0.790说明整体趋势有较强正相关Spearman 0.441说明模型排名的一致性只是中等偏弱。论文也据此说明TOOLRET 和传统 IR 任务有相关性但工具检索更难也有自己的特殊性。Pearson 系数衡量的是“线性相关性”。简单说它关心两个变量是不是大体沿着一条直线一起变化。例如模型 A 在 MTEB 高在 TOOLRET 也高模型 B 在 MTEB 低在 TOOLRET 也低。这种情况下 Pearson 就会比较高。但 Pearson 更关心“数值趋势”不完全关心排名。Spearman系数衡量的是“排名相关性”。它不太关心具体分数差多少而是关心排序是否一致。例如在 MTEB 上排名是A B C D在 TOOLRET 上如果也是A B C D那么 Spearman 很高。但如果变成B D A C那 Spearman 就会下降。所以 Figure 5 中 Pearson 0.790Spearman 0.441可以解释为模型在传统检索任务和工具检索任务上的整体强弱有一定关系但具体模型排名并不稳定。传统 IR 强不代表工具检索一定强。这对你的研究很重要因为它说明不能只看 MTEB 排名来选择工具检索模型工具检索需要单独评估。6、ROUGE-L 分数是什么ROUGE-L是一种文本相似度指标常用于摘要、生成文本和参考答案之间的重叠度评估。这里的 L 指的是Longest Common Subsequence即“最长公共子序列”。它关注两个文本之间有多少词或 token 可以按相同顺序匹配上但不要求连续。举个例子文本 Asearch Chinese news articles文本 Bretrieve news articles written in Chinese这两个文本中“news articles Chinese”这些词在语义上和顺序上有一定对应所以 ROUGE-L 会有一定分数。如果两个文本几乎没有共同词比如文本 Afind restaurants nearby文本 Bgeolocation-based business discovery API它们语义可能相关但词面重叠很低ROUGE-L 分数就会很低。论文中用 ROUGE-L 来衡量 query 和 target tool documentation 的词面重叠程度。结果显示TOOLRET 的 ROUGE-L 只有 0.06而 NQ、MSMARCO、MTEB 等传统检索任务更高。这说明 TOOLRET 中用户 query 和工具文档之间表面词汇重叠很少检索模型必须做更深层的语义匹配。所以 ROUGE-L 在这篇论文里不是最终检索指标而是用来说明TOOLRET 的 query 和目标工具文档在字面上很不像因此工具检索更难。7、训练目标这段到底是什么意思这部分是全文里比较技术的一块我拆成一个具体过程讲。作者训练检索模型时每个训练样本大概包含四部分query instruction target tools negative tools其中query是用户任务。instruction是额外生成的检索说明。target tools是正确工具也就是模型应该检索到的工具。negative tools是错误工具也就是模型不应该排在前面的工具。论文中说每个训练任务包含 query q 和目标工具集合 T同时用 target-aware 策略给 query 配一个 instruction I训练时还用模型检索 top-K negative tools并设置 K10、learning rate5e-5。现在看公式里的几个符号。I ⊕ q表示 instruction 和 query 拼接。比如query: convert audio to text instruction: retrieve tools that process audio inputs to produce accurate textual transcriptions拼接后就是retrieve tools that process audio inputs to produce accurate textual transcriptions [SEP] convert audio to text这个拼接后的文本就是检索模型的输入。sim(I ⊕ q, ti)表示“输入文本”和某个工具 ti 之间的相似度。如果 ti 是正确的语音转文字工具模型应该让这个相似度变高。如果 tj 是无关的天气查询工具模型应该让这个相似度变低。所以训练目标可以简单理解为正确工具的分数要高错误工具的分数要低。这就是我说它类似对比学习或softmax ranking loss的原因。可以用一个小例子说明。假设有一个任务query: 把音频转成文字 instruction: 检索能够处理音频并输出文字转录的工具候选工具有 4 个ASpeech-to-Text API正确工具 BWeather API错误工具 CImage Caption API错误工具 DStock Price API错误工具训练前模型可能打分是A 0.45 B 0.50 C 0.40 D 0.35这就不行因为 Weather API 分数比 Speech-to-Text API 还高。训练的目标是把它调整成A 0.90 B 0.15 C 0.20 D 0.10也就是让正确工具 A 的相似度明显高于负样本 B、C、D。softmax ranking loss的作用就是把这些相似度转成概率。比如模型看到 A、B、C、D 四个工具它应该把大部分概率分给正确工具 A。如果它把概率分给了错误工具 Bloss 就会变大如果它把概率分给了正确工具 Aloss 就会变小。所以这段公式本质上不是很神秘它就是在做一件事给定 query instruction让模型在正确工具和错误工具之间做选择并不断训练它把正确工具排到前面。作者还做了一个消融实验把 instruction I 去掉只用 query 训练。结果发现只用 query 训练也比不训练好但效果不如 query instruction。这说明 instruction 不是摆设它确实给检索模型提供了更明确的检索方向。论文也明确说去掉 instruction 的变体虽然比未微调模型有提升但弱于 instruction-tuned 的版本。最简单地总结这段训练逻辑输入query instruction 正样本target tools 负样本negative tools 目标让模型更像正确工具不像错误工具 结果检索模型更懂“任务需求和工具功能之间的对应关系”