MIT團隊推出遞歸語言模型！不改架構，上下文處理能力擴展百倍

新年伊始，MIT CSAIL 的一紙論文在學術圈引發了不小的討論。Alex L． Zhang 、 Tim Kraska 與 Omar Khattab 三位研究者在 arXiv 上發布了一篇題為《Recursive Language Models》的論文，提出了所謂“遞歸語言模型”（Recursive Language Models，簡稱 RLM）的推理策略。

圖丨相關論文（來源：arXiv）

早在 2025 年 10 月，Zhang 和他的導師 Omar Khattab 就在博客上公開了初步想法，引發了一些關注。如今這篇正式論文帶來了更系統的實驗和更扎實的數據，論證了通過讓語言模型把長文本當作“外部環境中的變量”來處理，可以讓模型有效處理超出其上下文窗口 2 個數量級的輸入。

Zhang 在推文中寫道：“正如 2025 年是從語言模型到推理模型的轉換之年，我們認為 2026 年將是遞歸語言模型的時代?！彼€特別提到，RLM 是他們對推理時算力擴展（inference-time scaling）的“bitter lesson 式”解法，即與其精心設計復雜的人工規則，不如讓系統自己去學、去算。RLM 的設計哲學與此一脈相承，它不試圖從模型架構層面“修復”長文本處理的問題，而是提供一套通用的推理時框架，讓模型自己決定如何與超長輸入交互。

過去兩年，幾乎所有主流大模型都在競相擴展上下文窗口。Gemini 把窗口拉到了百萬級別，GPT 系列持續加碼，Llama 更是喊出了千萬 token 的口號。表面上看，這是一場“誰更能裝”的軍備競賽。但問題在于，上下文窗口變大并不意味著模型就真的能把所有內容都“讀進去、記得住”。

2025 年年中，向量數據庫公司 Chroma 發布了一份技術報告，正式為這種現象命名，“context rot”（上下文腐爛）。Chroma 的研究團隊測試了包括 GPT-4.1 、 Claude 4 、 Gemini 2.5 、 Qwen3 在內的 18 款主流模型，發現即便是在最簡單的“大海撈針”（Needle in a Haystack，NIAH）任務上，模型的準確率也會隨著輸入長度的增加而顯著下降。

更值得注意的是，當任務本身變得復雜，比如需要語義推理而非簡單的字面匹配，性能下滑會來得更早、更陡峭。所謂百萬 token 的上下文窗口，實際有效利用的可能只有一小部分。

（來源：Chroma Research）

針對長上下文的解決方案目前業界已經發展出幾種主流策略。最常見的是“上下文壓縮”（context condensation），也就是當上下文超出一定長度時，讓模型先對前面的內容做摘要，再繼續處理新內容。這種方法簡單直接，但摘要本身是有損的，早期出現的細節可能在壓縮過程中丟失。

另一種流行方案是檢索增強生成（Retrieval-Augmented Generation，RAG），先把長文檔切塊存入向量數據庫，根據問題檢索相關片段再喂給模型。這避免了讓模型一次性吞下整篇長文，但效果高度依賴檢索質量，對于需要綜合全文信息的問題往往力不從心。

還有一類是遞歸任務分解框架，允許模型把復雜任務拆解成子任務再遞歸調用。但這些方法的共同局限在于：它們要么損失信息，要么無法真正突破模型本身的上下文窗口限制。

RLM 的核心思路在于換了一個角度來思考問題。與其絞盡腦汁讓 Transformer 直接消化長文本，不如把長文本“外包”到一個獨立的運行環境中，讓模型通過編程的方式按需訪問。具體來說，RLM 會啟動一個 Python 的 REPL（Read-Eval-Print Loop，讀取-求值-打印循環）環境，把用戶的長文本作為一個字符串變量存進去。

然后模型不再直接閱讀全文，而是編寫代碼來“窺探”這個變量，打印一小段看看、用正則表達式搜索關鍵詞、按章節拆分等等。更關鍵的是，模型還可以在代碼里調用另一個語言模型來處理子任務，并把結果存回變量中。整個過程是迭代式的：模型執行一段代碼，觀察輸出，決定下一步怎么做，直到最終拼湊出答案。

圖丨遞歸語言模型將提示視為環境的一部分（來源：arXiv）

這種設計的靈感據稱來自“外存算法”（out-of-core algorithms）。在傳統計算機科學中，當數據量超出內存容量時，系統會把數據存在硬盤上，通過精心設計的調度策略來回讀取需要的部分。RLM 本質上是在給語言模型搭建一個類似的“內存管理層”。對外部用戶而言，RLM 的接口與普通語言模型完全一樣：輸入一個字符串，輸出一個字符串。但內部的處理方式已經不同。

論文中的實驗設計了 4 組不同復雜度的任務。S-NIAH 是最簡單的大海撈針任務，答案固定，不隨輸入長度變化。OOLONG 要求模型對輸入中的每一行進行語義分類并匯總，處理量與輸入長度成正比。OOLONG-Pairs 更極端，要求找出滿足特定條件的所有“用戶對”，處理復雜度與輸入長度的平方成正比。還有一組 BrowseComp-Plus，給模型 1,000 篇文檔（總計約 600-1,100 萬 token），要求回答需要跨文檔推理的問題。

實驗結果顯示，裸跑 GPT-5 的表現隨著輸入長度和任務復雜度的增加而急劇下滑。在 OOLONG-Pairs 上，GPT-5 和 Qwen3-Coder 的 F1 分數都不到 0.1%。但套上 RLM 框架之后，GPT-5 的 F1 分數躍升至 58%，Qwen3-Coder 也達到了約 23%。

在 BrowseComp-Plus 的千文檔場景下，RLM（GPT-5）取得了 91.33% 的準確率，而上下文壓縮方案只有約 70%，檢索工具代理是 51%。研究者還強調，RLM 的成本并不比直接調用基礎模型貴多少，在某些任務上甚至更便宜，因為模型可以選擇性地只查看需要的片段，而非一股腦把所有內容都送進 Transformer。

（來源：arXiv）

當然，任何新方法都有其適用邊界。論文坦承，當輸入較短、任務較簡單時，直接使用基礎模型可能比 RLM 更高效。畢竟 RLM 需要多次與環境交互，開銷不可忽視。當前實現使用同步的、阻塞式子模型調用，端到端延遲較高，研究者認為通過異步調用和并行化還有優化空間。

此外，論文中的系統提示詞是固定的，并未針對不同任務調優。另一個值得關注的問題是，讓模型在 REPL 環境中自主編寫和執行代碼，在安全隔離和行為可預測性方面帶來了新的工程挑戰。

論文作者在文末提到，未來可能會出現專門針對 RLM 范式進行訓練的模型，就像今天有專門針對推理任務訓練的模型一樣。他們認為 RLM 的軌跡本身可以被視為一種推理形式，理論上可以通過強化學習或蒸餾來優化。這個方向是否能走通，還需要更多后續工作來驗證。

參考資料：

1.https://arxiv.org/pdf/2512.24601

2.https://research.trychroma.com/context-rot

3.https://x.com/a1zhang/status/2007198916073136152

運營/排版：何晨龍