代码解释器局限性：超出硬件系统规格

环境会经常重置代码执行状态，导致已上传的文件丢失，且从失败中恢复的能力有限。

OCR（光学字符识别）能力远不及GPT-4 版本[16]。

会拒绝执行本可以做到的任务，你必须坚持让它执行。

无法在代码中调用GPT-3/4，它无法访问网络，所以无法完成像数据增强等任务，它试图通过编写代码来解决问题。

但总体而言，代码解释器给人们留下了深刻印象：

“代码解释器Beta版十分强大。它堪称你的个人数据分析师：可以读取上传的文件、执行代码、生成图表、进行统计分析等。我预计社区需要一段时间来充分发掘其潜能。”——Karpathy

“如果这不是一个改变世界，影响GDP的产品，我不确定还会有什么能够做到。每个人都可以用20美元/月的价格雇佣一个‘脚本小子’为自己效力。”——roon

“我开始尝试代码解释器，它实现了我未来两年内的所有规划。”——Simon Willison

2017年，Noam Brown（现为OpenAI研究科学家）构建了一个名为 Libratus的AI，它在12万局无限制德州扑克对决中击败了四名顶尖专业选手。从中我们可以得出什么重要结论？

“通常神经网络的响应时间为约100毫秒……我们发现，只需添加一些搜索功能，就相当于使预先计算的策略扩大1000倍。这一发现超越了之前所有的相关研究成果。”（链接：/uploads/pic/20230913/rdgsmkh3sye ql-global-para="true" line="n9ay" style='margin: 0px 8px 15px;padding: 0px;clear: both;min-height: 1em;color: rgb(51, 51, 51);font-size: 17px;font-style: normal;font-variant-ligatures: normal;font-variant-caps: normal;font-weight: 400;orphans: 2;text-align: justify;text-indent: 0px;text-transform: none;white-space: normal;widows: 2;word-spacing: 0px;-webkit-text-stroke-width: 0px;text-decoration-thickness: initial;text-decoration-style: initial;text-decoration-color: initial;max-width: 100%;font-family: -apple-system-font, system-ui, "Helvetica Neue", "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;background-color: rgb(255, 255, 255);line-height: 1.75em;letter-spacing: 1px;box-sizing: border-box !important;overflow-wrap: break-word !important;'>事后看来，结果显而易见：

在现实生活中，当人类在面对较难的问题时，相比简单的问题会花费更多时间思考。但GPT-3在回答“球是圆的吗？”和“P = NP 吗？”两个问题时，所花费的时间几乎相同。如果我们让它花费一年的时间呢？

我们已经看到Kojima等人的“让我们一步步思考（Let’s Think Step By Step）”方法如何大幅提升了LLM的性能，主要是通过允许LLM在上下文中外化其思维过程，但也需要花费更多推理时间。Beam和思维树（Tree of Thought）类型的搜索能更有效地利用推理时间。

人工智能的每一次巨大飞跃都来自于某种形式的扩展。Transformer解锁了并行预训练计算。掩码语言建模使我们能够自由使用大量未标记数据。规模定律（Scaling Laws）为我们提供了扩展模型规模的向导。显然，推理时间计算/“实时搜索”是下一个前沿，使我们“只需投入时间”。

在2019年，Noam Brown利用这一洞见用Pluribus模型解决了6人德州扑克问题。在2022年，他再次利用这一想法，用Cicero模型在战略游戏“Diplomacy“中达到人类水平的AI（使用了AlphaGo和AlphaZero的搜索算法）。上个月，他仍在思考这一问题：

代码生成、沙盒和智能体云（Agent Cloud）

我一直强调LLM具备编程能力这一事实的特殊地位，这是AI工程师崛起的重要动力。不仅仅是简单的“Copilot对开发人员用处很大，但对其他人没什么用”——具备编程能力的LLM对于不懂编程的人来说通常也很有用，因为LLM是对代码的完美抽象。

我所知道的最早关于“代码核心（Code Core）”的实验来自Riley Goodside，他在去年进行了“你是GPT-3，你不会做数学”的实验。

这是第一个迹象，表明修复LLM的缺陷（如做数学计算、与外部环境交互、可解释性、速度/成本等方面）的最佳方法是利用其编写代码的能力，实现超越LLM范畴的任务。

NVIDIA的Voyager为这一思路提供了合乎逻辑的路线图：

从Voyager中进行泛化存在一个明显的问题：现实世界远比Minecraft环境更加随机，并且文档记录远不如Minecraft完善，反馈循环时间也更长。当前Minion AI、Multion和AutoGPT等智能体的实现都在你的实时浏览器/桌面上运行，这使得潜在的幻觉和错误变成灾难，相当于一辆双手完全不能离开方向盘的自动驾驶汽车。

如果你支持“Code Core”，就会了解这一问题的发展走向。自Ada Lovelace开始为还不存在的巴贝奇差分机上进行编程，开发人员一直在对分支进行测试。你可以通过添加语义层来改进代码生成，就像Seek AI的Sarah Nagy所做的那样。但最终，要知道代码是否运行并按预期工作的唯一方法是像Guardrails的Shreya Rajpal那样为其创建一个沙盒，并像Codium AI的Itamar Friedman那样生成测试。

大部分的代码生成/沙盒操作能够在本地完成且应该在本地完成，但随着本地主机服务接近终结，越来越多的智能体构建者和用户意识到，为构建和运行LLM推理过程中的代码部分需要云基础设施，相应就会预测到智能体云（Agent Cloud）的崛起，以满足这一需求。实际上，这是一种新型的Serverless基础设施需求，向非人类操作者提供必要的反馈。自然地，会涌现出大量候选者参与这一新兴的智能体云子行业：

Replit的Amjad已经公开讨论过。

E2B的Vasek拥有一个开源的Firecracker微虚拟机实现。

Codesandbox的Ives也有一个。

Fly的Kurt在五月份推出了Fly Machines。

你会注意到，所有这些实现都用到了Firecracker，亚马逊在2018年开源的替代QEMU的微虚拟机技术（microVM，亚马逊通常不会开源软件，对它来说这是一项不错的成就）。然而，与此形成对比的方法可能来自Deno（JavaScript领域）和Modal（Python领域），它们的自动配置运行时为智能体开发者与基础设施提供商提供了更轻量的协议，但代价是大大降低了可熟悉度。

当然，OpenAI必须构建自己的智能体云，以便在一个周末内为200万客户提供代码解释器的托管和规模化服务。多年来，他们一直在工作中使用这项技术，而其他人现在才意识到其重要性。

将所有内容综合起来，我们可以对比代码解释器与之前的方法：

在后文的播客对话中，GPT-4忠实的支持者们坚称GPT-4的基准模型质量已经下降（Logan已经声明所提供的模型没有改变），他们也声称代码解释器的输出，在没有编写代码的情况下，与原始的GPT-4被“削弱”之前具有同等的性能。

假设这一情况属实（如果没有明确的代码解释器API通过lm-eval-harness来验证，很难证伪），那么代码解释器为编写代码所做的额外微调可能也提高了整体输出质量（这是我们从相关研究、Replit以及GPT-3.5的基础模型code-davinci-002得出的结论）。这使得代码解释器的基础模型，在没有沙盒的情况下，单论模型质量，实际上成为了“GPT-4.5”。

未能归类的笔记

OpenAI的领先地位：Sundar Pichai在6月份宣布谷歌Bard的“隐式代码执行”功能，并实现了简单且无需依赖Python的功能。有趣的是，一个月后，我再次运行与谷歌宣传中同样的提示，却失败了。与此同时，OpenAI正推出一个全新的LLM编码范式。OpenAI的领先地位简直令人难以置信。

OpenAI作为云发行版：我对多个“第二层云（又称云发行版）”了如指掌，不禁注意到OpenAI现在已形成了云发行版的形态。在不久的将来，它是否会根据计算时间、存储容量进行收费，引入IAM策略，并填充云服务的其余组件？多久后OpenAI会去掉公司名称中的“Open”，并成为纯粹的AI云平台？

（就代码解释器，Latent Space主理人Swyx和Alessio Fanelli，以及Simon Willison、Alex Volkov、Shyamal Anandkat（OpenAI市场负责人）等AI技术专家进行了深入探讨，以下内容为对话节选。）

代码解释器的亮点

Alex Volkov：如果你是ChatGPT的付费用户，现在可以使用代码解释器。它的亮点之一是，代码解释器能够接收用户上传的文件；第二个亮点是，它能够在安全的环境中运行代码；第三个亮点是，代码解释器支持文件下载，也是ChatGPT的全新功能。

Simon Willison：我基本每天都会使用，毫不夸张地说，这是目前最令人兴奋的AI工具，因为它提供了许多功能，甚至带插件的ChatGPT都无可比拟。如果你是一名经验丰富的开发者，那更是如虎添翼；如果不是，结果证明也同样可以用它达成惊人的成就。

就在几周前，大家对代码解释器还相对陌生；现在，我想大家都了解到它的强大之处了。它能像ChatGPT那样编写代码，虽然ChatGPT很久以前就可以实现该功能，但代码解释器还能运行代码并显示结果。最有趣的是，它能够反复运行该代码，发现错误并提示修正：“我可以修复它，再试一次。”通过编写代码，捕捉错误，经过思考，再次编写代码这一方式，它由此尝试了四五次才获得正确的解决方案。

同时，观察它不断尝试各类任务也十分有趣。除了运行代码，它还支持上传文件和下载文件，支持上传的文件数量也很惊人。除了对CSV这样的简单文件进行分析，它还能够处理Python标准库的任何文件，包括SQLite。

实际上，你现在拥有了一个多功能工具，可以处理各类不同格式的文件。真正有趣的是，如果代码解释器知道某个文件格式的布局，即便没有相应的库，也可以对该文件格式进行处理。

你可以告诉它：“我正在上传该文件”，它可能会回答：“我没有这一文件类型对应的库。”然后你回复：“好的，请读取二进制字节，根据你对这一文件格式的了解，解释该文件。”之后它就会执行这一操作。这个功能十分有趣，富有创造性，可以尝试运用。

Alex Volkov：我注意到，有时它并不了解自己的能力，但可以鼓励代码解释器去尝试。

Simon Willison：没错，你可以鼓励它，“你可以做到的。”它会说，“好的，让我试试。”然后就会成功。基本上可以把它看作是一位编程实习生，有时非常聪明，能力超群，同时又十分愚蠢，不了解自己的能力。但与人类实习生相比，它最大的优势在于永远不会感到沮丧并放弃。它的处理速度很快，可以让它立刻抛开之前的工作并开始新的任务，它会持续不断地进行处理。

代码解释器与ChatGPT的区别在于，你可以让前者编写代码，并进行测试以确保其正常运行，然后进行迭代以修复bug。之前手动编写某些功能会非常繁琐，使用代码解释器可以帮助我简化这一过程。

有一些任务可能比较乏味，包含需要逐步解决的边缘案例，所以我直接交给代码解释器。它会运行代码，发现错误，尝试修复，再接着运行其他部分，使我可以更快地找出问题并进行调试。

对人工而言，这一过程通常需要花费一小时，但代码解释器只需几分钟就能完成。这种方法的效果很棒，当你使用普通的ChatGPT写代码时，很有可能会创造一些不存在的API，会产生幻觉，犯一些愚蠢的错误。而代码解释器在生成代码时可能会出错，但在为你输出最终结果之前，它会自动修复这些错误。

Daniel Wilson：因此，这就是为何我将其称为世界上最先进的智能体，这一点不容忽视。

代码解释器+插件

Daniel Wilson：Shyamal Anka是OpenAI的市场负责人，对代码解释器的商业用例非常感兴趣。他想知道结合代码解释器和插件的问题有什么价值，可以从中获得什么。

Surya Danturi：在自己的插件中调用其他插件是一个值得探索的领域，但会涉及安全相关问题。首先，我们必须先安装插件，如果在代码解释器内部，能够有一个作为自己小型向量数据库的插件，这将是一件很棒的事。

如果我们可以让代码解释器与插件进行交互，并调用外部API，就可以在代码解释器内部添加任何外部 API。从而使代码解释器与插件对话，让插件完成某些任务，将外部API添加到代码解释器内部。

目前 OpenAI还无法做到这一点，这涉及安全问题。

Alex Volkov：我觉得这很不错，目前在 ChatGPT中使用插件时，由于OpenAI 限制了网络访问，插件只能通过API访问外部服务。如果将这一插件功能与代码解释器相结合，OpenAI就有可能控制外部访问范围，限制API的使用范围，即只能使用经批准的插件，这将是一项了不起的进展。

Simon Willison：插件在注入提示方面确实有内在安全隐患。我认为，OpenAI 限制代码解释器访问这些功能是为了防止模型被欺骗去运行Python代码，并访问私人数据，从而导致数据泄露。

代码解释器的局限

Daniel Wilson：作为开发者，我们知道如何使用这些现有的库。不过，我们也许应该讨论代码解释器的局限性：首先它没有网络访问功能，其次你只能上传最多一百兆字节的文件。

Simon Willison：之前它可以运行子进程，因此能够调用其他程序，但现在似乎已经禁用了一些功能。

我最大的突破是，设法让代码解释器支持其他编程语言，如Deno使用单一的二进制文件。然后我上传了二进制文件，并告诉它，“现在有了Deno，你可以运行JavaScript了。”代码解释器确实顺利运行了Deno。但现在OpenAI可能限制了这一功能，真是遗憾，因为在某个瞬间，我曾在代码解释器上运行并执行了JavaScript。

我还上传了一个Lua解释器，代码解释器就开始运行和执行Lua，真是太酷了。不过，我想他们现在也不再支持这一功能了。

Alex Volkov：有时代码解释器会断开连接，顶部显示橙色通知，这种情况下，之前生成的下载链接将失效。

Simon Willison：虽然有备份保存了对话记录，但之前上传的所有数据都丢失了。这种情况确实令人沮丧，但至少你可以轻易在新会话中重新执行之前的所有操作，因为你有关于上一次对话的详细记录。

Alex Volkov：是的，上传压缩文件后请求解压并执行一些操作，但不知何时，代码解释器竟然丢失了那些文件。我不确定是如何丢失的，但需要注意的是，有时它会陷入循环中。代码解释器不知道文件是否存在，或者在代码方面是否犯了错误，因此，它会尝试以不同的代码方式从库中提取。所以如果你陷入循环，请及时中止，然后开启一个新的会话再从头开始。

swyx：在某些情况下，存在限制实际上是一件好事。例如，当我输入一个大型数据表时，让它进行探索性数据分析，也就是给我一些有趣的统计数据。但实际上，由于花费的时间太长，它主动中止了操作，并生成一段更短的代码，处理数据集中的一部分，这样的表现出乎意料。所以，有时你希望它超时，这也相当于用户体验的改进。但在其他一些情况下，显然你希望它能完整执行。因此，我们可能需要让它提供不同的执行模式，有时这种主动中止或超时的模式可能并不受欢迎。

Daniel Wilson：我想谈谈另一个限制。我尝试用它来进行数据增强，比如我有一个超级英雄名称的列表，想通过添加模型已知的其他信息来增强这个列表，我知道模型已经具备这些相关的知识，但问题在于模型倾向于生成代码，而不是用其已有的世界知识来填充表格的空白。而且由于没有网络访问权限，代码解释器无法调用自身。

我希望它能够将提供的文本嵌入其中，但它无法完成。所以我观察到它在某些方面存在一些限制，如果你之前使用的是常规的GPT-4，切换到代码解释器可能会在以上这些方面的能力产生倒退。

Simon Willison：这真的很有趣。我承认还从未试过用它来做数据增强，因为我进行类似工作时通常直接在常规的GPT-4中处理，比如输出一个Python字典，为每位超级英雄提供名称和简介等内容。然后我可以将它复制并粘贴回去。实际上不是复制粘贴，你要将那个JSON文件上传到代码解释器，因为上传文件不会占用词元，但复制粘贴代码会。

swyx：完全正确。这也是一个很有意思的观点，什么时候我们使用文件上传，什么时候使用代码解释器，什么时候使用原始的GPT-4更适合。

非编程式的代码解释器 = GPT-4.5?

Gabriel：我一直在使用代码解释器来执行常规的ChatGPT操作，所以没有涉及到编写代码，因为这个模型比目前默认的模型更强大。ChatGPT和GPT-4在过去一两个月内性能变得更差，我不确定这是否在该领域引起了争议，但我确实观察到这一点。

代码解释器模型感觉就像原始的 ChatGPT 模型，并且在执行回答问题、写文章等任务时，表现非常出色。我猜测，尽管目前代码解释器的性能很好，但这种情况可能不会持续太久，因为一旦该技术稳定下来，OpenAI肯定会进行性能改进，到那时，一切可能就会变得不再那么顺利。

Simon Willison: 我对这一说法持怀疑态度。我认为，关于模型性能变差的论点可能很难进行量化测量，我们可以很容易获得某件事的个人经验（anecdotal evidence），但很难完全确定发生了什么情况。

Gabriel：我之前在 ChatGPT-4 上运行了一些提示，并将其与今天默认模型的结果进行了比较。显然现在的结果更糟糕。

Simon Willison：这些都是个人经验，但如果你能公布真正详细的对比数据，可能会有所帮助，因为模型的输出有一定的不确定性，所以你可以多次运行同一个提示，其中两次可能表现不好，而另外三次可能表现良好。因此，即使你有几个月前的对比数据，也很难确定你第一次运行时是否只是运气好得到了好结果。

Gabriel：我先用相同的提示在四月份的模型上运行，然后在现在的默认模型上运行，通过对比发现现在的模型要糟糕得多。但是，我现在用相同的提示在代码解释器中进行了测试，结果只是生成了大量文本，没有涉及代码，而且结果与四月份的模型相似。

Simon Willison: 你使用的是长下文窗口为8000个词元的GPT-4模型吗？

Gabriel：我进行了测试，发现代码解释器的上下文窗口为8K，与插件模型和ChatGPT-3相同。我使用OpenAI的词元生成器来测量文本的词元数量，并尝试了一些不同的长度，最后发现在接近8K的时候会出现问题。当文本长度超过8K时，代码解释器会提示太多，无法得到答案。因此，插件模型、代码解释器和ChatGPT3.5的上下文窗口都是8K，而ChatGPT-4的默认上下文窗口是4K。

未来的用户需求

Host：GPT-4的视觉功能，我们都期待已久。虽然OpenAI宣布GPT-4会很快推出视觉功能，但并未透露确切时间。后来有传闻称，OpenAI的规划图显示视觉功能可能在明年推出。我们也知道Bing已经开始在Bing Chat中使用了一些视觉实例，但并未像我们现在拥有的可用插件生态系统那样。而且它们并没有提供API，但这是作为开发者所希望的。

Simon Willison：我有一个非常简单的需求。如果代码解释器是基于一个精调的模型来运行的，那么我想通过API来直接使用这个模型，但是让我们有自己的函数来对代码进行评估，这样就可以构建个人理想中的代码解释器版本，拥有个人想要的所有功能，这对OpenAI没有任何危害，他们可以按使用模型计费。但我们就可以在自己的Kubernetes容器中自由发挥，进行网络访问等。

Host：Simon刚才谈到代码解释器是一个经过微调的模型。因为在他们发布函数模型之前，我也正在开发，所以我做了些研究，结果发现：新的函数模型对代码解释器的任务理解程度更高，因此，我认为他们对其进行了微调。

Kyle: 我想将多模态功能结合在一起。当你在代码解释器中使用模型时，有时在绘图时会产生幻觉。

Audience：OpenAI应该认真考虑让 ChatGPT提供社交功能，允许所有人与使用类似意图提示模型的人进行协作。换句话说，让体验变得社交化。现在我们每个人都在自己的个体容器中进行操作，无论是字面还是比喻上，所以，ChatGPT 的社交版将会是一次“量子飞跃”，期待在这些社交体验中与大家共同参与。

Host：OpenAI注意到了“SharedGPT”现象，即许多人通过分享他们的会话内容来共享他们与GPT的交互，从而推动了社区的交流与合作。现在似乎有一种方法可以在一定程度上分享会话，但不确定是否适用于代码解释器。

Simon Willison：可以的，只是图表不会显示。所以在图表输出的地方会显示空白。

R5：重点不仅是分享，还包括能够找到志同道合的分析师和提示者（prompters），以建立联系。因为现在只有模型和 OpenAI 知道我们的提示内容，除非我们分享，否则他人是不知道的，而且第三方插件无法填补这个漏洞。

Simon Willison：Midjourney之所以是最好的图像提示工具，就是因为人们必须公开使用，彼此之间相互学习。

Lantos：我希望OpenAI能发布一个 Docker 工具，让用户可以在自己的计算机上运行，直接将GPT 模型连接到其中，然后在本地进行代码评估。我觉得这个项目可能会很快实现，甚至可以由 OpenAI的实习生开展。

Gabriel：我认为，代码解释器的最佳用例是商业分析师。商业分析师需要深入了解业务、用户和市场，但只需要基本的数据分析技能。对于初入公司的初级商业分析师来说，需要花费一两年的时间来真正理解业务和与之相关的所有内容；而高管则已经对业务有了深入了解，只是在数据分析方面可能还需要一些帮助。所以代码解释器在该领域有着巨大潜力。

为了充分发挥代码解释器对商业分析师的潜力，OpenAI需要提供更好地方式来将数据输入给模型，而不仅仅是上传文件。我觉得可以提供API密钥，让模型直接查询和分析数据。

Simon Willison：我已经用我的数据集软件构建了一个插件版本，插件确实为我们提供了一种做这件事的方法。如果可以上传高达100兆字节的文件，那么对于大多数业务问题，你都可以将数据压缩至100兆字节以下（比如通过查询数据仓库、提取过去30天日志文件的重要信息，并将其存储为100兆字节以下的SQLite文件或CSV文件），然后将其上传到代码解释器，再进行最后分析。所以如果你愿意花工夫将数据提取成100兆字节的数据块，那么你可以在现有工具的加持下走得相当远。

Gabriel：是的。代码解释器在某种程度上很有用，但无法完全解决问题，因为最终是你在决定上传哪些数据。但在解决问题时，一开始你并不知道实际上需要哪些数据，这是一个试错的过程，试图找出需要哪些列、哪些行、哪个表中的数据。如果我必须在开始解决问题之前弄清楚所有这些，那么我就已经局限在了特定内容，而无法跟随数据走向。

Kyle：通过给出不同的代码风格要求，比如想让代码解释器像数据工程师或统计学家一样写代码，你可以得到不同风格的代码输出。这种方法可以让你获取不同“人物”的代码解释。更有趣的是，你还可以让它进行ETL（数据提取、转换和加载）工作或者执行EED（数据工程设计）任务，这样就好像在与不同的“角色”进行交互。

Swyx：OpenAI正在开发视觉模型，并且已经在Alpha阶段进行测试；此外，OpenAI 还在研究微调功能，逐步弃用一些旧模型或功能，计划推出新的Instruct模型。那么OpenAI在完成了上述项目后，接下来会有什么发展方向？我觉得可能是GPT-5。目前GPT-4可能是OpenAI在第四阶段的最终产品，就像漫威电影宇宙的第四阶段一样成功。我希望在第四阶段中能够实现微调功能，就像《蜘蛛侠：英雄无归》一样，是这个阶段的高潮和收尾，然后在第五阶段带来全新创新。