Türkçe BPE Belirteç Maliyeti: Eklemeli Yapı ve Fatura

Türkçe, BPE (Byte Pair Encoding — bayt çifti kodlaması) tabanlı belirteçleştiricilerde İngilizce'ye kıyasla aynı anlamdaki metin için tipik olarak yaklaşık 1,5–2,5 kat daha fazla belirteç üretir; bunun ana nedeni eklemeli yapıdır: kök + çok sayıda ek, sözlükte tek parça olarak bulunmayan diziler oluşturur ve kelime alt parçalara bölünür. Belirteç sayısı arttıkça hem bağlam penceresi daha hızlı dolar hem de giriş/çıkış belirteç ücreti üzerinden API faturası aynı oranda şişer. Aşağıda bunu adım adım sayılarla ve varsayımları açıkça belirterek gösteriyorum.

BPE Belirteçleştirmeye Giriş: Türkçe Neden Farklı?

BPE, bir metni önce baytlara (veya karakterlere) ayırır, sonra eğitim verisinde en sık yan yana geçen parçaları iteratif olarak birleştirerek bir "sözlük" (vocabulary) oluşturur. Model bu sözlükteki en uzun eşleşen parçaları belirteç olarak kullanır. Yani bir kelimenin kaç belirtece bölüneceği, o kelimenin ve eklerinin eğitim verisinde ne sıklıkta birlikte görüldüğüne bağlıdır. İngilizce gibi sınırlı çekim gösteren dillerde "read", "reading", "reader" gibi formlar sözlükte ayrı ayrı yer bulabilir; Türkçede ise "okuyabileceklerimizdenmişçesine" gibi bir kelime, teorik olarak milyonlarca farklı biçim üretebilen bir ek zinciridir.

Türkçe'de tek bir kökten türetilen biçim sayısı çok yüksektir: isim çekimi (durum, iyelik, çoğul), fiil çekimi (zaman, kişi, kip), yapım ekleri ve bunların kombinasyonları üst üste biner. Belirteçleştirici sözlüğü ise sınırlı boyuttadır (tipik olarak on binlerle yüz binler arası parça). Sözlükte "kitap" kökü ve "lar", "dan" gibi yaygın ekler ayrı ayrı bulunsa bile "kitaplarımızdan" gibi bir form çoğu zaman tek parça değildir; bu yüzden kelime birkaç belirtece ayrılır. Üstelik Türkçe'de ünlü uyumu ve ünsüz yumuşaması gibi ses olayları (kitap → kitabı, ağaç → ağacı) eklerin yüzey biçimini değiştirdiğinden, aynı ekin farklı varyantları sözlükte ayrı parçalar olarak yer alır ve verimlilik daha da düşer.

Buna bir de ğ, ş, ı, İ gibi Türkçe'ye özgü karakterlerin durumu eklenir. Modern belirteçleştiriciler bayt düzeyinde çalıştığı için bu karakterler kaybolmaz; ancak bu karakterlerin geçtiği diziler, İngilizce ağırlıklı eğitim verisinde daha seyrek görüldüğünden daha küçük parçalara bölünme eğilimindedir. Sonuç: aynı bilgi içeriği, daha fazla belirteç.

Eklemeli Yapının Belirteç Sayısını Şişirmesi: Adım Adım Örnek

Somut bir örnekle ilerleyelim. Aşağıdaki tabloda bir cümleyi varsayımsal ama gerçekçi bir BPE sözlüğüyle parçalara ayırıyorum. Buradaki bölünmeler temsilidir; gerçek sayılar kullandığınız modele ve sürümüne göre değişir, bu yüzden bunları "tahmini" olarak okuyun.

Cümle: "Kitaplarımızdan bazılarını arkadaşlarıma verdim."

Adım adım bölünme (tahmini):

"Kitaplarımızdan"  -> ["Kitap", "lar", "ımız", "dan"]        = 4 belirteç
"bazılarını"       -> ["bazı", "lar", "ını"]                 = 3 belirteç
"arkadaşlarıma"    -> ["arkadaş", "lar", "ım", "a"]          = 4 belirteç
"verdim"           -> ["ver", "dim"]                         = 2 belirteç
noktalama ve boşluklar                                       = ~4 belirteç
Toplam: yaklaşık 17 belirteç

Aynı cümlenin İngilizce karşılığı olan "I gave some of my books to my friends." çoğu modern belirteçleştiricide yaklaşık 9–11 belirtece denk gelir. Yani Türkçe cümle, aynı anlam için yaklaşık 1,6–1,9 kat daha fazla belirteç tüketir. Bu oran, cümlede ek yığılması arttıkça yükselebilir: "Arkadaşlarımızdan bazılarına kitaplarımızı verdirememişiz" gibi bir cümlede fiil zinciri ("ver-dir-eme-miş-iz") tek başına 5–6 belirtece bölünebilir.

Şimdi bu farkı bir metin ölçeğine taşıyalım. Varsayım: 1.000 kelimelik bir Türkçe metin, ortalama kelime başına 2,5 belirteç üretiyor; aynı içeriğin İngilizcesi kelime başına 1,3 belirteç üretiyor. Bu durumda:

Türkçe:  1.000 kelime x 2,5 = 2.500 belirteç
İngilizce: 1.000 kelime x 1,3 = 1.300 belirteç
Fark: 1.200 belirteç, yani ~%92 daha fazla

Buradaki 2,5 ve 1,3 katsayıları evrensel sabitler değildir; metnin türüne (teknik metinlerde ödünç kelimeler daha az ek alır, günlük metinlerde ek yoğunluğu artar), modele ve sürüme göre değişir. Kendi metninizde gerçek sayıyı görmek için bir sonraki bölümde anlatacağım token-counter yaklaşımını kullanmanız gerekir. Ancak yön ve büyüklük mertebesi tutarlıdır: eklemeli yapı, belirteç sayısını sistematik olarak şişirir.

Token-Counter ile Ölçüm: Karşılaştırmalı Sayılar

Belirteç (token) sayısını tahminle değil, ölçerek konuşmak gerekir. Bunun için token-counter türü araçlar, verdiğiniz metni belirli bir modelin belirteçleştiricisinden (tokenizer) geçirip tam sayıyı döndürür. Python tarafında yaygın yaklaşım, ilgili modelin kütüphanesini kullanmaktır:

# Kurulum: pip install tiktoken   (OpenAI modelleri için örnek)
import tiktoken

enc = tiktoken.get_encoding("cl100k_base")  # modelin kodlayıcısı
metin = "evlerimizdeki kitaplardan"
print(len(enc.encode(metin)))  # belirteç sayısı

Aynı mantık Hugging Face tokenizers veya modelin kendi tokenizer nesnesiyle de kurulabilir. Önemli nokta: hangi modeli faturalandırıyorsanız onun belirteçleştiricisini kullanın. Farklı modeller aynı metni farklı sayıda belirtece böler; bu yüzden "yaklaşık 4 karakter = 1 belirteç" kuralı Türkçe'de yanıltıcıdır.

Karşılaştırmalı ölçüm için basit bir yöntem izleyin:

1. Aynı anlamı taşıyan bir Türkçe ve bir İngilizce paragraf seçin (eşdeğer uzunlukta).
2. Her ikisini de aynı kodlayıcıdan geçirin.
3. Belirteç/kelime oranını not edin.
4. Farkı yüzde olarak raporlayın: (tr_token - en_token) / en_token * 100.

Beklenti: Türkçe'de eklemeli yapı nedeniyle bu oran tipik olarak İngilizce'nin belirgin biçimde üzerinde çıkar; kesin kat sayı modelden modele değişir, bu yüzden kendi metninizle ölçmeden sayı vermeyin.

API Faturasına Etkisi: Maliyet Hesaplama ve Azaltma Stratejileri

API faturası çoğu sağlayıcıda girdi belirteci + çıktı belirteci üzerinden hesaplanır. Çıktı belirteçleri genelde daha pahalıdır, ama Türkçe'de asıl sürpriz girdi tarafında yaşanır: aynı içerik daha çok belirtece bölünür.

Temel formül:

maliyet = (girdi_token * girdi_birim_fiyat) + (cikti_token * cikti_birim_fiyat)

İşlenmiş örnek (varsayımsal fiyatlarla, tahmin): Farz edelim girdi 1.000 belirteç başına 0,50 birim, çıktı 1.000 belirteç başına 1,50 birim ücretlendiriliyor. Bir istekte 2.000 girdi ve 500 çıktı belirteci varsa:

girdi  = 2.000 / 1.000 * 0,50 = 1,00
cikti  =   500 / 1.000 * 1,50 = 0,75
toplam = 1,75 birim

Aynı içerik İngilizce'de varsayalım 1.200 girdi belirtecine düşsün (Türkçe'nin ~1,67 katı olduğu bir senaryo):

girdi  = 1.200 / 1.000 * 0,50 = 0,60
cikti  =   500 / 1.000 * 1,50 = 0,75
toplam = 1,35 birim

Fark istek başına 0,40 birim; günde 1.000 istekte bu 400 birim eder. Sayılar temsilidir, gerçek fiyatlar sağlayıcıya göre değişir — ama mantık sabittir: belirteç şişmesi doğrudan faturaya yansır.

Maliyet azaltma kontrol listesi:

• İçeriği kısalt: gereksiz nezaket kalıpları, tekrarlar, dolgu cümleler çıkarın.
• Bağlamı budayın: her istekte tüm geçmişi değil, ilgili kısmı gönderin.
• Önbelleğe alın: tekrar eden sistem talimatlarını sağlayıcının bağlam önbelleği varsa kullanın.
• Çıktıyı sınırlayın: max_tokens ve net talimatlarla uzun yanıtları engelleyin.
• Ölçün: göndermeden önce token-counter ile sayıp bütçe eşiği koyun.

Kısa bir bütçe kontrolü fikri:

def butce_uygun(metin, enc, limit=1500):
    return len(enc.encode(metin)) <= limit

Bu eşik, istekleri göndermeden önce eleyerek beklenmedik fatura sıçramalarını önler.

Sıkça Sorulan Sorular

Türkçe metinler neden İngilizce'ye göre daha fazla belirteç üretir?

BPE (Byte Pair Encoding, yani bayt çifti kodlaması) belirteçleştiricileri, eğitim verisinde en sık geçen karakter dizilerini tek bir belirteç olarak öğrenir. İngilizce gibi kelimelerin az çekim eki aldığı dillerde "run", "running", "runs" gibi biçimler sınırlı sayıdadır ve sık kullanılan kelimeler çoğunlukla tek belirteçe sığar. Türkçe'de ise "gidiyorum", "gidemeyeceğim", "gittiklerinde" gibi aynı kökten türeyen onlarca farklı yüzey biçimi olduğu için belirteçleştirici her biçimi ayrı ayrı ezberleyemez ve kelimeler birden fazla parçaya bölünür. Sonuç olarak aynı anlamı taşıyan bir cümle Türkçe'de tipik olarak İngilizce'ye kıyasla belirgin biçimde daha fazla belirteç üretir; bu oran metne ve modele göre değişmekle birlikte çoğu pratik durumda 1,3–2 kat bandında seyreden bir tahmin olarak düşünülebilir.

BPE belirteçleştirme eklemeli dillerde neden verimsizdir?

Eklemeli dillerde (agglutinative languages) tek bir kelime, kök üzerine sıralanan çok sayıda ekle anlam kazanır; Türkçe'de "evlerimizdekiler" gibi bir kelime kök, çoğul, iyelik, bulunma ve çoğul eklerini üst üste taşır. BPE'nin birimleri sabit karakter dizileri olduğu için bu tür uzun ve seyrek kelimeler, sık geçen kısa parçalara ayrılır ve her parça ayrı bir belirteç sayılır. Üstelik ekler köke göre çok daha sık tekrarlandığından belirteçleştirici sıklıkla kökü bir, ekleri ayrı parçalara böler; bu da anlamlı birimlerin belirteç sınırlarıyla örtüşmemesine yol açar. İngilizce gibi ek bakımından fakir dillerde kelime ile belirteç arasındaki kopukluk küçük kaldığı için aynı sorun maliyet açısından görünür hale gelmez.

token-counter aracıyla belirteç sayımını nasıl yaparım?

token-counter, bir metnin belirli bir modelin belirteçleştiricisiyle kaç belirtece ayrıldığını ölçen bir araçtır; API çağrısı yapmadan yerelde sayım yapar ve maliyet tahminini şeffaf kılar. Tipik kullanımda metni araca verir, hedef modelin (örneğin kullandığınız sağlayıcının istem ve yanıt için geçerli belirteçleştiricisinin) belirteç setini seçersiniz; araç size toplam belirteç sayısını ve isteğe bağlı olarak parçalama dökümünü gösterir. Aynı cümleyi Türkçe ve İngilizce karşılıklarıyla sayarak farkı somutlaştırabilir, uzun istemlerinizi (prompt) ve sakladığınız bağlam metinlerini karşılaştırmalı olarak ölçebilirsiniz. Sayım sonuçlarını fatura hesabında kullanmak için sağlayıcının giriş ve çıkış belirteç fiyatlarını ayrı ayrı uygulamanız gerekir.

Belirteç sayısını azaltmak API maliyetini ne kadar düşürür?

API faturası büyük ölçüde işlenen belirteç sayısıyla doğrusal olarak ölçeklenir; giriş (prompt) ve çıkış (completion) belirteçleri genellikle farklı birim fiyatlarla ücretlendirilir, dolayısıyla toplam belirtecin yüzde X azalması, sabit fiyat varsayımıyla faturada yaklaşık aynı oranda bir düşüşe karşılık gelir. Örneğin bir istemde belirteç sayısını yarıya indirebiliyorsanız, o istemin maliyeti de kabaca yarıya iner; ancak model çağrı başına minimum ücret uyguluyorsa veya önbellekleme (caching) gibi indirimler devreye giriyorsa gerçek tasarruf bu orandan sapabilir. Türkçe'de eklemeli yapıdan kaynaklanan fazladan belirteçleri kısaltmalarla, gereksiz bağlamı atarak ve çıktı uzunluğunu sınırlayarak azaltmak, ölçülebilir ve öngörülebilir bir tasarruf sağlar; kesin yüzde için kendi metinlerinizde önce-sonra sayımı yapmanız gerekir.

LLM API faturasını hesaplamak için hangi araçları kullanmalıyım?

En güvenilir yöntem, sağlayıcının kendi belirteçleştiricisini kullanan sayım araçlarıdır; çünkü farklı modeller aynı metni farklı sayıda belirtece böler ve yanlış belirteçleştiriciyle yapılan hesap yanıltıcı olur. Pratikte token-counter gibi yerel sayım araçlarıyla istem ve yanıt belirteçlerini ölçüp, sağlayıcının güncel giriş/çıkış birim fiyatlarıyla çarparak tahmini faturayı kendiniz hesaplayabilirsiniz; formül şu şekildedir:

maliyet = (giris_belirtec * giris_fiyati) + (cikis_belirtec * cikis_fiyati)

Toplu kullanımda gerçek faturayı görmek için sağlayıcının kullanım panosuna (usage dashboard) ve faturalama raporlarına başvurmanız, tahmin ile gerçek arasındaki farkı düzenli olarak karşılaştırmanız önerilir. Fiyatlar modelden modele ve zamanla değiştiği için hesaplamada her zaman sağlayıcının o günkü fiyat listesini esas alın.