RAG Değerlendirme 2026: RAGAS, Faithfulness, OpenTelemetry ve Başarılı Çıktı Başına Maliyet

TL;DR — Bir RAG sistemini üretime almak kolay; onun gerçekten doğru cevap verdiğini kanıtlamak zor. 2026'da fark, değerlendirmede (evaluation). Araştırmalar tutarlı biçimde getirme kalitesinin RAG performansının birincil sürücüsü olduğunu, doğruluğu, sadakati ve halüsinasyon oranını doğrudan etkilediğini gösteriyor. RAGAS gibi referanssız çerçeveler, sadakat (faithfulness), yanıt alaka düzeyi ve bağlam kesinliği gibi metrikleri altın-standart cevap olmadan ölçmenizi sağlıyor. Her getir-rerank-üret-yargıla adımını OpenTelemetry span'leriyle sarmak, sistemi kara kutu olmaktan çıkarıyor. Ve nihai birim ekonomisi metriği: başarılı çıktı başına maliyet. Bu yazıda RAG değerlendirmesini, metrikleri, RAGAS'ı ve bir değerlendirme hattını anlatıyorum.

Çoğu ekip bir RAG demosu kurar, birkaç soru sorar, "işe yarıyor" der ve üretime alır. Sonra ne olur? Gerçek kullanıcılar beklenmedik sorular sorar, sistem halüsinasyon yapar, yanlış belge getirir ve güven çöker. Sorun, ekibin kötü mühendis olması değil; değerlendirmeyi atlaması. "Birkaç soru sordum, iyi görünüyordu" bir değerlendirme değil, bir izlenim. İzlenimle üretim sistemi yönetilmez.

RAG değerlendirmesi zor, çünkü doğru cevap çoğu zaman öznel ve bağlama bağlı. Bir sınıflandırma modelini değerlendirmek kolay — doğru ya da yanlış. Ama "bu cevap iyi mi?" sorusu birçok boyut içerir: doğru mu, kaynağa sadık mı, soruyla alakalı mı, eksiksiz mi? Bu çok-boyutluluk, RAG değerlendirmesini bir sanat gibi gösterir; oysa 2026'da bunu bir bilime dönüştüren araçlar var.

RAG değerlendirmesi iki ana bileşeni ölçer: getirme kalitesi ve üretim kalitesi. Getirme tarafında bağlam kesinliği (context precision — getirilen belgeler ne kadar alakalı) ve bağlam geri çağırma (context recall — gereken bilginin ne kadarı getirildi) öne çıkar. Üretim tarafında sadakat (faithfulness — cevap getirilen bağlama sadık mı, yoksa uyduruyor mu) ve yanıt alaka düzeyi (answer relevancy — cevap soruyu gerçekten yanıtlıyor mu).

Bu ayrım kritik çünkü hataların kökenini gösterir. Cevap kötüyse, sorun getirmede mi (yanlış belge geldi) yoksa üretimde mi (doğru belge geldi ama model kötü kullandı)? Sadakat düşükse model halüsinasyon yapıyor; bağlam geri çağırma düşükse getirme eksik. Araştırmalar getirme kalitesinin birincil sürücü olduğunu gösteriyor — yani çoğu zaman sorun modelde değil, ona verdiğiniz bağlamda. Metrikleri ayırmak, doğru yeri tamir etmenizi sağlar.

Temel RAG değerlendirme metrikleri

Metrik	Ne ölçer	Düşükse ne demek
Bağlam kesinliği	Getirilen belgeler ne kadar alakalı	Gürültülü getirme
Bağlam geri çağırma	Gereken bilgi getirildi mi	Eksik getirme
Sadakat (faithfulness)	Cevap bağlama sadık mı	Halüsinasyon
Yanıt alaka düzeyi	Cevap soruyu yanıtlıyor mu	Konu dışı cevap

RAG değerlendirmesinin pratik engeli şu: her soru için elle "altın standart" cevap hazırlamak çok pahalı ve yavaş. RAGAS (Retrieval-Augmented Generation Assessment) bu engeli aşıyor. Referanssız (reference-free) bir çerçeve olarak RAGAS, önceden hazırlanmış doğru cevaplar olmadan da sadakat, yanıt alaka düzeyi ve bağlam kesinliği gibi metrikleri ölçebiliyor — genellikle bir yargıç-model (LLM-as-judge) kullanarak.

Bu neden devrimci? Çünkü değerlendirmeyi ölçeklenebilir kılıyor. Elle etiketlenmiş 500 soruluk bir altın set hazırlamak yerine, RAGAS ile yüzlerce soruyu otomatik değerlendirebilirsiniz. Elbette otomatik değerlendirmenin de sınırları var — yargıç-model de hata yapar. Bu yüzden en iyi pratik hibrit: RAGAS gibi otomatik metriklerle geniş kapsama, kritik örneklerde insan değerlendirmesiyle derinlik. Otomatik değerlendirme hızı, insan değerlendirmesi güveni sağlar.

RAG değerlendirmesinin belki de en pratik uygulaması bir regresyon test seti. Temel işlevselliği, uç durumları ve bilinen hata modlarını kapsayan bir test seti oluşturun ve her değişiklikte — yeni bir embedding modeli, farklı bir chunking stratejisi, güncellenmiş bir prompt — çalıştırın. Böylece bir "iyileştirme"nin aslında başka bir yeri bozup bozmadığını erkenden yakalarsınız.

Yazılım mühendisliğinden ödünç alınan bu disiplin, RAG'de sıkça atlanıyor. Oysa RAG hattı kırılgan: bir chunking değişikliği getirmeyi bozabilir, bir prompt değişikliği sadakati düşürebilir. Regresyon seti olmadan, her değişiklik bir kumar. Tam değerlendirme takımını haftalık bir kadansta veya büyük sürümlerden önce çalıştırın; hızlı bir alt-küme setini ise her commit'te CI'da koşturun.

Değerlendirme, sistemin ne kadar iyi olduğunu söyler; gözlemlenebilirlik, neden öyle olduğunu. 2026 pratiği, her getir-rerank-üret-yargıla adımının etrafına OpenTelemetry span'leri sarmak. Bu size uçtan uca izlenebilirlik veriyor: hangi sorgu geldi, hangi belgeler getirildi, reranker ne yaptı, model ne üretti, yargıç ne dedi, her adımın gecikmesi ve token maliyeti ne. Bir cevap kötü çıktığında, bu span'ler sayesinde hangi adımın suçlu olduğunu tam olarak görürsünüz.

Bu telemetri olmadan RAG bir kara kutu olur. "Sistem bazen kötü cevap veriyor" şikâyeti, span'ler olmadan çözülemez bir muamma; span'lerle ise "şu tür sorgularda getirme eksik kalıyor" gibi somut bir teşhise dönüşür. Gözlemlenebilirlik, üretim RAG'inin ayıklama (debugging) altyapısı.

Değerlendirme sadece kaliteyi değil, birim ekonomisini de kapsamalı. Nihai metrik: başarılı çıktı başına maliyet — kalite kapılarını geçen çıktı başına toplam maliyet. Bir RAG sistemi teknik olarak "doğru" cevaplar verebilir ama her cevap on getirme turu ve binlerce token tükettiğinde ekonomik olmayabilir. Kalite ve maliyeti birlikte değerlendirmek, sürdürülebilir bir sistem için şart.

Bu metrik, kalite ile maliyet arasındaki dengeyi görünür kılar. Daha fazla getirme turu doğruluğu artırabilir ama maliyeti de artırır; bir reranker eklemek kaliteyi yükseltirken token'ı azaltarak maliyeti düşürebilir. Başarılı çıktı başına maliyeti izlemeden, bu dengeyi bilinçli kuramazsınız. Kalite kapısını (örneğin sadakat > belirli bir eşik) tanımlayın, o kapıyı geçen çıktı başına maliyeti hesaplayın.

Türkçe RAG değerlendirmesinde dile özgü bir zorluk var: global değerlendirme setleri ve yargıç-modeller İngilizce için ayarlanmış olabilir. Türkçe cevabın sadakatini değerlendirirken, yargıç-modelin Türkçe'de yeterince güçlü olduğundan emin olun; zayıf bir yargıç, yanlış bir değerlendirme üretir. Kendi Türkçe test setinizi kurun; global metriklere körü körüne güvenmeyin.

KVKK açısından: RAG değerlendirme setleriniz genellikle gerçek kullanıcı sorularından ve kurumsal belgelerden oluşur; bunlar kişisel veri içerebilir. Değerlendirme verinizi de kişisel veri işleme ilkelerine göre yönetin — anonimleştirme, erişim kontrolü, amaçla sınırlılık. Ayrıca yargıç-model bir dış API ise, değerlendirmeye giden hassas veriyi bu API'ye göndermenin KVKK sonuçlarını değerlendirin; hassas senaryolarda yerel bir yargıç-model tercih edin.

Pratik kurulum sıram: Kendi verinizden temsili bir test seti oluşturun — kolay sorular, uç durumlar, bilinen hata modları. Getirme ve üretim metriklerini ayrı ölçün (bağlam kesinliği/geri çağırma; sadakat/alaka). RAGAS gibi bir çerçeveyle otomatik değerlendirmeyi ölçeklendirin, kritik örneklerde insan değerlendirmesi ekleyin. Her adımı OpenTelemetry span'leriyle sarın. Bir regresyon setini CI'a bağlayın. Başarılı çıktı başına maliyeti izleyin. Türkçe iş yüklerinde dile özgü değerlendirme yapın.

RAG'de 2026'nın en büyük dersi şu: bir RAG sistemi kurmak bir mühendislik görevi, ama onun güvenilir olduğunu kanıtlamak bir değerlendirme görevi. Değerlendirmesiz bir RAG, göstergesiz uçan bir uçak — havada durabilir ama nereye gittiğini bilmezsiniz. Metrikleri ayıran, otomatik ve insan değerlendirmesini birleştiren, her adımı izleyen ve maliyeti kaliteyle birlikte gören bir değerlendirme disiplini; bir demoyu güvenilir bir üretim sistemine dönüştüren şeydir. Ölçün, ayıklayın, iyileştirin — ve her değişikliği yeniden ölçün.