上下文視窗到底有多大？揭開AI記憶力背後的真相

上個月我們在跑一個文件分析任務——給Claude塞了一份2000頁的法律合約，讓它找出所有關於賠償條款的內容。Claude沒有報錯，也沒有說「文件太長了」，它給了我們一個答案。但那個答案，只覆蓋了文件的前三分之一。

這就是上下文視窗問題的本質：不是「放不進去」，而是「放進去了但不一定都被處理」。

什麼是上下文視窗

簡單說，上下文視窗是模型在處理你的請求時，一次能「看到」的文字量上限。超過這個上限，要麼被截斷，要麼報錯。單位是token（大約1個中文字=1.5個token，1個英文詞=1-2個token）。

現在主流模型的上下文視窗：

數字看起來很美好。但用過之後你會發現，上下文視窗大小只是這個遊戲的入場券，不是終點。

2023年史丹佛有一篇論文專門研究這個問題，標題就叫 Lost in the Middle。結論是：大多數語言模型對放在輸入開頭和結尾的資訊記憶最好，對放在中間的資訊容易遺漏。

這不是某個模型的bug，是所有Transformer架構模型的普遍現象。原因在注意力機制的工作方式：位置編碼和注意力權重的分布，天然讓開頭和結尾更「顯眼」。

我們在SFD實驗室的實測裡驗證了這一點：給Claude一份100頁的技術文件，問文件中間某處的細節，命中率比同樣細節在開頭或結尾時明顯下降。

1. 把最重要的資訊放在開頭和結尾。如果你能控制輸入的順序，把關鍵指令放最前面，關鍵約束放最後面。不要把核心需求埋在大段文字的中間。

2. 分塊+檢索通常比一個巨型prompt更可靠。對於很長的文件，拆成chunks用向量檢索——只把最相關的chunks載入上下文——通常比一次性塞進去效果更好。

3. Context Rot是真實存在的。當上下文很長時，即使技術上在視窗範圍內，模型對早先提到的細節的處理品質也會下降。我們對於需要高精度的任務，通常把工作上下文控制在50K token以內。

大上下文視窗意味著高成本。Gemini的1M上下文聽起來很吸引人，但每個輸入token都要計費。一個20K token就能解決的任務，「以防萬一」用200K token，是在燒錢。

合適的上下文視窗，是匹配你任務需要的那個——不是最大的那個。