Context Rot — LLM 越長越懂嗎

Context Rot — LLM context 越長，理解力就越強嗎？

context window 變大代表模型能「接收」更多 token，但不代表能等比例「理解」更多內容。
多個 long-context benchmark 顯示，模型在長 context 中會出現位置偏差、語意干擾、共指消歧困難與整體穩定性下降。
因此實務上不應追求塞滿 context，而應做 context engineering：檢索、壓縮、重排、去雜訊、把高價值資訊放在模型最容易利用的位置。

問題的核心

現在各家模型拼命擴 context window：
Gemini 2.5 Pro 1M、GPT-5.5 API 約 1.05M（Codex 為 400K）、DeepSeek V4 1M…

但 「放得進去」和「看得懂」是兩回事。

Transformer 的 self-attention 需要把每個 token 跟其他所有 token 做關係計算
100K tokens 的 self-attention 關係量級約為 10¹⁰（O(n²) 級別估算）
→ 越長，注意力越被稀釋，模型越難聚焦在真正重要的地方

三個主要現象

1. Lost in the Middle（位置偏差）

Stanford Liu et al., 2023 — arXiv:2307.03172

模型對 context 的注意力分布不均勻：

注意力強度
  ▲
  █                         █
  █                         █
  █    █              █     █
  █    █    ░  ░  ░   █     █
  └────┴────┴──┴──┴───┴─────→ 位置
 開頭  前段    中間段    後段  結尾

Liu et al. 發現：模型在相關資訊位於開頭或結尾時表現最好，位於中間時顯著下降。
具體數字因模型、任務、文件數、位置而異，不是固定比例。

這跟人類記憶的 primacy / recency effect 非常像。

2. Context Rot（整體穩定性下降）

Chroma Research, 2025 — 研究報告

測試了 18 個 frontier 模型，包括 GPT-4.1、Claude Opus 4、Gemini 2.5 Pro、Qwen3 等：

在被測模型與任務中，context 變長通常會造成穩定性下降。

2b. 長度本身就會造成退化（不只是雜訊）

Du et al., 2025 — arXiv:2510.05381

測試 5 個模型，把不相關 token 換成空白（逼模型只看相關段落）
→ 性能仍然下降 13.9%–85%

這說明問題不只是「被雜訊干擾」，input length 本身就有代價。

3. NoLiMa：去掉關鍵字匹配後才是真實能力

LMU Munich + Adobe Research, ICML 2025 — arXiv:2502.05167

傳統 Needle-in-a-Haystack 測試有個漏洞：
問題的關鍵字和答案的關鍵字高度重疊，模型靠字面匹配就能找到

NoLiMa 讓問題和答案沒有字面重疊，需要真的「推理」才能定位答案

結果：測試 13 個聲稱支援 ≥128K context 的模型

模型	短 context baseline	32K 時表現
GPT-4o	99.3%	69.7%
其他 11 個	高	低於 50% baseline

在 NoLiMa 這類去除字面匹配線索的任務中，許多模型在 32K 已出現明顯退化。
（注意：這是特定任務類型的結果，不代表所有任務在 32K 都如此）

廣告值 vs 有效理解

Maximum Effective Context Window（MECW）：模型實際上能有效理解的 context 長度上限

MECW 不是固定值，高度依任務類型、模型、prompt 結構、檢索難度而變。
有研究顯示部分任務下有效窗口可能比標稱窗口低非常多，最高可差到 >99%。

→ 廣告的 token 數只是上限，不能當作可靠的理解能力保證。

為什麼會這樣（三個機制）

① Attention Dilution（注意力稀釋）
Transformer attention 是 O(n²)，token 越多，每個 token 分到的「關注預算」越薄

② Lost in the Middle（位置偏差）
Pre-training 資料裡重要資訊通常在開頭/結尾（摘要、結論）
→ 模型學到「中間不重要」的偏見

③ Distractor Interference（語意干擾）
語意相近但不相關的內容會主動誤導模型
長文件裡這類干擾累積得更多

怎麼判斷「多長才夠」？

基本原則

不要直接用到廣告值的上限。 一般建議維持在 ≤80% 的安全緩衝。
但真正的門檻必須依任務實測，沒有通用固定值。

退化的形態

退化常是非線性的；某些任務會出現閾值後快速下降，但也有任務是緩慢波動。
不能靠「感覺還好」來判斷，要主動找邊界。

性能
 ▲
 ████████████████
 ████████████████░░░
 ████████████████░░░░░░░
 ████████████████░░░░░░░░░░░░
 └───────────────┴───────────→ context 長度
      相對穩定區       退化區（形狀依任務而異）

怎麼實際測

RULER（NVIDIA, 2024）是常見且代表性的長 context 評測工具之一 — GitHub

做法：把你的任務類型和 context 長度帶進去跑，找到性能跌破可接受線的位置

看既有 benchmark 時優先關注：

NoLiMa score（去掉字面匹配後的推理能力）
RULER score at your target length（指定長度的分，不是整體均分）
MRCR v2：長上下文中的多輪共指消歧與精準檢索能力
→ 在 OpenAI MRCR v2 8-needle 512K–1M 區間，GPT-5.5 為 74.0%、GPT-5.4 為 36.6%

不要只看「支援 N tokens」，要看「在 N tokens 下具體任務的分數」。

依任務類型的粗估

任務	風險程度	建議
單文件摘要	相對低（但超長或需精確引用時仍有風險）	優先，但過長建議分段 map-reduce
多文件比較	中高	小心中間段文件被忽略
長對話記憶	高	超過 32K 早期對話開始消失
程式碼理解	中高	中段函式易被跳過
RAG 合併結果	依 chunk 數、相似度、reranker 品質	應用 target task eval 找 top-k 上限

實務上的警告訊號

不需要跑 benchmark，觀察這些：

模型開始「忘記」前面說過的條件
答案越來越模糊、不引用具體細節
重複強調某件事但模型仍沒反應
同樣問題短 context 答得好，長 context 答不好

→ 出現這些就是已經超過有效範圍的信號

現在的緩解策略

目前沒有根治方案，核心思路是 context engineering：只保留高訊號資訊、摘要舊內容、清除過期結果、需要時再回填。

詳見：Context Rot (上下文腐爛)（Chroma 論文深度筆記，含 RAG / memory 架構的關聯討論）

方法	說明
Context Engineering	只放真正需要的資訊，刪掉雜訊 → 最直接有效
RAG	不把全文塞進 context，先檢索再讀
Summarization / MapReduce	長文先分段摘要，再合併
重要資訊放開頭/結尾	善用 primacy/recency 效應
反覆強調關鍵約束	在 prompt 中多次重申最重要的限制