newsence

播客訪談:Jeremy Howard 對大語言模型持悲觀看法

Lesswrong·30 天前

Jeremy Howard 認為大語言模型擅長透過內插法進行組合式創意,但在超出訓練分佈的真正創新上表現不佳,這使得它們在處理先進研發與複雜軟體工程時效果有限。

Jeremy Howard 最近^([1]) 接受了 Machine Learning Street Talk 播客的採訪:YouTube 連結互動式逐字稿PDF 逐字稿

Jeremy 在 2018 年共同發明了大型語言模型(LLMs),並教授了優秀的 fast.ai 線上課程(這在我學習機器學習時非常有幫助)。他一直在使用 LLM,例如他 90% 的新程式碼是由 LLM 編寫的(見下文)。

因此,我認為他對 LLM 的「看空」^([2]) 觀點是一個有趣的數據點,我將其分享出來供大家討論。

以下是播客中一些相關的摘錄,重點放在看空 LLM 的部分!(這些並非 100% 精確的引言,而是為了提高可讀性而進行了整理。)

你知道 Piotr Woźniak,他是我非常尊敬的一個人,他重新發現了間隔重複學習,建立了 SuperMemo 系統,是現代記憶大師:他將一生奉獻於記憶事物的全部原因,是因為他相信創意來自於記住大量的事物。也就是說,將你記住的東西以有趣的方式組合起來,是發揮創意的一種絕佳方式。

LLM 實際上非常擅長這一點。

但有一種創意是它們完全不擅長的,那就是跳出分佈之外……

你必須對這些事情保持非常細微的觀察,因為如果你說「它們沒有創意」,可能會給人錯誤的印象,因為它們可以做出看起來非常有創意的事情。

但如果問題是:它們真的能推斷出訓練分佈之外的東西嗎?答案是:不,它們不能。但訓練分佈是如此之大,在它們之間進行內插(interpolate)的方式又是如此之多,以至於我們還不知道其局限性在哪裡。

但我每天都能看到這一點,因為我的工作是研發(R&D)。我經常處於訓練數據的邊緣或之外。我正在做以前沒人做過的事情。這裡有一種奇怪的現象,我不知道你是否見過,但我每天都會見到好幾次:LLM 會從極其聰明變得比愚蠢還糟糕,比如連世界運作最基本的前提都不理解。這就像是:噢,糟了,我掉出了訓練數據分佈。它變笨了。然後,再繼續討論下去就沒有意義了,因為在那一刻你已經失去它了。……

我的意思是,我認為它們無法超出其分佈,因為這就是那種數學模型無法做到的事情。我的意思是,它或許能做,但做不好。

你知道,當你觀察將曲線擬合到數據的二維案例時,一旦你超出了數據覆蓋的區域,曲線就會向瘋狂的方向消失在空間中。這就是我們正在做的事情,只是我們是在多維空間中進行。我想 Margaret Boden 可能會對「組合創意」(compositional creativity)在你能組合整個人類知識庫時能走多遠感到相當震驚。我認為這正是人們經常感到困惑的地方,因為這就像——

例如,我昨天正和 Chris Lattner 聊到 Anthropic 如何讓 Claude 編寫 C 編譯器。他們說:「噢,這是一個潔淨室(clean-room)開發的 C 編譯器。你可以看出它是潔淨室開發的,因為它是用 Rust 創建的。」Chris 創建了現今可能最廣泛使用的 C / C++ 編譯器 Clang,它建立在 LLVM 之上,而 LLVM 是最廣泛使用的編譯器基礎。他們覺得:「Chris 沒有使用 Rust。我們也沒有給它任何編譯器源代碼的訪問權限。所以這是一個潔淨室實現。」

但這誤解了 LLM 的運作方式。對吧?事實是:Chris 所有的工作都在訓練數據中,出現了無數次。LLVM 被廣泛使用,許多東西都建立在它之上,包括大量的 C 和 C++ 編譯器。將其轉換為 Rust 是訓練數據各部分之間的內插。這是一個風格遷移(style transfer)問題。所以這充其量只是組合創意,如果你還能稱之為創意的話。當你查看它創建的儲存庫(repo)時,你就能看到這一點。它複製了部分 LLVM 代碼,而 Chris 今天會說:「噢,我犯了個錯誤。我不應該那樣做。沒人會那樣做。」噢,哇。看。Claude C 編譯器是唯一一個也那樣做的。這不是偶然發生的。這發生是因為你實際上並不是在發揮創意。你實際上只是在訓練數據中尋找 Rust 相關事物和構建編譯器相關事物之間的非線性平均點。……

我對數學的熟悉程度遠不如計算機科學,但從與數學家的交流中,他們告訴我,像艾狄胥(Erdős)問題之類的事情也是如此。其中一些是新解決的,但它們並不是靈感的火花。你知道,它們解決的是那些你可以通過將人類已經弄清楚的非常密切相關的事物揉合在一起來解決的問題。……

問題在於,這些人最近都不是軟體工程師。我不確定 Dario 是否曾經擔任過軟體工程師。軟體工程是一門不尋常的學科,很多人誤以為它等同於在 IDE 中輸入代碼。編碼是另一種風格遷移問題。你獲取要解決的問題的規範,你可以利用你的組合創意找到訓練數據中經過內插後能解決該問題的部分,並將其與目標語言的語法進行內插,然後你就得到了代碼。

幾十年前 Fred Brooks 寫過一篇非常有名的文章《沒有銀彈》(No Silver Bullet),聽起來簡直就像是在談論今天。他指出了一個非常相似的現象,在那個年代,大家都在說:「噢,看看這些新的第四代語言之類的東西,你知道,我們不再需要任何軟體工程師了,因為軟體現在這麼容易編寫,任何人都能寫。」他說,他猜測你最多能獲得 30% 的提升。他特別提到在未來十年內提升 30%,但我認為他不需要限制得那麼死。因為軟體工程中的絕大部分工作並不是輸入代碼。

所以在某種意義上,Dario 所說的部分內容是對的:對於現在相當多的人來說,他們的大部分代碼都是由語言模型輸入的。對我來說也是如此。大約是 90%。但這並沒有讓我那麼多產,因為那從來都不是緩慢的部分。它在研究方面也給了我很大幫助,比如弄清楚哪些文件會被改動。

但每當我嘗試讓 LLM 設計一個以前沒有被多次設計過的解決方案時,結果都很糟糕。因為它每次實際給我的,都是外表看起來有點相似的東西的設計。而這通常會是一場災難,因為外表看起來有點相似的東西,而我字面上是想創造一些新的東西來擺脫那個相似的東西。這非常具有誤導性。……

假裝聰明與真正聰明之間的區別完全不重要,只要你處於假裝有效的區域內。所以對於很多任務來說,LLM 只是假裝聰明其實沒關係,因為出於所有實際目的,這根本不重要,直到你達到它無法再假裝的地步。然後你會意識到:天哪,這東西太笨了。

  • ^(^) 該播客於 2026 年 3 月 3 日發布。不確定具體的錄製時間,但肯定是在前一個月內,因為他們談到了 2 月 5 日的一篇部落格文章

  • ^(^) 我的意思是,與 2026 年初 LessWrong 的時代精神相比,他是「看空」的——這其實說明不了什麼!

參與討論

https://lesswrong.com/posts/hvun2mP2yEr4kyKWk/podcast-jeremy-howard-is-bearish-on-llms