On the Tool Manipulation Capability of Open-source Large Language Models

文章标题：论开源大语言模型的工具操纵能力
作者/机构：Qiantong Xu, Fenglu Hong, Bo Li, Changran Hu, Zhengyu Chen, Jian Zhang, SambaNova Systems, Inc. Palo Alto, CA, USA

A1 主要贡献

核心问题：近期关于使用大型语言模型（LLMs）进行软件工具操纵的研究主要依赖于封闭模型API。由于向封闭LLM API服务暴露信息存在安全和鲁棒性风险，这些模型的工业应用受到极大限制。本文旨在探讨，我们能否在实际可行的人工监督下，增强开源LLMs，使其在工具操纵方面具备与领先的封闭LLM API相竞争的能力。

研究目标与创新点：
本文首先通过分析常见的工具操纵失败案例，揭示了开源LLMs在工具操纵方面面临的关键挑战，并基于这些洞察提出了一套实用的增强方案。
1. 揭示核心挑战：研究发现开源LLMs在工具操纵中面临三大挑战：
* API选择困难：开源模型难以准确识别API名称，而封闭模型似乎在训练中内化了API使用知识。
* API参数填充混淆：若无示例，开源LLM通常无法为API参数填充正确的值。
* 生成非可执行内容：开源LLM倾向于生成超出所需代码范围的自然语言等非可执行内容。

  1. 提出并验证增强技术：受上述挑战启发，本文重新审视并调整了LLM领域的经典技术，以增强开源LLM的工具操纵能力，这些技术仅需少量人工监督：

    • 模型对齐（Model Alignment）：通过程序化生成的数据进行指令微调，使模型内化API使用知识。此方法首先由人工编写少量（几十个）关于目标和相应API调用的模板，然后通过实例化模板中的关键词来批量生成数据。
    • 上下文演示检索器（In-context Demonstration Retriever）：受检索增强生成（Retrieval-Augmented Generation）的启发，为LLM配备一个检索器，在推理时从人工策划的示例池中挑选与当前目标语义最相似的演示示例。
    • 系统提示（System Prompt）：将目标描述嵌入预定义的系统提示中，为模型提供推理时的指导，以规范其生成可执行的API调用。

  2. 构建并开源评测基准ToolBench：为了对这些技术进行评估，本文创建了ToolBench，一个包含八种用于真实世界任务的多样化软件工具的工具操纵基准测试。与现有工具增强LLM文献中的基准相比，ToolBench是首个提供预定义测试用例以进行公开量化评估的测试平台。

核心结论：
实验证明，本文提出的技术能将领先的开源LLM的成功率提升高达90%，使其在ToolBench的8个任务中的4个任务上表现出与OpenAI GPT-4相媲美的能力。这种增强通常每个工具只需要大约一个开发日来策划数据，证明了该方案在人工监督成本上的实用性。

图1：工具操纵设置。我们将LLM增强为可访问API文档的动作生成器。在单步场景中，动作生成器直接生成API调用以完成目标。多步动作生成器则使用API调用与环境进行迭代交互，并根据环境信息生成下一步调用，直到达到退出状态。
图1：工具操纵设置。我们将LLM增强为可访问API文档的动作生成器。在单步场景中，动作生成器直接生成API调用以完成目标。多步动作生成器则使用API调用与环境进行迭代交互，并根据环境信息生成下一步调用，直到达到退出状态。

A3 背景知识与关键观察

2.1 工具操纵设置

将自然语言目标转化为API调用。本文研究的场景是将软件用户的自然语言目标描述$g$转化为一个API调用序列$C_g = \{c_0, c_1, \dots, c_{n_g}\}$来完成目标。选择API作为研究对象，是因为它们是现代软件系统中开发者和用户普遍使用的抽象层。

基于大型语言模型的动作生成器。自回归语言模型通过对给定上下文序列$x_0, x_1, \dots, x_N$的下一个词$x_{N+1}$的条件概率$p(x_{N+1}|x_0, x_1, \dots, x_N)$进行编码【索引21, Speech and Language Processing, Jan 2023】，并通过迭代采样生成语言续写。近期基于Transformer的大型语言模型在遵循指令进行文本和代码生成方面展现了前所未有的能力【索引22, Language models are few-shot learners, 2020, Advances in neural information processing systems】, 【索引23, Multitask prompted training enables zero-shot task generalization, 2021, arXiv preprint arXiv:2110.08207】, 【索引24, Evaluating large language models trained on code, 2021, arXiv preprint arXiv:2107.03374】。在工具操纵的背景下，我们将目标描述和可选信息作为上下文中的指令，让LLM生成API调用的代码作为续写。

算法1：API调用生成

输入: 目标 g, API文档 D, 动作生成器 A
输入: 可选信息 O
1: procedure ACTIONGEN(g, D, A, O)
2:    Dg ← R(g, D)   ▷ 检索API函数
3:    Cg ← A(g, Dg, O) ▷ API调用生成
4:    return Cg
5: end procedure

动作生成器与检索增强。工具操纵的一个关键实现是动作生成器$A$，它将目标$g$映射到API调用$C_g$。由于开源LLM可能未见过相关API信息，我们通过提供一个包含$m$个候选API函数的池$D = \{d_0, d_1, \dots, d_m\}$来将LLM $M$增强为动作生成器。考虑到LLM的输入序列长度限制，我们提供一个可选的检索器$R$来保留一个相关的API文档子集$D_g = R(g, D) \in D$。因此，动作生成器产生的API调用序列为$C_g = A(g, D_g, O)$，其中$O$代表可以包含在提示中的可选信息。这是一种朴素的检索增强生成方法【索引18, In-context retrieval-augmented language models, 2023, arXiv preprint arXiv:2302.00083】, 【索引25, Retrieval-augmented generation for knowledge-intensive nlp tasks, 2020, Advances in Neural Information Processing Systems】, 【索引26, Few-shot learning with retrieval augmented language models, 2022, arXiv preprint arXiv:2208.03299】，我们使用了一个现成的检索器实现【索引27, Haystack documentation, 2023, https://docs.haystack.deepset.ai/docs/retriever#bm25-recommended】进行研究，但也鼓励社区探索为动作生成器量身定制的算法 。

单步与多步工具操纵。如图1所示，动作生成器可以以单步或多步方式与软件交互。在单步场景中，动作生成器直接产生一个API调用序列$C_g = A(g, D_g, \emptyset)$。在多步场景中，动作生成器产生一系列API调用序列$C_g = \cup_i C_{g,i}$，其中每个分段$C_{g,i}$用于与预定义的环境$E$交互并生成观察$O_i = E(C_{g,i})$。然后，该观察被用来生成新的分段$C_{g,i+1} = A(g, D_g, O_i)$。这个过程在达到退出状态时停止。为清晰起见，除非另有说明，本文其余部分将使用单步设置进行说明。我们在第6节的实验中涵盖了单步和多步两种情况。

2.2 激励性观察

开源LLM与闭源LLM的巨大能力差距。为了评估开源LLM的工具操纵能力，我们使用第2.1节中讨论的设置将它们与OpenAI GPT-4 API进行比较。我们最初预计闭源LLM在工具操纵方面会表现出优势，正如在传统NLP任务中观察到的那样【索引12, Holistic evaluation of language models, 2022, arXiv preprint arXiv:2211.09110】。然而，我们观察到的差距远超预期。例如，在一个房屋搜索任务中，开源LLM生成正确的API调用非常困难，导致与零样本GPT-4 API相比，成功率存在70%的差距，如表1所示。这种差距激励我们研究阻碍开源LLM性能的因素。

表2：工具操纵错误示例。错误部分以红色突出显示。
图2：左图：在推理过程中不暴露API文档，闭源LLM在选择API方面仍能达到高准确率，这暗示其在训练中可能接触过使用示例。右图：在OpenWeather任务上，手工挑选的神谕单样本演示比零样本设置的成功率更高，显示了上下文演示的潜在影响。
表1：在房屋搜索任务上存在巨大的能力差距。开源LLM的成功率比OpenAI GPT-4落后70%。

3. 开源LLM面临的挑战

开源LLM的三大挑战。为了揭示关键挑战，我们研究了开源LLM在工具操纵中的行为。通过分析一个天气查询任务中的常见错误，我们发现了实现强大工具操纵能力的三个挑战。如表2所示，我们观察到开源LLM通常在（1）API选择、（2）API参数填充和（3）生成合法且可执行的代码方面遇到困难。这些见解在本节中详细描述，并启发了第4节中旨在缓解这些挑战的技术。

API选择困难。我们观察到API选择失败通常涉及使用错误的API，甚至幻化出不存在的API名称。为了量化地理解在API选择方面的内在能力，我们在推理时不提供任何文档或上下文演示，比较了开源LLM与GPT-4。结果如天气查询工具OpenWeather的图2所示，揭示了GPT-4可以在没有目标之外的额外信息的情况下选择正确的API，而开源模型则表现不佳。这种能力差异意味着闭源LLM可能在训练期间内化了API使用的知识。

参数填充混淆。在动作生成器选择了合适的API之后，接下来的挑战在于解析目标描述并填充API参数。在这个阶段，我们观察到开源模型经常为所需的API参数提供错误的值。参数填充的混淆导致了开源模型中高达63%的失败，如表3所示。为了缓解这个问题，我们为LLM提供了一个手工挑选的神谕上下文演示，该演示用不同的参数值实现了相同的目标。我们在图2中显示，手工挑选的神谕示例将成功率提高了多达45%。需要注意的是，神谕示例并非旨在作为参数填充混淆的解决方案，因为它们是按每个测试用例手工挑选的。尽管如此，这些观察表明上下文演示可以显著增强开源LLM的工具操纵能力。

非可执行生成。开源LLM的第三个常见失败是非可执行生成。这类失败包括围绕API调用的语言冗余和遵循基于自然语言的指导方针等问题，如表2所示。在一百个天气查询案例中，开源模型有时在23%的情况下表现出此类错误。这些观察强调了规范开源LLM专门生成代码的必要性。

表3：在一个天气查询工具上，按类别划分的典型工具操纵错误类型。
表3：在一个天气查询工具上，按类别划分的典型工具操纵错误类型。

A2 方法细节

第3节的洞察强调了在工具操纵领域中使用API使用示例进行微调、上下文演示和生成规范的重要性。本节中，我们重新审视了LLM文献中的三种技术，并对其进行调整以应对上述挑战，同时使用了实际可行的人工监督量。我们首先在第4.1节介绍通过程序化策划数据进行模型对齐，以内部化API使用知识。接着，在第4.2节讨论通过上下文演示检索器来增强开源LLM。最后，在第4.3节应用系统提示来规范生成。这些技术共同构成了一个强大的基线，用于缓解第3节中提出的挑战并启发进一步的创新。

4.1 通过程序化数据管理进行多工具模型对齐

通过示例微调进行模型对齐。模型对齐，通过使用示例对LLM进行微调，在提高LLM的指令遵循和对话能力等方面扮演着至关重要的角色【索引14, Training language models to follow instructions with human feedback, 2022, Advances in Neural Information Processing Systems】, 【索引19, Improving alignment of dialogue agents via targeted human judgements, 2022, arXiv preprint arXiv:2209.14375】, 【索引28, Scaling instruction-finetuned language models, 2022, arXiv preprint arXiv:2210.11416】。鉴于我们在第3节中的洞察，我们认识到使用API使用示例进行模型对齐以提高API选择能力的潜力。为了在工具操纵中实际利用这种对齐，需要一种无需大量手动编写示例的数据策划策略。为此，我们设计了一种从人工策划的模板生成使用示例的方法。

数据生成流程。图3描绘了我们生成对齐数据的流程。我们创建了少量由目标描述和相应API调用组成的模板。这些模板包含一个或多个占位符对。每个占位符对都映射到目标中的一个关键词和相应API调用中的一个参数。我们还为每个关键词提供一个候选值池，并随机选择值来填充模板中的占位符。对于一个拥有$n$个候选API的工具，我们仅需$O(n)$个人工策划的模板，以确保实际可行的人工监督。具体来说，我们遵循一个原则，即鼓励$n$个API中的每一个至少出现在一个模板中。在实践中，我们发现一个开发者平均花费一天时间来为我们基准测试中的一个软件工具策划数据；这包括编写目标模板、提供参数值池以及生成数据。我们在附录C中提供了用于不同工具的示例模板。在为所有工具策划好数据后，我们对所有工具联合进行模型对齐微调，并生成一个单一模型。

图3：使用模板和随机值进行程序化训练数据生成
图3：使用模板和随机值进行程序化训练数据生成

4.2 演示检索

上下文演示的挑战。在第3节中，我们展示了手工挑选的神谕示例在改善参数填充方面的有效性。然而，从神谕示例扩展到实用的上下文演示面临两个挑战。首先，给定$n$个API函数候选，与不同目标相关联的API调用组合数量是指数级的。因此，LLM应能够基于有限数量的示例泛化到各种目标。其次，为确保演示的有效性，重要的是在没有人工干预的情况下仅向LLM提供相关的示例。

演示检索器模块。为了满足以上两个要求，我们通过一个演示检索器模块来增强开源LLM。该模块围绕一个知识库，其中每个API只需出现在一个由人工策划的演示中。这意味着只需要$O(n)$个示例。在这些演示示例中，检索器会选择与目标描述语义最相似的示例。

有效性验证。为了验证演示示例在实践中的有效性，我们通过实验证明，检索到的演示可以提高对那些需要示例库中未曾见过的API组合的目标的成功率。具体来说，我们在房屋搜索任务上评估了这种方法，该任务暴露了15个API函数，并且每个目标需要多个函数来完成。仅使用了10个在API组合方面与100个测试用例中的任何一个都不完全匹配的人工策划的演示，检索到的演示就能将开源LLM的成功率提升高达79%，并使GPT-4近乎完美，如图4所示。这表明演示示例可以通过一个大小仅为$O(n)$的知识库来改善对未见类型目标的工具操纵能力。

图4：上下文演示可以改善闭源和开源模型在“房屋搜索”（一个用于浏览待售房屋的工具）上的表现。
图4：上下文演示可以改善闭源和开源模型在“房屋搜索”（一个用于浏览待售房屋的工具）上的表现。

4.3 使用系统提示进行生成规范

系统提示的应用。使用系统提示是LLM驱动的聊天机器人中的一项成熟技术【索引19, Improving alignment of dialogue agents via targeted human judgements, 2022, arXiv preprint arXiv:2209.14375】。通过融入人机对话，系统提示可以有效地控制生成回应的自然语言风格。在工具操纵的背景下，我们使用图5中的系统提示来规范开源LLM，使其仅生成API调用，其中黑色部分是所有任务共享的模板，红色行则在推理时针对特定目标进行实例化。

提示结构与功能。我们的系统提示首先定义了一个结合了包含目标、演示和生成的文本部分的格式。然后，它用自然语言提供明确的指导，指示LLM只生成代码。该系统提示为每个请求直接整合了目标描述和检索到的API函数，将人工开发工作减少为一次性任务。

图5：带有指导方针的系统提示，仅以期望的格式生成代码。红色部分在推理时为每个测试用例填充真实数据。
图5：带有指导方针的系统提示，仅以期望的格式生成代码。红色部分在推理时为每个测试用例填充真实数据。

A4 实验环境

5. ToolBench：一个新的工具操纵基准

为了在工具操纵领域评估开源LLM，我们从现有数据集和新收集的数据中策划了一个基准套件。与最近使用封闭LLM进行工具操纵研究的文献【索引2, api-bank: A benchmark for tool-augmented llms, 2023, arXiv preprint arXiv:2304.08244】, 【索引3, Tool learning with foundation models, 2023, arXiv preprint arXiv:2304.08354】相比，该基准是第一个提供预定义测试用例以进行量化评估的开源测试平台。本节将介绍软件工具和评估基础设施，并展示每个工具在泛化到未见API组合和需要高级推理能力方面的挑战水平。

5.1 软件工具和评估基础设施

ToolBench构成。如表4所示，我们的基准包括我们收集的五个任务和从现有数据集（包括VirtualHome【索引29, Virtualhome: Simulating household activities via programs, 2018】, 【索引30, Language models as zero-shot planners: Extracting actionable knowledge for embodied agents, 2022, International Conference on Machine Learning】, Webshop【索引31, Webshop: Towards scalable real-world web interaction with grounded language agents, 2023】和Tabletop【索引20, Code as policies: Language model programs for embodied control, 2022, arXiv preprint arXiv:2209.07753】）中派生的三个任务。它们涵盖了单步和多步动作生成，需要从2到108个API函数中选择和组合以完成目标。每个任务包含大约100个测试用例，包括目标描述和基准API调用。我们还提供有限数量的演示示例以辅助模型预测。我们在附录A中对基准中的每个任务进行了全面的介绍和分析。

评估指标与基础设施。对于大多数任务，我们使用成功率作为主要评估指标，除了WebShop（我们报告奖励）和VirtualHome（我们使用可执行性和最长公共子序列（LCS），遵循原作者提出的指标）。为便于评估，我们构建了一个基础设施，该设施可以执行动作生成器生成的API调用并评估最终结果。这一过程使得能够可靠地评估工具操纵能力，而不限制动作生成器必须与基准API调用完全匹配。

5.2 挑战级别

API复杂度与高级推理。为了评估挑战级别，我们根据API复杂度和对高级推理的要求来审视ToolBench任务。直观上，API复杂度表示泛化到未见API组合和非默认参数值的挑战。超出API复杂度的挑战则涉及高级推理。

API复杂度量化。为了量化泛化到未见API组合的挑战，我们开发了一个与任务无关的复杂度分数$S \in \mathbb{R}^+_0$，其中
$S(\mathcal{T}, \mathcal{X}, \mathcal{D}) = \mathbb{E}_{t \in \mathcal{T}} \min_{e \in \mathcal{X}} d(t, e).$
该分数对测试集$T$中所有测试样本$t$与示例池$X$中任何演示示例$e$之间的最小距离进行平均。具体来说，每个测试样本$t$和演示示例$e$之间的距离$d(t, e)$与将$e$的API组合转换为与$t$匹配的概率成反比，转换方式为随机丢弃与$t$无关的API函数，并从API池$D$中插入$t$所需的未覆盖API函数。复杂度分数的详细信息请参见附录D，其值列于表4。该分数为非负值，分数越高，任务越复杂。

高级推理挑战。尽管该复杂度分数反映了API选择的挑战级别，但它并未捕捉任务的所有困难。一个复杂度分数低的任务仍然可能非常具有挑战性，因为它可能需要高级推理。例如，尽管Webshop具有挑战性，但其API选择复杂度为零。这是因为Webshop中只有两个API函数，每个函数只需要一个参数，并且它们都被示例覆盖，因此没有API选择的复杂性。高级推理涵盖了泛化到未见API组合之外的挑战，例如Google Sheets和Tabletop任务中的非基于API的编码，以及基于从WebShop环境返回的观察进行决策。例如，在表5所示的Google Sheets示例中，牛肉价格单元格的坐标（"C2"）无法轻易地从目标或表格本身推断出来。动作生成器需要理解内容或编写额外的python代码来推导此坐标，然后才能调用API函数。在类似场景下，WebShop任务要求动作生成器根据描述提取网页上要点击的确切按钮ID。这些被归类为高级推理的挑战，补充了API复杂度类别。

表4：ToolBench中的任务。我们为少样本上下文学习提供演示示例，而测试用例用于量化评估。我们开发了API复杂度这一指标来量化泛化到未见API组合的挑战级别；复杂度越高表示任务越具挑战性。我们将API复杂度之外的挑战归类为高级推理。有关这些任务的更多详细信息，请参阅附录A。
表5：一个典型的Google Sheets操作任务。它既需要选择正确的API函数，也需要对参数进行推理。

6.1 实验设置

模型选择。为了建立强大的基线，我们使用GPT-4 API作为研究中的代表性封闭LLM，因为它在主流NLP任务中达到了领先的准确率。在我们的研究中，我们将LLAMA-30B【索引32, Llama: Open and efficient foundation language models, 2023, arXiv preprint arXiv:2302.13971】、StarCoder【索引33, Starcoder: may the source be with you!, 2023, arXiv preprint arXiv:2305.06161】和CodeGen-16B-mono【索引34, Codegen: An open large language model for code with multi-turn program synthesis, 2022, arXiv preprint arXiv:2203.13474】与GPT-4进行比较。LLAMA代表开放研究模型，而StarCoder和CodeGen可用于研究和商业目的。我们选择这三个模型是因为它们在ToolBench上的性能优于其他开源模型（如表9所示）。

实验配置。在我们的实验中，我们将零样本设置视为开箱即用配置，其中仅提供API文档，没有任何演示示例。我们使用此配置来了解模型之间的初始能力差距。然后，我们在此初始配置之上整合所有可用的技术，以评估它们的益处。对于原始的Tabletop数据集【索引20, Code as policies: Language model programs for embodied control, 2022, arXiv preprint arXiv:2209.07753】，其在少样本设置中包含示例但没有明确的API定义，我们只评估带有上下文演示的设置。

硬件/软件：实验在混合了GPU和SambaNova RDU【索引66, Spatial: A language and compiler for application accelerators, 2018, Proceedings of the 39th ACM SIGPLAN Conference on Programming Language Design and Implementation】, 【索引67, Plasticine: A reconfigurable architecture for parallel paterns, 2017, ACM SIGARCH Computer Architecture News】, 【索引68, Sambanova sn10 rdu: Accelerating software 2.0 with dataflow, 2021, 2021 IEEE Hot Chips 33 Symposium (HCS)】的环境中运行。具体来说，176B参数的bloomz在RDU上评估，而所有其他模型在配备80GB RAM的NVIDIA A100 GPU上评估。模型微调在包含4个A100 GPU的内部集群上进行。

可复现性：我们每个任务运行3次，使用不同的随机种子，并报告平均准确率。由于变异很小，我们在主论文中忽略了它，但在附录中报告了。

A4 实验结果

6.2 能力差距

零样本设置下的巨大差距。表6展示了在开箱即用的零样本设置中，封闭的GPT-4 API与开源模型在工具操纵方面存在显著差异。对于较简单的任务，即Open Weather和The Cat API，它们每个目标只需要一个API调用，开源模型的成功率比GPT-4低了高达74%。此外，在除了Webshop之外的所有其余任务上，LLAMA、StarCoder和CodeGen模型都无法达到有意义的准确率或与GPT-4相提并论。这些结果凸显了增强开源LLM的机会。

6.3 提升开源LLM

增强后的显著提升。为了提升开源LLM，我们首先使用程序化生成的数据进行模型对齐。然后在推理过程中应用系统提示和3-shot演示检索器。由于GPT-4不提供微调API，我们使用与基线相同的系统提示和演示检索器来增强开箱即用的GPT-4。组合增强技术带来的改进如表6所示，开源LLM的成功率可以提高高达90%。

与GPT-4的竞争力。结果显示，在8个任务中的4个任务上，包括Open Weather、The Cat API、VirtualHome和WebShop，开源模型取得了有竞争力或更好的成功率。此外，在Home Search和Trip Booking任务上，LLAMA模型与GPT-4 API之间的差距分别缩小到11%和13.4%，而初始差距高达91%。尽管开源模型在Google Sheets和Tabletop上仍然落后，但这些观察表明我们的方案可以显著提高开源LLM的性能，并在ToolBench的许多任务上达到与GPT-4 API相当的成功率。

人力监督成本。在我们的方法中，人力监督主要以上下文演示示例和对齐数据模板的形式存在。如表4所示，除了WebShop任务因其高级推理的难度外，我们为每个任务提供了10到83个演示示例。如表10所示，用于对齐数据的模板数量通常每个任务少于100个。我们观察到，提供这些监督平均需要一个开发者一天的时间，这使得它在人力监督的时间成本方面是实际可行的。

剩余的挑战。实验中，我们观察到增强后的开源LLM在需要高级推理的任务上，如Google Sheets、WebShop和Tabletop任务，成功率仍然相对较低。这表明需要进一步增强开源模型的推理能力。

表6：在开箱即用的零样本设置中，闭源API和开源LLM在工具操纵方面的能力差距是巨大的。通过使用模型对齐、上下文演示检索器和系统提示，开源LLM的成功率得到了显著提升。GPT-4通过检索器和系统提示得到了增强。Tabletop仅在少样本方式下进行评估。
表6：在开箱即用的零样本设置中，闭源API和开源LLM在工具操纵方面的能力差距是巨大的。通过使用模型对齐、上下文演示检索器和系统提示，开源LLM的成功率得到了显著提升。GPT-4通过检索器和系统提示得到了增强。Tabletop仅在少样本方式下进行评估。

6.4 消融研究

各项技术的贡献分析。我们通过两种方式分解各项技术的贡献。首先，我们在开箱即用的零样本配置之上单独应用每种技术并评估其影响。如表7所示，3-shot上下文演示和模型对齐技术都提高了所有任务的成功率，而系统提示仅对涉及较少API调用的简单任务有益。

在完整系统中的相对贡献。其次，我们考虑所有技术的组合，并一次移除其中一种来评估它们在完整系统中的相对贡献。如表7所示，仅移除模型对齐会导致多达7个任务的成功率下降，而移除上下文演示最多影响5个任务，移除系统提示最多影响3个任务。我们注意到，在移除技术时未受显著影响的任务通常是那些成功率相对较低的任务（即使在完整系统中通常也<20%）。因此，这些准确率的变化可能受到高方差和波动的影响。本节实验的完整结果见表12。

表7：当添加或移除技术时，相较于基线，ToolBench任务得到改进（+N）或受损（-N）的数量。
表7：当添加或移除技术时，相较于基线，ToolBench任务得到改进（+N）或受损（-N）的数量。

A5 结论

核心问题回答。本文回答了我们是否能够通过实际可行的人工监督量，增强开源LLMs以与领先的封闭LLM API在工具操纵方面竞争的问题。

方法与洞察。借鉴我们对常见工具操纵失败的观察以及LLM在传统NLP任务上的文献洞见，我们提出实例化模型对齐与程序化数据生成、系统提示以及上下文演示检索器，以提高开源模型的工具操纵能力。

评估与成果。为了全面评估这些技术的影响，我们创建了ToolBench，一个由多样化的真实世界任务软件工具组成的基准。我们的结果表明，这些技术可以使领先的开源LLMs在ToolBench的8个任务中的4个上与OpenAI GPT-4相媲美，所有这些都是通过实际可行的人工标注努力实现的。

A6 附录

A 基准详情

A.1 OpenWeather

任务描述。该任务涉及使用REST API与OpenWeather网站进行交互。我们包含了9种类型的API调用，以满足9类查询，包括但不限于检索城市的当前天气数据、获取特定经纬度的空气质量数据以及获取邮政编码指定位置的天气预报数据。每种API调用都需要正确填写2到3个必需参数（如lon表示经度，lat表示纬度）和0到3个可选参数（如lang表示语言，units表示度量单位），具体取决于每个查询的要求。我们总共为这9个类别开发了100个独特的查询，并为每个类别提供了2个演示示例。

评估方法。为了评估LLM生成的质量，我们寻找以单词"curl"开头的第一行（如果存在）。然后我们使用shell进程执行该行。如果shell进程返回非零值，我们宣布此生成为“不可执行”。另一方面，如果代码可以执行，我们将返回的响应与来自基准Curl请求的相应结果进行比较。如果输出与预期结果完全匹配，则认为模型的生成是成功的。

A.2 The Cat API

任务描述。该任务与OpenWeather类似，是一个REST API任务，但它涉及对The Cat API网站进行GET、DELETE或POST请求。共有6种类型的API调用对应6种查询，包括从用户的收藏列表中删除一张猫的图片、将图片添加到用户的收藏列表、返回收藏图片列表、对图片进行投票（赞成或反对）以及根据筛选要求搜索猫的图片。我们开发了100个查询用于测试集，并为每个类别提供了2个演示示例。

评估方法。为了评估LLM在这些场景中生成的可执行性和成功率，我们遵循与Open Weather任务相似的程序。值得注意的是，对于与从收藏列表中移除图片相关的查询，我们将LLM的生成与基准标签进行逐字比较，因为如果执行，重复的删除将不可避免地导致失败。

A.3 Home Search

任务描述。此任务旨在模拟根据特定标准在特定位置搜索房屋的过程。我们设计了包含15个函数的API，包括：
* set_location：设置期望的位置；
* set_but_or_rent：指明用户是想买房还是租房；
* 12个用于设置标准的函数，如房价、卧室数量和房屋面积；
* search：提交标准以获取搜索结果。

评估方法。我们考虑生成动作的可执行性和f1分数。为确保可执行的搜索，代理应进行一系列函数调用，以set_location和set_buy_or_rent开始，接着是设置标准的函数，最后以调用search函数结束。如果可执行，则在生成的程序设置的标准与基准程序设置的标准之间计算f1分数。我们开发了一个包含100个查询的测试集，这些查询要求不同标准组合的房屋选项，并提供了10个演示示例。为了测试LLM利用未见API函数的能力，我们有意地从所有演示示例中排除了3个标准设置函数。

A.4 Trip Booking

任务描述。旅行预订任务与房屋搜索任务相似，但函数调用之间有更高级的依赖要求。它模拟了根据具体要求（如地点、日期和所需票数）提交交通票、酒店房间或两者兼有的搜索请求的过程。我们为这三种预订场景设计了20个函数。根据场景的不同，某些函数调用可能是必需的，而其他则是可选的。缺少任何必需的函数调用或弄错某些函数调用的顺序会导致搜索不可执行，而缺少可选的函数调用会导致搜索不成功。我们在测试集中包含了120个查询，并提供了11个演示示例。

A.5 Google Sheets

任务描述。此任务是通过gspread库操作Google Sheets中的真实工作表。我们包含了gspread库中100个不同的API函数调用，但我们只为最常见的用例创建了测试，包括更新单元格值、排序、添加或删除行和列、合并单元格、筛选、格式化和创建数据透视表。总共有70个测试用例和10个示例。我们还通过明确提供8个额外的API函数和相应的示例来鼓励模型利用Pandas DataFrame和gspread-dataframe进行高级操作。

评估方法。只有当每个单元格的值和格式都与预期匹配时，操作才被认为是正确的。

A.6 Virtual Home

任务描述。此任务继承自VirtualHome模拟器的设置，要求LLM生成完成家庭活动的一系列动作。我们基于【索引30, Language models as zero-shot planners: Extracting actionable knowledge for embodied agents, 2022, International Conference on Machine Learning】中整理的可用示例列表，开发了API定义、演示示例和测试集。API包含40个函数，每个函数对应于示例中使用的特定动作。这些函数最多可以接受两个参数，我们根据所有示例收集了每个参数的有效对象名称列表。函数的例子包括Sleep()、Push(object)和PourInto(object1, object2)。

数据构建。原始示例列表包含202个家庭活动，由5088个示例表示，每个示例是完成特定活动的一系列动作。然而，某些活动的解决方案与另一活动完全相同。去重后，我们剩下183个独特的活动，任意两个活动之间的解决方案没有重叠。我们随机选择100个活动构成测试集，其余83个任务及其512个解决方案用作演示示例。

评估方法。在评估LLM对给定任务的生成时，我们同时考虑可执行性和正确性。如果生成可以被正确解析为一系列有效的动作，且每个动作仅涉及可识别的对象，则认为生成是可执行的。关于正确性，我们使用最长公共子序列（LCS）【索引29, Virtualhome: Simulating household activities via programs, 2018】（由两者最大长度归一化）来衡量生成的程序与基准解决方案之间的相似度。对于有多个解决方案的任务，我们考虑任何解决方案中最高的LCS分数。

A.7 WebShop

任务描述。这是一个继承自Webshop【索引31, Webshop: Towards scalable real-world web interaction with grounded language agents, 2023】的多步任务，一个模拟的在线购物环境。该任务要求代理在一系列网页中导航，根据概述物品描述的文本指令找到并购买所需产品。代理可以执行两种主要类型的动作：search[text]，涉及输入文本查询；和click[button]，涉及选择页面上的一个按钮。

数据构建。我们根据一个包含人类执行在线购物任务轨迹的文件生成演示示例。我们将每个轨迹格式化为纯文本格式的（指令，网页描述，动作）元组序列。演示集的长版本包含1533个完整轨迹，这通常超过LLM的输入序列长度限制。为了解决这个问题，我们提供了一个短版本的演示示例，首先从任何网页描述中移除80%的非目标项目，然后从完整集中仅选择200个最短的轨迹。

评估方法。对于评估，我们使用WebShop环境预定义的简单模式，并设置环境仅使用1000个随机产品。测试集中包含了ID号为0到99的会话中的100条指令。我们将成功定义为在25步内进行一次购买并从环境中获得正奖励。

A.8 Tabletop

任务描述。此任务基于【索引50, Code as policies: Language model programs for embodied control, 2023】中提出并在其附录K中概述的模拟桌面操纵域开发。在此模拟环境中，一个带有Robotiq 2F85爪形夹持器的UR5e机器人可以执行由2D俯视位置参数化的拾取和放置动作。我们重用他们的API定义和提示作为演示示例。我们对他们评估基准中使用的14个指令模板进行迭代，并创建了15种类型的任务，涉及操纵多达4个彩色方块和4个彩色碗。对于每种类型的任务，我们为测试集生成7个有效的方块和碗的初始设置，确保在执行有效解决方案期间不会发生碰撞。

评估方法。LLM生成的程序的成功与否取决于执行后所有对象是否在其目标位置的一个小阈值范围内。

B ToolBench上的全面模型评估

B.1 模型

模型选择。如表8所列，我们从闭源和开源社区选择了一组代表性的LLM。闭源模型主要是OpenAI的GPT系列。开源模型包括基于Transformers架构的解码器专用模型，如Bloomz【索引52, Crosslingual generalization through multitask finetuning, 2022, arXiv preprint arXiv:2211.01786】、StarCoder【索引33, Starcoder: may the source be with you!, 2023, arXiv preprint arXiv:2305.06161】、LLaMA【索引32, Llama: Open and efficient foundation language models, 2023, arXiv preprint arXiv:2302.13971】、Alpaca【索引54, chavinlo/gpt4-x-alpaca, 2023, https://huggingface.co/chavinlo/gpt4-x-alpaca 】, 【索引55, Stanford alpaca: An instruction-following llama model, 2023, https://github.com/tatsu-lab/stanford_alpaca】、OPT-IML【索 引56, Opt-iml: Scaling language model instruction meta learning through the lens of generalization, 2022, arXiv preprint arXiv:2212.12017】、CodeGen【索引34, Codegen: An open large language model for code with multi-turn program synthesis, 2022, arXiv preprint arXiv:2203.13474】、Pythia【索引62, Pythia: A suite for analyzing large language models across training and scaling, 2023, arXiv preprint arXiv:2304.01373】、Dolly【索引63, dolly-v2-12b, 2023, https://huggingface.co/databricks/dolly-v2-12b】和StableLM【索 引64, Stablelm, 2023, https://github.com/Stability-AI/StableLM】等家族 。

表8：我们评估中所有模型的架构和训练数据。模型按其架构和训练数据分组。
表8：我们评估中所有模型的架构和训练数据。模型按其架构和训练数据分组。
B.2 评估

评估方法。为了收集基线结果，我们利用第2节中描述的朴素方法作为动作生成器。我们为每个LLM在每个任务上提供足够的最大token数以生成，并在提示中检索尽可能多的API函数。详细信息列于表9。我们评估所有模型的3-shot场景性能。对于面向对话的模型，我们还在提示中添加了<human>:和<bot>:关键词以更好地对齐其训练数据格式。

后处理与执行。在从LLM获得续写后，我们应用了最少的后处理步骤：1) 根据任务特定的停止序列列表适当地截断续写，2) 将续写中的{API_KEY}关键词替换为真实的API密钥，以便正确执行代码。最后，对于单步任务，我们执行生成的API调用并将其输出与基准进行比较；对于多步任务，动作直接用于与环境交互，只评估最终状态。我们仅评估禁用采样生成的top-1动作。

B.3 不同模型在ToolBench上的性能

主要观察。不同模型的性能总结在表9中。我们有几个观察：
* 能力差距：目前，GPT系列模型是该领域的领先者，GPT-4、GPT-3.5与所有其他开源模型之间存在显著差距。
* 传统NLP指令微调无效：对常规NLP任务进行指令微调的模型（如Alpaca vs LLaMA）在ToolBench上没有显示出显著的准确率提升。
* 模型规模很重要：在同一模型家族内，更大的模型在ToolBench上倾向于表现更好。
* 代码生成训练很重要：StarCoder和CodeGen家族在ToolBench上表现突出，优于其他类似规模的模型，表明针对代码生成进行微调非常有益。

表9：不同模型在3-shot场景下在ToolBench上的性能。模型按其架构和训练数据分组。
表9：不同模型在3-shot场景下在ToolBench上的性能。模型按其架构和训练数据分组。

C 实验细节

C.1 训练数据

数据生成。对于OpenWeather、The Cat API、Trip Booking和Home Search任务，我们通过将每个任务的演示示例转换或扩展为模板，并用各种变量值集填充它们来生成训练数据。对于其余四个任务，我们直接从第5节中描述的演示示例集格式化训练样本。我们从训练数据中排除了任何测试样本，并最小化了任何训练和测试样本之间API函数调用组合的重叠。

数据统计。每个任务的模板和训练样本数量总结在表10中。不同工具的示例模板和变量值显示在表11中。

表10：模型对齐数据的统计信息
表11：不同工具的训练模板示例

C.2 全样本损失 (All-shot loss)

损失函数。为了构建训练样本，我们将API文档和多个目标与API调用的配对连接成一个输入序列给LLM。我们使用图6所示的“全样本损失”公式，该公式学习为序列中的每个目标生成API调用。我们使用此损失公式是因为它在经验上提供了更好的成功率，特别是在使用上下文演示时，优于仅反向传播与最后一个目标的API调用相关的损失的传统损失函数。

图6：正常损失与全样本损失的比较。全样本损失计算序列中所有API调用的损失。
图6：正常损失与全样本损失的比较。全样本损失计算序列中所有API调用的损失。
C.3 训练细节

超参数。我们使用第C.1节中描述的方法创建的相同数据集对每个模型进行8个周期的微调。我们使用2048的最大序列长度，不进行打包，并将所有任务的数据混合到一个数据集中并随机打乱。在每个样本中，所有的目标-动作对都来自同一个任务。我们报告了最佳检查点上的验证准确率。我们对每个模型使用16的批量大小和1e-5的恒定学习率，并在一个由4个A100 GPU组成的内部集群上进行训练，每个GPU有80GB内存。

C.4 第6节的扩展结果

详细结果表。我们在表12中列出了第6节的详细结果，其中我们报告了模型在所提出的三种技术的所有可能组合下的性能。主要观察结果已在第6节中涵盖。我们每个任务运行3次，并报告主要指标的均值和标准差。尽管存在一些不可避免的随机性，但我们观察到它们几乎不改变最终结果。

表12：应用不同技术的模型在ToolBench上的详细性能。为每个任务提供了均值（标准差）值。存在一些不可避免的随机性，但它不会对结果产生太大影响。
表12：应用不同技术的模型在ToolBench上的详细性能。为每个任务提供了均值（标准差）值。存在一些不可避免的随机性，但它不会对结果产生太大影响。

D API选择复杂度分数

D.1 复杂度分数

分数系统。本节介绍了一个旨在衡量ToolBench任务内在复杂性和难度的复杂度分数系统。该系统通过计算在所有可能结果等概率的随机系统中，从示例派生或转换出测试的概率，来提供对测试内在复杂性的量化度量。

从示例派生测试的可能性。给定一个演示示例$e$和一组API函数$D$，派生特定测试样本$t$涉及两个主要步骤：1) 移除所有未使用的API调用，同时保留所有必要的API调用；2) 插入$e$未涵盖的新API调用。假设在一个随机系统中，从$e$中删除每个API调用的可能性为50%，而插入正确API调用的可能性为$1/|D|$。基于这些假设，生成测试样本$t$的可能性使用公式(1)计算。
$p(t \mid e, \mathcal{D}) = \left(\frac{1}{2}\right)^{|e|} \left(\frac{1}{|\mathcal{D}|}\right)^{|t \setminus e|}$
其中$|e|$表示示例$e$中的API调用数，而$|t \setminus e|$是测试样本中未覆盖的API调用数。

测试与示例对之间的距离。我们通过取公式(1)倒数的对数来定义一个特定测试和示例对之间的距离$d$：

$$d(t, e) = \log \left[ \frac{1}{p(t \mid e, \mathcal{D})} \right]$$

任务的复杂度分数。基于从一个示例生成一个测试的复杂度分数，我们可以构建给定任务的复杂度分数$S$。分数$S = f(T, X, D)$是测试样本$T$、演示示例$X$和每个任务的API函数$D$的函数。

$$\begin{aligned} S(\mathcal{T}, \mathcal{X}, \mathcal{D}) = \mathbb{E}_{t \in \mathcal{T}} \min_{e \in \mathcal{X}} d(t, e) \\ = \mathbb{E}_{t \in \mathcal{T}} \min_{e \in \mathcal{X}} \log \left[ \frac{1}{p(t \mid e, \mathcal{D})} \right] \\ = -\mathbb{E}_{t \in \mathcal{T}} \max_{e \in \mathcal{X}} \log \left[ \left( \frac{1}{2} \right)^{|e|} \left( \frac{1}{|\mathcal{D}|} \right)^{|t \setminus e|} \right] \end{aligned}$$


该分数范围从零到无穷大。分数越大，任务在API选择方面就越具挑战性。

D.2 ToolBench上的复杂度分数

计算细节。对于单步、单API调用的任务（Open Weather和The Cat API），每个带参数的有效URL被视为集合$D$中一个独特的API选项。对于WebShop任务，由于只有两个API函数且总是被示例集覆盖，复杂度分数根据定义为0。

反向F1分数。为了比较，我们还考虑了简单的反向F1（r-F1）距离$d_{r-F1}$，它源自传统的F1分数，定义如下：
$d_{r-F1}(t, e) = (1 - F1(t, e)) * 100$
一个任务的r-F1分数$S_{r-F1}$定义如下：

$$S_{r-F1}(\mathcal{T}, \mathcal{X}) = \mathbb{E}_{t \in \mathcal{T}} \min_{e \in \mathcal{X}} d_{r-F1}(t,e)$$

$$= \mathbb{E}_{t \in \mathcal{T}} \min_{e \in \mathcal{X}} [(1 - F1(t,e)) * 100]$$

测量。我们使用斯皮尔曼相关系数（SCC）来评估所提出的复杂度分数的有效性，分析了五个不涉及高级推理的任务。结果如图7和表13所示。研究结果显示，对于LLaMA-30b、CodeGen-16b和StarCoder模型，复杂度分数与错误率之间存在近乎完美的斯皮尔曼相关系数。这种强相关性表明，所提出的复杂度分数系统准确地捕捉了这些任务的内在难度。对于像GPT4这样更强大的模型，由于其在低复杂度任务上表现近乎完美，SCC对实验中的随机性较为敏感。尽管如此，复杂度分数仍然是比r-F1分数更好的任务难度指标。

图7：斯皮尔曼相关系数(SCC)分别计算了两个比较：（1）复杂度分数与错误率，（2）反向F1分数与错误率，涵盖五个任务。
表13：斯皮尔曼相关系数