这两天有点沉迷ChatGPT.
固然一方面有被impressed到.
但另一方面更多的是一种好奇或者说怀疑.
毕竟原则上来说,对目前给予统计概率的AI还是比较不太容易有好感的.
虽然说从工程或者说实用主义角度出发的话,确实是一个容易有比较promising结果的一个方向.
但至少以人类理性/逻辑的尊严或者自负来说,还是希望有能够符合直接的reasoning过程的方案出现的.
回到ChatGPT本身.
官方的卖点一开始也是code generation.
至于其他的,可能还算是GPT系列的固有技能.
所以这几天也着重在玩这方面的.
开始是spell了一个爬取网页内容的脚本描述.
很自然地generate出了基于beautifulsoup的脚本.
然后附加了一些instrument也支持了script的解析和结果变量提取,以及随后的结构化数据处理和存储.
最后还支持脚本参数化命令行.
从结果上来说,还是比较惊艳的.
更意外的是instruct它把python version port到javascript的话,结果也是相当让人满意的.
这里就不仅涉及到语言之间的对等翻译,还涉及到对应库功能的替换和重写.
毕竟两种语言的风格和支持库的用法是不一样的.
所以如果说是符合人类直觉的翻译过程的话,出了procedure的对等变换之外,还有合适的库的选型以保证风格/结构上面的大致对称.
当然,还有另外一种方式是根据初始的spell替换一个上下文语言约束重新生成.
这种方式的话就相对简单多了.
后来想想的话,也确实是这种方式的generator比较合理.
但是对问题的理解和到合适代码生成这个task的过程还是让人眼前一亮的.
猜测的大致模型是语义的annotation组成一个knowledge graph的embed结构,然后有一些基本的infer规则匹配.
一个例子就是别人的一些诸如星期几的简单演算问题.
encode之后的形式化结构的逻辑表现形式可能类似于一个属性结构,推算就变成了相邻子树/层级之间的模式匹配问题了.
比如从周三开始连上七天班之后是周几这样的问题.
平行结构就是天数和对应的quality(天)的同态模式匹配/infer问题.
不过具体到这个特定问题还有个意外惊艳就是考虑到周六日这种特殊情况.
想想,可能也正常.
这两个节点可能有相应的negative的signal/attribute.
另外一种实现方式可能是服用code generator的方式.
把自然语言translate成用于code generator的instrument结构,然后生成在翻译成自然语言.
这个方式的话倒是打开了这类概率模型发展的一个新思路.
毕竟之前诟病的就是可解释性问题.
如果转成这类IR之后,以程序/图灵机的方式做推理演算,那之后IR之后的部分是acceptable/比较让人舒适/愉悦的一个方向的.
这样的就对后半部分的可解释问题没什么疑问了.
而且能够解决相当一部分问题.
只要给出了相应的数学约束就行了.
剩下的就是常规的程序演算问题.
如果是这个方向的话,倒是对ChatGPT有一些好感了.
然后就是试着用这个思路去套它本身的实现机制.
但估计是设置一些伦理道德限制.
就像那些毁灭世界问题意义,对于自身的一些回答都是相对固定的模版.
尤其是涉及到上下文内容推理的部分.
虽然conversation本身就已经代表了有上下文,但生成的回答里还是明确否定了这点.
所以在话术这方面,可能还是不太容易有突破的.
然后回到code generator的部分去尝试.
使用的spell是最近在做的一个关于kafka proxy相关的描述.
再给出初始的sketch描述之后,出来的是一个consumer poll topic然后producer send record的模型.
一步步纠正确实生成了一个server accept client request and forward的看上去能work的代码.
提出optimize要求之后,还能做一些常规的诸如异步/多线程/reuse方面的重写.
refactor和inline指令也能正确地apply过去.
甚至于指定用kafka library替换原生的socket selector处理IO的部分也能正确地重构出来.
到这里可以算是非常令人震惊了.
看上去真是的是指导/结对编程的感觉.
但是仔细想想,可能也不是不能理解.
因为优化和inline/refactor之类的,算是现代language server/ide/linter常见的功能.
本质上来说,也是一种模式/规则匹配.
对一个动不动百亿千亿参数的模型来说,这个反而可能不算什么.
毕竟只是关于训练集的fine tune而已.
不过从应用场景上来说,倒是挺适合做compiler的optimize建议的.
尤其是在模式识别方面.
可能会带来一些新的突破,尤其是offline profile方面.
online/jit的话, 可能就不太现实了,一个是程序本身的性能损耗/采集,一个是模型本身的算力需求.
不太可能像gc一样做到runtime里面去.
至少以目前的技术架构来说还是挺不现实的.
剩下的就还是老问题.
库相关的等价替换实现/重构是怎么做到的.
按照IR的思路的话,还有一个问题就是kickstart/bootstrap的问题.
也就是IR本身怎么到生成合适的代码的.
重新spell了一个生成socks5 proxy的例子.
然后意外地看到了一些熟悉的代码模式.
然后就有些豁然开朗的感觉.
直觉上是类似于copilot的方式,代码库作为语料.
然后跟text2image之类的一样,结合相关的自然语言描述,比如注释和readme,以及相关的project knowledge graph entity等一起做training出来的embed.
这样的话,生成就还是回归GPT的概率模型了.
需要fine tune的部分可能就是code block的attention之类的.
因为从使用经验来说,ChatGPT是可以指定特定局部代码重写.
前提是你能引导/recall指向到意图的那一段.
这样的话,ChatGPT说自己并不具有逻辑推理能力的话倒确实不一定是safe guard.
本质可能还是特定领域的GPT模型fine tune.
不过这里引申出来比较有意思的是关于一开始的impression方面的.
如果只是概率模型的话,那么这种一开始看上去是有逻辑推理过程的结果反映的一个事实是,目前的信息丰富程度需要用另一种角度去看待了.
也就说,可能并没有什么想法/东西是新的.
所有一般人能想到/问出来的,在这个世界上已经存在语料中了.
所以GPT才能generate出来这些看似有逻辑的内容.
而对于像Google最初的索引一切的理念来说,需要revise的就是索引的定义.
或者说现在对于搜索这个需求的定义是什么.
是特定内容关键字的匹配.
还是说特定intension的识别匹配.
前者最多还是逃离不开语句结构本身.
后者则是借助于猴子写的莎士比亚做的伪逻辑inference.
刚好这两天三体动画版开播了.
用智子的话说,就是人类实际可能已经nothing new了.
