Tokenlar, Tokenizer’lar ve Context Window

“Çoğu insan bir LLM’in kelimeleri okuduğunu düşünür. Okumaz. Yerel bir model sana cevap verebilmeden önce, metnin token denilen daha küçük parçalara bölünmesi, sayılara dönüştürülmesi ve context window denilen sınırlı bir çalışma alanına yerleştirilmesi gerekir.”

Bu anlaşıldığında, birçok LLM tuhaflığı anlam kazanır: uzun promptlar neden yavaşlatır, modeller neden önceki mesajları unutur, çıktı uzunluğu neden önemli, farklı modeller metni neden farklı sayar.

Öne Çıkanlar

• Tokenlar kelime değil, metin parçalarıdır (1 token ≈ 3-4 karakter)
• Context window giriş ve çıkış tokenlerini paylaşır
• Tokenizer seçimi token sayısını ve verimliliği etkiler
• Aktif context’te olmayan bilgi modele görünmez

Model Metni Doğrudan Görmez

Prompt yazdığında model bu cümleyi insanın okuyabileceği metin olarak almaz. Önce metin bir tokenizer’dan geçer. Tokenizer metni parçalara böler, sonra her parçayı bir sayıya eşler. Model o sayıları görür.

Basitleştirilmiş örnek:

Metin: “Local LLMs are useful”

Tokenizer: [“Local”, ” L”, “LM”, “s”, ” are”, ” useful”]

Token ID’leri: [9012, 426, 11234, 82, 527, 6043]

Tam bölme tokenizer’a bağlıdır. Bazı tokenler tam kelimeler, bazıları kelime parçaları, bazıları boşluk veya noktalama içerir.

Çıkarım: Bir LLM promptunu kelime olarak okumaz. Tokenizer’ının ürettiği token sayıları dizisini okur.

Tokenlar Kelime Değil, Parçalardır

Bir token genellikle bir metin parçasıdır:

• Tam bir kelime: “apple”
• Bir kelimenin parçası: “app” + “le”
• Boşluk + kelime: ” hello”
• Noktalama işareti: “.”
• Sayı parçası: “202” + “6”
• Özel işaret: metnin başlangıcı, sohbet formatlaması

İngilizce metin için kaba kural: 1 token ≈ 3-4 karakter, 100 token ≈ 75 kelime. Ama kod, emoji, matematik ve Türkçe metinler çok farklı tokenize edilebilir.

“hello” 1 token olabilirken, uzun bir kelime veya emoji birden fazla token kullanabilir.

Çıkarım: Tokenlar modelin metin birimleridir. Kelimelerle ilgili ama aynı şey değiller.

Tokenizer, Metinden Sayıya Çevirmendir

Tokenizer iki iş yapar:

Encoding: Metni token ID’lerine dönüştürür.

Decoding: Token ID’lerini tekrar metne çevirir.

Model belirli bir tokenizer ile eğitildi. Tokenizer, modelin temsil edebildiği token parçaları kümesini (kelime dağarcığını) tanımlar.

Yanlış tokenizer kullanırsan giriş ID’leri modelin eğitim verisiyle eşleşmez. Sonuç kırık veya kullanılamaz olur.

Model paketleri genellikle ağırlık, config ve tokenizer dosyalarını birlikte içerir.

Çıkarım: Tokenizer isteğe bağlı bir yardımcı değil. Modelin metni anlamasının parçasıdır.

Farklı Modeller Metni Farklı Böler

Tüm tokenizer’lar aynı şekilde davranmaz. Aynı cümle farklı modellerde farklı token dizilerine dönüşebilir.

Örnek:

Metin: “Tokenization matters.”

Tokenizer A: [“Token”, “ization”, ” matters”, “.”]

Tokenizer B: [“Tokenization”, ” matters”, “.”]

Her ikisi de çalışabilir ama model kendi tokenizer’ının ID’lerini bekler. Bu, token sayılarının modeller arasında neden farklı olduğunun sebeplerinden biridir.

Ayrıca pratik kullanımı etkiler. Daha verimli tokenize eden bir tokenizer aynı context window’a daha fazla bilgi sığdırabilir.

Çıkarım: Token sayıları modele özgüdür. Aynı metin farklı tokenizer’larda farklı sayıda token maliyeti olabilir.

Context Window, Aktif Çalışma Alanı Demek

Context window, modelin bir seferde aktif olarak işleyebildiği maximum token sayısıdır.

• 8K context window → yaklaşık 8.000 token
• 32K context window → yaklaşık 32.000 token
• 128K context window → yaklaşık 128.000 token

Modelin 128K tokeni kalıcı olarak hatırladığı anlamına gelmez. Mevcut oturum girdisinde aktif olarak işleyebildiği maksimum budur.

Aktif context şunları içerir: sistem promptu, sohbet formatlama tokenleri, kullanıcı mesajları, asistan mesajları, alınan metin, araç çıktıları, kod, talimatlar.

Çıkarım: Context window, modelin kalıcı belleği değil, aktif token bütçesidir.

Giriş ve Çıkış Aynı Bütçeyi Paylaşır

Context window şu ikisi arasında paylaşılır: gönderdiğin prompt ve modelin ürettiği cevap.

8K context window’lu bir modelde prompt zaten 7.000 token kullanıyorsa, cevap için çok az yer kalır.

Bu yüzden uzun bir prompt cevabı dışarıya itebilir. Detaylı açıklama isteyebilirsin ama context zaten doluyorsa modelin üretmesi için daha az alan olur.

Yerel inference’da context boyutunu doğrudan kontrol edersin, bu yüzden etki daha görünürdür.

Çıkarım: Context sadece ne kadar yapıştırabileceğini değil, modelin ne kadar cevap verebileceğini de sınırlar.

Uzun Promptlar Bedava Değil

Daha uzun context window kullanışlıdır ama sihir değildir. Model verdiği tokenleri işlemek zorundadır.

Daha fazla token şu anlama gelir:

• Daha fazla bellek kullanımı
• Daha fazla işlem gücü
• Daha yavaş prompt işleme
• Daha büyük KV cache
• Donanım üzerinde daha fazla baskı

Yerel donanımda kısa bir prompt hızlı üretmeye başlayabilir. Binlerce token içeren devasa bir prompt, ilk çıktı tokeni görünmeden önce zaman harcayabilir.

Buna prompt processing veya prefill denir. Uzun promptlar bu ilk aşamayı ağırlaştırır.

Çıkarım: Daha uzun context daha fazla alan verir ama yerel inference’ı yavaşlatabilir ve bellek kullanımını artırabilir.

Modeller Neden “Unutuyor” Gibi Görünür

İnsanlar “model unuttu” dediğinde genellikle iki şeyden biri anlaşılır:

1. Bilgi hiç modelin aktif context’inde değildi.
2. Bilgi context’te bir zamanlar vardı ama dışarı itildi.

Sürekli büyüyen bir sohbette context window dolduğunda eski mesajlar truncated, özetlenmiş veya düşürülmüş olabilir.

Model, aktif context’inde olmayan bilgiyi güvenilir şekilde kullanamaz — ta ki eğitim sırasında zaten öğrenilmiş veya harici bir sistem tarafından yeniden eklenmiş olmadığı sürece.

Bellek Türleri:

• Context: Modele şu anda görünür tokenler
• Training bilgisi: Model ağırlıklarında depolanan örüntüler
• Sohbet geçmişi: Uygulama tarafından kaydedilen mesajlar
• Uzun vadeli bellek: Harici notlar veya veritabanı girdileri

Çıkarım: Aktif context’te değilse, modelin onu kullanabileceğini varsayma.

Context Length Prompting’i Nasıl Değiştirir

Token bütçeleri anlaşıldığında prompting daha pratik hale gelir.

Artık “Modele ne kadar metin dökebilirim?” yerine “Modelin iyi cevap vermesi için aktif context’inde gerçekten ne bilmesi gerekiyor?” diye düşünürsün.

Kısa, kesin bir prompt genellikle devasa düzensiz bir taneden daha iyi çalışır. Alakasız context sinyali seyreltebilir.

Bir projeyi özetlerken her dosyayı yapıştırmak yerine projenin amacı, ilgili dosya, spesifik soru ve kısıtlamaları vermek daha iyi sonuç verir.

Context bir bütçedir. Önemli olana harca.

Çıkarım: Daha iyi prompting her zaman daha fazla context değildir. Daha iyi prompting doğru contexttir.

Basit Token Bütçesi Çerçevesi

Her LLM sohbeti bir token bütçesine sahiptir. Bu bütçe şu şekilde harcanır:

1. Sistem talimatları
2. Sohbet formatlaması
3. Kullanıcı promptu
4. Sohbet geçmişi
5. Yapıştırılan belgeler veya kod
6. Alınan bilgi
7. Modelin cevabı

Büyük bir prompt göndermeden önce sor:

• Model ne bilmeli?
• Neyi kaldırabilirim?
• Cevap ne kadar uzun olmalı?
• Eski sohbet geçmişi önemli olanı dışarıya itecek mi?
• Bu görev daha büyük context model mi gerektiriyor, yoksa sadece daha temiz bir prompt mu?

Çıkarım: Context’i sabit bütçeli çalışma belleği gibi düşün. Tokenleri kasıtlı harca.

Pratik Sonraki Adım

Token sayılarını gösteren herhangi bir yerel model UI’siyle bunu dene:

Aynı isteğin üç versiyonunu yapıştır:

• Kısa bir prompt
• Çok fazla ek context içeren uzun bir prompt
• Sadece gerekli context içeren temiz bir prompt

Karşılaştır: token sayısı, ilk token’e kadar geçen süre, çıktı kalitesi, cevabın talimatları takip edip etmediği.

Hızla sezgi geliştireceksin.

Çıkarım: Tokenleri anlamanın en hızlı yolu, farklı promptların context’i nasıl tükettiğini karşılaştırmaktır.

Temel Zihinsel Model

Token ID’leri → Model → Sonraki token tahmini → Token ID’leri → Tokenizer → Metin

Ve temel kural: Giriş tokenleri + çıkış tokenleri context window’a sığmalıdır.

Bu tek kural çok şeyi açıklar: uzun promptlar neden yavaşlatır, cevaplar neden kısa kesilebilir, eski sohbet neden kaybolur, tokenizer seçimi neden önemli, context length neden gerçek bir donanım ve iş akışı kısıtlaması.

Çıkarım: Tokenler birimler, tokenizer’lar çevirmenler ve context window’lar aktif çalışma alanıdır.

Serideki Yeri

Önceki makalede inference’ı ele aldık: model sonraki tokeni tahmin eder, ekler, sonra tekrarlar.

Şimdi o tokenlerin ne olduğunu ve nerede olduğunu biliyorsun.

Sırada: 03 – Weights, Parameters ve Modelin Ne Öğrendiği

O makale şu açık soruyu cevaplıyor: “Model sadece token tahmin ediyorsa, ‘bilgi’ nerede saklanıyor?”

Seriye genel bakış:

• ✅ 00 – Local LLMs’e Giriş
• ✅ 01 – Inference ve Diziler
• ✅ 02 – Tokenlar, Tokenizer’lar ve Context Window (bu makale)
• 🔜 03 – Weights, Parameters ve Modelin Ne Öğrendiği

Sık Sorulan Sorular

Token sayısı ile kelime sayısı aynı mı?

Hayır. 1 token genellikle 3-4 karakterdir ama bu dil, içerik türü ve tokenizer’a göre değişir. Emoji, kod ve Türkçe metinler farklı oranlarda tokenize edilir.

Context window dolunca ne olur?

Eski mesajlar truncated, özetlenmiş veya düşürülür. Model aktif context’inde olmayan bilgiyi kullanamaz.

Daha büyük context window her zaman daha iyi mi?

Hayır. Daha büyük context daha fazla bellek ve işlem gücü gerektirir. Yerel donanımda 128K context kullanmak ciddi kaynak tüketebilir.

Farklı modellerde aynı prompt farklı token sayısına sahip olabilir mi?

Evet. Tokenizer’lar farklı bölme stratejileri kullanır. Bu, token sayılarını ve dolayısıyla context kullanımını etkiler.

Tokenizasyonu kendim kontrol edebilir miyim?

Bazı araçlar (Ollama, LM Studio) token sayılarını gösterir. Tokenizer viewer araçlarıyla da metnin nasıl bölündüğünü inceleyebilirsin.

Sonuç ve Sonraki Adım

Tokenler, tokenizer’lar ve context window’u anlamak, lokal LLM’lerle çalışırken en temel becerilerden biridir. Promptlarını kasıtlı tasarlayarak hem hızı hem kaliteyi artırabilirsin.

Sonraki adım: Aynı promptun farklı versiyonlarını test et ve token tüketimini karşılaştır. Hangi değişikliklerin context’i nasıl etkilediğini gözlemle.

Serinin bir sonraki makalesinde ağırlıkların ve parametrelerin modelin “bilgi”yi nasıl sakladığını inceleyeceğiz.