Türkçe tokenleştirme, faturada görünmeyen bir Türkçe vergisi

Tez#

Fiyatlandırma token başına yapılıyor ve bu, dilden bağımsız görünüyor: bin token bin token. Ama token, bir karakter ya da bir kelime değil — tokenleştiricinin sözlüğünde bulunan bir parça. Sözlük hangi dilin metinlerinden çıkarıldıysa, o dilin parçaları daha verimli temsil ediliyor.

Yaygın modellerin tokenleştiricileri İngilizce ağırlıklı derlemlerden çıkıyor ve Türkçe iki nedenle dezavantajlı. Birincisi sözlükte Türkçe parçaların payı düşük: sık kullanılan Türkçe kökler ve ekler ayrı birimler olarak yer almıyor, kelimeler daha küçük parçalara bölünüyor. İkincisi Türkçe eklemeli bir dil: tek bir kelime birden çok dilbilgisel işlevi taşıyabiliyor ve İngilizcede birkaç kelimeyle anlatılan bir şey Türkçede tek kelime oluyor — ama o kelime tokenleştiricide çok parçaya bölündüğü için kazanç kayba dönüşüyor. Sonuç, aynı anlam için daha çok token ve bu, faturada ayrı bir kalem olarak görünmeyen bir maliyet farkı.

Bağlam: farkın görüldüğü üç yer#

Token farkının etkisi tek bir yerde kalmıyor. Tablo, aynı farkın üç ayrı sonucu nasıl doğurduğunu gösteriyor.

İkinci satırın pratik sonucu geri getirmeli sistemlerde doğrudan kaliteye yansıyor. Aynı pencere bütçesiyle Türkçe belgelerden daha az parça taşınabiliyor; yani sistem İngilizce bir kurulumla aynı yapılandırmada çalıştırıldığında Türkçede daha az kanıtla cevap üretiyor. Bu, modelin Türkçe yeteneğiyle ilgili değil — tümüyle bir bütçe sorunu ve yapılandırmayla düzeltilebilir.

Kanıt: ölçüp yönetmenin yolu#

Bu fark tahmin edilmeye değil ölçülmeye uygun; ölçümü de basit. Aşağıdaki adımlar kendi sisteminizdeki katsayıyı ortaya çıkarıyor.

1. 01Kendi metninizle ölçün: tipik istem ve tipik belgelerinizin token sayısını sayın. Genel oranlar yerine kendi katsayınızı kullanın.
2. 02Karakter başına token oranını kaydedin: bu oran, bütçe tahminlerinin dayanağı olacak tek sayı.
3. 03Model bazında karşılaştırın: tokenleştiriciler farklı; aynı Türkçe metin modeller arasında belirgin farklı token sayıları veriyor.
4. 04Bağlam bütçesini token ile ifade edin: "on belge" değil "şu kadar token" demek, Türkçe içerikle doğru davranıyor.
5. 05Çıktı uzunluğunu sınırlayın: çıktı token'ı hem fiyatta hem gecikmede daha pahalı; kısa cevap talimatı iki yerde kazandırıyor.
6. 06Özetleme katmanı düşünün: uzun Türkçe belgeler pencereye sığmıyorsa özet parçalar taşımak, kırpmadan iyi.
7. 07Karşılaştırmaları dil bazlı yapın: İngilizce ölçümlerle yapılan maliyet ve kalite kıyasları Türkçe için geçerli değil.

Dördüncü madde en çok fark yaratan tek değişiklik. Bağlam bütçesi genellikle parça sayısıyla ifade ediliyor — "en ilgili on parçayı al" gibi. Türkçe parçalar daha fazla token tuttuğu için bu yapılandırma, aynı sayıda parçayla pencereyi daha çok dolduruyor ve bazen taşırıyor. Bütçe token cinsinden ifade edildiğinde sistem dile göre kendini ayarlıyor ve taşma da ortadan kalkıyor.

Mekanizma: eklemeli dilin tokenleştiricideki hâli#

Türkçenin yapısı tokenleştirme açısından iki yönlü bir etki üretiyor ve bu ikisinin toplamı dezavantaj yönünde çalışıyor.

Bir yandan Türkçe bilgi yoğun: İngilizcede birkaç kelimeyle anlatılan bir şey tek bir kelimeye sığabiliyor. Bu, karakter sayısında avantaj demek. Öte yandan o tek kelime, tokenleştiricinin sözlüğünde bulunmadığı için birçok parçaya bölünüyor ve kazanç ortadan kalkıyor — hatta tersine dönüyor. İkinci bir mekanizma Türkçe harflerde: bazı tokenleştiriciler Türkçeye özgü harfleri tek başına birer birim olarak ele alıyor ve o harfleri içeren kelimeler daha fazla parçaya bölünüyor. Bunun bir yan sonucu da var: aynı kelimenin farklı ekli hâlleri farklı token dizilerine dönüştüğü için, kelime bazlı sayımlara dayanan hesaplar Türkçede daha çok sapıyor. Bu yüzden Türkçe sistemlerde bütçe hesabı kelime ya da karakter değil doğrudan token cinsinden yapılmalı — ve ölçüm kendi metniniz üzerinde yapılmalı, çünkü katsayı metin türüne göre de değişiyor.

Karşı görüş#

Üç itiraz var. Birincisi: yeni model kuşaklarında çok dilli sözlükler genişledi ve fark küçülüyor. İkincisi: token maliyeti toplam maliyetin küçük bir bölümü; asıl maliyet mühendislik. Üçüncüsü: bu bir doğa durumu, yapılabilecek bir şey yok.

Bütçeyi parça sayısıyla veriyorduk. Türkçe belgelerde pencere taşıyor, kırpma kritik paragrafı kesiyordu. Bütçeyi token cinsine çevirince sorun bir günde kapandı.

Birinci itiraz doğru yönde ve izlenmeli: çok dilli sözlükler genişledikçe fark küçülüyor. Ama fark modele göre değiştiği için bu bir ölçüm gerekliliği doğuruyor, ihmal gerekçesi değil — model seçiminde token verimliliği bir karşılaştırma boyutu hâline geliyor. İkinci itiraz düşük hacimde doğru, yüksek hacimde değil; ayrıca etki yalnızca fiyatta değil etkin pencerede ve gecikmede de görünüyor ve bu ikisi kaliteyi doğrudan etkiliyor. Üçüncü itiraz alıntının doğrudan çürüttüğü yer: yapılabilecek şeyler var ve çoğu yapılandırma düzeyinde — bütçeyi token cinsinden ifade etmek, çıktı uzunluğunu sınırlamak, özet parçalar taşımak ve model seçiminde token verimliliğini hesaba katmak.

Sınırlar ve belirsizlik#

Bu analiz bir oran vermiyor; oranın kendi metninizle ölçülmesi gerekiyor.

• Katsayı modele bağlı: aynı Türkçe metin farklı tokenleştiricilerde belirgin farklı token sayıları veriyor.
• Katsayı metin türüne bağlı: teknik metin, günlük dil ve resmî yazışma farklı oranlar üretiyor.
• Kalite etkisi ayrı bir konu: bu analiz maliyet ve bütçe tarafına dair; Türkçe kalite farkı ayrıca ölçülmeli.
• Sözlükler genişliyor: yeni kuşaklarda fark küçülebilir, bu yüzden ölçüm dönemsel tekrarlanmalı.

Sonuç#

Token başına fiyatlandırma dilden bağımsız görünüyor ama değil: sözlüğün hangi dilden çıktığı, o dilin metinlerini daha verimli temsil ediyor. Türkçe hem sözlükteki payı düşük olduğu için hem eklemeli yapısı nedeniyle daha çok token tutuyor ve bu, faturada ayrı bir kalem olarak görünmeyen bir maliyet farkı üretiyor.

Etki üç yerde: maliyette, etkin bağlam boyutunda ve gecikmede. İkincisi hiç görünmüyor ve kaliteye doğrudan yansıyor — aynı yapılandırma Türkçede daha az kanıtla cevap üretiyor. Düzeltmenin en yüksek getirili adımı bağlam bütçesini parça sayısı yerine token cinsinden ifade etmek; bu tek değişiklik hem taşmayı hem kırpma kaynaklı bilgi kaybını ortadan kaldırıyor. Katsayı ise tahmin edilmemeli, kendi metninizle ölçülmeli.

Ne yapmalı?#

1. 1Kendi katsayınızı ölçün

   Tipik istem ve belgelerinizin token sayısını sayın; genel oranlar yerine kendi sayınızı kullanın.

2. 2Bağlam bütçesini token cinsine çevirin

   "On parça" yerine "şu kadar token". Tek değişiklikle taşma ve kırpma kaybı kapanıyor.

3. 3Çıktı uzunluğunu sınırlayın

   Çıktı token'ı hem fiyatta hem gecikmede daha pahalı; kısa cevap talimatı iki yerde kazandırıyor.

4. 4Model seçimine token verimliliğini ekleyin

   Aynı Türkçe metin modeller arasında farklı token sayıları veriyor; bu bir karşılaştırma boyutu.

5. 5Uzun belgeler için özet parça taşıyın

   Pencereye sığmayan Türkçe belgelerde özet taşımak, kırpmadan daha az bilgi kaybediyor.

6. 6Karşılaştırmaları dil bazlı yapın

   İngilizce ölçümlerle yapılan maliyet ve kalite kıyasları Türkçe için geçerli değil.