Với phần lớn mô hình ngôn ngữ lớn đa ngôn ngữ, cùng một nội dung viết bằng tiếng Việt thường được cắt thành nhiều token hơn so với khi viết bằng tiếng Anh. Có hai nguyên nhân chính. Ở tầng mã hoá, chữ Việt có dấu chiếm nhiều byte hơn chữ Latin trơn khi lưu theo UTF-8. Ở tầng từ vựng, bộ tách token của nhiều mô hình được xây chủ yếu từ dữ liệu tiếng Anh, nên dành ít “mảnh gộp sẵn” cho chữ Việt hơn. Mức chênh khác nhau rất nhiều giữa các mô hình, và các thế hệ bộ tách token mới đã thu hẹp khoảng cách đáng kể.
Chênh lệch này có hệ quả thật: tính phí theo token thì cùng một việc tốn hơn, giới hạn ngữ cảnh tính theo token thì nhét được ít tài liệu tiếng Việt hơn, mô hình sinh từng token một thì câu trả lời tiếng Việt ra chậm hơn. Bài này giải thích hai tầng nguyên nhân một cách cụ thể, chỉ cách tự đo trên mô hình mình dùng, và các cách giảm chi phí hợp lý mà không làm hỏng chất lượng tiếng Việt.
Tầng thứ nhất: chữ Việt chiếm bao nhiêu byte
Máy lưu văn bản dưới dạng byte. Chuẩn phổ biến nhất hiện nay là UTF-8, trong đó số byte của mỗi ký tự phụ thuộc vị trí của nó trong bảng Unicode. Chữ Việt rải ra ba vùng khác nhau.
| Nhóm ký tự | Ví dụ | Số byte trong UTF-8 |
|---|---|---|
| Chữ Latin không dấu, chữ số, dấu câu thông thường | a, b, t, n, 0–9 | 1 byte |
| Chữ có dấu thuộc vùng Latin-1 Supplement | à, á, â, ã, è, é, ê, ì, í, ò, ó, ô, õ, ù, ú, ý | 2 byte |
| Chữ thuộc vùng Latin Extended-A và Extended-B | ă, đ, ĩ, ũ, ơ, ư | 2 byte |
| Chữ có dấu thuộc vùng Latin Extended Additional | ạ, ả, ấ, ầ, ẩ, ẫ, ậ, ắ, ệ, ố, ồ, ợ, ữ… | 3 byte |
Áp vào một từ cụ thể: “Việt” gồm V, i, ệ, t, trong đó “ệ” chiếm 3 byte, nên cả từ là 6 byte cho 4 ký tự. “Người” có “ư” (2 byte) và “ờ” (3 byte), thành 8 byte cho 5 ký tự. Một đoạn văn tiếng Việt có dấu đầy đủ vì thế dài hơn đáng kể về số byte so với số ký tự nhìn thấy.
Nếu chữ ở dạng tổ hợp thay vì dựng sẵn, mỗi dấu kết hợp lại chiếm thêm byte riêng, làm chuỗi còn dài hơn. Đây là một lý do nữa để chuẩn hoá về dạng dựng sẵn (NFC) trước khi gửi văn bản cho mô hình.
Tầng thứ hai: bộ từ vựng của bộ tách token
Nhiều bộ tách token hiện đại hoạt động trên byte và dùng kỹ thuật gộp cặp (byte pair encoding hoặc các biến thể). Ý tưởng: bắt đầu từ từng byte, rồi lặp lại việc gộp những cặp đứng cạnh nhau xuất hiện nhiều nhất trong dữ liệu thành một mảnh mới, cho đến khi bộ từ vựng đạt kích thước định trước. Chuỗi nào càng phổ biến trong dữ liệu xây bộ tách, càng có khả năng được gộp thành một token duy nhất.
Nếu dữ liệu dùng để xây bộ tách chủ yếu là tiếng Anh, các từ tiếng Anh thông dụng sẽ thành token trọn vẹn, còn âm tiết tiếng Việt chỉ những âm tiết rất thường gặp như “của”, “và”, “là”, “không” mới được gộp trọn. Âm tiết ít gặp hơn, nhất là âm tiết có dấu 3 byte, bị cắt thành hai ba mảnh. Cộng với việc mỗi từ tiếng Việt thường gồm nhiều âm tiết có dấu cách ở giữa, tổng số token cho một câu tăng lên.
Các bộ tách token thế hệ mới thường có bộ từ vựng lớn hơn và dữ liệu xây dựng đa ngôn ngữ hơn, nên nhiều âm tiết tiếng Việt được gộp trọn. Các mô hình chuyên tiếng Việt, hay những mô hình được mở rộng bộ từ vựng cho tiếng Việt, đi xa hơn nữa. Vì vậy câu hỏi “tiếng Việt tốn hơn tiếng Anh bao nhiêu” không có một con số chung; nó phụ thuộc mô hình và phiên bản, và phải đo.
Hiện tượng này không riêng tiếng Việt. Một nghiên cứu năm 2023 của Petrov và cộng sự về các bộ tách token đã chỉ ra rằng cùng một nội dung có thể cần số token chênh lệch rất lớn giữa các ngôn ngữ, và gọi đó là một dạng bất bình đẳng giữa người dùng các ngôn ngữ. Các ngôn ngữ ít dữ liệu và dùng chữ viết ngoài bảng chữ Latin cơ bản thường chịu thiệt nhiều hơn.
Tốn token thì ảnh hưởng tới đâu
Chi phí. Các dịch vụ mô hình qua giao diện lập trình thường tính phí theo số token vào và ra. Cùng một bản tóm tắt hợp đồng, nếu bản tiếng Việt tốn nhiều token hơn, hoá đơn cao hơn tương ứng. Với ứng dụng xử lý khối lượng lớn, chênh lệch này đáng kể.
Độ dài ngữ cảnh hiệu dụng. Mỗi mô hình có giới hạn số token xử lý được trong một lần. Tài liệu tiếng Việt tốn token hơn nghĩa là nhét được ít trang hơn vào cùng một giới hạn. Với các hệ thống hỏi đáp trên tài liệu nội bộ, điều này ảnh hưởng tới việc chọn bao nhiêu đoạn tài liệu đưa vào mỗi câu hỏi.
Tốc độ. Mô hình sinh văn bản lần lượt từng token. Câu trả lời tiếng Việt cùng độ dài nội dung nhưng nhiều token hơn sẽ mất nhiều thời gian hơn để hiện ra hết.
Giới hạn độ dài đầu ra. Nhiều hệ thống đặt trần số token cho câu trả lời. Với tiếng Việt, trần đó tương ứng với ít chữ hơn, câu trả lời dễ bị cắt ngang khi chưa xong.
Chất lượng, phần còn tranh luận. Có lập luận cho rằng cắt chữ thành nhiều mảnh vụn làm mô hình khó học nghĩa hơn, và một số công trình về ngôn ngữ ít tài nguyên ủng hộ điều này. Nhưng chất lượng tiếng Việt của mô hình còn phụ thuộc lượng và chất lượng dữ liệu huấn luyện, nên khó tách riêng ảnh hưởng của bộ tách token. Đây là câu hỏi nghiên cứu còn mở.
Tự đo trên mô hình mình đang dùng
Không cần tin vào con số chung chung trên mạng. Có thể tự đo trong khoảng nửa giờ với các bước sau.
- Chọn ba đến năm đoạn văn tiếng Việt đại diện cho việc mình làm: một đoạn văn bản hành chính, một đoạn trò chuyện với khách, một đoạn tài liệu kỹ thuật. Dùng văn bản không chứa thông tin cá nhân hay bí mật.
- Chuẩn bị bản tiếng Anh tương đương của từng đoạn, dịch cẩn thận để nội dung tương đương.
- Dùng công cụ đếm token của nhà cung cấp mô hình (nhiều nhà cung cấp có trang đếm token hoặc trả số token trong kết quả gọi giao diện lập trình) để đếm số token mỗi đoạn ở cả hai ngôn ngữ.
- Tính tỷ lệ số token tiếng Việt chia số token tiếng Anh cho từng đoạn. Ví dụ giả định: đoạn hành chính cho tỷ lệ 1,4, đoạn trò chuyện 1,2.
- Lặp lại với hai ba mô hình đang cân nhắc. Tỷ lệ khác nhau giữa các mô hình chính là thông tin hữu ích khi chọn.
- Thử thêm hai biến thể của cùng đoạn tiếng Việt: dạng dựng sẵn và dạng tổ hợp, để thấy chuẩn hoá Unicode ảnh hưởng thế nào.
Kết quả đo chỉ đúng cho phiên bản mô hình tại thời điểm đo. Nhà cung cấp có thể đổi bộ tách token khi ra mô hình mới, nên nên đo lại khi chuyển phiên bản.
Giảm chi phí hợp lý, không hy sinh tiếng Việt
Đừng bỏ dấu để tiết kiệm. Văn bản không dấu đúng là ít byte và thường ít token hơn, nhưng mô hình phải đoán lại dấu, dễ hiểu sai và trả lời kém. Tiết kiệm vài phần trăm token mà mất chất lượng là lỗ.
Cân nhắc kỹ khi dịch sang tiếng Anh để tiết kiệm. Có người viết phần chỉ dẫn hệ thống bằng tiếng Anh để giảm token, giữ nội dung người dùng bằng tiếng Việt. Cách này đôi khi hợp lý với chỉ dẫn kỹ thuật dài, nhưng có rủi ro mô hình trả lời chêm tiếng Anh hoặc mất sắc thái xưng hô. Nếu làm, cần kiểm kỹ đầu ra. Còn dịch nội dung tài liệu tiếng Việt sang tiếng Anh rồi xử lý thì thêm một bước dễ sai, thường không đáng.
Cắt phần thừa trước khi gửi. Tài liệu nội bộ thường có phần đầu trang, chân trang, mục lục, đoạn lặp lại. Làm sạch trước khi đưa vào mô hình giảm token đáng kể mà không mất nội dung.
Chuẩn hoá Unicode. Đưa văn bản về dạng dựng sẵn trước khi gửi, tránh dấu tổ hợp làm tăng số byte và số token.
Chọn mô hình theo phép đo, không theo cảm giác. Một mô hình có giá mỗi token cao hơn nhưng cắt tiếng Việt gọn hơn có thể rẻ hơn tính theo việc. Phép đo ở phần trên cho con số để so.
Dùng lại kết quả. Với các câu hỏi lặp lại hay phần chỉ dẫn cố định, nhiều dịch vụ có cơ chế lưu đệm giúp giảm chi phí cho phần lặp. Kiểm tính năng hiện hành của dịch vụ mình dùng.
Những hiểu lầm hay gặp về token tiếng Việt
“Một token là một chữ.” Không đúng với cả tiếng Anh lẫn tiếng Việt. Token là mảnh do bộ tách quyết định: có thể là cả âm tiết “của”, một nửa âm tiết “nghiêng”, một dấu cách kèm vài chữ cái, hoặc chỉ một byte lẻ của chữ có dấu. Đếm chữ rồi suy ra token chỉ cho con số áng chừng.
“Tiếng Việt đơn âm tiết nên phải rất tiết kiệm token.” Âm tiết ngắn không có nghĩa là ít token. Mỗi âm tiết cách nhau một dấu cách, và âm tiết có dấu 3 byte không được gộp sẵn sẽ vỡ thành nhiều mảnh. Lợi thế “từ ngắn” chỉ thành hiện thực khi bộ từ vựng có sẵn các âm tiết đó.
“Mô hình tốn nhiều token tiếng Việt thì chắc chắn kém tiếng Việt.” Chưa chắc. Số token phản ánh cách cắt chữ, còn chất lượng phụ thuộc chủ yếu vào dữ liệu và quá trình huấn luyện. Có mô hình cắt tiếng Việt khá vụn mà vẫn viết tốt, và ngược lại. Phải thử cả chi phí lẫn chất lượng trên việc thật.
“Con số tỷ lệ đọc trên mạng áp dụng được cho mọi mô hình.” Mỗi mô hình, thậm chí mỗi phiên bản, có bộ tách riêng. Tỷ lệ đo cho mô hình này năm ngoái có thể đã sai với phiên bản hiện tại. Chỉ dùng con số tự đo, ghi rõ mô hình, phiên bản và ngày đo.
“Viết hoa hay viết thường không ảnh hưởng.” Có ảnh hưởng nhỏ: “Hà Nội” và “HÀ NỘI” là hai chuỗi byte khác nhau, dạng viết hoa toàn bộ ít gặp hơn trong dữ liệu nên thường bị cắt vụn hơn. Văn bản dán từ tài liệu in hoa toàn bộ, như tiêu đề công văn, có thể tốn token hơn bản viết thường.
Câu hỏi thường gặp
Tiếng Việt tốn token hơn tiếng Anh khoảng bao nhiêu lần?
Không có con số chung. Tỷ lệ phụ thuộc mô hình, phiên bản bộ tách token và loại văn bản. Bộ tách token thế hệ mới đã thu hẹp khoảng cách đáng kể so với trước. Cách đúng là tự đo trên vài đoạn văn bản đại diện cho việc của mình, so với bản tiếng Anh tương đương.
Vì sao chữ có dấu lại chiếm nhiều byte hơn?
Vì UTF-8 dùng 1 byte cho các ký tự cơ bản như chữ Latin không dấu, còn các ký tự nằm ở vùng xa hơn trong bảng Unicode cần 2 hoặc 3 byte. Phần lớn chữ Việt có dấu thanh nằm ở vùng Latin Extended Additional nên chiếm 3 byte mỗi ký tự.
Mô hình chuyên tiếng Việt có tốn ít token hơn không?
Thường có, vì bộ tách token của chúng được xây hoặc mở rộng với dữ liệu tiếng Việt, nên nhiều âm tiết được gộp trọn thành một token. Nhưng ít token hơn không tự động có nghĩa là trả lời tốt hơn; chất lượng còn phụ thuộc dữ liệu và kích thước mô hình, nên cần thử cả hai mặt.
Gõ không dấu cho chatbot có tiết kiệm được nhiều không?
Có thể giảm một phần token, nhưng mô hình phải đoán dấu và dễ hiểu sai câu hỏi, nhất là với tên riêng và thuật ngữ. Câu trả lời kém đi thường khiến phải hỏi lại, rốt cuộc tốn hơn. Gõ có dấu đầy đủ vẫn là lựa chọn nên dùng.
Dùng chatbot qua giao diện trò chuyện thông thường thì có cần quan tâm token không?
Ít cần hơn vì thường không tính tiền theo token trực tiếp. Tuy vậy giới hạn độ dài ngữ cảnh vẫn tính theo token, nên khi dán tài liệu tiếng Việt rất dài, mô hình có thể không đọc hết hoặc quên phần đầu. Chia tài liệu thành phần và tóm tắt từng phần là cách khắc phục.
Đếm token tiếng Việt bằng cách nào khi không biết lập trình?
Nhiều nhà cung cấp mô hình có trang đếm token trực tuyến: dán văn bản vào và xem số token. Mỗi mô hình có bộ tách riêng nên phải đếm bằng công cụ của đúng mô hình đó. Khi dán văn bản, nhớ bỏ thông tin cá nhân hay bí mật kinh doanh trước.