BPE Belirteçleştirme: Türkçe Metinlerde Adım Adım

BPE (Byte Pair Encoding, bayt çifti kodlaması), metni önce karakterlere veya baytlara böler, sonra en sık yan yana gelen çiftleri adım adım birleştirerek sınırlı sayıda "alt kelime" (subword) parçası üretir. Türkçe'de ekler kelimeleri çok uzattığı için BPE aynı kelimeyi birden çok parçaya bölmek zorunda kalır; bu da aynı anlamdaki metnin daha fazla token (modelin işlediği en küçük metin birimi) tüketmesi demektir. Aşağıda süreci küçük sayılarla izleyip tipik hataları ve token sayısını düşürme yollarını somutlaştırıyoruz.

BPE Nedir ve Neden Türkçe İçin Önemlidir?

BPE, adını sıkıştırma algoritmalarından alır: bir sözlükten (vocabulary) başlar, her eğitim adımında en sık geçen ardışık sembol çiftini tek bir yeni sembolle değiştirir. Sonunda elinizde sabit boyutlu bir parça listesi kalır; örneğin 32.000 parçalık bir sözlük. Model bu parçaları görür, kelimeleri değil. "Kelime" tabanlı bir sözlük Türkçe'de patlar: isim çekimleri, fiil çekimleri ve yapım ekleriyle milyonlarca yüzey biçimi (surface form) üretilir. BPE bunu, sık ekleri ("-lar", "-dan", "-mış") ve sık kökleri parça olarak öğrenerek yumuşatır.

Türkçe için kritik nokta şu: BPE'nin birleştirme kararı tamamen frekansa bağlıdır ve dil bilgisi tanımaz. "-de" eki hem bulunma hâli hem de bağlaç "de" olarak geçtiği için sık bir parça olur; ama "evdeki" gibi zincirler tek parçaya sığmaz. Bu yüzden bir Türkçe kelime tipik olarak 1 değil, 2–4 parçaya ayrılır. Token sayısı arttıkça bağlam penceresi (context window) daha hızlı dolar ve API maliyeti token başına hesaplandığı için doğrudan artar.

BPE'yi anlamak için tek bir sayı yeterli: sözlük boyutu. 8.000 parçalık küçük bir sözlükte "gidemeyecekler" gibi bir kelime 5–6 parçaya bölünebilirken, 50.000 parçalık sözlükte 2–3 parçaya inebilir — bu bir tahmindir, kesin değer eğitim verisine bağlıdır. Yani "Türkçe çok token harcıyor" şikâyeti çoğu zaman sözlük boyutu ve eğitim verisinin Türkçe oranıyla ilgilidir.

Türkçe Bir Cümlede BPE'nin Adım Adım Uygulanışı

Küçük bir örnekle ilerleyelim. Eğitim metnimiz yalnızca şu üç kelime olsun: ev, evler, evlerden. Başlangıç sözlüğü karakterler: e, v, l, r, d, n. Metni karakterlere ayırıp boşlukla ayırırsak:

e v   e v l e r   e v l e r d e n

Çiftleri sayalım: e v 3 kez, v l 2 kez, l e 2 kez, e r 2 kez, diğerleri 1 kez. En sık çift e v olduğu için onu ev sembolüne birleştiririz. Yeni dizilim:

ev   ev l e r   ev l e r d e n

Şimdi l e 2 kez, e r 2 kez geçiyor; eşitlikte alfabetik veya keyfi bir kural seçilir, diyelim l e → le:

ev   ev le r   ev le r d e n

Sıradaki sık çift le r (2 kez) → ler:

ev   ev ler   ev ler d e n

Sonra ev ler (2 kez) → evler:

ev   evler   evler d e n

Bu noktada d e ve e n birer kez geçtiği için birleştirme durur (ya da sözlük dolana kadar devam eder). Ortaya çıkan parçalar: ev, evler, evler, d, e, n. Dikkat: "evlerden" tek parça olmadı; evler + d + e + n gibi bölündü. Gerçek bir tokenizer'da bu adımlar on binlerce birleştirme için tekrarlanır ve sonuç, eğitim verisinde sık görülen ekleri yakalayan bir parça listesi olur.

Uygulama tarafında süreç iki aşamalıdır: (1) eğitim — metin üzerinde çift sayımı ve birleştirme kuralları listesi çıkarılır; (2) kodlama — yeni bir metin aynı kurallarla soldan sağa taranır, önce karakterlere/baytlara ayrılır, sonra öğrenilen birleştirmeler sırayla uygulanır. Byte-level BPE'de (GPT ailesinin kullandığı yaklaşım) başlangıç birimi karakter değil bayttır; bu sayede hiç görülmemiş karakterler bile "bilinmeyen token" (unknown token) üretmeden temsil edilir — Türkçe için ğ, ş, ı, İ gibi harflerde bu önemlidir.

Sık Karşılaşılan Hatalar: Ekler, Birleşik Kelimeler ve Unicode

BPE (Byte Pair Encoding — ikili bayt birleştirme), metni en sık geçen karakter/sembol çiftlerini birleştirerek alt kelimelere böler. Türkçede üç noktada tökezler:

1. Ek yığılması. Türkçe sondan eklemeli bir dildir; tek köke birden çok ek gelebilir. "evlerimizdekiler" gibi bir kelime, BPE sözlüğünde bütün hâliyle yoksa parçalanır: ev + ler + imiz + de + ki + ler. Her ek ayrı token demektir. İngilizcede aynı anlam çoğu zaman tek token tutar. Bu yüzden aynı içerik Türkçede daha fazla token üretir.

2. Birleşik ve kesme işaretli yazımlar. "Ankara'da", "TRT'de", "herşey" (yaygın hatalı yazım) gibi biçimler tokenizer'ın hiç görmediği diziler oluşturur; kesme işareti ve sonrası ayrı ayrı parçalara ayrılır. Tutarlı bir ön işleme (kesme işaretini kaldırma veya ayırma kararı) token sayısını doğrudan etkiler.

3. Unicode normalizasyonu. "İ" (noktalı büyük i) ile "I" (noktasız büyük i) farklı kod noktalarıdır; "ş" bazen tek karakter, bazen "s" + birleşik işaret olarak gelir. Normalize edilmemiş metin, aynı kelimeyi iki farklı token dizisine böler. Çözüm: metni yazmadan önce Unicode NFC normalizasyonundan geçirmek ve büyük/küçük harf katlamasını (case folding) tutarlı yapmak.

Token Sayısını Azaltma Yöntemleri ve Küçük Bir Kod Örneği

Token sayısı = maliyet ve gecikme. Azaltmanın somut yolları:

• Normalizasyon + tutarlı küçük harf: NFC uygula, İ→i, I→ı kuralını sabitle.
• Kesme işareti politikası: "Ankara'da" → "ankarada" (ek köke yapışır, sık geçen diziler tek token'a yaklaşır).
• Sık ekleri koruma: Kendi BPE sözlüğünü eğitiyorsan, -ler, -de, -ki, -imiz gibi ekleri birleştirme adayı olarak öne çıkar.
• Gereksiz boşluk/noktalama temizliği: Çift boşluk, tekrar eden noktalama ayrı token üretir.

İşlenmiş örnek (varsayımsal sayılarla). Bir cümlede 20 kelime var; kelime başına ortalama 3 alt kelime (subword) düşüyor → 60 token. Normalizasyon ve kesme işareti birleştirmesiyle kelime başına ortalama 3 → 2,6'ya inerse: 20 × 2,6 = 52 token. Tasarruf: 60 − 52 = 8 token, yani yaklaşık %13. (Bu sayılar örnek varsayımdır; gerçek oran tokenizer'a göre değişir.)

Kısa kod fikri (Python):

import unicodedata, re
def normalize(text):
    text = unicodedata.normalize("NFC", text)
    text = text.replace("İ", "i").replace("I", "ı").lower()
    text = re.sub(r"'", "", text)          # Ankara'da -> ankarada
    text = re.sub(r"\s+", " ", text).strip()
    return text
# normalize edilmiş metni tokenizer'a ver, len(tokens) ile karşılaştır

Kontrol listesi:

• NFC normalizasyonu uygulandı mı?
• Büyük/küçük harf kuralı sabit mi?
• Kesme işareti politikası net mi?
• Fazla boşluk/noktalama temizlendi mi?
• Önce/sonra token sayısı ölçüldü mü?

Sıkça Sorulan Sorular

BPE belirteçleştirme Türkçe metinlerde neden daha fazla token üretir?

BPE (Byte Pair Encoding), bir metni sık geçen karakter veya alt kelime çiftlerini birleştirerek daha büyük parçalara böler; token sayısı, kelimenin bu öğrenilmiş parçalara ne kadar iyi denk geldiğine bağlıdır. Türkçe eklemeli bir dil olduğu için tek bir kökten onlarca farklı kelime biçimi türeyebilir ve bu biçimlerin çoğu eğitim verisinde seyrek görülür, dolayısıyla tokenizer bunları birden çok küçük parçaya ayırır. İngilizce gibi dillerde yaygın kelimeler genellikle tek token'a sığarken, Türkçede "gidemeyebilecekler" gibi bir kelime kolayca dört-beş parçaya bölünebilir; bu da aynı anlamdaki metnin daha fazla token tüketmesi anlamına gelir.

Türkçe ekler BPE tarafından nasıl parçalanır?

BPE, ekleri dilbilgisel olarak tanımaz; yalnızca eğitim verisinde sık yan yana gelen karakter dizilerini birleştirir. Bu yüzden "-lar/-ler", "-dan/-den" gibi çok sık görülen ekler genellikle tek bir token olarak öğrenilirken, "-ebilecekler", "-miyordu" gibi daha seyrek ve uzun ek zincirleri birden fazla parçaya ayrılır. Sonuç olarak aynı köke gelen farklı ekler farklı biçimlerde parçalanabilir: "ev-de" iki token olabilirken "ev-de-ki-ler" üç-dört token'a çıkabilir. Bu düzensizlik, eklerin morfolojik sınırlarına saygı duyulmadığını ve token sayısının biçime göre değiştiğini gösterir.

Token sayısını azaltmak için metin ön işlemede neler yapılabilir?

En etkili adım, tokenizer'ı hedef dilin gerçek metniyle eğitmek veya Türkçe ağırlıklı bir tokenizer seçmektir; çünkü token sayısı büyük ölçüde öğrenilen parça dağarcığına bağlıdır. Bunun yanında tutarlı Unicode normalizasyonu (örneğin NFC) uygulamak, gereksiz boşlukları ve tekrarlayan noktalama işaretlerini temizlemek ve çok seyrek görülen karakter karmaşalarını sadeleştirmek küçük ama ölçülebilir kazanç sağlar. Ayrıca çok uzun birleşik kelimeleri veya kısaltmaları tutarlı biçimde yazmak, tokenizer'ın bunları tanıma olasılığını artırır. Bu adımların hiçbiri sihirli değildir; beklenen kazanç genellikle yüzde birkaç ile yüzde onlar arasında kalır ve mutlaka kendi verinizde ölçülmelidir.

Aynı cümle farklı tokenizer'larda neden farklı token sayısı verir?

Her tokenizer'ın parça dağarcığı (vocabulary) farklı veriyle ve farklı boyutta öğrenildiği için aynı kelimeyi farklı biçimlerde böler. Bir tokenizer "kitaplarımızdan" kelimesini tek parça olarak öğrenmişse bir token üretirken, başka bir tokenizer aynı kelimeyi "kitap + lar + ımız + dan" gibi üç-dört parçaya ayırabilir. Ayrıca büyük/küçük harf davranışı, boşluk işleme biçimi ve Unicode normalizasyonu da sayıyı değiştirir. Bu nedenle token sayıları yalnızca aynı tokenizer ve aynı sürüm içinde karşılaştırılmalıdır.

BPE yerine Türkçeye özel bir tokenizer kullanmak maliyeti düşürür mü?

Türkçe ağırlıklı eğitilmiş bir tokenizer genellikle aynı metinde daha az token üretir, bu da API faturalandırması token başına olduğunda doğrudan maliyet düşüşü anlamına gelebilir. Ancak tasarruf oranı sabit değildir; metnin türüne, alan sözlüğüne ve tokenizer'ın dağarcık boyutuna göre değişir ve yüzde birkaç ile yüzde onlar arasında bir aralıkta kalması beklenir (bu bir tahmindir). Ayrıca modelin kendi tokenizer'ı sabitse, farklı bir tokenizer kullanmak modelle uyumsuzluk yaratabileceğinden pratikte çoğu zaman modelin tokenizer'ıyla çalışmak zorunludur; bu durumda kazanç, metin ön işleme ve istem tasarrufuyla sınırlı kalır.