Từ "Google" có thể được mã hóa chỉ bằng một token duy nhất ["Google"] hoặc hai token như ["Go", "ogle"]["G", "o", "o", "g", "l", "e"].
Điều này tạo ra hai vấn đề cộng hưởng:
Thứ nhất, lớp nhúng (embedding layer) không mã hóa đầy đủ thông tin ở cấp độ ký tự. Nghiên cứu cho thấy lớp nhúng của LLM chỉ lưu trữ thông tin ký tự một cách mạnh mẽ cho ký tự đầu tiên của mỗi token; sau đó, mức độ chi tiết ở cấp ký tự suy giảm nhanh chóng . Khi một mô hình cần đếm số chữ cái bên trong một token, nó phải tái tạo lại chuỗi ký tự từ một biểu diễn vốn không được thiết kế để bảo toàn thông tin đó. Các lớp Transformer sau này bù đắp được một phần – các nhà nghiên cứu đã quan sát thấy một điểm "đột phá" nơi mô hình có thể đánh vần chính xác một token – nhưng quá trình này không đáng tin cậy và rất mong manh
.
Thứ hai, các tokenizer cấp dưới từ (subword) gần như "không hay biết gì về cấu trúc bên trong của các token". Một nghiên cứu năm 2024 từ Arxiv đã đặt ra cụm từ "lời nguyền tokenization" (the curse of tokenization) để mô tả lỗ hổng này: các tokenizer vốn rất nhạy cảm với lỗi đánh máy, thay đổi độ dài, và mù tịt về thành phần bên trong của chính các token . Một từ như "journalism" có thể là một token duy nhất – do đó mô hình chưa bao giờ học cách phân tách nó thành
j-o-u-r-n-a-l-i-s-m ở cấp độ ký tự, và khi được yêu cầu đánh vần, nó chỉ đơn thuần là phỏng đoán.
Kết quả là những gì người dùng đã thấy với AI Overview của Google: một AI có thể tranh luận về triết học và viết mã code, nhưng lại khăng khăng rằng có hai chữ 'p' trong "Google" và từ "poop" chứa chính xác một chữ 'r' .
Nếu vấn đề nằm ở tokenization, giải pháp trực quan nhất là chuyển sang các mô hình xử lý trực tiếp ở cấp độ ký tự hoặc byte. Để mô hình "nhìn" thấy từng chữ cái. Hướng tiếp cận này đã tồn tại – các mô hình như ByT5 hoạt động trực tiếp trên luồng byte thô – nhưng không được áp dụng rộng rãi vì khiến chi phí vận hành tăng đáng kể .
Việc chuyển sang xử lý thuần túy ở cấp độ ký tự sẽ làm độ dài chuỗi đầu vào tăng lên gấp 3 đến 5 lần, kéo theo chi phí tính toán tăng tỉ lệ thuận và khiến mô hình khó học được các mối quan hệ ngữ nghĩa và phụ thuộc xa hơn rất nhiều . Các tokenizer cấp dưới từ (subword) chính là sự thỏa hiệp về hiệu năng đã giúp các LLM hiện đại trở nên khả thi: chúng nén văn bản thành các bộ từ vựng có kích thước dễ quản lý, đồng thời bảo toàn đủ ý nghĩa cho việc tạo sinh ngôn ngữ trôi chảy.
Giới nghiên cứu nhìn chung đồng ý rằng một tokenizer "hoàn hảo" rất có thể là không tồn tại . Các tokenizer "thường xuyên tạo ra các cách mã hóa không duy nhất" và tạo ra "sự không khớp trong biểu diễn" (representational mismatch) – một vấn đề mang tính kiến trúc sâu xa, chứ không phải một lỗi đơn giản có thể vá được
. Sự đánh đổi giữa độ chính xác ở cấp ký tự và sự trôi chảy về ngữ nghĩa dường như là một đặc điểm cơ bản của kiến trúc Transformer.
Những thất bại trong việc đánh vần này phơi bày một số giới hạn cấu trúc có ảnh hưởng vượt ra ngoài phạm vi AI Overview của Google.
LLM là những cỗ máy nhận diện mẫu hình (pattern matcher), không phải bộ xử lý ký hiệu (symbol manipulator). Đếm chữ cái là một tác vụ thuật toán tầm thường đối với bất kỳ máy tính nào chạy code truyền thống, nhưng các LLM không thực thi thuật toán – chúng dự đoán token có xác suất cao tiếp theo dựa trên các mẫu thống kê trong dữ liệu huấn luyện . Khi được hỏi về số lượng chữ cái, mô hình tạo ra một câu trả lời nghe có vẻ hợp lý dựa trên các liên kết đã học, chứ không phải thực hiện một phép đếm thực sự.
Sự tự tin không liên quan gì đến tính chính xác. AI đã tình nguyện đưa ra đáp án "hai" với sự trôi chảy hoàn hảo về mặt ngữ pháp, nhưng về mặt khách quan là hoàn toàn sai. Đây là một dấu hiệu đặc trưng của "ảo giác" LLM (hallucination): những kết quả đầu ra tự tin, nghe có vẻ hợp lý nhưng không có cơ chế xác minh tích hợp nào. Chính Google vào năm 2024 cũng đã thừa nhận rằng mặc dù AI Overviews được "xây dựng để chỉ hiển thị thông tin được hỗ trợ bởi các kết quả web hàng đầu", nhưng chúng vẫn có thể hiểu sai câu truy vấn hoặc các sắc thái trong ngôn ngữ .
Điểm mù này mang tính kiến trúc, không phải là ngẫu nhiên. Mọi LLM chính sử dụng tokenization cấp dưới từ – bao gồm các mô hình từ OpenAI, Anthropic và Meta – đều biểu hiện những điểm yếu tương tự trong các tác vụ ở cấp độ ký tự như đánh vần ngược một từ, đếm chữ cái, hay xử lý phép đảo chữ cái (anagram) . Việc mở rộng quy mô mô hình có cải thiện phần nào, nhưng thiên kiến này vẫn tồn tại dai dẳng
.
Những thất bại này có vẻ đáng xấu hổ – một AI không thể đánh vần nổi tên công ty mình – nhưng ngành công nghiệp không coi đó là một cuộc khủng hoảng, bởi giá trị to lớn của các LLM nằm ở chỗ khác.
Khả năng tạo văn bản trôi chảy, tóm tắt, lập luận, dịch thuật, tạo code – tất cả những năng lực này đến từ khả năng làm việc của mô hình ở cấp độ ngữ nghĩa (semantic), nơi mà sự trừu tượng hóa ở cấp token là một tính năng, không phải lỗi . Độ chính xác ở cấp độ ký tự đơn giản không phải là thứ mà các kiến trúc này được thiết kế để tối ưu hóa.
Giải pháp thực tế là định tuyến các truy vấn về chính tả và đếm sang các phần mềm dựa trên luật truyền thống thay vì yêu cầu LLM xử lý chúng. Một số triển khai của AI Overviews đã cố gắng phát hiện và chuyển hướng các truy vấn như vậy, dù những lỗi rất dễ thấy hồi tháng 5 năm 2026 cho thấy bản thân việc phát hiện vẫn chưa hoàn hảo . Một nghiên cứu riêng biệt cho thấy AI Overviews của Google trả lời sai các truy vấn đánh vần ngược tới 52% số lần – và chỉ 10% các từ có ba âm tiết trở lên được đảo ngược chính xác
.
Google đang nỗ lực sửa các vấn đề đếm ký tự cụ thể đã bị công khai . Nhưng với bất kỳ ai hiểu về sự đánh đổi của tokenization, bài học thực sự không phải là Google đã phát hành một sản phẩm lỗi. Mà là chính kiến trúc đang thúc đẩy cuộc cách mạng AI lại có một điểm mù cơ bản – và chưa ai tìm ra cách khắc phục nó mà không phải hy sinh những giá trị đã làm nên sức mạnh của các LLM ngay từ đầu.
Comments
0 comments