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

什麼是Context Rot？

你可能注意到過這個現象：開始一段跟AI的對話，一起處理一個複雜問題，大約在第30-40條訊息左右，回應品質開始微妙地下降。不完全是遺忘——資訊技術上還在上下文視窗裡。而是更微妙的東西：模型似乎被積累的上下文重量「搞糊塗了」。

這個現象有個名字：Context Rot（上下文腐敗）。

工程層面的解釋

Context Rot不是單一機制——它是多種因素的綜合效應：

1. 注意力稀釋

Transformer的注意力是跨上下文中所有token計算的。隨著上下文增長，每個單獨的token獲得的注意力權重成比例地減少。早期的關鍵資訊被後來上下文的積累所「稀釋」。

2. 指令衝突

在長對話中，早期的指令常常被後來的指令修訂、澄清或取代。模型通常更重視近期的指令——但舊指令並不消失。結果是潛伏的衝突，可能以不可預測的方式浮現。

3. 連貫性退化

隨著上下文增長，維持全域連貫性變得更難。回答第40個問題的模型需要整合39次之前交流的資訊。在某個時刻，綜合能力崩潰——回應在局部上合理，但在全域上與早先建立的事實不一致。

它什麼時候真正成為問題？

根據SFD實驗室在生產Agent任務上的經驗：

• 20K token以下：通常沒問題
• 20K-50K：在複雜多約束任務上有明顯退化
• 超過50K：Context Rot成為可靠性的重要因素

這些不是硬性邊界——因模型、任務類型和上下文結構化程度而異。

緩解策略

上下文壓縮：定期總結早期對話，用提煉的摘要替換詳細的交流。在保留關鍵資訊的同時減少token數量。對對話上下文效果好；對細節很重要的技術任務較難。

上下文剪枝：識別並移除不再相關的交流。比壓縮更激進，需要判斷什麼還需要。

Session分割：有意識地把長任務分成獨立的Session。明確地傳遞關鍵狀態，而不是依賴對話歷史。摩擦更多，但對長期執行的Agent任務可靠性大幅提升。

結構化上下文管理：不要讓上下文有機地增長——主動管理裡面的內容。這意味著在重要資訊被埋沒之前把它寫到外部記憶，只載入當前任務需要的內容。

誠實的結論

Context Rot是真實存在的，更大的上下文視窗解決不了它——只是把門檻往上推。對於認真的Agent工作，正確的方法不是「用更大的上下文視窗」——而是「更仔細地管理上下文視窗裡有什麼」。