论文阅读：Gorilla: Large Language Model Connected with Massive APIs-EW帮帮网

地址：Gorilla: Large Language Model Connected with Massive APIs

摘要

大型语言模型（LLMs）已迎来令人瞩目的发展浪潮，如今在数学推理、程序合成等各类任务中均表现出色。然而，它们通过 API 调用有效使用工具的潜力尚未充分发挥。即便对于像 GPT-4 这样当今最先进的大型语言模型而言，这仍是一项极具挑战性的任务，主要原因在于它们不清楚可用的 API 有哪些，以及在频繁更新的工具集中如何使用这些 API。我们开发了 Gorilla，这是一款基于 LLaMA 模型微调而成的模型，其在编写 API 调用方面的性能超越了 GPT-4。该模型采用新颖的检索器感知训练（Retriever Aware Training, RAT）方法进行训练，当与文档检索器结合使用时，Gorilla 展现出强大的适应测试时文档变化的能力，能够灵活应对用户更新或版本变更。同时，它还大幅缓解了直接对大型语言模型进行提示时常见的幻觉问题。为评估该模型的能力，我们引入了 APIBench 数据集，这是一个涵盖 HuggingFace、TorchHub 和 TensorHub API 的综合数据集。检索系统与 Gorilla 的成功集成表明，大型语言模型有望更准确地使用工具、及时跟进频繁更新的文档，进而提高其输出结果的可靠性和适用性。Gorilla 的代码、模型、数据和演示版本可在以下网址获取：Gorilla

一、研究动机

1. LLM 对 API 的 “认知缺口”：未知性与不适应性

现有 LLMs（如 GPT-4）难以高效使用 API 的首要障碍是 “信息滞后” 与 “范围盲区”。一方面，API 生态系统规模庞大（仅 HuggingFace 就托管约 203,681 个模型）且更新频繁（如版本迭代、参数增减、注册源变更），LLMs 的训练数据无法覆盖所有 API 及实时更新内容，导致模型不清楚 “有哪些 API 可用”；另一方面，即便模型尝试调用 API，也常因不了解最新使用规则（如新增必填参数、废弃旧函数）生成错误代码，例如在语音转文本任务中，GPT-4 会调用 TorchHub 中不存在的asr模型，Claude 则错误选择torchaudio库而非指定平台，严重限制 LLMs 的工具使用能力。

2. LLM 生成 API 调用的 “幻觉顽疾”

直接提示 LLMs 生成 API 调用时，普遍存在 “幻觉” 问题 —— 即生成不存在的 API（如虚构 GitHub 仓库名、错误参数组合）或调用与任务无关的库。这种幻觉并非简单的参数错误，而是模型 “凭空创造工具” 的严重缺陷：例如在 HuggingFace API 生成中，GPT-4 会将非 HuggingFace 仓库名填入pretrained_model_name_or_path参数，或假设用户拥有本地未公开的模型文件（如your_model_name）。这种问题源于 LLMs 依赖内部静态知识，缺乏对外部 API 库的精准认知，导致生成结果可靠性极低，无法满足实际开发需求。

3. API 评估的 “基准缺失”：无统一数据集与有效指标

此前研究缺乏专门用于评估 LLMs API 调用能力的综合基准：一方面，现有数据集要么规模小（仅覆盖少数 API），要么信息不完整（缺少性能、环境依赖等关键字段），无法全面测试模型在不同领域、不同约束下的 API 调用能力；另一方面，传统 NLP 评估指标（如 BLEU、ROUGE）基于文本相似度，无法区分 API 调用的 “功能正确性”—— 例如，两个文本相似的 API 调用可能功能完全不同，而功能等价的 API 调用可能文本表述差异较大。同时，传统指标也无法有效量化 “幻觉”（虚构 API）与 “错误”（调用正确 API 但参数错误）的区别，导致 LLMs API 调用能力的评估缺乏客观性与可比性。

二、方法架构

（一）数据集构建（APIBench）

1. 核心来源平台

为确保数据集的多样性和代表性，三个平台覆盖的具体领域各有侧重：

TorchHub：涵盖 6 个核心领域，包括分类（Classification）、语义分割（Semantic Segmentation）、目标检测（Object Detection）、音频分离（Audio Separation）、视频分类（Video Classification）和文本转语音（Text-to-Speech）。

TensorHub：领域最广泛，共 57 个领域，涵盖文本（如文本嵌入、文本分类、文本生成）、图像（如图像分类、目标检测、图像超分辨率）、视频（如视频分类、视频生成）、音频（如音频嵌入、语音转文本）等多个方向。
HuggingFace：包含 37 个领域，覆盖多模态（如文本转图像、图像转文本、视觉问答）、计算机视觉（如深度估计、图像分割、视频分类）、自然语言处理（如文本分类、翻译、摘要）、音频（如语音识别、音频分类）、表格数据（如表格分类、回归）和强化学习等领域。

2.数据筛选

HuggingFace：平台拥有约 203,681 个模型，但许多模型存在文档不完善、依赖缺失等问题。研究从多模态数据（7 个领域）、计算机视觉（8 个领域）、自然语言处理（12 个领域）、音频（5 个领域）、表格数据（2 个领域）和强化学习（2 个领域）等领域中，每个领域选取排名前 20 的模型，最终筛选出 925 个模型。
TensorFlow Hub：分为 v1 和 v2 版本，研究选取最新的 v2 版本，该版本共 801 个模型，剔除文档信息极少的模型后，保留 626 个模型。
Torch Hub：全面提取其中的模型，最终得到 95 个模型。

3. 数据格式标准化

为统一不同平台 API 的表示形式，研究将每个 API 的模型卡片转换为包含10 个核心字段的 JSON 对象，确保数据的可扩展性和可解释性，字段定义如下：

{
  "domain": "API所属领域（如目标检测、文本分类）",
  "framework": "依赖的机器学习框架（如PyTorch、TensorFlow）",
  "functionality": "API的核心功能描述",
  "api_name": "API的官方名称",
  "api_call": "可直接执行的API调用代码（如torch.hub.load(...)）",
  "api_arguments": "API的关键参数及取值范围",
  "environment_requirements": "运行API的环境要求（如Python版本、库依赖）",
  "example_code": "API使用的完整示例代码",
  "performance": "API对应模型的性能指标（如准确率、mAP）",
  "description": "API的详细说明及适用场景"
}

4. 指令生成

为解决 API 训练数据中 “指令 - API 对” 稀缺的问题，研究借鉴Self-instruct 范式，使用 GPT-4 生成大规模合成指令数据，具体流程如下：

种子示例构建：手动设计 18 个高质量 “指令 - API 对” 种子示例（每个平台 6 个），示例中包含自然语言指令（不包含任何 API 名称或提示）、对应的 API 调用及参考文档，确保指令符合真实应用场景（如 “构建医学图像分类器”“将录音中的语音转换为文本”）。
批量指令生成：对 APIBench 中的 1,645 个 API，每次从对应平台的 6 个种子示例中随机抽取 3 个作为上下文，输入 GPT-4 并要求其生成 10 个与该 API 功能匹配的自然语言指令，且明确禁止指令中出现 API 名称或参数提示。
数据量扩展：最终生成 16,450 个 “指令 - API 对”（1,645 个 API × 10 个指令），形成核心训练数据集，同时确保指令的多样性和实用性，避免重复或无效表述。

5. 带约束的 API 指令扩展

API 调用常需满足特定约束（如模型参数规模、准确率下限），为提升模型对约束的理解能力，研究将约束信息融入训练数据：

约束类型定义：针对机器学习 API，重点关注两类约束：一是参数规模约束（如 “模型参数小于 1000 万”），二是性能约束（如 “ImageNet 准确率不低于 70%”）。

约束指令生成：基于 API 的 “performance” 和 “api_arguments” 字段，生成包含约束条件的自然语言指令（如 “调用一个参数小于 10M 且 ImageNet 准确率至少 70% 的图像分类模型”），并将这些带约束的 “指令 - API 对” 补充到训练数据中，增强模型对复杂需求的响应能力。

（二）Gorilla 模型设计

1. 基础模型与微调方式

Gorilla 基于 LLaMA-7B 模型进行微调，将生成的 “指令 - API” 对转换为用户 - 智能体对话风格的格式，每个数据点包含一轮用户提问和智能体回答，然后对基础 LLaMA-7B 模型进行标准的指令微调。模型训练分为带检索器和不带检索器两种方式，且微调方法对底层预训练模型具有鲁棒性。

2. 检索器感知训练（RAT）原理

训练过程：在指令微调数据集中，将相关的检索文档以 “Use this API documentation for reference: <retrieved_API_doc_JSON>” 的形式附加到用户提示后。由于检索器的召回率并非完美，检索到的文档可能不准确，通过这种方式，在模型响应中提供准确的真实信息，实际上是教会模型在推理时 “判断” 检索器的结果。
推理时作用：推理时，若模型判断检索器提供的 API 文档与用户提示相关，就会利用该文档补充用户提示中的细节来生成响应；若判断不相关，模型不会被无关上下文干扰，而是依靠检索器感知训练过程中融入的领域特定知识提供相关 API。这种训练方式使模型能适应测试时 API 文档的变化、提升上下文学习性能并减少幻觉错误。

3. Gorilla 推理过程

Gorilla 推理支持零样本和带检索器两种模式：

零样本模式：直接将用户的自然语言提示输入到 Gorilla 模型中，模型输出完成任务所需的 API 调用。
带检索器模式：首先，检索器（BM25 或 GPT-Index）从 API 数据库中检索最新的 API 文档；然后，将检索到的 API 文档与用户提示拼接，附加 “Use this API documentation for reference.” 的信息后输入到 Gorilla 模型；最后，模型输出对应的 API 调用。研究还实现了执行这些 API 的系统，但这并非论文重点。

（三）API 验证方法（AST 子树匹配）

1. 核心原理

由于 API 调用存在多个正确答案，仅通过单元测试难以验证代码的语义正确性，因此采用 AST 子树匹配的方法来评估模型生成的 API 调用与数据集中参考 API 的功能等价性。对于单个 API 调用，检查生成 API 调用的 AST 是否为参考 API 调用 AST 的子树，以此确定模型调用的是数据集中的哪个 API。

2. 幻觉定义与判断

将幻觉定义为生成的 API 调用不是数据集中任何 API 的 AST 子树，即调用了完全虚构的工具；而将调用 API 错误（如参数错误等）定义为错误。在评估中，准确率、幻觉率和错误率之和为 1。

3. 具体匹配过程

考虑到 Python 允许默认参数，对于每个 API，在数据库中预先定义需要匹配的参数。例如，在函数调用中检查repo_or_dir和model参数。以 torch API 调用为例，先构建生成 API 调用的 AST 树，然后与数据集中的 AST 树进行对比，匹配torch.hub.load、pytorch/vision、densenet121等节点，而对于pretrained=True这类可选参数则不进行匹配检查。

三、实验设计

1. 基线模型对照组

选取当前主流的开源与闭源大型语言模型（LLMs）作为基线，覆盖不同模型规模、训练目标与开源属性，具体包括：

闭源模型：
- GPT-4（OpenAI，gpt-4-0314 checkpoint）：当时最先进的闭源 LLM，采用 RLHF（基于人类反馈的强化学习）训练，主打对话与复杂任务推理能力。
- GPT-3.5-turbo（OpenAI，gpt-3.5-turbo-0301 checkpoint）：轻量级闭源 LLM，同样经过 RLHF 优化，在效率与基础任务表现上平衡较好。
- Claude（Anthropic，claude-v1 checkpoint）：以长上下文处理能力著称的闭源 LLM，在文档理解与逻辑推理场景有优势。
开源模型：
- LLaMA-7B（Meta）：开源基础 LLM，未经过 API 调用相关微调，作为开源模型的基础基线，用于验证微调对 API 任务的增益。

所有基线模型均在零样本（0-shot） 与三样本上下文学习（3-shot in-context） 两种设置下进行测试：零样本设置直接输入用户指令，无额外提示；三样本设置则在指令前附加 3 个 “指令 - API 对” 示例，模拟实际应用中少量示例引导的场景。

2. 检索器类型对照组

为验证检索器感知训练（RAT）的有效性及不同检索器对模型性能的影响，设计 4 类检索器对比组，覆盖 “无检索”“传统检索”“先进嵌入检索” 与 “理想检索” 场景：

零样本（0-shot）：无任何检索器参与，模型仅依赖自身预训练或微调知识生成 API 调用，用于评估模型的 “无外部辅助” 基础能力。
BM25 检索器：传统文本检索方法，将每个 API 视为独立文档，通过用户指令与文档的文本相似度（BM25 算法）检索 Top-1 相关 API 文档，并将文档拼接至用户指令后输入模型。
GPT-Index 检索器：基于嵌入的先进检索方法，使用 OpenAI 的 text-embedding-ada-002-v2 模型（嵌入维度 1536）对 API 文档进行编码，通过向量相似度检索 Top-1 相关文档，同样拼接至指令后输入模型。
Oracle 检索器：理想检索器（上限参照组），能以 100% 召回率返回与指令完全匹配的 API 文档，用于衡量 “检索器性能无缺陷” 时模型的理论上限，同时辅助分析检索器误差对模型性能的影响。

四、评价指标

1. 核心量化指标定义

（1）AST 准确率（AST Accuracy）

定义：衡量模型生成的 API 调用与数据集中参考 API 的功能等价性，通过 AST 子树匹配判断：若生成 API 调用的 AST 是参考 API AST 的子树，则视为正确。
计算逻辑：
对单个测试样本，设参考 API 集合为S，生成 API 的 AST 为Tgen，参考 API 的 AST 集合为{Tref∣Tref∈S}。若存在Tref∈S使得Tgen是Tref的子树，则该样本计为 “正确”；否则计为 “错误” 或 “幻觉”。
准确率计算公式为：AST Accuracy=正确样本数/总有效样本数×100%
参数匹配规则：根据 API 类型定义必匹配参数，如 TorchHub 的torch.hub.load需匹配repo_or_dir与model参数，TensorHub 的hub.load需匹配handle参数，可选参数（如pretrained=True）不参与匹配。

（2）幻觉率（Hallucination Rate）

定义：衡量模型生成 “完全虚构 API” 的比例，即生成的 API 调用不属于数据集中任何参考 API（AST 子树不匹配任何Tref）。
计算公式：
Hallucination Rate=幻觉样本数/总有效样本数×100%
与 “错误” 的区别：“错误” 指调用了数据集中的 API 但参数错误（如model参数取值错误），而 “幻觉” 指调用了数据集中不存在的 API（如虚构的 GitHub 仓库名）。

（3）错误率（Error Rate）

定义：衡量模型调用了数据集中的 API 但存在参数错误、格式错误等问题的比例。
计算公式：
Error Rate=数错误样本数/总有效样本×100%
三者关系：在所有有效样本中，准确率、幻觉率、错误率满足互斥且穷尽，即：
AST Accuracy+Hallucination Rate+Error Rate=100%

2. 辅助验证指标

（1）人工评估准确率

目的：验证 AST 指标的可靠性，避免因 AST 匹配规则导致的偏差。
方法：随机选取 100 个 Gorilla 生成的 API 调用样本，由人工判断 “是否调用了正确的 API” 及 “代码是否可执行”，计算人工评估准确率与代码可执行率。
结果：AST 准确率（78%）与人工评估准确率（78%）完全一致，代码可执行率为 72%（未执行成功的 6% 为辅助代码错误，非 API 本身错误），证明 AST 指标的有效性。

（2）约束满足率（Constraint Satisfaction Rate）

目的：评估模型在带约束指令下的性能，即生成的 API 是否满足指令中的约束条件（如参数规模、准确率）。
计算逻辑：对带约束的测试样本，检查生成 API 的 “performance”“api_arguments” 字段是否满足约束，满足则计为 “约束满足”，计算公式为：
Constraint Satisfaction Rate=约束满足样本数/带约束总样本数×100%

五、实验结论

1. Gorilla 模型在 API 调用任务上显著优于现有 LLMs

在 APIBench 数据集的零样本与带检索器设置下，Gorilla（基于 LLaMA-7B 微调）的性能全面超越开源与闭源基线模型（GPT-4、GPT-3.5、Claude、LLaMA）：

准确率优势：零样本设置下，Gorilla 在 TorchHub 的 AST 准确率为 59.13%，比 GPT-4（38.70%）高 20.43%，比 LLaMA（0%）高 59.13%；在 TensorHub 的准确率达 83.79%，远超 GPT-4 的 18.20% 与 Claude 的 9.19%。
幻觉抑制优势：零样本设置下，Gorilla 在 TorchHub 的幻觉率仅为 6.98%，远低于 GPT-4 的 36.55%、Claude 的 65.59%；结合 GPT-Index 检索器后，Gorilla 的幻觉率降至 0%，而 GPT-4 仍有 1.07% 的幻觉率。
约束感知能力：在带约束的 API 调用任务（如 “参数 < 10M 且 ImageNet 准确率≥70%”）中，Gorilla 在零样本设置下的约束满足率达 47.88%，高于 GPT-3.5（43.66%）与 GPT-4（43.66%），证明其能有效理解并响应用户的约束需求。

2. 检索器感知训练（RAT）是提升 LLM API 适应性的关键

RAT 技术通过 “噪声检索文档 + 正确 API 响应” 的训练方式，使 Gorilla 具备自主判断检索文档相关性的能力，从而有效适应 API 文档的动态变化：

性能提升：结合 RAT 训练后，Gorilla 在 TorchHub 的准确率比无检索器微调高 12.37%，在 HuggingFace 高 23.46%；即使使用性能有限的 BM25 检索器，Gorilla 的准确率仍优于零样本设置下的 GPT-4。
变化适应性：RAT 使 Gorilla 能应对三类 API 文档变化：一是模型版本更新（如将 FCN 的 ResNet-50 骨干网络升级为 ResNet-101），二是注册源变更（如从pytorch/vision迁移到NVIDIA/DeepLearningExamples:torchhub），三是参数约束调整（如新增 “准确率≥80%” 的要求）。实验表明，当 API 文档发生上述变化时，Gorilla 的准确率下降幅度仅为 GPT-4 的 1/3~1/2，证明其强适应性。

3. APIBench 数据集与 AST 指标为 API 评估提供可靠基准

APIBench 的有效性：包含 1,645 个 API（覆盖 HuggingFace、TorchHub、TensorHub）及 16,450 个 “指令 - API 对”，涵盖 37~57 个领域，能全面测试模型在多平台、多约束下的 API 调用能力。后续实验证明，基于 APIBench 训练的模型能迁移到未见过的 API 领域，验证了数据集的泛化价值。
AST 指标的可靠性：基于 AST 子树匹配的评估指标（准确率、幻觉率、错误率）与人工评估高度一致 —— 对 100 个随机样本的评估显示，AST 准确率（78%）与人工判断准确率完全相同，且 72% 的 Gorilla 生成代码可成功执行（未执行成功的 6% 为辅助代码错误，非 API 本身问题）。三者满足以下关系：
AST Accuracy+Hallucination Rate+Error Rate=100%
该指标有效区分了 “幻觉” 与 “错误”，解决了传统指标的局限性。

4. 微调 + 检索的组合优于单纯提示或检索

对比 “零样本提示”“三样本上下文学习”“微调 + 检索” 三种方式发现：三样本提示虽能提升 GPT 模型的 API 调用准确率（如 GPT-4 在 TorchHub 的准确率从 54.30% 提升至 75.80%），但仍低于零样本 Gorilla（75.80% 与 Gorilla 持平，但幻觉率更高）；而 “微调 + 检索” 的组合（即 Gorilla+RAT）在所有设置下均表现最佳，证明通过微调将 API 知识内化为模型能力，同时结合检索获取实时文档，是提升 LLM API 调用能力的最优路径。

六、创新点分析

1.提出 Gorilla 系统 —— 首个支持大规模 API 集成的 LLM

Gorilla 是基于 LLaMA-7B 微调的模型，首次实现 LLM 与海量 API 的高效集成，具备两大核心能力：

精准生成 API 调用：通过指令微调，Gorilla 能根据用户自然语言指令（如 “构建医学图像分类器”“跟踪动物园动物运动”），输出包含正确 API 调用、相关依赖包及分步流程说明的结果。在 APIBench 数据集上，零样本设置下 Gorilla 的 AST 准确率比 GPT-4 高 20.43%，比 LLaMA 高 83%，且幻觉率仅为 6.98%（远低于 GPT-4 的 36.55%）。
双模式推理支持：Gorilla 支持 “零样本” 与 “带检索器” 两种推理模式：零样本模式直接利用微调知识生成 API 调用；带检索器模式则结合外部检索器（BM25/GPT-Index/Oracle）获取最新 API 文档，确保对动态更新 API 的适应性。例如，当检索到 API 版本更新文档时，模型能自动调整调用代码，避免使用过时参数。

2. 提出检索器感知训练（Retriever-Aware Training, RAT）技术

针对 LLM 难以适应 API 文档动态变化的问题，RAT 技术创新性地将 “检索器判断能力” 融入模型训练，核心原理如下：

训练过程设计：在微调数据中，为用户指令附加 “可能不准确的检索文档”（模拟真实检索场景的召回误差），同时在模型响应中提供准确的 API 调用。通过这种 “噪声文档 + 正确响应” 的训练方式，教会模型在推理时自主判断检索文档的相关性 —— 若文档相关则利用其补充细节，若不相关则忽略干扰，依赖领域知识生成 API。
核心优势：RAT 使 Gorilla 能灵活应对测试时 API 文档的三大变化：一是 API 版本更新（如模型骨干网络升级），二是参数约束变更（如新增必填参数），三是模型注册源调整（如从 PyTorch Hub 迁移到 NVIDIA 仓库）。实验表明，结合 RAT 训练后，Gorilla 在 TorchHub 的准确率比无检索器微调高 12.37%，在 HuggingFace 高 23.46%。

3.构建 APIBench—— 首个综合机器学习 API 基准数据集

APIBench 填补了 API 评估数据集的空白，具备 “规模大、覆盖广、信息全” 的特点：

数据规模与来源：共包含 1,645 个 API 调用样本，涵盖 HuggingFace（925 个，覆盖 37 个领域）、TorchHub（95 个，覆盖 6 个领域）、TensorHub（626 个，覆盖 57 个领域）三大主流平台，是当时已知最大的机器学习 API 数据集。
数据结构化设计：每个 API 样本以 JSON 格式存储，包含domain（领域）、api_call（调用代码）、performance（性能指标）、environment_requirements（环境要求）等 10 个字段，不仅支持 API 调用训练，还能满足 “带约束 API 调用” 任务（如 “参数小于 10M 且准确率≥70%”）。
指令数据生成：基于 Self-instruct 范式，使用 GPT-4 为每个 API 生成 10 个自然语言指令，形成 16,450 个 “指令 - API 对” 训练数据，且指令中不包含任何 API 名称提示，确保模型真正理解任务而非依赖关键词匹配。

4. 提出基于 AST 的评估指标体系

针对 API 调用评估的特殊性，论文设计了以抽象语法树（AST）子树匹配为核心的量化指标，解决传统指标的局限性：

AST 准确率：衡量生成 API 与参考 API 的功能等价性 —— 若生成 API 的 AST 是参考 API AST 的子树，则视为正确。计算公式为：
AST Accuracy=总有效样本数正确样本数×100%
该指标能精准判断 API 调用的有效性，例如对torch.hub.load('pytorch/vision', 'densenet121', pretrained=True)，仅需匹配repo_or_dir（pytorch/vision）和model（densenet121）参数，忽略可选的pretrained参数，避免因格式差异误判。
幻觉率与错误率：首次明确区分 “幻觉” 与 “错误”：幻觉指生成的 API 不属于数据集中任何参考 API（AST 不匹配任何参考 AST），错误指调用了数据集中的 API 但参数错误。两者计算公式分别为：
Hallucination Rate=总有效样本数幻觉样本数×100%
Error Rate=总有效样本数错误样本数×100%
三者满足 AST Accuracy+Hallucination Rate+Error Rate=100%，实现对 API 调用质量的全面量化。
指标可靠性验证：通过人工评估验证，AST 准确率（78%）与人工判断准确率完全一致，且 72% 的 Gorilla 生成代码可成功执行，证明该指标能有效替代耗时的人工评估。

七、相关工作

1. LLM 与工具使用（Tool Usage for LLMs）

现有研究已探索 LLM 结合外部工具提升能力，但存在 “聚焦特定工具、缺乏系统性” 的局限，具体包括：

早期工具集成探索：以 Toolformer 为代表的工作（[33]）首次证明 LLM 可自主决定调用工具的时机与方式，涉及的工具包括网页浏览（[32]）、计算器（[12, 39]）、翻译系统（[39]）、Python 解释器（[14]）等。例如，Toolformer 通过微调让 LLM 生成工具调用代码（如search("2024年奥运会举办地")），再执行工具获取结果并生成最终回答。
API 在特定领域的应用：部分研究尝试将 API 用于机器人控制（[41, 4]），如通过 API 调用机器人运动控制函数实现特定动作；还有工作通过 API 连接数据库与搜索技术（[24, 39, 35]），让 LLM 获取动态知识或完成复杂计算。
与本研究的差异：现有工作仅针对 “单一或少数工具”，未覆盖大规模、多领域的 API 生态（如 HuggingFace/TorchHub/TensorHub 的海量 API）；且多依赖 “提示工程” 演示工具使用潜力，缺乏统一的评估基准与系统化的训练方法（如微调 + 检索的结合）。而 Gorilla 首次以 “开放域海量 API” 为目标，通过 RAT 技术和 APIBench 基准，实现 LLM 对动态 API 生态的适应性与可评估性。

2. 大型语言模型（Large Language Models, LLMs）

LLM 领域的预训练、微调技术为 Gorilla 提供了基础，但现有工作聚焦方向与本研究不同：

LLM 能力拓展：近年来 LLM 在自然语言处理、程序合成等领域快速发展（[10, 40, 48, 47]），例如 PaLM（[10]）通过路径缩放提升模型规模与推理能力，CodeLlama（[40] 衍生工作）优化代码生成性能。这些进展主要依赖 “更大模型规模” 或 “领域特定预训练”。
微调技术成熟：指令微调（[11, 30, 43, 15]）、提示工程（[44, 14]）成为提升 LLM 任务适配性的核心方法。例如，Alpaca（[38]）通过 Self-instruct 生成指令数据微调 LLaMA，提升对话能力；Vicuna（[9]）通过 GPT-4 生成的对话数据微调，实现接近 ChatGPT 的对话质量。
与本研究的差异：现有 LLM 微调多聚焦 “对话能力”“通用推理” 或 “特定任务（如数学）”，未针对 “API 调用” 这一需要 “精准知识 + 动态适应” 的场景设计训练方法。Gorilla 的创新在于：一是将 “检索器判断能力” 融入微调（RAT 技术），而非单纯依赖静态指令数据；二是微调目标聚焦 “API 调用的准确性与适应性”，而非通用对话或推理。

3. LLM 与程序合成（LLMs for Program Synthesis）

现有工作致力于提升 LLM 生成代码的能力，但在 “API 调用正确性” 与 “评估方法” 上存在不足：

代码生成优化策略：研究人员通过多种方法改进 LLM 代码生成，包括上下文学习（[44, 18, 7]）、任务分解（[17, 46]）、自调试（[8, 34]）等。例如，Self-Debugging（[8]）让 LLM 生成代码后自主检测错误并修正；CodeGen（[25, 26]）通过 “代码专用预训练” 提升代码生成质量。
API 相关代码生成探索：DocPrompting（[49]）是与 Gorilla 最接近的工作，其通过检索 API 文档辅助 LLM 生成代码，核心思路是 “先检索文档片段，再基于文档生成代码”。
与本研究的差异：一方面，现有程序合成工作多关注 “通用代码逻辑正确性”，而非 “API 调用的功能等价性”（如是否调用正确的 API 及参数）；另一方面，DocPrompting 存在三大局限：数据集仅包含通用 API 调用信息，缺乏参数、性能等细节；评估依赖传统 NLP 指标（如 BLEU），未量化幻觉；聚焦 “NLP 到代码的生成”，无用户约束感知能力。而 Gorilla 通过 APIBench 的结构化数据（含性能、约束字段）、AST 评估指标、RAT 技术，解决了这些问题，并在实验中证明（附录 A.3.4），Gorilla 的准确率（71.68%）高于 DocPrompting（61.72%），幻觉率（10.95%）低于 DocPrompting（17.36%）。

论文阅读：Gorilla: Large Language Model Connected with Massive APIs

摘要