@akshay_pachaar：Recursive Language Models，清晰解析 來自 MIT 的研究人員最近提出了一個巧妙的解決方案，用來應對現代 LLM 最大的限制之一：…

Recursive Language Models，清晰解析 來自 MIT 的研究人員最近提出了一個巧妙的解決方案，用來應對現代 LLM 最大的限制之一：Context Rot（上下文衰減）。 Context Rot 的情況如下： 你將一份 200 頁的文件貼進 ChatGPT，並問了一個簡單的問題。儘管答案就在第 53 頁，但模型給出的回答卻是錯的。 這並不是因為你超過了 context window 的限制，而是因為資訊量太大，模型在一次處理過多內容時，推理能力下降了。 他們提出的優雅修正方案稱為 Recursive Language Models (RLM)。其結果令人驚豔，且核心概念出奇地直觀。 讓我們一步步來理解。 問題所在：Context Rot 是推理失敗，而非視窗失敗 一個宣稱擁有 1M token 視窗的模型，在處理 50K token 的文件時仍可能產出垃圾內容，而原因與能塞進多少文字無關。 頂尖模型在「大海撈針」(needle-in-a-haystack) 的基準測試中表現優異。你將一句奇怪的句子藏在堆積如山的填充文字中，詢問關於該句子的資訊，模型確實找得到。 但該測試衡量的是針對一堆 token 的檢索能力，而非跨越這些 token 的推理能力。 頂尖模型能通過「大海撈針」測試，但如果你要求它們對數千個隱藏的條目進行計數、分類或推理，效能就會崩潰。 你可能也注意到了： 長時間的 Claude Code 會話會變得遲鈍 冗長的 ChatGPT 對話需要更多的重複確認 模型並不是產生幻覺，它只是隨著 context 變大而變得「更笨」了。 解決方案：Recursive Language Models (RLM) 核心概念很簡單： 不要強迫模型一次處理所有內容，而是讓它將 context 切分成較小的片段，並以遞迴方式處理。 關鍵的轉變在於「以 context 為中心的分解」： Agent 是根據人類設計的步驟來分解任務 RLM 則是讓模型自行分解 context 本身 模型變成了一個分析資料集的程式設計師，而不是一個為了應付考試而死記硬背的學生。 RLM 如何運作 將查詢與 context 分離 在一般的 LLM 呼叫中，查詢與完整的 context 會一起塞進同一個 prompt。在生成開始之前，所有你想讓模型看到的內容都必須塞進那個單一的 prompt 視窗中。 RLM 打破了這個假設。Context 存在於 prompt 之外，位於一個 runtime 的記憶體槽位中，而根模型 (root model) 只會看到問題和一組工具。 想像一下 Jupyter notebook。你將一個 dataframe 載入到名為 df 的變數中，從那時起，每個儲存格都會參照 df，而不需要重新上傳 CSV。 RLM 借用了完全相同的思維模型。那份 200 頁的文件變成了一個變數（我們稱之為 ctx），它存在於一個 REPL 環境中，模型可以透過呼叫工具與其互動。 模型獲得工具 根模型無法直接讀取 ctx，因此整個設計的成敗取決於它用來探測該變數的工具。論文為模型提供了四種工具，它們共同涵蓋了資料分析師會使用的所有存取模式： 窺探 context (Peek)：查看前 2,000 個字元以了解結構 使用 Regex 進行 Grep：篩選相關行 分割 (Partition)：將內容切分成更小的區塊 遞迴呼叫 (Recursive call)：對這些區塊呼叫模型本身 策略從任務中浮現 Agent 框架傳統上是硬編碼分解過程的。人類預先選擇步驟、順序和備援策略，模型只是扮演人類已經寫好的腳本角色。 RLM 則相反。根模型會根據它在搜尋過程中發現的內容，自行決定如何分解問題。 它可能會先執行 Grep，然後再分割；或者先窺探，再進行總結。它會自行找出方法，而不是遵循人類設計的工作流程。 具體範例 假設你有 5,000 筆客戶支援工單，並詢問：「在使用者 12345、67890 和 11111 中，有多少問題是關於帳單的？」 一般的 LLM 會收到全部 5,000 筆工單，試圖掃描所有內容，然後在計數時出錯。 RLM 的處理方式則不同： 窺探結構：「每一行都有日期、使用者 ID、問題」 Grep 目標使用者，將 5,000 行縮減為 50 行 發起遞迴呼叫：「將每一筆分類為帳單問題或其他」 回傳：最終結果 根模型的 context 在整個過程中都保持很小。沒有衰減。 為何這很重要 沒有 Context Rot：無論文件大小如何，準確度都能維持 無限 context：10M token？只要切分更多次即可 可解釋性：精確查看模型做了什麼 具成本效益：較小的呼叫勝過一次巨大的 API 呼叫 未來保障：隨著 LLM 進步，RLM 會自動隨之提升 RLM 將 context 視為可以透過程式探索的資料。 模型結合了程式碼執行與語言推理。這不是總結，也不是僵化的 Agent。它會根據所發現的內容，決定如何分解問題。 若要深入了解，我分享了研究論文以及一個你可以基於其上進行開發的 RLM 啟動程式碼。 論文 → GitHub → --- 感謝閱讀！ 如果你覺得有收穫，請分享給你的網路。 找到我 →@akshay_pachaar ✔️ 獲取更多關於 LLM、AI Agent 和機器學習的見解與教學！ 原文：https://easyvibecoding.app/curated/969