機器之心報道

編輯：+0、冷貓

目前，所有主流 LLM 都有一個固定的上下文窗口（如 200k, 1M tokens）。一旦輸入超過這個限制，模型就無法處理。

即使在窗口內(nèi)，當(dāng)上下文變得非常長時，模型的性能也會急劇下降，這種現(xiàn)象被稱為「上下文腐爛」（Context Rot）：模型會「忘記」開頭的信息，或者整體推理能力下降。

這種現(xiàn)象在現(xiàn)實使用中遠(yuǎn)比在標(biāo)準(zhǔn)化基準(zhǔn)測試中更明顯。當(dāng)用戶與 ChatGPT 等主流 LLM 進行長時間、多輪的復(fù)雜對話時，會明顯感覺到模型開始變「笨」，變得難以聚焦、遺忘關(guān)鍵信息。

來自 MIT 的研究者從一個直觀的想法出發(fā)：也許可以把超長上下文切分，分別交給模型處理，再在后續(xù)調(diào)用中合并結(jié)果，以此避免衰退問題？

基于此，他們提出了遞歸語言模型（Recursive Language Models，RLMs），這是一種通用的推理策略：語言模型將輸入上下文視作變量，對其進行分解并遞歸式交互。

• 將上下文視為一個可操作的「變量」：主模型（root LM）在一個類似 Jupyter Notebook 的編程環(huán)境（REPL）中工作，完整的上下文只是一個它能用代碼訪問的變量，而不是直接的輸入。
• 遞歸調(diào)用自身或小模型：主模型可以編寫代碼來查看、切分、過濾（比如用 grep）這個巨大的上下文變量，然后把小塊的任務(wù)外包給一個個小的、臨時的 LLM 調(diào)用（遞歸調(diào)用）。
• 綜合結(jié)果：主模型收集這些「外包」任務(wù)的結(jié)果，最終形成答案。

研究者還設(shè)計了一個具體實現(xiàn)：在一個 Python REPL 環(huán)境中調(diào)用 GPT-5 或 GPT-5-mini，并將用戶的 prompt 存入變量中進行迭代式處理。

結(jié)果很驚人：在能獲取到的最難的長上下文評測集之一 OOLONG 上，使用 GPT-5-mini 的 RLM 正確答案數(shù)量是直接使用 GPT-5 的兩倍以上，而且平均每次調(diào)用的成本更低。

研究者還基于 BrowseComp-Plus 構(gòu)建了一個全新的長上下文 Deep Research 任務(wù)。在該任務(wù)中，RLM 顯著優(yōu)于 ReAct + 推理時索引 / 檢索等方法。令人意外的是，即使推理時輸入超過 1000 萬 tokens，RLM 的性能也沒有出現(xiàn)衰減。

他們相信，RLM 很快會成為一個強大的范式

同時，相比于僅依賴 CoT 或 ReAct 風(fēng)格的代理模型，顯式訓(xùn)練以遞歸式推理為核心機制的 RLM，很可能成為推理時擴展能力領(lǐng)域的下一個里程碑

• 博客文章：https://alexzhang13.github.io/blog/2025/rlm/
• 原帖壓縮總結(jié)見推文：https://x.com/a1zhang/status/1978469116542337259

博客作者為 MIT CSAIL 的 Alex Zhang 和 Omar Khattab。

這是一個遞歸語言模型 (RLM) 調(diào)用的示例。它作為一種從文本到文本（text → text）的映射，但比標(biāo)準(zhǔn)的語言模型調(diào)用更靈活，并且可以擴展到近乎無限的上下文長度。RLM 允許語言模型與一個環(huán)境（在此實例中為 REPL 環(huán)境）進行交互，該環(huán)境存儲著可能非常龐大的上下文。在其中，模型可以遞歸地子查詢「自身」、調(diào)用其他 LM 或其他 RLM，從而高效地解析這些上下文并提供最終的響應(yīng)。

評論區(qū)的反饋也非常積極，并且進行了很多深入的討論。

遞歸語言模型 RLM

RLM 的通用性與其底層語言模型本身相同。實際上，從用戶角度來看，RLM 的調(diào)用方式與普通模型調(diào)用并沒有區(qū)別，但它在內(nèi)部可以生成（遞歸式的）LM 子調(diào)用來完成中間計算。

當(dāng)你向一個 RLM 發(fā)起查詢時，「根」語言模型（root LM）可以把整個上下文當(dāng)作可操作的環(huán)境來探索和處理。它會通過遞歸調(diào)用（R）LM，將對任意結(jié)構(gòu)或任意長度上下文的處理任務(wù)分解并逐級委托，從而實現(xiàn)可擴展的推理能力。

遞歸語言模型（RLM）調(diào)用取代了傳統(tǒng)的語言模型調(diào)用。它為用戶提供了一種「仿佛上下文無限大」的體驗，但在底層，語言模型會自動對上下文進行管理、分區(qū)，并根據(jù)需要遞歸調(diào)用自身或其他 LM，從而避免出現(xiàn) context rot（上下文退化）問題。

研究者將這一機制實現(xiàn)為一個類似 Jupyter 的 REPL 環(huán)境：

核心思想是：將用戶的 prompt 存入一個 Python 變量中，然后提供一個 REPL 循環(huán)給 LLM，讓它可以在不一次性讀取全部內(nèi)容的前提下，主動嘗試?yán)斫夂筒僮?prompt。

「根」語言模型（root LM）通過編寫代碼并查看每個單元格的輸出，與這個環(huán)境進行交互；在此過程中，它還可以在 REPL 環(huán)境中遞歸調(diào)用其他 LM 或 RLM，以此在上下文中進行導(dǎo)航和解析。

這種方式要比任何「分塊（chunking）」策略都更加通用且更智能。研究者認(rèn)為：應(yīng)該讓語言模型自己決定如何探索、拆解并遞歸地處理長 prompt，而不是由人為制定固定的切分策略。

RLM 框架實例為根 LM 提供了在 Python 筆記本環(huán)境中分析上下文的能力，并能在任何存儲在變量中的字符串上啟動遞歸 LM 調(diào)用（深度 = 1）。LM 通過輸出代碼塊進行交互，并能在其上下文中接收（截斷的）輸出版本。完成時，它輸出帶有 FINAL (…) 標(biāo)簽的最終答案，或者可以選擇使用代碼執(zhí)行環(huán)境中的字符串 FINAL_VAR (…)。

這種結(jié)構(gòu)在實際使用中帶來了多項明顯的優(yōu)勢：

• 根語言模型（root LM）的上下文窗口很少被「塞滿」 —— 因為它從不直接讀取完整上下文，它接收的輸入規(guī)模增長得很慢。
• root LM 擁有靈活的上下文訪問策略 —— 它可以只查看部分上下文，或者對上下文塊進行遞歸處理。例如，當(dāng)任務(wù)是尋找「needle-in-the-haystack」信息或需要多跳推理時，root LM 可以先通過正則表達式（regex）等方式粗略篩選上下文范圍，再對篩選結(jié)果發(fā)起遞歸式 LM 子調(diào)用。這對于任意長度的上下文輸入尤其有價值，因為對整個長文檔現(xiàn)檢索（on-the-fly indexing）通常代價很高。
• 理論上，RLM 能處理任何可以加載到內(nèi)存的模態(tài)數(shù)據(jù) —— root LM 可以完全掌控數(shù)據(jù)的查看與轉(zhuǎn)換方式，并在此基礎(chǔ)上繼續(xù)向遞歸 LM 發(fā)起子查詢。

RLM 框架的一個顯著優(yōu)勢在于：可以在一定程度上解釋它的行為軌跡，理解它是如何一步步推理并得出最終答案的。研究團隊編寫了一個簡易可視化工具，用來觀察 RLM 的推理路徑，展示了 RLM 實際在「動手做什么」。

令人振奮的早期結(jié)果

研究者一直在尋找能夠真實反映長上下文任務(wù)場景的基準(zhǔn)測試，例如 長時間多輪的 Claude Code 會話。他們希望通過這些任務(wù)重點突出當(dāng)今前沿模型面臨的兩類核心限制：

1. 上下文退化現(xiàn)象 —— 模型性能隨著上下文長度增加而退化；

2. 系統(tǒng)層面的約束 —— 模型在處理超大型上下文時出現(xiàn)的架構(gòu)或交互瓶頸。

激動人心的成果 — 處理上下文退化

RLMs 旨在解決上下文退化問題，即當(dāng)你有一個很長的 Claude Code 或 Cursor 實例時，它無法正確處理你的長歷史記錄的奇怪現(xiàn)象。

OOLONG 是一個具有挑戰(zhàn)性的新型長上下文基準(zhǔn)，其中模型在極其密集的上下文中回答查詢。研究者選擇了一個特別困難的分割點，在 OOLONG 基準(zhǔn)測試的 trec_coarse 數(shù)據(jù)集上報告結(jié)果，GPT-5 在 132-263k token 上下文中得分約為 33%。

與此同時，一個使用 GPT-5-mini 的 RLM 在 132k 情況下以超過 114%（即超過兩倍）的低查詢成本優(yōu)于 GPT-5，在 263k 情況下以49% 的成本優(yōu)于 GPT-5！

RLM (GPT-5-mini) 比 GPT-5 高出 34 分以上（約增長 114%），并且?guī)缀趺總€查詢的成本都相同（研究者發(fā)現(xiàn)中位數(shù)查詢更便宜，因為有些異常昂貴的查詢）。

RLM (GPT-5-mini) 比 GPT-5 高出 15 分以上（約 49% 的提升），并且平均每個查詢的成本更低。

令人興奮的結(jié)果 — 超大上下文

RLM 的設(shè)計目標(biāo)之一，就是在無需額外輔助結(jié)構(gòu)的情況下，處理近乎無限長度的上下文。

BrowseComp-Plus（BC+） 是一個 DeepResearch 任務(wù)基準(zhǔn)，模型需要通過檢索多個離線文檔，來回答多跳組合性問題（multi-hop compositional questions）。

在目前的初步實驗中，研究者從 BC+ 中抽取了一個小規(guī)模的查詢子集，然后直接將不同數(shù)量的文檔（從 10 份擴展到 1000 份，對應(yīng)約 10 萬到 1000 萬 tokens）原樣塞進上下文中。實驗結(jié)果顯示：基于 GPT-5 的 RLM 在跨越這些規(guī)模時性能并未下降，甚至優(yōu)于采用 ReAct + 檢索循環(huán)（retriever loops）的方法

研究者在 BrowseComp-Plus 上對 20 個隨機查詢繪制了各種方法的性能和每個答案的 API 成本，隨著上下文文檔數(shù)量的增加。只有迭代方法（RLM、ReAct）在 100 篇文檔以上時仍保持合理性能。

這些實驗結(jié)果令人振奮：在沒有進行任何額外的微調(diào)或架構(gòu)改動的前提下，就能夠在真實基準(zhǔn)上處理超過 1000 萬 tokens 規(guī)模的上下文，并且完全不依賴檢索器（retriever）！

思考與總結(jié)

RLM 不是 agent，也不只是作總結(jié)。一個系統(tǒng)中使用多次 LM 調(diào)用的想法并不新穎 —— 從廣義上講，這正是多數(shù) Agent 框架所做的事情。在現(xiàn)實中，最接近的例子是 ROMA Agent，它會分解問題并運行多個子代理來解決每一部分。另一個常見的例子是 Cursor 和 Claude Code 這樣的代碼助手，它們會在上下文越來越長時對歷史進行摘要或裁剪。這些方法通常是從任務(wù)或問題的角度來理解多輪 LM 調(diào)用的分解。而研究者們堅持認(rèn)為，LM 調(diào)用可以從上下文的角度進行分解，而分解方式應(yīng)完全由語言模型自己來決定。

固定格式對 scaling laws 的價值。從 CoT、ReAct、指令微調(diào)、推理模型等理念中，得到的經(jīng)驗是：以可預(yù)測或固定的格式向模型呈現(xiàn)數(shù)據(jù)，對于提升性能至關(guān)重要?；舅悸肥?，如果能將訓(xùn)練數(shù)據(jù)的結(jié)構(gòu)約束到模型預(yù)期的格式，就可以用合理的數(shù)據(jù)量顯著提升模型性能。將這些理念應(yīng)用到改進 RLM 之上，或許可以作為另一條擴展軸。

隨著 LM 的進步，RLM 也會進步。最后，RLM 調(diào)用的性能、速度和成本與底層模型能力的提升直接相關(guān)。如果明天最強的前沿語言模型可以合理處理 1000 萬 token 的上下文，那么一個 RLM 就可以合理處理 1 億 token 的上下文（可能成本還只有一半）。

研究者認(rèn)為，RLM 與現(xiàn)代 Agent 是兩種根本不同的押注方向。Agent 是基于人類 / 專家的直覺來設(shè)計如何將問題拆分為語言模型可以消化的形式。而 RLM 的設(shè)計原則是，應(yīng)該由語言模型自己決定如何拆分問題，使之可被語言模型消化。

研究者坦言：「我個人并不知道最終什么會奏效，但我很期待看到這個思路會走向何處！」