RAG Değerlendirmesi: LLM'yi Ayarlamadan Önce Retrieval'ı Test Etme

RAG değerlendirmesi retrieval ile başlamalıdır. Eğer doğru kanıt modele ulaşmazsa, prompt ayarlamaları ve model yükseltmeleri yalnızca yanlış bağlamı daha ikna edici hale getirir. Retrieval, generation ve operations'ı ayrı aşamalar olarak test edin. Herhangi bir aşama kötüleştiğinde başarısız olan küçük, versiyonlu bir regresyon seti tutun.

Okuyucu seviyesi: Orta. Bu kılavuz, retrieval-augmented generation veya RAG'ın, bir dil modeline cevap vermeden önce belgeleri bulduğunu bildiğinizi varsayıyor.

Bu kılavuzda

RAG değerlendirmesi üç ayrı başarısızlık yüzeyine sahiptir

Bir RAG uygulaması bir boru hattıdır. Nihai cevap için bir puan, hangi bileşenin çalışmaya ihtiyaç duyduğunu gizler.

Sıralama önemlidir. Retrieval yukarı akıştadır. Bir jeneratör, bağlamına hiç girmemiş bir politika paragrafını alıntılayamaz ve akıcı bir cevap, retriever'ın çalıştığını kanıtlamaz.

Microsoft'un mevcut RAG değerlendirici belgeleri uygulama terimleriyle aynı ayrımı yapmaktadır. Sıralı kanıtlar için belge-retrieval ölçümleri sağlar, ardından cevap katmanında groundedness, relevance ve yanıtın tamlığını değerlendirir. Belge-retrieval değerlendiricisi, sadakat, NDCG, XDCG, maksimum relevance ve eksik relevance yargılarını içerir.

_Kullanışlı bir RAG puan kartı, retrieval, generation ve operasyonel kontrolleri ayrı katmanlar olarak görünür tutar._

Neden bir uçtan uca puanın zayıf hata ayıklama kanıtı sunduğu

Birçok araştırma çerçevesi, farklı yönlerden aynı pratik sonuca ulaşmaktadır.

RAGChecker, retriever ve generator davranışını ayrı ayrı değerlendirir. Yazarları, on alan boyunca sekiz RAG sistemini karşılaştırdı. Metrikleri, retrieval için claim recall ve context precision'ı, generation için ise context utilization, noise sensitivity, hallucination ve faithfulness'ı içerir. 280 çiftlik bir meta-değerlendirmede, RAGChecker'ın genel değerlendirme puanı, insan tercihi ile 0.609 Spearman korelasyonu gösterdi. İki insan annotatörü 0.689'a ulaştı. Otomatik değerlendirme faydalıydı, ancak insan farkını ortadan kaldırmadı.

Ragas, faithfulness, answer relevance ve context relevance için referanssız ölçümler önerdi. WikiEval karşılaştırmalarında, insan tercihlerine uyum, faithfulness için 0.95, answer relevance için 0.78 ve context relevance için 0.70 idi. Yazarlar, context relevance'ı yargılamanın en zor olduğunu buldular. Bu rakamları, o çalışmadan elde edilen sonuçlar olarak değerlendirin, her yargıç, veri seti veya alan için evrensel doğruluk oranları olarak değil.

Daha yeni bir çerçeve olan RAGe, bileşen seçimi ve donanım telemetresi ekler. Chunking, embedding, retrieval, storage ve generation boyunca boru hattı yapılandırmalarını değerlendirirken, gecikme veya VRAM sınırlarını aşan kombinasyonları budar. Makale varsayılan olarak Natural Questions, NewsQA ve TriviaQA kullanır ve özel CSV veya JSON veri setlerini destekler. Ana katkısı, kaliteyi kaynak kısıtları ile karşılaştırmanın bir yoludur; her alan için kazanan bir yapılandırma belirlemez.

Birlikte, bu makaleler tanısal bir yaklaşımı destekler. Belirli bir metriğin veya kütüphanenin üretim için yeterli olduğunu kanıtlamazlar.

Metrikleri seçmeden önce bir test seti oluşturun

Hizmet ettiğiniz alandan 40 ila 60 soru ile başlayın. Bu aralık, istatistiksel bir yasa değil, pratik bir başlangıç noktasıdır. Birçok başarısızlık türünü açığa çıkarmak için yeterince büyük ve her önemli değişiklikten sonra bir insanın gözden geçirmesi için yeterince küçüktür.

En az beş sorgu sınıfı dahil edin:

Üretim günlükleri soruları önerebilir, ancak örnekleri bir değerlendirme setine eklemeden önce kişisel verileri ve sırları kaldırın. Yakın tarihli bir üretim RAG değerlendirmesi hakkında uygulayıcı tartışması da sabit sorguları, versiyonlu yapılandırmaları ve ayrı retrieval ve generation kontrollerini vurgular. Bu tartışma, iş akışı acısı hakkında anekdot niteliğinde bir kanıt olup, yaklaşımın her sistemde çalıştığını kanıtlamaz.

Yargıları, kopyalanmış metinle birlikte sabit belge kimliklerine karşı saklayın. Bir splitter'ı ayarladığınızda chunk sınırları değişir. Bir kanonik kaynak kimliği, aynı testin bu değişimi aşmasına olanak tanır.

{ "query_id": "refund-window-01", "query": "Müşterinin açılmamış bir ürünü iade etmesi için ne kadar süresi var?", "relevant_document_ids": ["returns-policy-v4"], "required_claims": ["Açılmamış ürünler 30 gün içinde iade edilebilir."], "must_abstain": false, "allowed_roles": ["customer", "support"], "as_of": "2026-07-01" }

Cevapsız bir durum için, `relevant_document_ids`'i boş bir listeye ve `must_abstain`'i `true` olarak ayarlayın. Kısıtlı bir durum için, aynı sorguyu iki rol altında çalıştırın. Yetkili kullanıcı belgeyi almalıdır; yetkisiz kullanıcı, belgenin içeriğini öğrenmemelidir.

Kendi corpus ve uygulama katmanını oluşturan ekipler, test seti ile birlikte içerik sözleşmesini versiyonlamalıdır. Aynı kural, Next.js ve AI ile oluşturulan özel veri sistemleri için de geçerlidir: bir şema veya içerik değişikliği, prompt'a dokunmadan retrieval'ı değiştirebilir.

Adım 1: Cevap üretmeden retrieval'ı değerlendirin

Her sorguyu retriever üzerinden çalıştırın ve sıralı sonuç kimliklerini, puanları, zaman damgalarını ve erişim kararlarını kaydedin. Henüz dil modelini çağırmayın.

Kanıt şekliyle eşleşen metrikleri seçin

Bir doğru belgenin yeterli olduğu durumlarda hit rate@k kullanın. Bu, en az bir ilgili kaynağın ilk `k` sonuçta görünüp görünmediğini sorar.

Cevap birden fazla kaynağı gerektiriyorsa recall@k kullanın. Bu, bilinen ilgili belgelerin ilk `k` içinde kaçının göründüğünü ölçer.

Alakasız bağlamın pahalı veya dikkat dağıtıcı olduğu durumlarda precision@k kullanın. Yüksek recall ile düşük precision, jeneratörü gürültü ile doldurabilir.

İlk ilgili sonucun en önemli olduğu durumlarda MRR kullanın. Birden fazla derecelendirilmiş sonucun faydalı bir sırada görünmesi gerektiğinde NDCG kullanın. Microsoft, değerlendiricisinde NDCG ve ilgili sıralı-retrieval ölçümlerini belgelerken, RAGChecker, alınan kanıtları bir cevabın ihtiyaç duyduğu iddialara bağlamak için claim recall ve context precision kullanır.

Her metriği varsayılan olarak toplamayın. Bir kapsama ölçüsü ve bir sıralama veya gürültü ölçüsü seçin. Bir metriği yalnızca bir kararı değiştirdiğinde ekleyin.

Modeli değiştirmeden önce kaçırılanları sınıflandırın

Retrieval hataları genellikle küçük bir küme içine düşer:

Her hatanın farklı bir sahibi vardır. Yeniden embedding, kaybolan bir belgeyi onaramaz. Daha büyük bir dil modeli, bir izin filtresini onaramaz. Bir reranker, kanıt mevcut ancak kötü sıralandığında yardımcı olabilir.

Araç bağlantılı uygulamalar için, retrieval isteğini, filtreleri, sonuç kimliklerini ve araç yanıtını izleme kaydında saklayın. Bu, MCP geliştirici iş akışlarında tanımlanan daha geniş kontrol desenine uyar: sözleşmeyi, durum geçişini ve nihai metni inceleyin.

Adım 2: Sabit kanıtlar üzerinden generation'ı değerlendirin

Retrieval eşiğine ulaştığında, alınan bağlamları dondurun ve bunları jeneratörle tekrar oynatın. Bu, prompt veya model değişikliklerini indeks değişikliklerinden izole eder.

Dört davranışı ölçün:

Tamlık için referans bir cevap yardımcı olabilir. Tek doğru kaynağı olarak daha az faydalıdır çünkü birkaç ifade biçimi doğru olabilir. Mümkünse gerekli iddiaları ve destekleyici belge kimliklerini saklayın.

Kasıtlı olarak eksik bir bağlamla ikinci bir generation testi çalıştırın. Güvenilir bir sistem, bellek boşluklarını doldurmak yerine belirsizliği açığa çıkarmalıdır. Bu, corpus özel, değişen veya özel alan bilgilerini içerdiğinde önemlidir.

Model seçimi hala cevap kalitesini, gecikmeyi ve maliyeti etkiler, ancak retrieval kanıtından sonra gelir. Aynı sabit bağlam, jeneratörler arasında başarısız olursa, model ve API ticaretlerini karşılaştırın. Eğer bağlamın kendisi yanlıştıysa, jeneratörü değiştirmek boşa harcanmış bir çabadır.

Retrieval setine güvenlik ve çelişki durumları ekleyin

Sıradan relevance testleri, düşmanca veya çelişkili kanıtları kaçırır.

Temmuz 2026'da yayımlanan bir makale, RAG'da polymorphic sybil zehirlenmesi, aynı saldırgan tarafından seçilen cevabı destekleyen kelime olarak farklı pasaj gruplarını test etti. Makalenin zorunlu maruz kalma ayarında, polymorphic pasajlar %22.8'lik bir ele geçirme oranı üretirken, tekrarlanan monomorphic pasajlar için %4.0'lık bir oran üretti. Token-overlap filtreleme, tüm monomorphic kümeleri yakaladı ve hiçbir polymorphic kümeyi yakalayamadı.

Sonuç, bu saldırının üretimde ne sıklıkla başarılı olduğunu ölçmez. Yazarlar, okuyucu davranışını izole etmek için alınan karışımı altı saldırı pasajı, iki altın pasaj ve iki dolgu ile sabitlediler. Ayrıca bir saldırı sınıfı, veri seti kontaminasyonu riski, 500 soruluk bir ablation ve LLM tabanlı doğrulama ile ilgili sınırlamaları rapor ederler.

Faydalı değerlendirme dersi daha dar: "doğru" ve "saldırgan hedef"ten daha fazlasını sınıflandırın. Makale dört sonucu izler:

Kendi setinize çelişki durumları ekleyin. Farklı ifadelerle çoğaltılmış iddiaları, mevcut politikayı çelişen eski bir kaynağı ve otoriter bir kaynakla çelişen daha düşük güvenilir bir kaynağı dahil edin. Sistem cevap verip vermediğini, abstain edip etmediğini veya kayıp yaşayıp yaşamadığını kaydedin.

LLM yargıçlarını puanlarına güvenmeden önce kalibre edin

LLM yargıçları, özellikle groundedness ve claim coverage için regresyon testlerini daha ucuz hale getirir. Promtlar, model versiyonları, ayrıştırma davranışı ve bilinen kör noktalarla yazılım bağımlılıkları olarak kalırlar.

Dört kontrol kullanın:

Ragas ve RAGChecker çalışmaları, kalibrasyonun neden önemli olduğunu gösterir. Anlaşma boyuta göre değişir ve otomatik korelasyonlar insan anlaşmasının altında kalır. Sayısal bir puan, incelemeyi tetiklemeli, sonlandırmamalıdır.

Mevcut açık kaynak sürümleri, değerlendiriciler etrafında aktif çalışmaları da göstermektedir. DeepEval 4.1.3, 12 Temmuz 2026'da yayımlandı ve ajan döngüleri ve araç izinleri için deterministik kontroller eklerken Ragas entegrasyonunu düzeltti. TruLens 2.9.0, 23 Temmuz'da yayımlandı ve yargıç toplulukları, A/B kriter testleri, puan dağılımı analizi ve altın set üretimi ekledi. Sürüm etkinliği, sürdürülen mühendislik çalışmasının bir kanıtıdır, ancak bu kütüphanenin yığınınız için doğru seçim olduğunu kanıtlamaz.

Minimal bir RAG regresyon iş akışı

Her önemli boru hattı değişikliği için aynı sıralamayı kullanın:

Kompakt bir sonuç kaydı şöyle görünebilir:

{ "run_id": "rag-2026-07-26-b", "test_set": "support-v7", "corpus_snapshot": "2026-07-25T22:00:00Z", "retrieval": { "recall_at_5": 0.91, "ndcg_at_5": 0.84, "unauthorized_hits": 0 }, "generation": { "grounded_pass_rate": 0.94, "complete_pass_rate": 0.87, "abstention_pass_rate": 0.90 }, "operations": { "p95_ms": 1380, "cost_per_query_usd": 0.0042 } }

Bu rakamlar örnektir. Eşikleri risk, temel ve hata maliyetinize göre ayarlayın. Bir tıbbi bilgi asistanı ve bir ürün arama yardımcısı aynı sürüm kapısını paylaşmamalıdır.

Başarısız katmandan düzeltmeyi belirleyin

Bu tablo, RAG değerlendirmesinin noktasıdır: başarısız bir puan, bir sonraki deneyi belirlemelidir. Eğer belirleyemezse, metrik, değiştirmeniz gereken bileşenden çok uzaktır.

Kanıtların desteklediği şeyler

Makaleler belirli sistemleri ve veri setlerini ölçtü. RAGChecker, modüler metriklerin insan tercihlerine korele olabileceğini ve retriever-generator ticaretlerini açığa çıkarabileceğini buldu. Ragas, yargıç anlaşmasının faithfulness, answer relevance ve context relevance arasında değiştiğini buldu. RAGe, kalite metriklerini gecikme ve bellek kısıtları ile birleştiren bir çerçeve gösterdi. Zehirleme benchmark'ı, bir kısıtlı saldırı ayarının belirgin ele geçirme, abstention ve kayma desenleri ürettiğini gösterdi.

Kanıtlar evrensel eşikler, evrensel en iyi değerlendirici veya üretim saldırı yaygınlığı kurmaz. Pratik yorumum, aşamaları ayırmak, insan kalibreli bir dilim tutmak ve her metriğin mühendislik eylemine işaret etmesini gerektirmektir.

İddia kontrolleri

Kaynaklar