AI · AI 基礎
AI 的 token 與上下文視窗是什麼?
簡答
token 是語言模型讀取與輸出的文字單位,可能是一個完整的短字、較長單字的一部分、一個標點符號,或幾個字元。上下文視窗(context window)則是模型一次能處理的 token 上限,你的指令、聊天紀錄、附加檔案,以及它要寫的回答,全都算在內。超過上限,較舊的內容會被捨棄,或是請求直接失敗。
token 長什麼樣子
語言模型讀的不是字母,也不是完整的單字。斷詞器(tokenizer)會先依固定詞表把文字切成片段,每個片段對應一個數字,模型看到的永遠只有這些數字。
以下例子用 OpenAI 的開源斷詞器函式庫 tiktoken,採用 o200k_base 編碼計算。其他模型使用不同的斷詞器,數字會有出入,但規律相近。
| 文字 | token 數 | 切分方式 |
|---|---|---|
| The cat sat on the mat. | 7 | The | cat | sat | on | the | mat | . |
| Tokenization is surprisingly unintuitive. | 7 | Token | ization | is | surprisingly | unint | uitive | . |
| unbelievable | 3 | un | bel | ievable |
| strawberry | 3 | st | raw | berry |
| 2026-11-02 | 6 | 202 | 6 | - | 11 | - | 02 |
| ChatGPT | 2 | Chat | GPT |
| 我喜欢吃苹果。 | 5 | 我 | 喜欢 | 吃 | 苹果 | 。 |
常見的字通常自己就是一個 token,前面的空格也包含在內;罕見或較長的字則會被拆成幾塊。數字和日期的切法與它們的意義無關,這也是模型算術容易出錯的原因之一。而 strawberry 被切成三塊後,模型根本看不到裡面到底有幾個字母 r。
為什麼模型使用子詞 token
如果詞表只收完整的單字,會龐大無比,而且還是漏掉新詞、人名和錯字。如果詞表只收單一字元,每段文字又會變得非常長。子詞(subword)token 就是折衷的做法。
現在多數斷詞器採用位元組對編碼(byte pair encoding,BPE)或類似的方法:從單一位元組或字元開始,反覆把訓練文字中最常一起出現的一對合併成新的 token。經過許多輪合併後,常見的字會變成單一 token,罕見的字也仍然能由較小的片段拼出來,所以不會有詞表之外的字。
每個模型系列都會訓練自己的斷詞器,同一句話在不同模型的 token 數也不同。token 數適合拿來估算與抓預算,卻不是通用的單位。
不同語言的同一句話
斷詞器主要依據訓練資料中最常見的語言來訓練。資料較少、或文字系統不同的語言,表達相同意思往往需要更多 token。下面用同一句指令 Please summarize this article in three bullet points,翻成各語言後,分別以較舊的 cl100k_base 和較新的 o200k_base 斷詞器計算:
| 語言 | 字元數 | token 數(cl100k_base) | token 數(o200k_base) |
|---|---|---|---|
| 英文 | 53 | 9 | 9 |
| 西班牙文 | 36 | 7 | 7 |
| 簡體中文 | 13 | 13 | 10 |
| 日文 | 20 | 15 | 12 |
| 韓文 | 24 | 19 | 13 |
| 越南文 | 42 | 21 | 14 |
有兩點值得注意。詞表更大的新斷詞器,處理中文、日文、韓文和越南文的效率高出許多。即使如此,在這個例子中,這些語言表達同一個意思用到的 token 還是比英文多。由於 API 價格和上下文長度上限都以 token 計算,同一項任務在某些語言中可能花費更多,視窗也會更快被填滿。
上下文視窗是什麼
上下文視窗是模型處理單次請求時的工作記憶,和模型在訓練中學到的知識是兩回事。模型寫出答案所能用到的一切內容,都必須放得進視窗,連答案本身也要算進去。
在聊天應用程式裡,每則新訊息都會連同先前的對話一起送出,所以視窗會隨著對話變長而逐漸填滿。一般請求中,下列幾個部分都會計入:
- 系統提示詞,也就是應用程式或開發者設定的隱藏指令。
- 對話中之前每一則使用者訊息與助理回覆。
- 附加的文件、貼上的文字、圖片,以及擷取出來的文字。
- 工具定義與工具回傳的結果,例如網路搜尋結果。
- 新產生的回答,包括模型在回答前寫下的隱藏推理(思考)token。
各模型的視窗大小差異很大,也經常變動:撰文當下,小型本機模型只有數千個 token,一些大型雲端模型則達到一百萬個以上。請查閱你使用的模型的文件。
視窗滿了會怎麼樣
不同產品處理上限的方式不同:
| 情況 | 通常會發生什麼 | 你會看到什麼 |
|---|---|---|
| API 請求超過視窗大小 | 請求被拒絕並回傳錯誤 | 提示詞過長的錯誤訊息 |
| 回答達到輸出上限 | 生成提早停止 | 回覆在句子或清單中間斷掉 |
| 應用程式中的長對話 | 最舊的幾輪被捨棄,或換成摘要 | 助理忘記對話一開始的細節 |
| 超長但仍放得下的上下文 | 模型保留全部內容,但利用得比較差 | 長篇輸入中段的事實被漏掉 |
最後一列在日常使用中最重要。研究顯示,模型對長篇輸入開頭和結尾的資訊,往往比中段的資訊利用得更好。模型供應商也提醒,token 數越多,準確度與召回率可能下降。視窗大代表你能放入更多內容,但不保證模型會把這些內容都好好用上。
如何估算與節省 token
- 先估算。英文把字數乘以約 1.3;中文或日文則數字元,新斷詞器大約每個字元一個 token,或略少一點。字數統計工具,例如 cv.cm 的字數計算工具,可以快速給你字數與字元數。
- 需要精確時再實際計算。使用你所呼叫模型的斷詞器或 token 計數端點,因為不同模型的數字不同。
- 只送出需要的內容。貼上文件的相關段落,而不是整份檔案;刪除重複的頁首、頁尾與制式內容。
- 把關鍵指令放在長提示詞的開頭或結尾,不要埋在中間。
- 換主題就開新對話。舊訊息仍會佔用空間,也可能干擾模型。
- 為回答留出空間。如果輸入幾乎塞滿視窗,回覆就會很短,或被截斷。
- 長任務可以請模型整理目前為止的決定,再帶著這份摘要到新的對話繼續。
常見的錯誤
- 把 token 當成字數。1,000 字的文件不等於 1,000 個 token,在許多語言中會多出不少。
- 以為模型把全部內容都讀進去了。即使在視窗之內,長篇輸入中段的細節也可能被忽略。可以請模型引用它所依據的段落。
- 期待跨對話的記憶。除非應用程式放入儲存的筆記,否則新對話的視窗是空的。
- 忘了隱藏的內容。系統提示詞、工具定義與推理 token 都會佔用視窗,只是你看不到。
- 直接比較不同模型的上限。因為斷詞器不同,一個模型和另一個模型的 100,000 token 上限,能容納的文字量並不相同。
常見問題
1,000 個英文單字是多少 token?
一般英文散文搭配常見的新式斷詞器,約 1,200 到 1,300 個 token。程式碼、數字、網址與許多非英語語言需要的更多。
空格和標點符號也算 token 嗎?
算。標點符號通常自成一個 token,單一空格一般會併入後面那個字的開頭。多餘的空格、換行和縮排,也會增加 token。
圖片也會用掉 token 嗎?
會。支援圖片輸入的模型會把每張圖轉換成一定數量的 token,計入上下文視窗。圖片越大、越精細,通常用掉越多,確切規則依模型而定。
為什麼 ChatGPT 或其他聊天機器人會忘記我先前說的話?
在長對話中,應用程式為了讓內容留在上下文視窗內,可能捨棄或摘要舊訊息。即使舊訊息還在,模型對它們的注意力也可能較弱。重複關鍵事實,或帶著簡短摘要開新對話,都有幫助。
上下文視窗越大一定越好嗎?
不一定。視窗大讓你能放入更多資料,但費用更高,模型也可能變慢、細節更不精確。送出較短而精挑細選的上下文,往往能得到更好的答案。