En basit RAG gösterimi, cevabı bir belgede açıkça bulunan bir soruyla başlar. Arama motoru ilgili bölümü bulur, model bunu kullanıcı dostu bir yanıt haline getirir ve sonuç ikna edici görünür.
Geliştirme aşamasında başka bir sorunun daha yararlı olduğunu düşünüyorum: Bilgi tabanında cevap bulunmadığında ne olur? Bu durum, uygulamanın “benzer bir şey bulmak” ile “yeterli kanıt bulmak” arasındaki farkı anlayıp anlamadığını ortaya koyar.
Yakındaki bir geçit yine de yanlış bir kanıt olabilir
Bir mağazanın genel bir iade politikası olduğunu, ancak belirli bir sipariş üzerine üretilen ürünün iade edilip edilemeyeceğine dair herhangi bir bilgi bulunmadığını varsayalım. Bir arama motoru, yüksek bir benzerlik puanıyla genel politikayı bulabilir. Metin, konuyla ilgili olsa da, mutlaka belirli bir cevabı desteklemiyor olabilir.
İşte bu nedenle, arama sıralamasını cevap verme izni olarak görmüyorum. Başvuru sahibi, soruda ne sorulduğunu, kaynağın gerçekte hangi gerçekleri ortaya koyduğunu ve nelerin hâlâ bilinmediğini dikkate almalıdır.
Lewis ve meslektaşlarının kaleme aldığı orijinal RAG makalesi, içerik üretimi ile geri çağrılan harici belleğin birleştirilmesini ele almaktadır. Müşteriye yönelik bir uygulamada, geri çağrılan bu materyalin ne zaman yeterli olacağına dair ürüne özgü kararlar alınması gerekmektedir.
İş akışını optimize etmeden önce bir değerlendirme kümesi oluşturun
Öncelikle, temsili sorulardan oluşan küçük bir derlemeyle başlıyorum ve beklenen davranışı etiketliyorum. Bu etiket, sadece tercih edilen bir cümleden ibaret değildir. Sistemin yanıt vermesi, açıklayıcı bir soru sorması ya da konuyu bir kişiye devretmesi gerektiğini de içerir.
Cevap verilebilir bir durum söz konusu olduğunda, destekleyici kaynağı ve kabul edilen iddiaları kayda geçiririm. Cevap verilemez bir durum söz konusu olduğunda ise eksik olan unsurları kayda geçiririm. Bu ayrım, değerlendiricilerin bir cevabın neden kabul edildiği veya reddedildiği konusunda fikir birliğine varmalarına yardımcı olur.
- Tek bir kaynakta doğrudan cevabı bulunan bir soru.
- Kaynak metindeki ifadenin yerine eşanlamlı bir kelime kullanılan bir soru.
- Katalogda bulunmayan bir ürünle ilgili bir soru.
- Belgelerde yer almayan bir politika istisnası gerektiren bir soru.
- “Daha büyük olan” gibi belirsiz bir ifade içeren bir soru.
- Sadece güncelliğini yitirmiş bir belgeyle desteklenen bir soru.
Zor ama makul ifadeler kullanıyorum. Yapay saçmalıklar kolayca reddedilebilir ve gerçekçi ancak dayanağı olmayan sorular hakkında pek bir şey ifade etmez.
Cevap hatalarını, veri alma hatalarından ayırın
Doğru kaynak hiçbir zaman bulunamamışsa, yanıt istemini değiştirmek altta yatan sorunu çözmeye pek yardımcı olmayacaktır. Kaynak bulunmuş ancak yanıtta bir koşul uydurulmuşsa, kaynak bulma aşaması düzgün çalışıyor olabilir.
Bu nedenle, aday seçimi, sıralama, kanıt yeterliliği ve nihai sonucun oluşturulmasını ayrı ayrı inceliyorum. Tek bir genel doğruluk değeri, iyi sonuçlar veren ancak kanıtlarını sıklıkla abartan bir sistemi gizleyebilir.
Eşikler, gerçek metin külliyatı ve sorgu dağılımına göre ayarlanmalıdır. Benzerlik puanı, evrensel bir güven yüzdesi değildir. Uygun karar sınırı, genel bir açıklayıcı soru ile fiyat veya garanti hakkındaki bir talep arasında da farklılık gösterebilir.
Belirsizliği müşterinin yararına çevirin
İyi bir “cevap verememe” durumu, eksik bilgileri açıklar ve bir sonraki adımı önerir. Ürün çeşidi net değilse, çeşidi sorunuz. İlgili politika yoksa, soruyu konuyla ilgili bilgiye sahip bir kişiye yönlendirin.
Sistem neye ihtiyaç duyduğunu tam olarak ifade edebiliyorsa, “Bu konuda yardımcı olamam” gibi belirsiz ifadelerden kaçınırım. Amaç, gerçekleri uydurmaktan kaçınırken müşteri deneyimini korumaktır.
Değerlendirme sırasında, desteklenmeyen yanıtları gereksiz çekimser oylarından ayrı olarak takip ediyorum. Her yanıtı “yararsız” olarak nitelendirerek bir tanesini azaltmak, yararlı bir iyileştirme değildir. Sistemin, kanıtların yeterli olduğu durumlarda yanıt vermesi ve yeterli olmadığı durumlarda bunu fark etmesi gerekir.
Olumsuz bir test kümesi, bu sınıra somut bir şekil kazandırır. “Asistanın dikkatli olması gerekir” ifadesini, mühendislik ekibinin her anlamlı arama veya komut değişikliğinden sonra uygulayabileceği örnekler haline getirir.
25 Eylül 2026 tarihinde güncellenmiştir.