Mô hình lớn AI "Thuế Trung Quốc": Tại sao tiếng Trung tiêu tốn Token hơn tiếng Anh?

Tác giả: Thang Y Tao, nguồn: Geeker Park

Vài ngày sau khi Opus 4.7 vừa phát hành, trên X đã tràn ngập lời than phiền. Có người nói một lần đối thoại đã dùng hết hạn mức session của cô ấy, có người nói chi phí chạy cùng một đoạn mã đã tăng gấp đôi so với tuần trước; còn có người đăng tải ảnh chụp màn hình cho thấy Max 200 USD của họ chỉ chưa đầy hai giờ đã chạm giới hạn.

Nhà phát triển độc lập BridgeMind thừa nhận Claude là mô hình tốt nhất thế giới, nhưng đồng thời cũng là mô hình đắt nhất. Gói Max của anh ấy dùng chưa tới hai giờ đã hết hạn mức, may mắn là — anh ấy đã mua hai gói.|Nguồn hình ảnh: X@bridgemindai

Giá của Anthropic không đổi, vẫn là 5 USD cho mỗi triệu token đầu vào, 25 USD cho đầu ra. Nhưng phiên bản này đã giới thiệu tokenizer mới, đồng thời Claude Code đã nâng effort mặc định từ high lên xhigh. Hai thay đổi cộng hưởng, lượng token tiêu thụ cho cùng một công việc đã tăng gấp 2 đến 2.7 lần so với trước.

Trong các cuộc thảo luận này, tôi thấy có hai cách nói liên quan đến tiếng Trung. Một là: tiếng Trung gần như không tăng giá dưới tokenizer mới, người dùng Trung Quốc đã tránh được đợt tăng giá này. Cách khác còn thú vị hơn: Văn cổ còn tiết kiệm token hơn cả tiếng Trung hiện đại, dùng văn ngôn để đối thoại với AI có thể tiết kiệm chi phí.

Cách nói thứ hai ngụ ý rằng Claude đã tối ưu hóa cho tiếng Trung, nhưng trong tài liệu phát hành của Anthropic, không đề cập đến bất kỳ điều chỉnh nào liên quan đến tiếng Trung.

Cách nói thứ hai lại khó lý giải hơn. Văn cổ rõ ràng khó hiểu hơn tiếng Trung hiện đại đối với người đọc, vậy một đoạn văn phức tạp hơn về mặt ngữ nghĩa, làm sao lại dễ hơn cho AI?

Vì vậy, tôi đã tiến hành một thử nghiệm, dùng 22 đoạn văn song song (gồm tin tức thương mại, tài liệu kỹ thuật, văn cổ, hội thoại đời thường, v.v.), cùng lúc đưa vào 5 tokenizer (Claude 4.6 và 4.7, GPT-4o, Qwen 3.6, DeepSeek-V3), đọc số token của mỗi đoạn trong từng mô hình, so sánh theo chiều ngang.

Các đoạn văn thử nghiệm:

  1. Hội thoại đời thường tiếng Anh và tiếng Trung (du lịch, hỏi giúp trên diễn đàn, yêu cầu viết lách)

  2. Tài liệu kỹ thuật tiếng Anh và tiếng Trung (tài liệu Python, tài liệu của Anthropic)

  3. Tin tức tiếng Anh và tiếng Trung (tin chính trị NYT, tin thương mại NYT, tuyên bố chính thức của Apple)

  4. Đoạn văn văn học cổ và tiếng Trung cổ (《出师表》《Đạo Đức Kinh》)

Sau khi hoàn thành, cả hai cách nói đều được phần nào xác thực, nhưng thực tế còn phức tạp hơn lời đồn.

1. Thuế tiếng Trung


Trước tiên, kết luận:

  1. Trên Claude và GPT, tiếng Trung luôn đắt hơn tiếng Anh

  2. Trên Qwen và DeepSeek, tiếng Trung lại rẻ hơn tiếng Anh

  3. Lần nâng cấp tokenizer của Opus 4.7 gây chấn động, lạm phát gần như chỉ xảy ra với tiếng Anh, tiếng Trung gần như không đổi

Cụ thể số liệu. Các mô hình toàn bộ dòng Opus 4.7 (bao gồm Opus 4.6, Sonnet, Haiku), đều dùng chung một tokenizer. Trong tokenizer này, lượng token tiêu thụ cho tiếng Trung cao hơn rõ rệt so với cùng lượng nội dung tiếng Anh, tỷ lệ cn/en dao động từ 1.11× đến 1.64×.

Tình huống cực đoan nhất xuất hiện trong các tin thương mại theo phong cách NYT: cùng một đoạn nội dung, tiếng Trung tiêu thụ nhiều hơn 64% token, tương đương trả thêm 64% tiền.

Opus 4.6 và các mô hình Claude trước đó, lượng token tiếng Trung tiêu thụ cao rõ rệt so với các mô hình khác (khoanh đỏ)

Tình huống cực đoan nhất là trong các tin thương mại theo phong cách NYT: cùng một đoạn nội dung, tiếng Trung tiêu thụ nhiều hơn 64% token (khoanh xanh)

Tokenizer o200k của GPT-4o tốt hơn, tỷ lệ cn/en phần lớn nằm trong khoảng 1.0 đến 1.35×, một số ít thấp hơn 1.0. Tiếng Trung vẫn nói chung đắt hơn, nhưng chênh lệch nhỏ hơn nhiều so với Claude.

Dữ liệu của các mô hình nội địa Qwen 3.6 và DeepSeek-V3 thì hoàn toàn ngược lại. Tỷ lệ cn/en của chúng đều thấp hơn 1, nghĩa là cùng nội dung, tiếng Trung lại tiết kiệm token hơn tiếng Anh. DeepSeek thấp nhất đạt 0.65×, cùng một đoạn, tiếng Trung rẻ hơn tiếng Anh một phần ba.

Lần nâng cấp tokenizer của Opus 4.7 gần như chỉ gây lạm phát với tiếng Anh. Token tiếng Anh tăng từ 1.24× đến 1.63×, còn tiếng Trung vẫn giữ nguyên gần như 1.000×, hầu như không đổi. Các hóa đơn của các nhà phát triển tiếng Anh ban đầu đã có chấn động, nhưng người dùng Trung Quốc thực sự không cảm nhận được. Nguyên nhân có thể là tiếng Trung đã bị cắt thành từng từ đơn trong phiên bản cũ, không gian để chia nhỏ là rất hạn chế.


So sánh Opus 4.7 và 4.6, lượng token tiếng Anh tiêu thụ nhiều hơn, còn tiếng Trung thì không đổi

Trong quá trình thử nghiệm, tôi còn để ý một điều. Sự khác biệt về tiêu thụ token không chỉ là vấn đề hóa đơn, nó còn ảnh hưởng trực tiếp đến kích thước không gian làm việc. Cùng một khung nội dung khoảng 200k, dùng tokenizer cũ của Claude để nạp dữ liệu tiếng Trung, lượng nội dung có thể chứa ít hơn 40% đến 70% so với tiếng Anh.

Ví dụ, khi yêu cầu AI phân tích một tài liệu dài hoặc tóm tắt một cuộc họp, người dùng Trung Quốc có thể cung cấp ít tài liệu hơn, mô hình tham khảo ngắn hơn. Kết quả là, họ trả nhiều tiền hơn, nhưng nhận được không gian làm việc nhỏ hơn.

Nhìn chung, bốn bộ dữ liệu này cho thấy một câu hỏi tự nhiên nổi lên:

Tại sao cùng một nội dung, đổi ngôn ngữ lại khác nhau về token? Tại sao Claude và GPT tiếng Trung đắt hơn, Qwen và DeepSeek tiếng Trung lại rẻ hơn?

Câu trả lời nằm trong khái niệm tokenizer (phân đoạn từ) đã đề cập nhiều lần ở trên.

2. Một chữ Hán có thể cắt thành mấy phần?


Trước khi mô hình đọc bất kỳ chữ nào, nó sẽ dùng tokenizer để cắt thành từng token. Bạn có thể tưởng tượng tokenizer như một “máy cắt ghép khối xây dựng” của AI. Bạn nhập một câu, nó sẽ phân chia thành các khối xây dựng tiêu chuẩn (tức token). Mô hình AI không nhìn chữ, chỉ nhận mã số của các khối này. Bạn dùng nhiều khối, trả nhiều tiền.

Tiếng Anh cắt khá trực quan, ví dụ “intelligence” gần như là một token, “information” cũng vậy, mỗi từ là một đơn vị tính phí.

Nhưng tiếng Trung đến bước này lại gặp vấn đề. Khi gửi cùng một câu “人工智能正在重塑全球的信息基础设施” vào GPT-4 với cl100k tokenizer và Qwen 2.5 với tokenizer, kết quả cắt ra hoàn toàn khác nhau.

GPT-4 cơ bản tách mỗi chữ Hán thành một token; Qwen thì sẽ nhận diện thành một từ, ví dụ “人工智能” chỉ tính là một token, thay vì bốn.


Cùng một câu 16 chữ Hán, GPT-4 cắt ra 19 token, Qwen chỉ 6 token.

Tại sao lại cắt như vậy? Nguyên nhân nằm trong thuật toán gọi là BPE (Byte Pair Encoding).

BPE hoạt động bằng cách thống kê tần suất xuất hiện của các tổ hợp ký tự trong dữ liệu huấn luyện, rồi hợp nhất các tổ hợp phổ biến thành một token, đưa vào từ điển.

Trong thời kỳ GPT-2, phần lớn dữ liệu huấn luyện là tiếng Anh. Các tổ hợp chữ cái như th, ing, tion xuất hiện nhiều, nhanh chóng được hợp nhất thành token. Trong dữ liệu tiếng Trung, tần suất xuất hiện của các ký tự rất thấp, không đủ để đưa vào từ điển, chỉ có thể xử lý như byte nguyên thủy, mỗi chữ Hán chiếm 3 byte, thành 3 token.

BPE dựa trên tần suất ký tự trong dữ liệu huấn luyện để quyết định hợp nhất. Trong dữ liệu tiếng Anh, ký tự tiếng Trung UTF-8 không thể hợp nhất thành chữ hoàn chỉnh.

Sau này, GPT-4 với bộ từ điển cl100k đã mở rộng, các chữ Hán phổ biến bắt đầu được đưa vào, mỗi chữ thường chỉ còn 1 đến 2 token, nhưng hiệu quả vẫn chưa bằng tiếng Anh.

Với bộ từ điển o200k của GPT-4o, hiệu quả tiếng Trung lại tiến thêm một bước. Điều này cũng giải thích vì sao trong dữ liệu ban đầu, tỷ lệ cn/en của GPT-4o thấp hơn của Claude.

Qwen và DeepSeek, là các mô hình nội địa, từ đầu đã đưa nhiều chữ Hán phổ biến và nhóm từ thường xuyên thành các từ ghép, từ đó mỗi chữ thành một token, hiệu quả tăng gấp đôi hoặc hơn thế.

Hình minh họa cách phân tách của cùng một câu trong các tokenizer khác nhau

Đây chính là lý do tỷ lệ cn/en của chúng thấp hơn 1, bởi vì nội dung chữ Hán vốn đã có mật độ thông tin cao hơn từ tiếng Anh, khi tokenizer không còn chia nhỏ chữ Hán nữa, lợi thế tự nhiên này lộ rõ.

Vì vậy, sự khác biệt trong bốn bộ dữ liệu trên không nằm ở khả năng của mô hình, mà nằm ở trong từ điển tokenizer đã dành bao nhiêu chỗ cho tiếng Trung.

Claude và các mô hình GPT sơ khai xây dựng từ điển dựa trên tiếng Anh làm chuẩn, tiếng Trung là phần thêm vào sau; Qwen và DeepSeek từ đầu đã coi tiếng Trung là ngôn ngữ mặc định. Sự khác biệt này dẫn đến số token, hóa đơn, kích thước cửa sổ ngữ cảnh đều bị ảnh hưởng.

3. Thật sự cổ văn rẻ hơn không?


Xem lại truyền đồn thứ hai ban đầu: Văn cổ tiết kiệm token hơn tiếng Trung hiện đại.

Dữ liệu xác nhận điều này. Trong thử nghiệm, tỷ lệ cn/en của các đoạn văn cổ đều thấp hơn 1, trên tất cả năm tokenizer. Cùng một nội dung, bản cổ còn tiêu thụ ít token hơn cả bản dịch tiếng Anh.

Trong tất cả các mô hình, văn cổ tiêu thụ ít token hơn rõ rệt so với tiếng Trung hiện đại, thậm chí còn ít hơn cả tiếng Anh.

Nguyên nhân cũng không phức tạp, chữ cổ cực kỳ súc tích. “学而不思则罔,思而不学则殆” chỉ có 12 chữ. Dịch sang tiếng hiện đại là “Chỉ học mà không suy nghĩ sẽ mơ hồ, chỉ suy nghĩ mà không học sẽ gặp nguy”, số chữ gấp đôi, token tự nhiên cũng gấp đôi.

Hơn nữa, các chữ phổ biến trong văn cổ (之、也、者、而、不) đều là ký tự tần suất cao, có vị trí riêng trong từ điển tokenizer, không bị chia nhỏ thành byte. Vì vậy, văn cổ thực sự hiệu quả trong mã hóa.

Nhưng ẩn chứa một cái bẫy ở đây.

Token của văn cổ tiết kiệm trong mã hóa, nhưng khả năng suy luận của mô hình không giảm. Ví dụ, chữ “罔” một chữ, mô hình cần xác định nó trong ngữ cảnh này mang ý nghĩa “mơ hồ”, “bị che khuất” hay “không có”. Tiếng Trung hiện đại có thể diễn đạt ý này bằng 26 chữ, còn văn cổ phải dùng cách diễn đạt dài hơn, khiến mô hình phải làm việc nhiều hơn để hiểu.

Nói cách khác, token tiết kiệm, nhưng tiêu hao trong suy luận lại tăng, độ chính xác trong hiểu biết cũng giảm. Không thể tính toán chính xác được.

Văn cổ khiến tôi nhận ra rằng, số lượng token không thể nói lên tất cả. Nhưng theo hướng đó, còn có một thứ tôi đã bỏ qua.

Trước đó, đã đề cập rằng tokenizer thời GPT-2 sẽ chia chữ “人” thành ba byte UTF-8, còn GPT-4 mở rộng từ điển, chữ phổ biến thành một token, Qwen thì ghép “人工智能” thành một token.

Theo trực giác, đây là quá trình cải tiến liên tục: hợp nhất càng nhiều, hiệu quả càng cao, mô hình cũng hiểu rõ hơn.

Nhưng thực sự như vậy không hẳn. Chúng ta hãy nhớ lại cách chúng ta nhận biết chữ Hán.

Chữ Hán là chữ tượng hình, hơn 80% trong chữ Hán hiện đại là chữ hình thanh, gồm một bộ phận biểu ý và một bộ phận biểu âm. Ví dụ, chữ “氵” liên quan đến chất lỏng, “木” liên quan đến thực vật, “火” liên quan đến nhiệt lượng. Bộ phận chữ là những dấu hiệu cơ bản nhất để con người nhận biết chữ, ai không biết “焱” thì nhìn thấy 3 “火” cũng đoán ra liên quan đến lửa.

Vì bộ phận chữ là những dấu hiệu cơ bản nhất, con người sẽ dựa vào cấu trúc để suy ra ý nghĩa chung, rồi kết hợp ngữ cảnh để hiểu rõ nghĩa cụ thể.


Lửa, ngọn lửa, ánh sáng, trong văn viết và tên người thường thấy, mang ý nghĩa sáng rực, nhiệt huyết.

Nhưng trong từ điển tokenizer, “焱” sẽ là một mã số. Giả sử nó là số 38721, đại diện cho một vị trí trong từ điển. Mô hình sẽ dùng mã này để tra ra một vector số, dùng để biểu diễn chữ “焱”.

Số mã không mang bất kỳ thông tin nào về cấu trúc bên trong của chữ. 38721 và 38722, đối với mô hình, giống như 1 và 10000. Vì vậy, “cấu trúc chữ Hán” bị đóng gói trong một mã số không rõ ràng. Việc ba “火” chồng chất nhau trong mã số là không tồn tại.

Tất nhiên, mô hình có thể học gián tiếp qua dữ liệu huấn luyện rằng “焱”, “炎”, “灼” thường xuất hiện trong các ngữ cảnh tương tự, nhưng con đường này còn gián tiếp hơn so với việc trực tiếp dựa vào thông tin bộ phận.

Vậy, mô hình có thể từ các byte đã chia nhỏ, “nhìn thấy” các dấu hiệu tương tự bộ phận rồi sau đó tái hợp trong các lớp tính toán tiếp theo không? Con đường này dù tốn nhiều token, chi phí cao, nhưng có thể hiệu quả hơn trong hiểu biết ngữ nghĩa so với việc chỉ nhận một mã số không rõ ràng?

Một bài báo đăng trên MIT Press “Computational Linguistics” năm 2025 (tựa đề “Tokenization Changes Meaning in Large Language Models: Evidence from Chinese”) đã trả lời câu hỏi này.

4. Mảnh ghép chứa bộ phận chữ


Tác giả bài báo David Haslett nhận ra một sự trùng hợp lịch sử.

Thập niên 1990, Liên minh Unicode phân phối mã UTF-8 cho chữ Hán theo thứ tự sắp xếp theo bộ phận chữ. Các chữ cùng bộ phận sẽ có mã UTF-8 gần nhau. Ví dụ, “茶” và “茎” đều chứa bộ “艹” (bộ cỏ), mã UTF-8 của chúng bắt đầu bằng các byte giống nhau. “河” và “海” đều chứa bộ “氵”, mã byte cũng chung phần đầu.


UTF-8 theo thứ tự bộ phận chữ trong từ điển, các chữ cùng bộ phận sẽ có mã gần nhau|Nguồn hình: Github

Điều này có nghĩa là, khi tokenizer chia chữ Hán thành ba byte, các chữ cùng bộ phận sẽ chia sẻ byte đầu tiên. Trong quá trình huấn luyện, mô hình sẽ thấy các mẫu byte này lặp đi lặp lại, có khả năng học được rằng “chữ có cùng bộ phận chữ” thường mang ý nghĩa chung. Điều này gần giống với cách con người dựa vào bộ phận để suy đoán ý nghĩa.

Haslett đã thiết kế ba thí nghiệm để xác minh điều này.

Thí nghiệm đầu tiên hỏi GPT-4, GPT-4o và Llama 3: “‘茶’ và ‘茎’ có cùng bộ phận chữ không?”

Thí nghiệm thứ hai yêu cầu mô hình đánh giá độ tương đồng ý nghĩa của hai chữ Hán.

Thí nghiệm thứ ba yêu cầu mô hình “tìm ra các chữ khác loại” để loại trừ.

Mỗi thí nghiệm kiểm soát hai biến: liệu hai chữ có thực sự chia sẻ bộ phận chữ, và liệu hai chữ có cùng token đầu tiên trong tokenizer hay không. Thiết kế 2×2 này giúp phân biệt rõ ảnh hưởng của bộ phận chữ và của token.

Kết quả của ba thí nghiệm đều nhất quán: khi chữ Hán bị cắt thành nhiều token (ví dụ như 89% chữ bị chia thành nhiều token trong tokenizer cũ của GPT-4), mô hình nhận diện chia sẻ bộ phận chữ chính xác hơn; khi chữ được mã hóa thành một token duy nhất (như tokenizer mới của GPT-4o, chỉ còn 57% chữ bị chia thành nhiều token), độ chính xác giảm đi.

Nói cách khác, giả thuyết ban đầu đã đúng. Chia nhỏ chữ Hán ra, chi phí cao hơn, nhưng trong chuỗi byte, vẫn còn lưu lại dấu vết của bộ phận chữ, mô hình thực sự học được một số điều. Trong khi mã hóa chữ thành một token nguyên vẹn, chi phí giảm, nhưng thông tin về bộ phận chữ bị đóng gói trong một mã số không rõ ràng, mô hình không thể lấy ra từ chuỗi byte.

Cần nhấn mạnh, kết luận này chỉ giới hạn trong các nhiệm vụ phân tích hình dạng chữ và ý nghĩa phân đoạn nhỏ, không phản ánh toàn diện khả năng hiểu tiếng Trung, suy luận logic, hay khả năng sinh văn bản dài của mô hình. Đồng thời, so sánh giữa GPT-4 và GPT-4o, ngoài khác biệt về phân đoạn, kiến trúc mô hình, dữ liệu huấn luyện, tham số đều có sự khác biệt rõ rệt, không thể quy hết sự thay đổi chính xác 100% về tỷ lệ chính xác này vào việc điều chỉnh phân đoạn.

Phát hiện này còn được xác nhận qua thực nghiệm kỹ thuật. Năm 2024, một nghiên cứu về GPT-4o cho thấy, khi tokenizer mới của GPT-4o hợp nhất một số ký tự Trung Quốc thành một token dài, mô hình lại xuất hiện lỗi hiểu. Khi các nhà nghiên cứu dùng bộ phân tách từ tiếng Trung chuyên nghiệp để tách các token dài này ra, độ chính xác hiểu lại phục hồi.

Hiện tại, ngành mô hình lớn toàn cầu vẫn thống nhất rằng, tối ưu hóa tokenizer cho ngôn ngữ mục tiêu, dùng phân đoạn nguyên từ hoặc chữ, sẽ nâng cao rõ rệt hiệu năng của mô hình. Phương pháp này không chỉ giảm đáng kể token, tăng hiệu quả của cửa sổ ngữ cảnh, mà còn rút ngắn chuỗi, giảm độ trễ suy luận, tăng độ ổn định khi xử lý văn bản dài. Các phát hiện về lợi thế trong các nhiệm vụ phân đoạn nhỏ không thể phủ nhận lợi ích trong hầu hết các ứng dụng NLP tiếng Trung.

Tuy nhiên, điều này vẫn chạm vào một vấn đề nan giải của hệ thống lớn: Bạn có thể tối ưu phần đã thiết kế, nhưng không thể tối ưu phần bạn không biết mình có. Việc Liên minh Unicode sắp xếp theo bộ phận chữ để dễ tra cứu, hay BPE chia nhỏ chữ Hán thành byte vì tần suất thấp, đều là các quyết định kỹ thuật không liên quan trực tiếp đến ý nghĩa, nhưng lại tạo ra các kênh ngữ nghĩa mà không ai dự tính trước.

Và khi các kỹ sư mới “cải tiến” tokenizer, hợp nhất chữ Hán thành chữ nguyên, họ vô tình đã chặn mất một con đường ngữ nghĩa tiềm tàng. Hiệu quả tăng, chi phí giảm, nhưng một số thứ lại âm thầm biến mất, mà không có cảnh báo nào.

Vì vậy, câu chuyện phức tạp hơn nhiều so với việc “tiếng Trung trong AI phải trả nhiều tiền hơn”. Mỗi tokenizer đều đang tối ưu cho một giá trị mặc định nào đó, và cái giá phải trả nằm ở chỗ khác.

5. Lý Tư Đường


Chi phí thích nghi tiếng Trung với hạ tầng kỹ thuật phương Tây không bắt đầu từ thời AI.

Tháng 1 năm 2025, cư dân New York Nelson Felix đăng vài bấm hình lên nhóm Facebook về máy đánh chữ dành cho người yêu thích máy đánh chữ. Ông phát hiện trong di vật của vợ chồng tổ tiên có một chiếc máy đánh chữ có khắc chữ Trung Quốc, không rõ nguồn gốc. Nhanh chóng có hàng trăm bình luận.


Nhà Hán học Stanford, Mạc Lê Ninh (Thomas S. Mullaney) nhìn ảnh liền nhận ra, đó chính là “Máy đánh chữ sáng rõ” do Lý Ngữ Đường phát minh năm 1947, là nguyên mẫu duy nhất đã mất tích gần 80 năm. Cùng năm 4 tháng sau, Felix và vợ bán máy cho Thư viện Stanford.

Vấn đề của “Máy đánh chữ sáng rõ” và vấn đề tokenizer ngày nay về cơ bản giống nhau: Làm thế nào để tích hợp tiếng Trung hiệu quả vào hạ tầng kỹ thuật do phương Tây thiết kế.

Trong thập niên 1940, máy đánh chữ tiếng Anh có 26 phím chữ cái, mỗi phím một chữ, đơn giản rõ ràng. Tiếng Trung có hàng nghìn chữ thông dụng, không thể một phím một chữ. Thời đó, máy đánh chữ Trung Quốc là một bàn chữ khổng lồ, xếp hàng nghìn ký tự chì, người đánh máy phải chọn từng chữ một, mỗi phút chỉ được mười mấy chữ.

Năm 1899, nhà truyền giáo Mỹ Sheffield phát minh ra máy đánh chữ tiếng Trung, là bản ghi chép sớm nhất về máy đánh chữ Trung Quốc|Nguồn: Wikipedia

Lý Ngữ Đường đã tiêu tốn 12 vạn USD để nghiên cứu, gần như phá sản, thuê công ty Carl E. Krum của New York chế ra một chiếc máy đánh chữ Trung Quốc chỉ có 72 phím. Nguyên lý là phân tách chữ Hán theo cấu trúc hình dạng, phím trên chọn phần trên của chữ, phím dưới chọn phần dưới, các chữ候 chọn trong một cửa sổ gọi là “mắt ma thuật”, rồi nhấn số để chọn. Mỗi phút có thể in 40-50 chữ, hỗ trợ hơn 8000 ký tự thông dụng.

(Trái) Cửa sổ thủy tinh trong suốt gọi là “mắt ma thuật”; (phải) cấu trúc bên trong máy đánh chữ sáng rõ|Nguồn: Facebook

Triệu Nguyên Nhiên nhận xét: “Dù người Trung Quốc hay người Mỹ, chỉ cần học một chút là có thể làm quen với bàn phím này. Tôi nghĩ đây chính là chiếc máy đánh chữ chúng ta cần.”

Về mặt kỹ thuật, máy đánh chữ sáng rõ là một đột phá, nhưng về mặt thương mại thì thất bại.

Khi Lý Ngữ Đường trình diễn cho các quản lý của Remington, máy gặp sự cố, nhà đầu tư mất hứng, lại do giá thành cao và ông bị đứt dây chuyền tài chính, không thể sản xuất hàng loạt. Năm 1948, ông bán nguyên mẫu và quyền thương mại cho công ty Mergenthaler Linotype. Công ty này cuối cùng bỏ cuộc sản xuất hàng loạt, nguyên mẫu bị một nhân viên đem về Long Island, sau đó mất tích, đến năm 2025 mới được phát hiện trở lại.

Trong cuốn “Chữ viết máy của Trung Quốc” của Mạc Lê Ninh, ông có nhận định: “Máy đánh chữ sáng rõ không hề thất bại”. Là một sản phẩm của thập niên 1940, nó thực sự thất bại. Nhưng về mặt tương tác người-máy, nó đã thành công.

Lý Ngữ Đường lần đầu tiên biến việc “đánh máy” thành “truy xuất và chọn lựa”. Ba hàng phím để định vị chữ, chọn từ các chữ trong danh sách. Đây chính là logic nền tảng của tất cả các phương pháp nhập liệu tiếng Trung hiện đại. Từ khoá, bộ phím Cánh, Wubi, Sogou Pinyin, đều là hậu duệ của máy đánh chữ sáng rõ.

Chiếc máy đánh chữ vượt qua gần tám mươi năm này, và cuộc thảo luận về tokenizer ngày nay, đều ẩn chứa một quy luật lịch sử nào đó. Chữ Trung luôn đối mặt với một vấn đề:

Làm thế nào để kết nối với hạ tầng dựa trên bảng chữ cái La Mã.

Điều thú vị là, trong quá trình tìm kiếm này, đầy những trùng hợp không do con người dự tính. Thứ tự sắp xếp của Unicode để tiện tra cứu, cùng với cách chia nhỏ chữ Hán thành byte của BPE, vô tình tạo ra một con đường ngữ nghĩa trong “hộp đen” của mạng nơ-ron, phản ánh quá trình nhận biết chữ của con người. Và khi các kỹ sư muốn “giảm thuế tiếng Trung”, chủ động ghép chữ Hán thành chữ nguyên, thì con đường ngữ nghĩa này cũng bị đóng lại.

Lịch sử không phải là một đường thẳng tiến hóa, mà là một dòng chảy biến dạng liên tục dưới áp lực của các giới hạn.

Một số khả năng là do thiết kế, một số chỉ là ngẫu nhiên không bị loại bỏ.

Xem bản gốc
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
  • Phần thưởng
  • Bình luận
  • Đăng lại
  • Retweed
Bình luận
Thêm một bình luận
Thêm một bình luận
Không có bình luận
  • Ghim