上下文視窗Context Window
也常被稱為:Context Window、上下文長度、脈絡視窗
一句話解釋
模型單次能處理的 token 總量上限,輸入與輸出共用這個額度。
它涵蓋什麼
Context window 常被誤解成「你能貼多少字進去」。實際上它涵蓋的是這一次請求裡的全部內容:
- 系統指令
- 完整的對話歷史
- 你這次的輸入(包含貼上的檔案)
- 模型即將生成的輸出
最後一項最常被忽略。如果你把視窗塞到快滿,剩下能拿來生成回覆的空間就很少了,模型可能被迫寫得比你要求的更短,或是中途被截斷。
「忘記」是怎麼發生的
當累積的 token 超過上限,最前面的內容會被移出視窗。這時模型不是「想不起來」——那段文字根本不在它眼前。
這解釋了幾個常見現象:
- 長對話進行到後面,模型開始違反你一開始設定的規則。
- 你在對話早期提供的背景資料,後來它像是沒看過。
- 重申一次要求,它馬上又能照做——因為你把它重新放進視窗了。
大視窗不等於能取代 RAG
視窗一大,很多人第一個念頭是「那我把整個知識庫貼進去就好了」。實務上通常不划算:
- 成本。每次請求都重送幾十萬 token,帳單很可觀。
- 延遲。要處理的內容越多,回應越慢。
- 精準度。無關內容會稀釋注意力,答案品質未必比較好。
RAG 的做法是先檢索出真正相關的幾段再送進去——通常又快、又便宜、又準。大視窗降低了 RAG 的必要性,但沒有取消它。
常見問題
- Context window 越大越好嗎?
- 大有好處,但不是線性的。研究和實務都顯示,模型對放在開頭和結尾的內容注意力較強,埋在中間的細節容易被忽略——這個現象常被稱為「lost in the middle」。塞滿一百萬 token 不代表模型會平均使用它們。
- 為什麼長對話會變慢又變貴?
- 因為每一輪都會把完整的對話歷史重新送進模型。對話越長,每次要處理的 token 越多,延遲和費用同步上升。這也是為什麼在話題轉換時開新對話,往往比在舊對話裡繼續更有效率。
相關術語
更新於 .全部術語