Tokenisasi Transformers v5: Arsitektur dan Panduan Migrasi

Tokenisasi adalah bagian dari tumpukan HuggingFace Transformer yang jarang kita perhatikan, sampai mulai "bocor" ke output Anda. Satu keanehan spasi putih dapat mengubah batas token, decoding dapat menghasilkan string yang tidak terduga, dan prompt chat dapat diam-diam rusak saat templating. 

Transformers v5 mengatasi titik nyeri ini dengan desain ulang tokenisasi yang menstandarkan perilaku di berbagai implementasi, menyederhanakan permukaan API, dan membuat internal tokenizer lebih mudah diperiksa saat kita perlu melakukan debug.

Dalam tutorial ini, saya akan mulai dengan menjelaskan hal-hal penting tentang apa yang dihasilkan tokenisasi dan bagaimana pipeline bekerja, lalu memandu Anda melalui apa saja yang benar-benar berubah di v5 dari sudut pandang praktis yang berfokus pada migrasi. Anda akan melihat pola kode v4 vs v5 berdampingan untuk encoding, decoding, template chat, dan serialisasi agar Anda dapat memperbarui codebase Anda.

Jika Anda baru dalam tokenisasi, saya merekomendasikan untuk melihat kursus Pengantar Pemrosesan Bahasa Alami di Python.

Apa itu Tokenisasi?

Definisi yang sangat umum dari tokenisasi adalah bahwa ia mengonversi teks menjadi ID token, yang benar tetapi tidak lengkap. Dalam produksi, tokenisasi lebih baik dipahami sebagai sebuah kontrak. Diberikan teks mentah, tokenizer harus menghasilkan encoding terstruktur yang dapat dikonsumsi model dengan aman.

Paling tidak, kontrak itu mencakup:

• input_ids, yaitu ID token berupa integer yang mengindeks ke tabel embedding model.
• Juga mencakup attention_mask, yang menunjukkan posisi mana yang sesuai dengan token nyata versus padding.
• Offset/penyelarasan (jika tersedia) memetakan rentang token kembali ke rentang tingkat karakter atau kata dalam teks asli, yang diperlukan untuk highlight, NER, dan atribusi.
• Semantik token khusus harus dipertahankan, artinya penempatan dan ID BOS/EOS/PAD/UNK harus sesuai dengan konvensi yang digunakan selama pelatihan model.
• Untuk model chat, pemformatan chat adalah bagian dari kontrak, jadi kita biasanya menerapkan template chat model sebelum menjalankan tokenisasi.

Di Transformers, tanggung jawab ini berada pada lapisan tokenizer (bukan di dalam forward pass model), itulah sebabnya AutoTokenizer adalah titik masuk standar. Berikut contoh sederhana:

from transformers import AutoTokenizer
tokenizer = AutoTokenizer.from_pretrained("HuggingFaceTB/SmolLM3-3B")
enc = tokenizer("Hello world")
print(enc["input_ids"])
print(tokenizer.convert_ids_to_tokens(enc["input_ids"]))Didukung oleh

Berikut output yang diharapkan:

[9906, 1917]
['Hello', 'Ġworld']Didukung oleh

Di sini, enc adalah objek BatchEncoding (kontainer mirip dict) yang menyimpan field siap-model yang dihasilkan tokenizer (seperti input_ids, dan sering kali attention_mask). Output mengembalikan [9906, 1917], yang merupakan ID token integer untuk string masukan beserta ['Hello', 'Ġworld'], yang menunjukkan string token yang sesuai. 

Catatan: Prefiks Ġ adalah konvensi umum yang menunjukkan token menyertakan spasi di depan, sehingga Ġworld merepresentasikan " world" alih-alih "world" tanpa spasi.

Tokenisasi sebagai Pipeline: Bagaimana v5 Membuatnya Mudah Di-debug

Masalah tokenisasi biasanya muncul sebagai masalah kecil seperti spasi ekstra, pemisahan Unicode yang aneh, lonjakan tiba-tiba dalam jumlah token, atau prompt chat yang tidak mengikuti peran dengan benar. 

Cara termudah untuk men-debug masalah ini adalah memperlakukan tokenisasi sebagai rangkaian tahapan. Setelah Anda tahu tahap mana yang bertanggung jawab atas apa, Anda dapat dengan cepat mengisolasi masalah alih-alih menebak. Berikut beberapa poin yang perlu diingat:

Tokenisasi adalah pipeline yang dapat dikomposisi

Tujuan pertama adalah mematahkan kesalahpahaman umum bahwa tokenizer hanyalah WordPiece. Sebaliknya, ini adalah rangkaian tahap transformasi yang berbeda, termasuk normalisasi, pra-tokenisasi, pemodelan subword, pascapemrosesan, dan decoding. Setiap tahap mengendalikan bagian berbeda dari perilaku akhir.

Model mental yang mudah di-debug

Memecah tokenisasi menjadi tahapan memberi kita peta pemecahan masalah yang andal:

• Keanehan spasi putih biasanya berasal dari pra-tokenizer atau decoder
• Unicode biasanya berasal dari normalizer.
• Ledakan token sering disebabkan oleh model subword, bersama dengan vocab/merges-nya
• Kesalahan pemformatan chat terutama berasal dari template atau pascapemrosesan

Eksplisit dan dapat diperiksa secara desain

Transformers v5 membuat tokenizer lebih mudah diperiksa, terutama untuk tokenizer yang didukung oleh mesin tokenizers berbasis Rust. 

Saat backend Rust digunakan, kita dapat memeriksa komponen dasar melalui tokenizer._tokenizer (normalizer, pra-tokenizer, model, pascaprosesor, decoder). Kita tidak menggunakan _tokenizer setiap hari, tetapi ini berguna dengan rilis v5, yang membuat internalnya terlihat saat kita perlu melakukan debug.

Ini secara alami mengarah pada pembedaan mesin vs pembungkus:

• Mesin (tokenizers): Implementasi Rust tingkat rendah yang melakukan mekanisme inti seperti normalisasi, pemisahan, segmentasi subword, dan menghasilkan ID token (dan offset bila tersedia).
• Pembungkus (transformers): Ini adalah lapisan yang menghadap model yang mengubah mekanisme tersebut menjadi input siap-model dengan menegakkan konvensi seperti penanganan token khusus, template chat, aturan padding/pemotongan, dan output tensor khusus framework.

Apa yang Berubah di Transformers v5?

Transformers v5 adalah rilis besar yang terstandarisasi, dan tokenisasi adalah salah satu area dengan perubahan yang terlihat oleh pengguna. Rilis ini mengurangi implementasi duplikat, membuat perilaku tokenizer lebih konsisten di seluruh model, dan membuat tokenizer lebih mudah diperiksa dan (dalam beberapa kasus) dilatih dari awal. Di bawah ini adalah perubahan yang paling berdampak pada pengguna sehari-hari.

Satu implementasi tokenizer per model

Pada rilis sebelumnya, banyak model memiliki:

• tokenizer Python yang lambat
• implementasi tokenizer cepat yang didukung Rust

Di v5, Transformers mengonsolidasikan ke satu file tokenizer per model dan memprioritaskan jalur yang didukung Rust. Berikut alasan mengapa tokenizer berbasis Rust bekerja:

• Menghilangkan implementasi lambat vs cepat yang terduplikasi.
• Mengurangi bug paritas yang disebabkan oleh ketidakcocokan perilaku halus antarimplementasi tersebut.
• Implementasi tokenizer ini memperkecil dan menyederhanakan permukaan pengujian, karena hanya ada satu jalur kode utama untuk divalidasi.
• Juga menetapkan satu "sumber kebenaran" untuk perilaku tokenizer di seluruh model.

Migrasi API encoding

API v4 encode_plus() tidak lagi direkomendasikan (deprecated) dan digantikan dengan memanggil tokenizer secara langsung. Berikut perbedaan versi antara v4 dan v5:

versi v4

enc = tokenizer.encode_plus(
    text,
    truncation=True,
    padding="max_length",
    max_length=128,
    return_tensors="pt",
)Didukung oleh

versi v5

enc = tokenizer(
    text,
    truncation=True,
    padding="max_length",
    max_length=128,
    return_tensors="pt",
)Didukung oleh

Beralih dari encode_plus() ke satu titik masuk tokenizer() mengurangi mode kegagalan nyata yang muncul dalam kode produksi. 

Di v4, memiliki beberapa metode encoding berarti perbedaan halus pada padding, pemotongan, batching, atau konversi tensor dapat muncul tergantung pada jalur yang Anda gunakan, sering kali baru terlihat saat beralih dari input tunggal ke beban kerja berkelompok. 

v5 menstandarkan semuanya pada satu jalur encoding yang selalu mengembalikan BatchEncoding, yang membuat perilaku lebih dapat diprediksi dan mengurangi bug kasus tepi serta jumlah kode yang diperlukan untuk menjaga konsistensi pipeline tokenisasi.

Migrasi API decoding

v5 menyatukan decoding sehingga decode() menangani input tunggal dan berkelompok, menyelaraskan perilaku decode dengan encode.

versi v4

texts = tokenizer.batch_decode(batch_ids, skip_special_tokens=True)Didukung oleh

versi v5

texts = tokenizer.decode(batch_ids, skip_special_tokens=True)Didukung oleh

Di v5, decoding dirancang untuk mencerminkan encoding. Sama seperti tokenizer() dapat menerima satu string atau sekumpulan string, decode() dapat menerima satu urutan ID token atau satu batch urutan. 

Hal utama di sini adalah tipe nilai kembali, yaitu jika Anda memberikan satu urutan, Anda akan mendapatkan kembali satu string, tetapi jika Anda memberikan batch (seperti list[list[int]]), Anda akan mendapatkan daftar string. Ini membuat API lebih bersih secara keseluruhan, tetapi juga berarti kode apa pun yang berasumsi decode() selalu mengembalikan string harus diperbarui untuk menangani kedua kasus.

Template chat

Di v4, apply_chat_template mengembalikan input_ids mentah untuk kompatibilitas ke belakang. Di v5, ia mengembalikan BatchEncoding seperti metode tokenizer lainnya.

versi v4

input_ids = tokenizer.apply_chat_template(messages, return_tensors="pt")Didukung oleh

versi v5

enc = tokenizer.apply_chat_template(messages, return_tensors="pt")
input_ids = enc["input_ids"]
attention_mask = enc["attention_mask"]Didukung oleh

Di v5, apply_chat_template() diperlakukan sebagai titik masuk tokenizer yang semestinya, bukan helper kasus khusus. Alih-alih hanya mengembalikan input_ids, ia mengembalikan objek BatchEncoding lengkap (dengan field seperti input_ids dan attention_mask). 

Ini penting karena input yang sudah diformat chat kini masuk ke alur kerja batching, padding, pemotongan, dan pengembalian tensor yang sama seperti tokenisasi biasa. Jadi kita tidak memerlukan kode tambahan untuk membangun kembali mask atau menyelaraskan format secara manual sebelum mengirim input ke model.

Serialisasi tokenizer

Di v5, serialisasi tokenizer disederhanakan dengan mengonsolidasikan metadata token khusus dan token yang ditambahkan ke dalam lebih sedikit artefak, sambil tetap mendukung file warisan untuk kompatibilitas ke belakang. Ini mengurangi risiko beberapa file "sumber kebenaran" melenceng tidak sinkron dan membuat aset tokenizer lebih mudah dimuat serta digunakan kembali dalam alat hilir yang beroperasi di luar pustaka Transformers.

Tokenizer sebagai arsitektur yang dapat dikonfigurasi

Di v5, pergeseran utamanya adalah bahwa tokenizer diperlakukan sebagai pipeline terdefinisi beserta artefak yang dipelajari, alih-alih hanya sesuatu yang kita muat dari file terserialisasi.

• Kelas tokenizer menentukan bagaimana teks dinormalisasi, dipecah menjadi potongan, dikonversi menjadi token subword, dan akhirnya didekode kembali menjadi teks.
• Kosa kata dan aturan penggabungan adalah artefak yang dipelajari, yaitu bagian yang dilatih yang menentukan token mana yang ada dan bagaimana teks dikompresi menjadi ID token.
• Pemisahan ini memungkinkan alur kerja berorientasi arsitektur terlebih dahulu. Untuk tokenizer yang didukung, Anda dapat menginstansiasi tokenizer yang mengikuti desain model lalu memuat atau melatih vocab/merges secara terpisah, yang membuat kustomisasi dan pelatihan ulang jauh lebih mudah.

Pemikiran Akhir 

Tokenisasi Transformers v5 adalah langkah besar menuju standardisasi dan penyederhanaan. Kini ada jalur perilaku yang lebih kanonik (mengurangi divergensi lambat/cepat), permukaan API yang disederhanakan, templating chat yang mengembalikan objek BatchEncoding terstruktur yang sama seperti tokenisasi normal, dan serialisasi yang terkonsolidasi sehingga mengurangi asumsi rapuh di tingkat file. 

Ini juga mendorong model mental berorientasi arsitektur terlebih dahulu di mana tokenizer lebih mudah diperiksa dan, dalam kasus yang didukung, dilatih dari awal. Untuk bermigrasi dengan mulus dari v4, gantikan encode_plus() dengan tokenizer(), gantikan batch_decode() dengan decode(), perbarui lokasi pemanggilan apply_chat_template() agar bekerja dengan BatchEncoding, hindari hardcode nama file tokenizer warisan saat menyimpan, dan harapkan keanehan tokenizer lambat apa pun semakin konvergen ke perilaku yang didukung tokenizers.

Jika Anda ingin mempelajari lebih lanjut tentang rilis terbaru, berikut catatan rilisnya. Saya juga merekomendasikan skill track Hugging Face Fundamentals untuk praktik langsung.