聞樂 發自 凹非寺量子位 | 公眾號 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
歡迎在評論區留下你的想法！