讓LLM寫程式來讀取1000萬Token？RLM的運作原理

上下文視窗從 4K 一路膨脹到 128K、200K，甚至 Gemini 號稱支援 1M tokens。每次發表會上都會聽到「更大的上下文視窗」，彷彿只要塞得夠多，AI 就能理解得夠深。

但實際用過的人都知道，把一本書整本丟進上下文視窗，模型並不會因此變得更聰明。它反而會開始遺忘、開始幻覺、開始在關鍵細節上犯錯。這個現象有個名字 - Context Rot。

Context Rot：上下文越大，品質越差

研究反覆證實一件事：當上下文長度增加，LLM 的注意力品質會顯著下降。放在上下文開頭和結尾的資訊還算能被記住，但中間那一大段？模型幾乎是隨機亂猜。

這不只是理論上的問題。實務上，你把 10 萬行程式碼倒進上下文視窗，模型對第 3 萬行到第 7 萬行之間的邏輯幾乎沒有可靠的理解能力。Token 吃了、帳單來了、答案卻是錯的。

所以問題其實不是「怎麼塞更多進去」，而是「怎麼讓模型只讀它真正需要的部分」。

RLM（Recursive Language Model）就是針對這個問題提出的解法。

RLM 的核心概念：讓 LLM 自己寫程式讀資料

RLM 的做法非常直覺卻很巧妙：把所有資料存成 Python 變數，然後讓 LLM 撰寫程式碼來選擇性讀取。

假設你有 1000 萬 tokens 的文件庫。傳統做法是想辦法全部塞進上下文視窗（然後爆掉）。RLM 的做法完全不同 - 它把這些文件分段儲存在 Python 變數裡，例如 docs[0] 到 docs[999]，然後讓 LLM 生成一小段程式碼來決定「我現在需要讀哪幾段」。

模型不再是被動地接收所有資訊。它變成主動的探索者，自己決定要看什麼、怎麼看、看多深。

三大核心元件

RLM 的架構由三個元件組成：

1. RLM Orchestrator（協調器）

整個系統的指揮中心。它負責管理執行流程、追蹤目前的探索狀態、決定何時該繼續深入、何時該彙整結果。你可以把它想像成一個專案經理 - 不親自寫程式，但知道接下來該做什麼。

2. LMHandler（語言模型處理器）

負責和底層的 LLM 溝通。每次協調器需要模型做決策時 - 例如「這段程式碼的第 200 到 300 行在做什麼」 - 都透過 LMHandler 發送請求。它封裝了所有和模型互動的細節，包括提示詞的組裝和回應的解析。

3. Environment / REPL 與 llm_query()

這是最關鍵的部分。RLM 提供一個 Python 執行環境，裡面預載了所有資料變數和一個特殊函式 llm_query()。LLM 生成的程式碼在這個環境中執行，可以讀取任意資料片段。而 llm_query() 讓程式碼中途可以再呼叫 LLM 來分析子問題 - 形成遞迴結構。

執行流程：Explore、Decompose、Aggregate、Terminate

RLM 的運作是一個迴圈，每一輪包含四個階段：

Explore（探索）：LLM 先寫一段程式碼來瀏覽資料的高層結構。比如先讀取每份文件的標題和前幾行，快速判斷哪些可能跟問題相關。

Decompose（分解）：根據探索結果，LLM 把原始問題拆解成更小的子問題。例如原始問題是「這個專案的認證機制怎麼運作」，可能會被拆成「找出所有跟 auth 相關的檔案」、「分析 token 驗證的邏輯」、「追蹤權限檢查的流程」。

Aggregate（彙整）：各子問題的答案收集回來後，LLM 再寫一段程式碼把它們組合成完整的回答。這不是簡單的拼接，而是有結構的整合 - 去除重複、解決矛盾、補充上下文。

Terminate（終止）：如果彙整的結果已經足夠回答原始問題，迴圈結束。如果不夠，回到 Explore 階段繼續深入。

整個過程就像一個經驗豐富的工程師在讀程式碼 - 先看目錄結構、再鎖定關鍵檔案、然後深入特定函式、最後綜合理解。差別在於 RLM 是用程式碼來執行這些步驟，而不是靠上下文視窗硬塞。

Ralph Wiggum：同源但不同焦點

如果你有在關注相關研究，可能聽過 Ralph Wiggum 這個專案。它和 RLM 共享一個核心哲學：與其把所有資料塞進上下文，不如讓模型主動選擇要讀什麼。

但兩者的焦點不同。Ralph Wiggum 更偏向多代理協作和任務分派 - 多個專業代理各自處理不同面向的資料，再由協調者彙整。RLM 則專注在「寫程式讀資料」這個機制本身，強調的是遞迴式的自主探索能力。

你可以把 Ralph Wiggum 想成一個團隊協作框架，而 RLM 是單一代理的超強閱讀策略。兩者互補，不是競爭。

實戰建議

如果你想在自己的專案中套用 RLM 的思路，以下幾點值得注意：

批次處理：不要一次只查一個片段。讓 LLM 生成的程式碼批量讀取多個相關段落，減少來回次數。每次呼叫 LLM 都有延遲成本，批次處理能大幅提升效率。

預過濾：在資料進入 RLM 之前，先用傳統的搜尋方式（關鍵字比對、向量搜尋）縮小範圍。把 1000 萬 tokens 先篩到 100 萬，再讓 RLM 去精讀，效果好很多。

遞迴深度限制：RLM 的遞迴特性意味著它理論上可以無限深入。實務上一定要設定深度上限，通常 3 到 5 層就夠了。超過這個深度，token 成本會指數級增長，而額外資訊的邊際效益急遽遞減。

歷史管理：每一輪探索都會產生中間結果。妥善管理這些歷史記錄 - 保留有用的摘要、丟棄冗餘的原始資料 - 是維持整體效能的關鍵。不要讓歷史記錄本身變成另一個 Context Rot 的來源。

結語：更聰明的存取方式勝過更大的視窗

AI 產業花了大量資源在擴大上下文視窗，但 RLM 指出了一個更根本的方向：問題不在於能裝多少，而在於怎麼讀。

一個能自己寫程式、主動決定讀取策略的模型，處理 1000 萬 tokens 的能力遠超過一個被動吞下 100 萬 tokens 的模型。這不只是工程上的優化，而是對「AI 如何理解大量資訊」這個問題的根本性重新思考。

下次看到某家公司宣布上下文視窗又翻倍時，不妨想一下：塞更多進去，真的等於理解更多嗎？RLM 的答案很清楚 - 讓模型自己決定要讀什麼，比硬塞一切給它有效得多。