TL;DR | 面試情境模擬 #
👴 面試官:什麼是 LLM 的 Context Window?有什麼限制?
🧑💻 你:Context Window 是 LLM 單次推理能處理的 token 上限,包含輸入(System Prompt + 對話歷史 + 文件)和輸出。超出上限的內容模型看不到,等於忘記了。GPT-4o 是 128K tokens,Claude 3.5 是 200K,Gemini 1.5 Pro 最長 1M tokens。限制有兩個:成本(token 越多越貴)和「Lost in the Middle」效應(超長文件裡,模型對中間部分的注意力會下降)。
比喻:工作桌的大小 #
Context Window 就是你的工作桌面積——桌上能放多少文件。
- 小桌子(4K tokens):只能放眼前的幾頁紙
- 大桌子(200K tokens):可以鋪開整份報告
- 超大桌子(1M tokens):能同時看整個程式碼庫
但就算桌子再大,如果文件太多堆成一疊,你對埋在中間的那幾頁注意力也會下降。
Context Window 的組成 #
┌─────────────────────────────────────────┐
│ Context Window │
│ │
│ System Prompt (角色設定、規則) │
│ ─────────────────────────────── │
│ Conversation History │
│ User: ... │
│ Assistant: ... │
│ User: ... │
│ ─────────────────────────────── │
│ Retrieved Documents(RAG 注入的文件) │
│ ─────────────────────────────── │
│ Current User Message │
│ ─────────────────────────────── │
│ → Output(輸出也佔 token) │
└─────────────────────────────────────────┘
所有部分加起來不能超過上限,否則最早的對話歷史會被截掉。
各模型 Context Window 比較 #
| 模型 | Context Window | 約等於 |
|---|---|---|
| GPT-3.5 | 16K tokens | 約 12,000 個英文字 |
| GPT-4o | 128K tokens | 約一本短篇小說 |
| Claude 3.5 Sonnet | 200K tokens | 約一本長篇小說 |
| Gemini 1.5 Pro | 1M tokens | 約整個程式碼庫 |
| Llama 3(8B) | 8K tokens | 約 6,000 個英文字 |
Lost in the Middle 問題 #
研究發現(Stanford 2023 論文),LLM 對 context 開頭和結尾的注意力最強,對中間部分的注意力下降。
重要資訊放這裡 → 模型注意力高
─────────────
大量文件內容...
很多文件內容... ← 模型容易忽略中間
更多內容......
─────────────
重要資訊放這裡 → 模型注意力高
實務建議:
- 把最重要的指令放在 System Prompt(最前面)或最後的 User Message
- 用 RAG 只注入最相關的 K 個片段,不要把整份文件塞進去
Token 計費 #
Context Window 越大,API 成本越高。計費單位是 token:
| 項目 | 說明 |
|---|---|
| Input tokens | 你傳給模型的所有文字(Prompt + 文件) |
| Output tokens | 模型生成的回覆 |
| Cache tokens | 重複的 Prompt 部分(有些 API 有折扣) |
估算方式:英文約 1 token = 0.75 字,中文約 1 token = 1 字。
💡 延伸問題 #
Q1:Context Window 變大是不是就不需要 RAG 了? #
不完全。Context 再大也有上限,而且越長越貴。有些文件庫有幾百萬 token,不可能全塞進去。RAG 是找到最相關的片段,讓 context 精準而非龐大。兩者互補而非替代。
Q2:長 context 有沒有辦法讓模型「記得」更多? #
- Summarization:把舊對話壓縮成摘要放回 context,節省 token
- Memory 系統:把重要資訊存到外部(資料庫或向量 DB),需要時再注入
- KV Cache:推理層面的優化,讓重複出現的 context 不需要重新計算
Q3:Context 超出上限會怎樣? #
通常 API 會回報錯誤,或自動截掉最早的對話(取決於實作)。程式碼裡要自己管理歷史長度,例如只保留最近 N 輪對話,或把舊的壓縮成摘要。