![[AI 上下文 #2] 長上下文為何會毀掉回答 封面圖](/assets/images/posts/2441c21a-97a2-413d-93be-21c88b2120cb/1.jpg)
第 1 集我們看過上下文視窗為何有限。但看到最近的模型規格，不免會想：既然已經有 100 萬 token 的模型，直接把整個程式碼庫或文件一次放進去不就好了？還需要省著用嗎？
這一集要打破的迷思正是這個。能「放進」上下文視窗，和模型能「善用」它，是完全不同的問題。多項研究已確認，上下文越長，模型效能越會下降；長時間執行過代理程式的人也都會親身感受到：工作階段後半段的回答變得散亂，甚至重新修理已經修好的錯誤。
lost in the middle：中間內容讀不到
2023 年史丹佛研究團隊發表的〈Lost in the Middle〉論文，是這個領域最常被引用的成果之一。他們把正確文件放在長上下文的不同位置，測量模型找出它的能力，結果顯示準確度呈 U 型曲線。最前面和最後面的資訊容易找出來，但正中央資訊的檢索率會大幅下降。嚴重時，把答案放在中間的效能甚至低於完全不提供文件時直接提問。
模型確實會「讀完」20 份文件，只是並不會平均分配注意力。這和人閱讀厚重報告時集中看前言與結論、正文只用眼睛掃過的模式很像；相同模式也會出現在注意力權重中。
模型發表資料常見的「大海撈針（needle in a haystack）」測試分數，很容易掩蓋這個問題。這項測試只是在長文字中埋入一個句子，再要求模型原樣找出來；最新模型大多接近滿分。問題在於實務工作不是單純檢索。當任務改成需要串連多處資訊並進行推理時，同一個模型的分數會隨上下文變長而下滑。
context rot：長度本身就會降低效能
2025 年，向量 DB 公司 Chroma 發表技術報告，將這種現象命名為「context rot」。他們以 18 個主要模型為對象，只逐步增加輸入長度並執行相同任務，結果顯示即使任務難度不變，光是輸入變長，效能就持續下降。即使仍在上下文視窗規格之內也是如此。
原因是多層因素疊加。首先是注意力的結構性限制。注意力權重就像總量固定的預算，token 越多，分給單一 token 的份額就越薄。無關內容混入越多，真正重要的訊號就越容易被淹沒。其次是訓練分布問題。模型訓練時接觸的大多是短文件，因此數十萬 token 的輸入對模型而言是訓練中幾乎沒見過的陌生情境。規格上能處理，不代表能保證該長度下的推理品質。
因此在實務上，需要建立「有效上下文」的概念。即使規格是 20 萬 token，在複雜推理任務中能維持品質的區間也遠短於此，這樣看待比較安全。規格數字代表「放到這裡不會出錯」，不是「放到這裡仍然很聰明」。
代理程式的上下文不只是長，而是很混亂
在代理程式中，問題會更嚴重一層。正如第 1 集所見，代理程式的上下文會累積工具呼叫結果，而這些累積內容不只是很長，彼此還可能互相矛盾。
看看典型情境。代理程式為了修正錯誤而讀取檔案、修改檔案，再讀一次。此時上下文中並列著同一檔案修改前與修改後的版本，也同時有失敗和成功的測試記錄。模型下一步判斷時會參考哪一份，無法保證。它看著舊版本說「這裡還有錯誤」，接著重新開始一項其實已完成的修正，問題就由此產生。
這些失敗模式也有各自的名稱。錯誤資訊（例如混入幻覺的摘要）進入上下文，連鎖污染後續判斷，稱為 context poisoning；累積的歷史過長，使模型被過去模式的重複牽引，而不是遵循新指示，稱為 context distraction；相似但不同的資訊混在一起造成混淆，稱為 context confusion；矛盾資訊互相衝突，稱為 context clash。即使不知道名稱，症狀也很熟悉。工作階段後半段的代理程式特別容易重複犯同樣錯誤，或做出被要求不要做的事，通常就是這四者之一。
察覺品質下降的訊號
在長時間工作階段中看到以下訊號，就該懷疑是上下文問題。
- 重新處理已解決的問題，或反覆讀取同一個檔案
- 開始違反工作階段初期訂下的規則，例如程式碼風格或不可修改的檔案
- 回答變得冗長，偏離剛才的問題，反而被很久以前的主題牽著走
- 忽略剛才提供的資訊，改用上下文某處的過時資訊回答
重要的是，這不是模型「累了」。模型是每一輪都從頭重新讀取內容的無狀態機器。改變的不是模型，而是它必須讀取的上下文狀態。輸入變得又長、又亂、又矛盾，輸出品質自然就會下降。
總結
- 資訊放進上下文，不代表就會被善用。中間資訊檢索率下降的 lost in the middle，以及長度本身降低效能的 context rot，都是研究已確認的現象。
- 規格數字是上限，不是品質保證。越需要複雜推理的工作，就越應該假設有效上下文遠短於規格。
- 代理程式的上下文會累積工具呼叫殘骸，甚至包含矛盾。poisoning・distraction・confusion・clash 四種失敗模式，是工作階段後半段品質下降的主要原因。
診斷完成後，下一集開始談處方。我們先從最基本的工具 /clear 與 /compact 開始。兩者都「清空上下文」，但運作原理完全不同，使用錯誤反而會連工作脈絡一起丟掉。接下來建立何時清除、何時壓縮的判斷標準。