Recursive Language Models (RLM)：MIT 突破超長文檔處理嘅新架構

2026 年初，MIT CSAIL 發表咗一個突破性嘅架構 Recursive Language Models (RLM)，徹底改變大型語言模型處理超長文檔嘅方式。透過遞歸調用，可以處理 1000 萬+ tokens 嘅文檔，性能提升高達 91.3%！

TL;DR

核心重點：

• 🔄 核心創新：將 context 從 "輸入" 變成 "環境"，模型主動探索而唔係被動接收
• 🚀 突破限制：處理 10M+ tokens，遠超所有現有 LLM（Gemini 只有 1M tokens）
• ✅ 消除 context rot：性能保持穩定，唔會隨文檔長度退化（baseline：78%→18%，RLM：82%→86%）
• 💰 成本效益：只處理相關部分，節省 60-90% token usage
• 📊 實驗結果：BrowseComp+ 準確率提升 +276%，OOLONG F1 score 由 0.04%→58%

目錄

傳統 LLM 嘅長文檔問題

Context Window 限制

大部分 LLM 都有固定嘅 context window，處理長文檔時會遇到好多問題：

就算 context window 大，都會遇到呢啲問題：

• 📉 性能下降：Window 越大，attention 質量越差
• 💸 成本高昂：計算複雜度係 $O(n^2)$，超貴
• 🧠 記憶退化：模型會"忘記"太前面嘅內容

Context Rot：最嚴重嘅問題

**Context Rot（上下文退化）**係指當 context 太長，模型會"迷失喺資訊海洋"，關鍵信息被埋沒，推理能力急劇下降。

⚠️ 真實例子：分析 100 頁法律合約
假設你要 LLM 分析一份 100 頁嘅法律合約，搵出所有 termination clauses：

# 傳統做法  
prompt = f"""  
{entire_100_page_contract}  # ~50,000 tokens  
Question: What are the termination clauses?  
"""  
# 結果：模型可能會漏掉第 23 頁嘅關鍵條款！  

點解會咁？

• 100 頁 = ~50,000 tokens

• 每個 token 要 attend 50,000 個其他 tokens

• 距離遠嘅 token 之間 attention weight 會好細

• 結果：遠處嘅信息被"稀釋"

現有解決方案（同佢哋嘅問題）

1. 擴大 Context Window

做法：訓練更大 window 嘅模型（例如 Gemini 1M tokens）

問題：

• ❌ 計算成本爆炸（$O(n^2)$ complexity）
• ❌ Context rot 仍然存在
• ❌ 推理質量下降

2. RAG (Retrieval-Augmented Generation)

做法：先用向量搜索揾出相關嘅文檔片段，再餵俾 LLM 生成答案

工作流程：

問題：

• ❌ 需要預先 chunk 同 embed 文檔
• ❌ 可能搜唔到跨 chunk 嘅關係
• ❌ 依賴外部 retrieval 質量

3. Summarization（摘要）

做法：將長文檔壓縮成摘要

問題：

• ❌ 信息丟失：摘要會遺漏細節
• ❌ 唔適合需要精確信息嘅任務
• ❌ 壓縮本身都需要 LLM，有成本

RLM 嘅革命性想法

MIT 嘅研究團隊提出咗一個激進嘅想法：

💡 核心洞察：將 context 從 "輸入" (input) 變成 "環境" (environment)

• 傳統 LLM："我俾晒本書你，你一次過讀晒佢"（被動接收）

• RLM："我俾個圖書館你，你自己去搵、去讀、去總結"（主動探索）

人類 vs 傳統 LLM vs RLM

諗返你點樣做研究：

傳統 LLM 做法（唔似人類）：

1. 一次過讀晒 50 篇論文（所有字）
2. 嘗試喺腦入面記住所有細節
3. 回答問題

→ 結果：記憶爆炸，遺漏關鍵點

RLM 做法（似人類）：

1. 先睇所有論文嘅 abstract（high-level overview）
2. 識別邊幾篇同問題相關
3. 深入讀呢幾篇嘅 methodology
4. 如果需要，再調用自己去分析 specific sections
5. 綜合結果

→ 結果：有條理，重點突出

RLM 點樣運作？

核心機制：REPL Environment

RLM 將 context 包裝喺一個 REPL (Read-Eval-Print Loop) 環境入面，俾模型可以：

四個關鍵操作

1. Read（讀取）

模型可以要求讀取 context 嘅特定部分：

# 例子：讀取第 100-200 行
result = rlm.read(start=100, end=200)

好處：唔使一次過 load 晒整個文檔入 context window

2. Search（搜索）

模型可以搜索關鍵詞或 pattern：

# 搜索所有包含 "termination clause" 嘅段落
matches = rlm.search("termination clause")
# 返回：[(line_120, snippet), (line_450, snippet), ...]

好處：快速定位相關信息，唔使盲目掃描

3. Slice（切片）

提取特定範圍嘅內容：

# 提取第 3-5 章
chapters_3_5 = rlm.slice(section="chapters", start=3, end=5)

好處：按邏輯結構切分，而唔係 arbitrary chunks

4. Recurse（遞歸）

🔄 呢個係最強大嘅功能！
模型可以調用另一個 RLM instance 處理子問題。

關鍵機制：Fresh Context Window

當 Main RLM 調用 Sub RLM 時，Sub RLM 會獲得一個全新、空白嘅 context window。

• Main RLM 嘅 context：包含高層次嘅搜索結果同摘要

• Sub RLM 嘅 context：只包含被選中嘅 slice（例如 500-1000 tokens）同子問題

這就是為什麼 RLM 可以處理無限長度——因為任何單一 instance 永遠只處理 fit 入 window 嘅小量數據！

Live Example：分析 100 頁法律合約

讓我哋睇下 RLM 點樣實際運作。假設我哋要分析一份 100 頁嘅合約，搵出所有 termination clauses 並分析條件：

def analyze_contract_with_rlm(contract_text):
    # 創建主 RLM
    rlm = RLM(context=contract_text, model="gpt-4")
    
    # === 階段 1: 探索 ===
    # 模型自己決定先 search 關鍵詞
    search_results = rlm.search("termination")
    # 返回：找到 5 個匹配位置
    
    # === 階段 2: 定位 ===
    # 讀取每個匹配位置嘅周邊 context
    clause_ranges = []
    for match in search_results:
        snippet = rlm.read(
            start=match.position - 500, 
            end=match.position + 500
        )
        clause_ranges.append(snippet)
    
    # === 階段 3: 遞歸分析 ===
    # 對每個 clause 創建新嘅 RLM instance 做深度分析
    analyses = []
    for i, clause in enumerate(clause_ranges):
        # 遞歸調用！
        sub_rlm = RLM(context=clause, model="gpt-4")
        analysis = sub_rlm.query(
            "Analyze this termination clause: "
            "1) What are the conditions? "
            "2) Who can terminate? "
            "3) What are the penalties?"
        )
        analyses.append({
            "clause_id": i,
            "location": clause.position,
            "analysis": analysis
        })
    
    # === 階段 4: 綜合 ===
    summary = rlm.query(
        f"Given these {len(analyses)} termination clauses, "
        f"summarize the overall termination conditions."
    )
    
    return {"clauses": analyses, "summary": summary}

執行流程視覺化

關鍵點：

• 主 RLM 從頭到尾都冇讀過成份合約！
• 佢只係讀咗相關嘅部分（可能只係 5-10% 嘅內容）
• 子 RLMs 各自處理小部分，避免 context rot
• 最後主 RLM 綜合結果

效率對比：

• 傳統 LLM：處理 50,000 tokens → $O(n^2)$ = 2.5B operations
• RLM：5 次搜索 + 5 個 1000-token 子任務 → ~5M operations
• 節省 500x 計算！

實驗結果：驚人嘅提升

1. BrowseComp+（網頁理解）

任務：喺多個網頁入面搵特定信息

RLM 比 baseline 提升咗 91.3 個百分點！

2. OOLONG-Pairs（高複雜度推理）

任務：喺超長文檔入面做複雜配對推理（難度隨長度平方增長）

🎯 關鍵發現
當任務複雜度高，傳統 LLM 會 catastrophically fail（F1 只有 0.04%），但 RLM 仍然可以達到 58%！

3. Context Rot 測試

呢個係最重要嘅測試——RLM 有冇真係解決 context rot？

實驗設定

將文檔長度由 4K tokens 增加到 64K tokens，睇性能點變化。

結果

驚人發現：

• ❌ Baseline GPT-4：性能隨長度急劇下降（78% → 18%）
• ✅ RLM：性能保持穩定甚至稍微上升（82% → 86%）

結論：RLM 真係解決咗 context rot 問題！

4. 超長 Context 測試

MIT 團隊仲測試咗 RLM 喺極端長度嘅表現：

10 Million Tokens 測試：

• 文檔大小：~7,500 頁
• 傳統 LLM：完全處理唔到（超出所有現有 context window）
• RLM：成功處理，準確率 > 80%

點做到？

• RLM 唔使 load 晒 10M tokens 入 memory
• 佢用遞歸調用，每次只處理相關嘅小部分
• 實際用到嘅 context 可能只係 ~100K tokens

技術深究：訓練與模型需求

需要重新訓練模型嗎？

短答案：唔需要！RLM 主要係一種 Inference-time Technique（推理時技術）。

1. 基於現有 LLM (Inference-only)

最簡單嘅 RLM 實現係完全唔需要訓練嘅。佢只係一個 Agentic Framework（類似 LangChain），通過 Prompt Engineering 教導現有模型（如 GPT-4, Claude 3）去使用 4 個工具（Search, Read, Slice, Recurse）。

• 優點：即插即用，可以用最強嘅模型
• 缺點：Prompt 佔用 context，而且模型可能唔係 100% 聽話

2. Fine-tuning (微調) 優化

雖然唔_需要_訓練，但在論文中，MIT 團隊發現 Fine-tuning 可以顯著提升表現。

• 目標：唔係教模型新知識，而係教佢**「點樣做一個好嘅 RLM Agent」**（即係幾時應該 search，幾時應該 recurse）。
• 數據集：使用合成數據（Synthetic Data），記錄「正確嘅探索路徑」。
• 結果：Fine-tuned 嘅 7B 模型（如 Llama 3 7B）在 RLM 架構下，表現甚至可以超越 GPT-4！

3. Context Window 關係

• RLM 唔會打破物理限制：如果你嘅模型 context window 係 8K，每個 RLM instance 最多都係睇 8K。
• RLM 繞過限制：通過將 10M tokens 嘅大文檔切分成無數個 <8K 嘅小 context，令整體系統可以處理無限長度。

RLM vs RAG：點解設計似但唔同？

好多人會問：RLM 同 RAG 有咩分別？佢哋嘅設計似唔似？

💡 核心哲學完全唔同
雖然兩者都係避免將整個文檔放入 context window，但方法同目標完全唔同：

• RAG："我幫你搵好相關內容，呢啲係最相關嘅 chunks"（靜態檢索）

• RLM："呢個係完整文檔環境，你自己主動探索同遞歸分析"（動態導航）

詳細比較

工作流程對比

RAG 工作流程

關鍵點：

• 文檔被預先處理，切成固定 chunks
• LLM 只能看到 retrieval 返回嘅 5 個 chunks
• 如果相關信息分散喺 10 個唔同 chunks，LLM 會遺漏一半

RLM 工作流程

關鍵點：

• 文檔保持完整，唔會預先切分
• LLM 主動探索，自己決定讀咩
• 可以遞歸處理複雜問題，每個子問題有獨立 context
• 如果相關信息分散，LLM 可以多次 search/read 全部搵出嚟

實際例子：分析法律合約

假設有一份 100 頁法律合約，要搵所有 termination clauses：

RAG 做法

# 1. 預處理（一次性）
chunks = split_document(contract, chunk_size=512)
embeddings = embed_chunks(chunks)
vectordb.store(embeddings)

# 2. 查詢
query = "Find all termination clauses"
query_embedding = embed_query(query)
relevant_chunks = vectordb.search(query_embedding, top_k=5)

# 3. 生成答案
response = llm.generate(
    context=relevant_chunks,  # 只有 5 個 chunks！
    question=query
)

問題：

• 合約有 7 個 termination clauses，但分散喺唔同位置
• Vector search 只返回 5 個最相關 chunks
• 可能遺漏第 6、7 個 clauses
• LLM 無法跨 chunks 理解關聯條款

RLM 做法

# 1. 創建 RLM（唔需預處理）
rlm = RLM(context=contract, model="gpt-4")

# 2. 查詢（LLM 自己探索）
response = rlm.query("Find all termination clauses")

# RLM 內部會咁做：
# Step 1: rlm.search("termination") → 找到 7 個位置
# Step 2: 對每個位置 rlm.read(position-500, position+500)
# Step 3: 對每個 clause 遞歸：
#         sub_rlm = RLM(clause_context)
#         sub_rlm.query("Analyze conditions, parties, penalties")
# Step 4: 綜合所有 7 個分析結果

優勢：

• 找到所有 7 個 clauses（唔會遺漏）
• 每個 clause 都有詳細分析（遞歸處理）
• 理解跨條款關係（例如條款 A 引用條款 B）

深層次嘅設計差異

RAG：Two-stage Pipeline

用戶問題 → [Retrieval] → [Generation]
         ↑              ↑
      被動檢索      基於檢索結果生成

• Retrieval 同 Generation 分離
• Retrieval 係 "dumb"（只係向量相似度）
• LLM 只負責最後嘅 generation
• 唔能夠 iterate：一次檢索，一次生成，結束

RLM：Iterative Exploration

用戶問題 → [LLM 規劃] → [探索] → [LLM 分析] → [遞歸] → [LLM 綜合]
           ↑            ↓         ↑            ↓         ↑
           └────────────┴─────────┴────────────┴─────────┘
                      LLM 主導整個過程

• LLM 主導整個過程
• 可以多次 iterate（search → read → recurse → synthesize）
• 智能探索：LLM 自己決定探索策略
• 可以根據中間結果調整下一步

何時用 RAG vs RLM？

用 RAG 如果：

✅ 知識庫穩定：文檔內容唔會頻繁變化，可以預先 embed

✅ Simple Q&A：問題係 straightforward fact-lookup（例如："公司政策係咩？"）

✅ 需要低 latency：用戶期望 <2 秒回應

✅ 大規模文檔集：有成千上萬份文檔，需要高效檢索

✅ 成本敏感：Embedding 可以 cache，長遠成本低

✅ 文檔獨立性強：每個段落相對獨立，唔需跨段落理解

典型場景：

• 客服 FAQ 系統
• 企業知識庫搜索
• 文檔問答機器人

用 RLM 如果：

✅ 複雜推理任務：需要跨文檔多個部分綜合理解

✅ 關係密切嘅文檔：段落之間有強關聯（例如法律條款互相引用）

✅ 唔想丟失信息：Chunking 可能破壞重要 context

✅ 動態文檔：文檔經常更新，唔想重複 embedding

✅ 結構化文檔：有明確邏輯結構（章節、條款、代碼模塊）

✅ 深度分析：需要遞歸分解問題（例如："分析每個 termination clause 嘅風險"）

典型場景：

• 法律合約分析
• 醫療記錄綜合診斷
• Codebase 理解同 debugging
• 科研文獻深度綜述
• 財務報告審計

可以結合使用嗎？

可以！ 兩者唔係互斥，而係可以互補：

混合架構：RAG + RLM

# 1. 用 RAG 快速縮小範圍
relevant_docs = rag_system.retrieve(query, top_k=10)

# 2. 用 RLM 深度分析每份文檔
results = []
for doc in relevant_docs:
    rlm = RLM(context=doc, model="gpt-4")
    analysis = rlm.query(f"Deep analysis: {query}")
    results.append(analysis)

# 3. 最終綜合
final_answer = synthesize(results)

優勢：

• RAG 負責快速過濾（從 1000 份文檔縮小到 10 份）
• RLM 負責深度分析（對每份文檔做詳細理解）
• 結合兩者優點：速度 + 深度

總結：核心差異

🎯 記住呢個類比：

• RAG = 圖書館員幫你搵書，然後你讀佢哋俾你嘅幾本

• RLM = 你自己喺圖書館探索，自由跳轉、交叉引用、深入研究

RAG 係 被動檢索 + 生成，RLM 係 主動探索 + 遞歸分析。

選擇指南：

• 需要速度同規模 → RAG
• 需要深度同準確 → RLM
• 兩者都需要 → 混合架構

唔係邊個更好，而係邊個更適合你嘅場景！

點樣用 RLM？

唔係邊個更好，而係邊個更適合你嘅場景！

RLM vs Agent Frameworks：係唔係一樣嘢？

好多人會覺得 RLM 好似 Agent frameworks（例如 LangChain Agents、AutoGPT、ReAct）。的確有相似之處，但都有重要差異。

相似之處

🤝 核心共通點：LLM 主導決策
RLM 同 Agent frameworks 都係俾 LLM 自己決定下一步做咩，而唔係被動跟住固定流程。

兩者都有嘅特性：

✅ Tool/Function Calling：LLM 可以調用外部工具

✅ Iterative Reasoning：可以多次思考同行動，唔係一次過生成答案

✅ Planning Capability：LLM 自己規劃策略

✅ Observation-Action Loop：觀察結果 → 決定下一步 → 執行 → 重複

工作流程對比

Agent Framework (例如 ReAct)：

用戶問題
  ↓
[LLM Thought] "我需要先搵資料"
  ↓
[Action] search("相關關鍵詞")
  ↓
[Observation] 搜索結果
  ↓
[LLM Thought] "我需要更多細節"
  ↓
[Action] read_page(url)
  ↓
[Observation] 頁面內容
  ↓
[LLM Thought] "我而家可以答"
  ↓
[Answer] 最終回答

RLM：

用戶問題
  ↓
[RLM Main] search("關鍵詞")
  ↓
[RLM Main] read(positions)
  ↓
[RLM Main] recurse → [RLM Sub-1] 分析部分 A
                   → [RLM Sub-2] 分析部分 B
  ↓
[RLM Main] 綜合子結果
  ↓
[Answer] 最終回答

你會發現：兩者都係 iterative decision-making！

關鍵差異

雖然相似，但 RLM 同通用 Agent frameworks 有幾個重要分別：

深入分析差異

1. Context 管理策略完全唔同

Agent Framework：累積式 Context

# Agent 嘅 context 會越嚟越長
context = [
    "User: 分析呢份文檔",
    "Thought: 我應該先 search",
    "Action: search('關鍵詞')",
    "Observation: 找到 10 個結果",
    "Thought: 我要讀第一個",
    "Action: read(result_1)",
    "Observation: [1000 tokens]",
    "Thought: 我要讀第二個",
    "Action: read(result_2)", 
    "Observation: [1000 tokens]",
    # ... context 越嚟越長，最終會 hit limit！
]

問題：

• Context 會不斷累積
• 最終會 hit context window limit
• 早期嘅 observations 會被 "遺忘"（context rot）

RLM：遞歸式 Fresh Context

# Main RLM：只保留高層次信息
main_context = [
    "User: 分析呢份文檔",
    "Search results: found 10 positions",
    "Recurse to Sub-RLM-1 for position 1",
    "Sub-RLM-1 返回：分析結果 A",  # 只係結果，唔係過程！
    "Recurse to Sub-RLM-2 for position 2", 
    "Sub-RLM-2 返回：分析結果 B",
    # Main context 保持簡潔
]

# Sub-RLM-1 有自己嘅 fresh context
sub_context_1 = [
    "Analyze this clause: [clause text]",
    "條件係...",
    "責任係...",
    # 完成後，只返回結果俾 Main
]

優勢：

• 每個 sub-task 有 fresh context window
• Main RLM 唔會被細節淹沒
• 完全避免 context rot

2. Recursion 係 RLM 嘅獨特設計

通用 Agent：順序調用工具

• Agent 調用工具
• 工具返回結果
• Agent 繼續（喺同一個 context）

RLM：遞歸調用自己

• RLM 可以創建 新嘅 RLM instance
• 每個 instance 有獨立 context
• 可以多層嵌套

類比：

• Agent = 你打電話去圖書館問資料，館員幫你搵，然後話你知
• RLM = 你將工作分俾團隊，每個人負責一部分，並且團隊成員可以再分工

3. Tool Set 嘅哲學唔同

Agent：越多工具越好

agent_tools = [
    "web_search",      # 網絡搜索
    "calculator",      # 計算器
    "code_interpreter",# 運行代碼
    "database_query",  # 查詢數據庫
    "send_email",      # 發郵件
    "file_read",       # 讀文件
    # ... 可以有幾十個工具
]

• 越多工具，Agent 越強大
• 適應更多任務

RLM：少即是多

rlm_operations = [
    "search",   # 搜索關鍵詞
    "read",     # 讀取範圍
    "slice",    # 切片
    "recurse",  # 遞歸！
]

• 只有 4 個操作
• 但組合起嚟可以處理極複雜嘅文檔
• 專注做好一件事

4. 實際例子對比

任務：分析 100 頁合約嘅風險

Agent 做法：

agent = Agent(tools=["search", "read", "analyze"])

# Agent 會咁做
1. search("risk") in contract
2. read(page_23)  # 累積到 context
3. read(page_45)  # 累積到 context
4. read(page_67)  # 累積到 context
5. analyze(all_context)  # Context 已經好長
6. 可能會 hit context limit 或 context rot

RLM 做法：

rlm = RLM(contract)

# RLM 會咁做
1. search("risk") → 找到 10 個位置
2. 對每個位置 recurse：
   - sub_rlm_1 = RLM(page_23_context)
   - sub_rlm_1.analyze_risk()
   - 返回：風險評分 + 摘要
3. Main RLM 只收到 10 個摘要（唔係 10 頁原文）
4. 綜合 10 個風險評估

關鍵差異：

• Agent：所有內容都喺主 context → context rot
• RLM：每個風險分析有獨立 context → 保持清晰

RLM 可以睇成係「專業化嘅 Agent」

類比：

• 通用 Agent = 通用助手（識做好多嘢，但每樣都唔係最專業）
• RLM = 文檔分析專家（只做一件事，但做到極致）

💡 核心區別：

• Agent Frameworks 係 "I can use tools to solve any problem"（工具導向）

• RLM 係 "I recursively navigate documents to deeply understand them"（遞歸導向）

可以結合嗎？

可以！ 你可以將 RLM 當成一個 Agent 嘅工具：

# Agent with RLM as a tool
agent = Agent(tools=[
    "web_search",
    "calculator", 
    "rlm_analyzer",  # RLM 作為一個工具！
])

# 用例
user: "分析呢份合約並計算總潛在損失"

agent:
  1. 調用 rlm_analyzer(contract) → 得到風險清單
  2. 調用 calculator(risks) → 計算總金額
  3. 返回結果

優勢：

• Agent 處理多樣化任務
• RLM 專注深度文檔分析
• 結合兩者優點

總結：Agent vs RLM

相似：

• 都係 iterative, tool-using, LLM-driven systems

唔同：

• Agent = 通用，任意工具，單一 context
• RLM = 專注文檔，固定操作，遞歸 context

記住：

• RLM 可以睇成係一種特殊設計嘅 Agent，專門為長文檔優化
• Recursion + fresh context 係 RLM 嘅核心創新，唔係所有 Agent frameworks 都有

選擇指南：

• 需要多樣化任務（搜網、寫代碼、操作 API）→ 用通用 Agent
• 需要深度理解長文檔（法律、醫療、代碼）→ 用 RLM
• 兩者都要 → 將 RLM 包裝成 Agent 嘅一個工具

點樣用 RLM？

安裝

MIT 團隊開源咗 RLM，有完整版同 minimal 版：

完整版

# GitHub repo
git clone https://github.com/alexzhang13/rlm
cd rlm
pip install -e .

Minimal 版（推薦初學者）

# 輕量版，適合快速實驗
git clone https://github.com/alexzhang13/rlm-minimal
cd rlm-minimal
pip install -e .

快速開始

from rlm import RLMEnvironment

# 1. 載入文檔
with open("long_document.txt") as f:
    context = f.read()

# 2. 創建 RLM
rlm = RLMEnvironment(
    context=context,
    model="gpt-4",  # 或者 "claude-3", "gpt-3.5-turbo"
    max_recursion_depth=5
)

# 3. Query
response = rlm.query(
    "What are the main conclusions of this document?"
)

print(response)

# 4. 睇 trace（可選）
print(rlm.get_trace())  # 睇模型做咗啲咩

Live Example：分析 Codebase

假設你有一個 1000+ 文件嘅 codebase，想搵 memory leak：

from rlm import RLMEnvironment
import os

# 載入整個 codebase
def load_codebase(path):
    files = []
    for root, dirs, filenames in os.walk(path):
        for filename in filenames:
            if filename.endswith('.py'):
                with open(os.path.join(root, filename)) as f:
                    files.append({
                        'path': os.path.join(root, filename),
                        'content': f.read()
                    })
    return '\n\n'.join([f"# File: {f['path']}\n{f['content']}" 
                        for f in files])

codebase = load_codebase("./my_project/")

# 創建 RLM
rlm = RLMEnvironment(
    context=codebase,
    model="gpt-4",
    max_recursion_depth=10,
    parallel_recursion=True  # 平行處理
)

# 分析 memory leak
analysis = rlm.query("""
This codebase has a memory leak. 
Find all places where resources might not be properly released.

Strategy:
1. Search for resource allocation patterns (open, malloc, etc.)
2. For each allocation, check if there's corresponding deallocation
3. Track control flow across files
4. Report suspicious locations
""")

print(analysis)

RLM 會點做？

1. Search 所有 open(), malloc(), database connections
2. 對每個 allocation 遞歸檢查是否有 deallocation
3. 追蹤跨文件嘅 control flow
4. 報告可疑嘅 locations

實際應用場景

1. 法律文件分析

contract = load_document("100_page_contract.pdf")
rlm = RLM(contract, model="gpt-4")

analysis = rlm.query("""
Analyze this contract and identify:
1. All termination clauses and their conditions
2. Liability limitations
3. Dispute resolution mechanisms
4. Any unusual or high-risk provisions
""")

優勢：

• 唔會漏掉埋喺中間嘅重要條款
• 可以跨章節理解複雜關係
• 提供詳細嘅每個條款分析

2. 科研文獻綜述

papers = [load_paper(f"paper_{i}.pdf") for i in range(50)]
combined = "\n\n".join(papers)

rlm = RLM(combined, model="gpt-4")

review = rlm.query("""
Synthesize these 50 papers on neural architecture search:
1. What are the main approaches?
2. How do they compare in performance?
3. What are open problems?
4. Suggest future research directions
""")

RLM 會：

• 先 search 每篇論文嘅 abstract 同 conclusion
• 識別主要方法（NAS, DARTS, ENAS, etc.）
• 遞歸分析每個方法嘅 details
• 比較 benchmark results
• 綜合成 coherent review

3. 醫療記錄分析

records = load_medical_history(patient_id="12345")  # 20 年病歷
rlm = RLM(records, model="gpt-4-medical")

diagnosis = rlm.query("""
Patient presents with symptoms X, Y, Z.

Based on their complete medical history:
1. What are relevant past conditions?
2. Drug interactions with current medications?
3. What tests should be ordered?
4. Differential diagnosis?
""")

優勢：

• 可以考慮幾十年嘅病史
• 唔會漏掉重要嘅歷史信息
• 發現 long-term patterns

限制同挑戰

⚠️ RLM 唔係萬能
雖然 RLM 好強大，但都有啲限制需要注意。

1. 依賴底層 LLM 質量

RLM 係 meta-framework，佢嘅表現受底層 LLM 影響：

• 如果底層 LLM 唔識 function calling，效果會差
• 需要 LLM 有好嘅 planning 能力

解決方法：用高質量 LLM（GPT-4, Claude 3, etc.）

2. Latency

遞歸調用會增加 latency：

• 單次 LLM call：2 秒
• RLM with 5 sub-calls：~10 秒（sequential）

緩解方法：

# Parallel recursion
rlm = RLMEnvironment(
    context=context,
    model="gpt-4",
    parallel_recursion=True,  # 平行執行！
    enable_caching=True  # Cache 重複 queries
)
# 可以將 10 秒減到 ~3 秒！

3. 成本考量

雖然比傳統方法慳，但仍然有 cost：

# 成本比較（GPT-4 為例）
# 傳統：50K tokens × $0.03 = $1.50
# RLM：10 calls × 2K tokens × $0.03 = $0.60
# 節省：60%

但如果遞歸太深，成本可能反而增加。需要 tune max_recursion_depth。

4. 唔係所有任務都啱用

RLM 最適合：

• ✅ 長文檔理解
• ✅ 需要跨部分推理
• ✅ 信息檢索 + 推理結合

唔太啱：

• ❌ 短文檔（overhead 唔值得）
• ❌ 需要 real-time response 嘅應用
• ❌ 純 generation 任務（如寫作）

總結

核心要點

1. RLM 將 context 從 "輸入" 變成 "環境"，模型主動探索而唔係被動接收
2. 突破 context window 限制：處理 10M+ tokens，遠超現有 LLM
3. 消除 context rot：性能保持穩定，唔會隨文檔長度退化
4. 成本效益高：只處理相關部分，節省 60-90% token usage
5. 實驗證明有效：多個 benchmark 都有顯著提升（+276%, 0.04%→58%）

何時用 RLM？

適合場景：

• 法律文件、醫療記錄分析
• Codebase 理解同 debugging
• 科研文獻綜述
• 任何需要處理超長文檔 + 複雜推理嘅任務

唔適合：

• 短文檔（<10 頁）
• 需要極低 latency（real-time chatbot）
• 純 creative writing

RLM vs RAG 簡單對比

• RAG：靜態檢索，適合 fact-lookup 同穩定知識庫
• RLM：動態探索，適合複雜推理同 cross-referencing

記住：佢哋唔係競爭對手，而係針對唔同場景嘅工具！

下一步

想試用 RLM？

1. Clone minimal version 快速開始
2. 由中等長度文檔開始（10-50 頁）
3. 觀察 trace 理解模型點 navigate
4. 根據你嘅 use case 調整 prompt 同參數

RLM 證明咗：Smarter architecture > Bigger models。呢個可能係 2026 AI 發展嘅主要方向！🔄✨

相關資源

• 📄 論文：Recursive Language Models - Zhang, A. L., Kraska, T., & Khattab, O. (2025)
• 💻 代碼（完整版）：github.com/alexzhang13/rlm
• 💻 代碼（Minimal）：github.com/alexzhang13/rlm-minimal
• 📝 MIT News：A new way to increase LLM capabilities
• 📝 Prime Intellect Blog：RLM: the paradigm of 2026

記住：好嘅技術唔係 show off，而係真正解決問題。RLM 就係一個好例子——simple idea, powerful results! 💪