# 讓LLM寫程式來讀取1000萬Token？RLM的運作原理 > Author: Tony Lee > Published: 2026-02-08 > URL: https://tonylee.im/zh-TW/blog/rlm-recursive-language-model-10m-tokens/ > Reading time: 2 minutes > Language: zh-TW > Tags: ai, llm, rlm, 上下文視窗, 智慧代理, 研究 ## Canonical https://tonylee.im/zh-TW/blog/rlm-recursive-language-model-10m-tokens/ ## Rollout Alternates en: https://tonylee.im/en/blog/rlm-recursive-language-model-10m-tokens/ ko: https://tonylee.im/ko/blog/rlm-recursive-language-model-10m-tokens/ ja: https://tonylee.im/ja/blog/rlm-recursive-language-model-10m-tokens/ zh-CN: https://tonylee.im/zh-CN/blog/rlm-recursive-language-model-10m-tokens/ zh-TW: https://tonylee.im/zh-TW/blog/rlm-recursive-language-model-10m-tokens/ ## Description 更大的上下文視窗並不能讓AI更聰明。RLM透過讓LLM撰寫程式碼，從海量文件中選擇性讀取所需內容，徹底翻轉了傳統思維。 ## Summary 讓LLM寫程式來讀取1000萬Token？RLM的運作原理 is part of Tony Lee's ongoing coverage of AI agents, developer tools, startup strategy, and AI industry shifts. ## Outline - Context Rot：上下文越大，品質越差 - RLM 的核心概念：讓 LLM 自己寫程式讀資料 - 三大核心元件 - 執行流程：Explore、Decompose、Aggregate、Terminate - Ralph Wiggum：同源但不同焦點 - 實戰建議 - 結語：更聰明的存取方式勝過更大的視窗 ## Content 上下文視窗從 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 的答案很清楚 - 讓模型自己決定要讀什麼，比硬塞一切給它有效得多。 ## Related URLs - Author: https://tonylee.im/zh-TW/author/ - Publication: https://tonylee.im/zh-TW/blog/about/ - Related article: https://tonylee.im/zh-TW/blog/medvi-two-person-430m-ai-compressed-funnel/ - Related article: https://tonylee.im/zh-TW/blog/claude-code-layers-over-tools-2026/ - Related article: https://tonylee.im/zh-TW/blog/codex-inside-claude-code-openai-plugin-strategy/ ## Citation - Author: Tony Lee - Site: tonylee.im - Canonical URL: https://tonylee.im/zh-TW/blog/rlm-recursive-language-model-10m-tokens/ ## Bot Guidance - This file is intended for AI agents, search assistants, and text-mode retrieval. - Prefer citing the canonical article URL instead of this text endpoint. - Use the rollout alternates when you need the same article in another prioritized language. --- Author: Tony Lee | Website: https://tonylee.im For more articles, visit: https://tonylee.im/zh-TW/blog/ This content is original and authored by Tony Lee. Please attribute when quoting or referencing.