人工智慧和程式設計的終章

原文來源：CSDN

圖片來源：由無界 AI生成

今年早些時候，Matt Welsh 宣佈程式設計正在步入終結。 他在 ACM Communications 中寫道：

我相信編寫程式的傳統想法正在走向消亡，事實上，對於除非常專業的應用程式之外的所有應用程式，正如我們所知，大多數軟體程式設計都將被經過訓練的人工智慧系統所取代。 在一些只需要 「簡單」 程序的情況下（畢竟，並不是所有東西都需要在 GPU 集群上運行的數千億個參數的模型），這些程式本身將直接由人工智慧生成，而不是手工編碼 。

幾周后，在一次演講中，威爾士擴大了他的死亡觀察範圍。 走向墳墓的不僅僅是程式設計藝術，還有整個計算機科學。 所有電腦科學都 「註定要失敗」 。 （下圖是演講的屏幕截圖。 ）

這些悲傷消息的傳遞者似乎並沒有悲痛欲絕。 儘管 Welsh 已經成為一名電腦科學教師和實踐者（在哈佛、谷歌、蘋果和其他地方），但他似乎渴望繼續下一步。 “無論如何，寫代碼很糟糕！” 他宣稱。

我自己對後程式設計未來的前景並不那麼樂觀。 首先，我持懷疑態度。 我認為我們還沒有跨過機器學會自己解決有趣的計算問題的門檻。 我認為我們還沒有接近這一點，或者正朝著正確的方向前進。 此外，如果事實證明我的觀點是錯誤的，我的衝動不是默許而是抵制。 一方面，我不歡迎我們的新人工智慧霸主。 即使他們被證明是比我更好的程式師，我仍然會繼續使用我的代碼編輯器和編譯器，謝謝。 “程式設計很糟糕？” 對我來說，它長期以來一直是我快樂和啟迪的源泉。 我發現它也是理解世界的一個有價值的工具。 在我能夠將一個想法簡化為代碼之前，我永遠不確定我是否理解了它。 為了從這種學習經驗中受益，我必須實際編寫程式，而不僅僅是說一些魔法詞並從阿拉丁的人工智慧燈中召喚一個精靈。

大型語言模型

可程式設計機器可以編寫自己的程式的想法深深植根於計算歷史。 Charles Babbage 早在 1836 年討論他的分析機計劃時就暗示了這種可能性。 當 Fortran 於 1957 年推出時，它的正式名稱是“FORTRAN 自動編碼系統”。 它的既定目標是讓計算機“為自己編碼問題並生成與人類編碼員一樣好的程式（但沒有錯誤）”。

Fortran 並沒有消除程式設計技巧（或錯誤），但它使過程變得不那麼乏味。 後來的語言和其他工具帶來了進一步的改進。 而全自動程式設計的夢想從未破滅。 機器似乎比大多數人更適合程式設計。 計算機有條不紊、受規則約束、挑剔且注重字面意思——所有這些特徵（無論正確與否）都與高手程式師聯繫在一起。

但諷刺的是，現在準備承擔程式設計任務的人工智慧系統卻奇怪地不像計算機。 他們的性格更像Deanna Troi，而不是 Commander Data。 邏輯一致性、因果推理和對細節的仔細關注並不是他們的強項。 當他們似乎在思考深刻的想法時，他們有不可思議的輝煌時刻，但他們也有可能遭遇驚人的失敗——公然、厚顏無恥的理性失誤。 他們讓我想起一句古老的俏皮話：人都會犯錯，而真正把事情搞砸則需要計算機。

最新的人工智慧系統被稱為大語言模型（LLM）。 與大多數其他近期人工智慧發明一樣，它們建立在人工神經網路之上，這是一種受大腦結構啟發的多層結構。 網路的節點類似於生物神經元，節點之間的連接起著突觸的作用，突觸是信號從一個神經元傳遞到另一個神經元的連接點。 訓練網路可以調整連接的強度或權重。 在語言模型中，訓練是通過向網路強制輸入大量文本來完成的。 該過程完成後，連接權重會對訓練文本的語言特徵的詳細統計數據進行編碼。 在最大的模型中，權重數量為1000億個或更多。

在這種情況下，模型一詞可能會產生誤導。 這個詞並不是指比例模型或微型模型，如模型飛機。 相反，它指的是預測模型，就像科學中常見的數學模型一樣。 正如大氣模型預測明天的天氣一樣，語言模型預測句子中的下一個單詞。

最著名的大型語言模型是 ChatGPT，它於去年秋天向公眾發佈，引起了極大的關注。 縮寫 GPT Gee Pee Tee：我的舌頭不斷地被這三個押韻的音節絆倒。 其他 AI 產品的名字很可愛，比如Bart、Claude、Llama; 我希望我能以同樣的精神重命名 GPT。 我會把它稱為 Geppetto，它與輔音的模式相呼應。 GPT 代表 Generative Pre-Trained Transformer （生成式預訓練變壓器）; 系統的聊天版本配備了對話式人機介面。 ChatGPT 由 OpenAI 開發，該公司成立於 2015 年，旨在將人工智慧從少數富有的科技公司的控制中解放出來。 OpenAI 成功地完成了這一使命，以至於它已經成為一家富有的科技公司。

ChatGPT 因其用詞方式、能說會道、流利的英語和其他語言而既令人欽佩又令人震驚。 該聊天機器人可以模仿著名作家、講笑話、寫情書、翻譯詩歌、寫垃圾郵件、“説明”學生完成家庭作業，以及編造錯誤資訊以進行政治惡作劇。 無論好壞，這些語言能力代表了驚人的技術進步。 曾經難以構建一個可理解的句子的電腦突然變成了能說會道的文字大師。 GPT 所說的可能是真的，也可能不是，但它幾乎總是措辭得體。

ChatGPT 發佈後不久，我驚訝地發現它的語言掌握擴展到了程式設計語言。 該模型的訓練集似乎不僅包括多種自然語言，還包括來自 GitHub 等公共存儲庫的大量程式原始程式碼。 基於此資源，GPT 能夠根據命令編寫新程式。 我發現這很令人驚訝，因為計算機對它們的輸入是如此挑剔和無情。 儘管電腦有時存在諸如拼寫錯誤之類的小錯誤，人類閱讀者仍會努力理解一句話。 但如果計算機得到的輸入，哪怕只有一個逗號或不匹配的括弧，它就會嘔吐亂碼。 具有潛在統計或概率性質的語言模型似乎不太可能維持超過幾行所需的精度。

我在這件事上又錯了。 大型語言模型的一項關鍵創新，即注意力機制，解決了這個問題。 當我開始自己使用 ChatGPT 進行實驗時，我很快發現它確實可以生成沒有粗心語法錯誤的程式。

但其他問題也隨之出現。

攀登單詞階梯

當你坐下來與機器聊天時，你立即會面臨一個尷尬的問題：“我們該聊什麼？ “ 我正在尋找一個可以公平衡量 ChatGPT 程式設計能力的主題。 我想要一個可以通過計算手段解決的問題，但這不需要做太多算術，而這被認為是大型語言模型的弱點之一。 我選擇了 Lewis Carroll 150 年前發明的字謎遊戲，並由 Donald E. Knuth 在 20 世紀 90 年代進行了深入分析。

在下面的文字記錄中，我這邊的每次交換都被標記為 BR; 玫瑰花結是 OpenAI 徽標，指定 ChatGPT 的回應。

當我看到這些句子在螢幕上展開時——聊天機器人逐字逐句地打出它們，有點不穩定，好像在停下來整理思緒——我立即被系統的英語能力所震驚。 GPT 以簡單、有力的散文形式列出了單詞梯子的所有基本特徵：這是一個遊戲或謎題，你通過一次更改一個字母從一個單詞到另一個單詞，梯子的每個梯級必須是一個英文單詞，目標 就是找到從起始詞到目標詞的最短可能序列。 我自己無法更好地解釋它。 最有説明的是 COLD -> WARM 的工作示例。

給人留下語言能力印象的不僅僅是單個句子。 句子按段落組織，段落串在一起形成連貫的話語。 太棒了！

同樣值得注意的是機器人處理模糊和草率輸入的能力。 我最初的查詢被表述為是或否問題，但 ChatGPT 正確地將其解釋為請求：「告訴我你對單詞階梯的瞭解。 “ 我的第二條指令忽略了任何印刷提示，表明 LEAD 和 GOLD 應被理解為文字，而不是金屬。 聊天機器人本來有權向我提供煉金配方，但它卻提供了缺少的引號。

然而，拋開所有這些語言和修辭的複雜性，我真正想測試的是該程序解決單詞階梯問題的能力。 上面文字記錄中的兩個示例都可以在網路上找到，因此它們很可能出現在 ChatGPT 的訓練數據中。 換句話說，大型語言模型可能只是記住了解決方案，而不是構建它們。 於是我提交了一個更艱巨的作業：

乍一看，ChatGPT 似乎再次取得了勝利，解決了我確信它以前從未遇到過的難題。 但仔細看看。 MARSH -> MARIS 需要兩個字母替換，PARIL -> APRIL 也是如此。 MARIS 和 PARIL 作為「有效詞」的地位也可能受到質疑。 我已投訴：

哇！ 該機器人提供了油腔滑調的懺悔和道歉，但“更正”的詞梯比以往任何時候都更加瘋狂。 看起來我們正在和鵝媽媽童謠中的矮胖子玩拼字遊戲，並且還宣稱 “我說 APRCHI 是一個詞，他就是一個詞！” 然後分散所有的瓷磚。

這並不是一次單獨的、獨一無二的失敗。 我用 ChatGPT 解決字梯的所有嘗試都偏離了軌道，儘管並不總是以同樣的方式。 在一個案例中，我要求提供從 REACH 到 GRASP 的階梯。 AI專家提出了這個解決方案：

到達 -> 教 ->桃子 ->和平 ->步伐 ->帕雷斯 ->解析 ->解析 ->解析 ->解析 ->公園 ->公園 ->公園 ->公園 ->帕雷斯 ->掌握。

還有這個：

劍 ->斯沃德 ->獎勵 ->重繪 ->重繪 ->重繪 ->重繪 ->重繪 ->重繪 ->償還 ->修復 ->和平

現在我們像剛學數數的小孩子一樣胡言亂語：“一，二，三，四，三，四，四，四，七，藍，十！ ”

到目前為止我展示的所有結果都是用 ChatGPT 3.5 版本記錄的。 我還嘗試了 3 月份推出的新改進版本 4.0。 更新后的機器人散發出同樣和藹可親的自信，但我擔心它也有同樣的傾向，陷入不經意的語無倫次：

梯子一開始很好，有四個步驟，遵循所有規則。 但隨後人工智慧就會走神。 從 PLAGE 到 PAGES 需要四個字母替換。 然後是 PASES，它不是一個單詞（據我所知），並且無論如何這裡都不需要，因為序列可以直接從 PAGES 轉到 PARES。 更多的愚蠢隨之而來。 儘管如此，我還是很欣賞關於 PLAGE 的資訊說明。

最近我也有機會嘗試 Llama 2，一個由 Meta（Facebook 人）出版的 LLM。 儘管這個模型是獨立於 GPT 開發的，但它似乎有一些相同的心理怪癖，例如制定規則然後無視它們。 當我要求一個連接 REACH 和 GRASP 的階梯時，Llama 2 提出了這樣的建議：

伸手 ->教 -> 浸出 -> 浸出 -> 語音 -> 坐 -> 英尺 -> 格拉斯普

預言和代碼猴子

Matt Welsh 提到了構建在大型語言模型之上的計算系統的兩種操作模式。 到目前為止，我們一直在我所說的預言模式下工作，在這種模式下，你提出一個問題，計算機就會返回一個答案。 你提供一對單詞，系統會找到一個連接它們的梯子，並執行到達那裡所需的任何計算。 您交付一個裝滿財務記錄的鞋盒，計算機填寫您的 1040 表格。 您編譯歷史氣候數據，計算機預測 2050 年的全球平均氣溫。

人工智慧預言機的替代品是人工智慧代碼猴子。 在第二種模式下，機器不會直接回答你的問題或執行你的計算; 相反，它會創建一個可以在傳統計算機上運行的程式。 您從機器人返回的不是字梯，而是生成字梯的程式，用您選擇的程式設計語言編寫。 您無需填寫完整的納稅申報表，而是獲得報稅軟體; 氣候模型代替了溫度預測。

讓我們用 ChatGPT 3.5 來嘗試一下：

您可以使用 wordLadder 功能來解決字梯謎題。 這是一個用法範例：

它的輸出為：

請注意，這是一個基本演示，對於更大的字梯或更複雜的場景，可能需要額外的優化或演算法，例如廣度優先搜索。

同樣，粗略地流覽一下輸出表明性能是成功的。 ChatGPT 的 Java 似乎和英語一樣流利。 它知道 if、while 和 for 語句的語法，以及所有挑剔的標點符號和括號規則。 機器生成的程式似乎將所有這些元件組合在一起以完成指定的任務。 還要注意大量的解釋性評論，這肯定是為了我們的利益，而不是為了它。 同樣，描述性變數名稱（currentWord、newWord、ladder）。

ChatGPT 還主動包含了在特定示例（ MARCH 到 APRIL ）上運行程式的說明，並且它列印出了結果，該結果與我們之前的交流中給出的答案相匹配。 該輸出是通過實際運行程式生成的嗎？ ChatGPT 並沒有明確說明，但它確實聲稱，如果您按照指示運行該程式，您將得到顯示的結果（在所有荒謬的榮耀中）。

我們可以通過將程式載入到 Web 瀏覽器或其他 Java 執行環境中來測試這一說法。 結論是：被抓！ 程序確實運行了，但沒有產生指定的結果。 該程式的真實輸出是：MARCH -> AARCH -> APRCH -> APRIH -> APRIL。 這個序列沒有那麼奇怪，因為它遵循一次只改變一個字母的規則，並且所有“單詞”都恰好有五個字母。 另一方面，在英語詞典中找不到任何中間“單詞”。

有一個簡單的演算法可以生成序列 MARCH -> AARCH -> APRCH -> APRIH -> APRIL。 只需從左到右逐步流覽起始單詞，更改每個位置的字母，使其與目標單詞中相應的字母匹配即可。 遵循此規則，任何一對五個字母的單詞都可以在不超過五個步驟內進行階梯排列。 MARCH -> APRIL 只需四步，因為中間的 R 不需要改變。 我無法想像有一種更簡單的方法來製作單詞階梯——當然，假設你願意讓任何字母的混雜都算作一個單詞。

ChatGPT 創建的程式可以使用這個快速而骯髒的例程，但它會做一些更加乏味的事情：它構建所有可能的梯子，其第一個梯級是起始詞，並繼續擴展這些梯子，直到它偶然發現一個包含 目標詞。 這是一種浪費驚人的蠻力演算法。 起始詞的每個字母都可以以 25 種方式進行更改。 因此，一個 5 個字母的單詞有 125 個可能的後繼者。 當你到達五級梯子時，就有1.9億種可能性。 （我在這裡提供的示例，例如 MARCH -> APRIL 和 REACH -> GRASP，有一個不變的字母，因此解決方案只需要四個步驟。 嘗試計算完整的五步解決方案耗盡了我的耐心。 ）

第 4 代代碼猴子

讓我們嘗試使用 ChatGPT 4 進行相同的代碼編寫練習。 給出相同的提示，新機器人的回應方式如下：

該程式具有相同的整體結構（一個 while 循環，內部有兩個嵌套的 for 迴圈），並且採用相同的演算法策略（在一個位置生成與給定單詞不同的所有字元串）。 但 GPT-4 版本有一個很大的新穎之處：承認單詞清單是必不可少的。 通過這種改變，我們終於有希望生成一個由真實單詞組成的階梯。

儘管 GPT-4 認識到需要一個清單，但它僅提供一個佔位元，即它為上面給出的 REACH -> GRASP 示例配置的 10 個單詞序列。 這個單詞清單的存根沒有多大用處，甚至對於重新生成虛假的“REACH-to-GRASP”階梯也沒有什麼用處。 如果您嘗試這樣做，程式將報告不存在梯子。 這個結果並沒有錯，因為給定的10個單詞並不能形成每一步僅更改一個字母的有效路徑。

即使清單中的單詞經過精心挑選，10 的詞彙量也是非常微不足道的。 對於語言模型來說，生成更大的單詞清單似乎是一項很容易的任務。 畢竟，LLM 是在龐大的文本語料庫上進行訓練的，其中幾乎所有英語單詞都可能至少出現一次，而常見單詞會出現數百萬次。 機器人不能提取這些單詞的代表性樣本嗎？ 答案顯然是否定的。 儘管 GPT 可以說已經「閱讀」 了所有這些文本，但它並沒有以任何易於訪問的形式存儲這些單詞。 （人類讀者也是如此。 你能通過回顧一生的閱讀經歷，列出你詞彙量中最常見的 10 個五字母單詞嗎？

當我要求 ChatGPT 4 生成一個單詞清單時，它抱歉地表示反對：“我很抱歉造成混亂，但作為 OpenAI 開發的人工智慧，我無法直接訪問單詞資料庫或獲取數據的能力來自外部來源......” 所以我嘗試了一些技巧，要求機器人寫一個 1000 字的故事，然後按頻率對故事的單詞進行排序。 這個詭計奏效了，但樣本太小，沒有多大用處。 只要堅持下去，我也許可以從 GPT 中哄出一個可以接受的清單，但我卻走了一條捷徑。 畢竟我不是OpenAI開發的AI，我可以訪問外部資源。 我挪用了 Knuth 為他的單詞階梯實驗而整理的 5,757 個五個字母的英語單詞清單。 有了這個清單，GPT-4 編寫的程式就會找到以下九步梯形圖：

到達 ->桃 ->和平 ->地方 ->平面 ->計劃 ->->玻璃 ->草 ->格拉斯

這個結果與 Knuth 自己的字梯程式的輸出完全匹配，該程式是他 30 年前在斯坦福大學 Graphbase 上發表的。

在這一點上，我必須承認，在一點外部説明下，ChatGPT 最終完成了我的要求。 它編寫了一個可以構造有效字梯的程式。 但我還是持保留態度。 儘管 GPT-4 和 Knuth 編寫的程式產生相同的輸出，但程式本身並不等效，甚至不相似。

Knuth 從相反的方向處理這個問題，不是從所有可能的五個字母字串的集合開始（它們的數量還不到 1200 萬），而是從他的 5,757 個常見英語單詞的小得多的清單開始。 然後，他構建一個圖（或網路），其中每個單詞都是一個節點，當且僅當對應的單詞相差一個字母時，兩個節點才通過邊連接。 下圖顯示了此類圖的一個片段。

在圖中，字梯是從起始節點到目標節點的一系列邊。 最佳梯子是最短的路徑，遍曆最少數量的邊。 例如，從 leash 到 retch 的最佳路徑是 leash -> leach -> reach -> retch，但也有更長的路徑，例如 leash -> leach -> beach -> peach -> reach -> retch。 為了尋找最短路徑，Knuth 採用了 Edsger W. Dijkstra 在 20 世紀 50 年代設計的演算法。

Knuth 的單詞階梯程式需要預先投資才能將簡單的單詞清單轉換為圖表。 另一方面，它避免了浪費地生成數千或數百萬個五個字母的字串，而這些字串不可能是後者的元素。 在解決 REACH -> GRASP 問題的過程中，GPT-4 程式產生了 219,180 個這樣的字串; 其中只有 2,792 個（略多於 1%）是真實單詞。

如果我所描述的各種單詞階梯程式是學生提交的，那麼我會給沒有單詞清單的版本打不及格的分數。 帶有清單的 GPT-4 程式會通過，但出於效率和優雅的考慮，我只會給 Knuth 程式打最高分。

為什麼聊天機器人偏愛劣質演算法？ 您只需通過谷歌搜索「字梯程式」 即可獲得線索。 幾乎所有排名靠前的結果都來自 Leetcode、GeeksForGeeks 和 RosettaCode 等網站。 這些網站顯然是為了迎合求職者和程式設計競賽的競爭對手，其解決方案要求生成每個單詞的所有125個單字母變體，就像GPT程式一樣。 因為這樣的網站數量眾多——似乎有數百個——它們比其他來源更重要，例如 Knuth 的書（如果這些文本確實出現在訓練集中的話）。 這是否意味著我們應該將錯誤的演算法選擇歸咎於 Leetcode，而不是 GPT？ 相反，我想指出協定不可避免的弱點，其中最常見的答案預設是正確的答案。

每當我想到大型語言模型正在編寫我們所有的軟體時，另一個相關的擔憂就會困擾著我。 新的演算法從哪裡來？ 大學語言模型可能會在重新混合現有專案的元素方面發揮創意，但我看不出它有什麼方法可以發明全新的、更好的東西。

** 梯子這個詞已經夠了！ **

我承認我已經太過分了，用一個特殊（且無關緊要的）問題的太多變體來折磨 ChatGPT。 也許大學語言模型在其他計算任務上表現得更好。 我嘗試過幾種，結果好壞參半。 我只想討論其中之一，我發現ChatGPT的努力相當令人心酸。

使用 ChatGPT 3.5，我詢問第 100 個斐波那契數的值。 請注意，我的問題是在 Oracle 模式下提出的; 我要求的是這個數位，而不是一個計算它的程式。 儘管如此，ChatGPT 仍自願編寫一個斐波那契程式，然後呈現該程序的輸出。

該程式實現的演算法在數學上是正確的; 它直接來自斐波那契數列的定義，斐波那契數列是從 {0， 1} 開始的序列的成員，每個後續元素都等於前兩項之和。 給出的答案也是正確的：354224848179261915075 確實是第100個斐波那契數。 所以有什麼問題？ 就是中間句：「當你運行這段代碼時，它將輸出第100個斐波那契數。 」 這不是真的。 如果運行代碼，您將得到錯誤的值 354224848179262000000。 最近版本的 Java 提供了 BigInt 數據類型來解決此問題，但必須顯式指定 BigInt，而 ChatGPT 程式不會這樣做。 這種異常現象的原因在Java 使用浮點運算，即使是整數值。 根據 IEEE 浮點標準，在不損失精度的情況下可以表示的最大整數是 253−1; 第 100 個斐波那契數大約是 268。 這就是我所說的令人心酸的思：ChatGPT 給出了正確的答案，但它聲稱用來計算該答案的方法無法提供它。 機器人一定是通過其他方式找到了正確的值，但具體方式並未透露。

將同樣的任務交給 ChatGPT 4.0 會讓我們踏上更加陌生的旅程。 在接下來的交互中，我啟動了 Code Interpreter，這是一個 ChatGPT 外掛程式，允許系統測試和運行它編寫的一些代碼。 顯然，機器人利用了這一功能，首先提出了一個因未知原因而失敗的程式：

這裡 ChatGPT 是用 Python 編寫的，Python 是 Code Interpreter 支援的主要程式設計語言。 編寫程式的第一次嘗試是基於斐波那契矩陣的求冪：

這是一種眾所周知且有效的方法，並且程序正確地實現了它。 然而，由於神秘的原因，代碼解釋器無法執行該程式。 （該代碼在標準 Python 環境中運行良好，並返回正確的答案。 ）

此時，機器人將轉向一個全新的方向並起飛，建議通過稱為比奈公式的數學恆等式來計算所需的斐波那契值。 它已經寫出了數學表達式，但隨後又改變了主意。 它正確地預見了數值精度的問題：如果給定 5 的平方根的精確值，該公式將產生精確的結果，但這是不可行的。

因此，現在 ChatGPT 採取了另一種策略，採用與 3.5 版本相同的反覆運算演算法。 這次我們得到了正確的答案，因為 Python（與 Java 不同）在處理大整數時沒有任何問題。

這次的表現給我留下了深刻的印象，不僅僅是正確的答案，還有系統勇敢的堅持。 儘管ChatGPT陷入困境，但它仍然堅持不懈，對意想不到的困難感到困惑，但拒絕放棄。 “嗯，那個矩陣法應該有效。 但是，無論如何，我們還是試試比奈公式吧...... 哦，等等，我忘了...... 不管怎樣，沒必要對此這麼花哨。 讓我們以顯而易見的、緩慢的方式來做吧。 我覺得這是一種非常人性化的解決問題的方法。 在機器中看到這種行為很奇怪。

記錄成功和失敗的分數

我的小實驗讓我對人工智慧神諭和人工智慧代碼猴子即將排擠人類程式員的說法表示懷疑。 我看到了一些成功，但更多的是失敗。 這個慘澹的記錄是在相對簡單的計算任務上編製的，這些任務的解決方案是眾所周知的並被廣泛發佈。

其他人對 LLM 代碼生成進行了更廣泛和更深入的評估。 在本文末尾的參考書目中，我列出了五項此類研究。 我想簡要總結一下他們報告的一些結果。

兩年前，Mark Chen 和 OpenAI 的 50 多名同事投入了大量精力來測量 Codex 的準確性，Codex 是 ChatGPT 3 的一個分支，專門用於編寫程序代碼。 （Codex 自此成為驅動 GitHub Copilot（“程式師的助手”）的引擎。 ） 創建了一套包含 164 個任務的任務，可以通過編寫 Python 程式來完成。 這些任務主要是教科書練習、程式設計競賽以及有關如何在編碼工作面試中取得好成績的（數量驚人的）文獻中的類型。 大多數任務只需幾行代碼即可完成。 示例：計算給定單詞中的元音數，確定整數是質數還是合數。

陳教授團隊還對定義成功和失敗的標準進行了一些思考。 由於 LLM 過程是不確定的（單詞選擇基於概率），因此模型可能會在第一次嘗試時生成有缺陷的程式，但如果允許繼續嘗試，最終會得出正確的回應。 一個稱為溫度的參數控制不確定性的程度。 在零溫度下，模型在每一步總是選擇最可能的單詞; 隨著溫度升高，隨機性被引入，允許選擇不太可能的單詞。 陳等人。 通過採用三個成功基準來考慮這種變化的可能性：

pass@1：LLM 在第一次嘗試時生成正確的程式

pass@10：生成的10個程式中至少有一個是正確的

pass@100：生成的100個程式中至少有一個是正確的

Pass@1 測試是在零溫度下進行的，因此模型始終會給出最佳猜測結果。 pass@10 和 pass@100 試驗是在更高的溫度下進行的，使系統能夠探索更廣泛的潛在解決方案。

作者在所有 164 項任務上評估了 Codex 的多個版本。 對於最大、功能最強大的 Codex 版本，pass@1 率約為 29%，pass@10 率為 47%，pass@100 達到 72%。 看到這些數字，我們應該感到印象深刻還是感到震驚？ Codex 在幾乎三分之一的時間（當溫度設置為零時）第一次嘗試就正確，這值得慶祝嗎？ 或者，如果您願意篩選 100 個提議的計劃，尋找一個正確的計劃，成功率會攀升至近四分之三？ 我個人的觀點是：如果您將當前這一代 LLM 視為長期研究計劃的開創性努力，那麼結果是令人鼓舞的。 但如果你認為這項技術可以立即替代手工編碼的軟體，那就沒什麼希望了。 我們還遠未達到必要的可靠性水準。

其他研究也得出了大致相似的結果。 Fredrico Cassano 等人。 評估多個 LLM 以各種程式設計語言生成代碼的表現; 他們報告的 pass@1 率範圍很廣，但只有兩個超過50%。 Alessio Buscemi 在 40 項編碼任務上測試了 ChatGPT 3.5，要求使用 10 種語言編寫的程式，並將每個查詢重複 10 次。 在 4,000 次試驗中，1,833 次產生了可以編譯和執行的代碼。 Liu Zhijie 等人。 他們對 ChatGPT 的評估基於 Leetcode 網站上發佈的問題。 通過將生成的代碼提交給自動 Leetcode 評分流程來評判結果。 所有問題的平均接受率範圍從 C 語言編寫的程式的 31% 到 Python 程式的 50%。 Liu 等人。 另一個有趣的觀察是：ChatGPT 在 2021 年 9 月（GPT 訓練集的截止日期）之後發佈的問題上得分要差得多。 他們推測機器人可能會更好地解決早期的問題，因為它在訓練期間已經看到了解決方案。

Li Zhong 和 Zilong Wang 最近發表的一篇論文超越了程序正確性的基本問題，考慮了魯棒性和可靠性。 生成的程式能否正確回應格式錯誤的輸入或外部錯誤，例如嘗試打開不存在的檔時？ 即使 LLM 的提示中包含了一個展示如何正確處理此類問題的範例，Zhong 和 Wang 發現生成的代碼在 30% 到 50% 的情況下都無法做到這一點。

除了這些令人沮喪的結果之外，我自己還有更多的疑慮。 幾乎所有測試都是通過簡短的代碼片段進行的。 一個在編寫 10 行程式時遇到困難的LLM 在編寫 100 行或 1,000 行程式時可能會遇到更大的困難。 此外，簡單的通過/失敗分級是對代碼品質的非常粗略的衡量。 考慮一下 Chen 小組基準測試套件中的素性測試。 這是 Codex 編寫的程式之一：

這段代碼被評為正確——它應該是正確的，因為它永遠不會將質數錯誤地分類為合數，反之亦然。 然而，當 n 很大時，您可能沒有耐心或壽命來等待判決。 該演算法嘗試將 n 除以 2 到 n−1 之間的每個整數。

LLM 不符常規的實用性

對於大型語言模型來說，現在還處於早期階段。 ChatGPT 發佈不到一年; 底層技術只有大約六年的歷史。 雖然我非常肯定自己宣稱 LLM 還沒有準備好征服編碼世界，但我不能如此自信地預測他們永遠不會。 這些模型肯定會改進，我們會更好地使用它們。 已經有一個新興行業提供 「即時工程」 指導，作為充分利用每個查詢的方法。

提高 LLM 表現的另一種方法可能是與另一種計算系統形成混合體，該系統配備邏輯和推理工具，而不是純粹的語言分析工具。 Doug Lenat 在他最近去世前夕，提議將 LLM 與 Cyc 結合起來，Cyc 是他花費四十年努力建立的一個巨大的常識資料庫。 Stephen Wolfram 正在致力於將 ChatGPT 集成到 Wolfram|Alpha 中，Wolfram|Alpha 是一個精選數據和演算法的在線集合。

儘管如此，一些阻礙 LLM 課程生成的障礙似乎很難克服。

語言模型通過簡單的方式發揮其魔力：在撰寫句子或段落的過程中，LLM 根據之前的單詞選擇下一個單詞。 這就像在手機上寫短信一樣：你輸入“我會見你......”，軟體會建議一些替代的延續：“明天”、“很快”、“稍後”。 在 LLM 中，每個候選人都會被分配一個概率，該概率是根據模型訓練集中所有文本的分析計算得出的。

一個多世紀前，俄羅斯數學家 A. A. Markov 首次探索了通過這種統計分析生成文本的想法。 他的過程現在被稱為 n-gram 模型，其中 n 是在選擇序列的下一個元素時要考慮的單詞（或字元或其他符號）的數量。 長期以來，我一直對 n-gram 過程著迷，儘管主要是因為它的喜劇可能性。 （在 40 年前發表的一篇文章中，我將其稱為“將文學變成胡言亂語的藝術。 ”）

當然，ChatGPT 和其他最近的 LLM 不僅僅是 n 元模型。 他們的神經網路捕獲的語言統計特徵遠遠超出了 n 個連續符號的序列。 特別重要的是注意力機制，它能夠跟蹤任意距離處選定符號之間的依賴關係。 在自然語言中，這種手段對於維持主語和動詞的一致性，或者將代詞與其所指對象相關聯非常有用。 在程式設計語言中，注意力機制確保了多部分語法結構的完整性，例如 if... then... else，並且它保持括號正確配對和嵌套。

然而，即使有了這些改進，LLM 本質上仍然是一種根據現有文本中單詞出現的概率構建新文本的工具。 以我的思維方式，那不是思考。 這是比較膚淺的東西，專注於文字而不是想法。 鑒於這種粗糙的機制，我對 LLM 能夠取得如此大的成就感到既驚訝又困惑。

幾十年來，人工智慧的建築師相信真正的智慧（無論是自然的還是人工的）需要一個世界的心理模型。 為了理解你周圍（和你內心）發生的事情，你需要對事物如何運作、它們如何組合在一起、接下來會發生什麼、因果關係有直覺。 萊納特堅持認為，最重要的知識是你在開始讀書之前很久就獲得的知識。 你通過跌倒來瞭解重力。 當你發現一座積木塔很容易被推倒但很難重建時，你就瞭解了熵。 在語言開始紮根之前，你會在嬰兒期瞭解痛苦、恐懼、饑餓和愛。 盒子里的大腦無法獲得這種體驗，因為無法直接進入物理或社會宇宙。

兩百五十年前，瑞士製表師 Pierre Jacquet-Droz 製造了一台可以用羽毛筆書寫的機械自動機。 這個發條裝置有數百個凸輪和齒輪，裝扮成一個坐在凳子上的小男孩。 啟動後，男孩將筆浸入墨水中，寫下一條簡短的資訊——最著名的是笛卡爾警句“我思故我在”。 多麼滑稽啊！ 但即使在 18 世紀，也沒有人相信塗鴉娃娃真的會思考。 LLM 懷疑論者會將 ChatGPT 歸入同一類別。

我要告訴你這些對比鮮明的 LLM 心態理論中哪一個是正確的嗎？ 我不是。 這兩種選擇都不吸引我。 如果 Bender 等人是對的，那麼我們必須面對這樣一個事實：一個沒有推理或感覺能力、沒有物質宇宙或社會互動經驗、沒有自我意識的小玩意兒，寫大學論文、創作說唱歌曲、 給失戀者提供建議。 知識、邏輯、情感都毫無價值; 油嘴滑舌就是全部。 這是一個顛覆性的主張。 如果 ChatGPT 能用這種無意識的表演來愚弄我們，也許我們也是騙子，他們的聲音和憤怒毫無意義。

另一方面，如果 Sutskever 是對的，那麼我們所珍視的人類經驗的大部分內容——隨著我們的成長和生活而慢慢演變的人格意識——可以通過互聯網閱讀這些文字就瞭解到。 如果真是這樣，那我其實就不用忍受初中那種難以言表的痛苦了， 我不必犯下所有那些導致如此心痛和困難的愚蠢錯誤; 沒有必要因與世界的碰撞而傷害我的自尊。 我本可以在舒適的扶手椅上閱讀所有這些內容; 僅僅言語就能使我達到一種頭腦清醒的成熟狀態，而不會在塑造靈魂的山谷中經歷所有的絆腳石和痛苦。

關於大型語言模型對計算機科學的地位和影響，我仍然有兩種看法（或者可能不止兩種！ ）。 人工智慧愛好者可能是對的。 這些模型可能會接管程式設計以及許多其他類型的工作和學習。 或者它們可能會失敗，就像其他有前途的人工智慧創新一樣。 我認為我們不用等太久就能得到答案。