6月13日OpenAI最新博客突然发布了ChatGPT最新能力更新。重点如下:
一、新功能:函数调用
可以理解为将ChatGPT官网网页端的插件模式,移植到了OpenAI-API上,每个函数相当于原来ChatGPT-Plugin。第三方可以基于这套能力自行实现公司/团队内部的插件平台。
如何使用函数调用
以官网的天气查询为例子How_to_call_functions_with_chat_models,一步步讲解:
图片来源: twitter@ProgramerJohann
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。
2、dify支持新模型
functionCalling这套最合适的场景是流程编排,像flowise、dify、影刀这些做LLMOPs的公司团队应该已经在接了~~ 😄
关于LLMOPs,之前简单收集了业界一些实践,供参考:AI逻辑编排 LLMOPs
四、补充
在实际接入过程中我们也遇到一些问题,记录如下:
- functions参数是要算tokens的,因为OpenAI的处理是把它拼接在systemMessage之后
- 函数调用偶尔会出现幻觉:返回不存在的函数名
- 函数调用返回的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”