- En yeni LLM’lerin girdi token sınırı (context window) milyonlarca düzeye kadar genişlemiş olsa da, basit arama benchmark’larında (Needle in a Haystack, NIAH) yüksek puan almak gerçek uzun girdilerde performans düşüşünün açıkça var olduğu gerçeğini ortadan kaldırmıyor
- Araştırmacılar 18 model üzerinde çeşitli deneyler yürüttü ve yalnızca girdi uzunluğu kontrol edildiğinde bile performans düşüşü ve tutarsız örüntülerin tekrar tekrar ortaya çıktığını doğruladı
- Soru-cevap benzerliğinin düşmesi, dikkat dağıtıcı cümlelerin (distractor) eklenmesi, metin yapısındaki değişimler gibi etkenlerle performans düşüşü hızlanabiliyor ya da öngörülemez biçimde değişebiliyor
- Yapısal bağlamın (mantıksal paragraf akışı) korunması bile performansı olumsuz etkileyebiliyor; yani girdinin sıralanışı ve sunuluş biçimi LLM performansını ciddi biçimde etkiliyor
- Basit tekrar metni kopyalama gibi çok kolay görevlerde bile girdi uzadıkça tutarlı sonuç üretilemediği görülüyor; bu da gerçek uygulamalarda bağlam tasarımının (context engineering) önemini öne çıkarıyor
Araştırmanın arka planı ve amacı
- Son dönemde LLM’lerin context window’u 1 milyon ile 10 milyon token’a kadar çıktıkça, uzun girdilerde de “performansın garanti olduğu” algısı yaygınlaştı
- Gemini 1.5 Pro, GPT-4.1, Llama 4 bunun öne çıkan örnekleri
- Temel benchmark’lardan biri olan Needle in a Haystack (NIAH) yalnızca basit cümle aramaya dayandığı için, gerçek dünyadaki uzun belge özetleme ve soru-cevap gibi daha bileşik görevlerdeki performans düşüşünü yeterince yansıtmıyor
- Bu çalışma, yalnızca girdi uzunluğunu değiştirip görev zorluğunu sabit tutarak performans değişimini sistematik biçimde inceliyor
Başlıca deneyler ve sonuçlar
- 18 güncel LLM (Anthropic Claude, OpenAI GPT-4.1/4o/3.5, Gemini, Qwen vb.) üzerinde toplam 4 deney tasarımı uygulandı:
- Soru-cevap (Needle-Question) anlamsal benzerliğinin değiştirilmesi
- Dikkat dağıtıcı cümlelerin (distractor) eklenmesi
- Metin gövdesinin (haystack) konu/yapı bakımından değiştirilmesi
- Tekrarlanan kelime kopyalama (çıktı uzunluğu ile girdi uzunluğunun birlikte büyütülmesi)
- Tüm deneylerde girdi uzunluğu arttıkça performansın keskin biçimde düştüğü görüldü; özellikle anlamsal benzerlik azaldığında veya dikkat dağıtıcı öğe sayısı arttığında düşüş daha da büyüdü
- Soru-cevap benzerliği düştükçe, uzun girdilerde yanlış cevap oranı hızla yükseliyor
- Yalnızca bir dikkat dağıtıcı cümle eklendiğinde bile doğruluk hemen düşüyor; 4 veya daha fazla eklendiğinde ise modele göre karışıklık ve halüsinasyon belirgin biçimde artıyor
- Örnek: Claude ailesi yanlış cevap vermek yerine daha çok “doğru cevap bulunamadı” diyerek kaçınma eğilimi gösterirken, GPT ailesi daha fazla kendinden emin yanlış cevap üretiyor
- Metin yapısına (mantıksal akış/rastgele sıralama) göre performansın tersine döndüğü ilginç bir durum da gözlendi
- Mantıksal akışı koruyan özgün (Original) metinlerde model performansı daha kötü olabiliyor
- Cümlelerin rastgele karıştırıldığı (Shuffled) metinlerde ise arama performansı daha yüksek çıkabiliyor
- Tekrarlanan kelime kopyalama deneyinde de girdi ve çıktı token’ları arttıkça yanlış cevap, görevi reddetme ve rastgele kelime üretme gibi öngörülemez örüntüler arttı
- Örnek: 2.500~5.000 kelimeden sonra bazı modellerde kopyalamayı reddetme veya rastgele metin üretme gibi anormal sonuçlar hızla artıyor
LongMemEval: pratik odaklı uzun diyalog değerlendirmesi
- Gerçek konuşma kayıtlarını içeren LongMemEval benchmark’ında odaklanmış girdi (yalnızca doğru cevapla ilgili kısımlar) ile tam girdi (cevapla ilgisiz bağlamın da dahil edilmesi) karşılaştırıldı
- Tüm modellerde odaklanmış girdi çok daha yüksek doğruluk sağladı; tam girdide ise ilgili bilgiyi bulma işi ek bir görev hâline gelerek performansı ciddi biçimde düşürdü
- Claude ailesi modeller özellikle belirsiz durumlarda “cevap yok” diyerek kaçınma eğilimini daha belirgin gösterdi
Ek analizler ve çıkarımlar
- Dikkat dağıtıcı cümle bazında karışma oranı, yanıt konumu doğruluğu, rastgele kelime üretiminin konumu gibi modele özgü iç davranış örüntüleri çeşitli grafiklerle ayrıntılı biçimde analiz edildi
- Tekrarlanan kelime kopyalama deneyinde, doğru kelime ne kadar başta yer alırsa doğruluğun da o kadar yüksek olduğu gibi konuma bağımlı özellikler görüldü
- Bağlam tasarımının (bilgi sıralaması, mantıksal akışın yönetimi vb.) model performansı üzerindeki etkisi çok büyük olduğundan, gerçek hizmetlerde yalnızca context window’u büyütmenin tutarlı performans sağlamaya yetmeyeceği anlaşılıyor
Sonuç
- LLM’lerin uzun metin girdilerini işleme yeteneği benchmark puanlarıyla garanti edilemez; yalnızca gerçek girdi uzunluğunun artması bile tutarsız performans düşüşlerine yol açabiliyor
- İlgili bilginin sadece metne dahil edilmesi yeterli değil; bilginin sıralanışı, yapısı, dikkat dağıtıcı öğeler ve benzerlik düzeyi performansı belirleyici biçimde etkiliyor
- LLM kullanımında uzun bağlam yönetimi ve tasarımı (context engineering) mutlaka gerekli
2 yorum
2.5 çıkalı epey oldu; neden hâlâ 1.5?
Hacker News görüşü
Ben de buna benzer deneyimler yaşadım. Özellikle Gemini Pro kullanırken uzun metin referansları verdiğimde, birden fazla belgeyi tek seferde context window içine koymaktan ziyade önce her belgeyi özetleyip soruyu ondan sonra sormanın ve gerekirse ayrıntılı belgelerin tamamını RAG tarzında ya da basit bir ajan döngüsüyle sağlamanın çok daha iyi yanıtlar verdiğini gördüm. Benzer şekilde Claude Code'u Opus ya da Sonnet ile kullanırken de, compaction ne kadar çok olursa sonuçların o kadar kötüleştiğini bizzat deneyimledim. Bunun özet kalitesinin düşmesinden mi kaynaklandığını, yoksa context window içindeki daha az ilgili verilerin oranı arttığı için mi olduğunu tam bilmiyorum; ama context'i temizleyip yalnızca ilgili dosyaları yeniden okumasını söylediğimde (önceki özette zaten geçiyor olsa bile) sonuçlar çok daha iyi oluyordu
Gemini, sohbet context sınırına ulaşmadan önce bile tutarlılık ve akıl yürütme açısından dağılmaya başlıyor. Buna rağmen bu rapora göre birçok açıdan en iyi model. Buradan çıkan sonuç, context engineering'in hâlâ önemli olduğu ve RAG yaklaşımının da hâlâ geçerli olduğu
"Compaction" sonuçta transkripti bir özete kısaltmak değil mi? Öyleyse bilgi gerçekten kaybolduğu için performansın düşmesi zaten beklenir. Ama bu context rot yüzünden değil. Asıl context rot sinyali, auto-compact eşiğine yaklaşırken ortaya çıkıyor. Doğru anladıysam durum bu, değil mi?
En iyi kodlama ajanının bunu otomatik yapması gerekirmiş gibi geliyor. Gerekli kodu, MCP yanıtlarını, repo haritalarını vb. toplayıp ara sıra özetlemesi ve bunların hepsini yeni bir sohbet mesajında birleştirerek gerçekten gerekli olan kısımları bırakması gibi. Ben zaten aider adlı araçla buna benzer bir tarz kullanıyorum ve çok context gerektiren durumlarda bunun agentic ya da otomatik iş akışlarından çok daha iyi performans verdiğini gördüm. Yalnız epey emek istiyor
NotebookLM'yi denedin mi? Bu uygulama arka planda belgeleri parçalayıp özetliyor ve RAG üzerinden tüm belgeye sohbet biçiminde soru sormanı sağlıyor
Cursor'da yeni özellikler ya da kod değişiklikleri hakkında uzun süre konuştukça çıktının giderek kötüleştiğini deneyimledim. En iyi sonuçları, önce net ve somut talimatlar ile bir plan hazırlayıp değiştirilecek dosyaları doğrudan context prompt'una sürükleyip bıraktığımda aldım
"Explore → plan → code → test → commit" akışıyla ilerlemek çok daha faydalı oldu. Gerekirse her aşamada context'i temizlemek de etkiyi artırabiliyor
Belirli bir görev için yeterli bilgi toplandığında, o noktada context'i kaydediyorum. Kalitenin düştüğünü görürsem, o ana kadarki çalışmayı yeniden özetleyip önceki checkpoint'in üstüne ekliyorum
Bu olgu iyi biliniyor ama düzgün şekilde belgelendiği yer pek yok; o yüzden bu yazıyı görmek çok sevindirici. Benchmark'larla kolay ölçülemeyecek kadar pratik etkisinin daha büyük olduğunu düşünüyorum. Gerçekten kullanışlı LLM tabanlı uygulamalar, modelin yapabildiklerinin sınırında duruyor. Yani gerçek sorularda ya da görevlerde mantıksal olarak birkaç kez "sıçrama" yapmayı gerektiren context'i takip edebilmesi önemli. Gerekli mantıksal "sıçrama" sayısı arttıkça context rot sorununun üstel biçimde ağırlaştığını düşünüyorum. Çünkü her sıçramada dikkat edilmesi gereken şeylerin sayısı da artıyor
Context'i kolayca kesip atmanın bir yoluna gerçekten ihtiyaç var. Modeli ve tüm konuşmayı doğrudan kendim yönetebilsem, yaklaşık 200 bin tokenlık bir kodlama oturumundan çok daha fazla performans çıkarabileceğimi düşünüyorum. Ama pratikte, iyi bir instance kullansam bile 20 bin token civarında model garipleşmeye başlıyor ve oturum da tamamen rot oluyor. Keşke bu kısmı basitçe kesip atabilsek
Yerel LLM'lerde context'i istediğin gibi düzenleyebildiğin için, LLM'nin yanıtını değiştirip sonradan modele bunu sanki en başta kendisi söylemiş gibi gösterebilirsin. Bu yüzden istediğin yöne çekmek açısından avantajlı. Buna karşılık LLM-as-a-service modelleri böyle bir özellik sunmuyor; çünkü sansürü aşmayı kolaylaştırabilir
"Hey Claude, şimdi context'i sıfırlayacağım; sonrasında çalışmaya devam edebilmem için bana tek bir prompt oluştur" dedikten sonra, Claude'un önerdiği prompt'u önceden gözden geçirip düzenleyerek yeniden verdiğim denemeler yaptım
Önceki bir checkpoint'e kolayca rollback yapabilmek gerçekten en iyi özelliklerden biri olurdu
Çoğu CLI ajanında bunu
/compresskomutuyla yapabiliyorsunClaude Code kullandıkça giderek kendi hatalarını benim talimatlarımdan ayırt edemez hâle geliyor. Kafası karışmaya başladığında çözüm yeni bir oturum açmak. Oturum uzadıkça aynı döngüye giriyor ya da testlerin zaten bozuk olduğunu iddia edip onları yok sayıyor (oysa aslında bu oturumda bozulmuş oluyor). Muhtemelen prompt'u yanlış verdiğim içindir ama son zamanlarda Claude'un IQ'su bir anda 30 puan düşmüş gibi geliyor
Ben de aynısını hissediyorum. Max plan kullanmama rağmen performansın iyi olduğu zamanlarla kötü olduğu zamanlar arasında belirgin fark var
"Herhâlde benim prompt'um ve context'im sorunlu" diye düşünmek hepimizin içselleştirdiği bir gaslighting hissi gibi
Bu, bilgi erişim probleminin bir türü; ancak context uzunluğundaki değişime bağlı performans düşüşünün yalnızca arama tabanlı yanıtlarla aynı şekilde işlemediğini düşünüyorum. Örneğin "Bu butonu kırmızı yapmak için neyi değiştirmeliyim?" gibi sorularda ya da "Yukarıdaki cümleler hangi kategoriye giriyor?" türü problemlerde farklı çalışabilir. Eskiden beni etkileyen makalelerden biri Many-Shot In-Context Learning olmuştu. Bu çalışma, örneklerle context dolduruldukça performansın ciddi biçimde arttığını gösteriyor. Sonuç olarak, LLM'nin context içeriği ve uzunluğuna göre nasıl değiştiğini anlamak için her problemi gerçekten test etmek gerekiyor. Context uzadıkça performans her zaman düşer diye varsaymamak lazım
İçeriği çok havalı ve içgörüsü yüksek bir yazı. Ama medya okuryazarlığı açısından Chroma'nın bir vectorDB şirketi olduğunu akılda tutmakta fayda var
Son dönemde Gemini 2.5 Flash ile birkaç uzun roman yazdım; context rot'u kesinlikle hissediyorum ama bu yazıda öne sürülenden çok daha geç ortaya çıkıyor. Bende, başlangıçtaki context'i (ör. çıktı dili gibi) göz ardı etmeye başlaması ancak 50 bin ila 100 bin token sonra oldu. Muhtemelen yaratıcı yazım gibi karmaşık görevlerde etkiyi ölçmek daha zor ya da daha az belirgin olabilir. Her durumda, arada eksik kalan context'i yeniden verirsen kullanılabilir bir seviyede kalıyor
Ben de benzer bir şey yaşadım. Bir proje kapsamında video transkriptleri için arama özelliği geliştiriyordum ve metinler çok uzundu. GPT 4.1 gibi modellerin geniş context window'u olduğu için RAG'e gerek kalmayacağını sanmıştım ama özellikle küçük modellerde garip davranışlar sık görülüyordu. Soruyu doğru yanıtlamak yerine bazen sadece tüm içeriğin özetini veriyorlardı
İlginç bir rapor. Model bazında önerilen context boyutları gibi şeyler var mı merak ediyorum. Kendi kullanım senaryom için hangi sınıra kadar gitmenin uygun olduğunu anlamanın bir yolu olup olmadığını bilmek isterim