上下文視窗 128K 和 128K 不一樣：為什麼「越大越好」是個誤區

上週有個開發者朋友問我：「我的模型支援 200K 上下文，是不是把整個程式碼倉庫塞進去就行？」

我告訴他：不行。

不是模型撐不住，而是**塞進去的東西越多，模型找重點的能力越差**。這就像你讓一個實習生讀 500 頁文件然後回答一個問題——他確實能讀完，但大概率會漏掉關鍵資訊。

上下文視窗的真相

上下文視窗（Context Window）是模型一次能「看到」的 token 數量上限。2026 年主流模型普遍支援 128K 到 200K，聽起來很厲害。但這裡有個關鍵區別：**能裝下，不等於能記住**。

模型處理長文本的方式不是「逐字閱讀」，而是透過注意力機制（Attention）在輸入的所有 token 之間建立關聯。當輸入很長時，注意力權重會被稀釋——模型需要同時關注幾千個 token，每個 token 分到的注意力就變少了。

我們做了一個簡單的對比實驗。給同一個模型輸入不同長度的文本，然後問同一個問題：

- **10K token 輸入**：模型準確找到了答案所在段落，引用了原文。

- **50K token 輸入**：模型找到了答案，但混入了無關資訊。

- **100K token 輸入**：模型給出了看似合理但部分錯誤的答案，因為它把兩段相似內容搞混了。

這不是模型「變笨了」，而是**資訊密度下降**導致的。就像在一堆書裡找一句話，書越多，找得越慢，錯得越多。

不要直接把 10 萬字的文件丟給模型。先用模型自己做一個摘要（控制在 2K token 以內），然後在摘要基礎上提問。兩步走比一步到位準確得多。

模型對輸入開頭和結尾的資訊記憶最強，中間部分最容易遺忘——這就是所謂的「中間遺失」（Lost in the Middle）現象。所以，把你的核心問題放在 prompt 的第一行，參考資料放在後面。

如果必須處理超長文本，把它切成 4K-8K token 的段落，逐段讓模型提取關鍵資訊，最後把各段結果彙總。這比一次性塞進去效果好得多，而且成本更低——因為模型不需要在每次推理時處理全部 token。

因為行銷需要。「200K 上下文」聽起來比「4K 上下文」高級得多。但實際使用中，超過 32K 的情境並不多。大多數對話、程式碼審查、文件問答，16K-32K 已經綽綽有餘。

更大的上下文視窗還有一個隱藏成本：**推理延遲和費用**。token 越多，模型需要計算的注意力矩陣越大，回應時間呈非線性增長。

在我們 SFD 實驗室的 15 個 Agent 日常工作中，我們給每個 Agent 的上下文視窗設了硬上限——通常不超過 16K。超過的部分要麼被截斷，要麼先做摘要。

結果是什麼？Agent 的回應速度提升了 40%，錯誤率下降了 25%。

**少即是多，在 AI 系統裡同樣適用。**

上下文視窗不是越大越好，而是越精準越好。與其追求「能裝多少」，不如花心思在「怎麼裝」上。好的 prompt 工程師不是會寫長 prompt 的人，而是知道什麼時候該刪掉一半內容的人。