Büyük Bağlam Pencereleri RAG Sistemlerimizi Daha Akıllı Yapmadı

Uzun bağlam pencerelerine sahip büyük dil modelleri (LLM) ilk çıktığında, çoğumuz aynı varsayımda bulunduk: Eğer bir model 128K token okuyabiliyorsa, bilgi geri getirme (retrieval) aşaması önemini yitirir. Neden belgeleri seçmekle uğraşalım ki? Hepsini modele veririz, o halleder. Ancak pratikte durum hiç de öyle olmadı.

Daha Fazla Bağlam, Daha Kötü Yanıtlar

Dahili asistanınıza şu soruyu sorduğunuzu hayal edin: "Mikroservis mimarisini neden terk ettik?"

Sistem size 30 belge döndürüyor:

Bir mimari karar kaydı (ADR)
Birkaç Jira görevi
Slack tartışmaları
Toplantı notları
Bir terimler sözlüğü sayfası

Tüm bu belgeler konuyla ilişkili görünse de neredeyse hiçbiri asıl sorunun yanıtını içermez. Asıl karar, aylar önce yazılmış tek bir ADR'de saklıdır; fakat bu belge sorguyla kelime bazında doğrudan eşleşmediği için gerilerde kalır. Model, kendisine sunulan 30 belgeye bakarak son derece tutarlı bir açıklama üretir. Ancak tutarlılık, doğruluk (faithfulness) ile aynı şey değildir. Model, asıl kararı bulmak yerine ilgisiz belgelerdeki ortak temalardan mantıklı ama yanlış bir cevap uydurur.

Yazılımcılar İçin Pratik Çıkarım: Sistemlerinizde yalnızca anahtar kelime eşleştirmesi veya basit vektör benzerliği kullanmak yerine, belgelerin türünü (örneğin ADR veya Slack yazışması) belirten meta-verileri de arama kriterlerine dahil edin.

Büyük Pencereler Bilgi Geri Getirmeyi Çözmez

"Lost in the Middle" çalışması, modellerin uzun bağlamların ortasında kalan bilgileri gözden kaçırdığını zaten göstermişti. Bizim deneyimimiz ise daha derindi: Bilgi, bağlam uzun olduğu için değil; geri getirme aşaması kararın olduğu belgeyi sadece konudan bahseden belgelerden ayıramadığı için kayboluyordu. Daha fazla bağlam eklemek bu sorunu çözmez; sadece modele yanlış bilgileri "harmanlayıp" ortalama bir yanıt üretmesi için daha fazla malzeme verir.

Yazılım Geliştirme Açısından Yorum: "Lost in the Middle" etkisi sadece modelin dikkat kapasitesiyle ilgili değildir. RAG başarısı, modelin gücünden ziyade veri boru hattının (data pipeline) geri getirdiği bilgilerin kalitesine ve temizliğine bağlıdır.

Yanlış Şeyi Optimize Ediyorduk

Bir süre boyunca bilgi geri getirmeyi bir "paketleme" süreci olarak gördük: Prompt içerisine kaç adet yararlı parça (chunk) sığdırabilirdik? Zamanla bu soru değişti:

Bu belge neden burada?
Burada olması gerekiyor mu?
Kararı açıklıyor mu, yoksa sadece aynı teknolojiden mi bahsediyor?

Bu soruları sormak, bağlam penceresinin boyutundan çok daha kritik sonuçlar doğurdu.

Öğrenme ve Geliştirme Çıkarımı: Dokümanları düz metin parçalarına bölmek (chunking) yerine, ingestion aşamasında LLM yardımıyla her parça için yapay sorular üretip (doc2query yaklaşımı) bunları indekslemeyi deneyebilirsiniz.

Bilgi Geri Getirme Bir Seçim Problemidir

En büyük zihniyet değişimi, 8K'dan 128K'ya geçmek değil; bilgi geri getirmenin bir "prompta bilgi sığdırma" değil, doğru bilgiyi seçme problemi olduğunu anlamaktı. Büyük bağlam pencereleri son derece kullanışlıdır; ancak zayıf bir geri getirme sistemini telafi edemezler. Aksine, zayıf sonuçların kulağa çok daha inandırıcı gelmesine yol açarlar.

Pratik Çıkarım: RAG sistemlerinde veriyi sadece çekmek yetmez. Geri çağırma (recall) ve hassasiyet (precision) dengesini kurmak için Cohere Rerank gibi güçlü yeniden sıralama modellerini boru hattınıza entegre etmelisiniz.

Orijinal makaleye buradan ulaşabilirsiniz.