DS & AI

[DS & AI Blog #43] Xử Lý Ngôn Ngữ Tự Nhiên & Giải Mã Tokenization: Thuật Toán BPE, WordPiece, SentencePiece & "Gót Chân Achilles" Của LLMs

0 views
[DS & AI Blog #43] Xử Lý Ngôn Ngữ Tự Nhiên & Giải Mã Tokenization: Thuật Toán BPE, WordPiece, SentencePiece & "Gót Chân Achilles" Của LLMs

1. Bối cảnh thực tế (Context & Problem Statement)

Andrej Karpathy (cựu Giám đốc AI của Tesla, đồng sáng lập OpenAI) từng có một nhận định nổi tiếng gây sốt trong giới AI:
“Almost all weird problems in LLMs trace back to Tokenization.”
(Hầu như mọi lỗi kỳ quặc và ngớ ngẩn của các mô hình ngôn ngữ lớn đều bắt nguồn từ tầng Tokenization).

Các hiện tượng kỳ lạ khiến nhiều người dùng bối rối:

  1. Tại sao GPT-4 lại gặp khó khăn khi trả lời câu hỏi đơn giản: "Trong từ 'strawberry' có bao nhiêu chữ 'r'?" →\rightarrow Mô hình thường trả lời sai là có 2 chữ thay vì 3 chữ!
  2. Tại sao LLM rất dốt các phép tính số học cơ bản (ví dụ cộng 2 số có 8 chữ số) dù có thể viết code Python phức tạp?
  3. Tại sao chi phí gọi API của cùng một câu văn bằng Tiếng Việt lại đắt gấp 2−3 laˆˋn2 - 3\text{ lần} so với Tiếng Anh, đồng thời làm dung lượng ngữ cảnh (Context Window) thực tế của người dùng Việt Nam bị teo nhỏ đi một nửa?

Câu trả lời không nằm ở kiến trúc mạng nơ-ron Transformer hay số lượng tham số 70B/405B, mà nằm ở Tầng Tokenizer: Bộ chuyển đổi ký tự văn bản của con người thành các con số nhị phân cho máy tính.


2. Các Khái Niệm & Cơ Chế Cốt Lõi

2.1. Sự Tiến Hóa Của Các Phương Pháp Phân Đoạn Văn Bản

Trước khi Subword Tokenization ra đời, ngành Xử lý Ngôn ngữ Tự nhiên (NLP) bị mắc kẹt giữa hai thái cực:

WORD-LEVEL TOKENIZATION:              CHARACTER-LEVEL TOKENIZATION:
"unhappiness" ---> ["unhappiness"]     "unhappiness" ---> ['u', 'n', 'h', 'a', 'p', 'p', 'i', 'n', 'e', 's', 's']
- Từ điển khổng lồ (> 500k từ).         - Từ điển siêu nhỏ (vài chục ký tự a-z, 0-9).
- Bị lỗi OOV (Out-Of-Vocabulary):       - Chuỗi độ dài quá dài (Sequence length bùng nổ).
  Gặp từ mới lạ -> Biến thành [UNK].    - Từng ký tự riêng lẻ không mang ý nghĩa ngữ nghĩa độc lập.

⟹\Longrightarrow Giải pháp dung hòa hoàn hảo: Subword Tokenization (Phân đoạn từ con):

  • Các từ phổ biến được giữ nguyên vẹn (ví dụ: "the", "cat").
  • Các từ hiếm hoặc từ phức tạp được bóc tách thành các hình vị (morphemes) quen thuộc: "unhappiness"⟶["un", "happi", "ness"]\text{"unhappiness"} \longrightarrow \text{["un", "happi", "ness"]} (Cho phép mô hình hiểu được ý nghĩa của các từ mới chưa từng thấy thông qua việc kết hợp các khối từ con có sẵn).

2.2. Thuật Toán Byte-Pair Encoding (BPE - Chuẩn Của GPT & LLaMA)

BPE ban đầu là một thuật toán nén dữ liệu cổ điển (Philip Gage, 1994), được Rico Sennrich et al. (2016) ứng dụng mang tính cách mạng vào NLP.

  • Quy trình hoạt động từng bước:
    1. Khởi tạo bộ từ vựng: Bắt đầu bằng toàn bộ các ký tự cơ sở đơn lẻ (Characters). Mỗi từ trong ngữ liệu huấn luyện được tách thành các ký tự rời rạc kèm ký hiệu kết thúc từ </w>.
    2. Đếm tần suất: Đếm số lần xuất hiện của tất cả các cặp ký tự liền kề (Adjacent Pairs) trong toàn bộ tập văn bản.
    3. Hợp nhất (Merge): Tìm cặp ký tự có tần suất xuất hiện cao nhất và hợp nhất chúng thành một Token mới. Thêm token mới này vào bộ từ vựng.
    4. Lặp lại: Tiếp tục quá trình cho đến khi đạt được kích thước từ vựng mục tiêu (Vocabulary Size, ví dụ 32,00032,000 hoặc 128,000128,000 tokens).
VÍ DỤ HUẤN LUYỆN BPE:
Tập dữ liệu: {"low": 5, "lower": 2, "newest": 6, "widest": 3}
Khởi tạo từ vựng: {l, o, w, e, r, n, s, t, i, d}

Vòng 1: Cặp ('e', 's') xuất hiện 6+3 = 9 lần (Cao nhất) -> Hợp nhất thành 'es'.
        Từ vựng mới: {..., 'es'}
Vòng 2: Cặp ('es', 't') xuất hiện 6+3 = 9 lần -> Hợp nhất thành 'est'.
        Từ vựng mới: {..., 'es', 'est'}
Vòng 3: Cặp ('l', 'o') xuất hiện 5+2 = 7 lần -> Hợp nhất thành 'lo'.
        Từ vựng mới: {..., 'es', 'est', 'lo'}
Vòng 4: Cặp ('lo', 'w') xuất hiện 5+2 = 7 lần -> Hợp nhất thành 'low'.
        Từ vựng mới: {..., 'es', 'est', 'lo', 'low'}

2.3. Đột Phá Byte-Level BPE (BBPE): Triệt Tiêu 100% Lỗi Out-Of-Vocabulary (OOV)

Trong BPE ký tự truyền thống, nếu người dùng nhập vào một ký tự lạ (như emoji đặc thù 🚀, chữ tượng hình cổ, hoặc một ký tự Unicode chưa từng có trong tập train), Tokenizer sẽ bất lực và gán nhãn [UNK] (Unknown Token).

  • Giải pháp Byte-level BPE (OpenAI GPT-2, GPT-4, LLaMA):
    • Không khởi tạo bộ từ vựng bằng các ký tự Unicode!
    • Khởi tạo bộ từ vựng bằng đúng 256 giá trị Byte cơ bản (0x00 đến 0xFF) của chuẩn mã hóa UTF-8.
    • Mọi ký tự trên Trái Đất (từ tiếng Anh, tiếng Việt, tiếng Trung, tiếng Ả Rập đến Emoji) suy cho cùng đều được biểu diễn bằng một chuỗi từ 11 đến 44 bytes trong UTF-8.
    • →\rightarrow Mô hình có thể biểu diễn và mã hóa 100%100\% mọi dữ liệu văn bản nhị phân trên thế giới mà không bao giờ gặp lỗi OOV!

2.4. WordPiece vs. Unigram SentencePiece

  • WordPiece (Sử dụng trong Google BERT):
    • Tương tự BPE nhưng khác biệt ở tiêu chí hợp nhất cặp từ.
    • Thay vì chọn cặp có tần suất xuất hiện cao nhất, WordPiece chọn cặp ký tự (x,y)(x, y) giúp Tối đa hóa xác suất hợp lý (Maximizing Likelihood) của mô hình ngôn ngữ: Score(x,y)=Count(xy)Count(x)×Count(y)\text{Score}(x, y) = \frac{\text{Count}(xy)}{\text{Count}(x) \times \text{Count}(y)}
    • Nhờ chia cho mẫu số, thuật toán ưu tiên các cặp ký tự thực sự có tính liên kết chặt chẽ hơn là chỉ đơn thuần xuất hiện nhiều do ngẫu nhiên. Ký hiệu tiền tố ## được dùng để biểu thị từ con đứng sau (ví dụ: play và ##ing).
  • Unigram SentencePiece (Sử dụng trong Google T5, ALBERT, LLaMA):
    • Đi theo triết lý ngược lại: Bắt đầu từ một tập từ vựng khổng lồ (hàng trăm nghìn từ con), sau đó chạy mô hình xác suất Unigram Language Model và tỉa dần (Pruning) các token ít quan trọng cho đến khi đạt kích thước mong muốn.
    • Xử lý dấu cách như ký tự thông thường: Thay vì tách từ bằng khoảng trắng (vốn không khả thi cho tiếng Nhật, tiếng Trung), SentencePiece coi khoảng trắng là ký tự đặc biệt _ (Meta symbol U+2581), giúp quá trình Decode trở về văn bản gốc không bị mất dấu cách.

2.5. Hiện Tượng "Lạm Phát Token" (Token Inflation) Trên Tiếng Việt

  • Các mô hình LLM ban đầu (GPT-3, GPT-4 cũ, LLaMA 1/2) được huấn luyện với tập dữ liệu chứa >90%> 90\% là Tiếng Anh.
  • Do đó, bộ từ vựng BPE (32,00032,000 tokens) được dành gần như toàn bộ cho các từ và cụm từ tiếng Anh nguyên vẹn.
  • Với các ngôn ngữ có dấu thanh và ít tài nguyên như Tiếng Việt:
    • Các từ có dấu tiếng Việt bị Tokenizer chém vụn thành từng mảnh nhỏ hoặc từng byte UTF-8 riêng lẻ:
      • Tiếng Anh: "Artificial Intelligence" →\rightarrow Chỉ tốn 2 tokens.
      • Tiếng Việt: "Trí tuệ nhân tạo" →\rightarrow Bị chém thành: ['Tr', 'í', ' tu', 'ệ', ' nhân', ' t', 'ạo'] →\rightarrow Tốn tới 6 đến 8 tokens!
    • Hậu quả kép:
      1. Chi phí API tăng gấp 3–4 lần: Vì các nhà cung cấp (OpenAI, Anthropic) tính tiền theo số lượng tokens tiêu thụ.
      2. Context Window bị teo nhỏ: Cửa sổ ngữ cảnh 8k8\text{k} tokens trên tiếng Anh đọc được cả một cuốn sách ngắn, nhưng với tiếng Việt chỉ đọc được một nửa.
      3. Độ trễ sinh từ chậm gấp 3 lần: Do LLM phải sinh ra số lượng token nhiều gấp 3 lần để hoàn thành cùng một câu.
  • →\rightarrow Đây là lý do các mô hình thế hệ mới (LLaMA 3, Gemma, Qwen) đã mở rộng kích thước từ vựng từ 32k32\text{k} lên 128,000128,000 hoặc 256,000256,000 tokens để hỗ trợ đa ngôn ngữ tối ưu hơn.

3. Các Bảng Markdown So Sánh Chi Tiết

📊 Bảng 1: So Sánh Toàn Diện Các Thuật Toán Tokenization Hàng Đầu

Tiêu chíBPE (Byte-Pair Encoding)Byte-level BPE (BBPE)WordPieceUnigram / SentencePiece
Chiến lược xây dựng từ vựngBottom-up (Hợp nhất)Bottom-up (Hợp nhất)Bottom-up (Hợp nhất)Top-down (Tỉa dần)
Tiêu chí chọn cặp từTần suất xuất hiện lớn nhấtTần suất xuất hiện lớn nhấtTối đa hóa LikelihoodTối thiểu hóa mất mát Entropy
Bộ từ vựng cơ sở ban đầuKý tự đơn lẻ (Characters)256 Bytes UTF-8 (0x00 - 0xFF)Ký tự đơn lẻTập hợp từ con khổng lồ ban đầu
Khả năng gặp lỗi OOVVẫn có thể gặp nếu có ký tự lạTuyệt đối 0% (Zero OOV)Có thể gặpTuyệt đối 0% (Khi bật byte fallback)
Ký hiệu nhận diện từ conThường dùng @@ hoặc không dấuDùng ký tự phân tách byte ĠDùng tiền tố ## (ví dụ ##ing)Dùng ký tự đại diện khoảng trắng _
Mô hình tiêu biểu sử dụngGPT-1, RoBERTa cũ, BPEmbGPT-2/3/4, LLaMA 1/2/3, MistralGoogle BERT, DistilBERTGoogle T5, ALBERT, Gemma

📊 Bảng 2: So Sánh Kích Thước Từ Vựng & Năng Lực Đa Ngôn Ngữ Của Các LLMs

Mô hìnhThuật toán TokenizerKích thước từ vựng (Vocab Size)Mức độ tối ưu cho Tiếng Việt / Đa ngữTỷ lệ nén Token trung bình
BERT (Cased)WordPiece≈30,000\approx 30,000Kém (Chủ yếu tối ưu tiếng Anh)1.0×1.0\times (Chuẩn gốc)
GPT-2 / GPT-3.5Byte-level BPE50,25750,257Kém (Lạm phát token tiếng Việt ≈2.5×\approx 2.5\times)Khá cho tiếng Anh
LLaMA 1 & LLaMA 2SentencePiece (BPE)32,00032,000Rất kém (Tiếng Việt bị chém vụn thành bytes)Kém trên phi tiếng Anh
LLaMA 3 (Meta)Tiktoken (Byte-level BPE)128,256128,256 (Gấp 4 lần LLaMA 2)Rất tốt (Tiết kiệm 30%−40%30\% - 40\% tokens)Xuất sắc
Gemma / Gemma 2SentencePiece256,000256,000 (Khổng lồ)Xuất sắc nhất thế giới về đa ngữSiêu nén

📊 Bảng 3: Ma Trận Các Lỗi Kỳ Quặc Của LLMs Do Tokenizer Gây Ra & Nguyên Nhân

Lỗi phổ biến của LLMBiểu hiện thực tếNguyên nhân gốc rễ ở tầng Tokenizer
Không đếm được chữ cáiKhông đếm được số chữ 'r' trong từ "strawberry"Tokenizer chia "strawberry" thành 2 tokens: ['straw', 'berry']. LLM không nhìn thấy từng chữ cái riêng lẻ, nó chỉ nhìn thấy 2 con số ID đại diện!
Kém các phép toán số họcTính nhầm phép cộng các số lớn: 18274 + 9382 = ?Các con số bị chia ngẫu nhiên: 18274 bị chia thành ['18', '274'], trong khi 9382 bị chia thành ['938', '2']. Mô hình không thể căn thẳng hàng các cột đơn vị/chục/trăm!
Nhạy cảm với dấu cách thừaCâu hỏi có dấu cách ở cuối ("What is AI ") cho kết quả kém hơnDấu cách ở cuối tạo thành một token hoàn toàn khác (ví dụ: token " AI" khác với token " " và token "AI").
Tấn công Prompt Injection ẩnCác từ đặc biệt làm crash mô hình (ví dụ: " SolidGoldMagikarp")Glitch Tokens: Các chuỗi token xuất hiện trong tập train của Tokenizer nhưng không bao giờ xuất hiện trong tập huấn luyện của LLM →\rightarrow Vector embedding bị rỗng/nhiễu!

4. Best Practices & Kỹ Thuật Viết Code Tokenizer (Pro-Tips)

💡 Triển Khai Thuật Toán BPE Cốt Lõi Bằng Python (From Scratch)

Hiểu trọn vẹn cách thức máy tính tìm cặp ký tự phổ biến nhất để hợp nhất:

from collections import defaultdict

def get_stats(vocab):
    """Đếm tần suất xuất hiện của tất cả các cặp ký tự liền kề."""
    pairs = defaultdict(int)
    for word, freq in vocab.items():
        symbols = word.split()
        for i in range(len(symbols) - 1):
            pairs[(symbols[i], symbols[i+1])] += freq
    return pairs

def merge_vocab(pair, v_in):
    """Hợp nhất cặp ký tự phổ biến nhất thành một token mới."""
    v_out = {}
    bigram = ' '.join(pair)
    replacement = ''.join(pair)
    for word in v_in:
        w_out = word.replace(bigram, replacement)
        v_out[w_out] = v_in[word]
    return v_out

# Dữ liệu ban đầu (kèm ký hiệu kết thúc từ </w>):
vocab = {
    'l o w </w>': 5,
    'l o w e r </w>': 2,
    'n e w e s t </w>': 6,
    'w i d e s t </w>': 3
}

# Chạy 5 vòng lặp hợp nhất BPE:
num_merges = 5
for i in range(num_merges):
    pairs = get_stats(vocab)
    if not pairs:
        break
    best_pair = max(pairs, key=pairs.get)
    vocab = merge_vocab(best_pair, vocab)
    print(f"Bước {i+1}: Hợp nhất cặp {best_pair} -> Token mới: '{''.join(best_pair)}'")

💡 Kỹ Thuật Mở Rộng Từ Vựng (Vocabulary Expansion) Khi Fine-Tune LLM Cho Tiếng Việt

  • Vấn đề: Khi fine-tune mô hình có từ vựng tiếng Việt kém (như LLaMA 2), chi phí và thời gian huấn luyện sẽ rất cao.
  • Giải pháp Vocabulary Expansion:
    1. Dùng SentencePiece huấn luyện một Tokenizer tiếng Việt riêng biệt (20,00020,000 tokens) trên tập báo chí/văn bản tiếng Việt.
    2. Ghép các token tiếng Việt mới này vào Tokenizer gốc của LLaMA.
    3. Mở rộng kích thước ma trận Embedding đầu vào và tầng chiếu đầu ra lm_head của mô hình từ 32,00032,000 lên 52,00052,000.
    4. Khởi tạo các vector nhúng mới bằng trung bình cộng các vector con cũ để không làm hỏng tri thức gốc của mô hình.

5. Góc Ôn Luyện Phỏng Vấn (Interview Corner)

❓ Câu hỏi 1: Giải thích nguyên lý hoạt động của thuật toán Byte-Pair Encoding (BPE). Byte-level BPE (BBPE) giải quyết bài toán Out-Of-Vocabulary (OOV) như thế nào so với BPE ký tự truyền thống?

  • Gợi ý trả lời:
    • Nguyên lý BPE:
      • Là thuật toán nén và phân đoạn từ dạng Bottom-up. Bắt đầu từ danh sách các ký tự đơn lẻ.
      • Thuật toán liên tục duyệt qua ngữ liệu văn bản, đếm tần suất các cặp ký tự/từ con liền kề nhau và thực hiện phép hợp nhất (Merge) cặp có tần suất cao nhất thành một token mới. Quá trình lặp lại cho đến khi đạt kích thước từ vựng quy định.
    • Giải quyết bài toán OOV bằng Byte-level BPE:
      • Hạn chế của BPE ký tự: BPE truyền thống làm việc ở cấp độ ký tự Unicode. Do bảng mã Unicode có hơn 140,000140,000 ký tự khác nhau, tập huấn luyện không thể bao quát hết mọi ký tự hiếm, emoji hay ngôn ngữ đặc thù →\rightarrow Bất kỳ ký tự nào không có trong tập train đều bị biến thành token lỗi [UNK].
      • Đột phá của BBPE (GPT-2/4, LLaMA): Không khởi tạo bằng ký tự Unicode, BBPE sử dụng 256 giá trị Byte nhị phân cơ sở (từ 0x00 đến 0xFF) của mã hóa UTF-8 làm bảng chữ cái ban đầu.
      • Vì bất kỳ ký tự nào trong thế giới kỹ thuật số đều có thể biểu diễn thành một chuỗi các byte UTF-8, BBPE có thể mã hóa mọi văn bản, code, ký hiệu toán học hoặc emoji thành chuỗi byte mà hoàn toàn không bao giờ gặp lỗi Out-of-Vocabulary (Đạt 100%100\% tính toàn vẹn dữ liệu).

❓ Câu hỏi 2: Tại sao các mô hình ngôn ngữ lớn (LLMs) lại rất kém trong các tác vụ đếm ký tự (ví dụ: "Có bao nhiêu chữ 'r' trong từ 'strawberry'?") hoặc các phép tính số học số lớn (Arithmetic)? Nguyên nhân gốc rễ ở tầng Tokenizer là gì?

  • Gợi ý trả lời:
    • Bản chất vấn đề ở tầng Tokenizer:
      • Con người nhìn nhận từ ngữ dưới dạng chuỗi các chữ cái (s-t-r-a-w-b-e-r-r-y) và các con số dưới dạng các hàng đơn vị/chục/trăm/nghìn.
      • Tuy nhiên, LLM hoàn toàn không nhìn thấy các chữ cái hay con số rời rạc. Trước khi đi vào mạng Transformer, văn bản đã bị Tokenizer đóng gói thành các khối số nguyên ID đại diện cho cả một cụm từ con.
    • Phân tích trường hợp "strawberry":
      • Tokenizer của OpenAI (cl100k_base) chia từ "strawberry" thành 2 tokens duy nhất: ['straw', 'berry'] (tương ứng với 2 ID số nguyên: [496, 675]).
      • Mô hình Transformer chỉ nhận được 2 con số này. Đối với nó, việc đếm số chữ 'r' tương đương với việc hỏi: "Trong số 496 và số 675 có bao nhiêu chữ 'r'?". Mô hình phải tự dựa vào trí nhớ trong các tầng nơ-ron để đoán mò các chữ cái bên trong token →\rightarrow Rất dễ bị ảo giác và đếm sai.
    • Phân tích bài toán số học:
      • Tokenizer không chia các số theo giá trị toán học mà chia theo tần suất chuỗi ký tự. Ví dụ: Số 18274 bị chia thành ['18', '274'], trong khi số 9382 bị chia thành ['938', '2'].
      • Việc các chữ số bị gộp cụm bất đối xứng khiến cơ chế Self-Attention không thể căn thẳng hàng các vị trí hàng đơn vị, hàng chục để thực hiện phép cộng có nhớ như học sinh tiểu học.

❓ Câu hỏi 3: Hiện tượng "Token Inflation" (Lạm phát token) đối với các ngôn ngữ phi tiếng Anh (như Tiếng Việt) là gì? Nó gây ra những bất lợi kỹ thuật và tài chính nào, và các mô hình mới (LLaMA 3, Gemma) đã khắc phục bằng cách nào?

  • Gợi ý trả lời:
    • Bản chất hiện tượng Token Inflation:
      • Xảy ra khi một câu văn bằng ngôn ngữ A (ví dụ tiếng Việt) bị Tokenizer bóc tách thành số lượng token nhiều hơn gấp nhiều lần so với một câu có cùng ý nghĩa bằng tiếng Anh.
      • Nguyên nhân: Do tập dữ liệu huấn luyện Tokenizer ban đầu chủ yếu là tiếng Anh (>90%> 90\%), bộ từ vựng dành phần lớn không gian cho các từ tiếng Anh. Các từ tiếng Việt có dấu thanh bị coi là chuỗi hiếm và bị băm nhỏ thành từng âm tiết hoặc từng byte riêng lẻ.
    • 3 Bất lợi kỹ thuật và kinh tế nghiêm trọng:
      1. Chi phí API đắt gấp 2–3 lần: Người dùng phải trả tiền theo token cho cùng một nội dung thông tin.
      2. Độ dài ngữ cảnh (Context Window) bị thu hẹp: Một tài liệu tiếng Việt bị tốn 30,00030,000 tokens trong khi bản dịch tiếng Anh chỉ tốn 10,00010,000 tokens →\rightarrow Làm giảm 66%66\% khả năng đọc hiểu tài liệu dài của mô hình.
      3. Tăng độ trễ suy luận (High Latency): Vì LLM sinh từ tuần tự (Autoregressive), sinh nhiều token hơn đồng nghĩa với việc người dùng phải chờ lâu hơn để nhận câu trả lời.
    • Cách khắc phục của các mô hình thế hệ mới (LLaMA 3, Gemma):
      • Mở rộng kích thước từ vựng cực đại: LLaMA 3 nâng từ vựng lên 128,256128,256 tokens, Gemma nâng lên 256,000256,000 tokens.
      • Việc tăng kích thước từ vựng cho phép Tokenizer bổ sung hàng chục nghìn từ nguyên vẹn cho các ngôn ngữ khác (bao gồm tiếng Việt), giúp tỷ lệ nén token của tiếng Việt trên LLaMA 3 giảm được 30%−40%30\% - 40\% số lượng token so với LLaMA 2, giúp hệ thống chạy nhanh hơn, rẻ hơn và thông minh hơn.

6. Tóm Tắt Ghi Nhớ Nhanh (Key Takeaways)

  1. Tokenization là cây cầu nối giữa văn bản con người và toán học nhị phân của LLM; là nguồn gốc của các lỗi đếm chữ và tính toán số học.
  2. Byte-level BPE (BBPE) bắt đầu từ 256 Bytes UTF-8 cơ sở, loại bỏ hoàn toàn hiện tượng Out-Of-Vocabulary (Zero OOV).
  3. WordPiece tối ưu hóa Likelihood, trong khi SentencePiece (Unigram) xử lý khoảng trắng như một ký tự đặc biệt giúp hỗ trợ đa ngôn ngữ tự nhiên.
  4. Token Inflation khiến các ngôn ngữ có dấu (như tiếng Việt) tốn nhiều token hơn gấp 2–3 lần, làm tăng chi phí và thu hẹp Context Window.
  5. Các mô hình hiện đại (LLaMA 3, Gemma) khắc phục bằng cách mở rộng kích thước từ vựng lên 128k−256k128\text{k} - 256\text{k} tokens.
0Claps