# RAG sistemi nasıl değerlendirilir?

> Bir RAG sistemi iki ayrı katmanda değerlendirilir: doğru belge parçalarını bulup bulmadığı (getirme, retrieval) ve bulduğu parçalara sadık, soruya uygun bir cevap yazıp yazmadığı (üretim). Bunun için gerçek sorulardan oluşan bir test seti, her katmana uygun metrikler ve canlıda geri bildirim döngüsü gerekir. Tek bir genel doğruluk puanı, hatanın nerede olduğunu göstermez.

URL: https://corrplus.net/tr/blog/rag-degerlendirme/
Güncellendi: 2026-10-26
Corrplus Ekibi

## RAG değerlendirmesi neden iki katmanlıdır?

RAG değerlendirmesi, bir sistemin önce doğru bilgiyi bulup bulmadığını, sonra o bilgiyle doğru cevap yazıp yazmadığını ayrı ayrı ölçen test sürecidir. Ragas makalesi de değerlendirmeyi bu boyutlara ayırır: getirme sisteminin ilgili ve odaklı parçaları bulması, modelin bu parçaları sadakatle kullanması ve cevabın genel kalitesi.

Ayrım önemlidir çünkü düzeltme yolu farklıdır. Yanlış parça geliyorsa sorun parçalama, [embedding](/tr/sozluk/embedding-nedir/) modeli, [vektör veritabanı](/tr/sozluk/vektor-veritabani-nedir/) sorgusu veya yeniden sıralamadadır. Doğru parça geldiği halde cevap yanlışsa sorun istem, model veya cevap biçimindedir. Tek bir "doğru/yanlış" puanı bu iki durumu birbirinden ayıramaz.

RAG'in kendisini [RAG nedir](/tr/sozluk/rag-nedir/) sayfamızda, WordPress üzerindeki uygulamasını [WordPress için RAG](/tr/blog/wordpress-icin-rag/) yazımızda anlattık. Bu yazı yalnız ölçme tarafını işler.

## Test seti nasıl hazırlanır?

İyi bir test seti, sistemin canlıda karşılaşacağı soruların küçük bir aynasıdır. Anthropic'in değerlendirme rehberi üç ilke önerir: testleri görevinize göre kurun, mümkün olduğunca otomatik puanlayın ve az sayıda kusursuz soru yerine çok sayıda soru kullanın.

Pratikte şu adımlar işe yarar:

1. **Gerçek sorularla başlayın.** Destek talepleri, arama kayıtları ve ekip içi yazışmalar en iyi kaynaktır. Uydurma soru yazmak yerine kullanıcıların kendi cümlelerini kullanın.
2. **Her soruya beklenen kaynağı ekleyin.** Hangi doküman veya sayfanın cevabı içerdiğini işaretleyin. Kritik sorular için kısa bir referans cevap yazın.
3. **Zor durumları ekleyin.** Cevabı belgelerde olmayan sorular, iki belgenin çeliştiği durumlar, eski sürümü olan prosedürler ve belirsiz sorular. Sistemin "bilmiyorum" diyebilmesi de test edilmelidir.
4. **Dilleri ayrı temsil edin.** Türkçe ve İngilizce içerik birlikte kullanılıyorsa her iki dilde soru ekleyin. Türkçe soruya İngilizce belgeden cevap gelmesi gibi çapraz durumları da deneyin. Ekleri ve yazım farklılıklarını ("fatura iadesi", "iade faturası") ayrı sorular olarak tutun.

Test setini bir kez yazıp bırakmayın. Canlıda yanlış cevaplanan her soru, sete eklenecek bir aday olur.

Test setini kodla birlikte sürüm kontrolünde tutmak da işe yarar. Böylece hangi sonucun hangi set sürümüyle alındığı bellidir ve iki ölçüm birbiriyle dürüstçe karşılaştırılabilir. Set içindeki kişisel verileri maskeleyin; müşteri adı, telefon veya T.C. kimlik numarası test için gerekli değildir ve KVKK açısından gereksiz risk yaratır.

## Hangi metrik neyi ölçer?

Ragas dokümantasyonu RAG için context precision, context recall, faithfulness, response relevancy ve noise sensitivity gibi metrikler listeler. Hangisinin referans cevap gerektirdiği seçimi doğrudan etkiler.

| Metrik | Ne ölçer | Referans gerekir mi | Yakaladığı hata | Nasıl kontrol edilir |
|---|---|---|---|---|
| Context precision | İlgili parçaların sonuç listesinde üstte olup olmadığı | Referanslı ve referanssız türleri var | Doğru parçanın alakasız parçalar arasında kaybolması | Getirilen parçaların sırasına bakılır |
| Context recall | Cevap için gereken bilginin ne kadarının getirildiği | Evet | Eksik getirme, yanlış parçalama | Referans cevaptaki iddiaların getirilen parçalarda olup olmadığı |
| Faithfulness | Cevaptaki her iddianın getirilen parçalarla desteklenip desteklenmediği | Hayır | Kaynağa dayanmayan, uydurulmuş ifade | Cevap iddialara bölünür, her biri parçalarla karşılaştırılır |
| Response relevancy | Cevabın soruyu karşılayıp karşılamadığı | Hayır | Konudan sapma, eksik veya gereksiz uzun cevap | Soru ile cevabın anlam yakınlığı |
| Kaynak isabeti (kendi metriğiniz) | Gösterilen kaynak bağlantısının doğru belge olup olmadığı | Beklenen kaynak gerekir | Yanlış belgeye yönlendirme | Beklenen kaynak listesiyle karşılaştırma |

Faithfulness düşükse model, bulunan metnin dışına çıkıyor demektir; bu [yapay zeka halüsinasyonu](/tr/sozluk/yapay-zeka-halusinasyonu-nedir/) riskinin doğrudan ölçüsüdür. Context recall düşükse modeli değiştirmek işe yaramaz, getirme tarafına bakmak gerekir. Anthropic'in Contextual Retrieval çalışması da iyileştirmeleri getirme tarafında, ilk 20 sonuçta bulunamayan ilgili parça oranıyla ölçer. Bu, kendi sisteminizde de kullanabileceğiniz basit ve anlaşılır bir ölçüttür.

## LLM ile değerlendirme ne zaman güvenilir, ne zaman insan gerekir?

Yukarıdaki metriklerin çoğu, bir dil modelinin puanlayıcı olarak kullanılmasına dayanır (LLM-as-judge). Bu yöntem hacimli testleri mümkün kılar ama kendi hatalarını da getirir. Anthropic'in rehberi, mümkünse cevabı üreten modelden farklı bir modelle puanlamayı önerir.

LLM puanlayıcısına şu koşullarda güvenebilirsiniz:

- Puanlama kuralları açık ve ayrıntılıdır (örneğin "cevaptaki her tutar kaynakta aynen geçmeli").
- Puanlayıcının kararları, insan tarafından etiketlenmiş küçük bir örnekle karşılaştırılmış ve tutarlı bulunmuştur.
- Soru tipi, puanlayıcının kendisinin de iyi anladığı bir alandadır.

İnsan incelemesi şu durumlarda sürmelidir: cevap hukuki, finansal veya sağlıkla ilgili bir karara dayanak oluyorsa; puanlayıcı ile insan arasında sık anlaşmazlık varsa; yeni bir doküman türü veya dil eklendiyse. Örneğin [finans ve sigorta](/tr/sektorler/finans-sigorta/) kurumlarında poliçe veya sözleşme hükmü aktaran cevaplar, örnekleme yoluyla da olsa düzenli insan kontrolünden geçmelidir.

## Canlıda izleme ve geri bildirim döngüsü nasıl kurulur?

Test seti başlangıçtır. Canlıda kullanıcılar test setinde olmayan sorular sorar, belgeler değişir, model sürümleri güncellenir. İzleme için şu kayıtları tutun:

- **Soru, getirilen parçalar, cevap ve gösterilen kaynaklar.** Bunlar olmadan bir hatanın getirmeden mi üretimden mi geldiğini sonradan anlayamazsınız.
- **Kullanıcı geri bildirimi.** Basit bir "işe yaradı / yaramadı" düğmesi ve isteğe bağlı açıklama.
- **"Bilmiyorum" ve devir oranı.** Bu oranın ani artışı, indeksin eskidiğini veya yeni bir konunun belgelenmediğini gösterir.
- **Düzenli örneklem.** Her dönem rastgele bir grup cevabı faithfulness ve kaynak isabeti açısından yeniden puanlayın.

Model, embedding veya parçalama ayarı değiştiğinde aynı test setini önce ve sonra çalıştırın. Bu, [doküman analizi](/tr/cozumler/dokuman-analizi/) gibi belge yoğun uygulamalarda özellikle önemlidir; [inşaat ve yapı malzemeleri](/tr/sektorler/insaat-yapi-malzemeleri/) şirketlerinin teknik şartname arşivleri veya [teknoloji ve yazılım](/tr/sektorler/teknoloji-yazilim/) ekiplerinin ürün dokümantasyonu sık güncellenir.

## Nereden başlamalı?

Mevcut bir RAG asistanınız varsa, son dönemin gerçek sorularından küçük bir test seti çıkarın ve her soruya beklenen kaynağı işaretleyin. Önce yalnız context recall ve faithfulness ölçün; bu iki metrik, sorunun getirmede mi üretimde mi olduğunu çoğu zaman tek başına gösterir.

Corrplus'ta RAG projelerinde test setini tasarım aşamasında, müşteriyle birlikte gerçek sorulardan hazırlıyoruz ve ilk sürümü bu setle ölçerek teslim ediyoruz. Kurulum için [RAG kurumsal bilgi asistanı](/tr/hizmetler/rag-kurumsal-bilgi-asistani/), model ve API katmanı için [LLM entegrasyonu](/tr/hizmetler/llm-entegrasyonu/), canlıdaki düzenli ölçüm ve iyileştirme için [yönetilen hizmetler](/tr/hizmetler/yonetilen-hizmetler/) sayfalarımıza bakabilirsiniz.

## Sık sorulan sorular

### Test seti için kaç soru gerekir?

Sabit bir sayı yok. Anthropic'in değerlendirme rehberi, otomatik puanlanan daha çok sorunun, elle puanlanan az sayıda sorudan genellikle daha faydalı olduğunu söyler. Gerçek kullanıcı sorularından başlayın, her önemli konu ve soru tipi temsil edilsin, seti zamanla büyütün.

### Referans cevap yazmadan değerlendirme yapılabilir mi?

Kısmen. Faithfulness ve cevap uygunluğu gibi metrikler referans cevap istemez. Context recall gibi getirme metrikleri ise neyin bulunması gerektiğini bilmek için referans ister. En azından kritik sorular için beklenen kaynak ve kısa referans cevap yazmanızı öneririz.

### LLM ile puanlama insan değerlendirmesinin yerini tutar mı?

Tamamen tutmaz. Hacimli ve tekrar eden kontroller için uygundur. Puanlayıcıyı önce insan etiketli küçük bir örnekle karşılaştırın, sonra güvenin. Hukuki, finansal veya sağlıkla ilgili cevaplarda insan incelemesi devam etmelidir.

### Model veya embedding değiştiğinde ne yapmalı?

Aynı test setini değişiklikten önce ve sonra çalıştırın, sonuçları karşılaştırın. Değişikliği ancak getirme ve üretim metrikleri gerilemiyorsa canlıya alın. Bu, sistemi yönetilen hizmet olarak işletirken rutin bir adımdır.

## Kaynaklar

- [Es ve diğerleri, Ragas: Automated Evaluation of Retrieval Augmented Generation (arXiv, 2023)](https://arxiv.org/abs/2309.15217)
- [Ragas dokümantasyonu, Available metrics](https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/)
- [Ragas dokümantasyonu, Context Recall](https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/context_recall/)
- [Anthropic, Contextual Retrieval](https://www.anthropic.com/research/contextual-retrieval)
- [Anthropic, Define success criteria and build evaluations](https://platform.claude.com/docs/en/test-and-evaluate/develop-tests)