搜尋意圖： 如果你在找「上下文窗口 是什麼」或「上下文窗口 和相近概念差在哪」，先看這頁的短定義、完整說明與延伸比較。
TL;DR： 上下文窗口是指，大型語言模型一次性能處理的最大 Token 數量，超過此限制模型便會遺忘先前的內容
實用情境： 適合用在閱讀 AI 文章、產品文件或和同事討論時，先用一頁快速對齊概念。
下一步： 先讀完定義，再往下看延伸比較與對應工具，把概念轉成實際應用。
你有沒有發現，聊天聊太長，AI 好像會忘記前面說過的事？
你可以把上下文窗口想成「模型一次能看見的文字長度」：在這個範圍裡，它還記得你說了什麼，超過後就看不到更早的內容。
它很重要，因為很多對話、文件分析和長文推理都受這個限制影響，窗口太小時，模型就容易漏掉前文資訊。
容易混淆
上下文窗口 vs 長期記憶 vs token 上限
上下文窗口：單次可處理的內容範圍
長期記憶：跨次對話仍可保存的資訊
token 上限：窗口大小常用的計量方式
最關鍵的區別：上下文窗口是「這一回合看得到多少」，不是永久記住多少。
記住這句就好
視野越大，模型越不容易忘前文。
實際案例
長篇文件摘要
前：文件一拉長，前面的定義常被漏掉
後：增加上下文窗口，或先分段摘要，再合併成總結
客服對話
前：聊到第三輪後，模型忘了客戶前面提過的訂單號
後：把關鍵資訊持續放回上下文，讓模型維持對話脈絡
算法與應用
上下文窗口常和注意力機制、token、檢索增強生成一起討論
在產品設計上，它會影響提示長度、文件切片策略、對話保留和成本控制
窗口變大不是毫無代價，計算成本通常也會跟著上升
中英對照與常見說法
| 說法 | 出現場合 |
|---|---|
| 上下文窗口 | 中文最常見譯法 |
| 上下文视窗、上下文长度 | 簡體與其他變體 |
| Context Window | 英文原名 |
| 脈絡窗口、上下文限制 | 常見變體 |
| Context Length（上下文長度） | 幾乎同義，多用於描述模型規格 |
它到底限制了什麼
上下文窗口是模型單次能處理的 token 總量上限，而且這個上限是輸入加輸出一起算的。
這件事常被誤解。窗口 128K 不代表可以塞 128K 的文件然後還能生成很長的回覆，塞得越滿，能生成的空間就越少。實務上要預留輸出空間。
一次對話裡佔用窗口的東西通常包括：系統提示、工具定義、先前的對話歷史、檢索回來的文件、使用者這次的問題、以及模型要生成的回覆。多輪對話裡最先撐爆窗口的往往是對話歷史。
token 與字數的換算
| 語言與內容 | 大約換算 |
|---|---|
| 英文 | 1 個 token 約 4 個字元，或約 0.75 個單字 |
| 中文 | 1 個中文字約 1 到 2 個 token，視斷詞器而定 |
| 程式碼 | 通常比一般文字耗 token，符號多且變數名會被切碎 |
換算比例依模型的斷詞器而異，要精確計算就用該模型提供的計算工具，不要用經驗值估。中文的 token 效率通常比英文差，同樣一份文件翻成中文可能多耗三成到五成的 token。
窗口大不等於用得好
中間遺失（lost in the middle） 是已知現象：模型對放在開頭與結尾的資訊注意力較高，放在中間的容易被忽略。所以重要的指令與關鍵文件應該放在開頭或結尾，不要埋在一大段文字中間。
成本與延遲隨長度上升。 自注意力的計算量隨序列長度平方成長，雖然現在有各種最佳化，長上下文仍然明顯更慢更貴。把整份手冊塞進提示，往往比先檢索出相關的三段再送進去，又慢又貴又不準。
有效上下文常常小於宣稱上下文。 模型宣稱支援某個長度，不代表在該長度下的推理品質不變。評估長上下文能力要看實際的檢索與推理測試，不要只看規格數字。
這也是為什麼檢索增強生成（RAG）並沒有因為窗口變大而被取代：先篩掉無關內容再送進模型，仍然是又快又準又省的做法。
情境判斷
Q1（直覺題）： 如果模型忘了你前面兩千字說過的規則，可能和上下文窗口有關嗎？
→ 有，很可能是因為超出可見範圍。
Q2（判斷題）： 上下文窗口越大，就一定越好嗎？
→ 不一定。窗口大通常更能記住前文，但成本、速度和實作難度也會上升。
常見問題
上下文窗口和記憶力是一樣的嗎？
不一樣，它只是單次可讀範圍，不是人類式記憶。
為什麼有些模型能處理長文件，有些不行？
主要差在窗口大小、推理成本和設計策略。
超過窗口的內容會怎樣？
通常會被截掉，模型就看不到了。