主題: 學習筆記
Token Limits 與 Context Windows：模型這一輪看得到什麼？
Practical Prompt Engineering 第三篇筆記：釐清 token 與字數、上下文與輸出上限、對話歷史與記憶，以及如何提供足夠又相關的程式碼。
接著 Prompt Engineering 入門與 Temperature、Top P，這一篇整理 Frontend Masters《Practical Prompt Engineering》的 Token Limits 與 Context Windows。前一篇討論模型如何選下一個 token，這次關注的是：模型生成回答時，這一輪實際能參考哪些內容？
課程用 token 數量說明對話的容量，也帶到 system message 與程式碼上下文。這些概念很實用，但「一個 token 約等於 0.75 個單字」「超出上限一定會默默丟掉舊訊息」都需要加上條件。本文以官方文件補充差異，預算數字與程式情境都是自編示例，沒有實際呼叫模型或量測 tokenizer。
Token 是處理單位，不能直接當成字數
文字進入模型前，會先經過 tokenizer 切成 token，再對應成數字 ID。一個 token 可能是整個單字、單字的一部分，或標點等片段；切法取決於 tokenizer 的詞彙表與規則。Hugging Face 的 tokenization 說明
課程的 1 token ≈ 0.75 words 適合當作英文文字的粗估，不能直接套成「0.75 個中文字」。Google 的 Gemini token 文件也將估算明確寫成約 100 tokens 對應 60～80 個英文單字。
中文、程式碼、網址、空白與標點的組合，都不能只靠這個比例計算。即使文字相同，換 tokenizer 後，token 數也可能改變。要判斷請求能不能放進去，應使用目標模型適用的計數方式。
而且要算完整請求，不能只算剛輸入的問題。Anthropic 的 token counting 文件涵蓋 system prompt、工具定義與支援的附件輸入，並提醒結果仍是估算，部分輸入類型有支援限制。
Context window 與輸出上限，要分開預算
Context window 是一次生成可處理的上下文容量，包含輸入與生成內容。輸入可能已有指令、歷史訊息、文件和工具結果；這些都會使用容量。Context windows 文件
另外還要查模型的輸入與輸出限制。Google 的 token 文件將 inputTokenLimit 與 outputTokenLimit 分開列出；上下文還有空間，不表示單次輸出就能用完所有剩餘容量。
以下假設一個模型的 context window 是 16,000 tokens，單次輸出上限為 4,000 tokens。這不是任何真實模型的規格，數字也不是對下方文字做 tokenizer 計數的結果。
| 項目 | 假設占用的 tokens |
|---|---|
| 指令、工具定義與訊息封裝等開銷 | 1,000 |
| 保留的對話歷史 | 4,500 |
| 新問題 | 500 |
| 本輪加入的文件與工具結果 | 2,500 |
| 輸入合計 | 8,500 |
| 預留給這次生成 | 3,000 |
| 合計使用的預算 | 11,500 |
| 距離 16,000 的餘裕 | 4,500 |
在這個簡化模型裡，先檢查兩件事：
8,500 + 3,000 = 11,500 ≤ 16,000
3,000 ≤ 4,000若想生成 5,000 tokens，總和雖然只有 13,500，卻超過假設的單次輸出上限。反過來，14,000 tokens 的輸入加上 3,000 的生成預算，會達到 17,000；輸出額度本身合規，整段內容仍放不進視窗。
這是容量規劃，不能直接當成所有 API 的驗證公式。部分模型還有 reasoning tokens、工具或多模態的計數規則，要依文件另行納入；設定輸出上限也不表示模型一定會生成到那個長度。
對話能接著聊，靠的是提供歷史的機制
假設第一輪問：「請解釋 JavaScript closure。」第二輪接著問：「給我一個事件監聽的例子。」在一般無狀態的訊息 API 中，應用程式會把需要的前文一起提供：
第一輪：指令 + 問題 A → 回答 A
第二輪：指令 + 問題 A + 回答 A + 問題 B → 回答 B這是訊息組合示意，不是某家 API 的請求格式。Anthropic 的 Messages API 文件明確說明其無狀態特性，以及由呼叫端帶入對話歷史的做法。
有些服務也提供伺服器端的對話狀態，例如 Google 文件中的 previous_interaction_id。呼叫端未必每次重送所有文字，但仍有服務負責組合後續上下文；不能據此推論模型擁有無限記憶。Gemini Interactions API 文件
我會把「記得」拆成三個檢查問題：
| 要確認什麼？ | 可以檢查的證據 |
|---|---|
| 應用程式是否存著對話？ | 資料庫或對話紀錄 |
| 這一輪是否提供了某段資訊？ | 實際送出的訊息、摘要與檢索內容 |
| 模型是否正確使用資訊？ | 回答是否符合原文與任務要求 |
保存完整紀錄，只回答第一個問題。第二、第三個仍要分別驗證。
超出上限後，不只一種處理方式
「最舊的內容會默默消失」可以描述某些聊天產品的裁切策略，不能當成所有模型的共同規則。API 可能拒絕過長輸入，也可能在生成碰到上限時停止；實際行為依模型與端點而異。Anthropic 的 overflow 說明
應用端也可能主動管理內容：
| 處理方式 | 接下來要注意什麼？ |
|---|---|
| 裁掉部分舊訊息 | 被移除的限制或細節，需要時要重新補上 |
| 將舊對話換成摘要 | 核對摘要是否保留目標、決策與例外 |
| 需要時再檢索原始資料 | 確認有找回相關段落與版本 |
Compaction 是其中一種摘要機制。Anthropic 的 compaction 文件描述以摘要取代較舊對話，再讓後續請求使用它。摘要仍是後續上下文的一部分，不是額外的無限記憶層。
因此，遇到前文失效時，值得檢查實際歷史、摘要與停止原因。只從畫面上還看得到舊訊息，無法判斷後端採用了哪個策略。
System message 的持續性，由應用與服務管理
System message 可以設定角色、任務規則與回覆方式，也可以由應用開發者配置。它並非只能由模型供應商撰寫，或天生不能被開發者看見。例如 Anthropic API 的頂層 system 參數，就是呼叫端可提供的指令欄位。Create a Message
一個自編的指令可以是：
使用繁體中文說明。
先對照提供的程式碼；沒有證據時，列出需要確認的資訊。這類指令同樣占用輸入容量。至於不同角色的優先順序、後續請求如何保留指令，要看平台契約與應用實作。對無狀態 API 而言，應用端需要持續提供所需規則；「模型會永遠保留，絕不掉出視窗」不是通用保證。
甚至使用服務端歷史也要查清楚：Google 的 Interactions API 文件指出，previous_interaction_id 會保留對話歷史，system_instruction 等本輪參數仍需在後續請求重新指定。
程式碼上下文，要相關，也要足夠
課程提醒不要把整份 codebase 直接塞進提示。我會把它落實成先提供可定位問題的材料，再沿著依賴補齊。
例如，以下是自編的表單除錯情境，可以先準備：
- 問題：按下儲存後，畫面一直顯示送出中。
- 重現步驟、預期行為與實際錯誤。
- 相關表單元件、送出函式與 API client。
- 呼叫需要的型別、既有測試，以及這次修改範圍。
若線索指向共用狀態或後端回傳格式，再加入相關檔案。只剩一小段函式，卻缺少呼叫方式，也可能讓模型猜錯。目標是讓證據足以回答當前問題。
另外，「工具可以查整個 repository」不等於「每輪都把所有檔案全文送進 context window」。GitHub 的 Copilot repository indexing 文件描述用索引與語意搜尋找相關程式碼。因此，不能只看到 @codebase 這類名稱，就判定它一定把整份專案塞入提示；需要確認工具實際如何取用內容。
長任務可以準備一份可核對的上下文摘要
延續前面的表單情境，切換對話或整理上下文時，可以準備這樣的交接內容。檔名與狀態都是示意，不代表已做過實際除錯：
目標：修正儲存失敗後仍顯示送出中的問題。
限制：維持既有 API 契約；這次只處理表單狀態。
相關檔案：ProfileForm.tsx、profileApi.ts、ProfileForm.test.tsx。
已知證據：使用者提供的錯誤截圖；尚未確認失敗請求的回應內容。
目前決策：先重現，再檢查錯誤路徑是否還原 submitting。
下一步：讀取上述檔案與既有測試，確認後再修改。摘要要能回到來源核對，尤其要分清楚「已確認」和「待驗證」。若後續發現新證據，也要更新摘要，避免舊假設一直被當成前提。
即使內容都放得下，也還要檢查模型是否正確使用。2023 年的 Lost in the Middle在多文件問答與 key-value retrieval 實驗中，觀察到相關資訊的位置會影響表現。這是當時受測模型與任務的結果，不能直接推論所有目前模型都有相同程度的問題。
實際評估時，可以先固定一個任務與預期結果，比較完整相關資料、加入無關內容，以及摘要後的版本。記錄送入內容、token 計數、回答是否忠於證據與遺漏哪些限制，才能判斷上下文管理是否有效。本文尚未執行這組模型測試。
參考資料與查核範圍
- Sabrina Goldfarb，《Practical Prompt Engineering》投影片：第 6～7 頁的 token、context window 與 system message。
- 課程配套網站，Temperature, Top P, Tokens, and Context Windows。
- Hugging Face，Tokenization algorithms：文字切分與 tokenizer 差異。
- Google，Understand and count tokens、Interactions API：英文粗估、輸入與輸出上限、服務端歷史與本輪參數。
- Anthropic，Token counting、Context windows：完整請求的計數與超限行為。
- Anthropic，Using the Messages API、Create a Message、Compaction overview：歷史、指令與摘要的管理。
- GitHub，Indexing repositories for GitHub Copilot：索引與相關程式碼檢索。
- Liu 等人，Lost in the Middle: How Language Models Use Long Contexts：長上下文的研究範例。
資料於 2026-10-15 查閱。本文修正課程問答中的通用化說法；16,000／4,000 tokens 為假設規格，預算只經過算術核對。沒有實際 tokenizer 測量、模型品質 benchmark 或個人熟練度評量。