# 策展 · X (Twitter) 🔥🔥🔥 > 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt) > 作者：Carnage (@0xCarnagee) · 平台：X (Twitter) · 日期：2026-07-13 > 原始來源：https://x.com/0xCarnagee/status/2076269316912095422 ## 中文摘要 # Context rot：這項研究證明了你那百萬 token 的 context window 正在欺騙你大多數開發者將 context window 視為一個水桶。貼上更多內容、獲得更多資訊，填滿那百萬個 token，模型就能對所有內容進行推理。事實並非如此。而且這項數據在最新的模型上也同樣適用，而不僅僅是去年的舊模型。這一切始於 Chroma。2025 年年中，他們針對此議題進行了規模最大的對照研究——涵蓋 18 個前沿模型，進行了 194,000 次測試呼叫。結果顯示，隨著輸入內容變長，每一個模型的效能都會下降。他們的研究分析非常值得完整閱讀。當時測試的是 Claude 4 和 GPT-4.1。一年後，在 Opus 4.8、GPT-5.5 和 Gemini 3 上，這種效應雖然減弱了，但從未消失。其機制是結構性的。本文將拆解這項研究的發現、目前的數據、為什麼更大的 window 無法解決問題，以及你本週應該做出哪些改變。這是真實的數據，沒有理論空談。 --- ## 第 1 部分 - 在 Demo 中表現驚人，在生產環境卻崩潰的現象想像一個研究型 Agent。它運行在一個擁有 1M-token window 的前沿模型上，被餵入了所有資料——逐字稿、筆記、整份風格指南。每次呼叫大約會消耗 320,000 個 token。內部的 Demo 完美無缺。每個人都印象深刻，於是你將其上線。在生產環境運行兩週後，模式出現了。長篇逐字稿中間的關鍵事實開始遺失。 Agent 引用了錯誤季度的財報。引用了錯誤的來源。歸因錯誤。而且每次都表現得信心滿滿。你檢查了 Prompt 是否有 Bug。結果並沒有。window 足夠大，模型很強大，但輸出結果依然錯誤。這不是一個可以透過修補程式解決的 Bug。這就是 context rot（上下文腐敗），而 Chroma 是第一個精確量化這種情況有多嚴重的團隊。 ![此圖展示了 AI 模型在開發演示階段表現完美，但在實際生產環境中卻出現事實錯誤的常見困境。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/4af37904421f35e6.png)

展開畫面重點

圖中標題為「PART 1」與「Crushes the demo, dies in production」，副標題為「320,000 TOKENS PER CALL - AND THE FACTS GO MISSING」。畫面呈現一個三個階段的流程圖： 1. 第一階段（標籤為「demo」）：內容為「Internal eval」，描述為「Full transcripts, notes, style guide. Flawless.」。 2. 第二階段（標籤為「ship」）：內容為「Two weeks live」，描述為「Facts from the middle start disappearing」。 3. 第三階段（標籤為「bug?」）：內容為「Wrong quarter. Wrong source.」，描述為「Confident every time. No prompt bug to find.」。底部文字為：「the window was big enough. the model was strong. the output was still wrong.」

--- ## 第 2 部分 - 每個人都在吹捧的基準測試其實是個騙局這是 AI 行銷不想讓你面對的真相。每一個百萬 token 的發布會都揮舞著同一個基準測試：大海撈針（needle in a haystack）。在巨大的文字區塊中隱藏一個句子，要求模型找到它。模型的得分接近完美。這就是為什麼實驗室喜歡展示它。但看看它是如何構建的。那根「針」是「在舊金山最棒的事就是去多洛雷斯公園（Dolores Park）」，而問題是「在舊金山最棒的事是什麼」。問題和答案共享相同的詞彙。這只是一個詞彙匹配，僅此而已。模型只是定位了看起來像問題的 token。這證明了一件事：它可以在輸入中找到一個事實。但這完全無法證明它具備跨越該輸入進行推理的能力。而推理正是真實 Agent 的全部工作。因此，Chroma 重建了測試，要求模型進行真正的理解，而不是關鍵字匹配。這就是那 18 個模型全部敗下陣來的地方。 ![本圖說明「大海撈針」（Needle In A Haystack）測試僅為詞彙匹配，無法證明模型具備真正的理解能力。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/dab64606030e8fef.png)

展開畫面重點

標題：PART 2 The benchmark everyone brags about is a trick NEEDLE IN A HAYSTACK - A LEXICAL MATCH, NOTHING MORE 方框內容： ...essays about startups and painting and how to do great work... the best thing to do in San Francisco is go to Dolores Park... ...more unrelated text filling the context window... QUESTION what's the best thing to do in San Francisco? MODEL just matches the words. never had to reason. 底部文字： it proves the model can find a fact. it proves nothing about understanding it. 畫面重點：此圖透過一個簡單的範例，指出當前流行的「大海撈針」測試（Needle In A Haystack）本質上只是在進行詞彙匹配（Lexical Match）。圖中展示模型僅是從長文本中提取出與問題關鍵字對應的片段，而非真正理解內容，因此無法作為模型具備推理能力的證明。

--- ## 第 3 部分 - 當模型必須思考而非匹配時會發生什麼這就是讓它們崩潰的版本。答案不再是逐字匹配，而是需要一個小小的推論。問題：「哪個角色去過赫爾辛基？」文字中的「針」：「Yuki 住在 Kiasma 美術館隔壁。」要回答這個問題，模型必須知道 Kiasma 位於赫爾辛基，然後將兩者連結起來。人類可以不假思索地做到，但模型卻無法掌握。在短長度下，它們表現得很好。但隨著 context 增加，這 18 個模型的準確度都急劇下降。這裡有一個關鍵點，徹底粉碎了「這只是個難題」的藉口：Chroma 保持問題不變，僅改變周圍文字的長度。同樣的問題。同樣的答案。周圍更多的 token。更差的表現。這就是 context rot 的定義：隨著 window 被填滿，即使任務從未改變，模型也會變得更笨。 ![這張圖表說明了 AI 模型在處理長文本時，隨著輸入內容長度增加而導致準確度下降的「上下文腐敗（context rot）」現象。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/f6440fecb46d5620.png)

展開畫面重點

圖表標題為「PART 3 Make it think, not match」，副標題為「SAME QUESTION, MORE TOKENS AROUND IT, WORSE ANSWER」。圖表分為左右兩個區塊： 1. 左側綠色區塊「SHORT CONTEXT」： - 問題：「Which character has been to Helsinki?」 - 提示（needle）：Yuki lives next to the Kiasma museum. - 結果：✓ model connects Kiasma → Helsinki 2. 右側紅色區塊「SAME TASK, LONGER INPUT」： - 說明：identical question. identical answer. just more text wrapped around it. - 結果：X accuracy drops across all 18 models 底部註解：the task never changed. only the length did. that's context rot in one line.

--- ## 第 4 部分 - 應該終結爭論的數據這裡不再是憑感覺，而是規格問題。有三個發現經受住了生產環境的考驗。第一，每個模型的效能都隨長度下降。沒有模型能在其宣稱的 window 範圍內保持穩定。 1M-token 的模型在超過約 200,000 個 token 後，表現就不再像 1M-token 模型了。200K 的模型在 80,000 到 100,000 個 token 時就開始崩潰。第二，Prompt 的中間部分是「死亡地帶」。將關鍵事實放在 20 份文件 context 的開頭或結尾，準確度依然很高。將其放在第 5 到第 15 個位置——也就是中間——大多數模型的準確度會下降 30 個百分點以上。這就是舊有的「迷失在中間（lost in the middle）」效應，但比 2023 年史丹佛大學的數據顯示的還要嚴重。它並沒有隨著規模擴大而改善。第三，存在一個純粹由長度導致的底線。即使剔除所有干擾項，讓模型沒有任何被混淆的可能，準確度仍會因長度本身而下降 7.9%。請認真看待這一點。即使檢索完美，更長的 Prompt 也會讓你付出準確度的代價。更好的 RAG 救不了你。更乾淨的 context 也救不了你。只有更短的 Prompt 才能。 ![評測顯示，即使在完美檢索的情況下，較長的提示詞仍會損害準確度，1M token 模型的表現從 1K 長度時的 98% 準確度一路下滑至 1M 長度時的 41%，且在超過 200K tokens 後表現便開始嚴重退化。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/6ada5448ace7ca85.png)

展開數據表（1）三大發現

項目	數值
視窗限制	200K (1M-token模型在超過約200,000 tokens後表現退化)
中間地帶衰退	-30 pts (在20個文件上下文的第5-15個位置,準確度下降30點以上)
長度本身代價	-7.9% (移除所有干擾項後,僅長度本身就使準確度下降7.9%)

展開數據表（2）不同長度下的準確度

項目	數值
1K	98%
8K	95%
32K	89%
128K	78%
256K	64%
1M	41%

--- ## 第 5 部分 - 「但那是 2025 年的模型」——看看 2026 年的狀況顯而易見的反駁是：那項研究是在 Claude 4 和 GPT-4.1 上進行的。我們已經過了一年。前沿模型肯定已經修復了這個問題。它並沒有修復。而且實驗室用來證明這一點的基準測試本身就露了餡。以 MRCR v2 為例，這是一個 8 針測試，模型必須在長 Prompt 中找到並重現八個隱藏的事實。在 256K token 時，頂級模型看起來很強。 Opus 4.6 得分約 92%，GPT-5.2 達到 64%，Gemini 3 Pro 僅 45%。這已經有了差距，而且這還只是簡單的部分。現在將 window 填滿到 1M token。Opus 4.6 保持在 76%。Gemini 3 Pro 儘管宣稱擁有 1000 萬 token 的 window，卻崩潰至 24.5%。同樣的模型。同樣的任務。你只是使用了他們賣給你的 context，準確度就跌落懸崖了。而且每次發布並非線性提升。Opus 4.7 在長 context 上實際上出現了倒退，在 1M token 時降至 32%，而 4.6 版本卻能保持 76%。 Anthropic 在他們自己的系統卡（system card）中也說了：保留 4.6 作為多針檢索的備用方案。最新的模型在每個人都認為會持續進步的領域上反而更差了。在所有被測試過的模型中，2026 年的有效 context 仍然落在宣稱值的 60% 到 70%。現在有 13 個模型提供 1M 以上的 window。沒有一個能可靠地使用其全部 window。上限提高了，但腐敗並沒有消失——它已經深植於 attention 機制處理長輸入的方式中，每一次發布仍然要付出代價。 ![在 MRCR V2 八針檢索測試中，Opus 4.6 在 256K 與 1M 標記窗口下均取得領先（分別為 92% 與 76%），而 GPT-5.2、Gemini 3 及 Opus 4.7 等模型表現則顯著下滑，印證了窗口填滿時性能會下降 20 至 50 個百分點。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/64ed227b0c3e21be.png)

展開數據表（1）AT 256K TOKENS

項目	數值
Opus 4.6	92%
GPT-5.2	64%
Gemini 3	45%

展開數據表（2）AT 1M TOKENS

項目	數值
Opus 4.6	76%
Opus 4.7	32%
Gemini 3	24.5%

--- ## 第 6 部分 - 打破所有 RAG 指南的發現這個結果應該讓每個團隊重新思考他們構建 Prompt 的方式。亂序的文字比連貫的文字造成的傷害更小。你的直覺告訴你，整潔、組織良好的 context 區塊應該表現更好。將區塊按邏輯重排，將散文縫合成簡潔的簡報。但在超過 32,000 個 token 後，這種直覺是錯的。在所有 18 個模型中，亂序的「乾草堆」表現優於連貫的那個。破壞邏輯反而提高了效能。原因如下：連貫的文字為 attention 機制提供了一個看似合理、可以跟隨的替代故事。模型會抓住結構良好的段落，並將其視為答案進行推理。而由原始標記分隔的混亂區塊更容易被跳過。乾淨的摘要對人類審閱者來說讀起來更好，這正是它失敗的原因。它對模型來說讀起來也更好，而模型無法分辨「垃圾內容的連貫摘要」與「連貫的答案」之間的區別。他們還測試了 11 個位置的表現。位置幾乎不重要，長度才是關鍵。這甚至與 Anthropic 自己的 RAG 指南相悖，該指南建議將檢索結果放在前面。Chroma 完全沒有觀察到這種模式。 ![此圖表比較了在 RAG（檢索增強生成）應用中，經過整理的連貫文本與原始碎片化文本對模型表現的影響。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/db5bed5963fb45a3.png)

展開畫面重點

PART 6 The finding that breaks every RAG playbook SHUFFLED TEXT BEATS COHERENT TEXT PAST 32K TOKENS 左側方框（粉紅色）： COHERENT (what you ship) chunks reordered for flow, prose stitched into a clean briefing X gives attention a fake story to follow 右側方框（綠色）： SHUFFLED (what wins) raw chunks, split by markers, no smoothing, no narrative ✓ easier for the model to skip the junk 底部文字： the clean summary reads better to a human. that's exactly why it loses. 畫面重點：該圖表指出在處理超過 32k tokens 的長文本時，將資訊整理成連貫的敘事（Coherent）反而會干擾模型，導致模型將注意力放在虛構的敘事邏輯上；反之，將原始文本碎片化並打亂順序（Shuffled），雖然對人類閱讀不友善，卻能讓模型更容易過濾掉無用資訊，從而獲得更好的表現。

--- ## 第 7 部分 - 干擾項陷阱以及模型如何以不同方式撒謊干擾項（distractor）是指看起來像答案但並非答案的內容。主題相同、措辭相似，但細節錯誤。 Chroma 固定了干擾項的數量，只拉長了 context。一個干擾項就已經造成了傷害。四個則使其變得嚴重。但真正的發現是：隨著 window 變大，相同的干擾項造成了更大的破壞。問題不在於你增加了多少雜訊，而在於你給了它多少擴散的空間。而且模型以截然不同的方式失敗，如果你要選擇模型，這點很重要。GPT 模型會產生幻覺，表現得自信且錯誤。 Claude 模型則相反。面對模稜兩可的情況，它們通常會拒絕回答並聲稱沒有答案，即使答案就在那裡。一個對你撒謊。另一個直接放棄。兩者都會隨著 window 填滿而變差，且在長度增加時，兩者都不值得信任。 ![這張圖表比較了兩類 AI 模型在處理干擾資訊（distractors）時，面對長文本脈絡的不同錯誤行為模式。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/4b60f95c04b95f6d.png)

展開畫面重點

圖表標題：PART 7 The distractor trap – models lie differently (SAME DISTRACTORS, LONGER CONTEXT, MORE DAMAGE) 左側區塊（GPT FAMILY）： - 描述：generates a confident, wrong answer when distractors appear - 結論：X it lies to you 右側區塊（CLAUDE FAMILY）： - 描述：refuses and claims no answer exists, even when it's right there - 結論：X it gives up 底部總結：one lies, one quits. both get worse as the window fills. 畫面重點：此圖以對比方式呈現兩種模型家族在長文本脈絡中遇到干擾資訊時的缺陷，GPT 系列傾向於產生自信但錯誤的回答（說謊），而 CLAUDE 系列則傾向於拒絕回答或宣稱找不到答案（放棄）。

--- ## 第 8 部分 - 小學生測試，以及為什麼它無法修復 Chroma 進行了最後一項測試，簡單到令人尷尬。他們稱之為「重複單字」。取一個「apple」，重複幾百次，將其中一個換成「apples」，要求模型精確地複製回來。小學生都能做到。他們將測試擴展到 10,000 個單字。模型失敗了。它們提前停止、過度生成，或者產生了純粹的垃圾內容。 Gemini 2.5 Pro 在任務中途開始輸出隨機字串，如「orange orange orange--g.-g/2021/01/20/orange-county...」。Qwen3 寫道「我要休息一下，我沒心情」，而不是執行任務。這就是為什麼它無法修復的原因。這些模型是自回歸（autoregressive）的——它們生成的每一個 token 都成為下一個 token 的輸入。因此，輸出越長，模型對其自身不斷增長的文字堆進行的推理就越多。輸出 token 變成了輸入 token。它不僅僅是被你給它的東西噎住了。它還被自己剛剛說的話噎住了。而更大的 window 只會讓情況更糟。 ![本圖展示了大型語言模型在執行「重複文字」任務時所面臨的挑戰，說明模型如何因自身產出的內容而導致運作中斷。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/749ff083fb9ba3ba.png)

展開畫面重點

標題：PART 8 The grade schooler test, and why it's unfixable (小學生測試，以及為何它無法修復) 副標題：COPY THE TEXT BACK EXACTLY - MODELS CAN'T (精確複製文字 - 模型做不到) 程式碼區塊內容： - 標題：repeated-words · 10,000 words - prompt: replicate exactly → apple apple apples apple apple ... - Gemini 2.5 Pro: orange orange orange--g.-g/2021/01/20/orange-county... - Qwen3: "Okay, I'm going to take a break. I'm not in the mood." - 註解：# a task a child does on a blackboard. the model breaks. (一個孩子在黑板上做的任務。模型崩潰了。) UI 流程說明： - output token (what it just said) → becomes input (for the next token) - 底部說明：it's not choking on what you gave it. it's choking on what it just said. (它不是被你給它的內容噎住，而是被它自己剛說出的內容噎住。) 畫面重點：此圖展示了語言模型在處理長序列重複任務時的「自我干擾」現象。當模型產出的 token 成為下一個輸入時，模型會偏離原始指令（如 Gemini 2.5 Pro 產生了無關的 URL 連結，Qwen3 則直接拒絕執行任務），顯示出模型在維持長文本一致性上的技術侷限。

--- ## 第 9 部分 - 「RAG 已死」是目前 AI 領域最愚蠢的觀點讓我們終結那個你已經看過一百遍的觀點：「RAG 已死，現在 window 很大，全部貼進去就好。」聽起來很乾淨。但這完全是本末倒置。邏輯是：實驗室不斷推出更大的 window，Llama 4 宣稱有 1000 萬 token。既然都裝得下，誰還需要檢索？答案就是 context rot。對於 1M-token 的模型，效能下降大約在 300,000 到 400,000 個 token 時開始，遠低於他們賣給你的上限。對照 RULER（引用最廣泛的長 context 基準測試），有效 context 大約落在宣稱值的 50% 到 65%——在多跳推理（multi-hop reasoning）和程式碼任務中更低。用簡單的數字來說明差距：一個 200K 的模型給你 100-130K 的真實工作空間。一個 1M 的模型給你 500-650K。剩下的部分只是行銷簡報上的數字，模型根本用不到。將你的知識庫傾倒進百萬 token 的 Prompt 中，並不會讓它有更多可用的資訊，只會讓它有更多腐敗的空間。長 context 沒有殺死檢索。它殺死的是懶惰的檢索——隨機區塊、前五名、貼上並祈禱。但這正是改進檢索的理由，而不是停止檢索。問題從來不是「模型能不能裝下這些文字」，而是「你能不能提供正確的 token，讓它不至於腐敗」。這就是檢索。一直以來都是。 ![圖表反駁「RAG 已死」的說法，指出模型實際的有效上下文窗口僅為宣稱值的 60-70%，在處理困難任務時有效區間更會大幅縮減。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/3ff6a324d3b2e157.png)

展開數據表

	REAL WORKING ROOM	HARD TASKS
200K	100 - 130K	60 - 80K
1M	500 - 650K	250 - 350K
10M	still ~60-70%	falls off a cliff

--- ## 第 10 部分 - 本週該做什麼所以，更大並不代表更好。以下是週五前應該上線的調整，直接來自生產環境中表現最好的團隊。第一，將工作上限設定為模型宣稱 window 的 25% 到 30%。將其寫入設定檔。有效預算遠小於規格表上的數字。對於 1M 的模型，上限大約是 280,000 個 token，而不是一百萬。 ```javascript // [宣稱值, 工作上限] - 上限要比規格表更嚴格 const BUDGETS = { "opus-4-8": [ 1_000_000, 280_000], // 最新款，依然要設上限 "opus-4-6": [ 1_000_000, 300_000], // 該系列中長 context 表現最好 "gpt-5-5": [ 1_000_000, 260_000], "gemini-3-1": [10_000_000, 300_000], // 宣稱 10M，別相信它 } as const; // 超過工作上限後進行摘要 - 而不是等到硬性限制才處理 ``` 第二，對你真實的 Prompt 進行「大海撈針」評估。選出 30 個問題，答案位於你檢索到的 context 中。測量答案分別位於第 1、5、10、15、20 個位置時的準確度。第 5 到第 15 個位置之間的下降就是你的風險暴露——超過 20 個百分點意味著必須優先修復檢索。 ```python from anthropic import Anthropic client = Anthropic() def run_at_position(docs, answer, question, pos): docs = docs.copy() docs.insert(pos - 1, answer) # 將答案放在 pos 位置 context = "\n\n".join(docs) msg = client.messages.create( model="claude-opus-4-8", max_tokens=256, messages=[{"role": "user", "content": f"{context}\n\nQuestion: {question}"}], ) return msg.content[0].text for pos in [1, 5, 10, 15, 20]: out = run_at_position(docs, answer, question, pos) hit = answer_key.lower() in out.lower() # 你自己的匹配檢查 print(f"pos {pos}: {'PASS' if hit else 'FAIL'}") # 在約 30 個問題上運行此測試，並計算每個位置的平均通過率。 # pos 5 和 pos 15 之間的下降就是你的 context-rot 風險暴露。 ``` 第三，用原始區塊加上標題取代一個改寫過的 context 區塊。找出那些將檢索到的內容摘要成一個流暢段落的 Prompt。將其替換為由「Source N」標記分隔的原始區塊。在 50 個輸入上進行比較。混亂的結構通常會勝出。 ```javascript // ✗ 大多數團隊的做法 - 讀起來乾淨，但會導致模型腐敗 const ctx = await summarize(chunks.join("\n")); // ✓ 原始區塊，硬標記，不做平滑處理 const ctx = chunks .map((c, i) => `## Source ${i + 1}\n${c.text}`) .join("\n\n---\n\n"); ``` 第四，儘早壓縮，不要等到極限。長期的 Agent 運行會淹沒在自己的輸出中。在達到工作上限的 60% 時觸發摘要，保留最後幾次對話作為原文，並重新摘要摘要內容，以免膨脹。 ```python from anthropic import Anthropic client = Anthropic() WORKING_CAP = 280_000 # Opus 4.8, 1M window 限制在約 28% TRIGGER = int(0.6 * WORKING_CAP) # 儘早壓縮，不要等到極限 RECENT_TURNS = 6 # 保留這些對話原文 def summarize(text): msg = client.messages.create( model="claude-haiku-4-5", # 用便宜的模型進行摘要步驟 max_tokens=2000, messages=[{"role": "user", "content": f"壓縮此內容，保留事實與決策：\n\n{text}"}], ) return msg.content[0].text def maybe_compact(system_header, summary, turns): used = client.messages.count_tokens( model="claude-opus-4-8", messages=[{"role": "user", "content": system_header + summary + "".join(t["content"] for t in turns)}], ).input_tokens if used > TRIGGER: old = turns[:-RECENT_TURNS] # 除了最後幾次以外的所有內容 summary = summarize(summary + "".join(t["content"] for t in old)) turns = turns[-RECENT_TURNS:] # 固定最近的對話原文 return summary, turns # system_header 永遠不被摘要 ``` 第五，觀察你的資料。研究人員並不是在論文中發現 context rot 的，他們是透過盯著模型被噎住的輸入內容發現的。你 Agent 的 context 就是資料。閱讀它，你就會親自發現腐敗所在。 ![這是一份關於優化大型語言模型上下文處理能力的五項實務建議清單。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/0001fda2ad2a9d06.png)

展開畫面重點

該圖片為一份標題為「PART 10: What to do this week - FIVE CHANGES YOU CAN SHIP BEFORE FRIDAY」的技術建議清單，內容如下： 1. Set a working cap at 25-30% of the advertised window. Opus 4.8 1M → 280K 2. Run a needle-in-the-middle eval. Test the answer at positions 1, 5, 10, 15, 20. The 5-to-15 drop is your exposure. 3. Swap one paraphrased block for raw chunks with Source N headers. Messy usually wins. 4. Compact early, not at the limit. Trigger at 60% of your cap, keep recent turns verbatim, re-summarize the summary. 5. Look at your data. They didn't find context rot in a paper. They found it by reading the inputs models choked on.

--- ## 第 11 部分 - 轉變兩年來，業界一直在兜售同一個故事：更大的 window、更聰明的 Agent，只要增加 token 就好。但那些真正進行測量的人——18 個模型、194,000 次呼叫——發現了相反的事實。 window 是一個上限，而不是承諾。模型在填滿時會腐敗。而銷售 window 的基準測試並沒有測試那些會導致崩潰的東西。 context rot 不是單一模型的 Bug。它是這些系統運作方式的特性——自回歸、注意力不均勻、在中間最差、淹沒在自己的輸出中。 2026 年能交付可靠 Agent 的團隊，並不是那些擁有最大 window 的團隊。而是那些有效 context 小、結構化，且保持在宣稱值 30% 以下的團隊。檢索而不是傾倒。重置而不是累積。隨著 window 填滿來測量品質。 window 寫著一百萬。構建時請把它當作幾千來處理。 ![本圖表對比了 AI 模型在處理長文本時的「宣傳願景」與「實際效能」差異。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/abc8da09e50c4198.png)

展開畫面重點

圖表標題：PART 11 The shift 副標題：THE WINDOW SAYS A MILLION - BUILD LIKE IT SAYS A FEW THOUSAND 左側區塊（THE PITCH）： - bigger windows, smarter agents, just add tokens. fill the million. - X a measure of what fits 右側區塊（THE REALITY）： - effective context small, structured, held under 30% of advertised - ✓ a measure of what works 底部文字： retrieve instead of dump. reset instead of accumulate. measure as the window fills. 畫面重點：此圖表強調在 AI 開發中，應從盲目追求「百萬級別上下文窗口（Context Window）」的行銷宣傳，轉向關注「實際有效且結構化的上下文處理」，建議開發者採取檢索（retrieve）而非堆疊（dump）資料的策略，並在窗口填滿過程中進行效能評估。

## 標籤研究論文, LLM, Benchmark, Chroma, Anthropic, Claude