Andrej Karpathy 談論大型語言模型的認知缺陷

以下是 Dwarkesh Patel 對 Andrej Karpathy 的訪談 摘錄，我認為這對 LessWrong 的讀者很有價值。我認為他的觀點基本上是正確的。粗體強調為我所加。

Andrej Karpathy 00:29:53

我想我建立這個儲存庫（repository）大約花了一個多月的時間。我會說目前人們與代碼互動的方式主要分為三類。有些人完全拒絕所有的大型語言模型（LLM），他們只是從頭開始編寫。這可能已經不是正確的做法了。

中間的部分，也就是我所處的位置，是你仍然從頭編寫很多東西，但你會使用這些模型目前提供的自動補全（autocomplete）功能。所以當你開始編寫一小部分時，它會為你自動補全，你只需按 Tab 鍵即可。大多數時候它是正確的，有時則不然，然後你會進行編輯。但你仍然在很大程度上是你所寫內容的架構師。 然後是「氛圍編程」（vibe coding）：「嗨，請實現這個或那個，」按下 Enter，然後讓模型去做。那就是代理（agents）。

我確實覺得代理在非常特定的場景下有效，我也會在特定場景下使用它們。但這些都是你可以使用的工具，你必須了解它們擅長什麼、不擅長什麼，以及何時使用它們。例如，如果你在處理樣板（boilerplate）內容，代理就相當不錯。那些只是複製貼上的樣板代碼，它們非常擅長。它們非常擅長那些在網際網路上經常出現的東西，因為在這些模型的訓練集中有大量的範例。 對於某些功能，模型的表現會非常好。

我會說 nanochat 不是這類範例，因為它是一個相當獨特的儲存庫。我構建它的方式中並沒有那麼多代碼。它不是樣板代碼。它幾乎是智力密集型的代碼，每件事都必須非常精確地安排。模型有很多認知缺陷。舉個例子，它們一直誤解代碼，因為它們對於網際網路上所有典型做法的記憶太多了，而我正好沒有採用那些做法。例如——我不知道是否要深入細節——但模型一直認為我在寫普通的代碼，但我並不是。

Dwarkesh Patel 00:31:49

或許可以舉一個例子？

Andrej Karpathy 00:31:51

你有八個 GPU 都在進行前向和後向傳播。在它們之間同步梯度的方法是使用 PyTorch 的分散式數據並行（Distributed Data Parallel, DDP）容器，當你進行後向傳播時，它會自動開始通信並同步梯度。我沒有使用 DDP，因為我不想用，因為沒必要。我把它丟掉，並在優化器（optimizer）的步驟中編寫了自己的同步程序。模型一直試圖讓我使用 DDP 容器。它們非常擔心。這變得太技術化了，但我沒有使用那個容器，因為我不需要它，而且我有類似功能的自定義實現。

Dwarkesh Patel 00:32:26

它們就是無法理解你自己寫了一套。

Andrej Karpathy 00:32:28

它們無法跨越那一點。它們一直試圖弄亂風格。它們過於防禦性了。它們會寫出所有這些 try-catch 語句。它們一直試圖建立一個生產環境級別的代碼庫，而我的代碼中有一堆假設，這沒關係。我不需要所有這些額外的東西。所以我感覺它們在臃腫化代碼庫，增加複雜性，它們一直誤解，還多次使用已棄用的 API。這簡直是一團糟。淨收益並非正向。我可以進去清理它，但這並非淨正向的。

我也覺得必須用英文打出我想要的東西很煩人，因為打字太多了。如果我直接導航到我想要的代碼部分，去到我知道代碼必須出現的地方並開始輸入前幾個字母，自動補全就會捕捉到並直接給你代碼。這是一種指定你想要什麼的高信息頻寬方式。你指向你想要代碼的地方，輸入前幾個部分，模型就會完成它。

所以我的意思是，這些模型在技術棧的某些部分表現良好。我有兩個使用模型的例子，我認為很有啟發性。一個是我生成報告的時候。那更偏向樣板化，所以我對那部分內容進行了部分的「氛圍編程」。那沒問題，因為那不是關鍵任務內容，而且運行良好。

另一部分是我用 Rust 重寫分詞器（tokenizer）的時候。我不擅長 Rust，因為我對 Rust 還很陌生。所以在編寫一些 Rust 代碼時，確實有一些「氛圍編程」的成分。但我有一個我完全理解的 Python 實現，我只是在確保我正在製作一個更高效的版本，而且我有測試，所以我這樣做感覺更安全。它們增加了你可能不熟悉的語言或範式的可及性。我認為它們在那方面也非常有幫助。網上有大量的 Rust 代碼，模型對此相當擅長。我恰好對此了解不多，所以模型在那裡非常有用。

Dwarkesh Patel 00:34:23

這個問題之所以如此有趣，是因為人們對於 AI 爆炸式增長並迅速達到超智能的主要說法是，AI 會自動化 AI 工程和 AI 研究。他們看到你可以使用 Claude Code 從頭開始製作整個應用程序、CRUD 應用程序，然後心想：「如果你在 OpenAI 和 DeepMind 等內部擁有同樣的能力，想像一下有一千個你或一百萬個你並行工作，尋找微小的架構調整。」

聽你說這是它們非對稱地表現較差的部分，這非常有趣。 這對於預測 2027 年型 AI 爆炸是否可能在短期內發生非常相關。

Andrej Karpathy 00:35:05

這是一個很好的說法，你也觸及了為什麼我的時間線會長一點的原因。你是對的。它們不擅長那些從未被編寫過的代碼，這或許是一種說法，而這正是我們在構建這些模型時試圖實現的目標。

Dwarkesh Patel 00:35:19

一個非常幼稚的問題，但你添加到 nanochat 的架構調整，它們在某處的論文中，對吧？它們甚至可能在某處的儲存庫中。令人驚訝的是，當你說「添加 RoPE 嵌入」之類的時候，它們無法將其整合進去，或者它們以錯誤的方式處理？

Andrej Karpathy 00:35:42

這很困難。它們知道，但並非完全知道。它們不知道如何將其完全整合到儲存庫、你的風格、你的代碼和你的位置中，以及你正在做的一些自定義事情，還有它如何與儲存庫的所有假設相契合。它們確實有一些知識，但還沒有達到能夠整合並理解它的地步。

很多東西都在持續改進。目前，我首選的最先進模型是 GPT-5 Pro，那是一個非常強大的模型。如果我有 20 分鐘時間，我會複製貼上我的整個儲存庫，然後去問 GPT-5 Pro 這個「先知」一些問題。通常情況下還不錯，與一年前相比好得令人驚訝。

總體而言，模型還沒達到那種程度。我覺得業界跨出的步子太大了，試圖假裝這很神奇，但事實並非如此。那是「廢料」（slop）。他們沒有正視這一點，也許他們是在試圖融資之類的。我不確定發生了什麼，但我們正處於這個中間階段。模型很神奇。它們仍需要大量工作。目前，自動補全是我的甜蜜點。但有時，對於某些類型的代碼，我會求助於 LLM 代理。