上下文越長，AI越笨？Context Rot 現象工程拆解

一個讓工程師頭痛的現象

你有沒有發現：當你給 Claude 或 GPT-4 餵了一篇超長文件，要求它「總結第8節的關鍵數據」——它給你的答案往往不如短文件準確？不是模型變笨了，而是它的注意力被稀釋了。這就是所謂的 Context Rot（上下文腐爛）。

我們在 SFD 實驗室裡跑了大量長上下文任務，13個 Agent 協作時產生的上下文動輒幾萬 token，這個問題踩了很多次坑，今天來拆解清楚。

什麼是 Context Rot？

Context Rot 不是官方術語，但工程師群體裡已經在用了。它描述的是這個現象：

隨著上下文視窗中 token 數量增加，模型對中間位置資訊的提取能力顯著下降，即使這些資訊明確存在於 prompt 中。

研究者把這稱為 「Lost in the Middle」問題，史丹佛的論文在2023年就驗證了：把關鍵資訊放在 prompt 開頭或結尾，模型表現好得多；放在中間，準確率可以下降 20-30%。

三種衰減機制

1. 位置偏差（Positional Bias）

Transformer 的注意力機制本質上是對所有 token 做相似度計算，但位置編碼（RoPE/ALiBi/Sinusoidal）會給不同位置的 token 加上權重偏差。越靠近開頭和結尾的 token，在多層注意力傳遞中，梯度路徑更短，訊號衰減更少。

# 簡化示意：位置 i 的有效注意力權重
effective_attention(i) = raw_attention(i) * position_decay(i)
# 中間位置的 position_decay 往往小於邊緣位置

2. 注意力稀釋（Attention Dilution）

假設一個模型的注意力頭有固定的「總注意力預算」。當上下文從 4K 擴展到 128K token，每個 token 分到的平均注意力權重就從 1/4000 降到 1/128000——稀釋了32倍。那些在短上下文裡能被「高亮」的關鍵資訊，在長上下文裡就被淹沒了。

3. KV Cache 壓縮的副作用

為了讓長上下文推理在有限顯存裡跑通，工程師普遍用 KV Cache 壓縮技術（如 StreamingLLM、H2O）。這些方法會丟棄「不重要」的 KV 對——但「重要性」是根據過去的注意力分數判斷的，會系統性地偏向最近的 token，形成正反饋偏差。

實測數據：中間位置的代價

我們做了一個簡單測試：把同一份 API 文件嵌入不同位置，問模型「這個介面的 rate limit 是多少」：

| 資訊位置    | 正確率 | 平均延遲 |
|-----------|--------|----------|
| 前 10%    |  94%   |  1.2s   |
| 中間40-60%|  61%   |  1.8s   |
| 後 10%    |  89%   |  1.3s   |

中間位置的正確率直接跌了33個百分點。這在生產環境裡是不可接受的。

工程規避方案

方案一：關鍵資訊前置

把最重要的指令、約束、關鍵數據放在 system prompt 的最前面，而不是埋在大段背景資訊後面。SFD 實驗室的 Agent 提示詞現在都遵循「關鍵指令→背景資訊→範例」的順序，而不是反過來。

方案二：RAG 代替長上下文

與其把100頁文件全塞進去，不如用向量檢索只取相關段落。我們在處理 SFD 專案文件時，把 PRD/API 文件做成向量庫，每次只取 Top-3 相關塊，效果比直接餵全文好很多。

方案三：分段摘要（Map-Reduce）

長文件先分段摘要，再對摘要做二次處理。這是最樸素但最穩健的方法，在我們的內容生產流程裡用於處理研究報告。

方案四：顯式路標（Explicit Anchors）

在超長 prompt 裡，每隔一段插入顯式引用：「以下是你需要重點關注的資訊：」。這類「注意力錨」能拉高模型對該段的注意力分數。有研究表明這能提升 15-20% 的檢索準確率。

SFD編者注

我們 13 個 Agent 協作時，最頭痛的就是跨 session 的上下文累積。解法是：task-tracker 只保留「最近7天的活躍任務」，歷史任務歸檔到 archive/ 目錄，不再注入 prompt。Context Rot 不是不能解決，是需要主動設計資訊架構來對抗它。