Uzun bağlam RAG'i öldürmez, sorunu yer değiştirir

Tez#

Bağlam penceresi büyüdükçe tekrarlanan bir tahmin var: geri getirme geçici bir çözümdü, pencereler yeterince büyüyünce ortadan kalkacak. Bu tahmin geri getirmeyi tek işlevli bir mekanizma sanıyor — küçük pencereye çok veri sığdırma hilesi. Oysa geri getirme üç ayrı iş yapıyor ve pencere büyümesi yalnızca birincisine dokunuyor.

Üç işlev şunlar: sığdırma (sınırlı pencereye en gerekli bilgiyi seçmek), eleme (ilgisiz bilgiyi modelin dikkatinden uzak tutmak) ve yetki süzmesi (kullanıcının görmemesi gereken belgeyi hiç getirmemek). Pencere büyümesi birinci işlevi büyük ölçüde gereksiz kıldı. İkincisini kısmen zayıflattı ama ortadan kaldırmadı. Üçüncüsüne hiç dokunmadı — ve üçüncüsü kurumsal ortamda en belirleyici olanı.

Bağlam: üç işlevin akıbeti#

Aşağıdaki tablo, pencere büyümesinin her işleve ne yaptığını ayırıyor. Ayrımı yapmadan tartışmak, üç farklı soruyu tek cevapla geçmek anlamına geliyor.

Dördüncü satır ironik bir sonuç üretiyor. Pencere küçükken seçmek zorunluydu ve zorunluluk iyi mühendislik üretiyordu: ekip hangi bilginin gerçekten gerekli olduğunu düşünmek zorunda kalıyordu. Pencere büyüdüğünde bu zorunluluk kalktı ve yerine "hepsini koy, model bulsun" refleksi geldi. Bu refleks hem pahalı hem de kalite açısından tartışmalı.

Kanıt: sığdırmak kullanılmayı garanti etmiyor#

Uzun bağlamın en çok yanlış anlaşılan yönü şu: bir bilginin bağlamda bulunması, modelin o bilgiyi kullanacağı anlamına gelmiyor. Uzun bağlamlarda bilginin konumunun kullanımı etkilediği gözlemi — başta ve sonda olanın ortada olandan daha çok kullanılması — literatürde adı konmuş bir olgu. Bu, pratikte üç sonuç doğuruyor.

• Sessiz kayıp: doğru bilgi bağlamda olduğu hâlde cevapta kullanılmıyor. Hata teşhis edilemez çünkü "bilgi verilmemiş" gibi görünmez.
• Yanlış güven: ekip bilgiyi gönderdiği için sistemin onu bildiğini varsayar; denetim adımı atlanır.
• Sıralamanın gizli önemi: aynı bilgi kümesi farklı sırayla gönderildiğinde farklı cevap üretebilir — yani sıra bir tasarım parametresidir ama çoğu sistemde rastgeledir.
• Ölçüm zorluğu: bu kaybı yakalamak için bilginin bağlamdaki konumunu değiştirip cevabı karşılaştıran ayrı bir deney gerekir; standart değerlendirme setleri bunu görmez.

Mekanizma: yetki neden yer değiştirmiyor#

Kurumsal ortamda geri getirmenin en az tartışılan ama en belirleyici işlevi yetki süzmesi. Mantık basit ve pencere büyüklüğünden bağımsız: bir belgeyi bağlama koymak, o belgeyi o kullanıcıya göstermektir. Model belgeyi okuyup özetlerse, özet kullanıcıya gider. Belgeyi "görmemesi gerekiyordu" demek, sızıntıyı geri almaz.

Bu yüzden yetki sınırı cevap üretildikten sonra uygulanamaz; getirme aşamasında uygulanmak zorundadır. Kullanıcının göremeyeceği belge hiç getirilmemeli, bağlama hiç girmemeli. Pencere bir milyon token olsa da bu kural değişmiyor — aksine, sığdırma kolaylaştıkça ihlal etme olasılığı artıyor, çünkü "hepsini koy" refleksi yetki sınırını da atlar. Uzun bağlam bu nedenle yetki tasarımını gereksizleştirmiyor, aciliyetini artırıyor.

1. 1Yetkiyi dizine taşı

   Belge düzeyinde erişim etiketi dizinde saklansın; sorgu kullanıcının yetkisiyle süzülerek çalışsın.

2. 2Getirme sonrası filtrelemeyi savunma saymayın

   Belge bağlama girdiyse model onu okumuştur. Sonradan filtrelemek, çıktıyı değiştirir ama bilginin işlenmesini engellemez.

3. 3Bağlam dökümünü denetlenebilir tutun

   Hangi isteğe hangi belgelerin girdiği kayıtlı olsun. Bir sızıntı şüphesinde tek dayanak bu kayıttır.

4. 4Yetki değişimini dizine yansıtın

   Bir kullanıcının yetkisi kaldırıldığında dizinin de bunu bilmesi gerekir; gecikme bir sızıntı penceresidir.

Karşı görüş#

En ciddi karşı iddia maliyet tarafından geliyor: token fiyatları düşmeye devam ediyor ve istem önbelleği tekrar eden bağlamı çok ucuz hâle getiriyor. Sabit bir belge kümesini bir kez gönderip önbellekten yararlanmak, her soruda seçerek göndermekten ucuz olabilir. Bu iddia belirli iş yükleri için doğru ve giderek daha çok iş yükünü kapsıyor.

Tüm ürün dokümantasyonunu önbelleğe aldık ve geri getirmeyi kaldırdık. Maliyet düştü, gecikme düştü. Altı ay sonra yeni bir müşteri segmenti geldi ve herkesin aynı dokümanı görmemesi gerektiğini fark ettik.

Alıntıdaki hikâye tezin özünü gösteriyor: önbellekli uzun bağlam, tek bir yetki sınıfının olduğu durumda gerçekten geri getirmeyi gereksiz kılıyor. Herkes aynı belgeleri görebiliyorsa, seçmenin tek gerekçesi maliyet ve dikkat kalır; önbellek birincisini, model kalitesi ikincisini büyük ölçüde çözer. Ama birden çok yetki sınıfı ortaya çıktığı anda sabit önbellek çöker — her yetki sınıfı için ayrı önbellek tutmak gerekir ve sınıf sayısı arttıkça bu yaklaşım geri getirmeden pahalı hâle gelir.

Sınırlar ve belirsizlik#

Bu analizin dayandığı üç etken — maliyet, dikkat dağılımı, yetki — farklı hızlarda değişiyor ve ikisi öngörülemez.

• Fiyat eğrisi öngörülemez: token maliyeti belirgin biçimde düşerse maliyet argümanı zayıflar; ne kadar düşeceği bilinmiyor.
• Dikkat dağılımı mimariye bağlı: yeni kuşaklarda konum etkisinin ne kadar azaldığına dair karşılaştırılabilir ölçüm sınırlı.
• Yetki argümanı değişmiyor ama uygulaması ürün modeline bağlı: tek yetki sınıflı ürünlerde bu argümanın ağırlığı yok.
• Derlem büyüklüğü sınırı belirsiz: hangi belge hacminden sonra sığdırmanın tümüyle imkânsız hâle geldiği iş yüküne göre değişiyor.

Sonuç#

Uzun bağlam geri getirmeyi öldürmedi; onu bir sığdırma hilesinden bir erişim denetimi katmanına dönüştürdü. Bu, tartışmanın yer değiştirmesi demek: soru artık "bağlama sığar mı" değil, "bu kullanıcı bunu görebilir mi" ve "bunu göndermek fatura ile kalite açısından değer mi".

Pratik sonuç: tek yetki sınıflı, belge kümesi sabit ve hacmi sınırlı ürünlerde önbellekli uzun bağlam doğru ve basit bir mimari. Birden çok yetki sınıfı, sık değişen belge kümesi ya da büyük derlem varsa geri getirme yerinde duruyor — ve rolü daha kritik, çünkü artık yalnızca kaliteyi değil erişim sınırını da taşıyor.

Ne yapmalı?#

1. 1Yetki sınıfı sayısını sayın

   Tek sınıf varsa önbellekli uzun bağlamı ciddi bir alternatif olarak değerlendirin. İkiden fazlaysa geri getirme kaçınılmaz.

2. 2Konum deneyini yapın

   Aynı bilgiyi bağlamın başına, ortasına ve sonuna koyup cevabı karşılaştırın. Fark varsa eleme hâlâ gerekli demektir.

3. 3Önbellek isabetini ölçün

   Sabit önek gerçekten sabit mi? Kullanıcıya göre değişen tek bir alan, önbelleği tümüyle etkisiz kılar.

4. 4Bağlam dökümünü kayda alın

   Hangi isteğe hangi belge girdi? Bu kayıt olmadan sızıntı şüphesi araştırılamaz.

5. 5İki mimariyi maliyetlendirin

   Kendi hacminizle önbellekli uzun bağlamı ve geri getirmeyi ayrı hesaplayın. Karar genel bir eğilimden değil bu iki sayıdan çıkar.