概念位置

Long context 的 effective context 跟 claimed context 落差來自三個現象：

 1Recall accuracy vs 答案位置（典型 10K context）：
 2
 3100% |█                                       █
 4     |██                                     ██
 5 80% |███                                   ███
 6     |███                                   ███
 7 60% |███          ____                     ███
 8     |███      ___/    \___                 ███
 9 40% |███    _/            \_               ███
10     |█████─/                \─────         ███
11     |
12       0      2K     4K     6K     8K    10K
13       開頭                              結尾

成因：

1. Attention weight 分佈不均勻：訓練資料中、句首 / 段首通常含關鍵資訊、模型學會偏重句首；長 context 的中段在訓練資料中相對稀疏、attention 沒學好
2. Positional encoding 設計：RoPE / ALiBi 等對長距離 attention 的衰減模式、中段 token 跟 query 距離通常較大、attention 弱
3. 訓練 context 長度的影響：模型若訓練在 8K context、推論時用 128K（用 RoPE scaling 延伸）、中段表現比訓練範圍內差更多

設計責任

讀 long-context paper / benchmark 看到「lost-in-the-middle」「U-shape recall」就是這現象。寫 code 場景的判讀：

1. 把關鍵資訊放開頭或結尾：system prompt 在開頭、最新指示在結尾（剛好是模型 attention 最強的兩處）
2. 長 context 不是「塞越多越好」：超過 effective context（典型 8-16K）後、邊際效用急降
3. RAG 比 long context 仍有價值：把相關片段 retrieve 出來放 prompt 開頭、比把整份文件塞進 100K context 效果更穩定
4. 驗證自己模型的 effective context：用 needle-in-haystack 或自製測試、看模型在 8K / 16K / 32K 表現掉到哪
5. Reasoning model 的 thinking trace 不會遇到這事故嗎？ — 仍會遇到、但 reasoning 過程會主動重新引用前文、部分緩解；不過 thinking trace 本身會擠壓 context budget、可能反而觸發 degradation

概念位置

NIH 測試的典型流程：

 11. 準備 haystack：一份長文（如 Paul Graham essays、技術文件）
 22. 在指定位置（如 50% 處）插入 needle：
 3   「The best thing to do in San Francisco is eat a sandwich at Dolores Park.」
 43. Prompt 模型：「What is the best thing to do in San Francisco?」
 54. 看模型能否抓出 needle 內容
 6
 7Variables：
 8- Context 總長度（1K、4K、16K、64K、128K、1M）
 9- Needle 插入位置（0%、10%、25%、50%、75%、90%、100%）
10
11每個 (length, position) 組合測 N 次、得到 accuracy heatmap

跟 lost-in-the-middle 的對比：

 1典型 NIH heatmap（GPT-4 128K 之類）：
 2
 3100% |████ ████████████████████████████ ████
 4 80% |████ ████████████████████████████ ████
 5 60% |
 6 40% |
 7 20% |
 8   0 +----+----+----+----+----+----+----+
 9     0%   25%   50%   75%   100%（needle 位置）
10     ↑                                  ↑
11     開頭強                             結尾強
12
13NIH heatmap 通常全綠（強模型）、但實用任務（reasoning over long context）就會出現中段塌陷

設計責任

讀 long context 模型 release notes 看到「needle in a haystack: 100%」「pass NIH up to 128K」等聲稱、要區分：

1. NIH 100% 不代表「能用 128K context」：NIH 只測單一事實 retrieve、實際 reasoning over long context 仍可能崩
2. 真實任務 benchmark：LongBench、RULER 等是更貼近實用的 long context evaluation、會暴露 lost-in-the-middle 等問題
3. 本地跑 long context 模型：先用 NIH 驗證 baseline、再用 RULER / 自己工作流 case 測 effective context
4. 判讀「我的模型實際能用幾 K」：NIH pass 的長度是上限、實用 effective context 通常是 NIH pass 長度的 1/2 到 1/4

本章目標

讀完本章後、你應該能：

1. 區分模型「聲稱 context」、「NIH context」、「實用 effective context」三個層級。
2. 看到 lost-in-the-middle 症狀時、知道怎麼緩解。
3. 對自己工作流的任務、判斷該用 long context 還是 RAG。
4. 設計 prompt 時、把關鍵資訊放對位置。
5. 評估「升級到更長 context 模型」的實際邊際收益。

三層 context 概念：claimed / NIH / effective

讀 model card 看到「128K context」「1M context」時、需要區分：

落差來自：

1. RoPE scaling 是延伸、不是「免費擴展」：訓練多在 8K-32K range、用 RoPE scaling 推到 128K+、實用上會 degrade
2. 訓練資料偏短：trillion-token pretrain corpus 中、極長文件相對稀少、模型對 long context 中段不熟悉
3. Attention 衰減：attention 機制對長距離 token 的注意能力隨距離下降、雖未真正 attention to 0、但「有效訊號」減弱

實務啟示：聲稱 1M context 不代表「能塞 1M 進 prompt 解任務」、實用 effective context 多半是聲稱的 1/4-1/8。

Lost-in-the-middle：long context 的主要失敗模式

Lost-in-the-middle（Liu et al., 2023）的核心發現：模型對 long context 中段內容的 recall 顯著低於開頭與結尾。實測：

1Recall accuracy vs 答案位置（10K context）：
2  位置 0%（開頭）  ：85%+
3  位置 25%        ：70%
4  位置 50%（中段）：40-55%
5  位置 75%        ：65%
6  位置 100%（結尾）：80%+

成因細節見 lost-in-the-middle 卡片。本章聚焦緩解：

1. 關鍵資訊放開頭 / 結尾：system prompt、最新指示放在 prompt 開頭 / 最末段、剛好是 attention 最強的兩處
2. 重要內容重複出現：在 prompt 開頭跟結尾各放一次摘要、提高 recall
3. 避免在中段藏 deeply nested constraint：「請遵守附件中第 47 條規則」這類引用、長 context 中段容易被忽略
4. 拆 prompt 成多輪：把 long context 拆成「load context」+「query」兩輪、第二輪 query 在前一輪結尾、recall 較強

Long context vs RAG：什麼時候該選哪個

兩者解的問題重疊但不完全替代：

判讀流程：

1知識總量 < 你模型的 effective context（見後文表格、典型 7B-14B 約 8-16K、30B+ 約 16-32K）？
2  ├─ 是 → 直接 long context
3  └─ 否 → 知識結構化、retrieval key 明確？
4            ├─ 是 → RAG
5            └─ 否 → 嘗試 hybrid：RAG 把相關段 retrieve 出來 + 放進 long context

注意「effective context」是你模型實際能 reliable 處理的範圍、不是 model card 上聲稱的 128K — 拿 7B 模型塞 16K 知識仍可能踩 lost-in-the-middle。

混用情境：

1. Codebase 理解：codebase 整體用 RAG retrieve、單檔 deep dive 用 long context（讀整個檔案）
2. 文件問答：文件用 RAG retrieve 相關段、塞進 32K context、模型可看到「retrieve 結果 + 自己的對話歷史」
3. 長對話：對話歷史進 long context、新指令在最末段（避免 lost-in-the-middle）

Context 設計策略

具體 prompt 結構建議（適用 long context 場景）：

 1[1. System prompt 開頭]         ← attention 強、放核心指令
 2  你的角色 / 主要任務 / 不變的約束
 3
 4[2. Few-shot examples（若需）]   ← attention 仍強、放示範
 5
 6[3. 大段 context]                ← 中段、可能 lost-in-the-middle
 7  - 把最重要的內容也放這段開頭跟結尾、別只放中間
 8  - 若有多段 context、各段都帶明確 heading
 9
10[4. 當前查詢]                    ← attention 強、放使用者問題
11
12[5. 重述關鍵約束（若需）]         ← 末段、attention 強、再次強調 critical rule

典型反例（容易踩 lost-in-the-middle）：

1[1. 重要約束「使用者付費等級 = premium、回應應該詳細」]
2[2. 100K 文件全文]
3[3. 「請回答上述文件相關問題」]

→ 改成：

1[1. 重要約束（同上）]
2[2. 文件摘要 + 「以下是完整文件、若需細節請參考」]
3[3. 100K 文件全文]
4[4. 重述「使用者付費等級 = premium、提供詳細答案」]
5[5. 「使用者問題：X」]

第二版有兩處可靠出現核心指令、長 context 中段含有完整文件、但模型 recall instruction 時兩處任選一處都行、品質提升。

Reasoning model + long context 的特殊互動

Reasoning models 的 reasoning trace 跟 long context 有兩個衝突點：

1. Reasoning trace 擠 context budget：1000-10000 token reasoning trace 直接吃進 context、本來 effective 32K 的模型可能只剩 22K 給輸入
2. Long thinking traces 自己也踩 lost-in-the-middle：reasoning trace 變長時、reasoning 過程中段也會「忘記前面想到的」

緩解：

1. Reasoning model 配長 context 模型：DeepSeek-R1 distill 64K context 是合理 baseline
2. Reasoning 階段引導模型「定期重述目標」：prompt 加「請每隔幾步重新確認任務目標」
3. 複雜任務拆步：別把整個任務丟給 reasoning model 一輪解、拆成多個 sub-task

量測自己模型的 effective context

不要相信 model card 上的數字、自己跑：

 1# 1. 跑 needle-in-haystack（lower bound、寬鬆指標）
 2# 用 ggerganov/llama.cpp 或 RULER 工具
 3# 看模型在 8K / 16K / 32K / 64K / 128K 各自的 NIH accuracy
 4
 5# 2. 自己工作流的 real-task 評估
 6# 拿實際的長 prompt（如完整 codebase + 任務）
 7# 對不同 context 長度比較輸出品質、找到 degradation 點
 8
 9# 3. lost-in-the-middle 測試
10# 同個 prompt 把關鍵指令分別放在開頭、中段、結尾
11# 對比模型回答準確度

實務上、寫 code 場景的 effective context 通常落在：

升級到更長 context 模型的判讀

讀 model card 看到「context 從 128K 提升到 1M」、判斷對自己的價值：

1. 看 RULER benchmark、不只看 NIH：RULER 有 multi-needle、aggregation、reasoning 等任務、更貼近實用
2. 看 effective context（如 LongBench 數字）：聲稱 1M 但 effective 64K vs 聲稱 200K 但 effective 100K — 後者更有用
3. 看自己任務真實長度：如果你的任務 prompt 多在 8K 內、聲稱 128K → 1M 對你無收益
4. 看推論成本：long context 的 KV cache 跟 prefill 時間都隨長度增加、effective 64K 模型實用上比聲稱 1M 模型更快

何時過時 / 何時不過時

不會過時的部分：

• Claimed / NIH / Effective context 三層概念
• Lost-in-the-middle 的存在跟基本緩解策略
• Long context vs RAG 的判讀框架
• 「關鍵資訊放開頭結尾」的 prompt 設計原則

會變的部分：

• 各模型的聲稱 / effective context 數字（每代會推進）
• Long context 訓練技術（RoPE scaling 變體、long-context fine-tuning 方法會演化）
• Lost-in-the-middle 的減緩進展（可能透過新訓練方法部分解決）
• Benchmark 工具（NIH → RULER → 未來新 benchmark）

下一章

下一章：4.12 Embedding model 內部、看 RAG retrieval 階段背後的 embedding 是怎麼運作。