Cevaplamaması Gereken Sorularla Bir RAG Sistemi Başlatın

Bir arama sistemi, yanıt verebilmek için kanıtlara ve eksik kanıtlar için önceden belirlenmiş bir yoluna ihtiyaç duyar. Olumsuz örnekler, bu sınırın ölçülebilir olmasını sağlar.

En basit RAG uygulaması, 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 söz konusu cevabı desteklemiyor olabilir.

İşte bu nedenle, arama sıralamasını cevap verme izni olarak görmüyorum. Uygulama, sorunun neyi sorduğunu, kaynağın gerçekte hangi gerçekleri ortaya koyduğunu ve nelerin hâlâ bilinmediğini dikkate almalıdır.

Orijinal metin Lewis ve arkadaşlarının RAG makalesi Bu, içerik üretimi ile dış bellekten alınan verilerin birleştirilmesini açıklamaktadır. Müşteriye yönelik bir uygulamada, alınan bu materyalin ne zaman yeterli olacağına dair ürüne özgü kararların alınması hâlâ gereklidir.

İş 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 cevap 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ı kaydederim. Cevap verilemez bir durum söz konusu olduğunda ise eksik olan unsurları kaydederim. 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 yanıtı bulunan bir soru.
  • Kaynak metindeki ifade yerine bir eşanlamlı kelime kullanılan bir soru.
  • Katalogda yer almayan 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 elde edilmediyse, yanıt istemini değiştirmek temel sorunu çözmeye pek yardımcı olmayacaktır. Kaynak elde edilmişse ancak yanıt bir koşul uydurmuşsa, kaynak elde etme aşaması doğru şekilde ç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ık sık 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 verilemedi" yanıtı, eksik bilgileri açıklar ve bir sonraki adımı önerir. Ürün çeşidi net değilse, çeşidi sorun. İlgili politika yoksa, soruyu konuyla ilgili bilgiye sahip bir kişiye yönlendirin.

Sistem neye ihtiyacı olduğ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 çekimserliklerden ayrı olarak takip ediyorum. Her yanıtı “yardımcı olmayan” olarak değerlendirerek 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 dikkatli olmalı” 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.