RAG (retrieval-augmented generation), bir dil modelinin yanıt üretmeden önce seçilmiş kaynaklardan bağlam almasını sağlar. Bu yaklaşım, modelin yalnızca genel eğitim verisine dayanmasına göre daha güncel ve alan odaklı cevaplar üretebilir. Ancak önemli bir ayrım vardır: Bir yanıtın yanında kaynak parçası bulunması, o yanıtın gerçekten kaynak tarafından desteklendiği anlamına gelmez.
Bir ürün kullanıcısı için fark büyüktür. “Model bir belge buldu” ile “Bu cümle belgenin şu bölümüne dayanıyor” aynı güven düzeyi değildir. Özellikle hukuk, eğitim, finans, sağlık veya kurumsal bilgi gibi hatanın maliyetli olduğu alanlarda RAG özelliğinin hedefi yalnızca cevap vermek değil; her önemli iddia için denetlenebilir dayanak sunmak olmalıdır.
Retrieval, kanıt değildir
Retrieval katmanı sorguya yakın metin parçalarını aday olarak getirir. Bu adaylar doğru olabilir; fakat bağlamdan kopmuş, eski, eksik veya soruyla yalnızca yüzeysel olarak ilişkili de olabilir. Benzerlik puanı, metnin yanıtı kanıtladığının değil, sorguya dilsel olarak yakın olduğunun bir işaretidir.
Bu nedenle tasarımın ilk ilkesi şudur: getirilen her parça bir kanıt adayıdır. Model, bu parçadan cevap üretirken metnin açıkça söylemediği sonucu kesin bilgi gibi sunmamalıdır. Yeterli dayanak yoksa sistemin “bunu doğrulayacak kaynak bulamadım” diyebilmesi, daha uzun fakat belgesiz bir yanıttan değerlidir.
Kaynak verisini ürün sözleşmesi gibi ele alın
Doğrulanabilir yanıt, model çağrısından önce başlar. Her belge parçasının yalnızca metni değil, onu yeniden bulmayı sağlayan bağlamı da saklanmalıdır. Asgari olarak şu alanlar faydalıdır:
- belge kimliği, başlığı, sürümü ve yürürlük tarihi,
- bölüm, sayfa veya madde gibi insanların anlayacağı konum bilgisi,
- metin aralığı ya da alıntının tam başlangıç-bitiş noktası,
- kaynak türü ve erişim yetkisi,
- indeksleme zamanı ve önceki sürümle ilişkisi.
Bu metadata, kaynak kartını göstermek için olduğu kadar güvenlik için de gereklidir. Kullanıcının görmeye yetkili olmadığı bir belge, retrieval sonucunda görünse bile yanıta veya alıntı listesine sızmamalıdır. RAG katmanı, uygulamanın mevcut kimlik ve yetkilendirme modelinin dışında çalışan bir arka kapı olmamalıdır.
Alıntıyı cümle düzeyinde bağlayın
Bir yanıtta en sona beş bağlantı koymak, okuyucunun hangi iddianın hangi metne dayandığını anlamasına yetmez. Daha iyi yaklaşım, doğrulanabilir her önemli cümleyi veya maddesini kaynak kimliğiyle ilişkilendirmektir.
Örneğin sistem bir politika hakkında üç sonuç sıralıyorsa, her sonucun yanında ilgili belge bölümü açılabilmelidir. Bu bağ iki unsurdan oluşur: modelin döndürdüğü iddia ve onu desteklediği kabul edilen özgün metin parçası. Kullanıcı alıntıyı açtığında, yalnızca belge adına değil; mümkünse tam paragraf ve konum bilgisine ulaşmalıdır.
Prompt bu davranışı teşvik edebilir: modelden yalnızca sağlanan bağlamdaki bilgileri kullanması, kaynakta olmayan ayrıntıları tahmin etmemesi ve desteklenmeyen sorularda ret vermesi istenebilir. Ancak prompt tek başına güvenlik mekanizması değildir. Çıktı yapısı da bunu zorlamalıdır: her iddia için sourceId, metin aralığı ve güven durumu gibi alanlar tanımlı olmalıdır.
İkinci bir doğrulama adımı ekleyin
Modelin eklediği alıntı da hatalı olabilir. Bu yüzden yüksek riskli kullanımlarda üretimden sonra bağımsız bir doğrulama yapılmalıdır. Doğrulayıcı; iddiayı, alıntılanan metni ve gerekirse daha geniş belge bağlamını birlikte değerlendirir.
Amaç edebî bir benzerlik ölçmek değildir. Basit soru şudur: Bu kaynak, bu iddiayı gerçekten destekliyor mu? Destek yoksa sistem üç seçenekten birini kullanabilir: iddiayı kaldırmak, daha temkinli bir dille yeniden yazmak veya kullanıcıya yeterli kanıt bulunmadığını söylemek.
Bu ayrım, “alıntı kapsama oranı” ve “alıntı doğruluğu” gibi ölçümleri mümkün kılar. İlk metrik, önemli iddiaların ne kadarının kaynağa bağlı olduğunu; ikincisi ise bağlı kaynakların gerçekten uygun olup olmadığını izler. Yalnızca yanıt memnuniyetini ölçmek, bu hataları görünmez bırakabilir.
Ret ve belirsizlik, ürün özelliğidir
RAG sistemleri çoğu zaman boş ya da zayıf bir retrieval sonucunu ikna edici bir paragrafla gizlemeye çalışır. Bunun yerine ürün akışı farklı durumları açıkça ayırmalıdır:
- Hiç ilgili kaynak yoksa, sistem cevap vermemelidir.
- Kaynaklar kısmi ise, desteklenen kısım ve bilinmeyen kısım ayrı yazılmalıdır.
- Belgeler çelişiyorsa, çelişki saklanmamalı; sürüm, tarih veya kapsam farkı gösterilmelidir.
- Kaynak eskiyse, yanıtın güncellik sınırı kullanıcıya açıkça belirtilmelidir.
Bu yaklaşım kısa vadede daha az “kesin” cevap üretiyor gibi görünür. Uzun vadede ise kullanıcıya sistemin sınırlarını öğretir ve güveni rastgele özgüvenden daha sağlam bir zemine taşır.
Kullanıcı deneyiminde kanıtı görünür kılın
Kaynaklar ayrı bir teknik ekrana gizlenmemelidir. Yanıt içindeki numaralar, açılır alıntılar, bölüm bağlantıları ve belge sürümü bilgisi kullanıcıyı denetim yoluna davet eder. Fakat arayüzü bağlantı yığınına çevirmemek de önemlidir: yalnızca karar vermeyi etkileyen iddialara alıntı eklemek, okunabilirliği korur.
Ekip tarafında ise her yanıt için retrieval sorgusu, seçilen parçalar, model sürümü, kullanılan prompt sürümü ve doğrulama sonucu izlenebilmelidir. Bir kullanıcı “bu sonucu neden aldım?” diye sorduğunda, yalnızca son metni değil, bu metne giden zinciri de görebilmek gerekir.
Küçük ve ölçülebilir başlayın
Bütün bilgi tabanını bir anda RAG’a bağlamak yerine, önce dar ve iyi tanımlı bir kullanım alanı seçmek daha güvenlidir. Yirmi örnek sorudan oluşan bir değerlendirme seti; doğru kaynak, yanlış kaynak, kısmi kaynak ve hiç kaynak olmayan durumları içermelidir. Her sürümde aynı seti çalıştırmak, retrieval veya prompt değişikliğinin kaliteyi nasıl etkilediğini görünür kılar.
Güvenilir RAG, daha uzun cevap üretmekle ilgili değildir. Kaynağın söylediğiyle modelin söylediği arasındaki mesafeyi azaltmakla ilgilidir. Kanıtı veri modeline, çıktı şemasına, doğrulama adımına ve arayüze birlikte yerleştiren ürünler, cevabın yanında kullanıcıya kontrol edebileceği bir gerekçe de verir.