Agentic RAG mı, klasik RAG mı?

Erişimle zenginleştirilmiş üretim (RAG), bir dil modeline yanıt verdiği anda ihtiyaç duyduğu belgeleri sunar. Klasik biçiminde akış sabittir: soru alınır, dizinde bir kez arama yapılır, en iyi pasajlar modelin önüne konur ve yanıt yazılır. Agentic RAG, yani ajan tabanlı RAG, bu akışın etrafına bir döngü kurar. Sistem arama yapıp yapmayacağına, neyi arayacağına, hangi aracı çağıracağına ve bulduğunun yanıt için yeterli olup olmadığına kendisi karar verir.

İkisinden biri daha iyi bir tasarım değildir. Farklı sorulara uygundurlar; işin hangisine ihtiyaç duyduğunu masadaki soru belirler.

Tek arama neyi iyi yapar?

Bir uzmanın baktığı soruların çoğu tek bir aramayla çözülür. Güncel politika bildirim süresi hakkında ne diyor? Bu sözleşmede erken feshi hangi madde düzenliyor? Bu kontrol adımının toleransı ne? Bir arama, bir pasaj, bir yanıt.

Bu tür sorularda klasik RAG'ı geçmek zordur. Maliyeti bir arama ve bir model çağrısıdır. Gecikmesi öngörülebilir. Denetim izi kısadır: soru, getirilen pasajlar, yanıt ve her pasajın geldiği kaynak. Test etmek de doğrudandır, çünkü doğru pasajın gelip gelmediğini ve yanıtın ondan çıkıp çıkmadığını kontrol edebilirsiniz.

İlk RAG çalışması, bir üretici modeli dış bir dizin üzerinde çalışan bir bilgi getiriciyle eşleştirdi. Bu eşleşme hâlâ doğru varsayılandır. Değişen bilgi dizinde durur ve orada modele dokunmadan güncellenebilir.

Tek aramanın yetmediğini gösteren dört işaret

1. İkinci arama birincinin sonucuna bağlıdır. “Bu kredideki kefil hâlâ sağlam mı?” sorusu iki bilgi ister: kefilin kim olduğu sözleşmeden, kefilin güncel durumu da başka bir kaynaktan gelir. Trivedi ve arkadaşları, tek adımlı getir ve oku yaklaşımının çok adımlı sorularda yetersiz kaldığını gözlemledi; çünkü bir sonraki adımda neyin getirileceği, o ana kadar bulunana bağlıdır.
2. Sorunun kelimeleri belgenin kelimeleri değildir. Kullanıcı “geç ödeme kuralı” hakkında soru sorar; politika ise “vadesi geçmiş alacaklar” der. Yanıt dizinde olduğu hâlde arama onu ıskalar. Rewrite-Retrieve-Read yaklaşımındaki gibi sorguyu aramadan önce yeniden yazmak, girdi metni ile bilgi erişiminin ihtiyaç duyduğu bilgi arasındaki bu boşluğu kapatır.
3. Yanıt bir belgede değil, bir sistemdedir. Güncel bakiye, açık bir sipariş, bir makinenin son kalibrasyon tarihi. Hiçbir pasaj bunu içermez. Doğru adım bir araç çağrısıdır: salt okunur bir SQL sorgusu ya da bir API isteği. Sonuç da getirilmiş bir pasaj gibi kaydedilir.
4. Kanıt yanıtı desteklemiyor olabilir. Self-RAG, bir modeli ne zaman bilgi getireceğine karar vermeye ve hem getirilen pasajları hem de kendi çıktısını değerlendirmeye eğitir. Çoğu zaman yeterli olan daha basit bir yol, yanıttaki her iddianın onu destekleyen bir pasaja dayandığını ayrı bir adımda kontrol etmek ve dayanmayan bir iddiada durmaktır.

Bu dördünden hiçbiri işte görünmüyorsa tasarım klasik RAG'dır.

Döngünün bedeli ne?

Her adım bir arama, bir model çağrısı ya da bir araç çağrısı daha demektir. Maliyet adım sayısıyla büyür, gecikme de değişkenleşir: soruların çoğu hızlı bitebilirken birkaçı çok sayıda adım sürebilir.

Denetim izi de uzar. İnceleyen kişinin artık sistemin yazdığı her sorguyu, okuduğu her pasajı ve araç sonucunu, bunları hangi sırayla okuduğunu ve neden durduğunu görmesi gerekir. Bu kayıt olmadan beş adımlı bir döngünün verdiği yanlış yanıtı açıklamak neredeyse imkânsızdır.

Döngülerin kendine özgü hataları da vardır. Yanıt dizinde yokken aramayı sürdürürler. Asıl sorudan uzaklaşırlar. Sorguyu, kullanıcının hiç sormadığı bir şeye dönüştürürler. Her biri için döngü çalışmadan önce bir sınır konmalıdır: en fazla adım sayısı, kanıt eksikse durma ve sınıra ulaşıldığında adı belli bir kişiye giden bir yol.

Bir işin hangisini gerektirdiği nasıl sınanır?

1. Masadan gerçek soruları toplayın ve daha hiçbir şey kurulmadan doğru yanıtı ve kaynağını kurumun uzmanına yazdırın ya da puanlatın.
2. Önce bu sette klasik RAG'ı çalıştırın. Her soru için iki şeyi kaydedin: doğru pasaj geldi mi ve uzman yanıtı kabul etti mi.
3. Hataları gruplara ayırın. Kelime farkı yüzünden ıskalanan soru, sorguyu yeniden yazmaya işaret eder. İkinci bir bilgi gerektiği için ıskalanan soru, çok adımlı aramaya. Bilgi bir sistemde durduğu için ıskalanan soru, bir araç çağrısına. Dayanaksız yanıtlanan soru ise bir kanıt kontrolüne.
4. Yalnızca en büyük hata grubunu düzelten adımı ekleyin, sonra geliştirmede kullanılmayan, kenara ayrılmış sorularda yeniden çalıştırın. Orada kazanç gösterirse adımı tutun; göstermezse çıkarın.
5. İki tür soru da varsa soruya göre yönlendirin. Basit aramalar tek seferlik akıştan geçer; adım gerektiren sorular döngüye girer. Yönlendiricinin kendisi de aynı sette sınanır.

Sonuç çoğu zaman genel amaçlı bir ajan değil, tek bir adım eklenmiş klasik bir veri hattıdır.

Bilgi erişimi neyi asla değiştirmez?

Bilgi erişimi, modelin okuduğu kanıtı değiştirir. Modelin ağırlıklarını değiştirmez; kararı kimin verdiğini de değiştirmez.

Döngünün arayabileceği kaynaklar ve çağırabileceği araçlar, ajanın yazılı çalışma çerçevesinde (harness) tek tek adlandırılır ve varsayılan olarak salt okunurdur. Döngü, bir soru gerektiriyor gibi göründü diye kaynak, araç ya da izin ekleyemez. Politika ve yetki hem modelin hem de dizinin dışında kalır. Kanıt yetmediğinde sistem bunu söyler ve dosya, bulunanlarla ve aramanın nerede durduğuyla birlikte adı belli bir kişiye gider.

Önce gerçek sorulardaki adımları sayın. Tasarım bu sayıdan çıkar.