Gorilla：检索感知训练如何将 LLM API 幻觉从 78% 降低到 11%
阅读 Gorilla 论文（Patil 等人，2023 年，arXiv:2305.15334，NeurIPS 2024），因为它正处于我经常遇到的两个问题的交汇点：我们如何让 LLM 代理以正确的参数调用正确的工具，以及在 API 发生变化时如何保持这种能力？这里的答案很实用，数据也非常亮眼 —— 但评估中包含的假设值得比通常情况下更多的审视。
论文内容
来自加州大学伯克利分校的 Shishir G. Patil、Tianjun Zhang、Xin Wang 和 Joseph E. Gonzalez 在论文中针对一种具体的失败模式提出了对策：最先进的 LLM 经常幻觉 API 调用。当被要求编写调用特定库函数的代码时，GPT-4（截至 2023 年年中）经常生成看起来合理但错误的函数签名、不存在的模型或已弃用的参数名称。Gorilla 是一个基于 LLaMA 的 70 亿参数模型，专门针对生成准确的 API 调用进行了微调，采用了一种作者称为检索感知训练（Retriever-Aware Training, RAT）的技术。这个想法很简单：在训练期间，模型会看到检索到的 API 文档以及用户查询，格式为“使用此 API 文档作为参考：<retrieved_API_doc_JSON>”。这教会了模型既要阅读文档，又要信任检索到的上下文而非其参数化记忆（parametric memory）—— 这种属性在推理阶段文档发生变化时会产生回报。
评估数据集 APIBench 涵盖了 925 个 HuggingFace Model Hub API、95 个 TorchHub API 和 696 个 TensorFlow Hub API，每个 API 通过 self-instruct 生成了 10 个合成指令遵循查询。评估指标是 AST 子树匹配 —— 生成的 API 调用被解析并检查功能正确性 —— 这也使得在此场景下首次能够对幻觉率进行原则性的衡量。
核心观点
- RAT 使文档在推理时可读。 通过在包含检索文档的提示词上进行训练，Gorilla 学会了依赖检索到的文本，而不是从权重中回忆 API 细节。这意味着随着 API 的演进，模型无需重新训练即可保持最新。
- 零样本准确率：Gorilla 为 59–84%，GPT-4 为 18–39%。 在 TorchHub 上，Gorilla 的准确率为 59.13%，而 GPT-4 为 38.70%。在 HuggingFace 上，两者分别为 71.68% 和 19.80%。在 TensorFlow Hub 上，为 83.79% 对 18.20%。在 API 空间最多样化的地方，差距最为显著。
- 降低幻觉是核心亮点。 Gorilla 在 TorchHub 上的幻觉率为 6.98%，在 HuggingFace 上为 10.95%，在 TensorFlow Hub 上为 5.40%。在相同数据集下，GPT-4 的幻觉率从 36.55% 到 78.65% 不等。
- Oracle 检索器是上限。 在检索到地面真值文档（oracle 模式）的情 况下，准确率达到了 67–94%。这是任何基于 RAG 系统理论上的最佳情况，零样本 Gorilla 与此上限之间的差距是检索器改进的空间。
- 真实的检索器表现欠佳。 在评估时从 oracle 切换到 GPT-Index 会使准确率下降 29.20%；切换到 BM25 则下降 52.27%。模型对检索噪声的鲁棒性是真实存在的，但并非无限。
- AST 评估具有通用性。 子树匹配方法衡量生成的调用是否在功能上正确，而不仅仅是语法相似。对于任何输出为实际执行代码的任务，这都是正确的指标。
哪些站得住脚 —— 哪些站不住
核心主张是成立的：在文档增强的提示词上进行微调可以显著提高 API 调用的准确性并减少幻觉。AST 评估方法确实新颖，且在规模化评估中明显优于字符串匹配或人工评估。RAT 是一个简洁、可复现的想法。
我持怀疑态度的是基准测试的范围。所有三个数据集（HuggingFace、TorchHub、TensorFlow Hub）都是具有非常规则的 API 结构的机器学习模型库：你通过名称加载模型，可能带有一些关键字参数，然后调用类似 predict 的方法。指令是合成生成的，这意味着测试分布与训练分布紧密相关。一个在通过 self-instruct 训练的机器学习 API 文档上进行调优，并在机器学习 API 的 self-instruct 查询上进行评估的模型，并没有在生产环境中实际出现的难点上进行测试：模糊的请求、多步工作流、参数类型强制转换、身份验证、速率限制或错误恢复。
检索带来的性能退化也比 论文描述的更为严重。使用 BM25 检索时 52% 的准确率下降是灾难性的。如果你在生产中部署的检索器更接近 BM25 而不是 oracle，那么收益就会化为乌有。作者承认了这一差距，但没有提供缩小差距的路径。
最后，模型本身是一个 7B LLaMA 微调版本。与 GPT-4 零样本的对比虽然惊人，但并不完全公平：GPT-4 未经训练以使用检索到的文档。如果 GPT-4 配合专门设计用于阅读 API 文档的系统提示词进行 RAG 增强，几乎肯定会大幅缩小差距。
为什么这对金融 AI 至关重要
RAT 模式直接适用于 Beancount 回写代理。Beancount 代理需要调用 CLI 命令（bean-query、bean-report）、Python API（beancount.loader、beancount.core）以及 beancount-ledger FastAPI 服务 —— 每个都有特定的参数语义，这些语义虽然有文档记录，但不一定在模型的训练数据中。Gorilla 的方法是：在推理时检索相关的文档片段，将其注入上下文中，并训练模型阅读并遵循它。
幻觉数据是金融场景下最有用的信号。在机器学习模型名称上 10% 的幻觉率只是令人烦恼。但在账本变更调用（错误的账户名称、错误的货币代码、颠倒的借贷符号）中 10% 的幻觉率则是正确性问题。这意味着即使是经过 Gorilla 式训练的代理，在提交任何写入之前也需要一个执行时验证器，这与 CRITIC (LOG-012) 所展示的工具交互式批评（tool-interactive critiquing）一致。检索退化的发现强化了这一点：如果现实世界的检索会使准确率减半，那么安全网不能 仅仅依靠检索质量。
AST 评估方法可以自然转化。Beancount 交易具有可解析的结构，使用 AST 匹配对照 schema 检查生成的指令，正是可以在 pre-commit 钩子或代理循环中运行的那种轻量级验证器。
延伸阅读
- ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (arXiv:2307.16789) —— 将 API 调用问题扩展到 16,000 个真实的 REST API，并带有多步工具使用链；直接解决了 Gorilla 仅评估单次调用机器学习库调用的局限性。
- 伯克利函数调用排行榜 (BFCL) (OpenReview:2GmDdhBdDk, NeurIPS 2024 海报) —— Gorilla 的直接演变，是一个实时排行榜，追踪前沿模型在函数调用方面的进步；V3 增加了多轮交互，V4 增加了代理式网络搜索。
- API-Bank: A Comprehensive Benchmark for Tool-Augmented LLMs —— 在更广泛的领域（包括金融和 Web 服务）中，针对 73 个 API 评估 LLM，具有多轮工具使用；是对比 APIBench 较窄的机器学习关注点的有用补充。
