原文來源：硅星人

圖片來源：由無界 AI生成

在 Transformer 的自注意力（self-attention）機制中，每個token都與其他所有的token有關(guān)聯(lián),。所以，如果我們有n個token，那么自注意力的計算復(fù)雜性是O(n^2),。隨著序列長度n的增加，所需的計算量和存儲空間會按平方增長,，這會導(dǎo)致非常大的計算和存儲開銷,。

這意味著，當(dāng)你已經(jīng)不滿足喂給大模型一個兩百字的段落,，想扔給他一篇兩萬字的論文,，它的計算量增加了1萬倍。

圖源：Harm de Vries博客

那個負責(zé)輸入和輸出的對話框就像人工智能通往現(xiàn)實世界的一個隘口,。從ChatGPT第一次躍上4096個token，到GPT-4將上下文輸入長度擴展到32k,，再到MetaAI提出的數(shù)百萬tokens的MegaByte方法,，以及國內(nèi)大模型廠商月之暗面和百川智能之間，20萬與35萬漢字的長度競賽,，大模型解決實際問題的進程,，輸入窗的胃口正在變成一個重要的先決條件。

換句話說,，當(dāng)它讀《紅樓夢》也能像讀一個腦筋急轉(zhuǎn)彎那么認真仔細,，事情就好辦多了。

突破奇點落在了token數(shù)上。關(guān)于它的研究也從來沒有停下,。

越長越好,？

對于上下文長度的推進是必要的，復(fù)旦和香港大學(xué)的研究團隊在一篇論文中做了論證,。他們做了一個L-Eval的評價基準(zhǔn),，在這個基準(zhǔn)的測試下，Claude-100k在封閉任務(wù)上的推理能力仍然弱于GPT-4-32k,，但在開放式任務(wù)中,，長度更長——也就意味著通常擁有更多輸入標(biāo)記——的Claude-100k在表現(xiàn)上超過GPT-4-32k。

圖源：《L-Eval:Instituting Standardized Evaluation for Long Context Language Models》

結(jié)論很積極，意味著勤能補拙的故事仍然是成立的,，如果腦子不好，你可以多囑咐幾句,，笨一點的學(xué)生也能成事,。

在那之前，Google Brain也已經(jīng)做了類似試驗,，一直參與Bard的研發(fā)訓(xùn)練的工程師Li Wei告訴硅星人,，去年Google團隊已經(jīng)通過控制訓(xùn)練輸入上下文長度的方式來觀察模型的輸出表現(xiàn)，結(jié)果確實上下文長度與模型表現(xiàn)成正相關(guān),。這個認識也對后來Bard的研發(fā)有所幫助,。

至少這是個業(yè)內(nèi)非常篤定的方向。那理論上,，一直擴展上下文長度不就好了,？

問題是擴張不得，而這個障礙仍然落在Transformer上,。

梯度

基于transformer架構(gòu)的大模型,，也就意味著接受了自注意力機制賦予的能力和限制。自注意力機制對理解能力鐘情,，卻天然與長文本輸入有所違背,。文本越長，訓(xùn)練就越艱難,，最壞的結(jié)果可能是梯度的爆炸或者消失,。

梯度是參數(shù)更新的方向和大小。理想的訓(xùn)練下,，大模型在生成內(nèi)容上與人類想要的回答之間的差距應(yīng)該在每一輪深度學(xué)習(xí)后都比之前更接近,。如果把模型想象成試圖在學(xué)習(xí)一個線性關(guān)系y=wx+b的話，w表示模型正在尋找的那個權(quán)重。而梯度的概念就是在表達w是如何變化的,。

一個穩(wěn)定的學(xué)習(xí)過程是漸進的,，漸進意味著微調(diào)有跡可循。就是說權(quán)重不能不變化,，也不能突變,。

不變化或者變化非常微弱——也就是梯度消失——意味著深度學(xué)習(xí)網(wǎng)絡(luò)的學(xué)習(xí)時間無限延長；突變則被叫做梯度爆炸,，權(quán)重更新過大,，導(dǎo)致網(wǎng)絡(luò)不穩(wěn)定。這可能會導(dǎo)致權(quán)重變得非常大或模型發(fā)散,，使得訓(xùn)練無法進行,。

三角

而最核心的，短文本很多時候無法完整描述復(fù)雜問題,，而在注意力機制的限制下,，處理長文本需要大量算力，又意味著提高成本,。上下文長度本身決定了對問題的描述能力,，自注意力機制又決定了大模型的理解和拆解能力，而算力則在背后支撐了這一切,。

圖源：ArXiv

問題仍然在Transformer上,，由于自注意力機制的計算復(fù)雜度問題,，上下文長度的擴展被困在一個三角形里。

這個不可能三角就擺在這兒,，解決方案也在這里,。為了增加上下文長度，如果能夠把算力（錢和卡）推向無限顯然是最理想的,。顯然現(xiàn)在這不現(xiàn)實,，那就只能動注意力機制的心思，從而讓計算復(fù)雜度從n^2降下來,。

對擴展上下文輸入的努力很大程度上推動者一場Transformer的革新,。

Transformer變形記

谷歌DeepMind研究團隊在今年7月提出了一種新的Focused Transformer（FoT）框架，它采用了一個受對比學(xué)習(xí)啟發(fā)的訓(xùn)練過程,，以改善（key, value）空間的結(jié)構(gòu),，并且允許一些注意力層通過 k-最近鄰 (kNN) 算法訪問外部記憶中的（key, value）對。這種機制有效地擴展了總的上下文長度,。

這有點像是谷歌在2022年另一個Memorizing Transformer的衍生,，后者基于Transformer的調(diào)整邏輯是在編碼長文本時,，模型一邊往下讀，邊把之前見過的所有 token 保存在一個數(shù)據(jù)庫中,；在讀當(dāng)前片段時,，會用kNN 的方式找到數(shù)據(jù)庫中相似的內(nèi)容。

Focused Transformer和LLaMA-3B開源模型做了結(jié)合,，變成LongLLaMA-3B,，再和LLaMA-3B在上下文輸入的長度方面做了橫向?qū)Ρ取＝Y(jié)果是上下文輸入長度到100k之后,，LongLLaMA-3B的回答準(zhǔn)確率才開始從94.5％迅速下滑,。而LLaMA-3B在超過2k就瞬間跌倒0了。

圖源：《Focused Transformer: Contrastive Training for Context Scaling》

從Transformer-XL在2019年出現(xiàn)，引入了分段循環(huán)機制（Segment Recurrent Mechanism）為模型提供了額外的上下文,，到一年后Longformer和BigBird引入了稀疏注意力機制,，將長度第一次擴展到4096個tokens，循環(huán)注意力和稀疏注意力機制就開始成為Transformer的改造方向,。

Focused Transformer通過 kNN 算法也是實現(xiàn)了某種形式的稀疏注意力,，更新的架構(gòu)調(diào)整方案則是Ring Attention。

今年10月,，伯克利的團隊提出了環(huán)注意力（Ring Attention），Ring Attention從內(nèi)存角度改變Transformer框架,。通過分塊處理自注意力機制和前饋網(wǎng)絡(luò)計算的方法,，上下文序列可以分布在多個設(shè)備上，并更有效地進行分析,。這也理論上消除了單個設(shè)備所施加的內(nèi)存限制,，使得序列的訓(xùn)練和推斷能夠處理比之前的內(nèi)存效率更高的Transformer長得多的序列。

也就是說,，Ring Attention實現(xiàn)了“近乎無限的上下文”,。

當(dāng)頭一棒

但這件事也不是絕對的。斯坦福在9月公布了一項研究表明,，如果上下文太長,，模型會略過中間不看。

他們對多種不同的開源（MPT-30B-Instruct,、LongChat-13B (16K)）和閉源（OpenAI 的 GPT-3.5-Turbo 和Anthropic 的 Claude）的語言模型進行了對照實驗,。研究者通過向輸入上下文添加更多文檔來增大輸入上下文的長度（類似于在檢索增強式生成任務(wù)中檢索更多文檔）；以及通過修改輸入上下文中文檔的順序,，將相關(guān)信息放置在上下文的開頭,、中間或結(jié)尾，從而修改上下文中相關(guān)信息的位置。

圖源：《Lost in the Middle: How Language Models Use Long Contexts》

結(jié)果是隨著相關(guān)信息位置的變化，模型性能呈現(xiàn)出明顯的 U 型趨勢,。也就是說,，當(dāng)相關(guān)信息出現(xiàn)在輸入上下文的開頭或末尾時，語言模型的性能最高,；而當(dāng)模型必須獲取和使用的信息位于輸入上下文中部時,，模型性能會顯著下降。舉個例子,，當(dāng)相關(guān)信息被放置在其輸入上下文中間時,，GPT3.5-Turbo 在多文檔問題任務(wù)上的性能劣于沒有任何文檔時的情況（即閉卷設(shè)置；56.1%）,。此外,，研究者還發(fā)現(xiàn)，當(dāng)上下文更長時,，模型性能會穩(wěn)步下降,；而且配有上下文擴展的模型并不一定就更善于使用自己的上下文。

當(dāng)頭一棒,！

但這或許也是好事,，如果文章太長，人們大概也只會記得開頭和結(jié)尾,，大模型與人類大腦何其相似,。

交鋒

目前全球主流的大模型中，GPT-4與LLaMA 2 Long的上下文長度都已經(jīng)達到了32k,，Claude 2.1達到200k,。國內(nèi)的大模型中，ChatGLM-6B的上下文長度達到了32k,，最晚亮相的明星公司月之暗面直接拿出了一個200k的Kimi Chat,。

月之暗面的思路同樣是改造Transformer，但楊植麟同時也引出一場交鋒,。

蝌蚪模型和蜜蜂模型,。

直白說，凹一個造型讓模型看起來可以支持更長的上下文輸入有很多途徑,，最簡單的辦法是犧牲模型本身的參數(shù),。

模型參數(shù)的降低，意味著內(nèi)存消耗的減少以及計算的簡單化,，內(nèi)存和計算資源的重新分配能夠轉(zhuǎn)變成同樣算力資源下上下文輸入長度的增加,?；剡^頭來看，F(xiàn)ocused Transformer的驗證放在一個3B的小參數(shù)模型上,，對于Ring Attention的試驗也更側(cè)重于所提出方法的有效性驗證，而沒有經(jīng)歷百億參數(shù)以上的大模型,。

圖源：《Focused Transformer: Contrastive Training for Context Scaling》

但10億級別的模型參數(shù)并不具備太好的智能涌現(xiàn)能力,。楊植麟形容其為蝌蚪模型,，因為它做不了更多事情。

除此之外,，另一種可以增加長度的方式是從外部引入搜索機制,。

探索的原理

這也是目前相當(dāng)多大模型能快速擴展上下文長度所采取的辦法——如果不動自注意力機制，另一種方式就是把長文本變成短文本的集合,。

比如常見的Retrieval-augmented generation (RAG) ,。它是一個結(jié)合了檢索 (retrieval) 和生成 (generation) 兩種機制的深度學(xué)習(xí)框架，目的是將信息檢索的能力引入到序列生成任務(wù)中,，使得模型在生成響應(yīng)或內(nèi)容時可以利用一個外部的知識庫,。

圖源：Towhee

模型在處理長文本時,，引入的搜索機制會在數(shù)據(jù)庫中對短文本進行檢索，以此來獲得多個短文本回答構(gòu)成的長文本,。每次只加載所需要的短文本片段,，從而避開了模型無法一次讀入整個長文本的問題。

楊植麟將這類模型稱為蜜蜂模型,。

傳統(tǒng)的 Transformer 機構(gòu),，如 GPT,，其輸入長度有限,，通常限于幾百到幾千的token。這意味著當(dāng)需要處理大量的信息或長文檔時,，模型可能會遇到困難,。RAG 通過其檢索機制可以在一個大型的外部知識庫中檢索信息，然后僅將最相關(guān)的片段與原始輸入一起送入生成模型,。這使得模型能夠處理比其原始輸入長度更大,。

這個觀點背后的原理很有意思。如果循環(huán)注意力和稀疏注意力都是在模型內(nèi)部對注意力機制進行改進,，屬于模型結(jié)構(gòu)級的優(yōu)化,，那么通過在外部數(shù)據(jù)庫中檢索相關(guān)信息片段,，然后將最相關(guān)的片段與原始輸入一起送入生成模型，來避免直接處理完整的長文本,，這僅僅屬于輸入級的優(yōu)化,。

這種方法的主要目的是從大量的文檔中快速捕獲與當(dāng)前問題最相關(guān)的信息片段，而這些信息片段可能只代表了原始輸入的部分上下文或某些特定方面,。也就是說,，這種方法更重視局部的信息，可能無法把握一個長文本輸入的整體含義,。

就像蜂巢中互相隔開的一個個模塊,。

蜜蜂模型的說法有一些戲謔意味的指向了市面上用外掛搜索來拓展窗口容量的大模型廠商，很難讓人不想到近幾個月發(fā)展迅速,，一直強調(diào)自己“搜索基因”的百川智能,。

10月30日，百川智能發(fā)布全新的Baichuan2-192K大模型,。上下文窗口長度拉長到192K,，折算成漢字約等于35萬字。月之暗面的Kimi Chat才將Claude-100k的上下文長度擴充了2.5倍,，Baichuan2-192K又幾乎把Kimi Chat的上限翻了倍,。

在長窗口文本理解評測榜單LongEval上，Baichuan2-192K的表現(xiàn)遠優(yōu)于Claude-100k,，在窗口長度超過 100K后依然能夠保持強勁性能,，后者在70k之后的表現(xiàn)就極速下跌了。

也沒這么多長文本

但關(guān)于“我們?yōu)槭裁床辉囋嚫L的上下文”這個問題,，還有另一個觀察角度,。

公開可用的互聯(lián)網(wǎng)抓取數(shù)據(jù)集CommonCrawl是 LLaMA 訓(xùn)練數(shù)據(jù)集的主要數(shù)據(jù)來源，包括從CommonCrawl中獲取的另一個主要的數(shù)據(jù)集C4,，兩者占據(jù)了LLaMA 訓(xùn)練數(shù)據(jù)集中的82%,，

CommonCrawl中的語料數(shù)據(jù)是很短的。ServiceNow 的研究員Harm de Vries在一篇分析文章中表示,，這個占比龐大的數(shù)據(jù)集中,，95%以上的語料數(shù)據(jù)文件的token數(shù)少于2k，并且實際上其中絕大多數(shù)的區(qū)間在1k以下,。

圖源：Harm de Vries博客

“如果要在其中尋找到有明顯上下文邏輯的長文本就更少了”,，Li Wei說,。

更長的訓(xùn)練預(yù)料被寄希望于書籍或論文甚至者維基百科等來源。Harm de Vries的研究表明,，有50%以上的維基百科文章的詞元數(shù)超過了4k個tokens,，75%以上的圖書詞元數(shù)超過了16k個tokens,。但無奈以LLaMA訓(xùn)練預(yù)料的主要數(shù)據(jù)來源分布來看，維基百科和書籍的占比都僅僅是4.5%,，論文（ArXiv）的占比只有2.5%,。三者相加只有270GB的數(shù)據(jù)，不到CommonCrawl一成,。

或許目前也壓根沒有這么多長文本語料能夠用于訓(xùn)練,，Transformer們不讀《紅樓夢》也沒有那么多《紅樓夢》可讀，是橫貫在所有追求上下文長度的人們面前真正的難題,。