真·開外掛！MIT新研究：架構0改動，讓大模型解鎖千萬級上下文

聞樂 發自 凹非寺
量子位 | 公眾號 QbitAI

讓大模型輕松處理比自身上下文窗口長兩個數量級的超長文本！

MIT CSAIL研究團隊提出了一種叫做遞歸語言模型RLM的長文本處理新方法，來解決上下文腐爛問題。

不修改模型架構、不升級模塊設計，但能讓GPT-5、Qwen-3這類頂尖模型推理層具備千萬級token的超長文本處理能力。

核心思路是不把提示詞直接塞進大模型的上下文窗口，而把它“外包”給可交互的Python環境，讓模型主動通過自動編程和遞歸調用拆解任務、按需處理。

啊？大模型讀上下文也能遞歸操作？

上下文窗口不夠，仍能推理

先說上下文腐爛這個扎心的問題。

不管大模型宣稱自己的上下文窗口有多大，它們處理超長文本時，都會遇到文本越長，模型對早期信息的記憶越模糊，推理性能直線下滑的問題。

這就像我們讀百萬字小說，讀到后半段，早就忘了前半段的關鍵情節。

現在主流的解決辦法有上下文壓縮、檢索增強生成RAG，或者對模型進行架構級優化

比如，GPT-5.2-Codex采用的就是窗口內的原生上下文壓縮技術，在持續數周的大型代碼倉庫協助任務中保持全上下文信息。

同時，GPT系列、Claude、Qwen等企業級版本原生集成RAG功能也是行業共識。

而架構級優化的例子，有社區普遍猜測的Gemini 3的環形注意力等。

現在的RLM和這些直接在模型上“硬磕”的方法不同，它把上下文處理給“外包”了

RLM給模型搭了一個可交互的Python編程環境REPL

開始處理上下文前，它先啟動Python REPL交互式編程環境，將超長提示詞作為字符串變量存入環境；

接著模型像程序員一樣編寫代碼，對文本變量進行關鍵詞篩選、局部探查、邏輯拆分等操作，通過「編寫代碼-觀察結果」的交互循環減少無效信息攝入；

隨后模型將復雜任務拆解為若干子任務，遞歸調用自身或輕量化子模型處理拆分后的文本片段，所有子任務輸出均存儲為新變量回流到REPL環境；

最后主模型編寫代碼讀取并整合所有子任務結果變量，進行邏輯拼接或語義處理，形成最終輸出。

全程由模型自主決策，實現按需處理，徹底解耦輸入文本長度與模型上下文窗口的綁定。

實驗顯示，RLM有效處理規模已突破千萬級Token，超過GPT-5等前沿模型原生上下文窗口的兩個數量級。

在復雜長文本任務中，RLM的優勢也比較顯著。面對要求聚合成對信息、復雜度呈二次方增長的OOLONG-Pairs任務，基礎GPT-5和Qwen3-Coder的 F1分數不足0.1%；

采用RLM方案后，兩款模型分別取得58.00%和23.11%的F1分數。

在600萬至1100萬Token規模的BrowseComp-Plus（1K）多文檔推理任務中，RLM（GPT-5）的正確率高達91.33%，大幅超越其他長文本處理方案；

即便在要求線性掃描并處理幾乎所有信息的OOLONG任務中，RLM也實現了雙位數的性能提升。

從調用成本上看，在50分位數這個指標上，RLM的成本和其他長文本處理方案處于同一水平，甚至更低。

這說明在大多數常規任務場景中，RLM的性價比是很有優勢的。

但到了95分位數這類高百分位區間時，RLM的成本會出現明顯飆升。

主要是因為RLM的推理過程是動態的，會根據任務復雜度自主決定代碼編寫、文本拆分和遞歸調用的次數，額外的步驟會增加API調用次數。

最后再劃個小重點，RLM是一種不碰模型架構的通用推理策略，也就是說，理論上任何模型都能直接上車。

論文地址：https://arxiv.org/abs/2512.24601
參考鏈接：https://x.com/MatthewBerman/status/2012701592756383893

— 完 —