Octopus：用于软件API函数调用的设备端语言模型

Octopus: On-device language model for function calling of software APIs

摘要
在快速发展的人工智能领域，大语言模型（LLMs）因其强大的文本处理与生成能力而发挥着关键作用。本研究提出了一种新策略，旨在利用设备端部署的大语言模型来调用软件API。我们从软件API文档中精心构建了一个数据集，并对参数规模分别为20亿（2B）、30亿（3B）和70亿（7B）的LLM进行微调，以显著提升其在软件API交互方面的性能。我们的方法聚焦于增强模型对API结构和语法的理解，从而大幅提高API函数调用的准确性。此外，我们提出了条件掩码技术，以确保输出符合预期格式，降低错误率，同时保持推理速度。我们还设计了一个全新的基准测试，用于评估LLM在API交互中的有效性，为后续研究奠定基础。经过微调得到的模型Octopus，在软件API调用任务上的表现优于GPT-4。本研究致力于推动自动化软件开发与API集成的发展，标志着LLM能力与实际软件工程需求之间对齐的重要进展。

1 引言
大语言模型（LLMs）的出现彻底改变了人工智能领域，在自然语言处理方面展现出广泛的能力，并已应用于数学（Imani等，2023；He-Yueya等，2023）、医疗健康（Imani等，2023；Jo等，2023；Thirunavukarasu等，2023）以及法律分析（Cui等，2023；Fei等，2023；Luppi等，2022）等专业领域。尽管取得了这些进展，LLMs在吸收实时更新信息和执行特定任务（如图像/视频编辑（Fu等，2023）或复杂的税务申报）方面仍面临挑战。将大语言模型（LLMs）与外部API集成成为一项关键的改进措施。这种结合通过API使LLMs能够访问最新信息和专用功能，不仅增强了其能力，还催生了诸如代码解释器（Bairi等，2023；Vaithilingam等，2022；Chen等，2021）等新型应用。ToolAlpaca（Tang等，2023）和NexusRaven（Srinivasan等，2023）等研究也证明了开源语言模型具备函数调用能力。因此，这一集成代表了克服LLMs固有局限性的关键一步，从而拓展了其在实际应用中的效用和创新潜力。

进一步提升大语言模型（LLMs）与外部API的集成效果，需要解决大规模模型依赖性与效率、成本之间的平衡问题。对于仅使用少量API的特定任务而言，依赖GPT-4（Radford等，2018；2019；Brown等，2020；Achiam等，2023；Wu等，2023）这类大型模型是低效的，因为它们需要大量计算资源。这种情况促使人们开发更小、面向特定任务的LLMs，在保留核心功能的同时降低运行成本（Shen等，2024b；Pallagani等，2024）。然而，向小型模型的转变也带来了新的挑战，包括“幻觉”（hallucinations）风险增加（Yao等，2023；Zhang等，2023；Ji等，2023），导致输出格式不准确（Jiang等，2023），而正确的输出格式对于稳健的软件应用至关重要。

针对大型LLMs存在的推理开销过大以及训练数据缺乏聚焦的问题，我们提出了一种新的LLM训练与推理框架。该框架基于从Rapid API Hub（rap，2024）收集的超过3万个广泛使用的API构成的大规模数据集，涵盖从谷歌搜索到亚马逊商品查询等多种功能。通过采用课程学习（curriculum learning）策略（Liu等，2024），我们显著提升了LLMs在多个相似选项中准确选择合适API函数的能力。这种战略性数据工程，结合我们选用的基础模型——包括Codellama7b（Roziere等，2023；Touvron等，2023）、谷歌的Gemma 7B与2B（Gemma团队，Google DeepMind，2023）、Stable Code 3B（Pinnaparaju等，2023）——充分验证了我们方法的有效性，性能超越GPT-4的基准表现。同时，由于这些模型已可在移动设备上部署（team，2023），我们的方案也确保了在各类平台（包括移动端）上的实用性。

为了保证模型输出格式的一致性，我们在推理阶段引入了条件掩码（conditional masking）技术。这一创新方法确保LLM生成符合预期格式的输出，在不牺牲推理速度的前提下显著提升准确率并降低验证损失。我们还从数学上证明了条件掩码技术能够有效提升输出准确性。

这一进步在我们选定的多个基础模型上均得到验证，不仅展示了紧凑型LLM在外部API集成中的巨大潜力，也为可扩展的人工智能应用设立了新的效率标杆。通过对模型选择与训练过程的详细阐述，我们提供了一个整体性解决方案，有效应对当前LLM在API调用中的主要挑战。用于LLM训练的数据集以及微调后的模型将很快开源发布。

2 相关工作

利用工具增强大语言模型（LLMs）
将外部计算工具集成到大语言模型（LLMs）中，如GPT-4、Alpaca和Llama，标志着其能力提升的重要进展。早期的集成工作主要集中在针对特定模型的微调方法上（Lin等，2024；Hu等，2023），这些方法虽然有效，但在广泛应用和灵活性方面遇到了挑战。一个显著的转变出现在采用包含示例演示的提示（prompt）技术之后，这一方法大大扩展了工具的可访问性。所涉及的工具范围包括专用的代码解释器和广泛的检索框架，显著增强了模型解释和执行复杂指令的能力（Zhou等，2023）。此外，也观察到在工具交互的模拟环境（Shen等，2024a；Du等，2024；Xi等，2023）以及API交互框架（Li等，2023）方面的进展。同时，引入先进的推理（reasoning）策略（Valmeekam等，2022；Hao等，2023；Lewkowycz等，2022）也显著提高了模型理解和解决复杂任务的效率。

数据集格式
为提升大语言模型（LLMs）性能，对用于模型微调的数据集进行优化至关重要（Zhuang等，2024；Kong等，2023）。该过程通常采用多阶段精炼方法，利用GPT-4、Alpaca等模型进行迭代优化。通过不断改进数据集，这种方法不仅优化了输入提示（prompts），还提升了响应质量，并发展出更高级的思维链（Chain-of-Thought）（Wang等，2023；Zhang等，2022；Shridhar等，2023；Zheng等，2023a；Wei等，2022）机制。此类进展显著提高了LLMs在函数调用方面的准确性，为数据集优化和模型训练设立了新的基准。这种迭代式数据精炼代表了一种战略性转变，旨在提升LLM输出的精确度与质量。

大语言模型生成的鲁棒性
与文章生成不同，文章生成可以容忍较为灵活的输出格式，而软件应用则要求严格遵守特定的输出结构，例如Zheng等（2023b）中提到的JSON格式。目前在LLM生成过程中已观察到大量格式不一致的问题（Vaswani等，1987；Ackerman & Cybenko，2023）。为此，已有研究致力于强制执行严格的输出格式，以确保LLM生成内容的一致性和可靠性。例如，在LangChain框架中（Harrison，2022），提供了多种输出解析器（output parsers），用于强制输出为YAML、JSON、CSV等格式。然而，仍有许多情况无法通过输出解析器解决，尤其是函数调用的响应格式问题。

3 方法论

在本节中，我们详细阐述了数据集的收集与准备方法，并介绍了为实现高效训练而设计的数据格式化流程。随后，我们描述了所开发模型 Octopus 的构建过程，重点说明了所采用的训练技术与推理策略。我们模型的一个关键创新在于使用**条件掩码（conditional mask）**来增强推理效果，这是一种提升模型性能的新颖方法。该方法论将全面的数据准备与先进的建模技术相结合，旨在应对函数调用模型在训练与推理过程中面临的挑战。

3.1 数据集收集与精炼

我们的初始数据集来源于 RapidAPI Hub 的 API 文档，这是全球最大的 API 仓库之一。选择该来源是基于其官网声称拥有数百万开发者的使用基础。为了帮助大语言模型更好地理解 API 的使用模式，我们系统性地收集了约 30,000 个最常被使用的 API 的文档，构建了一个全面的数据集。数据集的获取分为两个主要阶段：首先是单个 API 文档的初步收集与处理，然后是针对训练目的的细致精炼过程。

单个 API 数据预处理

通过对文档的深入分析，我们全面了解了 RapidAPI Hub 中 API 使用示例的结构与使用方式。该方法包括仔细提取 API 使用示例，这些示例包含 API 的名称、描述、参数名称及其各自的说明，并将这些信息格式化为 JSON。随后，我们使用 OPENAI 的 GPT-3.5 和 CodeLlama 70B 模型对这些数据进行重新组织，使其符合我们期望的结构化标准。

接着，我们根据函数描述对函数名称进行优化，确保其简洁且具有信息性。随后，提取并整理各个参数的名称和描述。为了应对小型大语言模型可能存在的不准确问题（即“幻觉”现象），我们采用 Python 编程格式来表示 API 函数。这一决策具有战略意义，充分利用了 CodeLlama7b 和 StableCode3B 等模型在大规模代码数据集上训练所获得的代码推理能力。

这一流程不仅使 API 信息更加清晰、易于使用，还借助先进的 AI 模型确保信息以结构化、可访问的方式呈现。通过以函数描述为指导进行命名优化，并详细说明参数名称与描述，该方法有效传达了 API 使用的核心要素，帮助开发者更顺畅地将这些 API 集成到自己的项目中。以下是一个转换后的函数示例：

在我们的方法论中，最终数据集的构建明确排除了函数体。通过细致的筛选过程，我们汇总了约 20,000 个 API，并使用 OPENAI GPT-4 对其进行全面审查，剔除存在缺陷的 API，例如缺少参数、或函数描述与其参数之间存在不一致的情况。这一严格的筛选标准对于确保数据集质量至关重要。每个 API 都经过了这一严谨的审查流程，最终形成了数据集 A。该数据集 A 将作为后续数据处理的基础。

数据集精炼

为了提升大语言模型（LLMs）在真实场景中调用 API 的决策能力，我们提出了一种复杂的数据集构建方法，这是本研究的关键所在。我们首先将多个函数进行整合，并有意引入一些不相关的函数，以构建一个对大语言模型而言更具挑战性的复杂环境。受课程学习（curriculum learning）的启发，我们设计数据集时逐步引入困难的负样本（hard negative samples），即加入语义上相似的函数，逐步提高模型选择最相关函数的难度。我们的方法如图（1）所示，详细展示了数据集的构建流程。以下是我们所采用的具体技术：

  1. 负样本（Negative samples）为了增强模型的推理能力与实际应用能力，我们的方法同时采样正样本和负样本。这些样本的比例在图（1）中用变量 M/N 表示，是实验设置中的一个重要参数。具体而言，在我们的框架中，我们将 M 和 N 设为相等，即均设为 1。

  2. 相似函数聚类（Similar functions cluster）在实际实现中，模型需要从大量函数中根据用户查询选择合适的函数。为了增加训练难度，我们刻意使选择过程更加复杂。具体做法是：在构建训练数据时，将某一个目标函数与另外三个语义上相似的函数组合在一起。该过程通过计算函数描述的向量嵌入（vector embeddings）完成，并借助 Milvus 工具进行相似性搜索。我们选取相似度排名在第 5 至第 10 位的三个函数作为相似样本，刻意避开最相似的前几个函数，以避免过于重复，从而确保每个查询的挑战性。这种方法构建了一个更具挑战性的训练环境，培养出能够在实际应用中区分高度相似函数的模型。

  3. GPT-4 生成查询（GPT-4 generated query）高质量数据集的构建在很大程度上依赖于优质查询的生成。在此背景下，我们选择生成仅能由单个 API 解决的正向查询。此外，对于这些正样本，我们还生成并加入了思维链（Chain of Thought, CoT），用于模型训练。近期研究表明，引入思维链不仅能显著提升模型性能，还能有效增强其推理能力（Srinivasan 等，2023）。值得注意的是，高质量查询及其辅助信息的构建，对于开发有效的训练数据集至关重要。

  4. GPT-4 验证（GPT-4 verification）在数据集构建过程中，我们观察到：尽管 GPT-4 能力强大，但其生成的内容仍可能存在错误。因此，我们设计了一个工作流程，让 GPT-4 对其自身输出进行自我验证，从而有效识别并修正其中的不准确内容。在获得数据集 B 后，我们再次使用 GPT-4 对其进行细致的验证，并剔除所有不符合我们严格质量标准的数据点。这一严格的验证过程共剔除了约 1000 个数据点，显著提升了最终模型的性能。

遵循上述方法论，我们成功构建了一个精细的训练数据集，总计包含约 150,000 个数据点。每个独立的 API 均关联了 5 个它能够正确解决的正向查询。为便于全面理解，我们在附录（B.1）中提供了完整数据集的一个样本，展示了训练数据的详细结构与组成。

3.2 Octopus

为了验证我们框架的有效性，我们在四个著名的开源模型上进行了微调：CodeLlama-7B、Google Gemma 2B 与 7B，以及 Stable Code LM 3B。所有模型均采用统一的标准化训练模板，该模板详见附录（B.1）。我们使用了 LoRA（低秩适应） 和 8-bit 量化 技术进行高效训练，并分配如下 A100 80GB GPU 计算时长：

  • CodeLlama-7B 和 Google Gemma 7B：各 90 小时

  • Google Gemma 2B：30 小时

  • Stable Code LM 3B：60 小时

学习率设置为 5×10⁻⁵，并采用线性学习率调度器以优化训练效果。在推理阶段，用户查询会触发函数检索与执行过程，模型生成的函数名及其参数将被映射到对应的 API 上，从而生成最终响应。因此，只要模型能正确生成函数名和参数名，即可确保结果的准确性。

我们尝试了多种 LoRA 配置，最终发现最佳设置为：LoRA 秩（rank）设为 16，并将 LoRA 应用于以下模块的权重：“q_proj”（查询投影）、“v_proj”（值投影）、“o_proj”（输出投影）、“up_proj” 和 “down_proj”。我们还在图（2）中展示了所选模型的训练损失与验证损失曲线。在训练过程中，我们逐步引入包含更多相似函数示例的数据点，实现了课程学习（curriculum learning）策略，使模型由易到难地学习函数选择任务。

3.3 使用条件掩码进行推理

使用参数量较小的大语言模型（LLMs）面临一个关键挑战：在生成输出时鲁棒性明显下降。这一问题在我们的模型中同样存在，尤其体现在必须生成精确的函数名及其对应参数的要求上。预期的输出格式要求如下：

  • 参数必须包含在括号内；

  • 函数名必须与预定义的函数库完全一致；

  • 参数值必须符合其指定的数据类型。

任何偏差——例如函数名拼写错误，或参数类型不匹配——都会严重破坏输出的完整性，导致调用失败。例如，在 GPT-4 和我们的模型中，若函数名出现拼写错误或表达冗长（如添加额外描述），可能导致生成的名称无法正确映射回原始函数名，从而造成错误的调用。

传统的 LLM 生成过程是按如下方式采样下一个 token 的：

在构建掩码时，我们将所有不符合正确格式的 token 通过将其对应位置的值设为 0 进行屏蔽，而将其他合法位置的值设为 1。例如，如果我们已知下一个 token 应为整数类型，则仅对用于表示整数的 token 取消屏蔽（unmask），其余 token 均保持屏蔽状态。因此，精确构建掩码对于实现预期输出至关重要。在此背景下，我们列举了几种用于生成掩码的方法：

  • 枚举数据类型（enum data type）
    函数名通常是已知的，且在推理过程中不会改变，因此可将其视为枚举类型的变量。为了高效管理这些函数名，可以构建一棵 Trie 树（前缀树），从而以时间复杂度 O(D) 快速检索出有效 token，其中 D 表示 Trie 树的深度，即函数名的最大长度。在我们的场景中，该长度约为 20，因此可视为常数时间复杂度。作为另一种替代方案，将所有可能函数名的前缀存储在一个字典中，可进一步将查询复杂度降低至 O(1)。Trie 类的具体实现详见附录（B.2）。

  • 字符串（string）、浮点数（float）、字典（dict）、整数（int）等类型
    可以使用正则表达式（Regular Expressions）来分析后续 token 的合法形式，并据此生成条件掩码。

通过上述方法，我们可以确保模型输出结果完全避免格式错误。实验结果表明，应用条件掩码显著增强了大语言模型（LLM）在函数调用场景下的鲁棒性与准确性。

4 大语言模型在函数调用中的评估

我们对数据集进行了一系列全面测试，将 Octopus 模型与其它领先模型进行了对比评估。本次评估重点关注 Octopus 模型理解 API 调用的能力，特别是针对 RapidAPI 上的 API 调用表现。此外，我们还探讨了在训练阶段引入不同检索技术对模型最终效果的影响。

在基线模型选择方面，我们主要将 Octopus 与当前最先进的语言模型在零样本（zero-shot）框架下进行比较。所分析的模型包括 OpenAI 的 GPT-4（使用 gpt-4-0314 检查点）和 GPT-3.5-turbo（使用 gpt-3.5-turbo-0301 检查点）。这两个模型均经过基于人类反馈的强化学习（RLHF）优化，具备更强的对话能力。

4.1 评估数据集与基准测试

为了对常用软件 API 中的函数调用能力进行基准测试，我们专门构建了一个评估数据集。该数据集通过从大量 API 中随机选取四个不同的函数 API，并生成可由这些 API 解决的查询语句来构建。查询的生成采用了与训练阶段相同的提示模板（prompt template），具体细节见附录 B.1。

此外，我们还加入了一些这些 API 无法解决的查询，并保持可解与不可解查询的比例为 1:1，以确保数据集的平衡性。该数据集的真实标签（ground truth）通过人工标注确定。

我们在基准测试中采用了严格的标准，重点关注实际应用场景中的需求，包括函数名和参数的精确匹配。对于未在本数据集上进行训练的模型（如 GPT-4 和 GPT-3.5），我们忽略其输出格式错误问题，以确保比较的公平性。因此，在我们的分析中，GPT-3.5 因格式不正确而产生的问题不被记为错误。

4.2 无条件掩码时的性能表现

在函数调用推理任务中，我们首先使用了 GPT-3.5 和 GPT-4 模型来生成响应。对于这些预训练模型，我们采用贪心搜索（greedy search）技术来选择输出结果。这一选择是基于任务对精度的高要求，即必须准确识别出函数名称及其对应的参数，而模型能否正确选择函数名和参数至关重要。因此，本任务未采用采样（sampling）或束搜索（beam search）等其他生成方法。该方法得到的准确率指标结果如图（3）所示。

结果表明，GPT-4 在生成正确结果方面始终保持着最高的准确率。然而，GPT-4 存在一个显著问题，即“幻觉”现象，会导致输出不准确。例如，GPT-4 可能会自动纠正拼写错误的函数名，将 send emil 修正为 send email。但关键在于，无论函数名是否存在拼写错误，初始提示中提供的函数名都必须保持不变。这类纠正问题也出现在参数生成中；例如，当查询明确要求输入国家名称时，GPT-4 可能会生成 Australian 作为参数（应为 Australia）。错误输出的主要来源是生成了不准确的参数。然而，所有预训练模型在识别正确函数名方面的表现几乎完美。

4.3 使用条件掩码时的性能表现

与前一节所述的推理方法不同，本场景在推理过程中引入了条件掩码（conditional mask）。这一改进在提升输出效果方面表现出显著成效，尤其是在参数生成方面。使用条件掩码后，当输入为枚举类型（enum type）时（例如国家名称），能够有效防止模型生成不符合预期的参数。该方法带来的性能提升如图（4）所示。

然而，由于 GPT-3.5 和 GPT-4 的 API 接口不提供logits（即模型输出的原始未归一化概率），我们无法在其生成过程中应用条件掩码技术，因此这两个模型的评估指标未出现改善。

尽管如此，值得注意的是：两个参数量为70亿（7B）的模型在应用条件掩码后，性能超过了GPT-4。这一结果凸显了在特定任务场景下，条件掩码技术在提升小型大语言模型准确性和鲁棒性方面的显著有效性。

5 结论

在本研究中，我们提出了一种新颖的框架，旨在训练大语言模型以掌握实际软件 API 的使用，并对其在 API 调用任务中的性能进行了评估，特别是与 GPT-4 模型进行了对比。我们的方法包括一套用于精炼数据集及相关提示模板（prompt template）的方法论，其中融入了负样本采样和课程学习（curriculum learning）策略。此外，我们提出了一种创新技术——条件掩码（conditional mask），旨在解决输出格式不匹配的问题。

原文链接：https://arxiv.org/pdf/2404.01549