更好的模型真的更好嗎？

「做，或不做——沒有嘗試這回事」

每週都有新的模型、新的方法和新的玩意兒可以嘗試。每週都有人問我：「你試過 o1 Pro 了嗎？Phi 4 呢？Midjourney 6.1 呢？」我一直在想，嗯，我該如何判斷它們的好壞？

其中一個答案當然是看基準測試（benchmarks），但撇開關於這些測試有多大意義的爭論不休，它們並不能告訴我，有哪些事是我以前做不到，或者以前做得不夠好的。你也可以準備一個裝滿精心設計的邏輯謎題的文字檔來測試，這本質上只是在做你自己的基準測試，但同樣地，這能告訴你什麼？

更實際的做法是，在自己的工作流程中嘗試它們。這個模型做得更好嗎？然而，在這裡我們遇到了一個問題，因為在某些任務中，更好的模型會產生更好、更準確的結果；但在其他任務中，根本不存在所謂「更好」的結果，也沒有所謂「更準確」，只有對或錯。

有些問題沒有「錯誤」答案；輸出的品質是主觀的，而「更好」是一個光譜。這是同一個提示詞應用在 Midjourney 第 3、4、5 和 6.1 版本上的結果。更好了！

同樣地，有些任務的錯誤很容易被發現並修正。如果你要求 ChatGPT 草擬一封電子郵件，或提供一些烹飪點子，它可能會出錯，但你可以看出來並加以修正。

因此，生成式 AI 具有明確、早期且強大「產品市場契合度」（product-market fit）的兩個領域是軟體開發和行銷：錯誤通常很容易被發現（或測試出來），而且不一定有錯誤答案。如果我要求為一個新產品或品牌寫幾百字的文案，可能沒有所謂的「錯誤」答案，而且如果是你的產品，你就能發現錯誤——這仍然非常有用。我過去常將上一波機器學習浪潮比作「無限的實習生」。如果你有 100 個實習生，你可以要求他們做一堆工作，你需要檢查結果，有些結果會很糟，但這仍然比你自己從頭開始做所有工作要好得多。

然而，還有一大類我們希望能自動化的任務，它們枯燥且耗時，無法由傳統軟體完成，而這些任務的結果品質不是百分比，而是二元的。對於某些任務，答案不是更好或更壞：而是對或不對。

如果我需要處理某些在重要方面確實有明確對錯答案的事，而我不是該領域的專家，或者沒有背下所有底層數據，必須親自重複所有工作來核對，那麼在今天，我完全無法使用大語言模型（LLM）來處理。

這是一個我經常遇到、希望能自動化的實際例子。我問 ChatGPT 4o，1980 年美國有多少人受僱為電梯操作員。美國人口普查局收集並發布了這些數據：答案是 21,982 人（見此處 PDF 第 17 頁）。

首先，我直接詢問，得到了一個具體、無來源且錯誤的答案。接著，我嘗試提供原始資料來源來引導它，結果得到另一個錯誤答案，並附帶一份來源清單，那確實是美國人口普查局，第一個連結也指向了正確的 PDF……但數字還是錯的。嗯。試試把實際的 PDF 給它？沒用。解釋到底要在 PDF 的哪裡看？沒用。要求它瀏覽網頁？沒用、沒用、沒用……

這裡的問題不在於數字是錯的，而在於如果不親自做一遍，我根本無從得知。它可能是對的。換個提示詞可能更接近正確。如果我付費訂閱 Pro，可能更有機會答對。但我不需要一個「可能更有機會答對」的答案，尤其是在我無法判斷的時候。我需要一個正確的答案。

當然，這些模型並不處理「正確」。它們是概率性的、統計性的系統，告訴你一個好的答案看起來大概會是什麼樣子。它們不是確定性的系統，告訴你答案是什麼。它們並不「知道」或「理解」——它們是近似。一個「更好」的模型近似得更精確，它在某一類問題上的表現可能比另一類好得多（儘管我們可能不知道原因，甚至不了解類別是什麼）。但這仍然不等同於提供一個「正確」的答案——這與一個「知道」或「理解」應該找到標為 1980 的列和標為「電梯操作員」的行的模型是不一樣的。

這種情況在今年或這十年內會如何改變、是否會改變，是關於這些模型是否會持續擴展（scaling），以及關於通用人工智慧（AGI）核心爭論的一部分。對此我們唯一能肯定的是，我們還沒有一個理論框架可以告訴我們答案。我們不知道。也許隨著模型規模擴大，這種「理解」會自發產生。也許，就像芝諾悖論（Zeno’s Paradoxes）一樣，模型永遠無法到達目標，但仍會趨向於 99.99% 的正確率，所以它們是否「理解」就不一定重要了。也許需要其他未知的理論突破。也許 OpenAI O3 中的「推理」是解決這條路徑的方法，也許不是。很多人都有看法，但到目前為止，我們還不知道。而且就目前而言，「錯誤率」（如果這甚至是思考這個問題的正確方式）並不是一個可以透過多一點工程手段就能彌補的差距，就像 iPhone 獲得剪下/貼上功能或撥接上網被寬頻取代那樣：就我們所知，錯誤率是這項技術的基本屬性。

這引發了幾類問題。

從狹義上講，目前大多數利用生成式 AI 創業、希望自動化大公司內部枯燥後勤流程的人，都是將生成式 AI 模型包裝成傳統確定性軟體內部的 API 調用。他們透過工具、流程、控制、使用者體驗（UX）以及預處理和後處理來管理錯誤率（以及聊天機器人本身的使用者體驗差距，我已在別處多次論述）。他們給馬套上韁繩、戴上眼罩並拉住韁繩，因為這是獲得可預測結果的唯一方法。

然而，隨著模型變得更好，它們可能會走向架構的最頂層。LLM 告訴 SAP 該執行哪些查詢，或許使用者可以查看並驗證發生了什麼，但現在你是用概率系統來控制確定性系統。這是思考「代理人」（agentic）系統（這可能是下一個大趨勢，也可能在六個月後被遺忘）的一種方式——LLM 將其他所有東西都變成了 API 調用。哪種方式更好？是在可預測的東西內部控制 LLM，還是給 LLM 可預測的工具？

這帶我進入第二組問題。對我的「電梯操作員」問題最有用的批評不是我提示得不對，或用了錯誤版本的模型，而是我原則上試圖將非確定性系統用於確定性任務。我試圖把 LLM 當作 SQL 來用：它不是，而且它不擅長那個。如果你在 Claude 上嘗試上述電梯問題，它會直截了當地告訴你，這看起來像是一個特定的信息檢索問題，它可能會產生幻覺，並拒絕嘗試。這是將弱點轉化為優點：LLM 非常不擅長判斷自己是否錯了（確定性問題），但非常擅長判斷自己可能會錯（概率性問題）。

「破壞式創新」（Disruption）的概念之一是，重要的新技術往往在上一代技術看重的事情上表現糟糕，但它們卻做了其他重要的事情。詢問 LLM 是否能進行非常具體且精確的信息檢索，可能就像詢問 Apple II 能否達到大型主機的運行時間，或者詢問是否能在 Netscape 瀏覽器內構建 Photoshop。不，它們真的做不到，但那不是重點，也不代表它們沒用。它們做了別的事情，而那件「別的事情」更重要，並吸引了所有的投資、創新和公司創建。也許 20 年後，它們也能做舊的事情——也許最終你可以在個人電腦上運行銀行系統，在瀏覽器中構建圖形軟體——但在開始時，那並不重要。它們開啟了別的東西。

那麼，生成式 AI 的那件「別的事情」是什麼？你如何從概念上思考那些錯誤率是「功能」而非「錯誤」的地方？

機器學習最初是以圖像識別的形式運作的，但它的意義遠不止於此，人們花了一段時間才意識到，思考它的正確方式是將其視為「模式識別」。你可以花很長時間哲學性地思考個人電腦、網路或行動裝置「真正」是什麼。生成式 AI 的本質又是什麼？我不認為現在有人真正弄清楚了，但在傳統軟體模式中將其作為一組新的 API 調用，感覺就像是用新東西來做舊事情。

與此同時，有一個古老的英國笑話，說一個法國人說：「這在實踐中都很好，但在理論上行得通嗎？」你可能會花太多時間哲學性地思考「這真正意味著什麼」，而沒有花足夠的時間去實踐、構建和使用。這張圖表正是如此——矽谷的每個人都在用 AI 構建東西。其中一些會是錯的，許多會很無聊，但其中一些會找到那個「新東西」。

然而，所有這些公司仍然是在賭一個哲學觀點是正確的：他們賭生成式 AI 不會完全通用化，因為如果它做到了，我們就不需要所有這些單獨的產品了。

這類謎題也讓我想起 2005 年 2 月（距今幾乎整整 20 年前）在坎城 MWC 行動通訊大會上，我與摩托羅拉（Motorola）一位副總裁的會面。當時 iPod 是熱門產品，所有手機代工廠都想與之匹敵，但蘋果使用的微型硬碟（micro-HDD）如果你摔到裝置，非常容易損壞。那位摩托羅拉的高管指出，這部分是預期和認知的問題：如果你摔壞了 iPod，你會怪自己；但如果你摔壞了手機，你會怪手機製造商，即使兩者使用的是相同的硬體。

六個月後，蘋果憑藉 Nano 從硬碟轉向了快閃記憶體，而快閃記憶體摔了也不會壞。但兩年後，蘋果開始銷售 iPhone，現在你的手機摔了確實會壞，但你可能會怪自己。無論如何，我們接受了一個摔了會壞、電池只能撐一天而不是一週的裝置，以換取隨之而來的新東西。我們改變了我們的預期。這種預期和認知的問題似乎也適用於現在的生成式 AI。在經歷了 50 年的消費級運算後，我們被訓練成期望電腦是「正確」的——是可預測的、確定性的系統。這就是我的電梯測試的前提。但如果你翻轉這種預期，你能換回什麼呢？