Uzun Doküman Analizi: Hangi AI Asistanı Daha İyi Okur?

Uzun doküman analizinde en çok konuşulan rakam, sonucu en az belirleyen rakam: bağlam penceresi. "1 milyon token okuyor" cümlesi bir teknik özellik gibi sunuluyor ama 300 sayfalık bir ihale şartnamesini masaya koyduğunuzda üç ayrı sınırla karşılaşıyorsunuz. Modelin teorik penceresi, kullandığınız uygulamanın dosya limiti ve modelin o pencerenin ne kadarını gerçekten "anlayarak" kullandığı. Bu üçü aynı şey değil; bu yazının derdi de bu.

Yazının sonunda elinizde şu olacak: bağlam penceresi (context window) kavramının sayfa cinsinden karşılığı, Türkçe belgelerin neden İngilizce belgelerden daha "pahalı" olduğu, testlerin uzun belge okuma konusunda neyi ölçüp neyi ölçmediği, hangi durumda hangi asistanı seçeceğiniz ve uzun bağlam ile RAG arasındaki maliyet farkı. Bu yazı, işletmeler için AI araçları rehberimizin araç seçimi bölümünü uzun belge özelinde derinleştiriyor.

Bağlam penceresi nedir ve kaç sayfa belge eder?

Bağlam penceresi, bir yapay zeka asistanının tek seferde "görebildiği" metin miktarıdır ve token adı verilen parçalarla ölçülür. Sorunuz, yüklediğiniz belge, önceki mesajlar ve modelin cevabı aynı pencereye sığmak zorundadır. Pencere dolunca model belgenin bir kısmını görmez ya da en baştaki mesajları düşürür. Sayfa karşılığı ise dile göre ciddi biçimde değişir.

Token, kelimeden küçük bir birim. İngilizce'de bir token kabaca dört harfe, yani bir kelimenin dörtte üçüne denk gelir. Türkçe'de iş değişiyor. Türkçe eklemeli bir dil: "gönderilmeyecektir" gibi tek bir kelime, İngilizce ağırlıklı eğitilmiş bir tokenizer'ın (metni parçalara ayıran bileşen) sözlüğünde bütün hâlde yok; kelime beş altı parçaya bölünüyor. Türkiye merkezli bir güvenlik firmasının araştırması aynı içerik için Türkçe'nin yaklaşık iki kat token ürettiğini söylüyor; tek kaynağa dayanan bir oran ama sahada gördüğümüzle uyumlu.

Pratik hesap için şu bant işinizi görür: 50 sayfalık Türkçe bir belge kabaca 35-40 bin token. Buradan yürürseniz 200 bin tokenlık bir pencere yaklaşık 250-280 sayfa Türkçe belge alır, 1 milyon tokenlık pencere ise 1.200 sayfanın üzerine çıkar. Bu rakamların hepsi yazı tipi, tablo yoğunluğu ve tarama kalitesine göre oynar; taranmış, görüntü ağırlıklı PDF'lerde ek maliyet de var. Ama karar için "sayfa sayısını 750'ye böl, çıkan sayı bin token cinsinden kabaca ihtiyacınız" formülü yeterince yakın sonuç veriyor.

1 milyon token pencere gerçekten 1 milyon token okur mu?

Hayır, en azından ilan edilen kapasitede değil. Modeller pencerenin sonuna yaklaştıkça özellikle ortadaki bilgiyi kaçırmaya başlıyor; araştırmacılar buna "ortada kaybolma" (lost in the middle) diyor. İlan edilen pencere ile modelin güvenilir çalıştığı "etkin pencere" arasındaki fark, uzun doküman analizinde asıl bakmanız gereken şey. Ne yazık ki bu fark ürün sayfalarında yazmıyor.

Sektörün en çok gösterdiği test "samanlıkta iğne" (needle in a haystack): uzun bir metnin içine alakasız tek bir cümle gömülüyor, model onu bulabiliyor mu diye bakılıyor. Güncel modellerin çoğu bu testi neredeyse kusursuz geçiyor. Sorun şu ki bu test bir cümleyi bulmayı ölçüyor, belgeyi anlamayı değil. Bir sözleşmede "cezai şart" maddesini bulmak ile o maddenin 40 sayfa sonraki "mücbir sebep" maddesiyle nasıl çeliştiğini fark etmek aynı beceri değil.

Daha sert testler bu yüzden tasarlandı. RULER, tek iğne yerine birbirine benzeyen çeldirici iğneler, aynı anahtara bağlı birden fazla değer ve çoklu sorgu gibi 13 görevi 4 binden 128 bin tokena kadar uzanan uzunluklarda ölçüyor. BABILong'un yazarları "uzun bağlamlı modellerin çoğunun tam bağlamını kullanamadığının zaten gösterildiğini" not düşüyor. Epoch AI'ın Fiction.LiveBench'i ise uzun anlatılar üzerinden anlama sorusu soruyor ve iğne testini geçen modellerin burada belirgin biçimde zorlandığını raporluyor.

Hangi modelin kaç tokenda ne kadar düştüğünü tek bir sayıyla söylemek dürüst olmaz; bu tablolar her sürümde değişiyor ve araştırmamızda model bazlı güvenilir bir düşüş yüzdesi bulamadık. Kural olarak şunu tutun: ilan edilen pencerenin son üçte birine güvenmeyin.

Uygulamanın dosya limiti ile modelin penceresi neden aynı şey değil?

Modelin API'deki bağlam penceresi ile tarayıcıdan kullandığınız ChatGPT, Claude veya Gemini uygulamasının size verdiği limit iki ayrı sayıdır. Uygulamalar dosya boyutu, sayfa sayısı, dosya adedi ve plan bazlı pencere sınırı koyar; bunlar çoğu zaman modelin teorik kapasitesinin altında kalır. 300 sayfalık belgeniz modele sığsa bile uygulama onu içeri almayabilir.

Eylül 2026 itibarıyla ikincil karşılaştırma sayfalarının tutarlı biçimde aktardığı limitler şöyle (resmî yardım sayfalarını yüklemeden önce bir kez daha kontrol edin, bu sayılar birkaç ayda bir değişiyor):

• ChatGPT: dosya başına 512 MB üst sınır; ücretsiz planda günde birkaç yükleme, ücretli planlarda üç saatte 80 dosya. Bağlam penceresi ise plana göre değişiyor ve ücretsiz planda modelin API penceresinin çok altında kalıyor.
• Claude: sohbet başına 20 dosya, PDF'lerde 32 MB ve 100 sayfa sınırı. Bu, 300 sayfalık şartnameyi tek parça yükleyemeyeceğiniz anlamına geliyor; bölmeniz gerekiyor.
• Gemini: dosya başına 100 MB; ücretsiz planda istek başına 10 dosya.
• NotebookLM: kaynak başına 500 bin kelime ya da 200 MB, hangisi önce dolarsa; sayfa sınırı yok. Uzun tek belge için en rahat kapı bu. Nerede tıkandığını NotebookLM'in şirket dokümanlarında kullanımı yazısında anlattık.

Buradan çıkan pratik sonuç: "hangi model daha büyük pencereye sahip" sorusundan önce "hangi uygulama belgemi bölmeden kabul ediyor" sorusunu sormalısınız. Çünkü belgeyi ikiye böldüğünüz anda modelin çapraz referans kurma yeteneğini de ikiye bölmüş oluyorsunuz.

Uzun dokümanı hangi asistan daha iyi okur?

Tek bir kazanan yok; ama belirgin bir desen var. Büyük pencereli modeller (Gemini'nin Pro sürümleri, Claude'un ve GPT'nin 1 milyon tokena çıkan yeni nesilleri) tek belge üzerinde derin okuma isteyen işlerde öne çıkıyor. Belgeyi bölmek zorunda kaldığınız uygulamalarda ise modelin kalitesinden çok sizin bölme stratejiniz sonucu belirliyor. Ölçmeden karar vermeyin; ölçmek 20 dakika sürüyor.

Kendi projelerimizde uzun belge testi için beş soruluk basit bir protokol kullanıyoruz ve aynısını size öneriyoruz. Birinci soru belgenin ilk 10 sayfasından, ikincisi tam ortasından, üçüncüsü son 10 sayfasından cevaplanabilecek somut bir bilgi ister ("teminat oranı yüzde kaç?", "teslim süresi kaç gün?"). Dördüncü soru olarak iki uzak maddeyi çapraz bağlamasını istersiniz: "gecikme cezası ile mücbir sebep maddesi birlikte okununca fırtına kaynaklı gecikmede ceza işler mi?" Beşinci soru tuzaktır: belgede olmayan bir şeyi sorarsınız ve modelin "belgede bu bilgi yok" diyebilip diyemediğine bakarsınız.

Sahada gördüğümüz tablo şu: iyi modellerin neredeyse tamamı ilk üç soruyu geçiyor. Ayrışma dördüncü ve beşinci soruda başlıyor. Çapraz referans sorusunda belgeyi tek parça alan modeller belirgin biçimde daha iyi; bölünmüş belgede aynı model bile ikinci parçadaki maddeyi "görmediği" için yanlış cevap verebiliyor. Tuzak soruda ise fark model ailesine göre değişiyor ve her yeni sürümde yeniden test etmek gerekiyor. Üç büyük asistanın genel karşılaştırmasını ChatGPT, Gemini ve Claude'u Türkçe iş senaryolarında karşılaştırdığımız yazıda bulabilirsiniz; uzun belge orada tek bir senaryoydu, burada ana konu.

Uzun bağlam mı RAG mı? Maliyet nerede ayrışıyor?

Karar kuralı kısa: tek bir belge ya da birkaç belge üzerinde derin okuma ve akıl yürütme istiyorsanız uzun bağlam; yüzlerce belgeden oluşan bir arşive tekrar tekrar soru soracaksanız RAG (retrieval augmented generation, yani sorudan önce ilgili parçaları bulup modele veren mimari). Maliyet farkı sorgu başına 100 katı aşabiliyor. Sınır belirsizse, önce uzun bağlamla prototip yapın; ölçek gelince RAG'e geçin.

Rakamları bant olarak vermek daha dürüst. Uzun bağlamlı 1 milyon tokenlık tek bir API isteği, seçtiğiniz modele göre 5-15 dolar arasında; en ucuz açık kaynak türevlerinde bunun onda birinin de altına inebiliyor. Aynı soruyu RAG ile sorduğunuzda model yalnızca bulunan birkaç parçayı okuduğu için sorgu başına maliyet birkaç sentin altında kalıyor. Bu hesabı yapan bağımsız bir teknik yazı, günde 10 bin sorguluk bir yükte iki yaklaşım arasında binlerce dolarlık günlük fark çıkarıyor; kendi varsayımlarına dayalı bir hesap ama büyüklük sırası doğru.

İki ayrıntı fiyat listesinde küçük yazıyla duruyor. Birincisi, bazı sağlayıcılar (araştırmamızda Gemini'nin Pro modeli ve Grok bu grupta) 200 bin token eşiğinin üstündeki isteklerde birim fiyatı ikiye katlıyor; Claude'un yeni nesil modelleri ise tam pencereyi tek fiyattan veriyor. İkincisi, "önbellekleme" (prompt caching) aynı belgeye art arda soru sorduğunuzda girdi maliyetini birkaç kat düşürüyor, ama her seferinde taze bir belge yüklüyorsanız hiçbir işe yaramıyor. Bir KOBİ'nin "her sözleşmeyi bir kez okut" senaryosu tam da bu ikinci durum. RAG'in kurulum maliyetini ve ne zaman gerektiğini RAG'i patron diliyle anlattığımız yazıda bulabilirsiniz.

Somut senaryo: 380 sayfalık ihale şartnamesi

Ankara'da 25 kişilik bir inşaat taahhüt firması, kamu ihalesi için 380 sayfalık teknik şartname ve 40 sayfalık sözleşme taslağı alıyor. Amaç: teklif hazırlayan mühendisin iki günde okuduğunu iki saatte taramak, riskli maddeleri işaretlemek ve teklif ekibine bir özet çıkarmak. Bu iş hangi araçla, kaça ve nasıl yapılır?

Önce hesap. 420 sayfa Türkçe belge, yukarıdaki bantla kabaca 300-340 bin token eder. Bu, 200 bin tokenlık pencereye sığmaz; 1 milyonluk pencereye rahat sığar. Tüketici uygulamaları tarafında Claude uygulamasının 100 sayfalık PDF sınırı belgeyi dörde bölmeyi gerektirir, NotebookLM ise tek kaynak olarak kabul eder. API tarafında büyük pencereli bir modelle belgeyi tek parça göndermek mümkün.

Sonra maliyet. Belgenin tamamını tek parça okuyan bir API isteği, orta fiyat kademesindeki bir modelde girdi için yaklaşık 1-2 dolar, çıktıyla birlikte 2-3 dolar bandında kalır. Teklif ekibi aynı belgeye 20 soru soracaksa ve önbellekleme kullanılmıyorsa bu 40-60 dolara çıkar; önbellekleme ile aynı 20 soru 10-15 dolar bandına iner. Bir mühendisin iki günlük maaşıyla kıyaslanınca hesap açık. Ama "ayda 30 ihale, her biri 20 soru" ölçeğine gelindiğinde aylık fatura yüzlerce dolara tırmanır ve o noktada belgeleri bir kez parçalayıp indeksleyen RAG mimarisi hem ucuz hem tutarlı hâle gelir.

Bu senaryoda önerimiz kademeli: ilk üç ay NotebookLM ya da büyük pencereli bir API modeliyle tek belge çalışması, beş soruluk protokolle her ay bir doğruluk kontrolü, hacim büyüyünce RAG. Kritik uyarı da burada: ihale şartnamesini herkese açık bir tüketici hesabına yüklemeden önce o planın "verilerinizi eğitimde kullanmama" ayarını kontrol edin. Kurumsal planların çoğunda bu varsayılan, bireysel planların bir kısmında değil.

Sık sorulan sorular

300 sayfalık belgeyi ChatGPT'ye atsam okur mu?

Dosya boyutu olarak evet, ama bağlam penceresi plana göre değişiyor; ücretsiz planda belgenin büyük kısmı pencereye sığmayabilir ve model sessizce sonunu okumadan cevap verebilir. Kontrol yöntemi basit: son sayfadaki bir bilgiyi sorun. Cevap yanlışsa belge tam okunmamıştır.

1 milyon token kaç sayfa Türkçe belge?

Kaba hesapla 1.200-1.400 sayfa. İngilizce'de aynı pencere neredeyse iki katına, 2.500 sayfa civarına çıkar. Tablo yoğun ve taranmış belgelerde bu sayı düşer.

Bağlam penceresi büyükse her şeyi hatırlar mı?

Hayır. Uzun bağlam testleri modellerin pencerenin tamamını aynı dikkatle kullanamadığını gösteriyor; ortadaki bilgi kaybolmaya en yatkın olan. Kritik maddeleri sorarken sayfa numarası vermek isabeti belirgin biçimde artırıyor.

Türkçe belge okutmak İngilizce'den daha mı pahalı?

Evet, yaklaşık iki kat. Aynı içerik daha fazla tokena bölündüğü için hem daha fazla pencere harcar hem de API'de daha yüksek fatura üretir. Belgenin İngilizce çevirisi varsa ve iş izin veriyorsa onu okutmak daha ucuz olabilir; ama hukuki metinlerde çeviriye güvenmeyin.

Uzun bağlam mı RAG mı, nasıl seçeceğim?

Belge sayısı ve sorgu sıklığına bakın. Birkaç belge, derin okuma, ara sıra soru: uzun bağlam. Yüzlerce belge, tekrar eden sorular, birden fazla kullanıcı: RAG. İkisi arasındaysanız uzun bağlamla başlayın, hacim sizi zorlayınca geçin.

Aynı belgeye 20 soru soracağım, her seferinde tam ücret mi öderim?

API'de önbellekleme kullanırsanız hayır; girdi maliyeti birkaç kat düşer. Tüketici uygulamalarında ise bu sizin adınıza yönetiliyor, ödediğiniz abonelik dışında ek ücret çıkmıyor ama kullanım kotasına takılabilirsiniz.

Peki siz ne yapmalısınız?

• Sayfa sayınızı tokena çevirin. Türkçe belgede sayfa sayısını 750'ye bölün; çıkan sayı bin token cinsinden ihtiyacınız. 200 bin tokenı aşıyorsa bölmeden yükleyebileceğiniz bir araç ya da büyük pencereli model seçin.
• Uygulama limitlerini modelden ayrı kontrol edin. Yüklemeden önce sayfa, MB ve dosya adedi sınırlarına bakın; belgeyi bölmek zorunda kalıyorsanız çapraz referans sorularının kalitesi düşecek, buna göre plan yapın.
• Beş soruluk testi çalıştırın. Baş, orta, son, çapraz referans ve tuzak. 20 dakika sürer; hangi aracın sizin belgelerinizde güvenilir olduğunu bu testten öğrenirsiniz, ürün sayfasındaki rakamdan öğrenemezsiniz.
• Maliyeti sorgu sayısıyla çarpın. Belge başına bir okuma ucuz görünür; aylık belge sayısı ve soru sayısıyla çarpınca RAG'in ne zaman ucuzladığını görürsünüz.
• Gizlilik ayarını en başta kapatın. Sözleşme ve şartname yüklemeden önce planınızın eğitim verisi politikasını okuyun; kurumsal plan ya da API kullanımı bu riski büyük ölçüde kaldırır.

Bağlam penceresi, uzun belge işinde önemli ama tek başına karar verdiren bir sayı değil. Uygulama limiti, etkin pencere, dilin token maliyeti ve sorgu hacmi birlikte bakıldığında doğru araç kendiliğinden ortaya çıkıyor. Beş soruluk protokolü kendi belgelerinizde çalıştırıp sonuçları yorumlamakta zorlanırsanız, hangi aracın hangi belge tipinde daha iyi çalıştığına dair kendi test tablolarımızı paylaşabiliriz.