Michael的笔记本

一、新功能：函数调用

可以理解为将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 : 必须的参数，其余参数将被视为可选

functions例子

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-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，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。

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

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”

原文 https://zhuanlan.zhihu.com/p/637122720