开发者正确开启 GPT 的钥匙

上篇文章我写了自己用 GPT 处理输入生成更漂亮的 Stable Diffusion 的 prompt,有几个人留言嘲讽 GPT,我拉黑了事。最近似乎用 GPT 的人多了,各种拿着 GPT 失误的回答进行无脑嘲讽的人就越来越多。我不知道这种嘲讽是出于什么心理,是对新技术的不屑,还是对未来的恐慌?GPT 作为一个新生事物,尽管它已经“进化” 到相当”智能”的地步,失误,犯错也是在所难免。有必要揪着它数学计算的不完善,或者在某些问题上一本正经地胡说八道不放,就一杆子打死么?
我能理解非技术人员把 GPT 仅仅当作一个玩具,玩厌了或者遇到问题了就把这家伙当成 “言过其实” 的绣花枕头;但技术人员这么做,大概率是还没有找到正确开启 GPT 的钥匙。

GPT 聊天能力之外的「超能力」

聊天问答,其实是 GPT 的最浅层能力。对于程序员而言,GPT 最有价值的能力是其「自然语言编程能力」,或者说 “prompt engineering”。我们可以充分利用这种能力,在 GPT 上「编程」,来解决特定的需求。在具体开始编程时前,我觉得有必要聊聊 GPT 或者说 GPT-3 之后,突然涌现出来三个非常有价值的,只有生物甚至高等生物才具备的能力:
  • 大范围理解抽象指令的能力:任意给定一个抽象的指令,比如 “翻译”,或者 “生成数据库迁移脚本”,他可以正确执行
  • 理解例子的能力:给定一个或者多个例子,让他按相同的规律执行。如果你不知道该如何给 GPT 合适的指令,那么可以通过给它足够多的例子(一般一两个即可),让它举一反三。
  • 对复杂问题进行分治的能力:对于一个复杂问题,如果要求 GPT 分布思考,一步步给出答案,那么他做对的可能性非常高。
GPT 理解指令的能力大家可能觉得并不稀奇,你的 alexa 也可以理解一些指令。但 GPT 厉害之处在于,它能理解的指令几乎涵盖人类活动的所有领域,无论多么冷门。
GPT 理解例子的能力让人拍案叫绝,有时候我感觉它真的像一个有智慧的生物。之前的人工智能产品没有这个能力,因而它们只能处理特定领域的问题,而 GPT 的学习例子的能力,则是一种非常通用的能力,GPT 作为基础模型,加上我们精心准备的例子,就好像 GPT 通过学习,临时构建了一个新的,解决特定问题的模型,这是非常了不起的。
对复杂问题的分治能力,也是 GPT 让人感到惊艳的地方。有时候复杂的问题,你只是要求它一步一步推理,每步都给出中间过程,它就能给出更好的结果。这就跟我要求我们家小宝做数学详细写解题步骤,她做对的概率就大大提高一样。

如何使用 GPT 这种「超能力」

如果你对 GPT 涌现出的上述能力感到兴奋,那么,你完全(暂时)不用写一行代码,就把你的 GPT 按照特定需求,打造成一个个你的专属的机器人或者助手。以下是我自己的 GPT 主要助手,有陪我聊天的(随心聊 – 常规操作),有帮我对网上文章做内容梗概的(内容梗概助手),有做中英文翻译的(翻译助手),还有帮我写 Stable Diffusion prompt 的(SD 助手)。我还在尝试用 GPT 打造一个纯虚拟的 postgres 学习环境,用户在这里就像面对一台真实的 PG 服务器,就是想看它能力的边界在哪里(事实上,相当惊艳啊,我可以虚拟创建表,添加数据,查询,更新,然后查询到的数据是更新后的):
以内容梗概助手为例。有时候 hacker news 上的文章内容太长我不愿意看,或者我就想了解个大概,就可以把文章贴到这里,然后它自动帮我 summary,打 tag,描述文章的情绪,甚至帮我写三条情绪积极,中立,消极的评论,以 YAML 返回(以下是一篇关于 Trump 被刑事指控的英文新闻的 summary):
好,既然大家看了这么多例子,是不是也摩拳擦掌准备试试呢?既然大家都是开发者,那么我就放一个我晚上突然灵光一动,写的比较硬核的 migration-bot,供大家参考。这个 bot 的灵感来源于我今年年初 hackathon 做的 renovate,一个自动化生成数据库迁移脚本的工具。我在 renovate 上花了四天几乎不休少眠的日夜,写下了两千多行代码。今晚我开完一个短会突然想:如果用 renovate 的思想让 GPT 做数据库迁移,是不是可行呢?于是我花了大约15分钟写下了如下规则和例子:
一个基本功能完备的 migration bot 就完成了。不太客气地说,我觉得我算是一个相当不错的程序员,四天使出吃奶的力写两千行 Rust 代码,做完一个基本可用的产品,算是相当高效了。然而,使用 GPT,我可以 15 分钟风轻云淡地把需求一描述,最简单的例子一给,就完成一个类似的 POC,这种几个数量级的效率的碾压让我自己都一身冷汗。你可以看看我给的例子,那是青铜级别以下的,简单到不能简单的例子。而我喂给 GPT 的 current schema,是我直接 pg_dump 出来的,我之前 bilibili 做 reservation 系统讲座的数据库,有四百多行 SQL(以下截图不全),相对于我的例子,妥妥王者级别的数据:
但 GPT 完全能够理解这些 SQL,并以其作为 base schema,开始帮我计算 migration 脚本:
这些都是小打小闹,我的 renovate 也能很好支持,似乎不足为奇。接下来这个就厉害了:
这是 renovate 没有,也无法支持的能力。毕竟 renovate 无法理解自然语言,也就无法做这种 migration 的需求。
最后这个结果就完全出乎我的意料,并让我大呼「我擦」:
renovate 那个项目我之所以放在一边停了很久,就是因为如果某些数据库改动是破坏性更新,那么你仅仅是给出迁移的脚本还不够,你要考虑这种 schema 的更改是否安全。一个单纯是由规则建立的工具(代码其实就是给定的规则)很难完全捕获各种潜在的风险,因而在 renovate 中,这些可能引发破坏性更新的迁移,我一律不支持了事,这就使得工具的实用性大打折扣。现在,通过 GPT,起码,我得到了一个看上去非常靠谱的迁移脚本(我并未验证)。
如果你再回过头去看我为 migration-bot 撰写的规则和例子,它们相对代码而言要「模糊」得多,简单得多,且很多东西还欠考虑。但 GPT 以它自己「读万卷书,阅千人事」的超大规模知识和经验,顺利地理解了我的需求,还很好地理解了我的隐含需求。
© 版权声明
THE END
喜欢就支持一下吧
点赞13 分享
评论 抢沙发
头像
欢迎您留下宝贵的见解!
提交
头像

昵称

取消
昵称表情代码图片

    暂无评论内容