中文 LLM 訓練資料對台灣企業曝光的影響

由 CiphLens 團隊整理 · 來源：GitHub Copilot 研究 · 繁體中文

● Web Search (MCP: github-mcp-server) · Common Crawl Taiwan Traditional Chinese representation perc… └ {"type":"output_text","text":{"value":"根據2024年最新的社群、論文和資料集資 料，Common Craw...

● Web Search (MCP: github-mcp-server) · AEO Answer Engine Optimization Traditional Chinese vs Engli… └ {"type":"output_text","text":{"value":"Great question! As we move into 2...

● Web Search (MCP: github-mcp-server) · GPT-4 Claude Gemini Chinese training data proportion simpli… └ {"type":"output_text","text":{"value":"As of my knowledge cutoff in June...

● Web Search (MCP: github-mcp-server) · how enterprises enter LLM training data pool Common Crawl i… └ {"type":"output_text","text":{"value":"Your question covers several key ...

● Web Search (MCP: github-mcp-server) · Taiwan LLM github yentinglin training data Traditional Chin… └ {"type":"output_text","text":{"value":"For those seeking high-quality Tr...

以下是完整的繁體中文文件：

主流 LLM 中文訓練資料深度解析：簡體 vs 繁體、台灣覆蓋度與企業進場策略

一、前言：語料即世界觀

大型語言模型（LLM）的能力，根本上由訓練資料決定。GPT-4、Claude、Gemini 等模型在中文能力的表現，直接反映了它們訓練語料中的中文比例、品質與地域分佈。對台灣使用者與企業而言，一個核心問題是：這些模型「看過」多少真正的繁體中文？它們理解「台灣脈絡」的程度有多深？

本文將系統性地梳理主流 LLM 的中文資料來源，分析簡繁比例失衡的結構性原因，探討台灣企業的主動進場策略，並比較繁中內容在 SEO/AEO 生態中的現實差距。

二、主流 LLM 的中文訓練資料來源

2.1 通用預訓練語料的組成邏輯

三大主流模型的預訓練語料，雖然各家技術報告均未完整揭露，但從公開資訊可以歸納出共通結構：

| 語料類型 | 代表來源 | 中文比例估計 | |---|---|---| | 網路爬取資料 | Common Crawl、C4 | 中文佔全體 ~1%，其中繁體 ~10% | | 百科知識 | Wikipedia（多語言版） | 繁中 Wikipedia 約 125 萬條目 | | 書籍資料 | Books3、OpenBook | 以英文為主，中文書極少 | | 程式碼 | GitHub Repositories | 幾乎無語言區分 | | 多語平行語料 | mC4、CC-100 | 繁中（zh-Hant）比例極低 |

GPT-4：OpenAI 的技術報告（2023）提到採用多語言網路資料，但未揭露語言分佈細節。外部估計顯示，中文整體佔比約 3–5%，其中 80–95% 為簡體中文。

Claude：Anthropic 在 Claude 的模型卡與技術文件中，同樣未公開訓練語料的語言比例。社群評估認為繁體中文的比重與 GPT-4 相近，甚至更低。

Gemini：Google DeepMind 在 Gemini Technical Report（2023）中提到使用大規模多語言網頁資料與書籍，中文支援涵蓋兩種書寫系統，但無具體比例。值得注意的是，Google 擁有 YouTube、Google Maps 等在地化服務，理論上有機會接觸更多繁體中文內容，但這些資料是否納入訓練仍未確認。

2.2 維基百科的繁簡差距

維基百科是 LLM 訓練中品質最高的公開中文語料之一。截至 2025 年初：

• 中文（簡體為主）Wikipedia：約 145 萬條目
• 中文（繁體）Wikipedia：約 125 萬條目（含香港、台灣、澳門視角）

兩者數量差距不大，但維基百科採用「中文維基百科」統一站（zh.wikipedia.org），依靠轉換模組在簡繁之間切換，模型在訓練時若未妥善處理，可能將簡繁內容混同。

2.3 mC4 與 CC-100 的實際佔比

Google 發布的 mC4（Multilingual C4）是 T5 系列模型的重要語料，其中：

• zh（未區分簡繁）：約 1.3% 的資料來自中文頁面
• 台灣 .tw 網域的代表性：極低，研究者估計不超過整體的 0.1%

Facebook（Meta）發布的 CC-100 語料，特別針對高/中/低資源語言進行分拆，包含 zh-Hans（簡體）與 zh-Hant（繁體，含港台澳）。根據資料集統計，zh-Hant 的 token 數量約為 zh-Hans 的 15–20%。

三、Common Crawl 中台灣網站的代表性

3.1 結構性劣勢

Common Crawl 每月爬取數十億頁面，其資料分佈高度反映全球網路流量分佈。台灣面臨以下結構性劣勢：

1. 網域數量少：.tw 域名的網站數量遠少於 .com.cn 等中國大陸域名
2. robots.txt 限制：台灣主要新聞媒體（聯合新聞網、ETtoday 等）設有嚴格的爬蟲封鎖
3. 動態內容多：台灣電商平台與社群網站多使用 JavaScript 渲染，Common Crawl 的靜態爬取難以捕捉
4. 重複內容過濾：去重演算法（如 MinHash LSH）在過濾重複內容時，台灣媒體的「轉載文化」導致大量優質原創內容被誤判刪除

台灣研究者在建構本土 LLM 語料時，實際驗證了上述問題。以 MiuLab/Taiwan-LLM（GitHub）專案為例，第一版訓練資料大量依賴 Common Crawl 的台灣爬取資料，但品質測試後發現：色情、詐騙、極端政治言論的比例過高，且真正具台灣文化脈絡的優質內容佔比極低。V2 版本因此大幅降低 Common Crawl 比重，改以自建語料為主。

3.2 語言識別的問題

Common Crawl 的語言識別工具（如 langdetect、fastText langid）在區分繁體中文與簡體中文時，準確率不穩定。部分繁體中文頁面會被標記為 zh（未區分），或甚至因使用台灣特有詞彙而被誤判為低信心語言。這導致訓練資料的標籤品質欠佳，進一步稀釋繁中語料的有效性。

四、台灣特定資料的覆蓋缺口

4.1 詞彙與文化脈絡差異

簡繁中文的差異遠超書寫系統。以下幾個維度特別值得注意：

詞彙差異（部分示例）：

| 概念 | 台灣用語 | 中國大陸用語 | |---|---|---| | 軟體 | 軟體 | 软件 | | 影片 | 影片 | 视频 | | 機車 | 機車（諧音罵人語） | 摩托车 | | 捷運 | 捷運（MRT） | 地铁 | | 健保 | 健保（全民健保）| 医保 |

當模型的訓練資料中簡體中文佔絕對多數時，模型在處理台灣特有詞彙時容易出現語義混淆，甚至以大陸用語替換台灣用語。

法律與制度脈絡：台灣的司法體系、稅務制度、醫療體系與中國大陸根本不同。若 LLM 的中文法律語料以中國大陸法規為主，對台灣使用者提供的法律資訊可能存在根本性的錯誤。

4.2 學術研究對此問題的確認

arXiv 論文 "Large Language Models are not created equal: A Study on Chinese LLMs"（arXiv:2311.02501）指出，在中文 LLM 評估中，模型對繁體中文的理解能力普遍弱於簡體中文，且在台灣特定知識（如台灣歷史、政治制度、地理）上的準確性明顯偏低。

台灣大學林彥廷博士（Yen-Ting Lin）主導的 Taiwan-LLM 系列研究，明確記錄了這個問題，並提出以在地語料微調作為解方。其公開資料集 yentinglin/TaiwanChat 包含超過 50 萬筆繁體中文指令跟隨資料，專為補足台灣脈絡而設計。

五、台灣企業如何主動進入訓練池

5.1 被動進入：讓 Common Crawl 爬得到

最基本的策略是確保網站對爬蟲友善，提升被 Common Crawl 收錄的機率：

技術面：

• 開放 robots.txt：User-agent: CCBot 不應出現在 Disallow 清單中。Common Crawl 使用 CCBot 作為爬蟲識別碼，許多台灣網站的 robots.txt 因過於保守，直接封鎖了 Common Crawl。
• 靜態化關鍵內容：確保核心知識型內容以 Server-Side Rendering（SSR）或靜態 HTML 輸出，而非純 JavaScript 渲染
• Sitemap XML 完整性：提交 Sitemap 至 Google Search Console，間接提升被 Common Crawl 跟隨索引的機率
• 頁面速度與穩定性：Common Crawl 爬蟲對回應緩慢或不穩定的伺服器抓取頻率較低

內容面：

• 撰寫「常青型」（evergreen）長篇知識性內容，降低被去重演算法過濾的機率
• 避免大量轉載，以原創內容建立差異化，在語料池中保持唯一性

5.2 主動進入：直接貢獻開源資料集

更積極的策略是直接向開源語料庫貢獻資料：

Hugging Face Datasets：上傳高品質繁體中文資料集至 Hugging Face，並加上適當授權（CC BY 4.0 或 Apache 2.0）。許多 LLM 訓練團隊會掃描 Hugging Face 上的開放資料集納入訓練。參考案例：liswei/Traditional-Chinese-LLM-Corpus 集合。

Wikipedia 貢獻：組織員工系統性地為中文維基百科撰寫或更新與企業所在產業相關的條目，特別是台灣特有的制度、技術標準、文化知識。維基百科是幾乎所有主流 LLM 必然使用的高品質語料。

Common Crawl 的主動申請：Common Crawl 基金會接受特定組織提交重新爬取特定網域的請求，企業可透過其網站聯繫，要求將特定 URL 加入下一輪爬取清單。

參與學術合作：台灣企業可與國內大學的 NLP 實驗室合作（如台大 MiuLab、交大、成大等），共同建構開放語料庫，同時藉由論文發表提升資料集的學術可信度，增加被主流 LLM 採用的機率。

5.3 結構化資料標記（Schema.org）

在 AEO 時代，Schema.org 結構化資料的重要性不止於搜尋引擎，也直接影響 AI 答案引擎的知識擷取：

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "inLanguage": "zh-Hant-TW",
  "mainEntity": [{
    "@type": "Question",
    "name": "台灣健保費率如何計算？",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "全民健保費率依投保金額與負擔比率計算..."
    }
  }]
}

使用 inLanguage: "zh-Hant-TW" 明確標示繁體台灣中文，有助於 AI 模型在訓練與推論時正確識別語言脈絡。

六、繁中內容的 SEO/AEO 與英文版差異

6.1 搜尋引擎的語言理解差距

Google、Bing 等搜尋引擎對英文內容的語意理解能力，遠超過繁體中文。這個差距在 AEO 時代被放大：

關鍵字分詞問題：中文不使用空格，搜尋引擎需依賴分詞演算法（如 Jieba）。繁體中文的分詞準確率普遍低於英文，導致語意搜尋（Semantic Search）效果較差。台灣特有詞彙（如「悠遊卡」、「健保署」）的識別準確率尤其不穩定。

訓練資料的回饋循環：搜尋引擎的語意理解模型，本身也是以大量繁中文本訓練。由於繁中文本稀缺，模型的繁中語意理解較差 → 繁中排名不準確 → 繁中創作者的SEO投資回報率低 → 優質繁中內容產出減少 → 形成負向循環。

6.2 AEO 在繁中環境的特殊挑戰

AI Overview（原 SGE）的繁中覆蓋率低：Google 的 AI 摘要功能在台灣推出時間較晚，且初期對繁中問題的回答品質明顯低於英文。部分原因是供 AI 引用的高品質繁中來源數量不足。

Perplexity 與 ChatGPT 搜尋的繁中品質：這些 AI 搜尋工具在處理繁中查詢時，常出現：

• 以簡體中文語料回答繁中問題，出現大量「软件」「视频」等大陸用語
• 引用中國大陸的法規、制度，而非台灣適用的版本
• 對台灣本地新聞、時事的知識截止日期較不確定

6.3 繁中 AEO 最佳實踐

針對台灣繁中內容的 AEO 優化，以下策略與英文 AEO 有所不同：

hreflang 標記的正確使用：

<link rel="alternate" hreflang="zh-Hant-TW" href="https://example.com.tw/zh-TW/page" />
<link rel="alternate" hreflang="zh-Hant-HK" href="https://example.com.hk/zh-HK/page" />
<link rel="alternate" hreflang="zh-Hans-CN" href="https://example.com/zh-CN/page" />

台灣企業應嚴格區分 zh-Hant-TW（台灣繁體）與 zh-Hant-HK（香港繁體），避免語言標記混淆。

問答格式的台灣在地化：針對 AI 答案引擎，FAQ 的問題措辭應採用台灣使用者實際的搜尋語言，而非翻譯自英文或借用中國大陸用語。例如使用「健保卡」而非「医保卡」，「提款機」而非「ATM机」。

E-E-A-T 在繁中環境的建立：Google 的 E-E-A-T（Experience, Expertise, Authoritativeness, Trustworthiness）評分對繁中內容同樣適用，但建立繁中領域權威的難度更高，因為外部連結生態較稀薄。建議策略：積極爭取 .gov.tw、.edu.tw 等高權威網域的引用或合作。

七、開源社群的補位努力

面對主流 LLM 對繁中資料的系統性低估，台灣開源社群發展出若干補位機制：

7.1 MiuLab/Taiwan-LLM

台灣大學 MiuLab 實驗室的旗艦開源專案（GitHub: MiuLab/Taiwan-LLM），基於 LLaMA 架構，以繁體中文指令資料微調。Llama-3-Taiwan-70B 是目前最強的開源台灣繁中模型，訓練資料包含：

• YouTube 字幕（台灣媒體）
• 法律與法規文件
• 醫療知識（與長庚醫院合作）
• 繁中新聞語料

7.2 CKIP Lab 的語言工具鏈

中研院詞庫小組（CKIP Lab）提供開源的繁體中文 NLP 工具，包含分詞、詞性標注、命名實體識別等（GitHub: ckiplab/ckip-transformers）。這些工具對繁中語料的前處理至關重要，是建構高品質台灣中文訓練資料的基礎設施。

7.3 TMCCC（台灣多文化中文語料庫）

學術界多個機構合作建構的大規模繁體中文語料，包含台語漢字、原住民族語文混用等台灣特有語言現象，反映了台灣語言多樣性的真實面貌。

八、結論與展望

結構性失衡難以短期逆轉：只要台灣的網路內容總量（和數位化程度）低於中國大陸，Common Crawl 的繁簡比例失衡將持續存在，並傳遞至下游 LLM。

主動策略優於被動等待：台灣企業與機構應把「進入 LLM 訓練池」視為長期的數位資產建設工作，具體行動包括：開放 robots.txt、貢獻 Hugging Face 資料集、系統性維護維基百科、與學術機構建立語料合作。

AEO 是繁中內容的杠桿點：相較於英文市場的高度競爭，繁中高品質 AEO 內容目前仍是藍海。能夠提供台灣脈絡、正確詞彙、結構化標記的知識型內容，在 AI 答案引擎中的被引用率將持續提升。

生態系統需要集體行動：單一企業或機構的努力，難以扭轉訓練資料的結構性失衡。政府、學術界、產業界、公民社會的協作，系統性地建構開放繁中語料庫，才是讓 LLM 真正理解台灣的根本之道。

參考資料

1. OpenAI. (2023). GPT-4 Technical Report. arXiv:2303.08774
2. Google DeepMind. (2023). Gemini: A Family of Highly Capable Multimodal Models. arXiv:2312.11805
3. Lin, Y.-T., et al. (2023). Taiwan LLM: Bridging the Linguistic Divide with a Culturally Aligned Language Model. MiuLab, National Taiwan University. GitHub
4. Xue, L., et al. (2021). mT5: A Massively Multilingual Pre-Trained Text-to-Text Transformer. NAACL 2021. arXiv:2010.11934
5. Conneau, A., et al. (2020). Unsupervised Cross-lingual Representation Learning at Scale (XLM-R). ACL 2020. arXiv:1911.02116
6. CKIP Lab. CKIP Transformers: 繁體中文自然語言處理工具. GitHub
7. liswei. (2024). Traditional Chinese LLM Corpus Collection. Hugging Face
8. Common Crawl Foundation. CC-MAIN Crawl Statistics. commoncrawl.org
9. arXiv:2311.02501 — Large Language Models are not created equal: A Study on Chinese LLMs