模組三 3.6 tokenization 章節 提到 Llama 2 對中文支援差、Gemma 4 改善很多——但「為什麼」展開後不只 tokenizer 一層、還涉及訓練資料分佈、模型容量分配、跨語言 reasoning 行為差異。本章把跨語言場景的根本原理走過、讓「該用什麼語言寫 prompt」「commit message 用中文還是英文」這類取捨從直覺變成可推導判斷。

本章寫的是「跨語言能力為什麼這樣分佈」「該如何依場景選語言」的原理層。具體模型在 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 想學更深。