昨天用 RAGAS 的 context recall 與 faithfulness 把 RAG 管線的病灶量了出來。今天用同一套量測問一個更根本的問題：2026 年已有十幾款前沿模型宣稱支援百萬 token 以上的視窗，為什麼還要維護 chunking、embedding、rerank 這一整條管線？把知識庫整包塞進 prompt 不就好了。答案不是「RAG 比較好」也不是「長上下文取代了 RAG」，而是三筆得各自算清楚的帳：有效上下文長度（effective context length）與宣稱視窗的落差、context rot（上下文腐化）的衰減曲線、每次查詢的成本與延遲。
📖 學
宣稱視窗不等於有效長度
NoLiMa 這個 ICML 2025 的 benchmark 做了一件簡單但致命的事：把 needle-in-a-haystack（NIAH，大海撈針）裡的「針」改寫成與問題沒有字面重疊的版本，逼模型靠語意關聯而非關鍵詞比對去定位。例如問「哪個角色去過赫爾辛基」，針是「Yuki 就住在 Kiasma 美術館旁邊」。它同時給出一個好用的操作化定義：有效長度 = 還能維持短文本基準分數 85% 的最長上下文。
| 模型 | 宣稱視窗 | 有效長度 | 基準分數 | 32K 分數 |
|---|---|---|---|---|
| GPT-4.1 | 1M | 16K | 97.0 | 79.8 |
| GPT-4o | 128K | 8K | 99.3 | 69.7 |
| Claude 3.5 Sonnet | 200K | 4K | 87.6 | 29.8 |
| Llama 4 Scout | 10M | 1K | 81.7 | 21.6 |
宣稱 1M、有效 16K 已是全表最好的一列；宣稱 10M、有效 1K，落差四個數量級。在 32K 這個大多數人覺得「還很短」的長度上，12 款受測模型有 10 款掉到基準的一半以下。NVIDIA 的 RULER 更早得到同方向結論：17 款模型在原版 NIAH 幾乎滿分，加上 multi-hop 與 aggregation 任務後隨長度全面衰退。
誠實標註：表上是 2025 年上半的世代，2026 年這批確實好得多（NoLiMa-Hard 顯示 GPT-o3 在 32K 還有 58.5 分），但落差的結構沒消失，只是往右平移。
context rot：不是塞滿才壞，是一路都在壞
Chroma 2025 年 7 月的 Context Rot 報告測了 18 款模型、194,480 次呼叫，方法論關鍵是固定任務難度、只變輸入長度——這樣才能把「長度造成的衰退」跟「題目本身變難」分開，而混淆這兩者正是過往 benchmark 的通病。
三個發現。第一，針與問題的語意相似度越低，衰退越快；真實查詢幾乎都是低相似度的（使用者不會把答案關鍵詞抄在問題裡），所以 NIAH 的漂亮成績不能外推。第二，一個 distractor（干擾項）就掉分，四個複合惡化，且不同干擾項殺傷力不一致；更值得記的是家族差異——Claude 系列不確定時傾向棄答、幻覺率最低，GPT 系列傾向自信講錯。第三，把 haystack 句子打亂反而表現更好，18 款模型一致，說明上下文的結構本身在影響注意力分配。
最有說服力的是他們用 LongMemEval 跑的兩個條件：full input 是約 113K token 的完整對話歷史，focused input 只留真正需要的部分、平均約 300 token。同題目同模型，所有模型在 focused 上都顯著贏。翻成工程語言：377 倍的 token 換來更差的答案。因為 full input 逼模型一次做兩件事——先找出相關片段，再推理；focused 只要它推理。檢索交給注意力機制做，比交給專門的檢索系統做又貴又爛。這就是 RAG 沒被淘汰的原因：它不是長上下文的替代品，是幫模型省掉一個它不擅長的子任務。
Liu 等人 2023 年的 lost-in-the-middle U 型曲線也仍成立：資訊放頭尾表現最好、放中間顯著變差。推論很直接：rerank 之後別把最相關的片段丟在中間，放最後、緊貼問題。這也解釋了為什麼 top-k 從 5 調到 50 常常反而變差——你不只加了干擾項，還把正解推進了中間的死區。
成本帳
假設一個內部知識庫問答系統，一天一萬次查詢，以 3 美元／百萬 input token 計（2026 年 8 月 Sonnet 級的量級）。另外這一代旗艦普遍對長 prompt 加價：Gemini 3.1 Pro 超過 20 萬 token 單價翻倍，GPT-5.5 超過 27.2 萬 token 有 2 倍 input 乘數——階梯定價本身就在說明長上下文的成本結構。
架構 A 純長上下文，每次塞 80 萬 token：800,000 ÷ 1,000,000 × 2.40／次**，一天一萬次 $24,000，一年約 876 萬美元。
架構 B 檢索後餵 8,000 token：LLM input 8,000 ÷ 1,000,000 × 0.024；query embedding 約 20 token，小於 0.00001 量級，兩者皆可忽略；rerank 以 2 美元／1,000 次搜尋計約 0.026／次**，一天 $260，一年約 9.5 萬美元。
差 92 倍，年度差額約 867 萬美元——而這已經是對長上下文最友善的假設：沒套階梯加價、沒算 output、也沒算維護那 80 萬 token 文件集本身的工。
延遲那筆更硬。公開的推論基礎設施數據顯示 128K 的 prefill 約 3.8 秒，1M 約 77 秒——TTFT（time to first token）從幾秒跳到接近一分鐘，因為注意力對長度是二次成長，長度加倍計算量變四倍；8K 則在毫秒到百毫秒量級。結論：接近一分鐘的 TTFT 讓長上下文在對話式應用上不可用，與它準不準無關。
prompt caching 改了什麼、改不了什麼
2026 年三家供應商的 cached input 折扣都收斂到九折上下：Anthropic 的 cache hit 收基礎 input 價 0.1 倍（5 分鐘 TTL 的 write 收 1.25 倍、1 小時收 2 倍），OpenAI 新旗艦 cached read 也到 10%，Google 折 80 到 90% 但另收儲存費。重算架構 A：cache write 800,000 ÷ 1,000,000 × 3.00（一天約寫一次），cache hit 800,000 ÷ 1,000,000 × 0.24／次**，一天一萬次約 $2,403。
| A 無快取 | A + caching | B 檢索 | |
|---|---|---|---|
| 一天一萬次 | $24,000 | $2,403 | $260 |
| 年度 | 約 876 萬 | 約 88 萬 | 約 9.5 萬 |
| context rot 風險 | 高 | 高（沒改善） | 低 |
省 10 倍很可觀，但仍比檢索貴 9.2 倍；而且 cache hit 省掉的是重算 KV cache，不是把上下文變短——注意力仍要在 80 萬 token 上運作，context rot 的準確率損失一分錢沒省。還有一個常被忽略的前提：caching 只在前綴逐字相同時命中——每次餵不同檢索結果它就幫不了你，它剛好只在「所有查詢共用同一大塊文件」時有用，而那正是浪費最嚴重的情境。
混合式：retrieve-then-fill
必須承認長上下文在準確率上真的可能贏。2026 年 6 月一篇比較文件接地架構的論文（arXiv 2606.20898，作者稱之為 epistemic accuracy 的 token tax）評了 972 個答案，長上下文正確率 73.1%，語意 RAG 65.4%，代價是每次查詢 26 倍的 token。所以真正的問題不是誰比較好，而是「7.7 個百分點值不值 26 倍」。法律意見、臨床決策這類單次錯誤代價極高又低頻的場景，值；一天一萬次的內部問答不值——把那 26 倍預算拿去改善檢索，八成能把 65.4% 推更高。這也是昨天那套 evals 的用途：沒有 context recall，你分不清 RAG 是輸在撈不到還是輸在生成沒用好。
實務答案幾乎總是混合式，原則是：用檢索把候選壓到「有效上下文長度」的規模，不是壓到「宣稱視窗」的規模。檢索刻意撈寬（top-50 到 top-200，沒撈到的東西 rerank 救不回來），rerank 刻意收窄，最後填進 prompt 控制在 8K 到 32K——這是最好那幾款模型還沒明顯衰退、prefill 也還在秒級以下的範圍。長上下文在這裡的價值不是讓你不做檢索，而是讓 rerank 不用那麼激進：以前只能塞 3 段，現在可以塞 20 段，錯殺正解的機率大降。它是加法不是減法。
🧠 記
- 宣稱視窗與有效長度差一到兩個數量級。NoLiMa 定義有效長度為「還能維持短文本基準 85% 的最長上下文」：GPT-4.1 宣稱 1M／有效 16K，Llama 4 Scout 宣稱 10M／有效 1K。
- context rot 不是塞滿才壞。固定難度只變長度，18 款模型一致衰退；相似度越低衰退越快，一個干擾項就掉分。
- 最強證據是 LongMemEval：113K 的完整歷史打不贏 300 token 的精選片段——377 倍 token 換更差的答案，因為長上下文逼模型同時做檢索與推理。lost-in-the-middle 也仍在，rerank 後把最重要的證據放結尾緊貼問題。
- 成本：80 萬 vs 8 千 token，以 2.40 對 24,000 對 $260，一年差約 867 萬美元。TTFT 則是數十秒對百毫秒。
- prompt caching 讓長上下文降到約 $2,403／天（省 10 倍），但仍貴 9.2 倍，對 context rot 零改善，且只在前綴逐字相同時命中。
- 長上下文確實可能更準（73.1% 對 65.4%），代價 26 倍 token；低頻高風險值得，高頻不值得。正解是 retrieve-then-fill：撈寬、收窄、填進 8K–32K，讓長視窗去換 rerank 的容錯而不是取代檢索。
✍️ 實踐
20 到 25 分鐘，跑一個位置偏誤與長度衰退的小實驗，拿到你自己資料上的有效長度估計，而不是引用別人的表。
- 準備針與問題（5 分鐘）。 從文件集挑一個具體事實寫成一句 needle（例如「2025 年 Q3 的退貨率門檻調整為 4.2%」），再寫一個刻意不含針裡關鍵詞的問題（「當時我們把品質警戒線設在哪裡」）。低字面重疊是重點，否則你測到的是 NIAH。另備一個約 300 token 的 focused 版本，只有針加必要背景。
- 組 haystack（5 分鐘）。 串出 8K 與 64K 兩個長度（用 tiktoken 或供應商的 count-tokens API 量），並確認裡面沒有這問題的其他答案，否則實驗無效。
- 跑 3 × 5 網格（10 分鐘）。 三個條件（focused 300 token、8K、64K）× 針的五個位置（0%、25%、50%、75%、100%；focused 只跑一次），temperature 設 0，每格記答對／答錯／棄答與 TTFT。用最便宜的可用模型就好，你要的是曲線形狀不是絕對分數。
- 算成本（5 分鐘）。 用實際單價算「64K 每次查詢 input 成本 × 日查詢量」，再算 8K 的同一個數字，相減得年度差額；若前綴共用，再乘 0.1 得 caching 後版本。
自我檢查兩題：
- 64K 條件下，針放 50% 的表現是否明顯低於放 0% 或 100%？ 是的話你有可利用的位置偏誤，今天就改 prompt 組裝順序，把 rerank 第一名搬到最後；沒有明顯差異就記下結論，不要去修一個你身上不存在的問題。
- focused 的 300 token 版本，準確率是否不輸 64K？ 不輸（大概率如此）就等於你親手複現了 Chroma 的核心結論。該問的下一題不是「要不要拿掉 RAG」，而是「我的檢索能不能穩定產出那 300 token」——那是 context recall 的活。
🔗 延伸學習
- Context Rot: How Increasing Input Tokens Impacts LLM Performance — Chroma 技術報告，18 款模型、固定難度只變長度，含 113K 對 300 token 對照，程式碼。
- NoLiMa: Long-Context Evaluation Beyond Literal Matching — ICML 2025 官方 repo，README 直接附上宣稱長度對有效長度的完整結果表，論文。
- Lost in the Middle: How Language Models Use Long Contexts — 位置偏誤 U 型曲線的原始出處。
- Prompt caching（Anthropic 官方文件） — cache write／hit 的定價倍數、TTL 與命中條件。
💬 問 AI
我要判斷我的系統該用 RAG、純長上下文，還是 retrieve-then-fill 混合式。
請把這個決策量化，不要給我通則。
我的系統現況：
- 知識庫總大小（token 數）：____
- 每日查詢量：____
- 使用的模型與 input／output 單價：____
- 目前每次查詢餵進 prompt 的 token 數：____
- 查詢是否共用相同前綴（決定 caching 能否命中）：____
- 可容忍的 TTFT 上限（秒）：____
- 單次答錯的代價（低／中／高）：____
請依序做四件事：
1. 用我的實際單價，把「純長上下文」「長上下文 + caching」「檢索 + 短上下文」三種架構的每次查詢、
日、年成本列成一張表，算式寫出來讓我複核，並標明哪些數字是估算。
2. 依我的 TTFT 上限，判定哪些架構在延遲上已不可行，並說明 prefill 隨長度成長的量級依據。
3. 給我具體的 retrieve-then-fill 設定：top-k 撈多寬、rerank 後留多少 token、證據在 prompt 裡的
排列順序，並說明每個數字為什麼是這個值（要對應有效上下文長度與位置偏誤）。
4. 設計一個我今天跑得完的最小實驗來驗證第 3 點；寫明要記錄哪些欄位，以及什麼結果會推翻你的建議。