01 诞生背景

（本文主要参考b站up主 堂吉诃德拉曼查的英豪 的讲解视频）

在function calling出现之前，传统的大模型主要是聊天，无法与外部数据源交互（如通过API查询数据、查询用户文件等），也无法帮用户执行一些任务（例如发邮件、运行代码等）。

而这些事情是后端的强项，为了把这些能力纳入进来，人们想到了后端+LLM的方式。我们来简要看看是如何一步步走到function calling这个方案的。

02 最直观的实现方式有什么问题

先来看看上述方案最直观的实现方式。

以查询天气为例，up主提到如下的工作流程。当用户的问题来到后端的应用程序，该应用程序可以判断下当前问题会用到的工具，也就是用到哪个第三方API。然后再将工具的返回结果提供给大模型，大模型即可做出正确回答。

但这个方案会有两个问题。其一，后端应用是如何判断应该调用哪个API？或许我们可以使用正则表达式来识别，但终究是僵化、不准确的；其二，如何获取API的输入参数？可以使用字符串匹配的方式来解析，但同样是十分粗糙、不准确的。

而这两个场景，其实都是自然语言语义识别的范畴，都是大语言模型的强项。我们不如把这块工作交给大模型。这就是function calling思想的雏形。

03 Function Calling如何解决上述问题

3.1 Function Calling的基本概念

function calling指的是大模型能够调用外部工具的一种技术实现，其核心思想是：让大模型去告诉后端需要做的事情，然后由后端去完成调用，并把结果返回给大模型。

其具体的做法是：

• step1: 先向大模型提供可用函数的列表及说明
• step2: 大模型结合用户问题 1.判断是否调用，或具体调用什么函数 2.生成调用函数的参数
• step3: 然后大模型会返回函数调用的请求给后端

这就变相实现了让大模型调用外部的函数。

在这个过程中，比较重要的一个环节是第一步：如何给大模型传递可用函数的列表及说明

3.2 如何向大模型告知可用工具列表

一种是放在提示词里，一种是放在调用大模型时的参数里。（两张图的步骤1.2）

（1）方法一：放在提示词里

AI应用程序就是自己开发的一个应用程序，比如AI助手。它会向大模型的API发起调用，会带上系统提示词，提示词中会带着调用候选接口的信息。

不过，这种方案会存在问题。首先，可能会受限于模型能力，导致输出格式不稳定，以及出现幻觉，比如编造不存在的函数；其次，对开发者依赖度高，函数描述格式、调用指令格式都要由开发者设计；最后，这种方式的消耗token量大。

（2）方法二：放在调用大模型时的参数里

这个方法中，大模型提供商在模型内部与api层面做了一些支持，可以一定程度缓解上述提到的几个问题。

为了解决第一个问题，即模型能力的问题，大模型使用有监督微调、强化学习等方式让模型在选择函数、生成参数的准确性上有所提升。

同时该方法还在大模型API层面做了优化，例如GPT会提供一个function参数，使得在调用模型时，可以把函数信息（函数名称、用途说明、参数结构等）传递过去，并且开发者无需写系统提示词，这些都会由大模型提供商统一处理好。

这个方法也存在一些问题。其一，不同模型API传参的函数信息、返给后端的调用指令（函数名、参数）的格式不同，要适配不同模型的话就要重新开发一套；其二，不是所有的大模型提供商都会去投入精力做这么一套。