Context Window 是什麼？能放很多字，不等於模型真的都記得

你跟 AI 聊了很久，前面交代過一次「專案只能用 TypeScript」，幾十輪之後，它卻突然丟出 Python。第一個直覺通常是：「它忘了。」但對大型語言模型來說，這件事背後不只是一個「記憶好不好」的問題。模型每一次產生答案時，都只能根據這一次被送進去的上下文工作，而這些內容能有多長，就受到 context window 限制。

Context window，可以先理解成模型一次推理時能參考的 token 範圍。 系統指令、對話歷史、你這次輸入的問題、貼進去的文件、工具回傳結果，都可能占用這個範圍。不同模型的上限不同，而且有些 API 會把輸入和模型接下來要產生的輸出一起算進可用空間。真正計算的單位不是頁數或中文字，而是 token。

一個 context 裡，通常不只有你的最後一句話

聊天介面看起來像你只送出一句新訊息，但系統真正呼叫模型時，往往會重新組出一包完整輸入。裡面可能有 system prompt、過去幾輪對話、目前使用者訊息、檢索到的文件，以及 Agent 剛剛呼叫工具得到的結果。這些東西最後都會被 tokenizer 轉成 token，再一起送進模型。

因此「128K context」這種規格，不是說模型擁有一個可以永久保存 128K token 的腦內資料夾，而是代表單次請求可以在規定範圍內攜帶這麼多上下文。下一次請求如果應用程式沒有再把某段歷史送進去，模型就沒有那段文字可以參考。

放得下，不代表每一段都用得一樣好

這是長上下文最容易被誤解的地方。Context window 的最大長度，首先回答的是「最多可以輸入多少」，不是「輸入到上限時，每一個細節都能被同樣可靠地找回」。2024 年發表於 TACL 的 Lost in the Middle 研究就觀察到，當需要使用的資訊被放在長上下文不同位置時，模型表現會改變；一些模型在相關資訊位於開頭或結尾時表現較好，放在中間則可能明顯下降。

這不代表所有模型永遠都有一模一樣的「中間失憶症」。模型架構、訓練方式與長上下文能力都在改變。但它提醒了一件事：最大 context window 是容量規格，不是理解品質保證。 把十萬 token 全塞進 prompt，不能取代資料整理、檢索與測試。

超過 Context Window 時，不是單純「忘記前面」

如果整包輸入超過模型或 API 允許的範圍，實際發生什麼事取決於系統設計。有些 API 直接拒絕請求；有些聊天產品會先移除舊訊息、摘要較早的內容，或做 context compaction，再把縮短後的內容交給模型。也就是說，你在介面上仍然看得到完整聊天紀錄，不代表每一則訊息都原封不動地存在下一次模型輸入裡。

這也是為什麼長對話偶爾會出現奇怪的前後不一致。問題可能不是模型「突然變笨」，而是先前資訊已被截掉、壓縮，或在大量上下文裡沒有被有效利用。要判斷是哪一種，需要看實際產品怎麼管理 context，而不能只看模型標示的最大 token 數。

Context 很大，為什麼還需要 RAG、摘要和 Memory？

因為把所有東西一直塞進 context，通常不是最乾淨的設計。RAG 會先從外部資料中挑出和這次問題最相關的內容，只把需要的片段放進上下文；摘要會把已經很長的對話壓成較短表示；memory 系統則可能把值得跨對話保留的資訊存到模型外部，等真正需要時再取回。

三者解決的其實不是同一件事。Context window 是容量邊界；RAG 是「這次該拿哪些資料進來」；memory 是「哪些資訊值得跨請求保存」；摘要則是「怎麼把已經很長的歷史壓短」。把它們混成「模型記憶力」一個詞，就很容易設計錯系統。

更大的 Context Window 仍然很有價值，只是不是無限記憶

長 context 讓模型可以一次處理更長文件、更多程式碼、更多對話紀錄，很多任務確實因此變得更方便。但上下文越長，通常也代表要處理更多 token，可能帶來更高的計算量、延遲或 API 成本；而大量不相關資訊本身也可能變成干擾。因此實務上常見的問題不是「怎麼把 context 塞滿」，而是「這一次模型真正需要看什麼」。

所以如果只記住最後一句：Context window 決定模型這一次最多能帶著多少上下文工作；它不是永久記憶，也不是保證模型能把所有內容同樣可靠地用起來。 看懂這件事之後，RAG、memory、context engineering 和長對話管理其實都會開始連在一起。