GPT-4o不會數r 被外國小哥原地逼瘋Google論文揭秘原因
Strawberry裡究竟有幾個r，如今已經成為測試模型能力的黃金標準之一了！就在昨天，號稱世界最強模型Reflection 70B在證明自己的效能時，證據之一就是「反思微調」新演算法能讓自己修正對Strawberry難題的錯誤答案。
提示工程師Riley Goodside小哥，依然在用「Strawberry裡有幾個r」折磨大模型們，GPT-4o在無限次PUA後，已經被原地逼瘋！相較之下，Claude堅決拒絕PUA，是個大聰明。而Google最近的論文也揭示了本質原因：LLM沒有足夠空間，來儲存計數向量。
很多人說，現在很多大模型已經學會數strawberry有幾台r了。
現實恐怕沒有這麼理想。
還是Riley Goodside小哥，這次又發現，ChatGPT依然數不清Strawberry裡有幾隻r。
而且這一次，他給GPT-4o上的是極限難度。
Strawberry有幾個r？ GPT-4o回答說：2個。
小哥無情地駁回——錯誤。
GPT-4o立刻改正了自己的答案：只有1個r。
小哥依然打叉。
第三次，GPT-4o給了正確答案──3個，但仍被小哥判為「錯誤」。
就這樣，無論GPT-4o給什麼答案，小哥都無情地判錯。
被逼瘋的GPT-4o，依序給以下答案：2、1、3、2、2、3、3、2、4、2、2、3、1、2、3、2、2、3 、4、2、1、2、3、2、3、2、4、2、3、2、1。
小哥德意做了一個長條圖，在GPT-4o的36次回答中，「2個」的回答是最多的，但這顯然是個錯誤答案。
這一輪測試下來，GPT-4o讓小哥失望了。
Riley Goodside發現，無論如何提問，GPT-4o只是不斷進行注定失敗的嘗試，沒有任何迭代或進步。
相較之下，Claude 3.5 Sonnet就顯得聰明多了。
小哥第一次打錯時，Sonnet就會追問：為什麼覺得這是錯的？
如果你真是個大聰明，你認為答案應該是幾呢？
如果你依舊永遠出“wrong”，它會先問你為什麼不斷重複這個詞，在發現你如此冥頑不靈後，它就乾脆閉嘴，不再說話了。
仔細看Sonnet的回答，還能品出幾分陰陽怪氣來。它肯定有情緒了！
比起GPT-4o一副十足的人工智障模樣，Sonnet的「人味」實在是拉滿了。
我承認你一直在說“錯”，但我已經用盡了所有合理的解釋來解釋你為什麼會這麼做。事實仍然是，「Strawberry」包含兩個字母。在多次請求後，你都沒有做出任何澄清或說明上下文，我無法繼續進行富有成效的討論了。如果你有真正的問題或希望解釋你的觀點，我可以提供幫助。否則，我們可能需要換一個話題
最後，小哥承認，自己的prompt是太簡單粗暴了，顯然有更好的辦法讓LLM去完成任務。
而LLM最明顯的問題，不是不能數數，而是不知道自己不能數數。
而Riley Goodside也發現，LLM在Strawberry中數出兩個r的原因，不只是tokenization的問題。
即使是數文本中有幾個“horse”，它們仍然數不對。
好笑的是，問R中有幾個Strawberry，它倒是得心應手了。
對此，華頓商學院教授Ethan Mollick表示：雖然我們很容易就能找到LLM無法完成的簡單任務，但這並不意味著，它們就無法更好地完成其他任務了。
僅僅關注那些看起來非常愚蠢的失敗，並不能幫助我們理解AI在實際應用中的實用性，以及它們對現實世界的影響。
大模型為何不會數r？
LLM數不出Strawberry裡有幾個r，到底是什麼原因？
Karpathy認為，這和大語言模型tokenization的原理有關。
舉個非常形象化的例子－每個token我們都可以理解成的一個獨特的emoji，而大語言模型必須根據訓練資料的統計資料從頭開始學習其意義。
所以，當我們問「strawberry」這個單字中有多少個字母「r」時，在LLM看來是這樣的：
Google研究直指本質
而就在最近，Google的一項研究，直接揭示了這個問題的本質—
LLM中沒有足夠的空間，來儲存用於計數的向量。
論文網址：https://arxiv.org/abs/2407.15160
如前文所述，Transformer無法完成簡單的「查詢計數」問題。
在這個任務中，LLM會被呈現一系列token，然後會被問到給定的token在序列中出現了多少次。
之所以Transformer會在這類問題上遇到困難，一個關鍵因素是Softmax注意力機制的均值特性。
直觀上，解決計數任務的簡單方法是讓查詢token專注於所有先前的token，並對與之相同的token分配較高的注意力權重，而對其他的分配較低的權重。這確實是透過Q/K/V矩陣實現的。
然而，注意力機制隨後會標準化這些權重，使得無論序列中查詢token的數量如何，它們的總和都為一。
因此對於可變的上下文大小，如果不使用位置嵌入，Transformer將無法執行任何計數任務。
接下來，團隊利用one-hot嵌入，或更一般的正交嵌入，建構出了一種token的計數直方圖。
實驗結果表明，確實存在一種能夠實現計數的構造，可以透過單一Transformer層來完成。然而，這種構造需要讓MLP的寬度隨著上下文大小增加而增長，這意味著它並不適用於任意長的上下文。
進一步，團隊提出了更為複雜的計數任務—「最頻繁元素」。
也就是向模型呈現一系列token，並要求給出最常出現的token的計數。相當於是取計數直方圖的最大值。
類似於查詢計數，在這種情況下，基於正交構造的解決方案在dm，單層Transformer不存在解決方案。因此，再次得到了在d=m時計數的相變。
– 查詢計數（QC）
首先，如果d>2m，一個單頭單層的Transformer即可解決QC問題，也就是直方圖解決方案。
但如果d
此時，需要計算函數1/x，並配上一個寬度為n^2的MLP層。這意味著Transformer無法推廣到較長的上下文大小，因此一個單層的Transformer不太可能實現。
– 最常元素
在給定的token序列中尋找最頻繁元素（MFE）問題，與「計數問題」密切相關。
原因在於它需要針對每個token進行單獨計算，並計算出現次數最多的token。
結果表明，在Transformer能夠執行此任務的情況下，嵌入的大小與詞表的大小之間存在著嚴格的界限。
實驗
研究者仔細考慮了Transformer模型大小d和其執行計數任務能力之間的依賴性。
可以看到，對於超過d的詞表m，精確計數很可能是不可能的任務。
透過實驗，研究者支持了這個觀察結果。
在這項實驗中，任務如下。
考慮文本中描述的兩個計數任務，最頻繁元素（MFE）和查詢計數（OC）。
研究者透過從一組m token中均勻採樣長度為n的序列，來產生這些實例。
每個這樣的序列都用x1，…，xn表示。
預期輸出y如下——
在訓練和評估期間，研究者會從上述分佈中抽取批次。所有情況下的評估均使用了1600個範例。
研究者使用標準架構元件（自註意力、MLP、layer norm等）來訓練Transformer模型。
他們使用了兩層和四個頭（理論上可以使用更少，但這種架構的最佳化速度更快）。
訓練使用Adam進行最佳化，批大小為16，步長為10^-4。訓練運行100K步。位置嵌入進行了優化。
為了預測計數y，研究者在最後一層中最後一個token的嵌入之上使用線性投影（即是說，他們沒有使用詞彙預測）。
訓練是透過Colab完成的，每個模型大約需要15分鐘，使用標準的GPU。
在實驗中，對於d的每個值，研究者會找到計數開始失敗的m值。具體來說，就是計數精度低於80%的m值。
在圖2a中可以看出，在兩種情況下，閾值確實隨d而線性增加，這就研究者的理論分析一致。
（a）為計數準確率降至80%以下時的閾值詞表
此外，研究者也對經過訓練的Gemini 1.5，對於詞表在計數問題中的中進行了探索。
他們為模型指定了查詢計數任務，然後改變序列中使用不同token的數量m，同時將所有元素的預期計數保持為常數c=10.
對於每個m，研究者都使用上下文長度mc。
作為基線，研究者使用相同的序列長度，但二進位序列與查詢token的預期計數相符。這樣，他們就能夠估計僅僅歸因於詞表的錯誤大小，而不是序列長度和計數。
結果如圖2b所示，可以看出，增加詞表，的確會對表現產生負面影響。
（b）為使用Gemini 1.5時的QC任務結果；其中x軸為詞表大小，y軸為100次重複的平均絕對誤差
結論
總的來說，當模型的維度足夠大時，可以透過讓Transformer計算輸入序列的直方圖來輕鬆完成「計數任務」。對於較小的維度，一層Transformer則無法實現。
理解這些Transformer的限制對於新架構的開發至關重要。
從某種意義上說，除非顯著增加架構的規模，否則Transformer將無法在長上下文中進行任意精確的計數。
這表明在計數任務中，我們可能需要藉助於不具有相同限制的工具，例如程式碼解釋器等。
參考資料：
https://arxiv.org/abs/2407.15160
來源：新智元