Aplikasi language model biasanya memperlakukan prompt sebagai teks: berikan sebuah prefix, lalu minta model melanjutkannya. Namun, model melihat sesuatu yang lebih spesifik. Tokenizer terlebih dahulu mengubah teks tersebut menjadi token, dan akhir prompt memaksa token terakhir berhenti tepat pada posisi itu.

Detail ini dapat berpengaruh ketika prompt berakhir pada posisi karakter yang, jika prompt dan continuation ditokenisasi bersama, seharusnya berada di dalam token yang lebih besar. Masalah batas tokenisasi, yang juga disebut partial token problem, dapat membuat continuation yang sebenarnya natural menjadi sangat tidak mungkin.

Masalah ini mudah terlewat karena teks yang terlihat tetap masuk akal. Dampaknya terutama relevan untuk prefix completion, code completion, constrained generation, dan bahasa yang batas katanya tidak selalu ditandai whitespace. Artikel ini membangun mental model untuk memahami kegagalan tersebut, menunjukkan cara mengujinya, dan membahas trade-off beberapa mitigasi praktis.

Mulai dari perbedaan antara teks dan token

Misalkan aplikasi meminta model melengkapi teks berikut:

natural language processin

Manusia akan menganggap g sebagai karakter berikutnya yang masuk akal. Namun, subword tokenizer tidak harus merepresentasikan dua situasi berikut dengan cara yang sama:

tokenize("natural language processin") + tokenize("g")

dan:

tokenize("natural language processing")

Kata lengkap tersebut mungkin memiliki tokenisasi yang melintasi titik akhir prompt. Begitu aplikasi mengirim processin sebagai prompt lengkap, tokenizer harus mengakhiri sebuah urutan token di sana. Model kemudian diminta melanjutkan dari batas token yang dipaksakan, bukan dari urutan token yang akan dilihatnya jika string lengkap ditokenisasi sekaligus.

Pelajaran pentingnya bukan bahwa kata tertentu selalu dipecah dengan cara tertentu. Vocabulary dan algoritma tokenisasi berbeda antar-model. Intinya, men-tokenisasi prefix lalu menambahkan token tidak secara umum ekuivalen dengan men-tokenisasi teks akhir sebagai satu string.

Perbedaan inilah yang menciptakan failure mode.

Bangun mental model yang tepat

Autoregressive language model memprediksi token berikutnya, bukan karakter arbitrer berikutnya. Jika model terutama dilatih pada segmentasi canonical dari tokenizernya, distribusi next-token yang dipelajari mencerminkan segmentasi tersebut.

Misalkan E(x) berarti “tokenisasi teks x.” Kita mungkin tergoda mengasumsikan bahwa untuk prompt p dan continuation c:

E(p + c) = E(p) + E(c)

Namun, persamaan ini dapat gagal. Sebuah token dalam E(p + c) dapat mencakup karakter dari kedua sisi batas prompt-continuation.

Bayangkan tokenizer sederhana dengan vocabulary berikut:

"process"
"in"
"processing"
"g"

Tokenizer itu dapat menghasilkan:

E("processin")  -> ["process", "in"]
E("g")          -> ["g"]

sementara teks lengkap menjadi:

E("processing") -> ["processing"]

Model yang dilatih pada kemunculan biasa processing mungkin jauh lebih sering melihat ["processing"] daripada urutan non-canonical ["process", "in", "g"]. Memintanya menghasilkan g setelah urutan pertama bukan pertanyaan probabilistik yang sama dengan menanyakan seberapa mungkin string lengkap processing.

Ini adalah artefak batas, bukan bukti bahwa model tidak memahami kata tersebut.

Mengapa prompt completion biasa sering menyembunyikan masalah

Banyak prompt berakhir pada batas yang nyaman: setelah whitespace, tanda baca, atau unit lengkap yang juga cenderung diakhiri tokenizer pada titik tersebut. Dalam kasus seperti ini, tokenisasi prompt secara terpisah dapat cocok dengan bagian awal tokenisasi teks lengkap.

Risiko meningkat ketika aplikasi sengaja berhenti pada posisi karakter arbitrer, misalnya editor yang meminta code completion tepat setelah cursor, sistem infilling berbasis prefix karakter, autocomplete pada kata yang belum selesai, constrained generation yang membutuhkan prefix teks persis, atau bahasa yang batas semantik katanya sering tidak sama dengan batas tokenizer.

Kode perlu perhatian khusus karena titik completion sering berada di dekat tanda baca, identifier, indentation, dan syntax yang belum selesai. Posisi cursor yang bermakna bagi pengguna tidak dijamin merupakan batas token bagi tokenizer model.

Prinsip yang sama berlaku di luar kode. Whitespace dapat mengurangi masalah pada sebagian tokenizer dan bahasa, tetapi bukan jaminan batas universal.

Diagnosis sebelum mengubah decoding

Ketika completion terlihat aneh, tentukan terlebih dahulu apakah batas prompt mengubah tokenisasi. Gunakan tokenizer persis yang dipakai model; tokenizer model lain bukan pengganti yang dapat diandalkan.

Untuk continuation yang diharapkan, bandingkan secara konseptual:

prefix_tokens = encode(prefix)
combined_tokens = encode(prefix + expected_continuation)

Lalu periksa apakah prefix_tokens merupakan prefix token yang persis dari combined_tokens.

prefix_tokens = encode(prefix)
full_tokens = encode(prefix + expected)

aligned = full_tokens[0:length(prefix_tokens)] == prefix_tokens

Jika aligned bernilai false, setidaknya satu token pada tokenisasi canonical teks lengkap melintasi atau berubah di sekitar batas tersebut. Ini merupakan indikasi bahwa completion terkena masalah batas tokenisasi.

Jangan berhenti pada satu contoh. Untuk produk completion nyata, bangun test set dari posisi cursor yang representatif dan ukur seberapa sering alignment token gagal. Sertakan bahasa, tipe file, pola identifier, dan tanda baca yang benar-benar digunakan pengguna.

Pisahkan kegagalan batas dari error model biasa

Model dapat menghasilkan completion buruk karena banyak alasan: konteks kurang, intent ambigu, kemampuan tugas lemah, sampling randomness, atau prompt di luar training distribution.

Eksperimen yang berguna adalah membandingkan prompt berdekatan yang menyatakan prefix sama tetapi berhenti pada posisi token-aligned yang berbeda. Misalnya, mundurkan prefix ke batas aman lalu bandingkan kualitas completion dengan posisi cursor asli.

Jika kegagalan terkonsentrasi pada batas yang tidak aligned dan membaik ketika batas ditangani berbeda, tokenizer adalah penyebab yang masuk akal. Jika performa tetap buruk, perubahan penanganan batas token kemungkinan bukan solusi utama.

Penyesuaian decoding umum seperti menurunkan temperature tidak memperbaiki segmentasi yang sudah dipaksakan. Perubahan itu hanya memengaruhi sampling dari distribusi yang terbentuk setelah segmentasi terjadi.

Mitigasi 1: pilih batas yang lebih aman jika produk memungkinkan

Mitigasi paling sederhana adalah menghindari generation dari posisi karakter arbitrer. Sistem batch dapat memulai suffix setelah delimiter yang diketahui selaras dengan baik untuk tokenizer, atau template dapat diberi separator di akhir alih-alih berhenti di tengah nilai literal.

Pendekatan ini menambah sedikit kompleksitas inference dan tidak mengubah algoritma decoding. Namun, cara ini hanya valid jika memindahkan batas tidak mengubah semantik aplikasi. Editor tidak dapat diam-diam memindahkan cursor pengguna, dan sistem yang harus mempertahankan prefix byte atau karakter secara persis tidak dapat menggantinya dengan prefix yang lebih nyaman.

Mitigasi 2: mundur lalu batasi prefix yang diregenerasi

Keluarga mitigasi umum mundur satu atau beberapa token dari akhir prompt, lalu meminta model meregenerasi bagian tersebut sambil membatasi output agar mereproduksi suffix prompt yang diwajibkan sebelum melanjutkan secara bebas.

teks asli:      ... processin
                       ^ batas

1. mundur:      ... process
2. paksa generation mereproduksi "in"
3. setelah prefix wajib pulih, lanjutkan normal

Dengan cara ini decoder mendapat kesempatan memilih token yang melintasi batas lama, alih-alih dipaksa berhenti pada tokenisasi prompt awal. Teknik yang sering disebut token healing mengikuti gagasan umum ini.

Detail implementasi penting. Mundur tepat satu token hanyalah heuristik, bukan jaminan universal. Tokenizer dapat membutuhkan konteks lebih banyak untuk memulihkan segmentasi canonical. Constrained decoding juga harus menangani token yang hanya cocok dengan sebagian teks wajib atau token yang memuat teks wajib sekaligus karakter tambahan.

Karena itu, perlakukan token healing sebagai algoritma inference yang membutuhkan pengujian spesifik tokenizer, bukan sekadar manipulasi string.

Mitigasi 3: gunakan exact prefix conditioning ketika correctness menuntutnya

Tujuan mendasarnya dapat dinyatakan lebih presisi: sampling output model dengan kondisi bahwa teks hasil decode diawali prefix karakter atau byte yang persis, bukan hanya dengan kondisi satu tokenisasi tertentu dari prefix tersebut.

Metode riset dapat melakukan conditioning ini sambil memperhitungkan beberapa urutan token yang kompatibel dengan prefix teks yang sama. Pendekatan tersebut menangani masalah secara lebih fundamental daripada backtracking dengan jumlah tetap, meski biaya implementasi dan komputasinya bergantung pada tokenizer dan algoritma.

Bedakan kebutuhan Anda antara:

continuation praktis yang lebih baik pada batas yang sulit

dan:

sampling yang benar dengan kondisi prefix teks persis

Keduanya berkaitan, tetapi tidak identik. Heuristik token healing mungkin cukup untuk editor, sedangkan sistem yang bergantung pada semantik probabilitas tidak boleh menganggapnya mempertahankan distribusi asli model.

Ukur kualitas, latency, dan cakupan batas bersama-sama

Penanganan batas menambah pekerjaan pada inference path. Evaluasi setidaknya tiga dimensi: cakupan batas, yaitu berapa banyak posisi bermasalah yang benar-benar ditangani; kualitas tugas, misalnya accepted code completions atau exact-prefix continuation accuracy; dan biaya inference, termasuk orchestration, constrained decoding, model work, serta latency tambahan.

Segmentasikan evaluasi berdasarkan jenis batas, bukan hanya satu angka agregat. Minimal bandingkan prompt aligned dan misaligned. Untuk developer tools, pisahkan pula whitespace, tanda baca, identifier, dan partial-keyword boundary bila relevan.

Kesalahan umum

Menganggap batas kata yang terlihat adalah batas token

Kata merupakan properti teks dan bahasa; token merupakan properti tokenizer tertentu. Keduanya kadang selaras, tetapi aplikasi tidak boleh menganggapnya sebagai jaminan.

Menguji dengan tokenizer yang salah

Diagnosis bergantung pada tokenizer dan vocabulary model yang sebenarnya. Tokenizer pihak ketiga dapat menghasilkan segmentasi berbeda dan menyesatkan debugging.

Menganggap retokenisasi sebagai detail internal yang tidak berpengaruh

Dua urutan token dapat decode menjadi string yang sama tetapi memberi riwayat token berbeda kepada model. Kesamaan teks tidak berarti distribusi next-token identik.

Menerapkan token healing pada setiap kegagalan

Penanganan batas tidak dapat menyediakan pengetahuan yang hilang, menyelesaikan prompt ambigu, atau membuat model yang tidak mampu menjadi mampu. Pastikan kegagalan berkorelasi dengan batas tokenisasi sebelum menambah kompleksitas decoder.

Mengklaim heuristik mempertahankan probabilitas persis

Backtracking dapat memperbaiki perilaku tanpa mereproduksi distribusi persis model dengan kondisi prefix teks arbitrer. Jika correctness probabilitas merupakan bagian dari kontrak sistem, gunakan algoritma dengan jaminan conditioning yang diperlukan dan verifikasi asumsi tokenizernya.

Kapan masalah ini perlu ditangani

Penanganan batas tokenisasi layak direkayasa secara eksplisit ketika aplikasi menerima prefix teks arbitrer dan kualitas completion penting tepat pada posisi cursor atau karakter tersebut. Code completion, autocomplete tingkat karakter, dan constrained prefix generation adalah contoh kuat.

Mekanisme khusus mungkin tidak diperlukan ketika semua prompt berasal dari template internal, berakhir pada separator stabil, dan pengujian menunjukkan degradasi terkait batas yang dapat diabaikan. Keputusan sebaiknya berasal dari pengukuran terhadap batas yang benar-benar dibuat produk.

Kesimpulan

Prompt LLM adalah teks sekaligus urutan token, dan akhir prompt menghubungkan kedua pandangan itu dengan cara yang subtil. Jika prompt berakhir pada titik yang seharusnya dilintasi token dalam tokenisasi canonical teks lengkap, tokenisasi prefix secara terpisah dapat mendistorsi distribusi continuation.

Alur praktisnya jelas: uji alignment prefix dengan tokenizer yang digunakan saat deployment, pisahkan artefak batas dari error model biasa, dan ukur frekuensinya pada input representatif. Jika masalahnya signifikan, pilih mitigasi paling sederhana yang memenuhi kebutuhan—mulai dari batas prompt yang lebih aman, constrained backtracking, hingga exact text-prefix conditioning ketika semantik probabilitas menuntutnya.

Setelah batas token menjadi bagian dari mental model debugging, kelas kegagalan completion yang sebelumnya terasa misterius menjadi dapat diukur dan diuji.

Kecerdasan Buatan LLM Tokenisasi Inference