原文：Code Interpreter == GPT 4.5 (w/ Simon Willison, Alex Volkov, Aravind Srinivas, Alex Graveley, et al. — AUDIO FIXED)^[1]

由 lencx 整理翻译，并补充一些相关细节。

关于版本

科技界最糟糕的秘密之一就是版本号大多数时候只是为了营销。

📌 版本号

Semantic Versioning^[2]

摘要

版本格式：主版本号.次版本号.修订号，版本号递增规则如下：

• 主版本号（major）：当你做了不兼容的 API 修改，

• 次版本号（minor）：当你做了向下兼容的功能性新增，

• 修订号（patch）：当你做了向下兼容的问题修正。

先行版本号及版本编译信息可以加到 主版本号.次版本号.修订号 的后面，作为延伸（范例：1.0.0-alpha、1.0.0-alpha.1、1.0.0-0.3.7、1.0.0-x.7.z.92）。

简介

在软件管理的领域里存在着被称作“依赖地狱”的死亡之谷，系统规模越大，加入的包越多，你就越有可能在未来的某一天发现自己已深陷绝望之中。

在依赖高的系统中发布新版本包可能很快会成为噩梦。如果依赖关系过高，可能面临版本控制被锁死的风险（必须对每一个依赖包改版才能完成某次升级）。而如果依赖关系过于松散，又将无法避免版本的混乱（假设兼容于未来的多个版本已超出了合理数量）。当你项目的进展因为版本依赖被锁死或版本混乱变得不够简便和可靠，就意味着你正处于依赖地狱之中。

作为这个问题的解决方案之一，我提议用一组简单的规则及条件来约束版本号的配置和增长。这些规则是根据（但不局限于）已经被各种封闭、开放源码软件所广泛使用的惯例所设计。为了让这套理论运作，你必须先有定义好的公共 API。这可能包括文档或代码的强制要求。无论如何，这套 API 的清楚明了是十分重要的。一旦你定义了公共 API，你就可以透过修改相应的版本号来向大家说明你的修改。考虑使用这样的版本号格式：X.Y.Z（主版本号.次版本号.修订号）修复问题但不影响 API 时，递增修订号；API 保持向下兼容的新增及修改时，递增次版本号；进行不向下兼容的修改时，递增主版本号。

我称这套系统为“语义化的版本控制”（Semantic Versioning.），在这套约定下，版本号及其更新方式包含了相邻版本间的底层代码和修改内容的信息。

Windows 3.0 跃升至 95 来展示它们的（如今已经成为标志性的，React95^[3] 是一个受 Windows 95 UI 设计启发的组件库）重新设计。为了与整个 MS Office 保持同步，Microsoft Excel 从 5 跳跃到了 7，而 MacOS 和 Windows 都以吸引 X 世代为目的，跳过了版本 9。React^[4]（一个 Web 开发框架）从 0.14 跃升至 v15^[5]，而 Kubernetes^[6] 和 Go^[7] （Go updates to tackle pain points, but Golang 2 is dead^[8]）证明了系统开发者的承诺：不破坏任何东西/v2（兼容性）。

那我们应该如何给基础模型版本命名？对于研究人员来说，这是一个有些陌生的概念，他们可以随便训练 400 个没有名称的大型语言模型（LLMs）来证明一点，但随着 AI 工程师在这些模型之上构建产品和业务，这个问题变得越来越重要。

在迄今为止生成型 AI 的简史中，已经有了一些值得注意的案例研究。虽然 GPT1 → 2 → 3 的进步每次都是一个明确的步骤前进，Midjourney 4 → 5 预示着 Balenciaga Pope^[9] 的出现，但像 Stable Diffusion 1 → 2 这样的发展更具有争议性（大多数用户并不关心精确的细节，而关注于它可以生成的结果。用户很多时候都是主观的，更精确的控制，文本的微调这些隐藏技巧具有额外的学习使用成本），小版本升级应该是无争议的（Why "Prompt Engineering" and "Generative AI" are overhyped^[10]） - 它可能意味着从相同的检查点开始并添加更多的训练 - 就像 SD v1.3 → 1.4 → 1.5 ...

📌 Balenciaga Pope

AI 生成的一张教皇弗朗西斯穿着羽绒服的引人注目的照片，被称为“Balenciaga Pope”。

在 MidJourney 上的用户每天都会生成成千上万张有趣、引人注目的图片；为什么 "Balenciaga Pope" 会成为病毒呢？首先，这张图片的关注度很低；与特朗普"被捕"的图片不同，教皇穿着蓬松夹克并不是什么改变世界的事件。许多用户会在时间轴上滚动浏览该图片，而不会费心去核实图片是否真实，因为这并不重要。

虽然 "Balenciaga Pope" 并不像特朗普"被捕"那样具有误导性，但该图片的传播速度以及一些社交媒体用户的轻信引发了人们的担忧，即公众还没有准备好应对因人工智能的兴起而即将到来的虚假信息浪潮。

... 这就引出了今天的主题：以半点 GPT 版本作为 framing device（框架设备：这是一种用于理解和解决问题的概念结构。在这里，"framing device" 指的是使用 GPT 版本号来理解和比较不同的 AI 模型）。

你可能会记得，GPT3.5 是和 ChatGPT^[11] 一起宣布的，其中包括了 text-davinci-003 和 code-davinci-002（Model index for researchers^[12]）。这完成了两件事：

1. 提高了人们对 GPT3.5 模型（比 2020 年的 GPT3 模型要好）的认知，因为它添加了代码，进行了指令调整，使用了 RLHF/PPO。

2. 新的聊天范式是通用 AI 的未来发展方向（指能在多种任务和环境中进行有效操作的人工智能，而不仅仅是在特定任务中才有效的 AI）。

关于代码解释器模型的讨论话题将围绕：

1. 提醒人们 GPT4 升级到此版本的重大改进（如果你是一个非常在线的人，并且已经被各种资讯不厌其烦地告诉你 Code Interpreter 杀死数据分析师的 n 种方法，那么我（Shawn Wang @swyx^[13]）很抱歉作为又一个 AI 技术掮客来大肆宣扬它。但请相信我，在旧金山，我每天都在和人工智能领域的人交谈，而在这次推出之前，Code Interpreter 的市场认知度还不到10%，人们对此的误判是令人难以置信的）。

2. 建议这个新的范式是通用 AI 的一个发展方向。

这两个特征让 swyx 得出结论：代码解释器应该被视为实际上的 GPT 4.5，如果有一天有 API，我愿意打赌它也将被赋予法定的称号。

但我们先不要过于急躁。是时候回顾一下，就像我们之前做的 ChatGPT^[14]、GPT4^[15] 和 Auto-GPT^[16]！（相关阅读：GPT-4 混合模型：8 个 2200 亿参数的专家模型？，LLM Agent：构建 AI 大脑的机遇与挑战）

代码解释器

代码解释器是（Code Interpreter）一个实验性的 ChatGPT 模型可以将 Python 代码写入 Jupyter 笔记本并在沙盒中执行，该沙盒（相关文章：ChatGPT 探索：Code Interpreter 高级指南，ChatGPT 重大更新：代码解释器即将推出，GPT-4 API 全面开放！）：

• 与其他用户和互联网隔离。

• 支持最多 100MB 的上传/下载（包括 .csv, .xls, .png, .jpeg, .mov, .mp3, .epub, .pdf 整个 git 仓库的 .zip 文件）。

• 预先安装了超过 330 个库，比如 pandas（数据分析）、matplotlib、seaborn、folium（图表和地图）、pytesseract（OCR）、Pillow（图像处理）、Pymovie（ffmpeg）、Scikit-Learn 和 PyTorch 和 Tensorflow（机器学习）。

• 输出的图表包含中文字符时无法显示（暂未找到切换字体方法）。
  

😅 Code Interpreter 正在退化

我这几天不断地在探索 Code Interpreter 一些新玩法，但在遇到需要执行代码的任务时，有超过一半的任务被拒绝，它选择只给出代码片段，让用户在本地环境执行（我猜测可能是用户太多，导致服务压力过大，这个问题可能短期内也不会得到改善）。下面两张图是前几天和今天两次执行结果的对比。以下案例是获取 Code Interpreter 沙盒中的依赖库。

Code Interpreter 获取到环境依赖并输出到文件，提供下载链接

Code Interpreter 拒绝此任务

那我们继续换种方式，直接喂代码来让它执行：

📌 Prompt

请执行以下代码：

import pkg_resources

def get_installed_distributions():
dists = pkg_resources.working_set
return [f"{dist.key}=={dist.version}" for dist in dists]

# Get the list of installed distributions
installed_dists = get_installed_distributions()

# Write to requirements.txt
with open('/mnt/data/requirements.txt', 'w') as f:
for dist in installed_dists:
f.write(f"{dist}\n")


Code Interpreter 终于工作了

小结：如果遇到 Code Interpreter 不工作的情况，可能需要你修改 prompt 或者给一些辅助代码提示，可以帮助你更好的推进任务。

它于 3 月 23 日作为 ChatGPT 插件更新的一部分宣布，Andrew Mayne（ChatGPT + Code Interpreter = Magic^[17]） 和 Greg Brockman^[18] 提供了引人注目的演示。Alpha 测试人员在 4 月、5 月和 6 月获得了访问权限。最后，它在 7 月 6 日至 8 日被作为一个可选择的 beta 功能推出给所有约 200 万的 ChatGPT Plus 用户。

因为这些能力可以在代码中灵活且无限地组合，所以很难列举所有的能力，但通过例子学习是有用的（例如：p5.js 游戏创建，绘制模因，创建交互式仪表板，数据预处理，包括季节性，编写复杂的 AST 操作代码，大规模面部检测，更多示例可参考 OpenAI Discord 上的 #code-interpreter-output 频道）并且浏览库列表（从环境依赖库下手）。

Code Interpreter 引入了两个新元素 —— 模型和沙盒。这个新模型在编写代码、自主完成多步任务、选择何时停止并向用户提供选项等方面，都展示出了出色的性能。

尽管 Code Interpreter 收到了广泛的好评，但它也有一些明显的局限性：

• 优点

• 高度自主性：模型能够自主编写并调试代码，无需人类干预。

• 具有竞争优势：与开源社区的一些尝试相比，Code Interpreter 因为集成了模型和模式，展现出了显著的优势。

• 缺点

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

• 它的 OCR 能力远不及 GPT-4 Vision。

• 有时它会拒绝执行它能够做的事情，你必须坚持它能做。

• 它无法在代码中调用 GPT3/4，因为它不能访问网络，所以不能执行像数据增强这样的任务。

未来推测

主要有以下方面：

• 推断的下一个大前沿可能在推断时间计算或"实时搜索"上，也就是在解决问题时可以投入更多的时间（一个神经网络通常在大约 100 毫秒或者什么的时间里给你一个回应… 我们发现，如果你做一点搜索，它就相当于让你的预计算策略变得 1000 倍大。只需要一点搜索，它彻底打败了我们一直在研究的所有内容，这个结果是明显的）。

• 代码生成、沙盒和代理云可能成为 GPT-4 向 GPT-5 的发展道路上的重要一环。AI 工程师的崛起和 AI 的编程能力有重要关联，通过创建沙盒，可以测试和确认代码的运行情况和执行结果，更好地利用 AI 的这种编程能力。

• 模型的代码生成能力也是一个有趣的研究方向。在此之前的实验表明，利用 LLM（Language Model）编写代码，可以有效地解决一些 LLM 本身无法解决的问题，比如进行数学计算、与外部环境交互、可解释性以及速度/成本问题。

• 云计算在未来的发展中将会越来越重要。AI 需要云基础设施来运行代码段，预计代理云将会崛起，满足这种需求。这种需求实际上是一种新的无服务器基础设施需求，它需要具有特殊的便利性，为非人类操作者提供必要的反馈。

• OpenAI 已经具备了云分发的雏形，预计可能会开始收费计算时间、存储容量，引入 IAM 策略（身份和访问管理），并填充云服务的其他组件。

• 在 OpenAI 和 Google 的竞争中，OpenAI 在 LLM 编码领域处于领先地位。Google Bard 在执行简单的无依赖性 Python 能力时失败，而 OpenAI 正在推出全新的 LLM 编码范式。

总的来说，通过增加推断时间，利用代码生成和沙盒，以及适应云计算的发展，可以在 GPT-4 的基础上实现进一步的发展，达到 GPT-4.5 的水平。

References