Context rot 跟幻覺（hallucination）是同一件事嗎？
不是同一件事，但兩者常常一起出現。幻覺是模型生成了看似合理但實際不存在或不正確的內容，成因很多（訓練資料限制、缺乏檢索依據等）；context rot 則是模型明明有正確資訊在上下文裡，卻因為資訊被稀釋、埋沒在大量無關內容中，而抓取失敗或引用錯誤位置的內容。簡單說，幻覺是「模型不知道答案卻硬答」，context rot 更像是「答案明明就在眼前，模型卻找不到或看錯地方」。
實務上兩者的影響經常疊加：context rot 導致模型抓錯上下文中的線索，進而生成看似有依據、實際上引用錯誤的答案，外觀上就很像典型的幻覺。
如果上下文窗口已經很大（例如數十萬 token），是不是就不用擔心 context rot？
窗口大小和 context rot 的關係，不是「窗口越大問題就越輕」這麼單純。窗口大代表模型技術上「能容納」更多內容，但不代表塞滿了以後準確率不會下降——多份公開的長上下文評測顯示，即使模型號稱支援極大的上下文長度，實際準確率往往在窗口用到七八成甚至更早，就已經開始出現明顯下滑，尤其是需要跨多個分散片段做推理整合的任務。
換句話說，「上限多大」和「用到多少會開始腐化」是兩個獨立的問題，前者是硬體規格，後者是實際使用時的品質曲線，不能只看規格數字就假設沒有風險。
如果一個任務必須用到大量文件，實務上有哪些方法可以減緩 context rot？
幾個常見做法：第一，把資料先分類篩選，只放跟當前這一步真正相關的部分，其餘的等需要時再補充，而不是一次全丟進去；第二，善用摘要——長對話或長文件先壓縮成重點摘要再放入上下文，而不是逐字保留；第三，把最關鍵的指令或資訊放在上下文的開頭或結尾，避免埋在中段（呼應 lost in the middle 現象）；第四，分段處理——如果任務可以拆成多個獨立步驟，分批餵給模型並在每一步確認結果，通常比一次性丟入全部資料更穩定。
這些方法背後的共同邏輯，其實就是上下文工程的核心精神：讓上下文窗口裡的每一段內容都在為當前任務服務。
一般使用者跟 Claude 對話時，怎麼判斷是不是已經出現 context rot 了？
幾個常見的警訊：模型開始重複之前已經被糾正過的錯誤、忽略你在對話中段特別強調過的要求、或是回答內容明顯只針對訊息開頭的部分而漏掉後半段的重點。這些現象單獨出現不一定代表 context rot，但如果是在一個已經進行很長時間、話題也多次轉換的對話裡出現，通常就是上下文已經過度累積的訊號。
最直接的處理方式，是把當前真正需要的背景資訊整理成一段精簡摘要，開一個新對話貼上去繼續，而不是在舊對話裡不斷加碼。
很多人以為上下文窗口（context window）越大越好——反正 Claude 能讀的字數變多了，乾脆把整份文件、整段對話歷史、所有可能相關的資料全部丟進去，讓模型自己判斷。這個直覺其實有一個名字，叫「context rot」（上下文腐化）：隨著放進上下文窗口的內容變長變雜，模型從中準確抓取關鍵資訊的能力反而會下降，即使窗口本身的容量還遠遠沒有用滿。
模型處理長文本時依賴注意力機制（attention mechanism），去判斷輸入裡的哪些部分跟目前的任務最相關。理論上，注意力機制可以看到整個上下文窗口的所有內容，但實務上，當內容量暴增，模型分配給每個片段的「注意力預算」會被稀釋。研究者觀察到一個常見現象叫「lost in the middle」：放在上下文最前面和最後面的資訊，模型通常記得比較準，但埋在中段的內容，即使同樣重要，也更容易被忽略或誤判。這跟人類讀一份很長的會議記錄很像——你通常對開頭的議程和結尾的結論印象深刻，中間細節反而模糊。
Context rot 的嚴重程度，跟塞進去的內容「有沒有組織」關係很大。同樣是十萬字的輸入，如果是雜亂堆疊的原始資料（例如把十份不相關文件直接串接），模型抓重點的難度會明顯高於結構清楚、有標題分段、跟任務直接相關的內容。這也是為什麼檢索增強生成（RAG）系統不會把整個知識庫塞進提示詞，而是先做相似度篩選，只取最相關的幾段——目的正是避免把不相關的雜訊也一起餵給模型，稀釋掉真正重要的部分。
Context rot 不只出現在一次性丟進大量文件的情境，長時間的多輪對話同樣會累積問題。隨著對話輪數增加，早期討論過的細節、之前糾正過的錯誤、已經達成的共識，全部堆疊在上下文窗口裡，模型有可能在後續回答中「忘記」前面已經確認過的重點，或是把早期被推翻的說法又講一次。這也是為什麼實務上常見的建議是：當一個任務告一段落、或對話已經進行很久且主題轉換，開一個新對話反而比硬撐在同一個視窗裡更有效率。
如果你在用 Claude 處理需要長時間累積上下文的工作（例如逐步修改一份很長的合約、debug 一個大型程式庫、或是分析一份幾百頁的財報），了解 context rot 能幫你省下實際的時間與 API 成本：與其把所有資料一次塞進去、期待模型自己找出重點，不如先做篩選——只放跟當前這一步真正相關的段落，需要時再補充其他部分。這個做法不只降低出錯機率，也因為輸入 token 變少，直接反映在 API 帳單上；如果是透過付費方案或 API 大量使用 Claude，這個差異在長期使用下並不小。