Gorilla：教大模型「别瞎打电话」的开源功臣

上周有个做后端的朋友问我："听说有个叫 Gorilla 的大模型，专门干工具调用，是 Meta 开源的那个吧？"

我说："一半对，一半错。Meta 确实有关系，但它真不是 Meta 做的。"

他一脸懵："那是谁做的？又跟 Meta 有什么关系？"

这其实是一个特别有意思的误会。而要把这个误会讲清楚，恰好能顺带把"大模型到底怎么学会调用工具的"这件事，整个掰开揉碎讲明白。

因为今天你用的所有 Agent——不管是能帮你订机票的，还是能操作你电脑的——背后都站着一个核心能力：Function Calling（函数调用 / 工具调用）。让模型不再只会"说",而是会"做"。而 Gorilla，就是把这件事第一个做到极致、还把全套方法和评测标准都开源出来的项目。

它甚至在自己最擅长的赛道上，把当年如日中天的 GPT-4 给比下去了。一个参数量只有人家零头的小模型，怎么做到的？这篇文章，我们就来当一回侦探，层层揭开这只"大猩猩"的底牌。

一、先澄清一件事：它到底是谁家的？

先把身世问题解决掉，因为这是很多人的第一个误区。

Gorilla 不是 Meta 的项目。它来自 加州大学伯克利分校（UC Berkeley），由微软研究院联合参与，论文一作是博士生 Shishir G. Patil，团队里还有大名鼎鼎的 Spark、Databricks 之父 Matei Zaharia。论文叫《Gorilla: Large Language Model Connected with Massive APIs》，2023 年 5 月挂上 arXiv，后来中选了 NeurIPS 2024。

那为什么大家总把它跟 Meta 搅在一起？

因为初代 Gorilla 的"底子"，用的正是 Meta 开源的 LLaMA-7B。它是在 LLaMA 这个基座模型上微调出来的。换句话说，Meta 提供了毛坯房，伯克利做了精装修——房子是 Meta 盖的，但设计和装修是伯克利的。这就是误会的根源。

常见误解

"Gorilla 是 Meta 开源的工具调用大模型"——这句话流传很广，但并不准确。准确的说法是：Gorilla 由 UC Berkeley 主导、微软研究院参与，开源协议为 Apache 2.0（可商用）；它的初代基座模型才是 Meta 的 LLaMA。把基座的"出身"安到项目本身头上，是个典型的张冠李戴。

厘清了身世，我们就能问下一个、也是更关键的问题了：伯克利这帮人，为什么要专门做这么一个模型？GPT-4 不香吗？

答案是：在 2023 年那个节点，GPT-4 聊天很香，但一让它"打电话"，就经常打错号码。Gorilla 的存在，本身就是对一个行业痛点的正面回应。

二、大模型打电话，为什么总打错？

我们先得搞清楚，"工具调用"这件事到底难在哪。

你可以把每一个 API（应用程序接口）想象成一部"功能电话"。想用 HuggingFace 上的某个翻译模型，你得拨对它的"号码"——也就是准确的函数名、参数名、参数格式。一个字母错了，电话就打不通。

问题来了：大模型最擅长的事，恰恰是"编"。它本质上是个概率机器，根据上文猜下一个最像样的词。让它写诗，编得天花乱坠是优点；可让它写 API 调用，这个"爱编"的天性就成了灾难。

它会一本正经地告诉你：调用 torch.hub.load('pytorch/vision', 'super_resolution_x4')。代码看着特别专业，特别像那么回事。然后你一跑——报错。因为这个模型名根本不存在，是它现编的。

关键区别

这就是大名鼎鼎的 幻觉（Hallucination） 在工具调用场景下的样子。聊天时的幻觉，顶多是答案不准，你还能将就着看；可调用 API 时的幻觉，是直接"调用一个不存在的功能",程序当场崩溃，没有任何中间地带。对话可以容忍模糊，调用只认精确。

伯克利团队为了证明这事有多普遍，专门搭了个考场，叫 APIBench。他们从三大主流机器学习平台——TorchHub、TensorHub、HuggingFace——扒下来 1600 多个真实 API，做成一套标准化考题，让各家模型来答。

考试结果很说明问题：当时的 GPT-4、GPT-3.5 这些顶尖选手，在写 API 调用时，幻觉率高得感人，经常自信满满地拨打"空号"。

所以你看，Gorilla 要解决的不是一个锦上添花的问题，而是一个"卡脖子"的问题：大模型想从「会聊天」进化到「会干活」，第一道坎就是别瞎编 API。那它是怎么迈过这道坎的？这才是这只大猩猩真正的看家本领。

三、它凭什么比 GPT-4 还准？

先看结论，这个数字很硬核：在 APIBench 上，Gorilla 写 API 调用的准确率，比 GPT-4 高出 20.43%，比 GPT-3.5 高出 10.75%，而且在多个数据集上把幻觉率压到了接近于零。

一个基于 7B 小模型微调出来的东西，干翻了千亿参数的巨无霸。靠的不是更大力出奇迹，而是两个聪明的设计。

第一招：给它配一本「实时电话簿」

Gorilla 有两种工作模式：零样本（Zero-shot） 和 检索增强（Retrieval）。

零样本模式好理解：你直接问，它直接答，全靠肚子里背下来的知识。但 API 这东西有个要命的特点——它一直在变。今天这个参数还在，下个版本就废弃了。靠"背"是绝对跟不上的。

所以真正的杀手锏是检索模式。它的流程是这样的：

Gorilla 检索增强模式：先查实时文档，再生成调用

当你提出需求，检索器（可以是 BM25 这类经典算法，也可以是向量检索）先去文档库里捞出最新、最相关的那几页 API 说明书，把它和你的问题拼在一起，再喂给 Gorilla。

这就好比：你不让一个员工死记硬背全公司几千个分机号，而是给他一本随时更新的电话簿。号码改了？改电话簿就行，员工不用重新培训。API 一更新，换文档即可，模型不必重训。这是工程上极其务实的一步。

第二招：教它「别全信电话簿」

但这里藏着一个更深的坑，也是 Gorilla 最妙的地方。

检索器它也不是神，它也会出错，给你捞回来一页驴唇不对马嘴的文档。如果模型对检索结果照单全收，那等于被错误信息带着跑偏，反而更糟。

伯克利团队的解法，叫 检索感知训练（Retriever-Aware Training, RAT）。

核心思想一句话就能说透：在训练时，就故意让模型见识"检索回来的文档可能是错的"这种情况，逼它学会自己判断、自己甄别，而不是无脑信任。

insider 视角

RAT 的精髓，是把模型从一个"听话的执行者"训练成一个"带着脑子的执行者"。它知道塞进来的参考资料可能有水分，于是会结合自己的知识做交叉验证。这一招直接把检索带来的副作用摁住了，让"实时文档"的好处真正落了地——既跟得上 API 变化，又不被错误文档带沟里。

讲到这你可能会想到 RAG（检索增强生成）。没错，思路是相通的。但 Gorilla 把它从"聊天问答"场景，搬到了"精确代码生成"这个容错率为零的硬骨头上，还专门加了 RAT 来对抗检索噪声。同样是开卷考试，普通 RAG 是抄到啥写啥，Gorilla 是抄之前先掂量这答案靠不靠谱。

方法很漂亮。但一个停留在论文里的方法，影响不了行业。Gorilla 真正改变游戏规则的，是它把这套东西做成了一条完整的、能用的产品线。

四、从 Gorilla 到 OpenFunctions：一条产品线长什么样？

初代 Gorilla 证明了路子是对的，但它只覆盖三个 ML 平台的 API，还比较"学术"。真正让它走向实用的，是后续两个东西：OpenFunctions 模型 和 BFCL 排行榜。

OpenFunctions：一个能打的开源「函数调用专家」

最新的 Gorilla OpenFunctions-v2，是一个 69.1 亿参数（6.91B）的开源模型，基座换成了代码能力更强的 DeepSeek-Coder-7B。它已经不是当年那个偏科生了，能力相当全面：

并行调用：一句话里要做三件事，它能一次性吐出三个函数调用，不用来回三轮。
多函数选择：给它一堆工具，它能挑出该用的那个（或那几个）。
多语言支持：不只 Python，Java、JavaScript、REST API 都能写。
相关性检测：这点特别关键——当你给的工具没有一个能解决问题时，它会老实说"这活我手头的工具干不了",而不是硬凑一个调用糊弄你。

就这一身本事，官方评测里它的表现已经能和 GPT-4 掰手腕。一个开源、可商用、参数量小到能在自己机器上跑的模型，做到这个程度，对开发者意味着什么，不用我多说。

踩坑记录

很多人第一次用函数调用模型，最容易栽在"它从不说不"上：明明工具箱里没有合适的工具，模型还是硬要编一个调用出来。OpenFunctions-v2 的"相关性检测"就是专门治这个的。选型时，一定要测一下「无解场景」——给它一个现有工具都满足不了的请求，看它会不会老实拒绝。会拒绝的，才是能放进生产环境的。

BFCL：工具调用界的「高考阅卷标准」

如果说 OpenFunctions 是选手，那 BFCL（Berkeley Function-Calling Leaderboard，伯克利函数调用排行榜） 就是这个赛道的裁判和考场。

这是业界第一个系统性评估"大模型工具调用能力"的公开榜单，几乎所有主流模型——GPT、Claude、Gemini、各种开源模型——都在上面排队比分。它的价值，是给了一个混沌的领域一把统一的尺子。

更难得的是它一直在进化。最新的 BFCL v3，已经不满足于考"单次调用准不准"了，而是上了真正的硬菜——多轮、多步的 Agent 场景：

考察维度	它在测什么	为什么难
多轮交互	跨越好几轮对话完成一个任务	要记住上下文状态，不能失忆
缺失参数	信息不全时，主动反问用户	要会"承认不知道"并追问
缺失函数	没有工具能干这活时如何应对	要敢于说"做不到"
长上下文	在海量信息里精准定位该调的工具	容易被无关信息淹没

评判方式也很硬：既用 抽象语法树（AST）匹配 检查你写的调用语法对不对，又真的把代码跑一遍看结果对不对，甚至检查执行后整个系统的"状态"变没变对。覆盖了车辆控制、交易机器人、旅行预订、文件系统操作等上千个真实场景。

这就把"工具调用"这件事，从"看起来对"逼到了"真的能跑通"。BFCL 的真正贡献，不是评了谁第一，而是定义了「什么叫调用对了」。

可是，就算模型把调用写得百分百正确，故事就结束了吗？远没有。因为"写对"和"敢让它真的去执行"，中间还隔着一条最危险的鸿沟。

五、调用对了，就万事大吉了吗？

设想一个场景：你让 Agent "把这个项目里没用的旧文件清理一下"。它非常准确地生成了一条 rm -rf 命令——语法完美，BFCL 满分。然后它执行了。然后你发现它把不该删的也删了。

你看，调用的"正确性"和执行的"安全性",是两码事。模型可以保证前者，但保证不了后者。

Gorilla 团队显然想到了这一层，于是又做了一个叫 GoEx（Gorilla Execution Engine） 的运行时框架，专门管"安全执行"这件事。它的设计理念，特别值得每个做 Agent 的人琢磨：

撤销（Undo）：执行前先想好退路，万一错了能一键回滚，就像文档的 Ctrl+Z。
损害隔离（Damage Confinement）：把 AI 的行动关进一个"沙盒"里，就算它闯祸，破坏范围也被死死圈住，溢不出来。
最小权限：动态判断这次任务到底需要多大权限，绝不多给一分。
事后验证：允许你在动作执行之后再去核对结果，发现不对就撤销。

对比一下

传统软件的逻辑是"先审批，后执行"——人确认无误了才放行。但 Agent 时代行动是 AI 自主发起的、量大又快，事事人工审批根本扛不住。GoEx 的思路是换一个安全模型：与其纠结「能不能让它做」，不如保证「做错了能撤回、能兜住」。把防线从"事前拦截"挪到了"事后兜底"，这是 Agent 安全范式上一个很重要的转向。

从精准调用（Gorilla）、到统一评测（BFCL）、再到安全执行（GoEx），你会发现伯克利这帮人想的根本不是"做一个模型",而是为「大模型操作真实世界」这件事，铺一整条从能力到安全的完整轨道。这个格局，才是 Gorilla 项目最值钱的地方。

六、它给整个行业留下了什么？

聊到这，我们回头看那个朋友最初的误会，其实已经不重要了。是不是 Meta 做的不重要，重要的是 Gorilla 这个项目，给整个 AI Agent 行业立了几根桩子：

它第一个证明了：小模型 + 巧方法，能在工具调用这件专门的事上，干翻通用大模型。专精，是有价值的。
它给出了一套方法论：检索增强（实时文档）+ 检索感知训练（RAT，别全信文档），这套组合拳至今仍是函数调用的主流思路。
它定义了游戏规则：BFCL 成了工具调用能力的"高考",一把人人都认的尺子。
它把视野拉到了安全：GoEx 提醒所有人，调用对只是起点，敢执行才是终点。

我的看法：Gorilla 真正的历史地位，不在于它今天是不是榜单第一（这个赛道早已挤满了更强的选手），而在于它在 2023 年就清晰地喊出了一句话——大模型的下一站，是从「会说」到「会做」。今天满天飞的 MCP、Agent、工具生态，本质上都是在这条路上接力。Gorilla，是那个起跑发令枪。

所以我斗胆下两个判断，给自己设个 deadline：

判断一：到 2027 年，"函数调用准确率"会和"上下文长度"一样，成为每个新模型发布时必报的核心指标，而不再是一个小众评测。

判断二：GoEx 所代表的"事后撤销 + 损害隔离"安全范式，会在两年内成为主流 Agent 框架的标配能力——因为当 AI 真的开始大规模操作真实世界，"能不能兜底"会比"够不够聪明"更要命。

到时候回来看看，我说得对不对。

下一步建议：

去 BFCL 排行榜上看一眼你正在用的模型，排第几、弱在哪一类（多轮？相关性检测？），心里就有数了。
下次给 Agent 设计工具时，专门构造一个"现有工具都解决不了"的请求去测它——会老实拒绝的模型，才敢放进生产。