
Bir modelle çalışırken maliyet tablosuna baktığınızda çoğu zaman tek bir rakam görürsünüz: 1.000 token başına şu kadar. Ama aynı cümleyi Türkçe ve İngilizce yazıp denediğinizde faturanın neden farklı çıktığını fark edersiniz. İşte tam da bu noktada akla şu soru düşüyor: aynı anlamı taşıyan bir metin, dilden dile neden farklı bedellere mal oluyor?
Kısaca cevap vermek gerekirse: evet, token ücreti dile göre değişiyor. Çünkü mesele fiyat listesinde değil, modelin metni parçalara ayırma biçiminde saklı. Aynı cümleyi bir dilde 10 tokenla, başka bir dilde 25 tokenla ifade etmek pekâlâ mümkün.
Bir dil modelinin (LLM) sizin yazdığınız metni doğrudan "okuduğunu" düşünmek kolaycı bir varsayım. Oysa bilgisayar için metin, yapılandırılmamış veri (unstructured data) yığınından başka bir şey değil. Siz "Brick" yazdığınızda modelin bunun ne olduğunu anlaması için önce o kelimeyi sayısal bir karşılığa indirgemesi gerekiyor.
Bu indirgeme işini yapan yapıya tokenizer deniyor. Tokenizer, metni modelin işleyebileceği en küçük anlamlı parçalara böler ve her parçaya bir sayı atar. Model aslında sizin cümlenizi değil, o sayı dizisini görür ve ona göre cevap üretir.
Burada kafa karıştıran şey şu: bir token her zaman bir kelime demek değil. Kullanılan model mimarisine ve tokenizer yöntemine göre bir token bazen tam bir kelime olur, bazen sadece bir kök, bazen bir hece, bazen de tek bir harf ya da noktalama işareti olabilir.
Yani "kitap" kelimesi bir modelde tek token olarak geçerken, başka bir modelde "kit" ve "ap" diye ikiye bölünebilir. Bu tercih tamamen modelin eğitiminde kullanılan tokenizer stratejisine bağlı ve son kullanıcı olarak siz bu kararı doğrudan göremezsiniz — ama faturada hissedersiniz.
Türkçe, tokenizer açısından zorlu bir dil. Sondan eklemeli (agglutinative) yapısı, tek bir köke onlarca ek takabilme özelliği tokenizer'ın işini zorlaştırıyor. "Gel" fiilini alıp "gelemeyeceklerimizdenmişsiniz" gibi bir yapıya dönüştürebiliyoruz ve bu tek kelime, tokenizer için birden fazla parçaya bölünmesi gereken uzun bir yapı haline geliyor.
İngilizce ise bu açıdan çok daha "ekonomik" davranıyor. Cümleler arasında "to", "as", "of", "in" gibi kısa ve sık tekrar eden kelimeler var. Bu küçük kelimeler tokenizer için son derece verimli; çünkü çoğu zaman tek tokenla ifade ediliyorlar ve model bunları tanımak için ekstra bir çaba harcamıyor.
Sonuç olarak aynı anlamı taşıyan bir cümle, İngilizcede daha az tokenla, Türkçede daha fazla tokenla ifade edilebiliyor. Bu da doğrudan iki şeyi etkiliyor: maliyet ve performans. Daha az tokenla çalışan bir model, daha az bellek kullanıyor, daha hızlı yanıt veriyor ve size daha az fatura kesiyor.
Bunun yanında modelin "daha az tokenla daha iyi çalışabilmesi" gibi bir avantaj da devreye giriyor. Yani mesele sadece cebinizden çıkan para değil; modelin sizi ne kadar iyi anladığı da bu tokenizasyon sürecine bağlı.
Bir ürün yöneticisi ya da tasarımcı olarak model seçerken çoğu zaman "hangisi daha akıllı" sorusuna odaklanırız. Oysa dil desteği ve tokenizer verimliliği, en az akıl kadar kritik bir seçim kriteri. Özellikle Türkçe içerikle çalışan bir ürün geliştiriyorsanız, iki modelin tokenizasyon davranışını karşılaştırmadan karar vermek, ilerde beklenmedik maliyetlerle karşılaşmanıza yol açabilir.
Örneğin bir müşteri hizmetleri chatbot'u kurgulayacaksanız, kullanıcılardan gelen ortalama mesaj uzunluğunu birkaç farklı modelin tokenizer'ında test etmek işe yarar. Aynı 100 mesajın bir modelde kaç, diğerinde kaç token ürettiğini gördüğünüzde seçiminiz "en popüler olan" değil, "sizin diliniz için en verimli olan" yönde şekillenir.
Benzer şekilde uzun promptlarla çalışan bir uygulama tasarlıyorsanız — mesela bir doküman özetleyici — Türkçe metinlerin İngilizceye kıyasla çok daha fazla token tüketeceğini baştan hesaba katmanız gerekir. Bu, bağlam penceresi (context window) sınırlarına da hızlı ulaşacağınız anlamına gelir.
Türkçe her modelde İngilizceden pahalı mıdır?
Genel eğilim bu yönde, çünkü çoğu popüler model ağırlıklı olarak İngilizce veri üzerinde ve İngilizceye optimize edilmiş tokenizer'larla eğitildi. Ancak Türkçe için özelleştirilmiş tokenizer kullanan modellerde bu fark ciddi biçimde daralabiliyor.
Aynı token sayısı her modelde aynı anlama gelir mi?
Hayır. Bir modelde 100 token olan bir metin, başka bir modelde 70 ya da 130 token olabilir. Çünkü her modelin tokenizer'ı farklı bir metotla eğitilmiş olabilir. Bu yüzden model karşılaştırırken sadece "1.000 token başına ücret" değil, o modelin sizin dilinizde kaç token ürettiği de bakılması gereken bir metrik.
Tokenizer'ı ben değiştirebilir miyim?
Hazır bir modeli API üzerinden kullanıyorsanız hayır; tokenizer, modelle birlikte gelen ve eğitim sırasında belirlenmiş bir bileşen. Ancak model seçiminizi bu bilgiye göre yapabilirsiniz.
Kısa mı yoksa net mi yazmalıyım?
İkisi de. Türkçede aynı şeyi daha kısa ve sade ifade etmek, hem tokenizer'ın işini kolaylaştırır hem de modelin size daha isabetli cevap vermesini sağlar. Uzun ve dolambaçlı ekler, hem cümlenizi hem faturanızı büyütür.
Token meselesi ilk bakışta teknik bir detay gibi görünür; ama işin özünde çok daha temel bir şey var: modelin dünyayı hangi merkezden gördüğü. Bugünkü büyük dil modellerinin çoğu İngilizce merkezli düşünüyor, İngilizceye göre optimize ediliyor ve diğer diller bu yapıya sonradan uyum sağlıyor.
Sizin gibi Türkçe içerikle, Türkçe kullanıcılarla ve Türkçe ürünlerle çalışan biri için token farkı sadece bir bütçe kalemi değil; aslında modelin sizi ne kadar "kendi dilinde" anladığının da bir göstergesi. Bir sonraki model seçiminizde fiyat listesine bakmadan önce, kendi cümlelerinizin o modelde kaça bölündüğüne bakmak, belki de en değerli adım olacak.
Dillere göre de token ücreti değişiyor galiba değil mi? Değişiyor. O da bir seçim sebebi olabilir. Bu yapılar aslında tokenlarına daha doğrusu modellar eğitilirken belli bir tokenizer yöntemiyle eğitiliyor. Türkçe sondan eklemeli, eklerin yoğun olduğu bir dil. Ondan dolayı çok şey oluyor.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Phasellus sodales leo id commodo ornare.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Phasellus sodales leo id commodo ornare.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Phasellus sodales leo id commodo ornare.