就在最近，一個由硅谷創(chuàng)業(yè)極客和科研人員更新的播客火了，在這一播客中，他們詳細闡述了為什么代碼解釋器有如此強大的功能，以及代碼解釋器未來對OpenAI工作方向的影響，甚至，他們認為代碼解釋器本身就相當于GPT4.5。一起來看看本文的解讀。

在上周，一個由硅谷創(chuàng)業(yè)極客和科研人員更新的播客Latent Space Podcast火了！

兩個小時的播客結(jié)束時，有接近2萬人同時在收聽。

后來組織者將他們的播客內(nèi)容轉(zhuǎn)錄成一篇長文 ——《代碼解釋器就是GPT4.5》，在推特上獲得了40萬的閱讀量。

文章非常全面地闡述了代碼解釋器的功能和它未來對OpenAI工作方向的影響。

他們甚至認為，代碼解釋器是一條通往AGI的高速公路！

一、不要在意版科技產(chǎn)品的版本號和名字

在技術(shù)領(lǐng)域，版本號大多是為了營銷目的而存在，這已經(jīng)是一個公開的秘密了。

Windows 3.0 躍遷至95版本是為了讓公眾感知到微軟的重新設(shè)計（如今已成微軟的標志）。

而且MacOS和Windows有意跳過了9版本，是為了吸引00后用戶。

那么我們應該如何理解大模型版本之間的關(guān)系呢？

理解版本號，對于科研人員來說，這可能是一個相對陌生的概念。

因為他們可能會輕松地訓練400個不命名的語言模型來證實一個觀點，但隨著AI工程師在這些模型之上構(gòu)建產(chǎn)品和業(yè)務的重要性日益增加，版本管理變得越來越重要了。

在生成式人工智能的簡短歷史中，我們有了一些案例可供參考。

GPT1→2→3 ，每一次更新都是明顯的進步，而Midjourney 4→5則預示著Balenciaga Pope的到來。

但類似 Stable Diffusion 1→2 的發(fā)展卻引起了用戶的爭議。

小版本號理應是代表著某種意義上的升級。

它可能意味著從某一個基點開始，進行了更多的訓練，比如 SD v1.3→1.4→1.5…

…這就引出了今天的話題，即GPT的.5版本號代表了很重要的改進。

應該大家還記得，GPT3.5緊跟著ChatGPT發(fā)布，并且包括了text-davinci-003和code-davinci-002。

這次更新完成了兩個目標：

首先，讓用戶認識到GPT3.5相較于 GPT3（2020年的版本）優(yōu)秀太多了。

原因是：

1. 增加了代碼；
2. 進行了指令微調(diào)；
3. RLHF/PPO。

其次，表明這種新的聊天人機互動方式是通往AGI的未來之路。

我們對代碼解釋器認知的核心問題是：

1. 讓人們理解從GPT-4更新到代碼解釋器的影響到底有多大；
2. 討論種新的范式是未來通往通用人工智能的方向。

這兩個特點導致我得出了一個結(jié)論：代碼解釋器應該被視為事實上的 GPT 4.5。

而且如果將來再加入API功能的話，我敢打賭，代碼解釋器結(jié)合起來就會被正式命名為 GPT 4.5。

那現(xiàn)在我們再稍微回顧一下代碼解釋器到底能干什么。

二、全面認識代碼解釋器

代碼解釋器是「一個實驗性的ChatGPT模型」，可以將Python代碼寫入Jupyter Notebook并在Sandbox中執(zhí)行，具有以下特點：

1. 與其他用戶和互聯(lián)網(wǎng)隔離的防火墻

2. 支持高達100MB的上傳/下載（包括.csv、.xls、.png、.jpeg、.mov、.mp3、.epub、.pdf、.zip等整個Git存儲庫的文件）

3. 預裝了超過330個庫，如 pandas（數(shù)據(jù)分析）、matplotlib、seaborn、folium（圖表和地圖）、pytesseract（OCR）、Pillow（圖像處理）、Pymovie（ffmpeg）、Scikit-Learn 和 PyTorch、Tensorflow（機器學習）

它本身是作為ChatGPT插件更新的一部分于3月23日官宣的，并由Andrew Mayne和Greg Brockman進行了專門的演示。

Alpha測持續(xù)了3個月。

最后，在7月6日至8日間，作為一項可選擇的測試版功能向所有約200萬的ChatGPT Plus用戶推出。

由于這些功能可以在代碼中靈活且無限地組合，很難完全列舉出這個功能所有的潛力。

但通過示例學習（例如使用p5.js創(chuàng)建游戲、繪制表情包、創(chuàng)建交互式儀表板、數(shù)據(jù)預處理（包括季節(jié)性）、編寫復雜的AST操作代碼、大規(guī)模人臉檢測，參見 Discord 上的 #code-interpreter-output 頻道）并瀏覽庫列表是很有幫助的。

Ethan Mollick提供了一些樣本，他并不懂Python，但非常擅長從代碼解釋器中獲取結(jié)果

Ethan還將他的經(jīng)驗總結(jié)為一份適用于代碼解釋器的系統(tǒng)提示。

代碼解釋器實際上引入了兩個新的東西 – 沙盒和模型：

7月之前的大部分Alpha測試都是側(cè)重于Python沙盒以及用戶可以在沙盒里做什么，只是偶爾會用到自主編碼的能力。

但在發(fā)布后，功能的重點變成了通過代碼解釋器所能提供的模型的質(zhì)量上。

據(jù)傳聞，它似乎比當今的GPT-4更好（在編寫代碼、自主進行多個步驟、決定何時不繼續(xù)并要求用戶在一組選項中進行選擇方面）。

這個模型的自主性需要親眼看到才能相信。以下是它在沒有任何人類輸入的情況下進行編碼和調(diào)試的示例：

這種模型的進步之所以令人驚嘆，是因為它將模型與模態(tài)性能夠完美地結(jié)合在一起，就像之前的 ChatGPT 一樣。

當然它也有一些缺點和限制：

1. 環(huán)境經(jīng)常重置代碼執(zhí)行狀態(tài)，丟失已上傳的文件，并且其從故障中恢復的能力有限。
2. 它的OCR功能與GPT-4 Vision相去甚遠。
3. 它會拒絕做它能做的事情，而你必須堅持讓它做。
4. 它無法在代碼中調(diào)用GPT3/4，因為它無法訪問網(wǎng)絡，因此無法執(zhí)行諸如數(shù)據(jù)增強之類的任務，因為它試圖編寫解決問題的代碼。

但拋開這些不足，總體來說，所有人對代碼解釋器的評價都是非常高的：

Karpathy：「代碼解釋器 Beta 功能非常強大。它是你的個人數(shù)據(jù)分析師：可以讀取上傳的文件、執(zhí)行代碼、生成圖表、進行統(tǒng)計分析等等。我預計社區(qū)需要一些時間來充分發(fā)揮它的潛力?！?/p>

Simon Willison：「我開始使用Code Interprete后，它完成了我接下來兩年的計劃的所有任務?！?/p>

三、推理：大模型下一個最前沿的方向

在我們與George Hotz的對話之后，引發(fā)了一場關(guān)于OpenAI是否「沒有創(chuàng)意」、GPT-4是否真的「只是8個220B專家模型」的討論。

暫且不論像PanGu這樣的萬億參數(shù)級模型的Routed Language Models和Switch Transformers的工作是否是真正的進步，代碼解釋器表明，只要不將進步的定義局限于純粹的語言模型推理，仍然有提升的空間，并且OpenAI已經(jīng)抓住了關(guān)鍵的這一點。

2017年，Noam Brown開發(fā)了Libratus，這是一個在12萬次無限制德州撲克對決中擊敗了四名頂級職業(yè)選手的人工智能。

Noam Brown在Lex的訪談中談到自己在這個項目中產(chǎn)生的最重要的一個想法：

神經(jīng)網(wǎng)絡通常需要大約100毫秒的時間才能給出一個回答…但我們發(fā)現(xiàn)，如果你做一點搜索，就能使預先計算的策略（pre-computed strategy）擴大1000倍。而只需做一點搜索。就能使我們之前的所有研究都成了垃圾。

這個想法現(xiàn)在看起來是那么的顯而易見：

• 在現(xiàn)實生活中，當面臨一個更困難的問題時，人們會花更長時間思考，而不是面對一個更容易的問題。但是GPT3對于「一個球是圓的嗎？」和「P = NP？」這樣的問題幾乎花費相同的時間來回答。那么，如果我們讓它花上一年的時間呢？
• 我們已經(jīng)看到Kojima著名的論文「讓我們逐步思考」，通過允許模型在上下文中外化其思考過程并增加推理時間，就大大改善了語言模型的性能。Beam和Tree of Thought類型的搜索能夠更有效地利用推理時間。
• AI的每一個重大飛躍都源于某種能力的大量擴展（scaling）。Transformer 解鎖了可并行預訓練計算的能力。掩碼語言建模（Masked Language Modeling）讓我們可以處理大量的無標簽數(shù)據(jù)。規(guī)模定律（Scaling Law）為我們提供了擴展模型規(guī)模的地圖。似乎很明顯，推理時間的計算/「實時的搜索」是下一個有希望的前沿防線，用Noam Brown的話來說「只需將時間話在上面就一定會有豐厚回報」。

Noam后來在2019年利用這個想法解決了6人德州撲克問題，然后在2022年利用這一見解解決了Diplomacy游戲（感謝了AlphaGo和AlphaZero的搜索算法）。

上個月，他仍在考慮這個問題：

兩周后，他加入了OpenAI。

四、代碼生成、沙盒和智能體云（Agent Cloud）

我一直在強調(diào) LLM 編碼能力的特殊地位。

這是 AI 工程師崛起的重要推動因素。

這不僅僅是一個「噢，很可愛，Copilot 對開發(fā)人員有好處，但不太適合其他人」的故事 – LLM 代碼是普遍有用的，即使對于不懂編程的人來說。

我所知道的關(guān)于「Code Core」的最早實驗來自 Riley Goodside，他在去年在「你是GPT-3，你不能做數(shù)學」中展示了這一點。

這個實驗第一次表明了，要彌補LLM的缺陷（如數(shù)學計算、與外部環(huán)境的交互、可解釋性、速度/成本）的最佳方式是：

利用編寫好的代碼在LLM之外完成任務。

Nvidia的Voyager代理提供了將這一思路推向其邏輯結(jié)論的路線圖：

當然，Voyager也存在一個明顯的問題：現(xiàn)實世界比Minecraft更加隨機，文檔化程度更低，反饋周期更長。

就像Minion AI，Multion和AutoGPT一樣，當前所有的智能體實例都可在實時瀏覽器/桌面上運行。

這使得潛在的幻覺和錯誤就是災難性的，形成了就像「自動駕駛汽車中總是不得不把手放在方向盤上」一樣的情況。

自從Ada Lovelace在Babbage Difference Engine存在之前就開始編寫代碼以來，開發(fā)人員就一直在用現(xiàn)實中的人群進行測試。

但最終，要知道代碼是否可以運行并按預期執(zhí)行，唯一的方法就是為其創(chuàng)建一個沙盒。（而代碼解釋器就能和用戶一起創(chuàng)建無數(shù)個這樣的沙盒）

大部分的代碼生成/沙盒功能可以在本地完成。

但隨著《本地主機的終結(jié)》（一篇討論未來本地開發(fā)環(huán)境將會被云端開發(fā)環(huán)境取代的文章）中描述的情況越來越近。

越來越多的代理構(gòu)建者和用戶意識到構(gòu)建和運行這些LLM推理過程的代碼片段所需的云基礎(chǔ)設(shè)施的需求。

我們可以合理地預未來代理云的興起，以滿足這一需求。

這實際上是一種新型的無服務器基礎(chǔ)設(shè)施需求。

它不僅是臨時的和可編程的，還將具備特殊的功能以提供必要的反饋給非人類操作者。

毫不奇怪，有一系列的可供選擇的產(chǎn)品來適應這個新興的代理云行業(yè)：

• 來自 Replit 的 Amjad 已經(jīng)被公開討論了
• E2B 的Vasek擁有一個開源的Firecracker microVM實現(xiàn)
• Codesandbox的Ives也有一個實現(xiàn)
• Fly的Kurt在5月份推出了Fly Machines

你會注意到他們都使用了Firecracker，這個亞馬遜在2018年開源的QEMU替代品微型虛擬機技術(shù)（對于一個通常不以開源軟件領(lǐng)導者而聞名的公司來說，這是一個不錯的勝利）。

然而，一個對比性的方法可能來自于Deno（在JavaScript領(lǐng)域）和Modal（在Python領(lǐng)域），它們的自動配置運行時提供了更輕量級的代理開發(fā)者和基礎(chǔ)設(shè)施提供者之間的協(xié)議，但熟悉程度更低。

當然，OpenAI構(gòu)建了自己的代理云，為200萬用戶提供托管和擴展代碼解釋器。

多年來，他們一直在使用這個技術(shù)，并且我們其他人才剛剛意識到它的重要性。

五、通往 GPT-5 的道路：代碼增強推理

將所有這些綜合起來，我們可以將代碼解釋器與先前的方法進行對比：

就像上圖列的一樣，考慮到主要和次要版本升級的改進，考慮到代碼解釋器賦予了模型這么多的新能力，我認為代碼解釋器是「GPT 4.5」。

在我們的播客中，我們還會注意到，GPT4的重度使用者堅信GPT4基本版的質(zhì)量已經(jīng)有所下降（雖然OpenAI的Logan 聲稱服務的模型沒有改變）。

這些粉絲同時也報告稱，在沒有編寫代碼的情況下，代碼解釋器的輸出與原始的GPT4 在「削弱」之前的輸出一樣好。

假設(shè)這是真實的（很難證明，沒有明確的代碼解釋器 API 來運行 lm-eval-harness），很可能是為了讓代碼解釋器能夠編寫代碼而進行的額外微調(diào)也改善了整體輸出質(zhì)量（這是我們從研究和Replit的經(jīng)驗，再考慮到GPT3.5本身的起源，即 code-davinci-002，所得到的結(jié)果）。

這使得代碼解釋器的基本模型，即使沒有沙盒，從模型質(zhì)量上來看也是「GPT 4.5」。

OpenAI的領(lǐng)先優(yōu)勢：

Sundar Pichai在6月份宣布了 Google Bard 的「代碼執(zhí)行」功能。

聲稱Bard可以執(zhí)行簡單的無依賴性的Python功能，比如數(shù)字相加和字符串反轉(zhuǎn)。

有趣的是，在一個月后我重新運行Google宣傳時相同提示，發(fā)現(xiàn)完全用不了了！

與此同時，OpenAI正在推出一個全新的LLM編碼范式。

OpenAI的領(lǐng)先優(yōu)勢令人難以置信！

參考資料：

https://www.latent.space/p/code-interpreter#details