Uzun bağlam dil modelleri, duyurulan token limitlerinin çok altında başarısız olmaya başlıyor

Makale ne iddia ediyor

Dev.to'da yayımlanan bir geliştirici incelemesine göre, büyük dil modelleri uzun bağlam görevlerinde, duyurulan bağlam pencerelerinin çok altındaki girdi boyutlarında başarısız olmaya başlıyor ve belirli bir noktadan sonra eklenen bağlam yanıtları iyileştirmek yerine kötüleştiriyor. Temel iddia şudur: Modelin belirtilen bağlam uzunluğu, bir prompt'a ne kadar metin sığdığını değil, modelin gerçekte ne kadar metni etkili biçimde kullanabildiğini anlatır.

Pencere bir bellek değil, payload limitidir

Yazı, yaygın bir zihinsel modeli çürüterek başlıyor. LLM API'ları durumsuzdur (stateless): çağrılar arasında hiçbir şey saklanmaz, dolayısıyla her istek, system prompt ve önceki tüm soru-cevaplar dahil olmak üzere tüm konuşmayı yeniden gönderir. Bağlam penceresi yalnızca sağlayıcının isteği reddetmeden önce kabul edeceği metin miktarını tanımlar ve bu payload'daki her şey her çağrıda yeniden işlenir.

Dikkat karesiyle ölçekleniyor

Modelin içinde attention, her token'ın diğer tüm token'ları tartmasını sağlar; bu da token çiftlerinin sayısının girdi uzunluğunun karesiyle büyüdüğü anlamına gelir. Makale aritmetiği adım adım açıklıyor: 10 token 100 çift, 1.000 token bir milyon çift, 100.000 token ise 10 milyar çift üretir. Bağlam on kat arttığında iş kabaca yüz kat artar. Key-value önbelleği (cache), uzun bir sohbette ilk yanıtın sonrakilerden daha yavaş hissedilmesini açıklar — ancak yazarın da belirttiği gibi cache hesaplama gücünden tasarruf sağlar, yanıt kalitesini korumak için hiçbir şey yapmaz.

Bozulmanın ardındaki üç mekanizma

İlk mekanizma, dikkat alanının sabit bir bütçe olmasıdır. Softmax, her token'ın attention ağırlıklarının toplamını bire eşit olmaya zorlar; dolayısıyla elli belge daha yapıştırmak modele daha fazla odak vermez, aynı odağı daha fazla materyal arasında bölüştürür. Yazar bunu dosya aramasına benzetiyor: on dosya içinde bir sorgu yapmak önemsizdir, aynı sorgu on bin dosyada yapılırsa doğru sonuç, sonuç listesinin derinliklerine itilir — tek fark, model size bu sonuç sayfasını hiç göstermez, sadece bir yanıt üretir.

İkincisi konumsaldır. Makale, Liu ve ekibinin "Lost in the Middle" araştırmasına atıf yaparak, araştırmacılar tek bir doğru yanıtı içerik olarak aynı kalan uzun bir prompt içinde gezdirdiğinde doğruluğun başta ve sonda yüksek kaldığını, ortada ise keskin biçimde düştüğünü raporluyor. Uzun bir prompt'un yüzde 60 civarında duran kritik bir paragraf, olabilecek en kötü konumdadır.

Üçüncüsü, gerçek verideki dikkat dağıtıcıdır (distractor). Needle-in-a-haystack değerlendirmeleri yanıltıcı biçimde olumludur, çünkü iğne samana hiç benzemez. Üretim ortamındaki corpuslar farklıdır: bir belgenin ikinci ve üçücü sürümleri, eski bir changelog ve hepsini çelişen bir sohbet zinciri bulunur — yalnızca biri doğruyken birkaç makul parça vardır ve model bunları ayırt edemez. Girdi büyüdükçe doğruluk, aynı modelin kısa uzunluklarda iyi başa çıktığı görevlerde bile istikrarlı biçimde düşer.

Geliştiriciler neyi değiştirebilir

Makale dört somut ayarlama önerisiyle kapanıyor:

• Daha az ama daha iyisini gönderin. Retrieval hatlarında geniş arama yapın, sonuçları yeniden sıralayın (re-rank) ve elli yerine yalnızca en iyi üç ila beş parçayı iletin.
• Kenarları kullanın. Talimatları en üste koyun, veriyi ortaya yerleştirin ve asıl soruyu model yanıtlamadan hemen önce en alta tekrar edin.
• Tek dev bir konuşma zincirini kullanmayı bırakın. Bir işi adımlara bölün, her adıma yalnızca ihtiyacı olan şeyi içeren taze ve küçük bir bağlam verin ve adımlar arasında kısa özetler aktarın — yazarın ifadesine göre agent framework'lerin kaputun altında yaptığı da büyük ölçüde budur.
• Kendi verinizde ölçün. Uygulamanızdan yaklaşık yirmi gerçek soruyu 2.000 token bağlamla çalıştırın, sonra aynı soruları 20.000 token'la tekrar deneyin ve yanıtları yan yana karşılaştırarak kendi etkin limitinizi bulun — bu limit muhtemelen satıcının belirttiği değerin altında kalacaktır.

Neden önemli

RAG sistemleri veya uzun bağlam hatları kuran herkes için duyurulan pencere, girdi boyutuna bir üst sınırdır, doldurulması gereken bir hedef değil. Ona yaklaşmak üç cezayı aynı anda beraberinde getirir: karesel attention maliyeti, daha yavaş ilk yanıtlar ve ölçülebilir biçimde düşük doğruluk. Pratik çıkarım, bağlamı pahalı bir bant genişliği olarak görmektir — retrieval kalitesi ve prompt yapısı, ham kapasiteden daha fazlasını kazandırır ve bir ekibin kullanılabilir bağlam uzunluğu, teknik veri sayfalarından varsayilmak yerine kendi verisi üzerinde deneysel olarak ölçülmelidir.