# 策展 · X (Twitter) 🔥🔥🔥🔥

> 作者：Akshay 🚀 (@akshay_pachaar) · 平台：X (Twitter) · 日期：2026-04-27

> 原始來源：https://x.com/akshay_pachaar/status/2048757569775378858

## 中文摘要

# Recursive Language Models，清晰解析

來自 MIT 的研究人員最近提出了一個巧妙的解決方案，用來應對現代 LLM 最大的限制之一：Context Rot（上下文衰減）。

Context Rot 的情況如下：

你將一份 200 頁的文件貼進 ChatGPT，並問了一個簡單的問題。儘管答案就在第 53 頁，但模型給出的回答卻是錯的。

這並不是因為你超過了 context window 的限制，而是因為資訊量太大，模型在一次處理過多內容時，推理能力下降了。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777306163959-diaHG6kE7acAAVxySjpg.jpg)

他們提出的優雅修正方案稱為 Recursive Language Models (RLM)。其結果令人驚豔，且核心概念出奇地直觀。

讓我們一步步來理解。

# 問題所在：Context Rot 是推理失敗，而非視窗失敗

一個宣稱擁有 1M token 視窗的模型，在處理 50K token 的文件時仍可能產出垃圾內容，而原因與能塞進多少文字無關。

頂尖模型在「大海撈針」(needle-in-a-haystack) 的基準測試中表現優異。你將一句奇怪的句子藏在堆積如山的填充文字中，詢問關於該句子的資訊，模型確實找得到。

但該測試衡量的是針對一堆 token 的檢索能力，而非跨越這些 token 的推理能力。

頂尖模型能通過「大海撈針」測試，但如果你要求它們對數千個隱藏的條目進行計數、分類或推理，效能就會崩潰。

你可能也注意到了：

- 長時間的 Claude Code 會話會變得遲鈍

- 冗長的 ChatGPT 對話需要更多的重複確認

模型並不是產生幻覺，它只是隨著 context 變大而變得「更笨」了。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777306163971-iaHG6kRWxbYAAKVBKjpg.jpg)

# 解決方案：Recursive Language Models (RLM)

核心概念很簡單：

不要強迫模型一次處理所有內容，而是讓它將 context 切分成較小的片段，並以遞迴方式處理。

關鍵的轉變在於「以 context 為中心的分解」：

- Agent 是根據人類設計的步驟來分解任務

- RLM 則是讓模型自行分解 context 本身

模型變成了一個分析資料集的程式設計師，而不是一個為了應付考試而死記硬背的學生。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777306164464-iaHG6kpjVaQAABTKWjpg.jpg)

# RLM 如何運作

## 1. 將查詢與 context 分離

在一般的 LLM 呼叫中，查詢與完整的 context 會一起塞進同一個 prompt。在生成開始之前，所有你想讓模型看到的內容都必須塞進那個單一的 prompt 視窗中。

RLM 打破了這個假設。Context 存在於 prompt 之外，位於一個 runtime 的記憶體槽位中，而根模型 (root model) 只會看到問題和一組工具。

想像一下 Jupyter notebook。你將一個 dataframe 載入到名為 `df` 的變數中，從那時起，每個儲存格都會參照 `df`，而不需要重新上傳 CSV。

RLM 借用了完全相同的思維模型。那份 200 頁的文件變成了一個變數（我們稱之為 `ctx`），它存在於一個 REPL 環境中，模型可以透過呼叫工具與其互動。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777306164026-iaHG6lCWYbQAADeJkjpg.jpg)

## 2. 模型獲得工具

根模型無法直接讀取 `ctx`，因此整個設計的成敗取決於它用來探測該變數的工具。論文為模型提供了四種工具，它們共同涵蓋了資料分析師會使用的所有存取模式：

- 窺探 context (Peek)：查看前 2,000 個字元以了解結構

- 使用 Regex 進行 Grep：篩選相關行

- 分割 (Partition)：將內容切分成更小的區塊

- 遞迴呼叫 (Recursive call)：對這些區塊呼叫模型本身

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777306164055-iaHG6ldOpbQAAAJptjpg.jpg)

## 3. 策略從任務中浮現

Agent 框架傳統上是硬編碼分解過程的。人類預先選擇步驟、順序和備援策略，模型只是扮演人類已經寫好的腳本角色。

RLM 則相反。根模型會根據它在搜尋過程中發現的內容，自行決定如何分解問題。

它可能會先執行 Grep，然後再分割；或者先窺探，再進行總結。它會自行找出方法，而不是遵循人類設計的工作流程。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777306164091-iaHG6lh7rbkAADNvnjpg.jpg)

# 具體範例

假設你有 5,000 筆客戶支援工單，並詢問：「在使用者 12345、67890 和 11111 中，有多少問題是關於帳單的？」

一般的 LLM 會收到全部 5,000 筆工單，試圖掃描所有內容，然後在計數時出錯。

RLM 的處理方式則不同：

1. 窺探結構：「每一行都有日期、使用者 ID、問題」

2. Grep 目標使用者，將 5,000 行縮減為 50 行

3. 發起遞迴呼叫：「將每一筆分類為帳單問題或其他」

4. 回傳：最終結果

根模型的 context 在整個過程中都保持很小。沒有衰減。

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777306164003-diaHG6lnNuaMAAO9qjpg.jpg)

# 為何這很重要

- 沒有 Context Rot：無論文件大小如何，準確度都能維持

- 無限 context：10M token？只要切分更多次即可

- 可解釋性：精確查看模型做了什麼

- 具成本效益：較小的呼叫勝過一次巨大的 API 呼叫

- 未來保障：隨著 LLM 進步，RLM 會自動隨之提升

![](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/1777306164038-diaHG6lrE5bQAA8jLjpg.jpg)

RLM 將 context 視為可以透過程式探索的資料。

模型結合了程式碼執行與語言推理。這不是總結，也不是僵化的 Agent。它會根據所發現的內容，決定如何分解問題。

若要深入了解，我分享了研究論文以及一個你可以基於其上進行開發的 RLM 啟動程式碼。

- 論文 →

- GitHub →

---

感謝閱讀！

如果你覺得有收穫，請分享給你的網路。

找到我 →@akshay_pachaar ✔️

獲取更多關於 LLM、AI Agent 和機器學習的見解與教學！

## 標籤

LLM, 研究論文, ChatGPT, OpenAI, MIT