SentencePiece ile Metin Parçalama Sınırları

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. Metin parçalayıcı 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 metin parçalama katmanının çoğu zaman "ön işleme" diye küçümsendiğini gördüm. Oysa LLM veya seq2seq hattında metin parçalayıcı, 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 derlem zorunluluğu olmadan ham metin üzerinde alt sözcük modeli öğrenebilir. BPE ve unigram tabanlı modelleri destekler. Sözlük 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 boşluk'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 metin parçalamadan önce gelir

SentencePiece dokümantasyonundaki kritik ayrıntılardan biri, normalizasyonun bölümleme işleminden önce yapılmasıdır. Sözlük de normalize edilmiş derlem üzerinden öğrenilir.

Bu şu anlama gelir: eğitim sırasında uygulanan normalleştirme ile çıkarım sırasında uygulanan normalleştirme farklıysa modelin gördüğü sembol uzayı değişir.

Unicode tarafında aynı görsel karakter farklı kod noktası dizileriyle ifade edilebilir. Uyumluluk karakterleri, birleşik/ayrık aksanlar, full-width biçimler ve boşluk varyasyonları model açısından farklı byte veya kod noktası 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.

Sözlük boyutu bir kapasite kararıdır

Küçük sözlük daha fazla token üretir. Büyük sözlük 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ı metin parçalayıcı 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, metin parçalayıcı tercihi çıkarım maliyetini dolaylı biçimde etkileyebilir.

Örneğin aynı cümleyi iki metin parçalayıcı 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 önbellek, attention ve decode davranışı da değişir.

Türkçe için kelime sayısı iyi bir ölçüt değildir

Eklemeli dillerde boşluk ile ayrılan sözcük sayısını metin parçalama 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 normalleştirme sonrası bilgi kaybı
• domain terimlerinin kaç tokenda temsil edildiği

Ben özellikle teknik Türkçe derlemlerde İ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. Üretim log'u, teknik doküman ve doğal konuşma transkripti aynı metin parçalayıcı üzerinde farklı dağılımlar üretir.

Metin parçalayıcı değiştirmek model değiştirmektir

Eğitilmiş bir modelin metin parçalayıcıyı "daha iyi bir metin parçalayıcı bulduk" diye sonradan değiştirmek genellikle mümkün değildir. Token ID'leri embedding satırlarına karşılık gelir. Sözlük yeniden oluşturulduğunda ID semantiği değişir.

Aynı görünen token metni bile farklı ID'ye bağlanabilir. Bu nedenle metin parçalayıcı dosyası model artifact'ının ayrılmaz parçası olarak versiyonlanmalıdır.

Dağıtık çıkarım ortamında çalışanların farklı metin parçalayıcı sürümü kullanması sessiz veri bozulmasına yol açabilir. HTTP şeması doğru, tensor şekli doğru ve çıkarım başarılı görünür; fakat modele farklı ID dizisi gönderilir.

Bu tür hata istisna üretmediği için operasyonel olarak tehlikelidir.

Alt sözcük regularization neden ilginçtir?

Unigram modelinde aynı metnin birden fazla olası bölümleme'ı 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 metin parçalayıcı seviyesindeki karşılığı gibi düşünülebilir. Ancak çıkarım 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 metin parçalayıcı/saniye değildir

Metin parçalayıcı başarım ölçümünde işlem hacmi ölçmek kolaydır. Gerçek sistemde ise UTF-8 decode/encode, normalleştirme, bölümleme, token ID üretimi, bellek ayırma, FFI sınırı ve batching birlikte maliyet üretir.

Kısa isteklerde FFI ve bellek ayırma maliyeti baskın olabilir. Çok büyük batch'lerde algoritmanın çekirdek işlem hacmini önem kazanır.

SentencePiece projesinin güncel başarım ölçümü çalışmaları farklı metin parçalayıcı implementasyonlarını dengeli çok dilli veri üzerinde karşılaştırıyor. Bu tür sonuçlar yön gösterir, fakat kendi derleminizin token dağılımını ölçmeden üretim kararı vermek doğru değildir.

Modelden önce derlemi ölçmek

Metin parçalayıcı tasarımında benim tercih edeceğim sıra model eğitiminden başlamaz. Önce gerçek derlem üzerinde aday metin parçalayıcıların ürettiği dağılım ölçülür. Özellikle en kötü yüzde birlik dilimler incelenir.

Bir metin parçalayıcı 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 normalleştirme ve bölümleme kararlarını model artifact'ına bağlayan açık yapısı nedeniyle metin parçalayıcının sistem mimarisindeki gerçek yerini görünür kılar.

Kaynakça

• Google. SentencePiece Normalization. https://github.com/google/sentencepiece/blob/master/doc/normalization.md

• Google. SentencePiece Performance Benchmark. https://github.com/google/sentencepiece/blob/master/doc/performance_benchmark.md

• Google. SentencePiece. https://github.com/google/sentencepiece

• Taku Kudo; John Richardson. “SentencePiece: A Simple and Language Independent Subword Tokenizer and Detokenizer for Neural Text Processing.” Proceedings of the 2018 Conference on Empirical Methods in Natural Language Processing: System Demonstrations, 2018, ss. 66-71. DOI: 10.18653/v1/D18-2012.