更好的模型真的更好嗎？

每週都有新的模型、新的方法,還有新的東西可以玩。每週都有人問我:「你試過 o1 Pro 了嗎?Phi 4 呢?Midjourney 6.1 呢?」我一直在想,我要怎麼判斷呢?

當然,其中一個答案是看基準測試的結果,但先不談這些測試結果的意義有多大,它們並不能告訴我現在能做些什麼是以前做不到或做不好的。你也可以準備一份文件,裡面記滿精心設計的邏輯題來測試,但這其實就是在做自己的基準測試,這又能告訴我們什麼呢?

比較實際的做法是,你可以用自己的工作流程來測試。這個模型表現得更好嗎?但在這裡我們遇到了一個問題,因為有些任務,更好的模型確實能產生更好、更準確的結果,但其他任務卻不存在「更好」或「更準確」的結果,只有對與錯的區別。

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

同樣地,有些任務的錯誤很容易發現和修正。如果你請 ChatGPT 幫你草擬一封電子郵件,或是提供一些料理建議,它可能會有一些錯誤,但你可以看出來並加以修正。

因此,生成式 AI 在軟體開發和行銷這兩個領域具有明確、快速且強大的產品市場契合度:錯誤通常很容易發現(或測試),而且不一定存在所謂的標準答案。如果我要求為新產品或品牌寫幾百字的文案,可能並沒有「錯誤」的答案,而且如果是你自己的產品,你就能發現問題所在——這仍然非常實用。我總是將上一波機器學習比喻為「無限實習生」。如果你有 100 位實習生,你可以請他們做一堆工作,你需要檢查結果,其中一些結果可能不太理想,但這仍然比你從頭開始獨自完成所有工作要好得多。

然而,還有一大類我們希望能夠自動化的任務,這些任務既枯燥又耗時,且無法用傳統軟體完成,而其結果品質不是以百分比來衡量,而是非黑即白。對某些任務而言,答案不是好或壞的問題,而是對或錯的問題。

如果我需要處理的事情有明確的對錯之分,而且我不是該領域的專家,或者沒有將所有基礎資料都記在腦中,還必須重複所有工作來驗證結果,那麼在現階段,我根本無法使用 AI 來完成這類工作。

這裡有一個我經常遇到的實際例子,是我希望能夠自動化的類型。我向 ChatGPT 4 詢問 1980 年美國有多少電梯操作員。美國人口普查局確實收集並發布了這項資料:答案是 21,982 人(PDF 第 17 頁可見)。

首先,我不看任何資料就直接回答,得到一個具體但沒有來源且錯誤的答案。接著我試著提供主要資料來源,結果得到另一個不同但仍然錯誤的答案,雖然列出了美國人口普查局的資料來源,而且第一個連結確實連到正確的 PDF 檔案⋯⋯但數字依然是錯的。嗯,那麼直接給它 PDF 檔案試試?不行。明確指出要看 PDF 檔案的哪個部分?不行。要求它瀏覽網路?不行,不行,不行⋯⋯

這裡的問題不在於數字錯誤,而是我若不親自查證就無從得知正確答案。答案可能是對的,用不同的提示語可能會得到更接近正確的答案。如果我付費升級到 Pro 版本,或許得到正確答案的機率會更高。但我需要的不是「可能」比較正確的答案,特別是在我無法判斷其正確性的情況下。我需要的是確實正確的答案。

當然,這些模型不會給出「正確」答案。它們是機率統計系統,只會告訴你什麼是好的答案可能看起來的樣子。它們不是能告訴你答案是什麼的確定性系統。它們不具備「知道」或「理解」的能力——它們只是在近似。「更好」的模型可以更接近答案,在某些特定類型的問題上可能會表現得特別出色(儘管我們可能不知道原因,甚至無法理解這些類型的分類標準)。但這仍然不等同於提供「正確」的答案——這與一個能「知道」或「理解」應該要找到標示著 1980 年的欄位和標示著「電梯操作員」的列的模型是不同的。

這種情況在今年或這十年間是否會有所改變,以及如何改變,是關於這些模型能否持續擴展的核心爭論之一,也涉及人工通用智慧(AGI)的討論。目前我們唯一能確定的是,我們缺乏可以解答這些問題的理論框架。我們並不知道答案。或許這種「理解力」會隨著模型規模擴大而自然產生;又或許就像芝諾悖論一樣,模型永遠無法達到目標,但仍能達到 99.99% 的正確率,因此它們是否真正「理解」可能也不那麼重要。也許我們需要其他未知的理論突破。也許 OpenAI 的 O3 中的「推理」能力是解決之道,又或許不是。儘管許多人都有自己的見解,但目前為止,我們仍無從得知。暫時而言,這些「錯誤率」(如果這樣描述是恰當的話)並不是靠一點工程改進就能解決的問題,這和 iPhone 後來加入複製貼上功能,或是撥號上網被寬頻取代的情況不同:就我們所知,這是這項技術的根本特性。

這引發了幾個層面的問題。

從狹義來看,現今大多數運用生成式 AI 來建立公司的人,都希望能在大型企業中自動化那些枯燥的後台流程。他們是將生成式 AI 模型作為 API 呼叫,封裝在傳統的確定性軟體中。他們透過工具、流程、控制和使用者體驗,以及前處理和後處理來管理錯誤率(還有我在其他地方經常提到的聊天機器人的使用者體驗落差)。他們給這匹馬戴上馬具、眼罩和韁繩,因為這是獲得可預測結果的唯一方式。

隨著模型效能不斷提升,它們或許能夠位居技術堆疊之首。LLM 告訴 SAP 需要執行哪些查詢,使用者也許能看到並驗證執行過程,但現在你是在運用機率系統來控制確定性系統。這是一種思考「代理型」系統的方式(可能會成為下一個重大突破,也可能在六個月內被遺忘)—— LLM 將其他所有功能都轉換成 API 呼叫。究竟哪種方式比較好?是該在可預測的框架內控制 LLM,還是該讓 LLM 擁有可預測的工具?

這讓我想到第二組問題。對我的「電梯操作員」問題最有價值的批評並非在於我的提示詞有誤,或使用了錯誤版本的錯誤模型,而是我本質上正試圖將非確定性系統用於確定性任務。我在嘗試將 LLM 當作 SQL 來使用:它本質上不是 SQL,而且在這方面表現不佳。如果你將我上述的電梯問題詢問 Claude,它會直接告訴你這看起來像是特定的資訊檢索問題,而且它很可能會產生幻覺,因此拒絕嘗試。這是將弱點轉化為優勢:LLMs 在判斷自己是否錯誤(一個確定性問題)方面表現很差,但在判斷自己是否可能錯誤(一個機率性問題)方面卻相當擅長。

「破壞式創新」的部分概念在於,重要的新科技往往在上一代科技所重視的領域表現不佳,但它們反而在其他重要方面有所突破。詢問 LLM 是否能進行精確的資訊檢索,就像在問 Apple II 是否能達到大型主機的運作時間,或是否能在 Netscape 裡建構 Photoshop。答案是否定的,但這並非重點,也不代表它們毫無用處。它們能做到其他事情,而這些「其他事情」更為重要,能吸引所有的投資、創新和企業發展。或許在 20 年後,它們也能完成舊有的任務——也許你最終能用個人電腦經營銀行,在瀏覽器中開發繪圖軟體——但這些在初期並非關鍵。它們開啟了全新的可能性。

那麼,生成式 AI 的「其他可能性」究竟是什麼?你如何從概念上理解這些錯誤率反而成為特色而非缺陷的領域?

機器學習最初應用於影像辨識,但它的意義遠不止於此。經過一段時間後,我們才發現將其視為模式辨識才是正確的思考方向。我們可以花很長時間去思考個人電腦、網路或行動裝置的「本質」。那麼生成式 AI 的本質又是什麼?我認為目前還沒有人真正理解透徹,但若只是在傳統軟體模式中將其視為新的 API 呼叫,就像是用新工具做舊事情。

有個關於法國人的英國老笑話:「這在實踐上很好,但理論上可行嗎?」過度沉溺於思考「這究竟代表什麼」,而不夠專注於實際開發和應用是不智的。這張圖表正好說明了這一點——矽谷的所有人都在開發 AI 應用。其中有些可能是錯誤的,許多可能很乏味,但總會有人找到新的突破。

然而,這些公司都押注在同一個理念是正確的:他們賭的是生成式 AI 無法完全泛化,因為如果能完全泛化,我們就不需要這麼多獨立的產品了。

這類謎題讓我想起了 2005 年 2 月,也就是將近 20 年前,我在坎城 MWC 行動通訊大會上與摩托羅拉一位副總裁的會面。當時 iPod 正夯,所有手機製造商都想要趕上它,但蘋果使用的微型硬碟一旦掉落就很容易損壞。摩托羅拉的這位主管指出,這部分是期待與認知的問題:如果你的 iPod 掉落壞掉了,你會怪自己,但如果你的手機掉落壞掉了,你會怪手機製造商,即使它們用的是相同的硬體。

六個月後,蘋果推出 Nano 時改用了快閃記憶體,這種記憶體掉落時不會損壞。但兩年後蘋果開始銷售 iPhone,現在你的手機掉落時確實會壞掉,但你可能會怪自己。無論如何,我們接受了一個掉落會壞、電池續航力從一週縮短到一天的裝置,以換取隨之而來的新功能。我們調整了期待。這種期待與認知的問題,現在似乎也適用於生成式 AI。在經歷了 50 年的消費性運算之後,我們已經被訓練去期待電腦是「正確的」——是可預測、確定性的系統。這就是我的電梯測試的前提。但如果你轉變這個期待,又能得到什麼回報呢?