現代 AI 的「上下文視窗」：從 8K 到 1M，模型是如何在海量資訊中不「迷路」的？

在 AI 圈，我們經常聽到一個詞叫「上下文視窗」（Context Window）。當你看到某些模型號稱支援 128K、甚至 1M（一百萬）個 token 時，這意味著你可以把一整本書、整個程式碼庫或者長達數小時的會議記錄一次性塞給 AI，而不需要手動切片。

但一個殘酷的真相是：視窗大 $\neq$ 能記住所有內容。

很多模型雖然能「吞下」一百萬個 token，但在處理中間部分的資訊時卻像失憶了一樣。這就是學術界著名的「迷失在中間」（Lost in the Middle）現象。那麼，AI 系統是如何在工程上實現超長上下文，又是如何嘗試解決「記憶遺失」問題的？

1. 核心瓶頸：Attention 的平方複雜度

要理解長上下文，必須先看 Transformer 的核心——自注意力機制（Self-Attention）。

在標準的 Attention 中，每一個 token 都要與之前所有的 token 計算一次相關性權重。這意味著如果輸入長度是 $N$，計算量和顯存佔用是 $N^2$（平方級增長）。
- 輸入 1K token $\rightarrow$ 計算量 $1,000^2 = 1,000,000$
- 輸入 100K token $\rightarrow$ 計算量 $100,000^2 = 10,000,000,000$ (增長了 1 萬倍！)

如果直接硬跑，顯存會瞬間爆炸。為了突破這個限制，工程上採用了三種主流方案：

A. 旋轉位置編碼 (RoPE) 與 外推

早期的位置編碼是絕對的（第 1 個詞、第 2 個詞...），一旦超過訓練時的長度（比如 4K），模型就完全不知道怎麼處理第 5K 個詞。
RoPE 將位置資訊轉化為旋轉矩陣。透過對旋轉角度進行「縮放」（Interpolation/Scaling），可以讓模型在推理時處理比訓練時更長的序列，而不需要重新訓練整個模型。

B. FlashAttention: 用記憶體管理換速度

FlashAttention 不改變數學結果，但它改變了 GPU 讀取資料的方式。它透過分塊（Tiling）計算，減少了資料在 GPU 高速緩衝（SRAM）和主顯存（HBM）之間的搬運次數。這讓計算速度大幅提升，且顯存佔用從平方級降低到了線性級（針對記憶體讀寫）。

C. KV Cache 的壓縮

為了避免每次生成新詞都重新計算之前的所有狀態，模型會將之前的 Key 和 Value 保存下來（KV Cache）。但在超長上下文中，KV Cache 會佔用幾十 GB 的顯存。
- Multi-Query Attention (MQA): 讓所有 Head 共用一組 KV，極大地壓縮了快取體積。
- Grouped-Query Attention (GQA): 在 MQA 和標準 Attention 之間取折衷，既保證了效能又降低了開銷（Llama-3 等主流模型均採用此方案）。

2. 「迷失在中間」：為什麼大視窗不等於強記憶？

即便工程上解決了顯存問題，模型依然面臨認知挑戰。研究發現，當關鍵資訊位於輸入文字的開頭或結尾時，模型的檢索準確率最高；而當資訊被埋在文字正中間時，準確率會劇烈下降。

這就像人類閱讀長文件一樣：我們傾向於記得開頭和結尾，而中間的部分容易被模糊化。對於 AI 來說，這是因為訓練資料中大多數高品質指令的答案都集中在開頭或結尾。

3. 實戰建議：如何高效利用長上下文？

如果你正在使用支援超長視窗的模型（如 Claude 3.5 或 GPT-4o），不要盲目地把所有資料全部丟進去。以下是三個實用的工程技巧：

1. 關鍵資訊前置/後置：將最重要的指令、約束條件或核心參考資料放在 Prompt 的最開始或最末尾。
2. 結構化標記：使用清晰的 XML 標籤（如 <document>...</document>）或 Markdown 分級標題來分隔不同段落。這能幫助模型更好地定位資訊邊界。
3. RAG $\rightarrow$ Long Context 的混合模式：對於千萬級 token 的海量資料，依然建議先用 RAG（檢索增強生成）篩選出最相關的 Top-K 片段 $\rightarrow$ 再將這些片段放入長上下文視窗進行精細分析。這種「粗篩 + 精讀」的組合才是目前的工業最佳解。

總結

超長上下文視窗將 AI 從一個「短時對話框」變成了能夠處理複雜專案的「數位大腦」。雖然 $N^2$ 的複雜度依然是物理天花板，但透過 RoPE、FlashAttention 和 GQA 等工程優化，我們已經進入了百萬 token 時代。但請記住：工具的上限由參數決定，而效果的上限由你的 Prompt 建構方式決定。