最近，我觉得这个世界变得越来越科幻。三个月前，我还认为GPT只是一个自媒体上的标题党，不过是一个跟人类可以对话的概率模型而已。但在过去一个月里，我深入探索了GPT的能力，并一次又一次被它的能力所震惊。然而它在很多领域的智能相当superficial，让我觉得它的价值仍然有限。所以我在应用中把它的角色定位成秘书，可以做一些文档整理或通过一些浅显的反问和挑战来增加我的思维深度和广度。 最近，一件事情让我改变了看法。因为产品的原因，我需要做一个文本编辑器，它不是通过用户操作键盘来交互，而是通过直接的自然语言对话来交互。例如，用户可以说在第三行后插入"今天天气真好"，或者用户说把第六行的内容替换为"今天天气真好"，它就会这么去做。这个文本编辑器最核心的难点并不是在如何编辑文本，而是在如何把人类的自然语言翻译成机器能理解的语言。这有点像英文到中文的翻译过程，需要非常深入的机器学习知识。如果是三个月前，凭借我有限的NLP经验，我可能会用一个基于BERT的机器翻译模型，生成大量训练数据，然后在昂贵的显卡上进行微调，最后部署到生产环境。这件事不仅需要机器学习的经验，而且需要实际的工程经验，因为BERT是一个很大的模型，跑起来很慢。如果我们不想让用户傻等的话，就需要做distillation，quantization之类各种复杂的工程优化。整个过程说一个星期都算往少了说的。 但是，GPT彻底颠覆了这一切。现在，我们完全不需要任何机器学习经验，只需要调用OpenAI的API，知道如何跟GPT说话就可以了。具体来说，我们需要向GPT描述这个任务。我跟它说的话（prompt）大致是这样的："请阅读以下文字，把它分类成下面三种情况的一种，并且输出相应的json。第一种情况是这个文字想表达的意思是退出草稿模式，在这种情况下你需要把intent这个域设成exit。第二种情况是用户想要在某一行的末尾插入一段话，那么你需要把intent设成append，把content设成这段话的内容，把line设成行号。第三种情况是如果用户想要把某一行改成他想要的内容，那么你需要把intent设成modify，content设成修改后的内容，line设成行号。"接下来，我给了它一些例子。然后它就可以完美地输出了！以前可能需要一周才能完成的事情，现在可能只需要十分钟，这是一个100倍甚至1000倍的加速。更重要的是，GPT不仅简化了开发流程，提高了开发效率，还降低了开发门槛。以前的工作可能需要一个硕士或博士，拥有丰富的工程经验才能在一周内把模型跑起来。但现在，任何一个人，哪怕是初中生，只要会描述这个问题，知道如何利用JSON格式，他就可以通过和GPT用中文自然语言说话来实现这个功能。 但这还没完，我们跟GPT说话的这个东西叫[prompt](/prompt-engineering-guide.html)，如何找到合适的prompt其实也是有讲究的。我这里把它描述成一个在三种情况里面选一种的分类问题，要求它用JSON格式进行输出，并给了它一些实际的例子。这些都是一些实践技巧，这么表达是最可能拿到想要的结果的。而这些技巧需要在日常工作中逐渐学习。所以，prompt engineering仍然是一种不能轻易被替代的能力。 有一个赛博套娃的观点是，既然GPT可以帮你[写代码](/ai-coding.html)、开发模型，为什么不能让GPT来帮你做prompt engineering呢？我最近在试用GitHub的一个copilot服务，它是一个基于GPT的智能自动补全服务，可以根据你目前打的代码猜你下面要干什么，然后给你自动补全大段的代码和注释。在我这里，我的prompt本质上是一个字符串，所以它是没有代码结构的，完全就是自然语言。但是当我打到第二点的时候，我打了个开头"修改之前的某一行"，然后copilot就帮我完全补全了第二点的整个内容，接下来我就按了tab接受了它的意见。 ![First auto complete of copilot.](https://yage.ai/images/copilot-1.png) 然后我在第三点打了一个"3."，它又把第三点给补出来了。这个特别可怕，也就是说，现在我通过经验积累的这些prompt engineering的技巧又完全没有用了。GPT不仅代替了我去开发模型，而且代替了我来做prompt engineering。那么，真正人类在这里所起到的作用就是跟它用中文把第一句话说出来，然后下面就只要按tab键就可以了。包括后面的例子，它都可以完全帮你补全。整个模型从头到尾我用花了两分钟。为什么是两分钟不是一分钟呢？是因为例子里面我敲错了，我把JSON的双引号敲成了单引号，导致出来的结果Python解析不了，所以我是拖后腿的那个。如果只算按tab键的话，其实从头到尾只花了一分钟时间。这又把之前的速度效率又增加了十倍，而且进一步拉低了门槛。 ![Second auto complete of copilot.](https://yage.ai/images/copilot-2.png) 总的来说，这是一件令我非常震惊的事情，因为它不仅成百上千倍地提高了效率，而且成百上千倍地降低了干这些事情的门槛。从一种积极的角度来说，人类的时间和精力可以被大量解放，我们可以把核心的时间用到享乐或者真正需要创造力的东西上面去。但从另一个角度来说，这也意味着人类会变得更卷，因为我也不知道未来会不会有足够多的岗位需要这么多的人来干这些事。 当然，这个例子本身是有偏见的，因为GPT本身是一个NLP模型，所以它非常适合做NLP的事情。如果你让它去做其他事情，比如判断图像里面的内容并输出JSON，可能就没有这么轻松。当然，多模态的GPT-4也已经在测试中了，虽然还没有发布，所以也许图像在不久的将来也会被攻克。但总的来说，这种数量级的门槛降低仍然让我特别震惊。在使用copilot的过程中，我也日常被吓到，因为它仿佛真的有读心术。往往仅仅敲了开头的几个字母，它就会把后面的大段函数给你补全。我以前觉得这仅仅是记忆或者是机械的应用，但随着经验的增多，我越来越相信它有某种程度的举一反三的能力。我非常推荐大家都去试一下copilot，它前两个月是免费的。我觉得它本身已经提升了我的编码效率大约5倍。如果再和GPT结合起来，光是这一个模型就已经节约了我一个星期的时间。所以今天真的是震撼我妈一整年。 （这个2200字的文章使用上面说的自然语言对话编辑器生成提纲，然后在10分钟内口述由GPT整理成文） *** 后续： 今天我突然意识到一个问题：作为[工程师](/new-employee-suggestions.html)，在设计这个系统时，我可能会有一种思维定势: 这个文本编辑器的后台一定要是一段程序。所以我们先要理解用户意图，将其翻译成机器能理解的语言，然后完全用机器处理。但这可能是一个误区。如果我完全不懂编程，我可能会直接跟GPT交流，告诉它这是一段文字，这是一个指令，让它把指令应用到文字上，然后把结果返回；而不是先把它转成JSON，再用电脑实现文本处理。 从这个角度来看，我以前的专业知识可能反而成了拖累，变成了一种[知识的诅咒](/correctness-is-meaningless.html)，降低了我写代码的效率。换句话说，如果我不懂编程，可能用这种思路跟GPT两分钟就能写出这样的产品，但因为我懂编程，所以我会想着先把它转成JSON，再转成具体的文本，这样反而需要一个小时。而且这种方法除了降低门槛、提高效率外，还有一个优点，就是可以实现很灵活的功能，而无需事先规定。例如，可以说"把第一行到第三行全部删掉"，或者"把第二行扩写成一个100字的小文章"等。这一方面带来了更大的灵活性，另一方面也带来了滥用的可能性，因此在工程上需要设置一些保护措施。 但是，GPT真的有这么智能，能完全支撑这样的工作吗？为了验证这一点，我做了一些实验，用非常短的时间实现了这个功能，并用各种测试样例进行了测试。我发现有两个较大的问题：首先，如果使用GPT-3.5，它很多时候并不够聪明，可能会漏掉一些字，或者把例子中的关键字原样输出，显得很笨。所以，它的智能似乎不足以支撑这样的应用。然而，GPT-4表现得很聪明，在很多情况下没有这样的问题，但它的延时很长，用户体验很差。当然，我相信这个问题随着时间的推移会得到解决。 最终我还是没有采用这种方法，而是回到了之前基于JSON的方案。主要原因是它的稳定性仍然不够好，例如，当我说"把前两行删掉"时，它可能只删掉了第一行；或者当我说"把第三行换成12345"时，它换成了1234。也就是说，它在精细的输出控制方面还不如电脑。换言之，从工程权衡的角度来看，我们希望在灵活性、可控性和工程成本三者之间取得平衡。目前GPT作为一个[语言模型](/foundation-models.html)对输出的精细控制还是它的弱项。从这个角度来说，以JSON作为中间层，先弄清楚用户的意图，然后用电脑实现它，可能是三者之间权衡的一个sweet spot。但随着GPT未来能力的发展，我们可能会越来越倾向于智能的方向，即一个不懂编程的人可能比懂编程的人写得更快，而且效果一样。这可能预示着我们码农接下来的任务，就像张无忌学太极拳一样，主要是忘记之前的知识，不断拥抱新领域。