LLM Aslında Nasıl Çalışır? Token, Context Window ve Halüsinasyon Basitçe Ne Demek

"Bu model neden düpedüz yalan söylüyor?" ya da "Neden 40 sayfalık dosyayı verince tuhaflaşıyor?" — büyük dil modelleriyle (LLM) çalışan hemen herkesin er ya da geç sorduğu iki soru bu. Cevap aslında modelin nasıl 'okuduğu' ve nasıl 'ürettiği' ile ilgili üç basit kavramda saklı: token, context window ve halüsinasyon. Bu üçünü anladığında, bir yapay zekanın neden bazen harika çalıştığını, neden bazen saçmaladığını ve neden faturanızın beklediğinizden yüksek geldiğini de anlarsınız. Müşteri projelerinde LLM entegre ederken karşılaştığım sürprizlerin büyük kısmı, tam olarak bu üç kavramın yanlış anlaşılmasından çıkıyor — o yüzden burada jargon olmadan, somut örneklerle anlatıyorum. Teknik geçmişiniz olmasa da bu üç kavramı bir kez oturttuğunuzda, bir yapay zeka ürününe ne zaman güvenip ne zaman temkinli yaklaşmanız gerektiğine dair çok daha net bir sezgi kazanırsınız.

##Token Nedir? Bir Model Kelimeleri Değil, Tokenları Okur

Bir LLM'e bir cümle gönderdiğinde, model o cümleyi kelime kelime değil, 'token' dediğimiz daha küçük parçalara bölerek işler. Token bazen tam bir kelimedir ('masa' tek token olabilir), bazen bir kelimenin parçasıdır ('kahvaltı' iki-üç parçaya bölünebilir), bazen de tek bir noktalama işareti veya boşluktur. İngilizce metinde kabaca her 4 karaktere 1 token düşer; Türkçe gibi eklerin bol olduğu bir dilde bu oran biraz daha yüksek çıkar, çünkü model çoğu zaman kök ile eki ayrı tokenlar olarak görür. Bu teknik detayın iki somut sonucu var. Birincisi, faturanız kelime sayısına değil token sayısına göre kesilir — yani aynı anlamı daha sade, daha az kelimeyle ifade etmek gerçekten para biriktirir. İkincisi, model bir kelimeyi tek bütün olarak 'görmediği' için, bir kelimenin tam ortasından harf saydırmak gibi basit görünen görevlerde şaşırtıcı derecede kötü olabilir — çünkü o kelime, modelin gözünde zaten birkaç parçaya bölünmüş durumdadır. Somut bir örnek verelim: 200 kelimelik gereksiz uzun bir sistem promptu kullanan bir chatbot, günde 5.000 istek alan bir üründe, sadece bu fazlalık yüzünden ayda onbinlerce token'lık ek maliyete yol açabilir — tek bir isteğe bakınca önemsiz görünen birkaç saniyelik yazım tembelliği, ölçekte gerçek bir kalem haline gelir.

##Context Window Nedir ve Bir Sohbet Neden Bir Noktadan Sonra 'Unutmaya' Başlar

Context window (bağlam penceresi), modelin bir seferde 'görebildiği' toplam token miktarıdır — sistem promptu, sizin yazdığınız mesaj, önceki sohbet geçmişi ve varsa eklediğiniz belgeler, hepsi bu pencerenin içine sığmak zorundadır. Günümüzde yaygın modellerin çoğu 100 bin ile birkaç yüz bin token arasında bir pencereye sahip, bazı modeller milyon token seviyesine kadar çıkabiliyor — ama bu üst sınırın büyük olması 'sınırsız' demek değil; her ekstra token hem maliyeti hem de yanıt süresini artırır. Model, kelimenin gerçek anlamıyla bir 'hafızaya' sahip değildir; her yeni mesajda, o ana kadarki tüm konuşmayı yeniden, baştan işler. Bu yüzden uzun bir sohbette 40. mesaja geldiğinizde, model ilk birkaç mesajdaki bir detayı 'unutmuş' gibi görünebilir — aslında unutmamıştır, ama pencere doluysa ya da o detay çok geride kaldıysa, oraya aynı dikkati vermekte zorlanır. Bazı uygulamalar pencere dolduğunda eski mesajları sessizce kırpar; 'az önce söylediğimi neden hatırlamıyor' sorusunun teknik cevabı çoğu zaman budur.

Bunun pratik sonucu şu: bir müşteri destek chatbotu tasarlıyorsanız, tüm konuşma geçmişini sonsuza kadar modele göndermek hem gereksiz maliyet hem de gereksiz dikkat dağınıklığı yaratır. İyi tasarlanmış ürünlerin çoğu, tüm geçmişi değil, sadece son birkaç mesajı ve konuşmanın kısa bir özetini gönderir — bu hem faturayı düşürür hem modelin odağını korur. Sayılarla bakınca fark daha net görülür: 50 mesajlık bir sohbet geçmişinin tamamını her seferinde göndermek, konuşma uzadıkça giderek büyüyen bir token yüküne denk gelirken, son 6-8 mesaj artı kısa bir özet çoğu zaman bunun çok altında kalır. Küçük bir ürün için önemsiz görünen bu optimizasyon, binlerce aktif kullanıcısı olan bir üründe aylık faturanın kayda değer bir kısmını oluşturabilir.

##Gerçek Bir Senaryo: 50 Sayfalık Bir Sözleşmeyi Modele Verdiğinizde Ne Olur

Bunu somutlaştırayım. Diyelim ki bir hukuk bürosu için 50 sayfalık bir sözleşmeyi özetleyen bir araç kuruyorsunuz. 50 sayfalık Türkçe bir metin kabaca 25-35 bin token civarına denk gelir. Bunu doğrudan modele gönderdiğinizde — sistem promptu ve talimatlarla birlikte — context window'un önemli bir kısmı dolar; büyük pencereli bir modelde bu teknik olarak sorun değildir, ama modelin 'dikkati' pratikte pencerenin ortasındaki bilgilere göre başındaki ve sonundaki bilgilere genelde daha güçlü tutunur. Yani sözleşmenin 30. sayfasındaki kritik bir madde, bazen 2. sayfadaki kadar net yakalanmayabilir. Bunu bildiğiniz için, üretimde tek seferde 'tüm dosyayı at, özetle' yerine, dosyayı bölümlere ayırıp her bölümü ayrı ayrı işleyen ve sonunda birleştiren bir mimari (chunking + map-reduce) kurarsınız. Ya da RAG yaklaşımıyla, modele sadece soruyla doğrudan alakalı bölümleri gönderirsiniz. Sonuç: aynı model, aynı içerik, ama mimariye göre doğruluk oranı ciddi şekilde değişir — bu fark 'modeli değiştirmek' değil, 'modele veriyi nasıl sunduğunuzu değiştirmek' meselesidir.

##Halüsinasyon Nedir? Bir Model Neden Kendinden Emin Biçimde Yanlış Söyler

Halüsinasyon, modelin gerçek olmayan bir bilgiyi tereddütsüz ve akıcı bir şekilde üretmesidir — uydurma bir hukuk maddesi, var olmayan bir API fonksiyonu, yanlış bir tarih. Kök neden basit: bir LLM, 'doğruyu bilip söyleyen' bir sistem değil, 'bir sonraki tokenın istatistiksel olarak en olası ne olduğunu tahmin eden' bir sistemdir. Elinde net bir bilgi olmasa bile, cümleyi bitirmek için en makul görünen kelimeyi üretmeye devam eder — çünkü eğitim verisinde 'bilmiyorum' demek, akıcı ve kendinden emin bir cevap kadar yaygın bir örüntü değildir. Model kendi cevabının doğru mu yanlış mı olduğunu gerçekten 'bilmez'; sadece o cevabın dilbilgisel ve bağlamsal olarak makul göründüğünü 'bilir'. Örneğin bir hukuk asistanına var olmayan bir Yargıtay kararının numarasını sorduğunuzda, model çoğu zaman 'böyle bir karar bulamadım' demek yerine, gerçek kararlara çok benzeyen ama tamamen uydurma bir numara ve gerekçe üretebilir — çünkü öğrendiği örüntü budur.

Halüsinasyon en çok üç durumda artar: model eğitim verisinde az geçen niş bir konuda soru sorulduğunda, güncel — yani eğitim tarihinden sonraki — bir bilgi istendiğinde ve modelin elinde olmayan spesifik bir kaynağa (belirli bir doküman, belirli bir yasa maddesi, belirli bir sayfa numarası) atıf yapması istendiğinde. Azaltmanın en etkili üç yolu: modele gerçek kaynağı context olarak vermek (RAG), modelden kaynak göstermesini ve emin olmadığında bunu açıkça söylemesini istemek, ve düşük riskli olmayan çıktıları (hukuki, tıbbi, finansal) bir insanın gözden geçirmesini süreçten çıkarmamaktır. Halüsinasyonu sıfıra indiren tek bir 'anahtar' yok — ama doğru mimariyle çok düşük bir orana indirmek mümkün.

##Bunu Bilmek Pratikte Ne Değiştirir? Kurucular İçin Çıkarımlar

• ▸Token bazlı fatura mantığını bilerek prompt yazın: gereksiz uzun sistem promptları, tekrarlanan talimatlar ve aşırı ayrıntılı örnekler her istekte yeniden faturalanır.
• ▸Context window'u 'sonsuz hafıza' gibi kullanmayın: uzun sohbetlerde özet + son birkaç mesaj yaklaşımı hem daha ucuz hem daha isabetlidir.
• ▸Kritik bilgiyi promptun başına veya sonuna koyun, ortasına gömmeyin — modelin dikkati pratikte oralarda daha güçlüdür.
• ▸Yüksek riskli çıktılarda (fiyat, hukuki madde, tıbbi bilgi) modelin cevabını olduğu gibi kullanıcıya göstermeyin; bir doğrulama katmanı veya insan onayı ekleyin.
• ▸Spesifik ve güncel bilgi gerektiren her özellikte RAG düşünün — modelin kendi hafızasına değil, sizin sağladığınız gerçek veriye güvenmesini sağlar.
• ▸Farklı görevler için farklı model boyutları kullanın: basit sınıflandırma için küçük/hızlı bir model, karmaşık analiz için büyük bir model — ikisini aynı işe koşmak gereksiz maliyettir.

##Sık Sorulan Sorular

>Token ile kelime aynı şey mi?

Hayır. Bir token bazen bir kelimenin tamamı, bazen bir parçası, bazen tek bir karakterdir. Kabaca İngilizce metinde 100 kelime 130-150 token'a denk gelir; Türkçe'de ekler nedeniyle bu oran biraz daha yüksek olabilir.

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

Hayır. Daha büyük pencere daha fazla bilgi sığdırmanızı sağlar ama modelin dikkatini dağıtabilir ve maliyeti artırır. Elinizdeki bilgiyi ilgili kısımlara indirip (RAG, chunking) öyle vermek, çoğu zaman 'her şeyi tek seferde at' yaklaşımından daha isabetli sonuç verir.

>Halüsinasyonu tamamen önlemenin bir yolu var mı?

Hayır, bugünkü LLM mimarileriyle sıfır halüsinasyon garantisi yok. Ama modele gerçek kaynağı context olarak vermek (RAG), düşük 'temperature' ayarı kullanmak ve kritik çıktılarda insan doğrulaması eklemek oranı ciddi şekilde düşürür.

>Bir model neden bazen aynı soruya farklı cevaplar veriyor?

Çünkü çoğu model, bir sonraki tokenı seçerken belirli bir rastgelelik ('temperature') kullanır — en olası tek kelimeyi değil, bir olasılık dağılımından örnekleme yapar. Temperature'ı düşürmek cevapları daha tutarlı ve deterministik yapar, ama yaratıcılığı da azaltır.

>Küçük/hızlı bir model mi, büyük/akıllı bir model mi seçmeliyim?

Göreve bağlı. Basit sınıflandırma, kısa özetleme veya biçimlendirme gibi işlerde küçük ve hızlı bir model çoğu zaman yeterli ve çok daha ucuzdur; çok adımlı akıl yürütme, karmaşık kod üretimi veya nüanslı analiz gerektiren işlerde büyük modelin doğruluğu farkı gerçekten yaratır. Aynı üründe iki farklı boyutu farklı adımlarda kullanmak, hem maliyeti hem yanıt hızını dengelemenin en pratik yolu.

Çoğu 'yapay zeka neden böyle davranıyor' sorusunun cevabı, gizemli bir 'zeka' arızasında değil, bu üç mekanizmanın nasıl işlediğinde saklı. Token, context window ve halüsinasyon — bu üç kavram bir LLM'in neden bazen mükemmel, bazen tuhaf davrandığının teknik iskeletini oluşturuyor. Bunu bir kez anladığınızda, hem ürününüze yapay zeka eklerken doğru mimari kararları verebilir hem de bir modelden gelen cevaba ne kadar güvenip güvenmeyeceğinizi daha iyi tartabilirsiniz. RAG'ın bu sorunları nasıl çözdüğünü daha ayrıntılı görmek isterseniz ilgili yazıya, ya da web uygulamasına LLM entegrasyonunun adım adımına başka bir yazıya göz atabilirsiniz; kendi ürününüz için bir mimari değerlendirmesi istiyorsanız iletişime geçebilirsiniz.