Context collapse: Neden daha fazla dokümantasyonla doldurmak kodlama ajanlarını kötüleştiriyor

dev.to'da yayımlanan, aslında tamiz.pro'da paylaşılan derinlemesine bir inceleme, ekiplerin büyük bilgi tabanlarını yapay zekâ kodlama ajanlarına bağladıktan sonra genellikle zor yolla keşfettiği bir soruna ad veriyor: context collapse. Temel iddia şu: Her belge, yorum ve runbook ile yüklenmiş bir ajan, elinde yalnızca bir README olan ajandan daha kötü kod üretebilir — ve bu düşüş, model zekâsından kaynaklanan bir sorun değil, yapısal bir sorundur.

Context collapse nasıl görünür

Makaleye göre kötüleşme dört gözlemlenebilir şekilde ortaya çıkıyor. Birincisi, uzun bir prompt'un ortasına gömülmüş bilgi yok sayılırken model başa ve sona odaklanıyor. İkincisi, getirilen malzeme kendisiyle çeliştiğinde — örneğin farklı dokümantasyon sürümlerinden çekilen aynı API'nin iki farklı imzası — model belirsizliği işaretlemiyor; sessizce birini seçiyor. Üçüncüsü, bağlam büyüdükçe dikkat yayılıyor ve her öğe için etkin sinyal-gürültü oranı düşüyor. Dördüncüsü, dokümantasyondaki örnekler ve hazır kalıplar çıktıya sızıyor ve ajan, üretim kodu yerine dokümantasyon tadında kod üretiyor.

Yazar, etkinin doğrusal olmadığının altını çiziyor. Boş bağlamdan yaklaşık yarım doluluğa geçmek sonuçları iyileştirebilir ve biraz daha doldurmak hafifçe yardımcı olabilir; ancak kullanım oranının yaklaşık %80'i aşması raporlara göre kalitede yumuşak bir eğim değil keskin bir uçurum tetikliyor.

Arkasındaki dikkat matematiği

Yazı bunun nedenini adım adım açıklıyor: Bir transformer'da softmax normalizasyonu, modele bağlamdaki her token'a yayılan sabit bir dikkat bütçesi veriyor. 1.000 token'da her token ortalama yaklaşık %0,1 dikkat ağırlığı taşıyor; 10.000 token'da bu oran kabaca %0,01'e düşüyor. Yazarın örneği: 40 ilgili kod parçacığını 128K'lık bir pencereye tıkıştırmak, her parçacığa 4K bağlamlı bir modelde tek bir parçacığın alacağı dikkati veriyor. Kapsamı derinlik pahasına satın alıyorsunuz ve kodlama görevleri genellikle derinlik gerektiriyor — bir API'nin imzasını ve kısıtlarını derinden kavramak, kırk tanesini yüzeysel taramaktan daha iyi.

Makale ayrıca konumsal bir etkiye işaret ediyor ve bağlamın başını ve sonunu iyi, ortasını kötü işleyen U şeklinde bir performans eğrisi gösteren uzun bağlam araştırmalarına atıf yapıyor. Sunulan pratik çıkarım, sistem prompt'larını, konvansiyonları ve katı kısıtları pencerenin başına veya sonuna yerleştirmek, asla getirilen dokümantasyonun içine gömmemek.

Kodlama ajanları neden en sert vurulanlar

Dört etken kodlama ajanlarını alışılmadık ölçüde savunmasız kılıyor. Kod düz yazıdan daha yoğun, bu yüzden modelin kapasitesini ham token sayılarının ima ettiğinden daha hızlı doyuruyor. Çatışmalar sessiz: Bir sohbet asistanı çelişkili kaynaklar arasında tereddüt edebilir, ama bir kodlama ajanı çalıştırılabilir kod üretmek zorunda ve en son veya en sık görünen kalıbı seçme eğiliminde — kod tabanı için doğru olanı değil. Ayrıca her belge halüsinasyon yüzeyini büyütüyor, böylece bayat veya kullanımdan kalkmış imzalar kendinden emin biçimde yeniden üretiliyor. Son olarak yazar bir dokümantasyon paradoksunu çerçeveliyor: Dokümanlar göz gezdiren ve atlayan insanlar için yazılırken, modeller her token için tam işlem maliyeti ödüyor ve bir paragrafı yok sayma mekanizmasına sahip değil.

Önerilen beş çözüm

İnceleme beş mimari çare öneriyor: katmanlı bağlam mimarisi, alaka filtrelemeli getiri, enjekte etmeden önce özetleme, token muhasebesiyle bağlam bütçeleme ve ajan tarafından orkestre edilen bağlam birleştirme. Ayrıca kendi pipeline'ınızda context collapse'ı ölçmeye dair bir bölüm içeriyor. Belirtmek gerekir ki akışımızda bulunan sendikasyon kopyası ortadan kesiliyor, bu yüzden her çözümün ayrıntılı mekanikleri elimize ulaşan metinden doğrulanamadı; burada yalnızca çözüm adları ve onlardan önceki analiz yansıtılmıştır.

Neden önemli

RAG ağırlıklı ajanlar inşa eden ekipler getiri başarısını genellikle kapsamla ölçüyor — pencereye ne kadar ilgili malzeme girdiğiyle. Bu makale gerçek darboğazın dikkat tahsisi olduğunu ve bir eşiği geçtikten sonra ek bağlamın nötr değil, aktif olarak zararlı olduğunu savunuyor. Modeller giderek daha büyük pencerelerle piyasaya sürüldükçe, daha fazla kapasitenin sorunu çözdüğü varsayımı daha da sarsılıyor görünüyor: Kullanım uçurumları duruyor ve kodun yoğunluğu bunların daha erken gelmesine yol açıyor. Yazının yön verdiği pratik değişim, bağlamı kıt bir bütçe olarak ele almak — filtrelenmiş, özetlenmiş, bilinçli olarak konumlandırılmış ve ajan tarafından toplanmış, değilse toptan boşaltılmış.