What is Context Window（上下文視窗）?

Definition

上下文視窗（也稱為上下文長度或序列長度）定義了語言模型在單次互動中能處理的 token 總數上限——包括輸入提示和生成輸出。擁有 4,096 token 上下文視窗的模型大約可以處理 3,000 個英文字的組合輸入和輸出；擁有 128,000 token 視窗的模型可以處理相當於一部短篇小說的內容。

上下文視窗是在預訓練期間內建到模型中的架構約束。它由位置編碼方案和注意力矩陣的大小決定。在標準自注意力機制中，記憶體和計算隨序列長度呈二次方擴展（O(n²)），這就是為什麼上下文視窗在歷史上受到限制。現代技術如旋轉位置嵌入（RoPE）、滑動窗口注意力和 FlashAttention 已使上下文視窗從早期模型的 2K-4K token 增長到最近架構的 128K-1M token，同時保持資源使用可控。

對於微調，上下文視窗對訓練資料準備有實際影響。每個訓練範例必須適合模型的上下文視窗——如果範例超過限制，它將被截斷，可能丟失關鍵資訊。訓練上下文長度有時可以比模型的最大值更短以節省記憶體（例如在支援 8,192 的模型上以 2,048 token 進行訓練），代價是微調後的模型在超出訓練長度時可能表現不太可靠。

Why It Matters

上下文視窗決定了模型能實際執行什麼任務。摘要一份 50 頁的文件需要足夠大的上下文視窗來容納整個文件加上摘要。多輪對話助手需要上下文來維持完整的對話歷史。對於涉及長文件的企業應用——法律合約、醫療記錄、程式碼庫——上下文視窗長度通常是模型選擇的決定性因素。此外，上下文視窗限制影響微調經濟性：較長的訓練範例每批次消耗更多 GPU 記憶體，增加訓練成本。

How It Works

當文字提交給模型時，分詞器將其轉換為 token ID 序列。如果此序列超過上下文視窗，必須截斷否則請求將失敗。在處理過程中，注意力機制計算視窗內所有 token 之間的關係——每個 token 可以關注每個前面的 token（在因果模型中）。位置嵌入編碼每個 token 的位置，使模型理解詞序。在推論時，鍵值快取（KV cache）儲存先前生成 token 的注意力狀態以避免冗餘計算，但此快取隨上下文長度線性增長，對於長序列可能佔據主要的 GPU 記憶體使用。

Example Use Case

一家法律科技公司建立合約審查助手時發現，他們的平均合約長度為 12,000 token。他們選擇了具有 32K 上下文視窗的基礎模型，以舒適地容納完整合約加上系統提示和生成的分析。在微調期間，他們將最大序列長度設定為 16,384 token（資料集中最長的範例加上安全餘裕），以平衡訓練記憶體使用和覆蓋範圍。在生產中，模型在單次處理中處理整個合約，不會因截斷而丟失關鍵條款。

Key Takeaways

• 上下文視窗限制了模型一次能處理的 token 總數（輸入 + 輸出）。
• 現代模型從 4K 到 1M token 不等，8K-128K 最為常見。
• 注意力記憶體隨序列長度呈二次方擴展，使長上下文成本昂貴。
• 訓練範例必須適合上下文視窗，否則將被截斷。
• 上下文視窗長度是文件密集型應用中模型選擇的關鍵因素。