Aplikasi language model biasanya memperlakukan prompt sebagai teks: berikan sebuah prefiks, 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 berakhir tepat di posisi itu.

Detail ini dapat menjadi penting ketika prompt berakhir pada posisi karakter yang, jika prompt dan kelanjutannya ditokenisasi bersama, biasanya berada di dalam token yang lebih besar. Masalah batas tokenisasi (tokenization boundary problem), yang juga disebut masalah token parsial (partial token problem), dapat membuat kelanjutan yang sebenarnya natural menjadi sangat kecil kemungkinannya.

Masalah ini mudah terlewat karena teks yang terlihat dapat tampak sepenuhnya wajar. Ini terutama relevan untuk prefix completion, code completion, constrained generation, dan bahasa yang whitespace-nya tidak selalu menandai batas token dengan andal. Artikel ini membangun model mental untuk memahami kegagalan tersebut, menunjukkan cara mengujinya, dan menjelaskan trade-off berbagai mitigasi praktis.

Mulai dari perbedaan antara teks dan token

Misalkan sebuah aplikasi meminta model melengkapi teks berikut:

natural language processin

Manusia akan menganggap g sebagai karakter berikutnya yang masuk akal. Namun, subword tokenizer belum tentu 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 tempat prompt berakhir. Setelah aplikasi mengirim processin sebagai prompt lengkap, tokenizer harus mengakhiri urutan token di sana. Model kemudian diminta melanjutkan dari batas token yang dipaksakan itu, bukan dari urutan token yang akan dilihatnya jika string lengkap ditokenisasi sekaligus.

Pelajaran pentingnya bukan bahwa sebuah kata tertentu selalu dipecah dengan cara tertentu. Vocabulary token dan algoritma tokenisasi berbeda antar-model. Intinya adalah bahwa men-tokenisasi prefiks lalu menambahkan token secara umum tidak setara dengan men-tokenisasi teks final sebagai satu string utuh.

Perbedaan inilah yang menciptakan failure mode tersebut.

Bangun model mental yang tepat

Autoregressive language model memprediksi token berikutnya, bukan karakter arbitrer berikutnya. Jika model terutama dilatih menggunakan segmentasi kanonis dari tokenizer, distribusi next-token yang dipelajarinya akan mencerminkan segmentasi tersebut.

Misalkan E(x) berarti “tokenisasi teks x.” Kita mungkin tergoda mengasumsikan bahwa untuk prompt p dan kelanjutan 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-kelanjutan.

Pertimbangkan tokenizer sederhana dengan entri vocabulary berikut:

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

Tokenizer itu mungkin menghasilkan:

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

sementara teks lengkap menjadi:

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

Model yang dilatih pada kemunculan normal processing mungkin jauh lebih sering melihat ["processing"] daripada urutan non-kanonis ["process", "in", "g"]. Karena itu, meminta model menghasilkan g setelah urutan pertama bukanlah 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 ini

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

Risiko meningkat ketika aplikasi sengaja berhenti pada posisi karakter arbitrer. Contoh umumnya meliputi:

  • editor yang meminta code completion tepat setelah posisi kursor pengguna;
  • sistem infilling yang bekerja dengan prefiks pada level karakter;
  • autocomplete yang mengirim kata yang baru diketik sebagian;
  • constrained generation yang membutuhkan prefiks teks secara persis;
  • teks dalam bahasa yang batas kata semantiknya sering tidak sama dengan batas tokenizer.

Kode perlu mendapat perhatian khusus karena titik completion sering muncul di dekat tanda baca, identifier, indentasi, dan sintaks yang baru diketik sebagian. Posisi kursor yang bermakna secara visual belum tentu merupakan batas token bagi tokenizer model.

Prinsip yang sama berlaku di luar kode. Whitespace dapat mengurangi masalah untuk beberapa desain tokenizer dan bahasa, tetapi bukan jaminan batas universal untuk semua tokenizer dan sistem tulisan.

Diagnosis masalah sebelum mengubah decoding

Ketika sebuah completion tampak buruk tanpa alasan jelas, tentukan terlebih dahulu apakah batas prompt mengubah tokenisasi. Anda memerlukan akses ke tokenizer persis yang digunakan bersama model; tokenizer dari model lain bukan pengganti yang andal.

Untuk kelanjutan yang diinginkan dan sudah diketahui, bandingkan dua urutan berikut secara konseptual:

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

Kemudian periksa apakah prefix_tokens merupakan prefiks token yang persis dari combined_tokens.

Diagnostic kecil dapat ditulis sebagai pseudocode:

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 dalam tokenisasi kanonis teks lengkap melintasi atau berubah di dekat batas. Ini merupakan bukti bahwa completion tersebut terkena masalah batas.

Jangan berhenti pada satu contoh pilihan. Untuk produk completion nyata, bangun test set dari posisi kursor yang representatif dan ukur seberapa sering alignment token gagal. Sertakan bahasa, jenis file, gaya identifier, dan pola tanda baca yang benar-benar dihasilkan pengguna Anda.

Pisahkan kegagalan batas dari error model biasa

Model dapat menghasilkan completion buruk karena banyak alasan: konteks tidak cukup, intent ambigu, kemampuan tugas lemah, randomness dari sampling, atau prompt berada di luar distribusi training model.

Eksperimen yang berguna khusus untuk batas adalah membandingkan prompt berdekatan yang menyatakan prefiks yang sama tetapi berakhir pada posisi berbeda yang selaras dengan token. Misalnya, evaluasi kualitas completion setelah memundurkan prefiks ke batas aman yang diketahui, lalu bandingkan dengan kualitas pada posisi kursor asli.

Jika kegagalan terkonsentrasi pada batas yang tidak selaras dengan token dan membaik ketika batas ditangani secara berbeda, tokenizer merupakan penyebab yang masuk akal. Jika performa tetap buruk terlepas dari alignment, mengubah penanganan batas token kemungkinan tidak menyelesaikan masalah utama.

Perbedaan ini penting karena penyesuaian decoding umum seperti menurunkan temperature tidak memperbaiki segmentasi yang dipaksakan. Penyesuaian tersebut hanya mengubah cara model melakukan sampling dari distribusi yang terbentuk setelah segmentasi itu terjadi.

Mitigasi 1: pilih batas yang lebih aman jika produk memungkinkan

Mitigasi paling sederhana adalah menghindari permintaan generation dari posisi karakter arbitrer.

Sebagai contoh, sistem text generation batch mungkin dapat memindahkan awal suffix yang dihasilkan ke setelah delimiter yang diketahui selaras dengan baik untuk tokenizernya. Template terkadang dapat menyertakan separator di bagian akhir daripada berhenti di tengah nilai literal.

Pendekatan ini menarik karena hanya menambah sedikit kompleksitas inference dan tidak mengubah algoritma decoding model. Namun, pendekatan ini hanya valid jika memindahkan batas tidak mengubah semantik aplikasi.

Editor tidak dapat diam-diam memindahkan kursor pengguna. Sistem yang harus melanjutkan prefiks byte atau karakter secara persis juga tidak dapat mengganti prefiks tersebut dengan yang lebih nyaman. Dalam kasus seperti ini, pemilihan batas saja tidak cukup.

Mitigasi 2: mundur dan batasi prefiks yang diregenerasi

Salah satu keluarga mitigasi yang umum adalah mundur satu atau beberapa token di dekat akhir prompt, lalu meminta model meregenerasi bagian tersebut sambil membatasi teks yang dihasilkan agar mereproduksi suffix prompt yang diwajibkan sebelum generation dilanjutkan secara bebas.

Alur tingkat tingginya:

teks asli:     ... processin
                       ^ batas

1. mundur:     ... process
2. batasi generation agar mereproduksi "in"
3. setelah prefiks wajib pulih, lanjutkan secara normal

Cara ini memberi decoder kesempatan memilih token yang melintasi batas lama, alih-alih memaksa tokenisasi prompt asli berhenti di sana. Teknik yang sering disebut token healing mengikuti gagasan umum ini.

Detail implementasinya penting. Mundur tepat satu token adalah heuristic, bukan jaminan correctness universal. Sebuah tokenizer mungkin membutuhkan konteks lebih banyak untuk memulihkan segmentasi kanonis, dan tokenizer yang berbeda memiliki perilaku batas berbeda. Constrained decoding juga harus menangani token yang hanya cocok dengan sebagian teks wajib yang tersisa atau token yang memuat teks wajib sekaligus karakter tambahan.

Karena itu, perlakukan token healing sebagai algoritma inference yang memerlukan pengujian khusus tokenizer, bukan sebagai trik penggantian string.

Mitigasi 3: gunakan metode exact prefix conditioning ketika correctness menuntutnya

Tujuan dasarnya dapat dinyatakan lebih tepat: lakukan sampling output model dengan kondisi bahwa teks hasil decoding dimulai dengan prefiks karakter atau byte yang persis, bukan hanya dengan kondisi pada satu tokenisasi tertentu dari prefiks tersebut.

Metode riset dapat melakukan conditioning ini sambil memperhitungkan beberapa urutan token yang kompatibel dengan prefiks teks yang sama. Metode semacam ini menangani masalah secara lebih fundamental daripada backtracking dengan jumlah tetap, walaupun detail implementasi dan biaya komputasinya bergantung pada tokenizer serta algoritma.

Perbedaan ini penting pada sistem yang semantik probabilitasnya berarti. Heuristic yang meningkatkan kualitas autocomplete mungkin sepenuhnya memadai untuk editor, sedangkan sistem yang bergantung pada probabilitas sampling yang persis tidak boleh mengasumsikan bahwa heuristic token healing mempertahankan distribusi asli model yang dikondisikan pada prefiks teks.

Dengan kata lain, tentukan apakah kebutuhan Anda adalah:

kelanjutan praktis yang lebih baik pada batas yang canggung

atau:

sampling yang benar dengan kondisi prefiks teks yang persis

Keduanya merupakan tujuan yang berkaitan, tetapi tidak identik.

Ukur kualitas, latency, dan cakupan batas bersama-sama

Penanganan batas menambah pekerjaan pada inference path. Evaluasi yang berguna karena itu harus mengukur lebih dari sekadar akurasi completion.

Mulailah dengan tiga dimensi:

  1. Cakupan batas. Berapa banyak posisi kursor bermasalah yang benar-benar ditangani mitigasi?
  2. Kualitas tugas. Apakah mitigasi meningkatkan metrik yang penting, seperti code completion yang diterima pengguna atau akurasi exact-prefix continuation?
  3. Biaya inference. Seberapa banyak orchestration tambahan, constrained decoding, pekerjaan model, atau latency yang ditimbulkan?

Mitigasi dapat terlihat mengesankan pada kata yang sengaja dipotong, tetapi memberi sedikit manfaat jika prompt produksi hampir selalu berakhir pada batas yang selaras. Kebalikannya juga dapat terjadi: rata-rata failure rate yang rendah dapat menyembunyikan masalah berat untuk bahasa atau pola kode tertentu yang penting bagi pengguna Anda.

Segmentasikan evaluasi berdasarkan jenis batas, bukan hanya melaporkan satu angka agregat. Minimal, bandingkan prompt yang aligned dan misaligned. Untuk developer tool, memisahkan batas whitespace, tanda baca, identifier, dan partial keyword juga dapat berguna.

Kesalahan umum

Menganggap batas kata yang terlihat sebagai batas token

Kata adalah properti teks dan bahasa; token adalah properti tokenizer tertentu. Keduanya kadang selaras, tetapi aplikasi tidak boleh menganggap alignment tersebut selalu terjamin.

Menguji dengan tokenizer yang salah

Diagnosis bergantung pada tokenizer dan vocabulary model yang sebenarnya. Tokenizer pihak ketiga yang mudah digunakan dapat menghasilkan segmentasi berbeda sehingga Anda men-debug batas yang tidak dimiliki model deployment, atau justru melewatkan batas yang memang ada.

Menganggap retokenisasi sebagai detail internal yang tidak berbahaya

Dua urutan token dapat di-decode menjadi string yang terlihat sama tetapi memberikan history tingkat token yang berbeda kepada model. Karena itu, kesamaan teks tidak berarti distribusi next-token yang 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 mengerjakan tugas. Pastikan kegagalan berkorelasi dengan batas tokenisasi sebelum menambahkan kompleksitas decoder.

Mengklaim heuristic mempertahankan probabilitas secara persis

Backtracking dapat memperbaiki perilaku tanpa mereproduksi distribusi persis model yang dikondisikan pada prefiks teks arbitrer. Jika correctness probabilitas merupakan bagian dari kontrak sistem, gunakan algoritma dengan jaminan conditioning yang dibutuhkan dan verifikasi asumsinya untuk tokenizer Anda.

Kapan masalah ini perlu ditangani

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

Mekanisme khusus mungkin tidak diperlukan ketika prompt seluruhnya dihasilkan template Anda sendiri, berakhir pada separator yang stabil, dan pengujian menunjukkan degradasi terkait batas yang dapat diabaikan. Dalam situasi itu, inference path yang lebih sederhana lebih mudah dioperasikan dan dipahami.

Keputusan sebaiknya berasal dari pengukuran terhadap batas yang benar-benar dibuat produk Anda.

Kesimpulan

Prompt LLM adalah teks sekaligus urutan token, dan akhir prompt menghubungkan kedua sudut pandang tersebut dengan cara yang halus. Jika prompt berakhir di posisi yang dalam tokenisasi kanonis teks lengkap nantinya akan dilintasi sebuah token, men-tokenisasi prefiks secara terpisah dapat mendistorsi distribusi kelanjutan.

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

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

Kecerdasan Buatan LLM Tokenisasi Inference