ChatGPT重磅更新，函数调用实战讲解

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

一、新功用：函数调用

能够理解为将ChatGPT官网网页端的插件模式，移植到了OpenAI-API上，每个函数相当于本来ChatGPT-Plugin。第三方能够基于这套才能自行完结公司/团队内部的插件渠道。

如何运用函数调用

以官网的气候查询为比如How_to_call_functions_with_chat_models，一步步解说：

1、新增参数

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

functions参数

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

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

每个 Function 包括如下字段:

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

function_call参数

格局为{ name: string }，指定调用的函数名。默许情况下，GPT模型将参阅functions参数中每个函数的description以及输入的message来决定运用其间的一个函数。你也能够经过将function_call参数设置为{"name": "<insert-function-name>"}来强制API运用特定的函数。

2、新增回来字段

假如GPT模型判别需求调用函数，或者经过function_call指定需求进行函数调用，则在回来中包括"finish_reason":"function_call"（没有触发函数调用逻辑的话，此处回来finish_reason=stop），以及一个新增的function_call的目标，其间包括函数名称和生成的函数参数：

function_call回来

格局为{ name: 函数名, arguments: { …界说的参数 }}，告知客户端需求调用的函数以及入参

3、完结函数调用

在得到函数名和函数调用所需参数后，咱们需求在客户端（ChatGPT署理网关、VSCode插件等都能够认为是GPT的客户端）完结函数调用

4、将成果追加到会话中，继续调用GPT得到终究成果

在得到气候的成果“晴 温度25~32摄氏度”后，需求将这个成果拼接到会话中，再次调用OpenAI-API得到终究的穿衣服知道建议

二、新模型

完结函数调用的gpt3.5和gpt4-8k、gpt4-32k，别离进行了升级：

• gpt-3.5-turbo 新增gpt-3.5-turbo-0613版别，支撑函数调用，上下文仍是4k
• 新增全新的 gpt-3.5-turbo-16k-0613 版别，除了支撑函数调用外，上下文从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，TPM250000，相同能够写请求扩容。

这次更新后，我的老 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倍左右.

三、社区反应

1、langchain支撑函数调用

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

并且不到一个小时就发布了新版别，支撑官方新功用之外，还能够把开发者现已写好的tools转换成OpenAI的functions。

twitter.com/hwchase17/s…

2、dify支撑新模型

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

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

四、弥补

在实践接入过程中咱们也遇到一些问题，记载如下：

1. functions参数是要算tokens的，由于OpenAI的处理是把它拼接在systemMessage之后
2. 函数调用偶然会呈现错觉：回来不存在的函数名
3. 函数调用回来的arguments并不能确保是规范的json（直接回来GPT输出，OpenAI不会帮忙校验是否规范JSON），客户端需求自己做容错处理

1、tokens核算规矩

核算回来tokens规矩（已确认）

加入functionCall才能后，回来的content是None，新的回来格局核算tokens规矩为：
将 function_call 中 name 和arguments 的值，拼接后作为本来的content来核算tokens长度

核算提示词tokens规矩（待定）

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没有揭露，社区现在也没有研究出来，现在只能以这种方法大概预估

2、函数调用required并不契合预期？

咱们也尝试了OpenAI官方的CookBook指引:How_to_call_functions_with_chat_models。在设置location参数required后，好像并没有回来content引导用户弥补location信息，而是直接回来function-call，location参数的确有，只不过是参阅Function中描绘的比如，直接回来只是参数必定回来了原因未知

在官方案例中会回来content：

3、偶然呈现“错觉”，回来不存在的函数名

在比如中咱们界说了一个十分广泛的函数“Get”，GPT就呈现了错觉，回来的函数名是“python”