前阵子GPT的模型和API更新了,应该开发者们都收到了这个邮件:
它大致的意思可以归纳为:
2、3、4点基本是在做“降本增效”,功能性的更新主要就是第1点了(附上官方的专题介绍页):
https://openai.com/blog/function-calling-and-other-api-updates
这个function call功能意义还是挺大的,它解决的问题是:让GPT智能调用API接口或现成方法,这个会带来一些架构设计思路的转变,所以特意写篇文章解读一下。
基于这个功能,我动手做了个demo,实现了一个不大一样的AI助理(能智能调度第三方接口),大家可以先从大体上感知一下它的作用:
PC Chrome体验地址:
https://aiquickhelp.com/gptFun (你需要填入一个可用openai apikey 方可使用)
已开源:
https://github.com/minijoe/gptFun
----------华丽的分割线----------
简单的技术解读开始。
在这之前,我们先简单说说传统的应用开发逻辑。
一般开发者在设计完顶层架构后,就会根据架构需要去寻找或自研API和通用方法。
举个例子,比如我们要做一个“音乐检索和播放页面”,那么我们会先制定整个网页架构,然后去调度第三方音乐API接口实现数据获取,调用浏览器原生方法去实现音乐播放:
拿“搜索关键字来获取音乐列表”功能来举例,那么页面呈现是当前开发者实现的,但获取数据的能力可能是第三方接口提供的,当前开发者使用这些开放的第三方接口时,可能遵循的步骤是:
1.判断当前业务可产生什么业务参数(比如音乐检索页里,用户会主动输入搜索关键字,那么这些关键字就是业务自身可产生的参数)。
2.基于业务诉求和业务参数,做第三方接口选型(比如要实现音乐检索,那么就需要一个数据源接口,比如网易云音乐接口,再比如如果要做图中文字识别功能,那么就去腾讯云购买ocr接口服务)。
3.接着就需要把业务参数构建成第三方接口所需的参数格式,因为第三方接口都是按照既定的接口规范去暴露自身业务功能的,一般这些接口遵循“格式化后的参数输入”和“格式化后的结果输出”。
4.接着开发者会把这个接口调度的过程封装成自身业务代码组件,通常会形成通用方法,这样能快速内嵌到自身业务代码中。
简单表达下这个过程:
当然这是比较简单的应用层开发思路,更复杂的这里就不阐述了,基于这个背景,我们来看看GPT接口的新功能到底可以解决什么问题。
红框部分现在能直接交给他。这样说可能还是有点抽象,我结合一下文章开头的demo来录了个小解释(理解以下内容需要一点开发知识基础)。
视频:http://mpvideo.qpic.cn/0bc33uaaaaaaayaokseoifsfbxodadoqaaaa.f10002.mp4?
在这个功能出来之前,我其实就尝试过去实现这个中间层逻辑,当时的逻辑是给gpt定义动态prompt,比如同样要实现音乐检索,那么我会定义这样的prompt:
每次给Gpt发请求时,就依据这个模板构造一段新参数,Gpt就会按照我的要求去返回我需要的json格式,这时候我在开发侧就能做出“调度音乐接口”的决策。
具体体验方式可以访问:
https://aiquickhelp.com/
这是我一边学习AI一边研发的提升自身研发效率的工具,在Prompt Library的Community Prompts里可以选择“Music Player”进行体验。
也能勉强实现“智慧中间层”的逻辑,但这个逻辑下,Gpt本身还是有一定几率出现“幻觉”,他得到结果后在输出json格式化数据时,他偶尔就会出现一些奇怪的错误,比如把英文双引号换成了中文的(json解释时就会直接报错),有时候还会直接输出别的一些不相关的数据。
这种实现方式不是太稳定。
现在有了这个function call功能,相当于直接从官方底层去解决了这个问题,估计会影响深远。
可能会促使传统的应用层开发逻辑发生质的改变。
兴许,GPT作为开发者助理的同时,它会成为产品功能中标配的智慧核心,然后借助于原有的开放平台接口,它便拥有了各种触手,会进一步对传统行业进行渗透。
想象空间是很大的,但鉴于篇幅关系,今天就不聊那么多了。
感兴趣的同学多留言。
本文头图--MJ生成的