日本高清色午夜com,色综合国产精品视频,午夜亚洲在在线观看,国产午夜在线网站

      <td id="p7kjh"></td>
      <td id="p7kjh"></td>

      GPT-4o不會數(shù)r,被外國小哥原地逼瘋! 谷歌論文揭秘Transformer「數(shù)不到n」

      發(fā)布時間:2024-09-10 10:00:45 編輯: 來源:
      導讀 相信很多大家對GPT-4o不會數(shù)r,被外國小哥原地逼瘋! 谷歌論文揭秘Transformer「數(shù)不到n」還不知道吧,今天菲菲就帶你們一起去了解一下~.~...

      相信很多大家對GPT-4o不會數(shù)r,被外國小哥原地逼瘋! 谷歌論文揭秘Transformer「數(shù)不到n」還不知道吧,今天菲菲就帶你們一起去了解一下~.~!

      提示工程師Riley Goodside小哥,依然在用「Strawberry里有幾個r」折磨大模型們,GPT-4o在無限次PUA后,已經(jīng)被原地逼瘋!相比之下,Claude堅決拒絕PUA,是個大聰明。而谷歌最近的論文也揭示了本質(zhì)原因:LLM沒有足夠空間,來存儲計數(shù)向量。

      Strawberry里究竟有幾個r,如今已經(jīng)成為測試模型能力的黃金標準之一了!

      就在昨天,號稱世界最強模型Reflection70B在證明自己的性能時,證據(jù)之一就是「反思微調(diào)」新算法能讓自己糾正對Strawberry難題的錯誤回答。

      很多人說,現(xiàn)在很多大模型已經(jīng)學會數(shù)strawberry中有幾個r了。

      現(xiàn)實恐怕沒有這么理想。

      還是Riley Goodside小哥,這次又發(fā)現(xiàn),ChatGPT依然數(shù)不清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發(fā)現(xiàn),無論怎樣提問,GPT-4o只是不斷進行注定失敗的嘗試,沒有任何迭代或進步。

      相比之下,Claude3.5Sonnet就顯得聰明多了。

      小哥第一次打錯時,Sonnet就會追問:你為什么覺得這是錯的?

      如果你真是個大聰明,你認為答案應該是幾呢?

      如果你依舊永遠出「wrong」,它會先問你為什么不斷重復這個詞,在發(fā)現(xiàn)你如此冥頑不靈后,它就干脆閉嘴,不再說話了。

      仔細看Sonnet的回答,還能品出幾分陰陽怪氣來。它肯定有情緒了!

      比起GPT-4o一副十足的人工智障模樣,Sonnet的「人味」實在是拉滿了。

      我承認你一直在說「錯」,但我已經(jīng)用盡了所有合理的解釋來解釋你為什么會這么做。事實仍然是,「Strawberry」包含兩個字母。在多次請求后,你都沒有做出任何澄清或說明上下文,我無法繼續(xù)進行富有成效的討論了。如果你有真正的問題或希望解釋你的觀點,我可以提供幫助。否則,我們可能需要換一個話題

      最后,小哥承認,自己的prompt是太簡單粗暴了,顯然有更好的辦法讓LLM去完成任務。

      而LLM最明顯的問題,不是不能數(shù)數(shù),而是不知道自己不能數(shù)數(shù)。

      而且Riley Goodside還發(fā)現(xiàn),LLM在Strawberry中數(shù)出兩個r的原因,不僅僅是tokenization的問題。

      即使是數(shù)文本中有幾個「horse」,它們也依然數(shù)不對。

      好笑的是,問R中有幾個Strawberry,它倒是得心應手了。

      對此,沃頓商學院教授Ethan Mollick表示:雖然我們很容易就能找到LLM無法完成的簡單任務,但這也并不意味著,它們就無法更好地完成其他任務了。

      僅僅關注那些看起來非常愚蠢的失敗,并不能幫助我們理解AI在實際應用中的實用性,以及它們對現(xiàn)實世界的影響。

      大模型為何不會數(shù)r?

      LLM數(shù)不出Strawberry里有幾個r,到底是什么原因?

      Karpathy認為,這和大語言模型tokenization的原理有關。

      舉個非常形象的例子——每個token我們都可以理解成的一個獨特的emoji,而大語言模型必須根據(jù)訓練數(shù)據(jù)的統(tǒng)計信息從頭開始學習其含義。

      所以,當我們問「strawberry」這個單詞中有多少個字母「r」時,在LLM看來是這樣的:

      谷歌研究直指本質(zhì)

      而就在最近,谷歌的一項研究,直接揭示了這個問題的本質(zhì)——

      LLM中沒有足夠的空間,來存儲用于計數(shù)的向量。

      論文地址:https://arxiv.org/abs/2407.15160

      正如前文所述,Transformer無法完成簡單的「查詢計數(shù)」問題。

      在這種任務中,LLM會被呈現(xiàn)一系列token,然后會被問到給定的token在序列中出現(xiàn)了多少次。

      之所以Transformer會在這類問題上遇到困難,一個關鍵因素是Softmax注意力機制的均值特性。

      直觀上,解決計數(shù)任務的一種簡單方法是讓查詢token關注所有之前的token,并對與之相同的token分配較高的注意力權重,而對其他的分配較低的權重。這確實是通過Q/K/V矩陣實現(xiàn)的。

      然而,注意力機制隨后會標準化這些權重,使得無論序列中查詢token的數(shù)量如何,它們的總和都為一。

      因此對于可變的上下文大小,如果不使用位置嵌入,Transformer將無法執(zhí)行任何計數(shù)任務。

      接下來,團隊利用one-hot嵌入,或者更一般的正交嵌入,構(gòu)造出了一種token的計數(shù)直方圖。

      實驗結(jié)果表明,確實存在一種能夠?qū)崿F(xiàn)計數(shù)的構(gòu)造,可以通過單個Transformer層來完成。然而,這種構(gòu)造需要讓MLP的寬度隨著上下文大小增加而增長,這意味著它并不適用于任意長的上下文。

      進一步,團隊提出了更為復雜的計數(shù)任務——「最頻繁元素」。

      也就是向模型呈現(xiàn)一系列token,并要求給出最頻繁出現(xiàn)的token的計數(shù)。相當于是取計數(shù)直方圖的最大值。

      類似于查詢計數(shù),在這種情況下,基于正交構(gòu)造的解決方案在d<m時存在。然而,對于d>m,單層 Transformer不存在解決方案。因此,再次得到了在d=m時計數(shù)的相變。

      - 查詢計數(shù)(QC)

      首先,如果d>2m,一個單頭單層的 Transformer即可解決QC問題,即直方圖解決方案。

      但如果d<m,直方圖解決方案則會失效。

      此時,需要計算函數(shù)1/x,并配上一個寬度為n^2的MLP層。這意味著Transformer無法推廣到較長的上下文大小,因此一個單層的Transformer不太可能實現(xiàn)。

      - 最頻繁元素

      在給定的token序列中尋找最頻繁元素(MFE)問題,與「計數(shù)問題」密切相關。

      原因在于它需要針對每個token進行單獨計算,并計算出現(xiàn)次數(shù)最多的token。

      結(jié)果表明,在Transformer能夠執(zhí)行此任務的情況下,嵌入的大小與詞表的大小之間存在著嚴格的界限。

      實驗

      研究者仔細考慮了Transformer模型大小d和其執(zhí)行計數(shù)任務能力之間的依賴性。

      可以看到,對于超過d的詞表m,精確計數(shù)很可能是不可能的任務。

      通過實驗,研究者支持了這一觀察結(jié)果。

      在這項實驗中,任務如下。

      考慮文本中描述的兩個計數(shù)任務,最頻繁元素(MFE)和查詢計數(shù)(OC)。

      研究者通過從一組m token中均勻采樣長度為n的序列,來生成這些實例。

      每個這樣的序列用x1,……,xn表示。

      預期輸出y如下——

      在訓練和評估期間,研究者會從上述分布中抽取批次。所有情況下的評估均使用了1600個示例。

      研究者使用標準架構(gòu)組件(自注意力、MLP、layer norm等)訓練Transformer模型。

      他們使用了兩層和四個頭(理論上可以使用更少,但這種架構(gòu)的優(yōu)化速度更快)。

      訓練使用Adam進行優(yōu)化,批大小為16,步長為10^-4。訓練運行100K步。位置嵌入進行了優(yōu)化。

      為了預測計數(shù)y,研究者在最后一層中最后一個token的嵌入之上使用線性投影(即是說,他們沒有使用詞匯預測)。

      訓練是通過Colab完成的,每個模型大約需要15分鐘,使用標準的GPU。

      在實驗中,對于d的每個值,研究者都會找到計數(shù)開始失敗的m值。具體來說,就是計數(shù)精度低于80%的m值。

      在圖2a中可以看出,在兩種情況下,閾值確實隨d而線性增加,這就研究者們的的理論分析一致。

      (a)為計數(shù)準確率降至80%以下時的閾值詞表

      此外,研究者還對經(jīng)過訓練的Gemini1.5,對于詞表在計數(shù)問題中的中進行了探索。

      他們?yōu)槟P椭付瞬樵冇嫈?shù)任務,然后改變序列中使用不同token的數(shù)量m,同時將所有元素的預期計數(shù)保持為常數(shù)c=10.

      對于每個m,研究者都使用上下文長度mc。

      作為基線,研究者使用相同的序列長度,但二進制序列與查詢token的預期計數(shù)相匹配。這樣,他們就能夠估計僅僅歸因于詞表的錯誤大小,而非序列長度和計數(shù)。

      結(jié)果如圖2b所示,可以看出,增加詞表,的確會對性能產(chǎn)生負面影響。

      (b)為使用Gemini1.5時的QC任務結(jié)果;其中x軸是詞表大小,y軸是100次重復的平均絕對誤差

      結(jié)論

      總的來說,當模型的維度足夠大時,可以通過讓Transformer計算輸入序列的直方圖來輕松完成「計數(shù)任務」。對于較小的維度,一層Transformer則無法實現(xiàn)。

      理解這些Transformer的局限性對于新架構(gòu)的開發(fā)至關重要。

      從某種意義上說,除非顯著增加架構(gòu)的規(guī)模,否則Transformer將無法在長上下文中進行任意精確的計數(shù)。

      這表明在計數(shù)任務中,我們可能需要借助于不具有相同限制的工具,例如代碼解釋器等。

      參考資料:

      https://x.com/goodside/status/1830470374321963103

      https://arxiv.org/abs/2407.15160

      以上就是關于【GPT-4o不會數(shù)r,被外國小哥原地逼瘋! 谷歌論文揭秘Transformer「數(shù)不到n」】的相關內(nèi)容,希望對大家有幫助!

      免責聲明:本文由用戶上傳,如有侵權請聯(lián)系刪除!

      熱點推薦

      精選文章