【LLM Tool Learning】论文分享： Chain-of-Tools

论文名称：Chain-of-Tools: Utilizing Massive Unseen Tools in the CoT Reasoning of Frozen Language Models

论文链接：arxiv.org/abs/2503.16...

机构：苏州大学

Github代码链接：github.com/fairyshine/...

简介

本文主要是提出了一种可以提升LLM工具使用的泛化能力的方法，叫Chain-of-Tools，并且构建了一个新的知识问答数据集叫SimpleToolQuestions。方法在两个数理基准（GSM8K-XL、FuncQA）以及 两个知识问答基准（KAMEL、Chain-of-Tools）的效果均优于Baseline，相关代码和数据也做了开源，值得一看。

Motivation

对于LLM的工具学习方法，主要有两种：

• 基于微调的方法（Fine-tuning）：比如API-Bank、ToolLLM等，这种思路训练完，模型对于域内工具的使用能力会有提升，但涌现能力和CoT可能会受到影响。即使后面有ToolkenGPT这种方法不会伤害模型原有的能力，但泛化能力依然没有明显的提升。

• 基于上下文学习的方法（In-Context Learning）：比如HuggingGPT、AgentBench这种，虽然可以灵活的调用看不见的工具，但推理效率较低。

  

表1就展示了上述方法的优劣点，作者肯定是吹了一波自己的方法了，不赘述。各列名的含义如下：

• Tool Learning Paradigms：工具学习范式（指不同的工具学习方法类型）。
• Frozen LMs：是否支持冻结大语言模型（即不修改模型原有参数）。
• Plugable：工具是否可插拔（即能否灵活加载工具）。
• Massive Tools：是否适用于处理大量工具的场景。
• Unseen Tools：是否支持使用训练中未见过的新工具。
• Ability to Use Extensive Data：是否具备利用广泛训练数据提升方法性能的能力。

框架概述

图2展示了Chain-of-Tools（CoTools）的工作流程，主要包括思维链推理（CoT Reasoning）、工具选择（Tool Selection ）和工具调用（Tool Calling）三大部分。

思维链推理（CoT Reasoning）

在这一部分（图中左侧粉色区域），首先有一个任务提示（Task Prompt），包含问题（Query）和答案（Answer）相关部分。基础模型（Foundation Model）会基于此进行处理。这里有个工具判断模块（Tool Judge） ，它会判断是否需要调用工具。如果判断结果为不需要（NO），基础模型的语言模型头部（LM Head）就继续生成下一个标记（Generate Next Token） ；如果判断结果为需要（YES），则进入工具选择环节。

工具选择（Tool Selection ）

这部分（图中上方右侧区域）又细分为工具检索（Tool Retriever ）相关步骤：

• 检索提示（Retrieval Prompt） ：包含问题（Query）和答案片段（Answer Fragment），经基础模型的查询编码器（Query Encoder）处理得到查询向量（Query Vector） 。
• 工具提示（Tool Prompt） ：包含工具名称（Tool Name）和工具描述（Tool Description），通过工具编码器（Tool Encoder）得到工具向量（Tool Vectors） 。然后计算查询向量和工具向量之间的相似度（Similarity），依据相似度给各个工具打分（Score），选出得分最高（MAX）的工具 。工具相关信息都存储在工具数据库（Tool DataBase）中，这里面有工具池（Tool Pool ），还能进行工具管理（如添加工具、移除工具、执行工具等操作 ）。

工具调用（Tool Calling）

选好工具后进入这一环节（图中下方粉色区域） 。调用提示（Calling Prompt）包含工具相关信息（Tool 、Doc、Demo ）、问题（Query）和答案片段（Answer Fragment）。基础模型基于此进行处理，接着执行工具（Tool Execution），将工具执行结果添加到答案中（Add in Answer ） 。

一句话总结

其实从上面的流程中可以看到，整个流程践行的思路就是：先看需不需要用工具，要用的话就从一堆工具里找最匹配问题的，找到后用这个工具处理问题并把结果加到答案里。

接下来的部分，会挨个介绍一下整个方法的细节。

整体思路（Hidden State Based）

输入文本经过分词之后得到token序列，基础模型按照自回归的方式生成最后一个 token 的隐藏状态（hidden state）：

这个隐藏状态不仅能用于生成下一个token：

还可以作为工具调用决策的核心依据。

所以整个过程就能在冻结基础模型参数的前提下，只对tool judge、query encoder和tool encoder进行后训练。

Tool Judge: Whether Calling Tools

这一步核心是通过基础模型的隐藏状态判断是否需要调用工具。

Step-1：工具使用判断

首先会定义一个工具使用判断函数：

为了方便博客撰写，直接贴上我处理好的带公式的图片了，下同：

Step-2：工具调用决策阈值

其次定义调用工具的决策阈值：

策略如下：

Step-3：目标函数：二元交叉熵损失

本质上是个二分类任务，所以通过二元交叉熵损失函数进行训练：

其中：

• 标签（Label）：

  • 1：需要调用工具（如涉及数学计算、实时数据查询等场景）；
  • 0：无需调用工具（如纯文本推理）。

• 目标：使模块能准确区分 "需要工具" 和 "无需工具" 的场景，例如：

  • 当问题为 "解释勾股定理" 时，Label=0（纯逻辑推理）；
  • 当问题为 "计算月球到地球的平均距离" 时，Label=1（需要调用天文数据工具）。

具体例子讲解

光看公式可能不知所以然哈，举个例子帮助理解。

假设用户提问："计算 345 × 23 + sin (π/4) 的值"。

• 输入处理：

  • 问题通过 ICL 和 CoT 提示分词为 token 序列，如：["计算", "345", "×", "23", "+", "sin", "(", "π", "/", "4", ")"]。
  • 基础模型处理后生成最后一个 token（"4"）的隐藏状态h_t。

• 工具判断计算：

  • 将h_t输入公式（3），计算Score。
  • 由于问题涉及数学运算（乘法、三角函数），基础模型的隐藏状态可能会体现出 "需要工具辅助计算" 的语义特征，从而使得Score远高于阈值 0.5（例如 0.8）。

• 决策结果：

  • 触发工具调用，进入工具检索环节（Tool Retriever），选择合适的数学计算工具（如计算器工具）。

Tool Retriever: Find Needed Tools

这一步的核心是通过查询编码器和工具编码器将问题与工具映射为向量，基于向量相似度实现工具检索。

Step-1：查询向量（Query Vector）生成

主要看下面的公式：

继续附上处理好的图片文字：

对查询编码之后，生成查询向量：

其中：

Step-2：工具向量（Tool Vector）生成

整个过程与查询向量生成差不多：

其中：

Step-3：相似度计算与工具选择

接下来就是公式9到10的逻辑了，其实就是通过向量点积计算问题与工具的语义相似度，选择得分最高的工具。

Step-4：目标函数：对比学习交叉熵损失

因为是要挑出最适合的工具，所以采用了对比学习损失：

其中：

• 训练逻辑：

  • 在一个批次内，将正样本（正确工具）与负样本（其他工具）的相似度得分作为输入，通过交叉熵损失迫使模型学会区分相关工具与无关工具。
  • 例如：批次中包含 "天气查询工具"（正样本）和 "计算器工具""翻译工具"（负样本），模型需将正样本的得分显著高于负样本。

• 评估时：工具检索范围扩展至整个工具池，而非仅限批次内的工具，确保模型能泛化到大规模工具场景。

具体例子讲解

假设用户提问："查询 2024 年 7 月 23 日巴黎的天气情况"。

• 查询向量生成：

  • 检索提示为：["查询", "2024年7月23日", "巴黎", "的天气情况", "</s>"]。
  • 基础模型计算结束符 </s> 的隐藏状态，经查询编码器得到V_Q，其中关键维度表征 "时间"、"地点"、"天气" 等语义。

• 工具向量生成：

  • 工具池中有 "天气查询工具"，其描述为：["获取", "指定城市", "和日期", "的天气", "温度", "降水", "</s>"]。
  • 基础模型处理工具描述后，经工具编码器得到V_T，关键维度与 "城市""日期""天气参数" 匹配V_Q。

• 相似度计算与工具选择：

  • V_Q与V_T的点积得分最高（如 0.92），因此选择 "天气查询工具"。

Tool Calling: Use Retrieved Tools

这一步的核心是通过上下文学习（ICL）提示生成工具参数，并将工具执行结果融入回答。

Step-1：ICL 提示生成工具参数

• 输入：已检索到的目标工具（如 "天气查询工具"）和当前推理中的问题、答案片段。
• 方法：基于上下文学习（ICL）提示生成工具所需的参数。若工具需要 "城市" 和 "日期" 参数，ICL 提示中会包含类似以下格式的示例：

Tool: WeatherQuery  
Parameters:  
- city: Shanghai  
- date: 2024-05-20  

接下来模型就可以通过模仿示例格式，从问题中提取参数（如从 "巴黎 2024 年 7 月 23 日天气" 中解析出city=Paris、date=2024-07-23）。

Step-2：格式约束与参数提取

• 提示强调格式：在工具调用提示中明确要求输出符合特定格式（如 JSON、函数调用格式），例如：

Please call the tool in the format:  
[ToolName](parameter1=value1, parameter2=value2)  

• 正则表达式提取参数：通过正则表达式从模型输出中解析参数值，确保工具能正确接收输入。例如，从输出Weather("Paris", "2024-07-23")中提取城市和日期。

Step-3：工具执行与结果融合

• 工具执行：根据参数调用实际工具（如 API 接口），获取返回结果（如{"temperature": "25℃", "condition": "sunny"}）。
• 结果融入回答：将工具返回值插入到回答片段中，形成完整的思维链推理。例如：

The weather in Paris on 2024-07-23 is sunny with a temperature of 25℃.

实验数据集

数值推理

使用ToolkenGPT创建的GSM8K-XL（含4种基础算术工具）和FuncQA（含13种算术工具，含单步/多步问题），评估侧重结果正确性，指标为Round Accuracy（单步）和Approx Accuracy（多步）。

基于知识的问答

采用KAMEL（234种工具，含人工标注集KAMEL(sup)和ChatGPT生成集KAMEL(syn)）和新构建的STQuestions（1836种工具，999种训练集可见、837种测试集未见） ，重点评估工具选择准确性，尤其针对大规模工具和未见工具场景。

实验结果

主要结论

①【表2】在数值推理（GSM8K-XL、FuncQA）和基于知识的问答（KAMEL、STQuestions）场景的实验中，CoTools在工具选择上全面优于基线方法，尤其在大规模工具和未见工具场景表现出色且提升了模型可解释性。

②【表3】在数值推理任务中，CoTools在GSM8K-XL和FuncQA数据集上的表现优于0-shot Prompting、CoT Prompting等基线方法，且相比ToolkenGPT在部分场景更具优势，其性能依赖基础模型能力且能增强模型表现。

③【表4】在KBQA任务中，CoTools在KAMEL（含高质量和低质量训练数据）及STQuestions（含大量可见和未见工具）场景下的工具选择准确性均优于ToolkenGPT，尤其在低质量数据和未见工具场景优势显著。

Data Synthesis Analysis

④【图4】在使用高质量人工标注的KAMEL(sup)数据集微调基础模型时，CoTools和ToolkenGPT在工具选择准确性上表现均较好，且CoTools的前5选择准确性接近100%，在真实场景中表现稳定。

⑤【图5】在使用ChatGPT合成的低质量KAMEL(syn)数据集微调基础模型时，CoTools的工具选择准确性比ToolkenGPT高20%以上，显示出对比学习在数据有限场景下对工具区分能力的提升优势。

Tool Use Analysis

⑥【图6】在工具规模达千级的STQuestions基准测试中，CoTools的工具选择准确率显著高于ToolkenGPT，且随着工具数量增加，其凭借大语言模型的强语言理解能力在相似工具场景中优势更明显。

⑦【图7】在未见工具场景中，ToolkenGPT存在显著偏向调用已见工具的问题，而CoTools能更有效区分已见与未见工具，减少对已见工具的错误调用。

Hidden States Analysis

⑧【图8】学习率越大，工具检索模块共享参数W_dim的权重变化越显著，部分参数从初始值 1 大幅下降至接近 0。

⑨【图9】归一化后，不同学习率下的 W_dim权重呈现相似趋势，共享参数中数值较高的维度对工具选择起关键作用。

⑩【图10】随着学习率增加，工具检索的关键维度更集中，仅用部分高权重维度（如学习率 0.01 时的 1561 个维度）进行检索，准确率下降极少，表明 LLM 隐藏状态维度存在语义信息分工。

总结

本文方法属于后训练阶段的监督微调（SFT） 。主要是通过在 KAMEL 等数据集上微调冻结的基础模型（如 GPT-3.5），优化其工具选择和调用能力。所以说实际训练的时候，基本上就是主要做Tool Judge和Tool Retriever的训练，至于在Tool Calling之后产生的包含Tool调用的CoT数据怎么使用，就看具体需求了，也可以把论文的思路当作是构建Tool调用训练数据的一种方法。

但在实际落地的过程中，本文这个训练方法要想做到游泳，还需要注意的问题：

① 工具描述依赖性强：CoTools 依赖工具文档的准确性和完整性，若工具描述模糊或缺失，可能导致选择错误。

② 上下文依赖性：用户问题的表述方式可能影响工具选择准确性，所以PE工程设计要足够鲁棒，能够适用不同的用户问题。

③ 大规模工具效率瓶颈：当工具数量达到千级时，动态检索和匹配的计算成本显著增加，可能影响实时响应速度。

④ 未见工具泛化局限：尽管 CoTools 在实验中表现较好，但实际场景中工具功能可能就高度专业化，需更多标注数据才能覆盖长尾需求。实验中采取的两个场景还是偏"简单"了。

⑤ 学习率敏感问题：如论文图 8-10 所示，学习率调整对模型参数稳定性影响较大，需精细调优以避免性能波动。