Context Window (Bağlam Penceresi) Nedir?

Context window nedir? Context window (Türkçesiyle bağlam penceresi), bir dil modelinin tek seferde işleyebileceği ve yanıt üretirken dikkate alabileceği metnin token cinsinden azami uzunluğudur. Bu pencereye hem kullanıcının girdiği prompt hem de modelin ürettiği yanıt birlikte sığmak zorundadır.

Bir dil modelini, önündeki masaya yalnızca belli sayıda sayfa sığdırabilen bir okuyucu gibi düşünün: masaya sığan her şeyi aynı anda görür, ama masa dolunca yeni sayfa koymak için eskisini kaldırmak zorunda kalır. İşte o masanın boyutu context window'dur. Bu rehber context window nedir, nasıl çalışır, token limiti ile ilişkisi nedir, uzun bağlam neyi değiştirir ve kurumsal senaryolarda rag ihtiyacı ile bellek yönetiminin neden devreye girdiğini ele alıyor.

Tanım

Context Window (Bağlam Penceresi)

Bir dil modelinin tek seferde işleyebileceği ve yanıt üretirken dikkate alabileceği metnin token cinsinden azami uzunluğu. Hem kullanıcının girdiği prompt hem de modelin ürettiği yanıt bu pencereye sığmak zorundadır; pencere dolduğunda en eski içerik dışarıda kalır ve model onu unutur.

Ayrıca: Bağlam penceresi, context length, bağlam uzunluğu, token penceresi

Context window, bir dil modelinin "aynı anda ne kadarını görebildiğini" belirleyen temel sınırdır. Model, yalnızca bu pencerenin içindeki metne bakarak yanıt üretir; pencerenin dışında kalan hiçbir şeyi hesaba katamaz. Bu yüzden pencere boyutu, modelin ne kadar uzun bir belgeyi özetleyebileceğini, kaç sayfalık bir sözleşmeyi tek seferde okuyabileceğini ve bir sohbetin ne kadar geçmişini hatırlayabileceğini doğrudan tayin eder.

Pratikte bu sınır her gün karşımıza çıkar. Uzun bir sohbette modelin başta konuştuğunuz şeyi "unutması", büyük bir dosyayı yapıştırdığınızda "metin çok uzun" uyarısı almanız ya da bir belgeyi analiz ederken sonucun eksik kalması — hepsinin kökeninde context window sınırı vardır. Bu kavramı anlamak, modelle çalışırken karşılaşılan pek çok sınırı önceden görmeyi sağlar. Temeli için token nedir ve LLM nedir rehberleri iyi bir başlangıçtır.

Model bir istek aldığında, o isteğe kadar biriken tüm metin — sistem talimatı, önceki mesajlar, sizin yeni sorunuz ve getirilen belgeler — tek bir dizi hâlinde birleştirilip token'lara bölünür. Model bu token dizisini bütün olarak işler ve bir sonraki token'ı tahmin ederek yanıtı üretir. Ürettiği yanıt da aynı pencerenin içine yazılır; yani girdi ve çıktı aynı bütçeyi paylaşır.

Kritik nokta şudur: model bir "hafızaya" değil, bu pencereye bakar. İki mesaj arasında kalıcı bir bellek tutmaz; her istekte pencereye sığdırılan metin, modelin o an bildiği her şeydir. Sohbet arayüzlerinin geçmişi "hatırlıyor" gibi görünmesinin nedeni, arka planda önceki mesajların her seferde yeniden pencereye eklenmesidir. Pencere kapasitesi dolduğunda ise bu ekleme artık mümkün olmaz.

Nasıl Yapılır

Bir isteğin context window içinde işlenmesi

Kullanıcının mesajından modelin yanıtına kadar metnin pencere içinde izlediği temel adımlar.

1. 1

   Metni birleştir

   Sistem talimatı, önceki mesajlar, yeni soru ve getirilen belgeler tek bir dizi hâlinde birleştirilir.

2. 2

   Token'lara böl

   Birleştirilen metin tokenizer ile token'lara ayrılır ve toplam token sayısı hesaplanır.

3. 3

   Pencereye sığdır

   Toplam token sayısı limitin altındaysa metin olduğu gibi işlenir; aşıyorsa en eski içerik dışarıda bırakılır.

4. 4

   Yanıtı üret

   Model penceredeki token'lara dayanarak yanıtı üretir; üretilen yanıt da aynı pencerenin bütçesinden harcanır.

Context window boyutu her zaman token cinsinden ölçülür — kelime ya da karakter cinsinden değil. Buna genellikle token limiti denir. Token, bir kelimeden küçük metin parçasıdır: bazen bir kelimenin tamamı, bazen bir hece veya ek. Modelin gördüğü her şey önce token'lara çevrildiği için, pencerenin "128 bin token" gibi bir kapasitesi vardır ve bu sayı prompt ile yanıtın toplamını kapsar.

Türkçe konuşan kullanıcılar için burada önemli bir ayrıntı vardır. Tokenizer'lar ağırlıklı olarak İngilizce metinle eğitildiğinden, Türkçe kelimeler genellikle daha çok parçaya bölünür. Sonuç olarak aynı anlamı taşıyan bir Türkçe metin, İngilizce karşılığından daha çok token tüketir ve pencereyi daha hızlı doldurur. Bu yüzden aynı token limiti, Türkçe içerikte pratikte daha az "kelime" anlamına gelir. Token kavramının ayrıntısı için token nedir rehberine bakabilirsiniz.

Son yıllarda modellerin pencere boyutu belirgin biçimde büyüdü; birkaç bin token'dan yüz binlerce token'a çıkan uzun bağlam pencereleri artık yaygın. Uzun bağlam, tek bir istekte çok daha fazla belgeyi işlemeyi mümkün kılar: onlarca sayfalık bir raporu, uzun bir kod tabanını veya kapsamlı bir sohbet geçmişini tek seferde modele verebilirsiniz. Bu, birçok senaryoda belgeyi parçalama ihtiyacını azaltır.

Ancak uzun bağlam bedelsiz değildir. Birincisi, daha çok token işlemek maliyeti ve gecikmeyi artırır — büyük pencereyi doldurmak hem daha pahalı hem daha yavaştır. İkincisi, "ortada kaybolma" (lost in the middle) olgusu vardır: modeller pencerenin başındaki ve sonundaki bilgiye, ortasındakinden daha iyi dikkat eder; uzun pencerenin ortasına konan kritik bir detay göz ardı edilebilir. Bu yüzden "her şeyi pencereye doldur" yaklaşımı, çoğu zaman doğru bilgiyi doğru yere koymaktan daha zayıf sonuç verir.

Kurumlarda sık sorulan bir soru şudur: "Pencere zaten çok büyük; tüm belgelerimizi doğrudan içine koysak yetmez mi?" Cevap çoğunlukla hayırdır. Büyük pencere ile RAG (getirmeyle güçlendirilmiş üretim) farklı problemleri çözer; ikisini karşılaştırmak, hangi durumda hangisinin daha sürdürülebilir olduğunu netleştirir.

Büyük context window ile RAG yaklaşımının karşılaştırması

Boyut	Büyük context window	RAG
Bilgi kapasitesi	Pencere boyutuyla sınırlı	Pratikte sınırsız belge
Maliyet	Her istekte tüm metin işlenir, pahalı	Yalnızca ilgili parçalar işlenir, ekonomik
Güncelleme	Bilgi her seferinde elle eklenir	Kaynak güncellenince otomatik yansır
Doğruluk	Ortadaki bilgi göz ardı edilebilir	İlgili parça öne getirilir, kaynak gösterilir

Pratik kural nettir: geçici, tek seferlik bir görev için (örneğin uzun bir belgeyi tek seferde özetlemek) büyük pencere idealdir. Kalıcı, sürekli güncellenen ve büyük bir bilgi tabanına dayanan senaryolarda ise rag ihtiyacı ortaya çıkar; RAG hem daha ekonomik hem de kaynak göstererek daha güvenilirdir. Bu ikisinin ayrıntılı ayrımı için RAG nedir rehberine ve kurumsal kurulum için kurumsal RAG sistemleri çözümüne göz atabilirsiniz.

Context window sonlu olduğu için, uzun etkileşimlerde er ya da geç dolar. Pencere dolduğunda en eski içerik dışarıda kalır ve model onu artık göremez — bir sohbet asistanının "başta ne konuştuğumuzu hatırlamıyor" hâlinin teknik nedeni tam olarak budur. Bu, bir arıza değil, pencerenin doğal sınırıdır; çözüm, pencereyi akıllıca yönetmektir. Buna bellek yönetimi denir.

Bellek yönetiminin başlıca yöntemleri şunlardır:

• Özetleme: Eski mesajlar kısa bir özete indirgenir; ayrıntı yerine öz korunur, böylece pencerede yer açılır.
• Seçici getirme: İhtiyaç anında yalnızca ilgili geçmiş parçalar RAG ile pencereye geri getirilir; her şey sürekli pencerede tutulmaz.
• Harici bellek: Kalıcı bilgi (kullanıcı tercihleri, önceki kararlar) pencere dışında bir depoda tutulur ve gerektiğinde çağrılır.

Bu yaklaşımların ortak fikri şudur: pencereyi her şeyle doldurmak yerine, her an yalnızca en ilgili bilgiyi pencerede tutmak. İyi bir bellek yönetimi, sınırlı bir pencereyle bile uzun ve tutarlı etkileşimleri mümkün kılar. Agent tabanlı sistemlerde bu mesele daha da kritiktir; ayrıntı için AI agent nedir ve agentic AI nedir rehberlerine bakabilirsiniz.

Context window etrafında en sık yapılan hataların başında "büyük pencere her sorunu çözer" varsayımı gelir. Oysa büyük pencere maliyeti ve gecikmeyi artırır, ortadaki bilgiyi göz ardı edebilir ve kalıcı hafıza sorununu çözmez. İkinci yaygın hata, pencereyi kelime cinsinden düşünmektir; oysa ölçü token'dır ve özellikle Türkçede token/kelime oranı beklenenden yüksektir.

Üçüncü hata, sohbet asistanlarının kalıcı bir hafızası olduğunu sanmaktır. Model iki istek arasında hiçbir şey saklamaz; "hatırlıyor" görünmesi, geçmişin her seferde yeniden pencereye eklenmesindendir. Bu sınırları bilmek, hem daha isabetli prompt yazmayı hem de mimarî kararları (büyük pencere mi, RAG mı, bellek yönetimi mi) doğru vermeyi sağlar. Prompt tarafını güçlendirmek için prompt engineering nedir rehberi yardımcı olur.

Context window ile token limiti aynı şey mi?

Neredeyse aynı kavramı ifade ederler. Context window pencerenin kendisidir; token limiti ise bu pencerenin token cinsinden büyüklüğüdür. Örneğin 128 bin token limitli bir model, prompt ve yanıt toplamı 128 bin token'a kadar olan içeriği tek seferde işleyebilir.

Model neden sohbetin başını unutuyor?

Çünkü konuşma uzadıkça toplam token sayısı context window'u aşar. Pencere dolunca en eski mesajlar dışarıda kalır ve model artık onları göremez. Bu bir hafıza arızası değil, pencerenin fiziksel sınırıdır; kalıcı hafıza için ayrı bir bellek yönetimi katmanı gerekir.

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

Hayır. Büyük pencere daha çok belgeyi tek seferde işlemeyi sağlar ama maliyeti ve gecikmeyi artırır. Ayrıca pencere ortasındaki bilgi göz ardı edilebilir. Çoğu kurumsal senaryoda büyük pencere yerine iyi kurulmuş bir RAG daha doğru sonuç verir.

Türkçe metin context window'da neden daha çok yer kaplar?

Çünkü tokenizer'lar çoğunlukla İngilizce ağırlıklı eğitildiğinden Türkçe kelimeler daha fazla parçaya bölünür. Aynı anlamı taşıyan bir Türkçe metin, İngilizce karşılığından genellikle daha çok token tüketir; bu da pencerenin daha hızlı dolması demektir.

Context window dolduğunda ne yapmalı?

Birkaç yol vardır: eski mesajları özetleyip kısaltmak, yalnızca ilgili kısımları RAG ile getirmek veya kalıcı bilgiyi harici bir bellek yönetimi katmanında tutmak. Amaç, pencereye her şeyi doldurmak değil, doğru anda doğru bilgiyi pencereye koymaktır.

Özetle context window nedir sorusunun cevabı şudur: bir dil modelinin tek seferde işleyebileceği ve yanıt üretirken dikkate alabileceği metnin token cinsinden azami uzunluğu. Prompt ve yanıt birlikte bu token limitine sığmak zorundadır; pencere dolduğunda en eski içerik unutulur. Uzun bağlam pencereleri daha çok belgeyi işlemeyi sağlar ama maliyeti artırır ve kalıcı hafıza sorununu çözmez; bu yüzden kurumsal senaryolarda rag ihtiyacı ve bellek yönetimi çoğu zaman daha sürdürülebilirdir. Temel için token nedir ve prompt nedir rehberlerine göz atabilir, kurumsal bir kurulum için yapay zeka danışmanlığı ile başlayabilirsiniz.