打錯字的隱形成本：人類打字習慣如何推高 Token 數量

在與大型語言模型 (LLMs) 互動時，大多數使用者都專注於提示工程 (prompt engineering) 的品質，以獲得最佳結果。然而，在模型處理文本含義之前，存在著一個隱藏的效率層面：Tokenization (分詞)。

Tokenizer 會根據其訓練數據中常見的模式將文本拆分為塊。由於供應商是按 Token 計費，我們自然的打字方式——包含打錯字、縮寫和對話填充詞——在不改變訊息意圖的情況下，會直接影響 API 調用的成本。對於任何正在優化自動化流程或高流量 LLM 使用量的人來說，理解人類打字習慣與 Tokenizer 邏輯之間的差距至關重要。

打錯字帶來的 Token 稅

人類為了速度和語氣而打字，這往往導致字母顛倒、字符缺失或按錯鄰近按鍵。雖然人類讀者（通常 LLM 本身也能）可以輕易推斷出預期的單字，但 Tokenizer 看到的卻是它無法識別的模式。

常見拼寫的單字通常會被壓縮成單個 Token。較罕見的拼寫，例如打錯字，則會碎裂成多個 Token。例如：

  • template $\rightarrow$ 1 token
  • tempalte $\rightarrow$ 3 tokens
  • assistant $\rightarrow$ 1 token
  • assitant $\rightarrow$ 2-3 tokens

在程式碼情境中，這種效應會加劇。一個出現在宣告、引用、日誌和 diff 中的拼寫錯誤變數或函數名稱，會顯著推高被餵入提示中的程式碼庫的 Token 數量。

單字形狀與字尾

單字末尾的微小變化可能導致 Token 數量不成比例地跳升。對人類來說看似無害的微小字尾，可能會導致 Tokenizer 將單字拆分為好幾個部分。

考慮以下範例：

  • describe $\rightarrow$ 1 token
  • describer $\rightarrow$ 2 tokens
  • describers $\rightarrow$ 3 tokens

這證明了 Tokenizer 對單字的特定「形狀」高度敏感，即使只增加幾個字母，也可能將單字從常見模式轉變為碎裂模式。

對話噪音的成本

人類的聊天內容自然充滿了低訊號的填充內容。雖然這些元素增加了語氣和禮貌，但它們很少對手頭的任務有所貢獻，且總是會增加帳單金額。

低訊號填充

  • 填充詞： 像 just、basically、actually 和 really 之類的單字。
  • 模糊詞： 像 maybe、I think、kind of 或 sort of 之類的短語。
  • 包裝詞： 禮貌性的開場與結尾，例如 hey、please、thanks 和 sorry。
  • 尾綴詞： 懸掛式的短語，例如 etc.、or so 和 and all that。
  • 聊天噪音： 表達性的標點符號和俚語，例如 lol、haha、...、!! 和 ??。

表達性習慣

即使是我們強調單字的方式也會增加成本。雖然 Good 是 1 token，但 Good... 會變成 2 個。同樣地，yes 是 1 token，但 yesss 可能會跳升到 3 個 tokens。

縮寫的悖論

人類通常為了減少按鍵次數而優化，認為較短的文本等於較低的成本。然而，Tokenizer 會針對「常見」文本進行優化，而非「短」文本。標準字典單字更有可能成為單個 Token，因為它們在訓練數據中出現頻率很高。

使用縮寫通常會導致比完整單字產生 更多 的 Token：

  • please $\rightarrow$ 1 token / pls $\rightarrow$ 2 tokens
  • thanks $\rightarrow$ 1 token / thx $ ightarrow$ 2 tokens
  • without $\rightarrow$ 1 token / w/o $\rightarrow$ 2-3 tokens

靜默 Token 洩漏

除了對話習慣之外，技術數據也經常產生「Token 洩漏」——本質上很長且破碎的字串。

  • 識別碼： UUIDs、雜湊值 (hashes) 和請求 ID (request IDs) 是出了名的昂貴。單個 UUID 可能耗費 24-26 個 tokens。
  • 時間戳記： 一個 RFC 3339 時間戳記（例如 2026-05-08T21:00:00+05:30）可能耗費 16-17 個 tokens。 單* 基礎設施： 長 URL 和文件路徑，以及不規則的開頭或結尾空格，也會進一步推高計數。

結論：效率與理智之間的權衡

這裡的核心矛盾在於，雖然模型可以從混亂的人類輸入中恢復含義，但計費系統卻不行。

正如社群討論中所提到的，對於手動提示 (manual prompts) 來說，這種程度的優化是否實用存在爭議。一位評論者指出，在即時聊天會話中檢查每一個打錯字來節省幾分錢，可能會「讓你自己發瘋」。然而，對於正在構建自動化流程、攝取大量文件或管理高流量代理工作流 (agentic workflows) 的開發者來說，這些「洩漏」已不再是微不足道的。它們代表了一種系統性低效，可以透過在數據到達 Tokenizer 之前進行清理來解決。

Sources