对OpenAI的编程AI模型Codex的API应该有怎样的期待？

OpenAI 近日在博客上表示，将通过应用程序编程接口提供编程AI模型Codex。与此同时，OpenAI首席技术官Greg Brockman、首席科学家Ilya Sutskever和联合创始人Wojciech Zaremba在线演示了这一深度学习模型的功能。

Codex演示充分展示了这一大型语言模型的优势——为各种API和耗时而令人沮丧的微任务解析、引用和编写代码的令人印象深刻的能力。

目前，OpenAI 仍在对Codex 进行测试。在编程任务中，你能把它推进多远，它将如何影响软件就业市场，这些都是悬而未决的问题。但OpenAI探索大型语言模型的这一出人意料的转变，似乎是神经网络与人类对话的第一个有前景的应用。

编程语言模型

Codex是在GPT-3的基础上构建的，GPT-3是OpenAI在2020年发布的一个非常大的语言模型，可通过商业私有测试API获得。OpenAI的研究人员希望了解开发人员如何将GPT-3用于自然语言处理应用程序。

结果却让他们大吃一惊。“对我们来说，有趣的是，最能激发人们想象力、最能激发人们灵感的应用是编程应用。”Brockman在Codex的演示视频中说，“因为我们的模型根本不擅长编码。我们知道，如果我们付出一些努力，就能有所成就。”

作为GPT-3的新一代版本，Codex已经针对编程任务进行了微调。该机器学习模型已经用于Copilot，另一个Beta代码生成产品，由GitHub托管。OpenAI表示，目前的Codex在编码任务上的准确率为37%，而GPT-3的准确率为零。

Codex采用自然语言提示作为输入（例如，“Say hello world”），就能针对给定的任务生成代码。它应该使程序员更容易处理编写软件的日常部分。

“你只要让计算机做点什么，它就会照做。”Brockman说。

在演示视频中，Brockman和Sutskever带领Codex完成了一系列任务，从用Python显示简单的“Hello World”信息到逐步用JavaScript编写网页游戏。

演示中有一些令人印象深刻的亮点，尽管它似乎是经过排练的。例如，Codex似乎很擅长解决参照问题。它还将提示符中的名词与代码中相应的变量和函数联系起来。

Codex可以执行一些乏味的任务，如渲染网页、启动网络服务器和发送电子邮件。该模型还显示了GPT-3的一些零机会学习能力。例如，在演示中，Brockman通过三行指令展示了如何将Mailchimp接口功能添加到Codex。再往下，演示者让Codex用JavaScript创建用户界面，将对象放置在屏幕上，并通过键盘方向键控制对象。另一个视频展示了OpenAI在Python的Matplotlib库中生成数据科学代码和图表。

这些都不是复杂的任务，但它们乏味且容易出错，通常需要查阅参考手册、浏览编程论坛和仔细研究代码示例。因此，让人工智能助手为你编写这类代码可以节省一些宝贵的时间。

“这种东西并不是编程中有趣的部分。”Brockman说。

OpenAI的博客写道：“一旦程序员知道要构建什么，编写代码的行为可以被视为：1、将一个问题分解成更简单的问题；2、将这些简单的问题映射到已经存在的现有代码（库、API或函数）。后一项活动可能是编程中最不有趣的部分，而这正是OpenAI Codex最擅长的地方。”

Codex的局限性

虽然Codex的演示令人印象深刻，但并没有全面展现深度学习系统的能力和局限性。

演示视频显示了使用Codex时需要注意的一些缺陷。例如，如果你告诉人类程序员打印“Hello world”五次，他们通常会使用一个循环，将一条消息打印在一行上。但当Brockman告诉深度学习模型做同样的事情时，它使用了一种不同寻常的方法，将所有信息彼此紧邻着贴在一起。结果，Brockman只得被迫把他的指示改得更具体。

Codex的输出不一定是解决问题的最佳方式。例如，为了放大网页上的图像，模型使用了一个笨拙的CSS指令，而不是使用更大的数字作为宽度和高度。

有时，模型生成的代码与开发人员的意图相差甚远。在演示的最后10分钟，Brockman和Sutskever使用Codex创建了一款JavaScript游戏。当他们指示Codex定义游戏失败的条件时，深度学习模型为空格按键生成了一个事件监听器。Brockman通过明确告诉Codex编写游戏失败函数才解决了这个问题。

视频演示也没有显示Codex论文中详细描述的任何限制，包括模型在处理多步骤任务方面的限制。这一遗漏引起了人工智能社区的一些担忧。

尽管有这些不足，Codex还是非常有用的。那些有幸能够使用API的人已经用它来自动化一些枯燥乏味的工作了。许多与GitHub的Copilot一起工作的人也对AI驱动的代码生成之于生产力的提升表示满意。

谁应该使用Codex？

在接受The Verge采访时，Zaremba将Codex比作从穿孔卡片到编程语言的转变。在那个时候，C和Fortran等编程语言的出现降低了软件开发的门槛，并使更多的用户进入了这个市场。同样的事情也发生在更高级的语言出现时，它解决了编写代码的复杂技术挑战。如今，许多程序员在编写代码时并不担心分配和释放内存块、管理线程或释放系统资源和句柄。

但似乎不能认为Codex是一个从学习编程语言到给计算机会话指令并让它们自己编写代码的过渡。对于那些需要AI助手帮助编写代码的资深程序员来说，Codex是一个非常有用的工具。但在新手程序员手中，Codex是一个可能产生不可预测结果的危险工具。

这种统计模型可能存在的潜在安全缺陷更令人担心。由于该模型是根据训练语料库的统计规律生成输出的，因此容易受到数据中毒攻击。例如，如果对手在GitHub上上传了大量恶意代码，Codex可能会在训练期间获取这些模式，然后根据用户指令输出它们。事实上，GitHub Copilot使用了同样的技术，它的页面警告说，代码生成模型可能建议“使用旧的或已弃用的库和语言”。

这意味着盲目接受Codex的输出可能会导致灾难，即使它运行良好。你应该只使用它来生成你完全理解的代码。

Codex的商业模式

相信Codex API会为软件公司找到大量的内部用途。根据Codex文件提供的信息，它比GPT-3更节约资源，因此，它应该更便宜。如果软件开发公司能设法使这个工具适应他们的内部流程，并为他们的开发人员每个月节省几个小时的时间，那么将是物有所值的。

但围绕Codex的真正发展将来自微软，OpenAI的非官方所有者和其技术的独家许可持有者。

在OpenAI将GPT-3商业化之后，在语言模型上创建产品和商业模型是非常困难的，如果不是不可能的话。无论你用语言模型做什么，微软都能做得更好、更快，而且成本更低。凭借Office、Teams和其他生产力工具的庞大用户群，微软在大多数GPT-3驱动产品市场占据了有利地位。

微软在Codex上也占据了主导地位，特别是因为它拥有GitHub和Azure这两家软件开发、DevOps和应用托管的巨头。因此，如果你计划使用Codex API创建一个商业产品，那么你很可能会在竞争中输给微软，除非你的目标是一个软件巨头不会感兴趣的非常狭窄的市场。像GPT-3一样，OpenAI和微软发布了Codex API，以探索开发新产品的机会，作为开发人员的试验，他们将利用反馈推出有利可图的产品。

OpenAI的博客上写道：“（我们）知道我们只触及了能做的事情的表面。”【原文：Ben Dickson；编译：黎雾】

作者简介：Ben Dickson是一名软件工程师，也是TechTalks的创始人。