Büyük bağlam pencerelerine güvenmeyin

• LLM'lerin bağlam penceresi, modelin keskin çalıştığı akıllı bölge ile dikkatinin düştüğü ve önceki talimatları unutmaya başladığı körelmiş bölge olarak ikiye ayrılabilir
• Ayrım noktası yaklaşık 100k token civarındadır ve ilan edilen bağlam penceresi boyutunun büyük olması, gerçek çalışma aralığının da aynı ölçüde büyük olduğu anlamına gelmez
• Kodlama ajanları yalnızca dosya okuma, uzun hata ayıklama ve büyük test çalıştırmalarıyla bile hızla token tüketip 100k token seviyesine ulaşabilir
• RULER ve Chroma'nın context rot raporu, etkili bağlamın ilan edilen sayının yalnızca bir kısmı olduğunu ve pencere doldukça performansın kademeli olarak düştüğünü gösteriyor
• Uzun oturumları otomatik özetlemek yerine, bilgiyi oturum dışına doğrudan yazılmış spesifikasyonlar ve küçük çıktılar olarak bırakmak, çalışmayı akıllı bölgede tutar

---

Bağlam penceresinin gerçek sınırları

• LLM bağlam penceresi, modelin keskin olduğu akıllı bölge ile dikkatinin azaldığı körelmiş bölge olarak ayrılabilir
  • Körelmiş bölgede model, birkaç dakika önce verilenleri unutmaye başlar
  • Ayrım noktası yaklaşık 100k token civarındadır
  • İlan edilen bağlam penceresi boyutu büyüse de bu ayrım noktası ortadan kalkmaz
• Kodlama ajanları, modern kullanım biçimlerinde token'ları hızla tüketir
  • Birkaç dosya okuma, uzun bir hata ayıklama oturumu ve geniş test çalıştırmalarıyla bile 100k token seviyesine ulaşılabilir
  • Sağlayıcılar 200k, 1M, 2M bağlam pencereleri ilan etse de bu sayılar kullanılabilir çalışma kümesini ifade etmez
• Büyük bağlam pencereleri çoğunlukla pazarlama rakamlarıdır
  • Arkasındaki mimari çalışsa da, temel dikkat mekanizmasının gerçekte çözemediği sorunları örtbas eder
  • Ürünlerde gösterilen rakamlar her sürümde büyür, ancak kullanılabilir kısım aynı hızda artmaz
• RULER ve Chroma'nın context rot raporu, etkili bağlamın ilan edilen rakamın yalnızca bir bölümü olduğunu gösteriyor
  • Bağlam penceresi doldukça performans kademeli olarak düşer

Oturumları kısa tutan çalışma biçimi

• En yeni ajanlar, uzun oturumları yönetmek için otomatik sıkıştırma özellikleri sunmaya başladı
  • Claude Code, oturum uzadığında geçmişi özetleyip yeniden başlayan bir auto-compact işlemi yapar
  • Bu yaklaşım yardımcı olur, ancak zaten körelmiş bölgede zaman geçirdikten sonra devreye girer
  • Üstelik özeti de performansı zaten düşmüş bir model üretir
• Daha iyi bir devir yöntemi, yeni bir oturum açıp elle yazılmış bir spesifikasyonu aktarmaktır
  • Elle yazılmış spesifikasyon, otomatik özetten daha güçlü bir sinyal taşıyan devir malzemesi olur
  • Çünkü bundan sonra neyin önemli olduğuna insan doğrudan karar verebilir
  • Bu yaklaşım, bir sonraki oturumun ya da bir sonraki kişinin temiz biçimde devralabileceği çıktılar bırakan breadcrumb yaklaşımına karşılık gelir
• obra/superpowers ve mattpocock/skills, ajan iş akışlarını adı olan küçük çıktılar etrafında kurar
  • PRD, planlar, beceriler ve alt ajan devirleri bu çıktılara örnektir
  • Her çıktı, bilgiyi canlı oturumun dışına taşıyarak bir sonraki oturumun onu okuyabilmesini sağlar
  • Bu yaklaşım, çalışma oturumunun akıllı bölgede kalmasına yardımcı olur
• Bağlam penceresine bir bütçe gibi yaklaşılmalıdır
  • Gerçekte yardımcı olan kısmın öndeki birkaç parça olduğunu varsaymak gerekir
  • Canlı oturumdan yazılı çıktılara aktarılan bilgi, modelin dikkatinin rekabet etmek zorunda olduğu şeyleri azaltır

[baam12]

100 bin de ne ki, 40-50 bin token olduğunda bile zorlandığı görülüyor.

[GN⁺]

Hacker News görüşleri

• Yapay zekanın temellerini öğrenmek epey keyifli ama işlerin şu anda gittiği yönü onaylamıyorum
  Böyle başlıklardaki yorumların ne kadar rahatsız edici hissettirdiğini anlatmak zor. “XYZ bende böyle oldu” türü iyi niyetli deneyim paylaşımları, Facebook’taki evcil hayvan bakımı ya da yemek başlıklarındaki tavsiyelere benziyor
  3D baskı Facebook gruplarında durum daha da kötü; baskı alıyor ama gerçekte neler olduğunu anlamak isteyen biriyseniz ne demek istediğimi anlarsınız
  LLM dünyasında, özellikle de bulut LLM dünyasında, ortak bir titizlik duygusu tamamen çökmüş ve iş en sonunda büyüsel taklide indirgenmiş gibi geliyor. Artık kimse diğerinden daha doğru ya da daha yanlış değil
  Hava şu tarzda: “Bağlamı Dawn bulaşık deterjanıyla yıkayıp kuruttuktan sonra bir kat glue stick sürdünüz mü?”
  Yardım etmeye çalışan insanlara fazla sert konuşmak istemem. Ama bu başlıklar diğer konulardaki başlıklardan çok farklı hissettiriyor. Normalde birinin önerisini başkaları tartışır ya da inceltir, bazen de biri bash history seçim yöntemi gibi bir şeyi açıklar ve hayatınız değişir; ama bu tür başlıklar sonunda “Tehdit edince işe yaraması sizce de tuhaf değil mi?” noktasına akıyor

  • LLM iş akışlarının keyfi ve deterministik olmayan yapısı gerçekten huzursuz edici. Eski usul gömülü/sistem tarafında çalışan biri olarak her zaman determinizmi ve tekrarlanabilirliği önceliklendirdim
    Buna rağmen ajanlar harika ve “düşünce süreci tasarımcısı” olmak da keyifli. Geri dönmeyeceğim. Yapay zeka geliştirme bugün dursa bile kariyerim artık eskisi gibi olmaz gibi geliyor
  • Teknoloji sektöründe bu tür şeyler LLM’lerden çok önce de hep vardı
    Nesnel ve ölçülebilir kriterler yerine “biraz daha ünlü bir şirket öyle yapıyor” diye karar verilen çok fazla toplantı yaşadım. Hatta o şirketin o yaklaşımı genel olarak uygulamadığına dair kanıtlar bile şaşırtıcı derecede etkisiz kalıyordu
  • IT tavsiyeleri zaten bir ölçüde hep böyleydi. Sistemler ve sonuçlar karmaşıklaştıkça neyin “daha iyi” neyin “daha kötü” olduğunu net tanımlamak zorlaşıyor
    Bir de LLM’lerin güçlü biçimde deterministik olmaması eklenince, LLM tavsiyeleri fiilen bahçıvanlık tavsiyesine dönüşüyor
    Hatta “benchmark”lar bile çoğu zaman birinin sezgisini belli ölçüde başarıyla kristalleştirme girişiminden ibaret
  • Bu hayal kırıklığına güçlü biçimde katılıyor ve genel olarak aynı fikirdeyim. LLM tabanlı iş akışlarını her formelleştirmeye çalıştığımda, neden bazı şeylerin çalışıp bazılarının çalışmadığını kimsenin gerçekten bilmediğini görüp yeniden hayal kırıklığına uğruyorum
    Bu yüzden en sonunda yine /plana dönüp “uygulamayı yinelemeye başlamadan önce bunu ileride kullanmak üzere bir Markdown belgesine yaz” diyorum ve belki gelecek ay biraz daha titiz, biraz daha rasyonel temeli olan bir şey çıkar diye umuyorum
    Ben hiç glue stick kullanmıyorum çünkü ihtiyaç duymuyorum. Ama Dawn, Bambu build plate’in yeniden iyi tutunmasını sağlamada oldukça etkili görünüyor. Özellikle arayıp aldığım bir şey değildi, zaten bulaşık için evde vardı. IPA işe yaramayınca Dawn denedim ve birçok kez baskıların yeniden iyi tutunmasını sağladı. Henüz N=30 seviyesine gelmedim
  • Zihnimizdeki “ortak titizlik” fikrinin kendisi bir yanılsama olabilir ve LLM’ler ile onların bağlam sorunu bunu görünür kılıyor olabilir
    On yıllardır içinde yaşadığım teknoloji sektöründe pek fazla titizlik görmedim. Araçlar çoğalıyor, paradigmalar doğup ölüyor ve yeniden ortaya çıkıyor; neyi ölçerseniz ölçün, her ölçüte farklı birimlerle çalışan rakip başka ölçütler eşlik ediyor. Güç ve sinyal fiziğini, silikon wafer’ların belirleyici maliyetlerini aştıktan sonra, çok daha eski birkaç disiplinle kıyaslandığında hepimiz neredeyse sadece farklı ustalık düzeylerine sahip tamircileriz
    Bağlam sınırlarını aslında görece kolay yönettik. Bir şartname tanımlar ve kapsamı sınırlandırırsınız. LLM’lerin iyi sonuç vermesi için açık bir spesifikasyon ve güçlü yönlendirme gerekir
    Ama bu da şimdilik sadece mevcut yamalı pratik sezgimizin bir parçası. Belki 90 gün sonra bu yük bile ortadan kalkar ve tek bir basit prompt ile dünya çapında bir işletim sistemi, bir programlama dili ve ikisi için matematiksel biçimsel temel üretilebilir

• Aracı döngüsüne tek bir basit kısıt koyarak bağlam boyutu sorununu önlüyorum. Kullanıcının en üst düzey konuşma akışında tüm araç çağrılarını engelliyorum. Araç çağrısı gerektiren işler yalnızca ajanın özyinelemeli çağrıları içinde gerçekleşiyor ve sadece sonuçlar çağırana geri dönüyor
  1 milyon LOC’yi aşan kod tabanlarında bile bütün gün aynı yüksek seviyeli konuşmayı sürdürürken anlamlı bir token sınırına ulaşmadım. Sıkıştırma ya da özetleme numaralarına da gerek yok. Özyinelemeli çağrıda 50 milyon token harcansa bile kök konuşma akışı 100 bin tokene bile dokunmayabilir
  Ajan her tekrar Narnia’ya indiğinde yeniden “bootstrap” etmek için biraz işi baştan yapmak gerekiyor, ama bu, her şeyi sürekli taşımaya çalışan büyük ve düz bir bağlamı yanında gezdirmekten çok daha verimli
  Özyineleme, token kullanımını kontrol etmekte çok etkili ama sınırları da var. Özyineleme derinliği 1’in üstünde fayda gördüğüm olmadı. Ajanın birkaç kez denediğini gördüm ama gerçek performans vermedi. Dışsal sembolik özyineleme, görünüşe göre en ileri modellerin eğitildiği bir şey değil. Bağlam içinde özyinelemeyi taklit etmekte harikalar ama amaç token kullanımını azaltmaksa bu istenen yön değil

  • Claude Code kullananlar için çözüm, tüm işleri workflow içinde yapmasını söylemek. Buna uygun bir araç var; Opus 4.8 ile gelen bir özellik ve uzun işleri de biraz daha iyi yapıyor gibi görünüyor
    Bu noktada ana konuşma sadece işi koordine etme rolünü üstleniyor
  • Sezgisel olarak mantıklı geliyor. Böyle kısıtlar koymayı sağlayan hangi harness’i kullandığını ve bunu nasıl ayarladığını merak ediyorum
  • Claude Code bunu bazı durumlarda otomatik yapıyor gibi görünüyor. “Bağlamı çok tüketecek” türünden bir heuristik var ve işi alt ajana devretmeye karar veriyor gibi
    Bunu özellikle problem çözme ya da veri analizi akışlarında sık görüyorum; veri toplama ve toplulaştırmayı alt ajana bırakıp sadece özet sonucu geri alıyor
    Benzer şekilde ana ajan bazen bağlamı tasarım dokümanında ya da Markdown dosyalarında tutup ilerledikçe güncelliyor. Böylece istenildiğinde silme, yeniden başlatma ya da devretme mümkün oluyor
  • Ben farklı bir yaklaşım kullanıyorum, ama hâlâ ne kadar iyi çalıştığını anlamaya çalışıyorum. Özyinelemeye girmek yerine, bağlam çok büyüdüğünde ya da tıkandığında ajan özet/rapor/düşünme aşamalarından geçip akışı yeniden başlatabiliyor; temel bulguları kalıcı belleğe yazabiliyor ve prompt’u yeniden oluşturabiliyor
    Bir bakıma tail call optimization olan bir özyinelemeye benziyor
    Bazı yönleriyle bu, belirtim güdümlü yaklaşımın genelleştirilmiş hâli; tek fark, biçimsel belirtimin yanında devralınan bir tamponun da bellekte kalması
  • Bunun ilginç olmasının nedeni, bağlamı ve token kullanımını azaltmanın kullanıcı için faydalı olması ama AI sağlayıcılarının mali çıkarlarıyla çelişmesi
    Uzman olmasam da bu “basit numara”, bağlam sorununu çözüp token kullanımını çok daha sıkı biçimde kontrol etmeyi sağlayacak gibi geliyor. Böyle bir ipucunu HN yorumunda paylaştığın için teşekkürler. Bundan sonra bilgili kişilerin AI ajanlarını kullanma biçimi değişebilir gibi görünüyor. Yetişmek zor

• Anthropic abonelik planında 1 milyon token bağlam penceresi sunmaya başladığından beri Opus’ta böyle bir deneyim yaşamadım. Normalde de sık sık 500 bin tokenı geçiyorum, bazen 800 bin token civarına yaklaşsam da bu sorunu görmüyorum
  Gerçek sınıra yaklaşan 900 bin token ve üstünde bir miktar gördüm ama yazarın yaşadığı kadar ağır değildi
  Zaten tek bir işte ya da aynı bağlamı koruyacak kadar ilişkili iş kümelerinde bağlam penceresini o kadar doldurmak nadir oluyor; genelde 200 bin ila 600 bin civarında kalıyor
  Bunu yaşayan hiç kimse yok demek değil, ama bazı kişilerin buna isim takacak kadar sık yaşaması bana garip geliyor

  • Bunu sık duyuyorum ama Opus modellerinin 100 bin tokenın altında bile temel hatırlama hataları yaptığını defalarca gördüğüm için kulağa saçma geliyor
    Bana göre Opus’un gerçekten zeki olduğu aralık 60 bin tokenın altı. Opus 4.7 ve 4.8 daha parçalı bir tokenizer yüzünden daha da kötü
  • Opus 4.6, 200 bini geçince sarhoş gibi oluyordu; 4.7’yi atladım; 4.8 yaklaşık 350 bine kadar iyiydi; Fable ise sınırlı testlerde 400 bini geçince bile harikaydı
    Kalite yükselen bir trendde görünüyor
  • Herkes aynı modeli ve aynı harness’i kullanmıyor, bir de modelleri aynı biçimde kullanmıyor
    Modeller ve model sürümleri farklı attention mimarileri kullanıyor ve bu da uzun bağlam performansını etkiliyor. Uzun bağlam eğitiminin miktarı ve türü de kesinlikle farklıdır
    Ajanların bağlamı nasıl kurduğu ve bağlam sıkıştırmayı nasıl uyguladığı da farklı
    Aynı model, aynı ajan/harness ve çok benzer işler yoksa bağlam boyutuyla ilgili model davranışının aynı olmasını beklemek için bir neden yok
  • Sık sık 300 bini geçiyorum ve 800 binde de çalıştım ama bu kesinlikle gözlemlenebilir bir sorun
    Büyük bağlam pencereleri bazı problemlerde işe yarayabilir, ama ben 300 binin altında daha küçük bağlamlara yönelmenin daha etkili olduğunu düşünüyorum
  • Katılıyorum. Claude ailesi bu açıdan her sürümde giderek daha iyi oluyor
    Opus 4.5, 200 bin sınırına yaklaşınca araç çağrıları başarısız olmaya başlıyordu; Opus 4.6, kafası karışmadan önce yaklaşık 300 bine kadar gidiyordu; Opus 4.7, yaklaşık 400 bine kadar çıkabiliyordu ama sonrasında aptallaşma bölgesi başlıyordu. Opus 4.8’de 500 bini rahat geçtiğim oturumlar oldu
    Fable’ı sınırlı süre kullandım ama 800 bin ila 900 bine sorunsuz çıkan birkaç oturum da oldu

• Opus’un son sürümleri 100 bini geçince de fena değil ama ben genelde 200 binin altında tutmaya çalışıyorum
  Bu yüzden sözde bellek sisteminin çoğu zaman modeli daha aptal hâle getiren bir hata olduğunu düşünüyorum. Modelin belleği yok, sadece bağlamı var; alakasız gerçekleri bağlama doldurdukça probleme ayırabileceğin bağlam azalıyor. Ne kadar az dikkat dağıtıcı şey varsa sonuç o kadar iyi oluyor
  Ajana bir şeyi “hatırlatmanın” yolu, bir insan geliştiricinin başka geliştiricilere kolaylık sağlayan bir proje oluşturduğu gibi işi belgelendirmesini sağlamaktır. Dizin sayfası olan iyi geliştirici dokümantasyonu ile kontrol listeleri içeren iyi planları kısa Markdown dosyaları olarak kaydedip depoya commit etmek, model için ideal bellektir; ayrıca modelin ne yaptığını anlamak için gereken ideal dokümantasyondur. İnsanların ya da başka modellerin kod incelemesinde de işe yarar ve hiçbir dezavantajı yoktur

  • En azından benim durumumda Opus sürekli belleğe bir şeyler yazıyor ama aynı hatayı tekrar etmeden önce o belleği kontrol etmeyi sürekli unutuyor
    Bu yüzden “belleği kontrol etmesini hatırlat!” da tekrar belleğe yazılıyor. Açıkçası iyi çalışan bir sistem değil
  • “Bellek” sistemleri, geliştiricilerin AI’a katkıda bulunduklarını hissetmelerinin bir yolu

• Buradaki yorumların neredeyse tamamı kişisel deneyime dayanıyor. Buna karşılık ana yazı, çeşitli modeller için bazı standartlaştırılmış test performanslarını karşılaştıran iki araştırmaya atıf yapıyor
  Bu testlerin ne kadar iyi olduğunu söyleyemem ama LLM performansı gibi muğlak ve öznel bir konuda anekdotsal kanıtlardan daha kötü olamazlar

  • Anekdotsal kanıta biraz daha ekleyeyim: Yaptığım tüm testlerde Llama ailesi komut takibinde berbattı. RULER'daki diğer modelleri ise pek bilmiyorum
    Chroma sonuçlarında Sonnet 4 görüyorum; benim deneyimimde de Sonnet 4 berbattı. Sonnet 4.5'te kusursuz çalışan aynı prompt, Sonnet 4'te feci şekilde başarısız oldu
    Hem en güncel en yüksek performanslı modelleri hem de açık ağırlıklı modelleri içeren yeni testler görmek isterim. En yüksek performanslı modellerin komutları her zaman daha iyi takip edip konudan daha az saptığı hissine kapılıyorum; bunu destekleyen veri olsa iyi olurdu
  • Bu araştırmalar 2024 ve 2025 tarihli. Mevcut Claude modellerine uygulanamaz

• AI'nın ürün yöneticisi gibi davranıp, yapılacak her özellik için kısa bir PRD yazmasını güçlü biçimde istemekle epey iyi sonuç alıyorum
  Bu sayede zaman geçse de neyin yapıldığını referans alabiliyorum ve her özellikte daha az savrulma oluyor. Her özellik için ayrı bir konuşma tutuyorum
  Benim için bu, raydan çıkmayı engellerken gerektiğinde geçmiş kararları referans almayı sağlayan iyi bir orta yol. Pocock'un yaklaşımında hoşuma gitmeyen şey, daha az PRD yazıp önce derinlemesine tartışmayla hizalanmaya çalışması; bence en iyi kısmı olan ilk gidiş gelişlerde çok fazla şey boşa harcanıyor

  • Bunu geçici olarak mı yapıyorsun, yoksa openspec gibi daha yapılandırılmış bir yaklaşım mı kullanıyorsun merak ediyorum
    Ben de önce plan yapma tarafındayım ama bu genelde oturum içindeki yapılacaklar listesi olarak kalıyor ve sonradan referans vermek zor oluyor

• Ajanın içinde neler olup bittiğini kurcalamak muhtemelen uzun süre yazılım geliştirmenin bir parçası olarak kalmayacak
  Ben şahsen LLM'leri ve ajanları zaten kara kutu olarak görüyorum. Her özellik isteğini birden fazla LLM'e verip sonuçları karşılaştırıyorum. “Oturum”ları elle yazmıyorum. Sadece sonuca bakıyorum. Hoşuma gitmezse git reset --hard yapıp prompt'u değiştiriyor, sonra özellik isteğini yeniden başlatıyorum
  Hangi ajanın en iyi performansı verdiğine dair sürekli sezgi kazanmak için log tutuyor ve ihtiyaçlarımı en iyi karşılayan ajanın ELO puanını hesaplıyorum. Benim için önemli olan o puan; ajanın buna nasıl ulaştığı çok da önemli değil

  • Gerçek çıkarım maliyetini düşününce bu gerçekten inanılmaz derecede savurgan bir yöntem ve övünülecek bir şey değil
  • Ne tür projeler ya da kod işleri yaptırdığını merak ediyorum
    Güvenlik ya da başka yoğun doğrulamalar gerektirmeyen frontend işi türleri için fena olmayabilir diye tahmin ediyorum
    Ama regüle sektörlerde ya da aşırı dikkat gerektiren işlerde uygun görünmüyor
  • Şu anda en önde giden model hangisi?

• Evet, bağlam yönetimi işin özü
  Kendi framework'ümü kurup bu sorunu debug etmeye çok zaman harcıyorum; mutlak bağlam boyutundan çok, pencerenin içine tortu ya da yanlış yönlendirmeler girip kullanıcının önemli gördüğü şeylerin üstünü örtme olasılığı daha büyük sorun
  Bu, LLM'in az önceki yaklaşımda başarısız olduğu şeyi tekrar tekrar yapmaya çalışması olarak ortaya çıkıyor. Bağlam penceresinde bir şey sık görünüyorsa, yanlış olsa bile ağırlık kazanıyor
  LLM'e tonla araç vermek yerine, araçları aramak için kullanacağı araç vermek gibi pek çok püf noktası da var
  Ama daha büyük çözüm süreçte. superpowers gibi bir şey kullanarak LLM'i adım adım zorlamak ve ileri taşınacak bağlamı kontrol etmek gerekiyor

• Pi için çok küçük bir kişisel eklenti yapıp /last komutunu ekledim. Tüm oturumu temizliyor ve yalnızca ajanın son çıktı mesajını bırakıyor
  Bu sayede manuel “sıkıştırma” yapılabiliyor. Temelde ajana “konuştuğumuz planı, düzenlenecek dosya referanslarıyla birlikte özetle” diyorum, ardından /last çağırıyorum ve sonra implement etmesini söylüyorum
  [1] https://pi.dev/

• Burada “modeller” diye genelleme yapılmasını sevmiyorum. Modellerin attention mimarileri farklı ve bu yüzden uzun bağlam davranışları da ciddi biçimde değişebilir
  Uzun bağlamın sorun olduğu ve çoğu modelde kalite düşüşü yaşandığı doğru, ama eski modellerin davranışını yeni modellere birebir genellemezdim