RAG sisteminin kalitesini ölçmek: test seti, metrikler ve hata ayıklama

RAG değerlendirmesi neden erişim ve üretimi ayrı ele alır?

Bir RAG sistemi ardışık aşamalardan oluşur: önce ilgili parçaları bulur, sonra bu parçalara dayanarak cevap üretir. Kullanıcı kötü bir cevap aldığında hata bu aşamalardan herhangi birinde olabilir. Doğru belge hiç bulunmamış olabilir, bulunmuş ama sıralamada geride kalmış olabilir ya da doğru bağlam modele verilmiş olduğu halde model onu görmezden gelip kendi bildiğini yazmış olabilir.

Bu yüzden değerlendirmenin ilk kuralı, tek bir "cevap iyi mi" puanıyla yetinmemektir. Erişim kalitesi ve üretim kalitesi ayrı ölçülür. Erişim tarafında soru şudur: Cevap için gereken bilgi getirilen parçaların içinde var mı ve gereksiz parça az mı? Üretim tarafında soru şudur: Cevap yalnızca getirilen bağlama dayanıyor mu ve kullanıcının sorusunu gerçekten yanıtlıyor mu? Taraflar ayrı puanlandığında bir kalite düşüşünün kaynağı da görünür hale gelir.

Değerlendirme veri kümesi nasıl hazırlanır?

Metrik seçmeden önce sorulacak şey, neyin üzerinde ölçüm yapılacağıdır. Değerlendirme veri kümesi, gerçek kullanıcıların soracağı soruları temsil etmelidir. En sağlam kaynak canlı sistemdeki gerçek sorgulardır; henüz canlı kullanım yoksa konu uzmanlarından, destek ekibinin sık gelen taleplerinden ya da dokümanların kendisinden türetilen sorular kullanılır.

Her örnek en az soruyu, beklenen cevabı ve cevabın dayandığı kaynak parçayı içerir. Veri kümesi şu soru türlerini kapsamalıdır:

• Tek parçada cevabı bulunan basit olgu soruları
• Birkaç belgeden bilgi birleştirmeyi gerektiren sorular
• Dokümanlarda cevabı olmayan sorular; sistemin "bilmiyorum" diyebildiğini sınar
• Eski ve yeni sürümleri çelişen politika soruları
• Yazım hatalı, kısaltmalı ya da belirsiz gerçek kullanıcı ifadeleri

Soruları dokümandan model ile otomatik üretmek hızlı bir başlangıçtır, ama üretilen setin bir kısmını insan gözüyle gözden geçirmek gerekir. Aksi halde sistem, kendi ürettiği kolay sorularda yüksek puan alıp gerçek hayatta başarısız olabilir. Veri kümesi bir kez yazılıp bırakılmaz; üretimde yakalanan her yeni hata türü sete eklenir.

Erişim kalitesi hangi metriklerle ölçülür?

Erişim ölçümünün amacı, doğru bilginin getirilen parçalar arasında olup olmadığını görmektir. RAGAS dokümantasyonu bu alanda Context Precision ve Context Recall metriklerini listeler. Context Precision, getirilen parçaların ne kadarının soruyla gerçekten ilgili olduğunu ve ilgili olanların listenin üst sıralarında yer alıp almadığını sorar. Context Recall ise cevap için gereken bilginin getirilen bağlamda ne kadar bulunduğuna bakar.

Klasik bilgi erişimi metrikleri de aynı amaç için kullanılabilir. Recall@k, doğru parçanın ilk k sonuç içinde olup olmadığını gösterir. MRR doğru parçanın ortalama kaçıncı sırada geldiğini, NDCG ise sıralama kalitesini ilgililik derecelerini hesaba katarak ölçer. Bunların avantajı, her soru için hangi parçanın doğru olduğunu etiketlediğiniz bir veri kümesiyle çalışınca model çağrısı gerektirmeden hızlı ve tekrarlanabilir sonuç vermesidir.

Bu aşamada elde edilen sonuç doğrudan müdahale yeri gösterir. Recall düşükse sorun parçalamada, embedding modelinde ya da arama yönteminde aranır. Precision düşükse getirilen parça sayısı fazladır ve yeniden sıralama ya da metadata filtreleme devreye girebilir.

Üretim kalitesi: cevap bağlama sadık mı, soruya uygun mu?

Üretim tarafında temel sorular öne çıkar. Sadakat bunlardan biridir: RAGAS'ın Faithfulness metriği, cevaptaki ifadelerin getirilen bağlamla desteklenip desteklenmediğine bakar. Bağlamda olmayan ama cevapta yer alan her iddia, uydurma riskinin işaretidir. Diğeri ilgidir: Response Relevancy, cevabın sorulan soruyla ne kadar örtüştüğünü ölçer. Bağlama sadık ama soruyu yanıtlamayan bir cevap da başarısızdır.

Bu metrikler genellikle bir büyük dil modelinin değerlendirici olarak kullanılmasıyla hesaplanır. Yani cevap, parçalarına ayrılır ve her iddia için bağlamda dayanak aranır. Bu yaklaşım ölçeklenebilir, ama değerlendirici modelin kendisi de hata yapabilir. Bu nedenle değerlendiriciyi insan etiketleriyle kalibre etmek gerekir: Belirli sayıda örneği insanlara puanlatın, otomatik puanla karşılaştırın ve uyumsuz örnekleri inceleyin. Uyum zayıfsa değerlendirici talimatı ya da modeli değişmelidir.

Bir ek ölçüt de "cevaplamama" davranışıdır. Dokümanlarda cevabı olmayan sorularda sistemin kaynak uydurmak yerine bilgi bulamadığını söylemesi ayrıca puanlanmalıdır.

Örnek akış: düşen kalitenin kaynağını bulmak

Örneğin bir şirketin iç politika asistanı, izin kuralları sorulduğunda zaman zaman eski sürüm bir politikaya göre cevap veriyor olsun. Değerlendirme akışı şöyle işler.

Önce şikayet edilen sorular veri kümesine eklenir ve her biri için doğru kaynak parça etiketlenir. Sonra erişim metrikleri çalıştırılır: Doğru parça getiriliyorsa sorun erişimde değildir. Getirilmiyorsa belge güncelleme ve dizinleme sürecine bakılır; eski sürüm silinmemiş olabilir. Doğru parça getirilip de cevap yine yanlışsa Faithfulness puanı incelenir; model, bağlamdaki eski ve yeni metin çelişkisinde yanlış olanı seçmiş olabilir.

Çözüm de teşhise göre değişir: Eski sürüm dizinden kaldırılır, belge metadata alanına sürüm ve geçerlilik tarihi eklenir, getirme sırasında filtre uygulanır. Ardından aynı veri kümesi yeniden çalıştırılıp düzeltmenin diğer sorulara zarar vermediği doğrulanır. Bu karşılaştırma yapılmadan yapılan her ayar, bir yerde düzeltirken başka yerde bozma riski taşır.

Değerlendirmeyi sürekli çalışan bir sürece dönüştürmek

Tek seferlik ölçüm, sistemin o günkü durumunu gösterir. RAG sistemlerinde ise veri, doküman ve model sürekli değişir. Değerlendirme bu yüzden otomatik bir kapıya dönüştürülür: Parçalama ayarı, embedding modeli, arama yöntemi, istem şablonu ya da üretici model her değiştiğinde aynı veri kümesi koşturulur ve sonuçlar önceki sürümle yan yana raporlanır. Belirlenen eşiğin altına düşen değişiklik yayına alınmaz.

Canlı sistemde ise sinyal kaynağı kullanıcı davranışıdır: Olumsuz geri bildirim verilen cevaplar, tekrar sorulan sorular ve insana devredilen konuşmalar, sete eklenecek yeni zor örneklerdir. Sorgu, getirilen parçalar, cevap ve kullanılan sürüm bilgileri kayıt altına alınırsa bir hata sonradan da incelenebilir.

Sık yapılan hatalar şunlardır:

• Yalnızca cevap kalitesine bakıp erişimi ölçmemek
• Değerlendirici modeli hiç kalibre etmeden puana güvenmek
• Çok küçük ve hep kolay sorulardan oluşan bir set kullanmak
• Aynı seti ayar yaparken de, son testte de kullanıp aşırı uyum üretmek
• Maliyet ve gecikmeyi kalite tablosunun dışında tutmak

Bu beceriyi Mindset programlarında nerede çalışırsınız?

Mindset kataloğunda RAG kalitesine doğrudan değinen eğitimler var. Retrieval-Augmented Generation (RAG) Sistemleri eğitiminin modülleri arasında "RAG Boru Hattı Değerlendirmesi" ve "Gelişmiş Geri Alma ve Yeniden Sıralama" yer alır. LLM Değerlendirme ve Karşılaştırma (Evals) eğitimi ise test seti tasarımı, puanlayıcı tasarımı, karşılaştırmalı değerlendirme ve sürekli değerlendirme otomasyonu modüllerinden oluşur.

Bu içerik, RAG ya da LLM tabanlı ürün geliştiren yazılım ve veri ekipleri için uygun bir çerçevedir; kurumsal ekiplerde ürün sahibi, kalite güvence ve veri bilimi rollerinin aynı ölçüm diliyle çalışmasına da zemin sağlar.