AI Google Tidak Bisa Mengeja Namanya Sendiri: Titik Buta Arsitektur yang Tak Terlihat

Kata "Google" mungkin di-encode sebagai satu token ["Google"] atau sebagai dua token seperti

["Go", "ogle"]

["G", "o", "o", "g", "l", "e"]

Ini menciptakan dua masalah yang saling memperparah:

Pertama, lapisan embedding tidak sepenuhnya menyimpan informasi tingkat karakter. Riset menunjukkan bahwa lapisan embedding LLM menyimpan informasi karakter yang kuat hanya untuk karakter pertama dari setiap token; setelah itu, detail tingkat karakter menurun drastis . Ketika sebuah model perlu menghitung huruf di dalam token, ia harus merekonstruksi urutan karakter dari representasi yang sejak awal tidak dirancang untuk melestarikannya. Lapisan Transformer selanjutnya mengompensasi sebagian—para peneliti mengamati titik "terobosan" yang jelas di mana model berhasil mengeja token dengan benar—tetapi prosesnya tidak bisa diandalkan dan rapuh .

Kedua, tokenizer sub-kata "sebagian besar tidak menyadari struktur internal token." Sebuah studi tahun 2024 dari Arxiv menciptakan istilah "kutukan tokenisasi" (the curse of tokenization) untuk menggambarkan kerentanan ini: tokenizer pada dasarnya sensitif terhadap kesalahan ketik, variasi panjang, dan buta terhadap komposisi internal token itu sendiri . Sebuah kata seperti "journalism" mungkin menjadi satu token—model tidak pernah belajar mengurainya menjadi j-o-u-r-n-a-l-i-s-m di tingkat karakter, jadi ketika diminta mengejanya, ia hanya menebak.

Hasilnya adalah apa yang dilihat pengguna pada AI Overview Google: sebuah AI yang bisa mendebat filsafat dan menulis kode dengan percaya diri, bersikeras bahwa ada dua 'p' di "Google" dan bahwa "poop" mengandung tepat satu 'r' .

Mengapa Memperbaiki Ini Lebih Sulit dari Kedengarannya

Jika masalahnya ada pada tokenisasi, perbaikan intuitifnya adalah menggunakan model tingkat karakter atau byte. Biarkan model melihat setiap huruf. Pendekatan itu memang ada—model seperti ByT5 beroperasi langsung pada byte mentah—tetapi belum diadopsi secara luas karena membuat model jauh lebih mahal untuk dijalankan .

Beralih ke pemrosesan tingkat karakter murni akan meledakkan panjang sekuens sekitar 3–5 kali lipat, meningkatkan biaya komputasi secara proporsional, dan membuat model jauh lebih sulit untuk mempelajari ketergantungan jarak jauh dan hubungan semantik . Tokenizer sub-kata adalah kompromi efisiensi yang membuat LLM modern praktis: mereka memampatkan teks ke dalam ukuran kosakata yang dapat dikelola sambil melestarikan cukup makna untuk menghasilkan bahasa yang fasih.

Para peneliti secara luas sepakat bahwa tokenizer yang "sempurna" kemungkinan besar tidak ada . Tokenizer "secara rutin menghasilkan penyandian yang tidak unik" dan menciptakan "ketidakcocokan representasional" yang bersifat sangat arsitektural—bukan bug sederhana yang bisa ditambal . Pertukaran antara presisi tingkat karakter dan kefasihan semantik tampaknya fundamental bagi arsitektur transformer.

Apa yang Diungkapkan Kesalahan Ini Tentang LLM

Kegagalan mengeja menyingkap beberapa keterbatasan struktural yang berlaku jauh melampaui AI Overview Google.

LLM adalah pencocok pola, bukan pemanipulasi simbol. Menghitung huruf adalah tugas algoritmik sepele bagi komputer mana pun yang menjalankan kode tradisional, tetapi LLM tidak mengeksekusi algoritma—mereka memprediksi token berikutnya yang paling mungkin berdasarkan pola statistik dalam data pelatihan mereka . Saat ditanya jumlah huruf, model menghasilkan jawaban yang terdengar masuk akal dari asosiasi yang dipelajari, bukan operasi penghitungan.

Kepercayaan diri tidak memiliki hubungan dengan kebenaran. AI itu secara sukarela menjawab "dua" dengan kefasihan tata bahasa yang sempurna, padahal secara objektif salah. Ini adalah ciri khas halusinasi LLM: keluaran yang percaya diri dan terdengar masuk akal tanpa mekanisme verifikasi bawaan. Google sendiri mengakui pada tahun 2024 bahwa meskipun AI Overviews "dibangun untuk hanya menampilkan informasi yang didukung oleh hasil web teratas," mereka masih bisa salah menafsirkan kueri atau nuansa bahasa .

Titik buta ini bersifat arsitektural, bukan insidental. Setiap LLM utama yang menggunakan tokenisasi sub-kata—termasuk model dari OpenAI, Anthropic, dan Meta—menunjukkan kelemahan serupa pada tugas tingkat karakter seperti mengeja kata mundur, menghitung huruf, atau menangani anagram . Memperbesar model sedikit membantu, tetapi biasnya tetap ada .

Mengapa Industri Tidak Menganggap Ini Mendesak

Kegagalan ini mungkin tampak memalukan—sebuah AI yang tidak bisa mengeja nama perusahaannya sendiri—tetapi industri tidak menganggapnya sebagai krisis karena nilai luar biasa dari LLM terletak di tempat lain.

Pembuatan teks yang fasih, peringkasan, penalaran, penerjemahan, pembuatan kode—semua kemampuan ini berasal dari kemampuan model untuk bekerja pada tingkat semantik, di mana abstraksi tingkat token adalah fitur, bukan bug . Presisi tingkat karakter bukanlah apa yang dioptimalkan oleh arsitektur ini.

Perbaikan praktisnya adalah mengarahkan kueri ejaan dan penghitungan ke perangkat lunak berbasis aturan tradisional alih-alih meminta LLM untuk menanganinya. Beberapa implementasi AI Overviews sudah berusaha mendeteksi dan mengalihkan kueri semacam itu, meskipun kesalahan yang sangat terlihat pada Mei 2026 menunjukkan bahwa deteksi itu sendiri masih belum sempurna . Sebuah studi terpisah menemukan bahwa AI Overviews Google menjawab kueri pembalikan ejaan dengan tidak benar sebanyak 52% dari keseluruhan waktu—dan hanya 10% kata dengan tiga suku kata atau lebih yang dibalik dengan benar .

Google sedang berupaya memperbaiki masalah penghitungan spesifik yang dipublikasikan . Tetapi bagi siapa pun yang memahami kompromi tokenisasi, pelajaran sebenarnya bukanlah bahwa Google meluncurkan produk yang bermasalah. Melainkan bahwa arsitektur yang mendukung revolusi AI memiliki titik buta mendasar—dan belum ada yang menemukan cara untuk memperbaikinya tanpa mengorbankan apa yang membuat LLM berharga sejak awal.