SentencePiece ile Tokenization Sınırları
SentencePiece, metni sabit bir vocabulary altında subword parçalara ayırırken normalizasyonu tokenization öncesinde uygular. Türkçe gibi eklemeli dillerde vocabulary boyutu, normalizasyon ve segmentation politikası doğrudan model davranışına dönüşür.
Türkçede "gelemediklerimizdenmişsiniz" gibi tek bir sözcük, İngilizcede birkaç ayrı sözcükle taşınabilecek miktarda morfolojik bilgi barındırabilir. Tokenizer bu yapıyı kötü bölerse problem yalnız token sayısının artması değildir; modelin öğrendiği istatistiksel birimler de değişir.
Metin işleme, Türkçe karakter dönüşümü ve konuşma sistemleriyle uğraşırken tokenization katmanının çoğu zaman "ön işleme" diye küçümsendiğini gördüm. Oysa LLM veya seq2seq hattında tokenizer, modelin giriş alfabesini tanımlar. Model ağırlıkları kadar sözleşmenin parçasıdır.
SentencePiece'in temel fikri
SentencePiece, önceden boşluklarla sözcüklere ayrılmış bir corpus zorunluluğu olmadan ham metin üzerinde subword modeli öğrenebilir. BPE ve unigram tabanlı modelleri destekler. Vocabulary boyutu eğitimden önce belirlenir ve model bu sınırlı sembol kümesi altında metni parçalamaya çalışır.
Buradaki önemli özelliklerden biri whitespace'in de temsil edilebilir bir sembol olarak ele alınmasıdır. Böylece token dizisinden metne dönüşüm klasik "tokenları araya boşluk koyarak birleştirme" yaklaşımına mahkum değildir.
Fakat bu davranış normalizasyon kurallarıyla birlikte okunmalıdır.
Normalizasyon tokenization'dan önce gelir
SentencePiece dokümantasyonundaki kritik ayrıntılardan biri, normalizasyonun segmentation işleminden önce yapılmasıdır. Vocabulary de normalize edilmiş corpus üzerinden öğrenilir.
Bu şu anlama gelir: eğitim sırasında uygulanan normalization ile inference sırasında uygulanan normalization farklıysa modelin gördüğü sembol uzayı değişir.
Unicode tarafında aynı görsel karakter farklı code point dizileriyle ifade edilebilir. Compatibility karakterleri, birleşik/ayrık aksanlar, full-width biçimler ve whitespace varyasyonları model açısından farklı byte veya code point dizileri oluşturabilir.
Türkçede sorun yalnız ı, İ, ş, ğ gibi karakterlerin korunması değildir. Case folding de dil bağımlıdır. İngilizce merkezli bir lower-case dönüşümü I ve İ için yanlış sonuç verebilir.
Bu yüzden normalizasyonu "temizlik" değil, model sözleşmesi olarak görüyorum.
Vocabulary boyutu bir kapasite kararıdır
Küçük vocabulary daha fazla token üretir. Büyük vocabulary daha uzun parçaları tek token altında toplar fakat embedding/output katmanlarının boyutunu büyütür.
Bu trade-off salt bellek hesabı değildir.
Bir Türkçe sözcüğün kök ve ek sınırları tokenizer tarafından anlamlı biçimde ayrılabiliyorsa farklı yüzey biçimleri arasında parametre paylaşımı kolaylaşabilir. Buna karşılık aşırı parçalama sequence length'i artırır. Attention maliyeti klasik tam attention için dizi uzunluğunun karesiyle büyüdüğünden, tokenizer tercihi inference maliyetini dolaylı biçimde etkileyebilir.
Örneğin aynı cümleyi iki tokenizer sırasıyla 20 ve 30 token'a ayırıyorsa fark yalnız yüzde 50 daha fazla token değildir. Model mimarisine göre KV cache, attention ve decode davranışı da değişir.
Türkçe için kelime sayısı iyi bir ölçüt değildir
Eklemeli dillerde whitespace ile ayrılan sözcük sayısını tokenization verimliliği için temel ölçü kabul etmek hatalıdır. Daha anlamlı metrikler şunlardır:
- karakter başına token
- byte başına token
- sözcük başına token dağılımı
- nadir morfolojik yapılardaki parçalanma
- sayı, tarih, URL ve kod parçalarının davranışı
- Unicode normalization sonrası bilgi kaybı
- domain terimlerinin kaç tokenda temsil edildiği
Ben özellikle teknik Türkçe corpus'larda İngilizce terimler, sınıf adları, dosya yolları ve sayısal ifadeler nedeniyle ortalama değerin tek başına yetersiz olduğunu düşünüyorum. Production log'u, teknik doküman ve doğal konuşma transkripti aynı tokenizer üzerinde farklı dağılımlar üretir.
Tokenizer değiştirmek model değiştirmektir
Eğitilmiş bir modelin tokenizer'ını "daha iyi bir tokenizer bulduk" diye sonradan değiştirmek genellikle mümkün değildir. Token ID'leri embedding satırlarına karşılık gelir. Vocabulary yeniden oluşturulduğunda ID semantiği değişir.
Aynı görünen token metni bile farklı ID'ye bağlanabilir. Bu nedenle tokenizer dosyası model artifact'ının ayrılmaz parçası olarak versiyonlanmalıdır.
Dağıtık inference ortamında worker'ların farklı tokenizer sürümü kullanması sessiz veri bozulmasına yol açabilir. HTTP şeması doğru, tensor şekli doğru ve inference başarılı görünür; fakat modele farklı ID dizisi gönderilir.
Bu tür hata exception üretmediği için operasyonel olarak tehlikelidir.
Subword regularization neden ilginçtir?
Unigram modelinde aynı metnin birden fazla olası segmentation'ı bulunabilir. Eğitim sırasında farklı segmentasyonların örneklenmesi, modele tek bir parçalama yoluna aşırı bağımlı kalmama şansı verir.
Bu yaklaşım data augmentation'ın tokenizer seviyesindeki karşılığı gibi düşünülebilir. Ancak inference tarafında deterministik çıktı gerekiyorsa sampling kapatılmalıdır.
Kritik veri işleme hatlarında aynı girdi için aynı token dizisini istemek doğaldır. Eğitim ve üretim davranışını aynı parametre seti sanmak burada hataya yol açar.
Performans yalnız tokenizer/saniye değildir
Tokenizer benchmark'ında throughput ölçmek kolaydır. Gerçek sistemde ise UTF-8 decode/encode, normalization, segmentation, token ID üretimi, allocation, FFI sınırı ve batching birlikte maliyet üretir.
Kısa isteklerde FFI ve allocation maliyeti baskın olabilir. Çok büyük batch'lerde algoritmanın çekirdek throughput'u önem kazanır.
SentencePiece projesinin güncel benchmark çalışmaları farklı tokenizer implementasyonlarını dengeli çok dilli veri üzerinde karşılaştırıyor. Bu tür sonuçlar yön gösterir, fakat kendi corpus'unuzun token dağılımını ölçmeden production kararı vermek doğru değildir.
Modelden önce corpus'u ölçmek
Tokenizer tasarımında benim tercih edeceğim sıra model eğitiminden başlamaz. Önce gerçek corpus üzerinde aday tokenizer'ların ürettiği dağılım ölçülür. Özellikle en kötü yüzde birlik dilimler incelenir.
Bir tokenizer ortalamada iyi görünürken uzun kimlikler, teknik semboller, Türkçe birleşik yapılar veya konuşma transkriptlerindeki bozuk noktalama nedeniyle bazı girdileri aşırı büyütebilir.
LLM sisteminde bu doğrudan context tüketimidir.
SentencePiece bu problemi tek başına çözmez; fakat normalization ve segmentation kararlarını model artifact'ına bağlayan açık yapısı nedeniyle tokenizer'ın sistem mimarisindeki gerçek yerini görünür kılar.
Kaynakça
