Function Calling为何能让2024年成为大模型应用元年？

OSCHINA

↑点击蓝字 关注我们

不知你是否听过这么一个说法：2023 年是大模型技术的元年，2024 年是大模型应用的元年。

为什么大模型产业应用爆发是在 2024 年？

广东智用人工智能研究院 CTO 张善友认为，一切的关键就在于 Function Calling（函数调用）机制的出现。该机制使得大模型可以有效地与外部 API 结合起来，让大模型技术加速落地。

那么，Function Calling 机制是什么，为何会有这么大的能力？

Function Calling 机制诞生背后

我们所经常提到的大模型，如 OpenAI 的 GPT-4、智谱 AI 的 GLM4，都属于预训练大模型。所谓预训练，就是提前训练好的模型。这也意味着，大模型所拥有的知识是基于其训练数据的时间范围。

比如今年 2 月更新的 GPT-4-0125-preview，其训练数据来源截止在 2023 年 12 月，那么 2024 年发生的事情它就不知道。它甚至无法获知现在的时间。

如果大模型需要具备访问实时数据的能力，就必须接入外部信息源，比如通过 API 调用等方式来获取最新信息。

在 2023 年 6 月 13 日之前，大模型本身并没有调用外部函数的能力，开发 AI 应用通常需要依赖特定的框架或平台 —— Semantic Kernel 或 Langchain 来实现执行互联网搜索或调用外部 API。

在这个过程中，设计提示词是关键的一环。开发者需要利用 Semantic Kernel 、Langchain 等大模型应用开发框架，从自然语言中通过提示词提取实体，转换成 JSON 结构，以实现将非结构化数据转换成结构化数据。

然而，由于每个人编写的提示词都是按照自己的结构来的，所以无法实现标准化，准确率会大打折扣。

还有一种方式，就是利用插件功能。在 GPT 的发展历程中，尤其是在 GPT-3 及其后续版本中，OpenAI 引入了插件功能，这与早期 GPT 版本有所不同 。早期的 GPT-2 模型，主要专注于通过无监督学习提高自然语言处理能力，而没有实现与外部系统的交互或插件系统。

插件的设计理念与目前 GPT 模型中使用的 Function Calling 有某些共通之处，但两者在实现方式和功能上有所不同。

用户可以访问 ChatGPT 插件商店，通过搭配不同的插件来增强 GPT 的功能。然而，由于同时使用的插件数量受限 —— 在同一时间最多只能激活和使用三个插件，用户无法构建具有一定复杂性和强大功能的 AI 应用。最终，插件商店在今年 4 月被废弃。

张善友认为，插件功能失败的原因在于其设计存在几个关键缺陷：首先，缺乏有效的 Agent（智能体）调度机制，导致用户只能手动选择有限数量的插件，限制了功能的灵活性和扩展性；其次，它无法为特定场景提供完整的端到端解决方案，影响了用户体验和解决问题的效率；最后，由于需要多次与 GPT 进行交互，导致整体响应延迟高，使得插件在实际应用中的性能表现不佳。

取代 ChatGPT 插件的，是一种让使用者能够量身打造自己的 AI 助理的工具 ——GPTs。GPTs 使用 Function Calling 来增强模型的能力。

Function Calling 机制是在 2023 年 6 月 13 日，随着 OpenAI 的 GPT 大模型的更新发布而为人所知的。

Function Calling 机制，带来了什么优势？

在 Function Calling 机制刚出现的时候，网上有一种论调：Langchain 要废了。张善友认为，这个说法可能有些夸张。

在 AI 应用开发过程中，Langchain 的作用是将大模型与外部工具（如 API、数据库等）连接起来，使得大模型能够利用这些工具的能力来增强其自身的功能。说白了，Langchain 只是充当了中介的角色。

Function Calling 则是让 AI 应用开发变得更加容易。大模型可以直接和外部 API 或函数结合起来，执行特定的任务，如获取实时数据、执行计算等。

好处是显而易见的。“以前，将一段话提取成 JSON 结构时，常常会出现缺少字段的情况。但如果使用 函数调用，大型模型内部会处理这些细节，从而大幅提高准确率。” 张善友表示。

以 GPT-4 与 Semantic Kernel 的交互为例，来看看引入函数调用机制之后，二者之间的交互流程是如何优化的。

带了另一大优势是，API 标准化与准确率提升。Function Calling 机制促使开发者按照一定的标准来定义和调用函数，从而提高了 API 的标准化程度。

许多大型模型应用开发公司在早期阶段，都会自行定义各种接口，而如今都在向 OpenAI 的接口标准靠拢。当然，它们之间仍存在一些差异。

“ Function Calling 可以使得提示词的标准化、结构化。因此 Function Calling 机制在很大程度上推动了大量 Agent 框架的流行。“张善友表示，从 2023 年年底至今，大家谈论大模型的话题基本都围绕着 Agent 和 Function Calling 进行 。

有了 Function Calling，能做什么？

张善友认为，目前真正能够将大模型用于生产环境中的 AI 应用还相对较少。即使有，其执行结果也往往不尽人意。正因如此，需要让 Agent 参与进来发挥作用。如果模型生成的内容可能只有 70 分，但通过人的参与和提升，可以轻松将其完善到 100 分。

在这一逻辑之下，张善友带领团队，用了一年左右的时间，开发了属于自己的 AI 智能体产品 ——Agent Foundry。

Agent Foundry 是一个 AI 应用开发的通用平台，能将开发工作流程标准化，使得原本难以完成的 AI 应用开发变得容易。

“我们采用了一种前后端分离的设计，前端负责用户界面（UI）体验，比如聊天区、展示区和编辑区，而后端则负责处理 API 请求。” 张善友表示，这种设计提供了一种新颖的交互方式，不论在国内还是国外都是首次出现。

其中，Agent 是最核心的部分，它主要负责功能调用。

” 一个应用可能包含多个 Agent ，每个 Agent 代表一个用户故事，可以包含多个子任务。这些 Agent 之间存在一定的关系，形成关系网，使得我们可以清晰地看到每个部分的作用。以前，产品经理要先写需求文档，开发人员根据文档来开发，最终结果还可能与预期不符。现在，我们可以将这些需求直接转化为语义代码，通过提示词来明确场景，使得开发过程更加直观和高效。” 张善友解释。

每个后台操作都有一个对应的 Agent 来处理。在这个过程中，大模型的 Function Calling 机制起到了关键作用。

在传统编程中， Function Calling 是一个常见操作。它通常是硬编码在程序中的，比如调用一个接口，参数可能是从用户界面直接获取的，例如通过菜单点击操作。

在 Agent Foundry 的聊天会话界面中，调用一个函数时无需传统的点击操作，仅通过聊天内容就能获取所需的参数，并指示系统执行 Function Calling 。

可以说，大模型的 Function Calling ，就是对传统的 Function Calling 方式的扩展，让计算机程序能够更加有效地利用大模型。

对张善友及其团队而言，提示工程仍然是最主要的。

最近，智用研究院与深圳市工业设计行业协会合作，基于 Agent Foundry 开发了 AI 工业设计平台 —— 灵鹿未来，并已正式上线。灵鹿未来有二十多个 Agent，每个 Agent 都有自己的提示词。提示词在代码中所占的比例超过一半。

” 这些操作实际上仍然是基于传统的函数接口调用方法，这一点并没有变化。在该平台中，对象模型、系统提示词、调用方法等都是通过 JSON 文本来描述的。这种方式结合了语义编程和语法编程，进行封装之后，可以转化为低代码开发方式。” 张善友表示。

在灵鹿未来上，用户通过简单的聊天对话就能设计出所需的工业产品。

“灵鹿未来的聊天区，实际上是一个多功能的工作台。这是国内首创，也是我们的一个创新点。” 张善友表示。

灵鹿未来能够大幅缩短产品设计的流程，原本需要委托设计公司完成的工作，现在可以由用户自行完成，并且设计完成后还能生成产品图片，最终用于生产。智用研究院将这一完整流程称为设计 BOM。

设计 BOM 不过是该系列产品的前端环节。据张善友透露，智用研究院精心规划了一套面向制造业全流程的创新产品，命名为 “AI BOM”。这一系列产品旨在为制造业带来智能化升级，提升生产效率和产品质量。

“AI BOM 是独一无二的，因为它覆盖了制造业全流程。目前只有我们团队在进行这项工作。” 张善友透露，他们正在将每个应用场景转化为开发包（SDK），使其能够在类似应用商店这样的平台进行管理。

Agent Foundry 的 诞生与 AI BOM 密切相关。为了开发 AI-BOM，张善友及其团队需要构建一个开发框架，类似于之前的微服务框架。Agent Foundry 就是基于大模型的应用开发框架。

目前，Agent Foundry 仍处于打磨阶段，主要供智用研究院自己使用，以赋能更多 AI 应用落地。

智用研究院的野心不止于此。张善友透露，AI BOM 包含了许多模块，除了正在开发的设计模块，未来还将包括生产、制造、服务、市场等模块，每个模块都可以独立开发并在平台上扩展。他们的目标是要打造面向整个制造业流程的 AI 平台。

“唯有 OpenAI 的 Function Calling 结果准确率达到 100%”

张善友认为，Function Calling 机制可以视为大模型的一种能力，这已经成为了事实上的标准。

为什么这么说？因为调用结果的准确率，代表了模型的推理能力是否强大。张善友表示，国外以 GPT 为代表的大模型率先实现了 Function Calling 机制，国内的大模型迅速跟进，现在几乎已经支持这一功能。尽管去年这一数量还寥寥无几。

不过，尽管当前市场上虽然有很多大模型可供选择，但唯有 OpenAI 的函数调用结果准确率达到 100%。

例如，当询问天气时，理想情况下，模型应该解析并触发平台内的 Function Calling，用并返回答案。但是，很多国内大模型有时候返回的是一段提示需要调用工具的文本。

张善友表示，这就是准确度问题，有时候大模型能够正确响应，有时候则不能。事实上，国内很少有大模型的 Function Calling 准确率能达到 90% 以上，有的甚至低至 20%，因此很难用于实际生产中。

而在几个月前，OpenAI 将 Function Calling 的准确率从 40% 提升到了 100%。"如果国内模型能够将准确率提高到 90% 的水平，那么对于 AI 应用场景落地将非常有帮助。" 张善友补充道。

为了应对这一挑战，张善友在 Agent Foundry 平台上制定了一套新的 API 标准。

他指出，应用场景通常非常复杂，不可能仅通过调用一个函数来解决。如果盲目地将所有函数交给大模型，它可能无法有效处理这些信息。因此，他们采用 Agent 来指导大模型，对在特定场景下使用哪些函数，以及哪些信息需要传递给模型做出决定。

“模型本身是无状态的，能够根据提供的数据推理出所需的函数调用参数，再利用这些参数来调用外部接口。外部接口返回的结果可能需要再次反馈给模型，以便生成自然语言回复，或者我们可能会在内部调用其他接口以进一步处理。”

“由于每个模型在接口上可能有差异，频繁调用可能导致结果并不准确。” 张善友解释说。“因此，我们参考 OpenAI 的标准，在 Agent Foundry 平台上定义了一个统一的标准，将所有模型整合到这套标准之下。这样，我们就能轻松地与每个模型进行对接。在系统后端，我们可以根据需求更换模型，选择更适合的、能力更强的模型来使用。”

事实上，如何提高 Agent Foundry 平台能力是张善友一直在思考的事情。此前，为了解决多个代理之间需要进行大量协调和推理工作的问题，就只能自己写代码实现 Function Calling 。但是这一方式准确率较低。而如今 Function Calling 转移到到模型内部之后，准确率已经大幅提高。

他想，目前复杂的推理多是由 Agent 来执行的，如果将这些功能转移到模型内部，类似于 OpenAI 的 O1 模型，那么开发 Agent 将会更加简单。”OpenAI 的 O1 模型为我们指明了一个方向，从模型的角度来看，是一个重大的进步。”

END

↓ 分享、 在看与 点赞~ Orz