今天小編分享的互聯網經驗：Transformer不讀《紅樓夢》，歡迎閲讀。
在 Transformer 的自注意力（self-attention）機制中，每個 token 都與其他所有的 token 有關聯。所以，如果我們有 n 個 token，那麼自注意力的計算復雜性是 O ( n^2 ) 。随着序列長度 n 的增加，所需的計算量和存儲空間會按平方增長，這會導致非常大的計算和存儲開銷。
這意味着，當你已經不滿足喂給大模型一個兩百字的段落，想扔給他一篇兩萬字的論文，它的計算量增加了 1 萬倍。
圖源：Harm de Vries 博客
那個負責輸入和輸出的對話框就像人工智能通往現實世界的一個隘口。從 ChatGPT 第一次躍上 4096 個 token，到 GPT-4 将上下文輸入長度擴展到 32k，再到 MetaAI 提出的數百萬 tokens 的 MegaByte 方法，以及國内大模型廠商月之暗面和百川智能之間，20 萬與 35 萬漢字的長度競賽，大模型解決實際問題的進程，輸入窗的胃口正在變成一個重要的先決條件。
換句話説，當它讀《紅樓夢》也能像讀一個腦筋急轉彎那麼認真仔細，事情就好辦多了。
突破奇點落在了 token 數上。關于它的研究也從來沒有停下。
越長越好？
對于上下文長度的推進是必要的，復旦和香港大學的研究團隊在一篇論文中做了論證。他們做了一個 L-Eval 的評價基準，在這個基準的測試下，Claude-100k 在封閉任務上的推理能力仍然弱于 GPT-4-32k，但在開放式任務中，長度更長——也就意味着通常擁有更多輸入标記——的 Claude-100k 在表現上超過 GPT-4-32k。
圖源：《L-Eval:Instituting Standardized Evaluation for Long Context Language Models》
結論很積極，意味着勤能補拙的故事仍然是成立的，如果腦子不好，你可以多囑咐幾句，笨一點的學生也能成事。
在那之前，Google Brain 也已經做了類似試驗，一直參與 Bard 的研發訓練的工程師 Li Wei 告訴硅星人，去年 Google 團隊已經通過控制訓練輸入上下文長度的方式來觀察模型的輸出表現，結果确實上下文長度與模型表現成正相關。這個認識也對後來 Bard 的研發有所幫助。
至少這是個業内非常笃定的方向。那理論上，一直擴展上下文長度不就好了？
問題是擴張不得，而這個障礙仍然落在 Transformer 上。
梯度
基于 transformer 架構的大模型，也就意味着接受了自注意力機制賦予的能力和限制。自注意力機制對理解能力鍾情，卻天然與長文本輸入有所違背。文本越長，訓練就越艱難，最壞的結果可能是梯度的爆炸或者消失。
梯度是參數更新的方向和大小。理想的訓練下，大模型在生成内容上與人類想要的回答之間的差距應該在每一輪深度學習後都比之前更接近。如果把模型想象成試圖在學習一個線性關系 y=wx+b 的話，w 表示模型正在尋找的那個權重。而梯度的概念就是在表達 w 是如何變化的。
一個穩定的學習過程是漸進的，漸進意味着微調有迹可循。就是説權重不能不變化，也不能突變。
不變化或者變化非常微弱——也就是梯度消失——意味着深度學習網絡的學習時間無限延長；突變則被叫做梯度爆炸，權重更新過大，導致網絡不穩定。這可能會導致權重變得非常大或模型發散，使得訓練無法進行。
三角
而最核心的，短文本很多時候無法完整描述復雜問題，而在注意力機制的限制下，處理長文本需要大量算力，又意味着提高成本。上下文長度本身決定了對問題的描述能力，自注意力機制又決定了大模型的理解和拆解能力，而算力則在背後支撐了這一切。
圖源：ArXiv
問題仍然在 Transformer 上，由于自注意力機制的計算復雜度問題，上下文長度的擴展被困在一個三角形裏。
這個不可能三角就擺在這兒，解決方案也在這裏。為了增加上下文長度，如果能夠把算力（錢和卡）推向無限顯然是最理想的。顯然現在這不現實，那就只能動注意力機制的心思，從而讓計算復雜度從 n^2 降下來。
對擴展上下文輸入的努力很大程度上推動者一場 Transformer 的革新。
Transformer 變形記
谷歌 DeepMind 研究團隊在今年 7 月提出了一種新的 Focused Transformer（FoT）框架，它采用了一個受對比學習啓發的訓練過程，以改善（key, value）空間的結構，并且允許一些注意力層通過 k- 最近鄰 ( kNN ) 算法訪問外部記憶中的（key, value）對。這種機制有效地擴展了總的上下文長度。
這有點像是谷歌在 2022 年另一個 Memorizing Transformer 的衍生，後者基于 Transformer 的調整邏輯是在編碼長文本時，模型一邊往下讀，邊把之前見過的所有 token 保存在一個數據庫中；在讀當前片段時，會用 kNN 的方式找到數據庫中相似的内容。
Focused Transformer 和 LLaMA-3B 開源模型做了結合，變成 LongLLaMA-3B，再和 LLaMA-3B 在上下文輸入的長度方面做了橫向對比。結果是上下文輸入長度到 100k 之後，LongLLaMA-3B 的回答準确率才開始從 94.5％迅速下滑。而 LLaMA-3B 在超過 2k 就瞬間跌倒 0 了。
圖源：《Focused Transformer: Contrastive Training for Context Scaling》
從 Transformer-XL 在 2019 年出現，引入了分段循環機制（Segment Recurrent Mechanism）為模型提供了額外的上下文，到一年後 Longformer 和 BigBird 引入了稀疏注意力機制，将長度第一次擴展到 4096 個 tokens，循環注意力和稀疏注意力機制就開始成為 Transformer 的改造方向。
Focused Transformer 通過 kNN 算法也是實現了某種形式的稀疏注意力，更新的架構調整方案則是 Ring Attention。
今年 10 月，伯克利的團隊提出了環注意力（Ring Attention），Ring Attention 從内存角度改變 Transformer 框架。通過分塊處理自注意力機制和前饋網絡計算的方法，上下文序列可以分布在多個設備上，并更有效地進行分析。這也理論上消除了單個設備所施加的内存限制，使得序列的訓練和推斷能夠處理比之前的内存效率更高的 Transformer 長得多的序列。
也就是説，Ring Attention 實現了 " 近乎無限的上下文 "。
當頭一棒
但這件事也不是絕對的。斯坦福在 9 月公布了一項研究表明，如果上下文太長，模型會略過中間不看。
他們對多種不同的開源（MPT-30B-Instruct、LongChat-13B ( 16K ) ）和閉源（OpenAI 的 GPT-3.5-Turbo 和 Anthropic 的 Claude）的語言模型進行了對照實驗。研究者通過向輸入上下文添加更多文檔來增大輸入上下文的長度（類似于在檢索增強式生成任務中檢索更多文檔）；以及通過修改輸入上下文中文檔的順序，将相關信息放置在上下文的開頭、中間或結尾，從而修改上下文中相關信息的位置。
圖源：《Lost in the Middle: How Language Models Use Long Contexts》
結果是随着相關信息位置的變化，模型性能呈現出明顯的 U 型趨勢。也就是説，當相關信息出現在輸入上下文的開頭或末尾時，語言模型的性能最高；而當模型必須獲取和使用的信息位于輸入上下文中部時，模型性能會顯著下降。舉個例子，當相關信息被放置在其輸入上下文中間時，GPT3.5-Turbo 在多文檔問題任務上的性能劣于沒有任何文檔時的情況（即閉卷設定；56.1%）。此外，研究者還發現，當上下文更長時，模型性能會穩步下降；而且配有上下文擴展的模型并不一定就更善于使用自己的上下文。
當頭一棒。
但這或許也是好事，如果文章太長，人們大概也只會記得開頭和結尾，大模型與人類大腦何其相似。
交鋒
目前全球主流的大模型中，GPT-4 與 LLaMA 2 Long 的上下文長度都已經達到了 32k，Claude 2.1 達到 200k。國内的大模型中，ChatGLM-6B 的上下文長度達到了 32k，最晚亮相的明星公司月之暗面直接拿出了一個 200k 的 Kimi Chat。
月之暗面的思路同樣是改造 Transformer，但楊植麟同時也引出一場交鋒。
蝌蚪模型和蜜蜂模型。
直白説，凹一個造型讓模型看起來可以支持更長的上下文輸入有很多途徑，最簡單的辦法是犧牲模型本身的參數。
模型參數的降低，意味着内存消耗的減少以及計算的簡單化，内存和計算資源的重新分配能夠轉變成同樣算力資源下上下文輸入長度的增加。回過頭來看，Focused Transformer 的驗證放在一個 3B 的小參數模型上，對于 Ring Attention 的試驗也更側重于所提出方法的有效性驗證，而沒有經歷百億參數以上的大模型。
圖源：《Focused Transformer: Contrastive Training for Context Scaling》
但 10 億級别的模型參數并不具備太好的智能湧現能力。楊植麟形容其為蝌蚪模型，因為它做不了更多事情。
除此之外，另一種可以增加長度的方式是從外部引入搜索機制。
搜索的原理
這也是目前相當多大模型能快速擴展上下文長度所采取的辦法——如果不動自注意力機制，另一種方式就是把長文本變成短文本的集合。
比如常見的 Retrieval-augmented generation ( RAG ) 。它是一個結合了檢索 ( retrieval ) 和生成 ( generation ) 兩種機制的深度學習框架，目的是将信息檢索的能力引入到序列生成任務中，使得模型在生成響應或内容時可以利用一個外部的知識庫。
圖源：Towhee
模型在處理長文本時，引入的搜索機制會在數據庫中對短文本進行檢索，以此來獲得多個短文本回答構成的長文本。每次只加載所需要的短文本片段，從而避開了模型無法一次讀入整個長文本的問題。
楊植麟将這類模型稱為蜜蜂模型。
傳統的 Transformer 機構，如 GPT，其輸入長度有限，通常限于幾百到幾千的 token。這意味着當需要處理大量的信息或長文檔時，模型可能會遇到困難。RAG 通過其檢索機制可以在一個大型的外部知識庫中檢索信息，然後僅将最相關的片段與原始輸入一起送入生成模型。這使得模型能夠處理比其原始輸入長度更大。
這個觀點背後的原理很有意思。如果循環注意力和稀疏注意力都是在模型内部對注意力機制進行改進，屬于模型結構級的優化，那麼通過在外部數據庫中檢索相關信息片段，然後将最相關的片段與原始輸入一起送入生成模型，來避免直接處理完整的長文本，這僅僅屬于輸入級的優化。
這種方法的主要目的是從大量的文檔中快速捕獲與當前問題最相關的信息片段，而這些信息片段可能只代表了原始輸入的部分上下文或某些特定方面。也就是説，這種方法更重視局部的信息，可能無法把握一個長文本輸入的整體含義。
就像蜂巢中互相隔開的一個個模塊。
蜜蜂模型的説法有一些戲谑意味的指向了市面上用外挂搜索來拓展視窗容量的大模型廠商，很難讓人不想到近幾個月發展迅速，一直強調自己 " 搜索基因 " 的百川智能。
10 月 30 日，百川智能發布全新的 Baichuan2-192K 大模型。上下文視窗長度拉長到 192K，折算成漢字約等于 35 萬字。月之暗面的 Kimi Chat 才将 Claude-100k 的上下文長度擴充了 2.5 倍，Baichuan2-192K 又幾乎把 Kimi Chat 的上限翻了倍。
在長視窗文本理解評測榜單 LongEval 上，Baichuan2-192K 的表現遠優于 Claude-100k，在視窗長度超過 100K 後依然能夠保持強勁性能，後者在 70k 之後的表現就極速下跌了。
也沒這麼多長文本
但關于 " 我們為什麼不試試更長的上下文 " 這個問題，還有另一個觀察角度。
公開可用的互聯網抓取數據集 CommonCrawl 是 LLaMA 訓練數據集的主要數據來源，包括從 CommonCrawl 中獲取的另一個主要的數據集 C4，兩者占據了 LLaMA 訓練數據集中的 82%，
CommonCrawl 中的語料數據是很短的。ServiceNow 的研究員 Harm de Vries 在一篇分析文章中表示，這個占比龐大的數據集中，95% 以上的語料數據檔案的 token 數少于 2k，并且實際上其中絕大多數的區間在 1k 以下。
圖源：Harm de Vries 博客
" 如果要在其中尋找到有明顯上下文邏輯的長文本就更少了 "，Li Wei 説。
更長的訓練預料被寄希望于書籍或論文甚至者維基百科等來源。Harm de Vries 的研究表明，有 50% 以上的維基百科文章的詞元數超過了 4k 個 tokens，75% 以上的圖書詞元數超過了 16k 個 tokens。但無奈以 LLaMA 訓練預料的主要數據來源分布來看，維基百科和書籍的占比都僅僅是 4.5%，論文（ArXiv）的占比只有 2.5%。三者相加只有 270GB 的數據，不到 CommonCrawl 一成。
或許目前也壓根沒有這麼多長文本語料能夠用于訓練，Transformer 們不讀《紅樓夢》也沒有那麼多《紅樓夢》可讀，是橫貫在所有追求上下文長度的人們面前真正的難題。
