TokenToken

為什麼要有 token 這個單位

語言模型不是逐字閱讀的。它會先把文字切成一段一段的片段，再把每個片段轉成數字向量來處理。這些片段就叫 token。

切法不是按字，也不是按單字。以英文為例，unhappiness 可能被切成 un + happi + ness 三個 token；而常見的短詞像 the 就是一個完整的 token。這種切法叫做 subword tokenization，好處是既能處理沒看過的生字，又不會讓詞彙表大到失控。

中文的情況不太一樣。因為中文本身沒有空格分詞，多數模型的分詞器會把常見的字或詞組切成一個 token，罕見字則可能被拆成兩三個。所以一個中文字大約落在 1 到 2 個 token 之間。

Token 影響你的兩件事

一、費用

API 是按 token 計費的，而且輸入和輸出分開算。輸出通常貴上好幾倍——讀一段文字對模型來說相對輕鬆，一個字一個字生成才是真正花運算的地方。

這解釋了幾件實務上會遇到的事：

• 叫模型「把這份文件摘要成三句話」很便宜，因為輸出很短。
• 叫模型「把這三句話擴寫成一篇文章」貴得多，即使輸入短得多。
• 每次對話都把完整歷史重送一遍，是很多人帳單暴增卻搞不清楚原因的主因。

二、長度限制

模型一次能處理的 token 總量有上限，這個上限叫 context window。它涵蓋的是輸入加輸出的總和，不是只算你打的字。

所以當你貼了一份很長的文件進去，可用來生成回覆的空間就變少了。對話累積得夠久之後，最早的內容會被擠出視窗，模型就真的看不到了——這不是它「忘記」，而是那段文字已經不在它眼前。

常見誤解

「Token 就是字數」——不是。中英文的比例差很多，而且標點、換行、空格全都算 token。純粹用字數估算，在中英混雜的內容上會低估得相當離譜。

「Context window 越大就一定越好」——空間變大不代表模型會平均地注意每個部分。實務上，放在開頭和結尾的內容比較容易被用到，埋在中間的細節則常常被忽略。與其塞滿，不如只放真正相關的內容。