0615作者更新：补充了一些函数调用接入的注意事项（见文章末尾）

6月13日OpenAI最新博客突然发布了ChatGPT最新能力更新。重点如下：

可以理解为将ChatGPT官网网页端的插件模式，移植到了OpenAI-API上，每个函数相当于原来ChatGPT-Plugin。第三方可以基于这套能力自行实现公司/团队内部的插件平台。

以官网的天气查询为例子How_to_call_functions_with_chat_models，一步步讲解：

讯享网

在新API协议中新增了2个可选参数 functions 和 function_call

格式为Function[]，用于定义函数给到OpenAI_API，使GPT模型能够生成符合函数输入模式的输出。

请注意，OpenAI-API实际上不会执行任何函数调用。需要开发人员在客户端使用模型输出来执行函数调用。

每个 Function 包含如下字段:

• Name: 函数名
• Description: 函数功能的自然语言描述。模型将使用该描述来决定何时调用该函数
• Parameters: 函数参数对象的所有输入字段。这些输入可以是以下类型：字符串、数字、布尔值、对象、空值和任意类型。详细信息请参阅 API文档
• Required: 必须的参数，其余参数将被视为可选

格式为{ name: string }，指定调用的函数名。默认情况下，GPT模型将参考functions参数中每个函数的description 以及输入的message来决定使用其中的一个函数。你也可以通过将function_call参数设置为{“name”: “<insert-function-name>”}来强制API使用特定的函数。

如果GPT模型判断需要调用函数，或者通过function_call指定需要进行函数调用，则在返回中包含“finish_reason”:“function_call”（没有触发函数调用逻辑的话，此处返回finish_reason=stop），以及一个新增的function_call的对象，其中包括函数名称和生成的函数参数：

格式为{ name: 函数名, arguments: { …定义的参数 }}，告知客户端需要调用的函数以及入参

在得到函数名和函数调用所需参数后，我们需要在客户端（ChatGPT代理网关、VSCode插件等都可以认为是GPT的客户端）实现函数调用

在得到天气的结果“晴 温度2532摄氏度”后，需要将这个结果拼接到会话中，再次调用OpenAI-API得到最终的穿衣服知道建议

实现函数调用的gpt3.5和gpt4-8k、gpt4-32k，分别进行了升级：

• gpt-3.5-turbo 新增 gpt-3.5-turbo-16k 版本，除了支持函数调用外，上下文从4k到16k
• gp-t4-8k 新增 gpt-4-0613 版本，支持函数调用，上下文还是8k
• gpt-4-32k 新增 gpt-4-32k-0613 版本，支持函数调用，上下文还是32k

更新后，gpt-3.5-turbo-16k对所有用户开发。而拥有GPT4权限的账号，默认新增对应版本的GPT4模型权限，不用另外申请。并且在博客中提到，将在不久对所有账号开放所有GPT4模型。

更新后，gpt-3.5-turbo-16k支持16k的上下文，主要还是因为函数调用功能需要更长的上下文。其它场景也可以获益，16k可以支持20页文本了

参考下图，旧模型频限不变，新模型统一RPM3000，TPM，同样可以写申请扩容。

这次更新后，我的老 gpt-4-32k 模型权限似乎被删掉了，同样的也没有 gpt-4-32k-0613 模型，原因未知

GPT3.5模型：老gpt-3.5-turbo模型价格降低25%，新 gpt-3.5-turbo-16k模型价格是老模型2倍，总体来讲可接受。

GPT4模型：新老gpt-4的价格都不变 ‍♀️，依然是3.5的15-60倍左右.

在OpenAI官推发布更新的10分钟之内，Langchain立马宣布“已经在做兼容工作了”。特别强烈的求生欲，functionCalling这套的发布后，langchain里将近30%的代码可以删掉，直接用functionCalling模型，稳定性和标准型都大大提升

并且不到一个小时就发布了新版本，支持官方新功能之外，还可以把开发者已经写好的tools转换成OpenAI的functions。

https://twitter.com/hwchase17/status/

functionCalling这套最合适的场景是流程编排，像flowise、dify、影刀这些做LLMOPs的公司团队应该已经在接了~~

关于LLMOPs，之前简单收集了业界一些实践，供参考：AI逻辑编排 LLMOPs

在实际接入过程中我们也遇到一些问题，记录如下：

1. functions参数是要算tokens的，因为OpenAI的处理是把它拼接在systemMessage之后
2. 函数调用偶尔会出现幻觉：返回不存在的函数名
3. 函数调用返回的arguments并不能保证是标准的json（直接返回GPT输出，OpenAI不会帮忙校验是否标准JSON），客户端需要自己做容错处理

functions的参数会被拼接在systemMessage里处理，所以也是会计算token的。并且它会将functions里的关键信息解析出来，拼接成完成的字符串，以上面定义format参数为例：

# 原始json结构 “format”:{“type”:“string”,“enum”:[“celsius”,“fahrenheit”],“description”:“The temperature unit to use. Infer this from the users location.”}

提取关键信息后拼接的字符串

format,celsius,fahrenheit,The temperature unit to use. Infer this from the users location.

最终追加到systemMessage的内容，除了functions解析出来的文本，还有固定的提示词

讯享网[引导GPT识别处理函数的提示词，固定token长度，约24tokens] [functions解析的文本，字符串拼接后计算，不定tokens]

详细的计算方法，OpenAI没有公开，社区目前也没有研究出来，目前只能以这种方式大概预估

我们也尝试了OpenAI官方的CookBook指引: How_to_call_functions_with_chat_models。在设置location参数required后，似乎并没有返回content引导用户补充location信息，而是直接返回function-call，location参数确实有，只不过是参考Function中描述的例子，直接返回只是参数必定返回了原因未知

在官方案例中会返回content：

在例子中我们定义了一个非常宽泛的函数“Get”，GPT就出现了幻觉，返回的函数名是“python”