概念位置

Unigram 是 subword tokenizer 家族的一員，常由 SentencePiece 支援。它跟 BPE 的差異在訓練與切分策略：BPE 是貪婪合併，unigram 是機率選擇與剪枝候選。

可觀察訊號與例子

讀 tokenizer 文件看到「unigram language model」「subword regularization」「SentencePiece unigram」就是這個概念。它可在訓練時對同一句話採不同合理切分，增加 tokenizer 層的資料多樣性。

設計責任

一般應用不會手動選 unigram tokenizer，但理解它能幫助比較模型的多語言支援與 token 效率。判讀時搭配 Vocabulary Size 與 Token。

概念位置

WordPiece 屬於 subword tokenizer 家族，BERT 系列是代表。BPE 偏向合併高頻相鄰片段；WordPiece 偏向選擇能最大化語言模型 likelihood 的片段；SentencePiece 則是 tokenizer framework，可支援 BPE 或 unigram。

可觀察訊號與例子

看到 ##ing、##ed 這類 continuation marker，通常是 WordPiece 風格 vocabulary。它讓模型能處理未見過的詞，因為陌生詞仍可拆成已知 subword。

設計責任

比較 tokenizer 時，WordPiece 主要作為 BERT/encoder 系統的背景知識。寫 LLM 推論與本地 serving 時更常遇到 BPE、SentencePiece、vocab size 與 special tokens。

概念位置

BPE 訓練 tokenizer 的流程（簡化）：

1Step 0：vocab = 所有單一字元（256 個 byte / Unicode 字符）
2
3迭代：
4  Step 1：掃描 corpus、統計所有相鄰 token 對的出現頻率
5  Step 2：找出現最多的字元對（如 "l" + "o" 一起出現 1M 次）
6  Step 3：把它當新 token 加進 vocab、把 corpus 裡所有這個對換成新 token
7  Step 4：回到 Step 1、直到 vocab 達到目標大小（如 50K、128K、256K）

實際 token 化的結果：

BPE 的變體：

1. Byte-level BPE：把每個 byte 當基底（256 個）、所以任何 Unicode / 二進制都能 tokenize、不會有 unknown token。GPT-2 開始的標準。
2. SentencePiece BPE：跟 SentencePiece 框架結合、處理多語言更靈活。

設計責任

讀 model card 看到 tokenizer: BPE 就是這個演算法。BPE 對英文友好（高頻單詞整個一 token）、中文 / 日韓較不友好（單字符常被當獨立 token）；這就是為什麼同一段中文翻譯成英文後、英文 token 數常常更少、雲端 LLM 用中文 API 比英文貴。但越新的模型（Gemma 4、Qwen3 等）vocab 越大（256K+）、對中文友善度提升中。

概念位置

SentencePiece 跟其他 tokenization 路線的對比：

關鍵特性：

1. ▁ 表示空白：SentencePiece 把空白編碼成 ▁（Unicode U+2581）、所以「Hello world」會被 tokenize 成 ["Hello", "▁world"]、保留空白資訊在 token 內。
2. 不依賴語言預處理：傳統 NLP 要先做 lowercasing、word segmentation；SentencePiece 直接從 raw bytes 開始學、跨語言通用。
3. 原生 multilingual：訓練 corpus 包含多語言時、tokenizer 自動學會跨語言的子詞單元、不需要為每種語言設定不同 tokenizer。

設計責任

讀 model card / repo 看到 tokenizer.model 檔案（不是 tokenizer.json 或 vocab.txt）就是 SentencePiece 用的 protobuf 格式。寫 code 場景的意涵：SentencePiece tokenizer 在中文 / 多語言任務上比 WordPiece 友好；換 tokenizer 等於整個 embedding layer 失效、所以 fine-tune 時不會動 tokenizer。

概念位置

LLM 中 special tokens 的常見類型：

關鍵特性：

1. 訓練時用特殊 token ID 標記：模型透過大量範例學會「看到 <\|user\|> 後面是使用者輸入、看到 <\|assistant\|> 後面要生成回答」。
2. Chat template 把這些組合起來：把使用者輸入 + 系統 prompt + 對話歷史依特定格式插入這些 token、組成模型訓練時看過的格式。
3. <eos> 的 sampling 行為：模型輸出 <eos> 後、推論伺服器停止生成、所以「為什麼回答突然停了」很多時候就是模型決定發 EOS。

設計責任

讀 tokenizer config（tokenizer_config.json）看到 bos_token、eos_token、chat_template 等就是這組設定。寫 code 場景的判讀：用 Continue.dev / Ollama 時、伺服器會自動套用模型的 chat template、把使用者輸入轉成正確的 special tokens 格式；自己寫 inference code 時、要呼叫 tokenizer.apply_chat_template() 避免格式錯亂導致模型輸出爛。

概念位置

主流 LLM 的 vocab size 演化：

Vocabulary size 的取捨：

範例：同段中文「你好、世界」、Llama 1 (vocab 32K) 約 6 token、Gemma 4 (vocab 256K) 約 2-3 token、差距不小。

設計責任

讀 model card 看到 vocab_size 就是這個值。寫 code 場景的判讀：跑同個 prompt、不同模型實際處理的 token 數差很多、影響 context window 利用率跟雲端 API 計費；換 tokenizer = 換 vocab = 整個 embedding layer 失效、所以 fine-tune 通常不動 tokenizer、想增加新語言的最簡單方式是 extend embedding（加新 row 不動既有 row、再 fine-tune）。

本章拆開四個主流 tokenization 算法（BPE、WordPiece、Unigram、SentencePiece）、解釋 vocabulary 怎麼學出來、為什麼中文 / 中日韓字幾乎一字一 token、tokenizer 為什麼影響 speculative decoding 的相容性。

本章目標

讀完本章後、你應該能：

1. 解釋 BPE（Byte-Pair Encoding）的工作原理。
2. 看到不同 model 切同段文字得到不同 token 數時、知道原因。
3. 解釋為什麼 drafter 跟 target 必須共用 tokenizer。
4. 看到 vocab_size = 256,000 vs 128,256 時、知道差異在哪。

Tokenization 的設計目標

理想 tokenizer 要同時滿足：

1. 覆蓋率高：能 encode 任何文字、不會「碰到沒見過的字壞掉」。
2. 效率高：常見字串切成少數 token、節省 context 與計算。
3. 語意保留：保留有意義的 sub-word 邊界（「unhappy」切成 un + happy 比 unh + appy 好）。
4. 跨語言公平：英文跟中文 / 日文 / 阿拉伯文等都用合理數量的 token。

不同算法在這四個目標上有不同取捨。

早期方法：word-level 跟 char-level

Word-level Tokenization

最簡單的方法是「用空白跟標點切」、每個 word 一個 token。

優點：直觀。

缺點：

1. Vocabulary 爆炸：英文有幾百萬個 word forms（含複數、時態、複合詞等）。
2. OOV（out-of-vocabulary）：新詞、typo、URL、混合語言完全壞掉。
3. 中文 / 日文沒有空白：要先做 word segmentation。

現代 LLM 已淘汰 word-level、主流改用 subword 系列。

Char-level Tokenization

另一個極端是「每個 character 一個 token」。

優點：vocabulary 小、無 OOV。

缺點：序列變很長（一句話幾十到幾百 char、效率低）、模型要從很基礎學起、訓練不效率。

現代 LLM 也跳過純 char-level、改用 subword 折衷。

折衷：Subword Tokenization

主流方案是「subword tokenization」：常見字串當一個 token、罕見字串切成更小單位（甚至到 char 級別）。三個主流算法：

Vocabulary size 跟 special tokens 是這幾個算法產出的 tokenizer 共同的概念維度。

BPE：Byte-Pair Encoding

BPE（Sennrich et al., 2016）的核心想法是「貪婪地合併最常出現的字元對」、迭代到 vocabulary 達到目標大小。

訓練流程

1. 初始 vocabulary：所有 character。
2. 統計訓練語料中、所有相鄰 character pair 的頻率。
3. 把頻率最高的 pair 合併成一個新 token、加進 vocabulary。
4. 用新 vocabulary 重新 tokenize 語料、重複 step 2-3。
5. 直到 vocabulary 達到目標大小（如 50,000、100,000）。

例：

1初始：l o w e r → 5 個 token
2步驟 1：合併 'l' + 'o' = 'lo'、變成 lo w e r → 4 個 token
3步驟 2：合併 'lo' + 'w' = 'low'、變成 low e r → 3 個 token
4步驟 3：合併 'e' + 'r' = 'er'、變成 low er → 2 個 token

訓練後、lower 就是 2 個 token。

Byte-level BPE

原始 BPE 在 character level 運作、但「character」依語言而異（Unicode 字元複雜）。Byte-level BPE 在 byte level 運作、任何文字都可以 encode 成 byte 序列、自然支援多語言。

GPT-2 / GPT-3 / GPT-4 / Llama 系列都用 byte-level BPE。

Tiktoken：OpenAI 的高效實作

Tiktoken 是 OpenAI 開源的 BPE 高效實作、Python 套件。可以拿來算「這段文字在 GPT-4 上是多少 token」：

1import tiktoken
2enc = tiktoken.encoding_for_model("gpt-4")
3tokens = enc.encode("Hello, world!")
4print(len(tokens))   # 4

Tiktoken 是估算 OpenAI API 費用的標準工具。其他模型有各自的 tokenizer 套件（Llama 的 sentencepiece、Hugging Face 的 transformers.AutoTokenizer）。

WordPiece：BERT 的選擇

WordPiece（Schuster & Nakajima, 2012、後來 Google 用在 BERT）跟 BPE 類似、但合併策略不同：

• BPE：合併「最頻繁出現的 pair」。
• WordPiece：合併「合併後 likelihood 最大化的 pair」（更貴的計算、但理論上更好）。

實務差異微小。BERT 系列用 WordPiece、現代 LLM 大多回到 BPE 系列。

Unigram：機率式 subword

Unigram（Kudo, 2018）是另一條主流 subword 算法、跟 BPE 的「greedy 從下往上合併」相反、它從一個很大的 candidate vocabulary 開始、用機率模型逐步刪掉 likelihood 貢獻最小的 token：

1. 起點：一個包含大量 candidate subword 的初始 vocab（可從訓練資料抓所有 substring）。
2. 用 EM 算法估每個 candidate 的機率、把整段文字 tokenize 成 likelihood 最大的 segmentation。
3. 評估「刪掉某個 candidate 後 total likelihood 損失多少」、刪掉損失最小的一批。
4. 重複到 vocab 達目標大小。

跟 BPE 的本質差異：

• BPE：每個輸入文字只有一個切法（merge 規則決定）、結果是 deterministic。
• Unigram：每個輸入可能對應多個合法 segmentation、訓練時用機率挑、推論時取 top-1。這個性質讓 Unigram 天然支援 subword regularization（訓練時隨機取不同 segmentation、增強 robustness）。

Unigram 是 SentencePiece 預設算法、T5、Gemma 系列訓練時用。實務上 Unigram 跟 BPE 的最終 tokenization 接近、選擇看「訓練時要不要做 subword regularization」。

SentencePiece：Google 的開源實作

SentencePiece（Kudo & Richardson, 2018）是 Google 開源的 tokenization 套件、可實作 BPE 或 Unigram 算法、設計上：

• 語言無關：把輸入當 byte 流處理、不假設「word boundary 是空白」。
• 無前處理：不用先切 word、適合中文 / 日文等無空白語言。
• 可逆：tokenize → detokenize 完全還原原文。

Gemma 系列、PaLM、T5 用 SentencePiece。實務上跟 BPE 表現接近、差異主要在「對中日韓文等無空白語言更友善」。

Vocabulary 大小

各 LLM 的 vocabulary 大小：

Vocabulary 大小的取捨：

Gemma 4 的 256K vocab 是現代 LLM 中較大的、目的之一是多語言支援。

同段文字在不同 tokenizer 上的差異

實測「The quick brown fox jumps over the lazy dog」：

差異不大。但中文「敏捷的棕色狐狸跳過懶狗」：

Llama 2 的 32K vocab 對中文支援差、Llama 3 / Gemma 4 改善很多。實務影響：中文 prompt 在 Llama 2 上吃 context 多、Gemma 4 較友善。

Tokenizer 跟模型相容性

Speculative decoding 要 target 跟 drafter 共用 tokenizer、因為兩者必須對「下個 token」的概念一致：

• Gemma 4 31B + Gemma 4 E4B：同 tokenizer、可以配對。
• Gemma 4 + Llama：不同 tokenizer、配不起來。

理解這點、能解釋為什麼 LM Studio 的 draft model UI 自動過濾相容候選、為什麼 Ollama 的 gemma4:31b-coding-mtp-bf16 model tag 內含 drafter 而不能自己組合不同家族。

Special Tokens

除了 vocabulary 中的「正常」token、還有特殊 token：

• <BOS> / <bos>：Beginning of sequence、prompt 起點。
• <EOS> / <eos>：End of sequence、生成結束。
• <PAD>：Padding、batch 訓練時補齊長度。
• <UNK>：Unknown token（現代 BPE 少用、因為 byte-level 覆蓋所有字元）。
• <|im_start|> / <|im_end|>：ChatML 格式中區隔每段訊息的邊界 token。
• ChatML 中的 role 名稱（system / user / assistant）寫在 <|im_start|> 之後當作文字內容、不是獨立 token；模型靠「<|im_start|> + 後接 role 字串」這個 pattern 識別說話者。

聊天 LLM 的 prompt 實際長相是用 special tokens 標記 role 跟訊息邊界，而非純文字：

1<|im_start|>system
2You are a helpful assistant.<|im_end|>
3<|im_start|>user
4Hello!<|im_end|>
5<|im_start|>assistant

不同模型的 chat template 不同、Ollama / Continue.dev 等工具自動處理、但若自己呼叫 API 要注意 template 對不對。

Tokenization 引發的 bug

Tokenizer 設計的副作用：

Glitch Tokens

某些 token 在訓練資料中很少出現、模型對它們的行為怪異。Reddit 上著名的 SolidGoldMagikarp 就是 GPT-2 / GPT-3 的 glitch token、模型遇到會出現奇怪反應。原因：tokenizer 學了這個 token、但訓練資料中幾乎沒上下文、模型沒學到它的語意。

數字 tokenization

早期 BPE 對數字的處理不一致：1234 可能切成 123 + 4、1235 可能切成 12 + 35。模型對「數字加法」表現差跟這個有關。

現代 LLM 多半把每個 digit 各自當一個 token（一致 tokenization）、改善數學能力。

Code 的 indentation

寫 code 場景的 tokenizer 要妥善處理 indentation。早期 LLM 把多個空白合併成一個 token、code 結構壞掉；現代 LLM（特別是 coding-specialized）把 4 空白 / 8 空白等常見 indentation 各自當一個 token。

跟 context window 的關係

Context window 的單位是 token、不是字。1M token 的 context window 在英文約等於 750K 字、在中文約 1M 字（看 tokenizer）。

實務啟示：

• 「128K context」在不同 tokenizer 上實際容量不同。
• 計算 API 費用要用該模型的 tokenizer 算 token 數。
• 中文 prompt 用 Llama 2 比 Llama 3 / Gemma 4 吃 context 多。

下一章

下一章：3.7 想學更深：推薦公開課程。

本章寫的是「跨語言能力為什麼這樣分佈」「該如何依場景選語言」的原理層。具體模型在 2026/5 的中文 / 多語言 benchmark 不在本章——這些隨新模型版本變、用本章的雙因素 framework 重新評估就好。

本章目標

讀完本章後、你應該能：

1. 解釋為什麼模型在不同語言上表現不一致、有哪兩個獨立因素。
2. 看到 tokenizer 對中文「一字切 N token」時、知道對 context cost 跟能力的影響。
3. 判讀「該翻英寫 prompt 還是維持中文」的取捨。
4. 解釋為什麼跨語言 reasoning 比 monolingual reasoning 容易失敗。

為什麼模型對不同語言表現不一致：雙因素

模型對不同語言的表現受兩個獨立因素疊加影響：

因素 1：Tokenizer Vocab Coverage

Tokenizer 把文字切成 token、tokenizer vocab 大小指 tokenizer 認識的 token 種類數（vocab 越大、能切得越細、越能用單一 token 表達常見字）。不同 tokenizer 對不同語言的切割密度不同：

• 英文中心的 tokenizer（如 Llama 2 的 32K vocab）對 vocab 沒涵蓋的中文字會 fallback 到 byte 級切割（UTF-8 一個中文字常用 3 個 byte、所以變 3 個 token）。
• 多語言 tokenizer（如 Gemma 4 的 256K vocab）把常見中文字當獨立 token 收進來、對中文多半一字一 token、跟英文接近。

完整的 BPE / WordPiece / Unigram / SentencePiece 算法見 3.6 tokenization 算法。

Tokenizer 影響三件事：

• Context 成本：同樣 prompt 在不同 tokenizer 上吃 token 量級不同、API 費用、context window 利用率都跟著差。
• Token 粒度：粗粒度 tokenizer 對某語言的「字」切割不細、影響模型對該語言細微差異的辨識。
• 訓練效率：tokenizer 切得好、模型每個 token 學到更多語意、訓練收斂快。

因素 2：訓練資料分佈

模型預訓練資料的語言佔比決定模型「學了多少」這個語言：

• Common Crawl 等主流預訓練資料英文佔 70%+、中文約 1-3%、其他語言更少。
• 即使 tokenizer 對某語言支援好、訓練資料少仍會限制模型在該語言上的能力。

訓練分佈影響三件事：

• 事實準確度：訓練資料少 → 該語言的事實覆蓋低 → hallucination 多。
• Reasoning 深度：複雜推理需要大量該語言範例支撐、訓練少就退化。
• 風格自然度：訓練少的語言、模型輸出語法 OK 但 idiom / 慣用搭配偏直譯。

雙因素的獨立性

兩個因素獨立、各自影響不同維度：

判讀模型某語言能力時、兩個因素都要評估、單看一個會誤判。「Gemma 4 vocab 對中文好」不代表「中文表現一定好」、還要看訓練資料佔比。「OpenAI 訓練資料量大」不代表「對所有語言都好」、還要看 tokenizer 設計。

Tokenizer Vocab 對非英文的影響

Tokenizer vocab 設計直接決定中文 context 成本量級、差距可達兩倍以上。具體看 tokenizer 對中文的影響（以下為各 tokenizer 對該句的近似切割、實測會 ±20%、用作量級對照、不含 system prompt / response budget）：

數字差異看似不大、累積起來影響顯著：

• 128K context 的「實際容量」：以中文每字平均 token 數估算、Llama 2（約 2.2 字 / token 的反比、即一字 ≈ 2-3 token）對中文約 6K 中文字、Gemma 4（接近一字一 token）對中文約 14K 中文字、差兩倍以上（估算未含 system prompt + response budget、實際可用更少）。
• API 費用：同樣中文 prompt、Llama 2 費用是 Gemma 4 的兩倍以上（按 token 收費的話）。
• 長 prompt 的 prefill 時間：token 多 prefill 慢、TTFT 受影響。

但這只是其中一個因素。Tokenizer 改進不會自動讓模型「懂」這個語言——還要訓練資料配合。Llama 3 vocab 比 Llama 2 大很多、但對中文表現的提升不只是 vocab 帶來的、也是訓練資料多語言比例提升的結果。

訓練資料分佈：語言佔比決定能力

Web 文字的語言分佈嚴重不平衡。Common Crawl 跟同類資料源的語言佔比約：

• 英文：60-70%
• 中文：2-5%
• 西班牙文、葡萄牙文、日文、法文、德文：各 1-3%
• 其他幾百種語言：合計 < 10%

模型預訓練多半反映這個分佈。即使「主打多語言」的模型、英文仍是主導。

實務影響：

• 事實準確度：問模型「台灣某縣市的人口」這類本地化問題、中文回答的準確度通常低於英文回答同個問題（即使翻譯為相同 query）。
• Reasoning 深度：複雜中文推理（如解中文奧數題）、模型可能「翻譯成英文 reasoning、再翻回中文」、中間步驟跳過、答案合理但推理鏈不通。
• 風格 / 慣用語：中文輸出可能語法 OK、但 idiom 與慣用搭配偏直譯、詞彙選擇偏「翻譯腔」。
• 長尾事實：訓練資料少的語言、長尾事實更容易 hallucinate。

判讀模型在某語言上的能力強弱、看訓練資料佔比是主要訊號。Qwen 系列訓練資料大量中文、中文能力強；Llama 系列訓練資料英文為主、即使最新版中文表現仍弱於 Qwen 在中文上的表現。

兩因素的獨立性對實務的影響

雙因素獨立、實際模型多半落在某個組合狀態：

Gemma 4 / Qwen3 / Llama 3 主流開源旗艦：

• Tokenizer：多語言、vocab 256K 級、中文 token 效率接近英文。
• 訓練資料：中英都有大量比例、Qwen 中文比例高、Llama 英文比例高。
• 結果：中文能力接近 native level、跨語言能力差距縮小。

OpenAI / Anthropic 雲端旗艦：

• Tokenizer：tiktoken 等、中文 token 效率中等。
• 訓練資料：規模極大、所有語言絕對量都多（即使相對佔比低）。
• 結果：中英都強、絕對能力受訓練規模支撐。

早期 Llama 2 / 純英文模型：

• Tokenizer：32K 英文中心、中文切散。
• 訓練資料：英文主導、其他語言極少。
• 結果：中文勉強可讀、不建議用於對輸出品質有要求的工作場景。

判讀新模型對某語言能力時、先看這兩個因素、再參考實測——比直接看 benchmark 數字準。

中文 Prompt 何時該翻英：機會成本判讀

寫 code 場景常見問題「該用中文還是英文寫 prompt」、答案取決於三個變數：

變數 1：模型在中英的能力差距

主流開源旗艦（Gemma 4 / Qwen3 / Llama 3）中英差距已縮小、寫 code 場景中英 prompt 表現接近。早期 / 較小模型差距大、英文 prompt 較穩。

判讀：用較強模型可以維持中文、用較弱模型考慮翻英。

變數 2：翻譯成本

翻譯成本包括：時間、認知負擔、可能的精度損失。

• 簡短 prompt（補完、寫單個 function）：翻英成本低、可考慮。
• 長 prompt（描述複雜需求、多個檔案 context）：翻英成本高、維持中文較划算。
• 含技術術語的 prompt：英文是 LLM 訓練的主流、術語維持英文較好（即使句子是中文也保留英文 keyword）。

變數 3：輸出語言要求

• 要中文回答（如寫中文 docs、跟中文團隊溝通）：維持中文 prompt 一致性較好。
• 要英文回答（如 commit message、open source PR）：英文 prompt 自然引導英文輸出、不需 explicit instruct。

綜合判讀

寫 code 場景的多數情境（主流模型 + 短 prompt + 維持原語言輸出）：直接用中文寫即可、不必特別翻英。例外：

• 用較弱模型（< 14B）、英文較穩。
• 特殊領域（法律、醫療、學術）、英文資料豐富、翻英可能更穩。
• Domain-specific reasoning（數學、邏輯）、英文訓練資料多、翻英可能改善 reasoning 鏈。

「直覺說該翻英」常是過度小心、實測通常發現中文跟英文 prompt 表現接近、翻譯成本浪費。

Commit / Docstring / 註解的語言選擇取捨

寫 code 場景的「該用什麼語言」決策多半取決於非模型因素：

Commit Message

• 團隊一致性：團隊都用英文就英文、都用中文就中文。
• 長期保留：commit message 進 git 歷史、長期保留、跨團隊成員 / 外部貢獻者讀。
• 可讀性受眾：團隊有非中文 reader 就英文、純中文團隊用中文也 OK。
• 隱私 / 合規：commit 進 git、可能進 public repo、敏感資訊不該寫進去（不論語言）。

模型對中英 commit message 都能寫、選擇主要看團隊跟 repo 屬性、不是看模型偏好。

Docstring

• 語言生態慣例：Python / JavaScript 開源社群慣例是英文 docstring；JetBrains / 微軟在地化文件多中文。
• API consumer：API 給誰用、用什麼語言。
• 自動化工具：docs generator、type checker、IDE hint 對英文 docstring 支援較成熟。

程式內註解

• 團隊母語 vs 國際慣例：團隊母語寫註解最自然、國際慣例（特別 open source）多英文。
• 複雜邏輯：用最能精確表達的語言寫、不一定要英文。
• TODO / FIXME：跟團隊慣例一致。

這些決策本質上是團隊跟生態問題、不是 LLM 問題。LLM 對中英都能 handle、選哪個取決於 downstream 讀者。

跨語言 Reasoning 的失敗訊號

跨語言 reasoning（如中文 prompt 要求模型用中文推理過數學題、或用中文回答需要英文事實 retrieval 的問題）容易出現幾種失敗：

內部翻譯失敗

模型「中文 prompt → 內部翻譯成英文 reasoning → 翻回中文輸出」、中間步驟跳過、中文輸出看起來合理但推理鏈不通。

判讀訊號：要求模型「請用中文逐步推理」、模型輸出推理鏈不連貫、步驟跳躍。

緩解：強制 step-by-step prompt、或乾脆翻英 prompt 拿英文輸出、再人工譯回中文。

訓練語言切換

模型在某語言上 reasoning 訓練不足、即使理解 query、輸出推理深度受限。

判讀訊號：中文 query 拿到淺薄答案、同樣 query 翻英拿到深入答案。

緩解：複雜推理任務用英文 prompt + 英文輸出、最後再翻譯。

Tokenizer 引發的細節遺失

中文一字切多個 token 時、模型可能在 token 邊界誤判語意、輸出細節不準。

判讀訊號：細節錯（罕用字 OOV 被切成 byte / 數字本身切分不一致導致算術出錯）、英文同義問題不會錯。

緩解：對細節敏感的任務（數字、日期、人名）強調確認、或翻英降低 tokenizer 誤判機率。

何時跨語言 reasoning 不會失敗 / 何時翻英無收益

上述三類失敗模式不會均勻發生在所有跨語言任務上、實際觸發條件是「深度推理 + 語言 specific 事實 retrieval」雙條件命中。以下情境通常翻英沒收益、留在中文 prompt 反而省事：

• Code 補完、語法重構、加 type annotation：code 本身就跨語言、模型不需要「翻譯」code、中文 prompt 直接寫即可。
• 短 QA、context-rich prompt：問題本身就含完整 context（如「這段程式碼做什麼」+ code）、模型不需要做 retrieval、reasoning 深度需求低。
• 格式 / 結構轉換：JSON 轉 YAML、Markdown 重排、tabular 整理 — 任務機械化、跟語言關係小。
• 單檔 refactor：選定範圍內的改寫、不需跨檔 retrieval、推理深度受 context 限制而非語言。
• commit message / docstring 草稿：套用 template 性質、模型輸出語言跟 prompt 一致較自然。

需要翻英的場景集中在「深度推理（多步邏輯 / 數學）」+「需要 retrieval 語言 specific 事實（如某個 framework 的 API、特定論文細節、英文社群討論）」這兩條都命中時、其他場景翻譯成本是浪費。

Code 跟自然語言的不對稱

Code 本身是「英文偏向」的：keyword（if、for、return）、變數名（多半 ASCII）、API（多半英文）。LLM 對 code 的能力跨語言差距較小——code 本身就跨語言、模型不需要「翻譯」code。

但「code + 自然語言」的混合場景仍受自然語言訓練分佈影響：

• 寫 code + 中文 docstring：模型寫 code 表現一致、寫 docstring 受訓練分佈影響。
• 解釋 code 給人聽：用哪種語言解釋、受該語言訓練分佈影響。
• 改寫 code 註解：改 code 行為一致、改自然語言部分受訓練分佈影響。

判讀「該不該翻英」時、要區分「code 部分」跟「自然語言部分」。Code 部分中英差距小、自然語言部分中英差距視模型而定。

何時過時 / 何時不過時

不會過時的部分：

• Tokenizer + 訓練分佈雙因素 framing。
• 跨語言能力受結構性限制的本質（不只是「模型不夠強」）。
• 三個變數判讀（能力差距、翻譯成本、輸出語言要求）。
• 跨語言 reasoning 失敗模式的分類。
• Code 跟自然語言的不對稱觀察。

會變的部分：

• 具體模型在特定語言上的當下能力（會隨新模型版本變、Gemma 5 / Qwen4 等出來會再變）。
• 各 tokenizer 的 vocab 大小（會調整）。
• 訓練資料的多語言比例（業界正在改善）。
• 哪些模型「中文能力好」的具體 ranking。

看到新模型時、回到雙因素 framework 評估：tokenizer vocab 多大、中文 token 效率如何、訓練資料中文佔比、實測中文表現是否符合預期——這個 framework 不變、評估結果會隨模型版本更新。

下一章

下一章：3.8 Reasoning models、看 2024-2026 的 test-time compute paradigm。完整公開課推薦見 3.10 想學更深。