Context Window Nedir? Yapay Zeka Neden Unutuyor? (2026)

Context window nedir? Context window (bağlam penceresi), bir büyük dil modelinin (LLM) tek bir istekte aynı anda “görebildiği” ve işleyebildiği maksimum metin miktarıdır; bu miktar token adı verilen küçük metin parçaları cinsinden ölçülür. Bir modelin context window’u ne kadar büyükse, tek seferde o kadar uzun bir sohbet geçmişini, dokümanı veya kod tabanını girdi olarak kabul edebilir; bütün bilgiyi doğru kullanması veya tutarlı yanıt vermesi garanti değildir. Bu rehberde context window kavramının teknik olarak ne anlama geldiğini, neden sınırlı olduğunu, pratikte hangi sorunlara yol açtığını ve bu sınırı aşmak için geliştiricilerin kullandığı somut yöntemleri (chunking, özetleme, RAG) ele alıyoruz.

Context Window Nedir, Token ile İlişkisi Ne?

Bir yapay zeka modeli metni doğrudan harf veya kelime olarak değil, token adı verilen alt birimler halinde işler. Türkçe gibi eklemeli dillerde bir kelime genellikle birden fazla token’a bölünür; İngilizcede ise kısa kelimeler çoğunlukla tek token olarak kalır. Context window, modelin bir istek içinde işleyebileceği toplam token sayısını (girdi + çıktı toplamı, bazı sağlayıcılarda ayrı ayrı sınırlanır) belirler. Bu sınırın üzerine çıkan metin ya kesilir ya da istek doğrudan hata döner.

Token kavramını daha ayrıntılı incelemek isteyenler için sitemizdeki Tokenization Nedir? rehberi, bu iki kavramın birbirini nasıl tamamladığını gösteriyor: tokenization metni parçalara ayırma işlemidir, context window ise bu parçalardan kaçının aynı anda hafızada tutulabileceğinin üst sınırıdır.

Neden “Pencere” Deniyor?

Pencere benzetmesi, modelin yalnızca belirli bir aralıktaki metni “görebilmesinden” geliyor. Konuşma uzadıkça, önceki mesajlar bu pencerenin dışına taşabilir; model, penceresinin dışında kalan bilgiyi hatırlamaz. Bu, insan hafızasındaki kısa süreli bellek sınırına benzetilebilir, ancak model tarafında bu sınır kesin ve sayısal bir değerdir.

Context Window Neden Sınırlı? Teknik Nedenler

Modern LLM’lerin büyük çoğunluğu transformer mimarisini kullanır ve bu mimarideki “self-attention” mekanizması, işlenen her token çiftini birbiriyle karşılaştırır. Pratikte bu, hesaplama ve bellek maliyetinin token sayısının karesiyle orantılı büyüdüğü anlamına gelir (bazı yeni mimarilerde bu oran optimize edilse de temel eğilim böyledir). Yani context window’u iki katına çıkarmak, sunucu tarafındaki işlem yükünü kabaca dört katına çıkarabilir. Bu yüzden sağlayıcılar context window’u sınırsız büyütmek yerine, maliyet ile kullanılabilirlik arasında bir denge noktası seçiyor.

Büyük bağlam kabulü, bağlamın her konumundaki bilginin aynı doğrulukla kullanılacağı anlamına gelmez. Lost in the Middle araştırması, test edilen modellerde ilgili bilgi ortada olduğunda bazı görevlerde başarımın başa veya sona yerleştirmeye göre düştüğünü gösterdi. Bu, her model ve görev için değişmez bir yasa değildir; kendi uzun belge testinizi yapın.

Karesel Maliyet Neden Bu Kadar Önemli?

Yoğun self-attention için n×n dikkat ilişkisi, uzun girdinin prefill hesaplamasının neden büyüdüğünü anlatır. Bu, bütün çıkarım maliyetinin ve KV cache belleğinin n² olduğu anlamına gelmez. Decode, KV cache, FlashAttention ve seyrek/kayan pencere mimarileri farklı maliyetler taşır; pencereyi iki kat büyütmek API faturasını otomatik olarak dört kat yapmaz.

Girdi ve Çıktı Token’ları Aynı Havuzu mu Paylaşır?

Sağlayıcıdan sağlayıcıya değişen önemli bir ayrıntı da şudur: bazı API’lerde girdi (prompt) ve çıktı (yanıt) token’ları tek bir toplam context window havuzunu paylaşır; bazılarında ise girdi ve çıktı için ayrı ayrı üst sınırlar tanımlanır. Uzun bir girdi gönderip ardından uzun bir yanıt beklediğinizde, toplam havuzu paylaşan sistemlerde yanıtın kısa kesilmesi riskiyle karşılaşabilirsiniz. Bu yüzden bir entegrasyona başlamadan önce sağlayıcının dokümantasyonunda bu ayrımın nasıl yapıldığını kontrol etmek, üretim ortamında sürpriz kesintilerin önüne geçer.

Context Window Boyutları: Genel Kategoriler

Sağlayıcıların ilan ettiği tam context window değerleri sürüm güncellemeleriyle sık değiştiği için, burada güncel kesin rakamlar yerine genel kategorileri ve bu kategorilerin pratik etkilerini özetliyoruz. Güncel ve kesin sınırlar için ilgili sağlayıcının resmi model dokümantasyonu kontrol edilmelidir.

Pratikte “büyük pencere” reklamı yapan bir model bile, pencerenin tamamını aynı doğrulukla kullanamayabilir; bu yüzden context window büyüklüğünü tek başına bir kalite göstergesi olarak değil, bir üst sınır olarak değerlendirmek daha doğru.

Context Window Sınırı Pratikte Ne Sorun Yaratır?

1) Uzun Sohbetlerde Hafıza Kaybı

Bir sohbet botu context window sınırına yaklaştığında, genellikle en eski mesajlar penceriden düşürülür (truncation). Kullanıcı sohbetin başında verdiği bir bilgiyi tekrar hatırlatmak zorunda kalabilir.

2) Maliyet Artışı

API tabanlı modellerde ücretlendirme genellikle token sayısına göre yapılır. Gereksiz yere uzun bağlam göndermek, her istekte daha fazla token işlenmesine ve dolayısıyla daha yüksek faturaya yol açar.

3) Yanıt Kalitesinde Düşüş

“Lost in the middle” etkisi nedeniyle, çok uzun bir dokümanın ortasına gömülü kritik bir bilgi, modelin yanıtında atlanabilir veya yanlış hatırlanabilir.

Farklı Uygulama Türlerinde Context Window Yönetimi

Sohbet Botları

Müşteri destek botu gibi uzun süreli sohbetlerde, her yeni mesajla birlikte context window doluyor. Basit bir uygulama tüm geçmişi olduğu gibi gönderirken, olgun bir uygulama belirli bir mesaj sayısından sonra ya kırpma ya da özetleme devreye sokar. Pratikte “son N mesajı ham haliyle tut, daha eskisini tek paragrafta özetle” yaklaşımı, hem bağlam kaybını asgariye indirir hem de maliyeti kontrol altında tutar.

Kod Asistanları

Bir kod tabanını analiz eden yapay zeka aracı için context window yönetimi daha karmaşıktır; çünkü kod dosyaları arasındaki bağımlılıklar (import’lar, fonksiyon çağrıları) genellikle dosya sınırlarını aşar. Bu tür araçlar genellikle dosyaları tek tek göndermek yerine, ilgili dosyaları bir bağımlılık grafiği üzerinden seçip yalnızca değişiklikle doğrudan ilişkili parçaları bağlama dahil eder. WordPress veya Laravel gibi büyük kod tabanlarında çalışan geliştiriciler için bu, “tüm projeyi gönder” yerine “değişen dosya + ona bağlı 2-3 dosya” stratejisinin neden daha verimli olduğunu açıklıyor.

Ajan (Agent) Sistemleri

Birden fazla adımda araç çağıran yapay zeka ajanlarında, her araç çağrısının sonucu (API yanıtı, dosya içeriği, arama sonucu) context window’a eklenir. Uzun süren ajan görevlerinde bu birikim hızla context window’u doldurabilir. Bu nedenle olgun ajan mimarileri, eski araç çıktılarını tam haliyle tutmak yerine yalnızca sonucun özetini bağlamda bırakıp ham veriyi ayrı bir bellek katmanında (ör. bir dosya veya vektör veritabanı) saklar; gerektiğinde bu katmandan tekrar çekilir.

Context Window ve Prompt Caching İlişkisi

Bazı model sağlayıcıları, aynı sistem talimatı veya doküman parçası birden fazla istekte tekrar gönderildiğinde bunu önbelleğe alıp (prompt caching) daha düşük maliyetle işleyebiliyor. Bu, context window sınırını değiştirmez ama büyük ve sabit kalan bir bağlamı (ör. bir ürün dokümantasyonu veya sistem talimatı) tekrar tekrar göndermenin maliyetini önemli ölçüde azaltabilir. Pratikte sabit kalan içerikleri isteğin başına, değişken kullanıcı sorusunu ise sonuna yerleştirmek, önbellekleme mekanizmasının daha verimli çalışmasına yardımcı olur; çünkü çoğu önbellekleme sistemi, isteğin başından itibaren ortak olan kısmı tanır.

Context Window Sınırını Aşmanın Yöntemleri

Yöntem 1: Chunking (Parçalama)

Uzun bir dokümanı, modelin context window’una sığacak küçük parçalara bölüp her parçayı ayrı ayrı işlemek, en temel çözümdür. Parçalama yaparken cümle veya paragraf sınırlarını koruyacak şekilde bölmek, anlam bütünlüğünü korur.

def parcala(metin, max_token=1500, ortalama_char_per_token=4):
    max_char = max_token * ortalama_char_per_token
    paragraflar = metin.split("\n\n")
    parcalar = []
    mevcut = ""
    for p in paragraflar:
        if len(mevcut) + len(p) < max_char:
            mevcut += p + "\n\n"
        else:
            parcalar.append(mevcut.strip())
            mevcut = p + "\n\n"
    if mevcut:
        parcalar.append(mevcut.strip())
    return parcalar

Bu fonksiyon yalnızca karakter tahminiyle paragraf ayırır; token sınırını garanti etmez ve tek uzun paragraf sınırı aşabilir. Üretimde seçilen modelin tokenizer’ıyla ölçüp uzun parçaları ayrıca bölün. Sohbet mesajı, araç şeması ve görsel girdisi ek maliyet taşır; yalnızca düz metni saymak bütün isteğin token hesabı değildir.

Yöntem 2: Gerçek Token Sayımı

import tiktoken

def token_say(metin, model="gpt-4"):
    enc = tiktoken.encoding_for_model(model)
    return len(enc.encode(metin))

print(token_say("Context window nedir, nasıl çalışır?"))

Bir isteği göndermeden önce token sayısını gerçek bir tokenizer ile hesaplamak, hem beklenmedik “context length exceeded” hatalarını hem de gereksiz maliyeti önler.

Yöntem 3: RAG ile Seçici Bağlam

Tüm dokümanı context window’a sıkıştırmak yerine, sorguyla en alakalı parçaları bir vektör veritabanından çekip yalnızca onları modele göndermek, hem maliyeti düşürür hem de “lost in the middle” riskini azaltır. Bu yaklaşımın mantığını sitemizdeki RAG Nedir? rehberinde adım adım anlattık. Pratikte RAG, context window’u “sonsuz” hale getirmez ama dokümanın tamamını her seferinde göndermek yerine, sorguyla anlamsal olarak en yakın birkaç parçayı seçip göndererek aynı context window içinde çok daha geniş bir bilgi tabanına dolaylı erişim sağlar; büyük kütüphaneye erişim için yararlı seçeneklerden biridir; anahtar kelime araması, SQL ve hiyerarşik özetleme de ihtiyaca göre kullanılabilir.

Yöntem 4: Özetleme (Summarization) Zinciri

Çok uzun sohbetlerde, eski mesajları olduğu gibi tutmak yerine periyodik olarak özetleyip context window’a bu özeti eklemek, hem yer kazandırır hem de önemli bilgilerin tamamen kaybolmasını önler. Bu yöntem özellikle çok oturumlu asistan uygulamalarında (kullanıcının günler içinde aynı asistanla defalarca konuştuğu senaryolarda) tercih edilir; her oturum sonunda o oturumun özeti bir sonraki oturumun başlangıç bağlamına eklenir.

Yöntem 5: Kayan Pencere (Sliding Window) Tamponu

Kayan pencere yaklaşımında, yalnızca son N mesaj ham haliyle tutulur; bu sınırın dışına çıkan mesajlar otomatik olarak düşürülür veya özetlenir. Aşağıdaki basit örnek, bir sohbet tamponunun token sınırına göre nasıl yönetilebileceğini gösteriyor:

def pencereyi_guncelle(gecmis, yeni, say_mesajlar, girdi_butcesi):
    # Yalnızca user/assistant metin sohbeti demosu.
    # Sistem talimatı ve çıktı payı bütçeden önceden ayrılmalıdır.
    if not callable(say_mesajlar) or girdi_butcesi <= 0:
        raise ValueError("Geçerli sayaç ve bütçe gerekli")
    mesajlar = [dict(m) for m in gecmis] + [dict(yeni)]
    if any(m.get("role") not in {"user", "assistant"} for m in mesajlar):
        raise ValueError("Araç ve sistem mesajları bu demoda desteklenmiyor")
    if say_mesajlar([yeni]) > girdi_butcesi:
        raise ValueError("Yeni mesaj tek başına bütçeyi aşıyor")
    while say_mesajlar(mesajlar) > girdi_butcesi:
        mesajlar.pop(0)
    return mesajlar

say_mesajlar, kullanılan sağlayıcının mesaj biçimini de hesaba katan bir sayaç olmalıdır. Bu demo sistem talimatını budamaz; talimatlar ve çıktı için pay önce ayrılır. Gerçek araçlı sohbetlerde tool çağrısı ile sonucu birlikte korunmalı, tek tek mesaj silinmemelidir. Özetler de ayrıntı kaybedebilir; kritik bilgiyi kalıcı kaynaktan doğrulayın.

Nasıl Yapılır: Context Window Yönetimi İçin Adım Adım Kontrol

1. Kullandığınız modelin resmi dokümantasyonundan güncel context window sınırını (girdi ve çıktı ayrı ayrı mı sınırlı, toplam mı) doğrulayın.
2. Uygulamanızda gönderdiğiniz istekleri gerçek bir tokenizer ile ölçün; “yaklaşık” karakter sayımına güvenmeyin. Özellikle Türkçe içerikte karakter tabanlı tahminler gerçek token sayısından belirgin şekilde sapabilir.
3. Sohbet geçmişi uzadıkça eski mesajları ya özetleyin ya da bir vektör veritabanı üzerinden yalnızca alakalı kısımları geri çağırın (RAG).
4. Kritik bilgileri (ör. sistem talimatları, kullanıcı tercihleri) pencerenin başına veya sonuna yerleştirin; ortadaki bilgi kaybı riskine karşı bu iki bölge daha güvenilir kabul edilir.
5. Üretim ortamında token kullanımını izleyen bir loglama mekanizması kurun; ani maliyet artışları genellikle gereksiz büyük bağlam gönderiminden kaynaklanır.

Sık Yapılan Hatalar ve Çözümleri

Hata 1: Karakter sayısını token sayısı sanmak. Çözüm: Gerçek tokenizer kütüphanesi (tiktoken veya modelin kendi tokenizer’ı) ile ölçüm yapın; Türkçe metinlerde karakter/token oranı İngilizceden farklıdır.

Hata 2: Tüm sohbet geçmişini olduğu gibi her istekte göndermek. Çözüm: Belirli bir mesaj sayısından sonra özetleme veya kırpma stratejisi uygulayın.

Hata 3: Context window’u kalite göstergesi sanmak. Çözüm: Büyük pencereli bir modelin, pencerenin tamamını aynı doğrulukla kullanamayabileceğini göz önünde bulundurun; kritik bilgiyi başa veya sona yerleştirin.

Hata 4: “Context length exceeded” hatasını yakalamadan üretime çıkmak. Çözüm: İstek göndermeden önce token sayımı yapıp sınıra yaklaşıldığında otomatik özetleme veya parçalama tetikleyen bir güvenlik katmanı ekleyin.

Hata 5: Çıktı token limitini girdi limitiyle karıştırmak. Çözüm: Bazı sağlayıcılar girdi ve çıktı için ayrı sınırlar tanımlar; her iki değeri de dokümantasyondan ayrı ayrı kontrol edin.

Context Window Büyüklüğü Fiyatlandırmayı Nasıl Etkiler?

Çoğu API sağlayıcısı, hem girdi hem de çıktı token’larını ayrı birim fiyatlarla ücretlendirir ve genellikle çıktı token’ları girdi token’larından daha pahalıdır. Bu, context window’u sonuna kadar doldurup her istekte devasa bir bağlam göndermenin, faturaya doğrudan yansıyan bir maliyet kalemi olduğu anlamına gelir. Örneğin bir uygulama her kullanıcı sorusunda 50 sayfalık bir dokümanın tamamını bağlama eklerse, kullanıcı yalnızca dokümanın bir bölümüyle ilgili soru sorsa bile tüm dokümanın token maliyetini öder. Bu noktada RAG yaklaşımı yalnızca teknik değil, doğrudan ticari bir avantaj sağlar: yalnızca alakalı 2-3 paragrafı bağlama ekleyerek aynı soruyu çok daha düşük maliyetle yanıtlamak mümkün olur. Üretim ortamındaki uygulamalarda token kullanımını kullanıcı başına ve özellik başına izlemek, hangi akışların gereksiz yere büyük bağlam gönderdiğini erken tespit etmeye yardımcı olur.

Kime, Hangi Durumda Uygun?

Kısa soru-cevap botları veya tek seferlik özetleme görevleri için küçük-orta context window genellikle yeterlidir ve maliyet açısından daha avantajlıdır. Büyük kod tabanı analizi, uzun hukuki/teknik doküman incelemesi veya çok oturumlu ajan (agent) sistemleri geliştiren ekiplerin ise büyük context window sunan modelleri değerlendirmesi, ancak bunu RAG ve özetleme stratejileriyle birlikte kullanması öneriliyor; yalnızca “büyük pencereye” güvenip tüm veriyi ham haliyle göndermek, hem maliyeti hem de yanıt kalitesizliği riskini artırır.

Sonuç

Context window, bir yapay zeka modelinin ne kadar “hatırlayabildiğini” belirleyen temel teknik sınırdır ve bu sınır büyüdükçe hesaplama maliyeti de orantısız şekilde artar. Pratik geliştirme sürecinde context window’u tek başına büyütmeye çalışmak yerine, chunking, RAG ve özetleme gibi tekniklerle bağlamı akıllıca yönetmek, hem daha tutarlı yanıtlar hem de daha öngörülebilir maliyetler sağlar. Yeni bir entegrasyona başlarken önce hangi tür bağlamın (statik doküman mı, değişken sohbet geçmişi mi, araç çıktısı mı) hangi sıklıkla değiştiğini haritalamak, doğru stratejiyi (özetleme, RAG, kayan pencere veya bunların bir kombinasyonu) seçmeyi kolaylaştırır.

Sık Sorulan Sorular

1) Context window nedir, kısaca nasıl tanımlanır?
Bir yapay zeka modelinin tek bir istekte işleyebildiği maksimum token miktarıdır; bu miktarın üzerindeki metin modele sığmaz.

2) Context window ile token limiti aynı şey mi?
Evet, birbirine çok yakın kavramlardır; context window genellikle token cinsinden ifade edilen üst sınırı tanımlar.

3) Büyük context window her zaman daha iyi sonuç mu verir?
Hayır. “Lost in the middle” etkisi nedeniyle çok uzun bağlamlarda ortadaki bilgi daha zayıf hatırlanabilir; büyük pencere yalnızca üst sınırı gösterir, doğruluğu garanti etmez.

4) Context window sınırını aşarsam ne olur?
İstek genellikle hata döner (context length exceeded) veya bazı arayüzlerde en eski içerik otomatik olarak kırpılır.

5) RAG, context window sorununu nasıl çözer?
Tüm dokümanı göndermek yerine sorguyla en alakalı parçaları bir vektör aramasından çekip yalnızca onları modele iletir; bu hem maliyeti düşürür hem de pencereyi verimli kullanır.

6) Türkçe metinlerde token sayısı İngilizceye göre neden daha fazla çıkabilir?
Türkçe eklemeli bir dil olduğu için bazı kelimeler birden fazla token’a bölünebilir; bu da aynı anlam için İngilizceye kıyasla daha fazla token harcanmasına yol açabilir. Bu farkı gözlemlemenin en kolay yolu, aynı cümleyi Türkçe ve İngilizce olarak bir tokenizer’dan geçirip çıkan token sayılarını karşılaştırmaktır; birçok geliştirici bu farkı fark etmediği için Türkçe içerik üreten uygulamalarda beklenenden erken context window sınırına ulaşabilir.

Tokenizer örneğindeki gpt-4 yalnızca o model ailesi için bir örnektir. Başka model sağlayıcılarına aynı encoding’i uygulamayın; bilinmeyen model adında sessiz tahmin yerine desteklenen tokenizer ve API kullanım verisini kontrol edin.

Teknik kaynak: Lost in the Middle — Araştırma.