在过去的 6 个月里,我一直致力于 GPT Pilot ( https://github.com/Pythagora-io/gpt-pilot ),以了解我们可以在多大程度上真正利用 AI 实现自动化编码,所以我想分享我们的经验到目前为止以及它能走多远。
当我开始构建 GPT Pilot 时,我写了一篇关于它的设想的博文。现在,我想分享我修改后的想法,并讨论哪些有效,哪些无效。
最后,您将看到使用 GPT Pilot 创建的应用程序示例,以及如何与真正的AI 配对程序员一起创建应用程序。
GPT Pilot 被设想为真正的人工智能开发人员,而不是自动完成或聊天机器人。相反,开发人员会为如何构建应用程序或功能制定计划并开始编码。它想自己完成大部分编码,但是当它遇到困难时,它需要澄清给定的需求,或者需要进行代码审查,它会向你寻求帮助。
我经常看到基于 CodeGen GPT-4 的工具声称他们正在构建 AI 初级开发人员。
不知何故,我一直有一个问题,因为当我使用 ChatGPT 进行编码时,它给我的答案和想法只有超级资深的人才能给出 - 绝对没有初级开发人员能够掌握的东西。尽管如此,没有法学硕士可以像高级开发人员那样构建应用程序,但 GPT-4 所掌握的编码知识远远超出了任何初级开发人员。
我想说,GPT-4 对软件开发的各个部分都有如此多的知识,就像世界上最高级的开发人员一样,但具有金鱼的记忆力。我把它想象成一个超人机器人,只是站在房间中央,一次只能做一个小动作,但它不能结合许多动作和重复工作。您必须准确地告诉它下一步应该做什么。
这就是我们 GPT Pilot 所追求的目标——我们希望为 LLM 创建一个思维框架,让超人机器人能够通过修改之前的操作来持续工作,建立反馈循环,并确定下一步应该做什么完成最终目标,即构建一个生产就绪的应用程序。
在我上面提到的博客文章中,我概述了构建 GPT Pilot 的主要支柱。但根据我们团队的经验,这些内容已经发生了一些变化,因此以下是修订后的支柱:
需要人类来监督人工智能,不仅是因为人工智能还不够好,还因为你可能想要改变某些东西的工作方式或实施后的管理方式。对于开发人员或产品经理来说,一旦看到实现的样子,就会决定更改它,这是很常见的。
或者,您意识到边缘情况比您最初预期的要多,并且认为重构当前的实现比解决每个问题更容易。问题是当您完成整个应用程序然后尝试重构它时 - 这会变得更加困难,因为每次更改都会影响所有其他功能。
另一方面,如果您在提交更改之前进行重构,您将能够在编写良好的代码之上继续处理下一个功能。这就是为什么人工智能开发人员在执行任务时让人员参与循环至关重要。
这样,在 GPT Pilot 继续执行下一个任务之前,人们可以检查每个任务的实现情况(就像合并 PR 之前的代码审查一样)。如果有人告诉 GPT Pilot 出了什么问题,那么解决任务本身的问题就会容易得多。同时,LLM有任务中需要做什么以及到目前为止已经做了什么的背景。
人工智能可以迭代自己的错误。我有一种感觉,很多人判断 ChatGPT 编写代码的能力是根据第一次要求它编写代码时它的交付情况。如果它不能生成工作代码,许多人会认为它并不令人印象深刻。事实上,人类几乎从来不会在第一次尝试时就编写出可用的代码。相反,您编写代码,运行它,查看错误,然后迭代。这正是 GPT Pilot 使 GPT-4 能够做的事情 - 在编写代码后,GPT Pilot 可以运行代码,获取输出,并向 LLM 询问输出是否正确,是否应该修复某些内容,如果是,如何修复。
软件开发是可以精心安排的。所有开发人员在构建应用程序时都会经历许多重复的例程。其中一个例程可以是 – 编写代码、运行它、读取错误、更改代码、重新运行它等。另一个更高级别的例程可以是 – 接受一项任务、实现它、测试实现(重复直到所有测试通过) ,发送以供审核,修复问题(重复直到审核者批准),然后部署。如果我们有一个明智的决策者(比如法学硕士),那么许多这些例程都是可以精心安排的。
编码过程并不是一条直线。当我们创建 GPT Pilot 的第一个版本时,我们认为它需要迭代任务、实现代码、修复它,然后继续。事实上,在编写应用程序时,您不会不断进步 - 您一直在重写代码。
有时,您会重构代码库,因为在初始实现之后,您意识到有更好的方法来实现某些内容。其他时候,您这样做是因为需求发生变化。正如我在 #1 中提到的,在发现解决方案不起作用后,有时需要回滚一系列更改,考虑问题的替代解决方案,并尝试以这种方式解决问题。
为了让 GPT Pilot 或任何其他人工智能开发人员大规模工作,它需要有一种机制,使其能够返回、选择替代路径并重新实现任务。
一般来说,法学硕士是一项每个人都试图理解的新技术——它是如何工作的、可以做得更好、如何进行适当的提示工程等。我们的方法是专注于构建应用程序层,而不是致力于获取法学硕士输出更好的结果。
原因是LLM会变得更好,如果我们花几周时间优化一个提示,新版本的GPT可能会完全解决这个问题。
相反,我们关注的是用户体验应该是什么样子,以及需要哪些机制来控制 LLM,使其能够持续工作,越来越接近最终的解决方案。因此,到目前为止,我们的经验教训如下:
应用程序的最初描述比我们想象的重要得多。我们最初的想法是,通过人类的输入,GPT Pilot 将能够朝着正确的方向导航,并越来越接近工作解决方案,即使最初的描述很模糊。
然而,GPT Pilot 的思维从最初的描述开始贯穿整个提示。这样,如果最初的提示中有误导性的内容,GPT Pilot 拥有的所有其他信息都将导致错误的方向。所以,当你彻底纠正它时,它就会深深地陷入这种错误的道路中,几乎不可能走上正确的道路。
现在,当我写这篇文章时,它看起来很明显,但这是我们需要学习的东西——更多地关注最初的描述。因此,我们构建了一个名为“Spec Writer”的新代理,它可以与您一起在开始编码之前分解项目需求。
编码不是一条直线。正如我在上面的支柱部分提到的,重构一直在发生,GPT Pilot 也必须这样做。我们还没有为此实现解决方案,但它可能会通过添加 GPT Pilot 围绕其决策树创建标记的功能来发挥作用,这样每当出现问题时,它就可以检查标记并思考可以在哪里进行处理拐错了弯。
代理商可以自行审核。我的想法是,如果一个代理人审查另一个代理人所做的事情,那将是多余的,因为这是同一个法学硕士重新处理相同的信息。但事实证明,当一个特工审查另一个特工的工作时,效果出奇的好。我们有 2 个不同的“审核者”代理来审核代码的实施方式。
一个在高层次上进行,例如整个任务是如何实现的,另一个在对文件进行更改之前检查每个更改(例如执行 git add -p)。
当法学硕士能够专注于一个问题而不是在一个提示中解决多个问题时,他们的工作效果最好。例如,如果您告诉 GPT Pilot 在单个描述中进行 2 个不同的更改,它将很难同时关注这两个更改。因此,我们将每个人工输入分成多个部分,以防输入包含多个不同的请求。
详细日志有帮助。现在这一点非常明显,但最初,我们没有告诉 GPT-4 在代码周围添加任何日志。现在,它创建带有详细日志记录的代码,这样当您运行应用程序并遇到错误时,GPT-4 在查看已写入哪些日志以及这些日志在代码中的位置时,可以更轻松地进行调试。
将代码库分割成更小的文件有很大帮助。这也是一个显而易见的结论,但我们不得不学习。如果代码被分割成许多文件而不是几个大文件,那么 GPT-4 实现功能和修复错误会容易得多。就像我们人类所想的那样——处理较小的代码块比处理大的代码块容易得多。我们通过创建抽象层次——函数、类等来做到这一点。
让 LLM 创建更易于管理的抽象的最简单方法之一就是告诉它创建更多模块化代码并将其拆分为更多文件。它的效果非常好,而且最终结果对我们开发人员来说也更好。
为了使人们能够修复代码,他们需要清楚地展示任务中编写的内容及其背后的想法。 GPT Pilot 的目标是完成所有编码任务的 90%,并将其余 10% 留给人类。这 10% 通常包括法学硕士很难注意到的修复或小变化,但对于人类来说,这可能是一个简单的变化。
然而,问题在于,告诉人们哪些代码不起作用以及他们应该查看哪些代码并不容易。如果 GPT Pilot 编写了 3,000 行代码,那么人类开发人员如果想要帮助 GPT Pilot,则需要在深入实际代码之前了解整个代码库。
在 GPT Pilot 的未来版本中,人类开发人员将详细解释当前任务中添加了哪些代码及其背后的原因。这样,您将能够帮助 GPT Pilot。
人类是懒惰的。法学硕士最好向人类提出问题,而不是让人类思考所有可能的错误。回顾过去,这一点非常明显,但我们注意到的一件事是,人们更愿意回答 GPT Pilot 提出的问题,而不是有一个开放式的输入字段,让他们可以编写不受限制的反馈。
很难让法学硕士跳出框框思考。这是我最大的收获之一。我认为你可以通过给它一些已经用来解决问题的解决方案来提示 GPT-4,并告诉它考虑另一个解决方案。然而,这并不像听起来那么容易。
我们最终做的是要求法学硕士列出它能想到的所有可能的解决方案并将它们保存到内存中。当我们需要尝试其他方法时,我们会提取替代解决方案并告诉它尝试不同但具体的解决方案。
目前,您可以使用 GPT Pilot 创建简单但不平凡的应用程序。我们还看到人们使用 GPT Pilot 创建了令人印象深刻的应用程序,例如可以微调 ResNet 模型来计算棕榈树数量的应用程序,然后在您上传图像时计算其中的树木数量。以下是我们创建的几个应用程序,以及代码、统计数据和演示:
可以将其视为增强版的 OpenAI Playground – 它使您能够从 JSON 数组加载对话或手动输入对话,使用 LLM 运行对话 X 次,将对话保存到数据库,然后重新加载。我们当我们设计一个提示并想看看它的行为方式时,实际上会使用这个应用程序。
Playground 不够好,因为重复重新运行单个提示非常耗时。使用提示实验室,您可以选择运行它的次数,并让应用程序重复运行提示。
完成后,您可以分析结果。这对于正在构建人工智能应用程序并需要优化提示的人来说可能很有用。
这也是我们内部用来分析本地 SQLite 数据库的应用程序。它以 GPT Pilot 数据库结构特有的格式从数据库中提取数据,但可以轻松修改以适应其他结构。
它读取并上传您的 SQLite 数据库,按特定字段拆分行,将行解压缩为值,将 LLM 对话数据加载到表单中,并使您能够简单地更改其中一条消息并将 LLM 请求提交到 GPT-4看看结果如何。
通过这种方式,您可以分析 GPT Pilot 代理与 LLM 的对话,并轻松探索如果提示不同会发生什么。
Code Whisper 是我们创建的一个有趣的项目,作为展示的示例。这个想法是,您可以使用它向 LLM 询问有关您的代码库的问题。您将链接粘贴到公共 Github 存储库。
然后,它克隆存储库,将相关文件发送到 LLM 进行分析,LLM 为每个文件创建有关代码功能的描述,并将这些描述保存到数据库中。
之后,您可以向应用程序询问有关代码库的问题,代码库会向您显示响应。在本演示中,我们使用 GPT-3.5。
我多年来一直在发布开源项目,而且我一直想看看我的 Github 存储库与https://star-history.com/上其他成功的存储库相比增长有多快。问题是,在 Star History 上,我无法放大图表,因此具有 1,000 颗星的新存储库无法与具有 50,000 颗星的大型存储库进行比较,因为您无法看到更大的存储库在开始时的表现。
因此,我要求 GPT Pilot 构建此功能。它会抓取观星者的 Github 存储库,将它们保存到数据库中,将它们绘制在图表上,并允许放大和缩小图表。
我希望您对我们在 GPT Pilot 处理的现状、问题和发现有一些了解。
所以,回顾一下:
我们认为真正的人工智能开发工具应该基于以下支柱:
需要有人来监督人工智能。
我们应该让人工智能能够迭代自己的错误。
软件开发是可以精心策划的,应该在法学硕士之上的一层上实施。
人工智能开发人员应该能够重构代码库,因为实际上,编码过程并不是一条直线。
到目前为止,我们了解到:
最初的应用程序描述比我们想象的重要得多
编码不是一条直线,代理可以自行检查
法学硕士在专注于一个问题时效果最好,而不是在一个提示中解决多个问题
详细日志创造奇迹
将代码库分割成更小的文件有很大帮助
让人类能够修复代码
必须清楚地向他们展示所写内容及其背后的想法
人类是懒惰的
很难让法学硕士跳出框框思考
你怎么认为?您在与法学硕士的互动中是否注意到这些行为,或者您对这些行为有不同的看法吗?
我非常高兴收到您的来信,因此请在下面发表评论或给我发送电子邮件至[email protected] 。
您可以在此处尝试使用 GPT Pilot 创建具有 AI 的应用程序:
如果您喜欢这篇文章,那么如果您为GPT Pilot Github 存储库加注星标,那将意义重大,如果您尝试一下,请告诉我们您的想法。您的反馈对于整个 GPT 试点团队非常重要。
也发布在这里