經常關注大模型的朋友一定聽過一個詞，叫做 " 上下文窗口 "。比如矽星人 Pro 的文章《模型上下文長度達到 10000000，又一批創業者完蛋了？》就提到了，谷歌 Gemini 1.5 Pro 的上下文長度達到了 100 萬個 token，如果讓它來寫哈利波特，可以一口氣從哈利波特去 9 又 4 分之 3 車站寫到小天狼星爲了救哈利而犧牲。
對于大語言模型來說，上下文窗口是指在訓練和應用大語言模型時，模型能夠同時考慮并處理的輸入序列的最大長度。這個窗口限制了模型對文本中連續标記之間依賴關系的理解範圍。對于 LLMs 而言，大的上下文窗口是極其重要的特征，因爲它允許模型在處理長文檔、對話曆史或複雜語境時保持連貫性和理解力。如果上下文窗口太小，當輸入文本超出這一窗口限制時，模型可能無法準确捕捉到遠距離詞語間的關聯，從而導緻性能下降。
2024 年 2 月 26 号，微軟看到谷歌 Gemini 1.5 pro 那 100 萬個 token 以後坐不住了，他們發表了一篇新的論文，提出了一個叫做 LongRoPE 的方法，能夠在保持原始短上下文窗口性能的同時，将預訓練 LLMs 的上下文窗口擴展到令人印象深刻的 200 萬個 token。
RoPE 是 Rotary Position Embedding（旋轉位置嵌入）的縮寫，這是一種在 transformer 模型中用于編碼輸入序列中 token 位置信息的方法，它最大的作用就是讓模型能夠知道各個 token 之間的順序關系。那麽 LongRoPE 的含義呢，就是 RoPE for long text，即給長文本準備的旋轉位置嵌入。
LonRoPE 的核心邏輯是通過改進位置插值方法，使得在擴展上下文窗口時仍能有效利用 RoPE 的特性。LongRoPE 本質上來說是一種微調，分爲下面下面三個步驟：1. 發現并利用了位置插值中的兩種非均勻性，通過高效搜索提供了更好的微調初始化條件，并使得在無需微調的情況下能實現上下文窗口 8 倍的擴展；2. 引入了漸進式擴展策略，首先針對 25.6 萬 token 長度的文本對大語言模型進行微調，然後在已微調的擴展大語言模型上進行第二次位置插值，從而達到 204.8 萬 token 的上下文窗口；3. 對于恢複原始較短上下文窗口的性能，LongRoPE 會在 8000 長度上重新調整參數，确保即使在非常長的上下文窗口設置下，模型也能在較短序列上的表現不下滑。
我們可以這樣來理解，它的技術原理是通過精巧地處理位置嵌入，依據實際情況靈活調整和優化，既拓寬了模型處理長文本的能力，又保證了模型在應對短文本時同樣具備優秀的性能。那麽開發 LongRoPE 的意義在久于允許大模型在無需大量的額外訓練和計算資源的情況下，能夠處理超長文本。
所以 Longrope 最大優勢并不隻是說能擴大上下文窗口，而是不需要額外訓練，不需要多配備硬件，僅僅使用 1000 步微調以内就能實現這 200 萬個 token 的擴展。
我們真的需要那麽多 token 嗎？
那你可能就要問了，微軟研究出這個 200 萬 token 的上下文窗口技術圖啥呢？别說日常對話了，哪怕是拿本小說來，估計也很難滿足 200 萬個 token。
咱們文章開頭也講過了，上下文窗口它就是同時考慮并處理的輸入序列的最大長度。而在 transformer 架構中的自注意力機制中，上下文窗口大小決定了模型可以同時捕捉到多遠距離的詞語依賴關系。粗暴點來理解，上下文窗口完全可以被當成模型能夠容納多少文本的一種體現。就跟郵箱的油表一樣，上下文窗口增大時，意味着它可以理解并基于更長的文本片段進行推理。
例如，如果一個大語言模型具有 20 萬 token 的上下文窗口長度，它可以一次性處理大約 35 萬個漢字的上下文信息。那麽 200 萬個 tokens 的上下文窗口長度，大約就是 350 萬字，要知道一本囊括了保爾柯察金一生的《鋼鐵是怎樣煉成的》才不到 40 萬個字而已。
在大模型領域，上下文窗口不應該是 " 你能煉一噸，咱煉一噸半 "，因爲增加上下文窗口也意味着模型的計算量和内存需求将大幅增加，因此在實際應用中必須權衡上下文窗口的大小和計算資源的有效利用。
如果隻是增加計算資源消耗倒還好說，畢竟硬件上下血本就完事了，沒有花錢的不是，但過分追求上下文窗口還會導緻一個問題，叫做 " 過拟合（overfitting）"。過拟合是說模型在訓練數據上表現很好，但在未見過的測試數據上表現較差的現象。也就意味着模型過度适應了訓練數據的特性，将訓練數據中的噪聲或随機變化也當作了真實的模式，從而導緻模型在新數據上泛化能力較差。
過拟合通常發生在模型複雜度較高時，例如參數過多或特征過于豐富的情況下。過度複雜的模型可能會在訓練數據中學習到過多的噪聲或細節，而忽略了數據中的真實規律。而目前來看，LongRoPe 還未正式啓用，因此我們也沒辦法清楚它是否發生了過拟合，不過照着 200 萬 token 大軍的勢頭看，這個概率并不低。
還沒完，模型在運行過程中，它是需要在内存中發生并行計算的。如果上下文窗口過大，與之對應的内存消耗也就會增加。所以綜合考量，無論是大模型的開發者，還是大語言模型的微調者來說，增加上下文窗口是沒問題的，然而過分追求超長上下文窗口，并沒有特别重大的意義，反倒還會産生未知的結果。
說了這麽多，其實有一個同樣很重要的原因，是各大廠商今天都在卷長度的重要 " 動機 " ——因爲大語言模型沒有特别明确的性能評分标準，隻有一個知識庫的評分标準，因此透過上下文窗口本身的數學表示，就會給人一種 " 數字越大，模型越厲害 "。也許是時候回歸本初，想想最初增加上下文窗口的意義是什麽，讓大家回到增加模型性能的初心上來了。
