LLM 如何解讀文字：我的 i18n 系統教會我的 Token 經濟學

當我為網站建置 i18n 翻譯系統時，我發現將一篇1,500字的英文部落格文章翻譯成韓文，所消耗的 token 數量是英文原文的2.8倍。相同的語意內容、相同的意思，卻是2.8倍的 API 成本。日文是2.4倍，繁體中文是2.1倍，西班牙文是1.15倍。多語言內容的 token 經濟學讓我措手不及，因為我當時並不理解分詞器的運作原理。¹

TL;DR

分詞（Tokenization）是將人類可讀的文字轉換為語言模型處理的數值 token。在將27篇部落格文章翻譯成6種語言之後，我獲得了真實的成本數據：非拉丁文字每個語意單元消耗的 token 數量是英文的2至3倍。下方的互動式視覺化工具讓您可以貼上任何語言的文字，查看 token 的分解結果。理解分詞幫助我精確地編列翻譯管線的預算、優化提示詞以降低35%的成本，並除錯了一個格式問題——韓文翻譯遺失了 markdown 結構，因為分詞器將註腳標記跨 token 邊界拆分了。

我的 i18n Token 成本數據

我使用 Claude 將27篇部落格文章翻譯成6種語言。翻譯品質要求使用 Opus 等級的模型（絕不使用較便宜的模型——這是我在 Haiku 產出的翻譯讀起來像機器輸出後學到的教訓）。每種語言的 token 消耗量令我驚訝：

拉丁文字語言（西班牙文、德文、法文）維持在英文的20%範圍內。CJK 和韓文字母語言則跳升至2至3倍。這個成本差異在27篇文章 × 6種語言 = 162篇翻譯中不斷累積。²

差距存在的原因

大多數分詞器（BPE，Claude 和 GPT-4 皆採用）主要以英文文本進行訓練。英文單字擁有最佳化的 token 表示，因為訓練資料中的英文比任何其他語言都多。常見的英文單字（”the”、”and”、”is”）對應到單一 token。韓文音節塊、日文漢字和中文字元則經常被拆分為2至3個位元組層級的 token，因為分詞器在訓練過程中遇到它們的頻率較低。³

這個效應是系統性的，而非隨機的。每篇韓文翻譯的成本約為英文的2.8倍。我可以精確地編列預算，因為這個倍數是一致的。

分詞錯誤

在我第一批韓文翻譯中，翻譯後的文章遺失了所有 markdown 格式：註腳引用（[^1]）消失了、程式碼區塊遺失了語言標籤、標題標記（##）與正文融為一體。

診斷花了一個小時。根本原因是：我的翻譯提示詞只寫了「將這篇部落格文章翻譯成韓文」，卻沒有指定要保留格式。分詞器在韓文語境中將 markdown 語法跨 token 邊界拆分的方式與英文語境不同。模型將 [^1] 視為可翻譯的內容，而非結構性標記。

修正方式：我在翻譯提示詞中加入了明確的約束條件：

Preserve all markdown formatting exactly:
- Keep [^N] footnote references unchanged
- Keep ``` code fences with language tags unchanged
- Keep ## heading markers unchanged
- Keep **bold** and *italic* markers unchanged

每個約束條件消除了一種失敗模式。約束條件清單最終比翻譯指令本身還長——這是我在 OODA 提示詞工程框架中描述的模式。⁴

Token 是什麼

從字元到 Token

文字處理的樸素方法是將每個字元視為一個輸入單元。”Hello world”變成11個字元。字元層級的處理能捕捉每個細節，但會產生極長的序列：一份1,000字的文件大約變成5,000個字元。⁵

單字層級的處理縮短了序列長度，但無法處理未知的單字。一個包含50,000個條目的單字詞彙表無法處理”unfathomability”，除非這個確切的單字出現在訓練資料中。

子詞分詞找到了折衷方案。常見的單字（”the”、”and”）保持為單一 token。不常見的單字則拆分為子詞片段。”Unfathomability”拆分為[“un”, “fath”, “om”, “ability”]，其中每個片段出現的頻率足以擁有經過訓練的表示。

位元組對編碼（BPE）

BPE 被 Claude 和 GPT-4 採用，從個別位元組開始，反覆合併最頻繁的相鄰對：⁶

1. 從個別字元開始：[l, o, w, e, r]
2. 最頻繁的配對：(l, o) → 合併為 [lo, w, e, r]
3. 最頻繁的配對：(e, r) → 合併為 [lo, w, er]
4. 最頻繁的配對：(lo, w) → 合併為 [low, er]
5. 最頻繁的配對：(low, er) → 合併為 [lower]

最終的詞彙表包含所有原始位元組加上每個合併的 token，通常有50,000至100,000個條目。英文單字在合併的 token 中佔主導地位，因為英文在訓練資料中佔主導地位。

我如何優化提示詞

發現 token 成本差距後，我優化了翻譯管線，降低了35%的成本：

優化1：按語系批次處理

拉丁文字語言（西班牙文、法文、德文）具有結構上的相似性。當原文篇幅短到足以與三個輸出一起放入上下文視窗時，我將翻譯提示詞批次處理，在單次 API 呼叫中產出全部三種語言。共享的上下文（英文原文）只需支付一次，而非三次。⁷

優化2：約束條件去重複

我原始的翻譯提示詞對每種語言重複了約束條件。優化後的版本定義一次約束條件，並套用於所有輸出：

# Constraints (apply to ALL translations below):
- Preserve markdown structure, footnotes, code blocks
- Keep proper nouns in English
- Adapt idioms, don't transliterate

# Translate the following post into: Spanish, French, German

約束條件部分只消耗一次 token。替代方案（每種語言重複約束條件）則消耗3倍。

優化3：精簡指令

我原始的提示詞使用了340個 token 的指令。優化後：180個 token。47%的縮減在162篇翻譯中不斷累積。

CJK 語言從提示詞優化中受益較少，因為輸出 token（翻譯本身）佔據了主要成本。無論指令多精簡，輸出在 token 層面本質上就是更長的。⁸

實際應用

估算成本

英文文字的粗略經驗法則：1個 token 大約等於0.75個單字，或大約4個字元。一份1,000字的文件大約消耗1,333個 token。對於非英文內容，套用上方表格中的語言倍數即可。⁹

程式碼分詞

程式碼的分詞方式與散文不同。常見的關鍵字（def、return、if）對應到單一 token。變數名稱則根據頻率進行拆分：

# "def calculate_total(items):" splits approximately as:
# ["def", " calculate", "_total", "(", "items", "):", ]

一致的命名慣例可以減少 token 數量。我的 hook 基礎架構使用 verb-noun.sh 慣例（git-safety-guardian、recursion-guard、blog-quality-gate）。一致的模式幫助分詞器有效地預測和合併常見的子詞。

除錯非預期行為

當模型產出非預期的輸出時，分詞可以解釋原因。我的韓文格式錯誤之所以發生，是因為分詞器在韓文語境中拆分 [^1] 的方式與英文不同。理解拆分模式直接引導出了修正方法（明確的保留約束條件）。

重點摘要

給使用 LLM API 的工程師： - 在承諾多語言支援之前，先測量每種語言的 token 成本；CJK 語言每個語意單元的成本比英文高出2至3倍 - 優化提示詞指令（精簡用詞、去重複約束條件）可在大量翻譯管線中降低30-50%的成本 - 在正式部署前測試領域專用術語和 markdown 語法的分詞；非預期的拆分會導致格式錯誤

給編列 AI 功能預算的產品經理： - 非英語的語言支援每次 API 呼叫的成本比英文高出1.5至3倍；使用語言倍數編列多語言 AI 功能的預算，而非固定的按語言估算 - 上下文視窗限制對 CJK 語言的影響不成比例；一個200K token 的視窗所能容納的韓文內容比英文少40%

參考資料