# RAG Değerlendirmesi 2026: Faithfulness, Context Precision ve Ragas ile Kaliteyi Ölçmek

> Source: https://sukruyusufkaya.com/blog/rag-degerlendirme-metrikleri-2026-ragas-faithfulness
> Updated: 2026-07-22T15:55:15.755Z
> Type: blog
> Category: yapay-zeka
**TLDR:** RAG sisteminizin gerçek kalitesini dört temel metrikle ölçün: faithfulness, answer relevance, context precision ve recall. Ragas, LLM-as-a-judge ve Türkçe zorlukları.

**TL;DR —** RAG sistemlerinin en büyük yalanı, demoda mükemmel çalışıp üretimde sessizce çürümesidir. 2026'da fark yaratan şey daha büyük model değil, retrieval kalitesini gerçekten ölçen bir değerlendirme disiplini. Bu yazıda faithfulness (sadakat), context precision (bağlam kesinliği), context recall (bağlam anımsama) ve answer relevance (cevap ilgisi) metriklerini; Ragas gibi araçlarla nasıl otomatik ölçüleceğini; LLM-as-a-judge yaklaşımının tuzaklarını ve Türkçe içerikte değerlendirmenin özel zorluklarını sahadan örneklerle anlatıyorum. Amacım, "iyi görünüyor" hissiyatından "sayıyla kanıtlanmış kalite"ye geçmenizi sağlamak.

## Neden RAG değerlendirmesi çoğu ekibin kör noktası

Sahada gördüğüm en yaygın manzara şu: ekip bir RAG sistemi kuruyor, birkaç soruyla deniyor, cevaplar makul görünüyor ve sistem canlıya alınıyor. Aradan üç ay geçiyor, kullanıcı şikâyetleri artıyor, "sistem saçmalıyor" deniyor ama kimse tam olarak neyin bozulduğunu bilmiyor. Çünkü ölçülen hiçbir şey yok. Değerlendirme olmadan bir RAG sistemi işletmek, gösterge paneli olmayan bir uçağı gece uçurmaya benziyor.

RAG'ın zorluğu, iki ayrı bileşenin — retrieval ve generation — birbirinden bağımsız hata üretebilmesi. Model harika ama getirdiğiniz bağlam alakasızsa, cevap kendinden emin bir yanlış olur. Bağlam mükemmel ama model onu görmezden gelip kendi bildiğini uydurursa, yine yanlış. Bu iki hata tipini ayırt edemezseniz, yanlış yeri tamir etmeye çalışırsınız. Değerlendirme metriklerinin asıl değeri burada: hatanın retrieval'da mı generation'da mı olduğunu söylemesi.

> Bir müşterime şunu söylemiştim: "RAG'ınızın kalitesini ölçmüyorsanız, aslında kalitesi olduğunu da iddia edemezsiniz." Ölçüm, iddianın ön koşulu.

## Dört temel metrik: neyi, neden ölçüyoruz

RAG değerlendirmesinde 2026 itibarıyla sektörün üzerinde uzlaştığı dört temel metrik var. Bunları anlamak, geri kalan her şeyin temelini oluşturuyor.

**Faithfulness (Sadakat).** Cevabın, getirilen bağlama ne kadar sadık kaldığını ölçer. Model bağlamda olmayan bir şey uydurduysa faithfulness düşer. Bu metrik doğrudan halüsinasyonun karşılığı: yüksek faithfulness, düşük halüsinasyon demek. Ölçüm mantığı şu: cevabı atomik iddialara böl, her iddianın bağlamda desteklenip desteklenmediğini kontrol et, desteklenenlerin oranını hesapla.

**Answer Relevance (Cevap İlgisi).** Cevabın, sorulan soruyla ne kadar ilgili olduğunu ölçer. Model doğru ama alakasız bir şey söyleyebilir; teknik olarak sadık ama kullanıcının sorusuna cevap vermiyordur. Bu metrik, cevaptan geriye doğru olası soruları üretip bunların orijinal soruyla benzerliğine bakarak hesaplanır.

**Context Precision (Bağlam Kesinliği).** Getirilen bağlam parçalarının ne kadarının gerçekten ilgili olduğunu ölçer. Retriever on parça getirdiyse ve sadece ikisi işe yarıyorsa, precision düşüktür. Bu, gürültülü retrieval'ın işareti.

**Context Recall (Bağlam Anımsama).** Cevabı üretmek için gereken tüm bilginin bağlama getirilip getirilmediğini ölçer. Kritik bir belge parçası retrieval'da kaçırıldıysa, recall düşer. Bu, eksik retrieval'ın işareti.

| Metrik | Neyi yakalar | Düşükse sorun nerede |
|---|---|---|
| Faithfulness | Halüsinasyon | Generation: model bağlamı yok sayıyor |
| Answer Relevance | Konudan sapma | Generation: cevap soruya odaklı değil |
| Context Precision | Gürültülü getirme | Retrieval: alakasız parçalar geliyor |
| Context Recall | Eksik getirme | Retrieval: gerekli parça kaçıyor |

Bu dört metriğin güzelliği, birlikte okunduğunda hatanın kaynağını neredeyse cerrahi bir kesinlikle göstermesi. Faithfulness düşük ama context precision/recall yüksekse, sorun modelde ve prompt'ta. Context recall düşükse, sorun chunking ya da retriever'da. Bu teşhis yeteneği, körlemesine model büyütmekten çok daha ucuz ve etkili.

## Ragas ile otomatik değerlendirme

Bu metrikleri elle hesaplamak ölçeklenmez. İşte burada Ragas gibi araçlar devreye giriyor. Ragas, RAG pipeline'ınızın çıktılarını — soru, getirilen bağlam, üretilen cevap ve varsa referans cevap — alıp yukarıdaki metrikleri otomatik hesaplayan açık kaynaklı bir çerçeve. Mantığı, metriklerin çoğunu bir LLM'i hakem (judge) olarak kullanarak ölçmesi.

Pratik kurulum şöyle işliyor: bir değerlendirme veri seti hazırlıyorsunuz — tipik olarak 50 ila 200 arası soru-cevap çifti, tercihen gerçek kullanıcı sorularından türetilmiş. Her soruyu RAG sisteminizden geçiriyor, çıktıları topluyor ve Ragas'a veriyorsunuz. Ragas her örnek için dört metriği hesaplayıp toplulaştırılmış bir skor kartı üretiyor. Bu skor kartı, sisteminizin sağlık panosu hâline geliyor.

Sahada uyguladığım en değerli pratik, bu değerlendirmeyi CI/CD hattına gömmek. Prompt'u değiştirdiğinizde, chunk boyutunu ayarladığınızda ya da retriever'ı güncellediğinizde, değerlendirme otomatik çalışıp "bu değişiklik faithfulness'ı %4 düşürdü" diye uyarıyor. Böylece regresyonları üretime çıkmadan yakalıyorsunuz. Bir müşterimde bu düzeni kurduğumuzda, ekip ilk kez "değişiklik yaptık ama bir şey bozuldu mu bilmiyoruz" korkusundan kurtuldu.

> Değerlendirme veri setinizi bir kere kurun ve onu kutsal sayın. Sistem her değiştiğinde aynı setle test edin; ancak o zaman skorlar karşılaştırılabilir olur.

## LLM-as-a-judge: güçlü ama tuzaklı

Modern RAG değerlendirmesinin bel kemiği, cevapları puanlamak için başka bir LLM'i hakem olarak kullanmak. Bu yaklaşım güçlü çünkü ölçeklenir ve insan yargısına yakın sonuçlar üretebilir. Ama körü körüne güvenilecek bir şey değil; kendine has tuzakları var.

Birinci tuzak, hakem modelin yanlılığı. Hakem model, kendi ürettiği ya da kendine benzeyen cevapları kayırma eğiliminde olabilir. İkincisi, uzunluk yanlılığı: hakemler uzun cevapları haksız yere daha iyi puanlama eğiliminde. Üçüncüsü, konum yanlılığı: iki cevabı karşılaştırırken ilk sunulanı kayırma. Dördüncüsü, tutarsızlık: aynı cevaba farklı çalıştırmalarda farklı puan verme.

Bu tuzaklardan korunmanın yolları var. Hakem prompt'unu çok net ve ölçütlü yazmak; puanlama kriterlerini açıkça tanımlamak; mümkünse zincirleme düşünce (chain-of-thought) ile hakemin gerekçesini istemek; ve en önemlisi, hakem skorlarını periyodik olarak insan değerlendirmesiyle kalibre etmek. İnsan-hakem uyumunu ölçmeden LLM-as-a-judge'a tam güvenmek, ölçüm aletini hiç kalibre etmeden kullanmaya benzer.

## Türkçe içerikte değerlendirmenin özel zorlukları

Türkçe RAG sistemleri değerlendirilirken çoğu ekibin gözden kaçırdığı bir katman var: dilin kendisi. İngilizce için mükemmel çalışan hakem prompt'ları ve embedding modelleri, Türkçede sessizce zayıflayabiliyor. Türkçenin sondan eklemeli yapısı, aynı kökün onlarca farklı biçimde geçmesi, embedding tabanlı benzerlik ölçümlerini zorluyor.

Pratik önerilerim şunlar. Birincisi, hakem modeli Türkçe değerlendirme yaparken açıkça Türkçe talimatla yönlendirin; İngilizce prompt ile Türkçe cevap değerlendirmek tutarsızlık üretiyor. İkincisi, embedding modelinizi Türkçe destekli seçin ve mümkünse Türkçe bir benchmark ile doğrulayın. Üçüncüsü, değerlendirme veri setinizi gerçek Türkçe kullanıcı sorularından kurun; İngilizceden çevrilmiş sorular, üretimdeki gerçek dağılımı temsil etmiyor.

Bir müşterimde, İngilizce metriklerle "harika" görünen bir sistem, Türkçe gerçek sorularla test edildiğinde faithfulness'ta ciddi düşüş gösterdi. Sebep, retriever'ın Türkçe eş anlamlıları ve çekim eklerini iyi eşleştirememesiydi. Bu ancak Türkçeye özgü bir değerlendirme setiyle görünür hâle geldi.

## Değerlendirme veri setini nasıl kurmalı

İyi bir değerlendirme, iyi bir veri setiyle başlar. Sık yapılan hata, birkaç uyduruk soruyla yetinmek. Sağlam bir set üç kaynaktan beslenir. Birincisi, gerçek kullanıcı loglarından türetilmiş sorular — bunlar üretimin gerçek dağılımını yansıtır. İkincisi, uç durumlar (edge cases) — bilinçli olarak zor, muğlak ya da tuzaklı sorular. Üçüncüsü, "olmaması gereken" sorular — bilgi tabanında cevabı olmayan sorular; sistem bunlara "bilmiyorum" diyebiliyor mu, yoksa uyduruyor mu?

Bu üçüncü kategori kritik. Çoğu RAG felaketi, sistemin cevabı olmayan bir soruya kendinden emin bir şey uydurmasından doğar. Değerlendirme setinize bilinçli olarak "cevapsız" sorular koyup sistemin dürüstçe geri çekilip çekilmediğini ölçmek, üretim güvenliğinizin sigortası.

## Skorları eyleme dönüştürmek

Metrikler kendi başına bir işe yaramaz; onları karar mekanizmasına bağlamak gerekir. Her metrik için bir eşik belirleyin: örneğin faithfulness 0.90'ın altına düşerse üretime çıkış durdurulur. Skorları zaman içinde izleyin; ani bir düşüş, bir belge güncellemesinin ya da model değişikliğinin yan etkisini ele verir. Ve en önemlisi, düşük skorlu örnekleri elle inceleyin — sayı size nerede sorun olduğunu söyler, ama neden olduğunu ancak örneği okuyunca anlarsınız.

Sahada bu döngüyü kuran ekipler, RAG sistemlerini "umut ederek" değil "bilerek" işletiyor. Her değişiklikte skor kartına bakıyor, regresyonu anında yakalıyor ve iyileştirmeyi sayıyla kanıtlıyorlar. Bu, RAG'ı bir demo oyuncağından üretim sınıfı bir sisteme dönüştüren kültürel sıçramanın ta kendisi.

RAG'ınızı bir sonraki seviyeye taşımak istiyorsanız, atacağınız ilk adım büyük modele geçmek değil; küçük ama gerçek bir değerlendirme seti kurup dört temel metriği bu hafta ölçmeye başlamak. Sayılar geldiğinde, hangi tarafı — retrieval mı, generation mı — tamir etmeniz gerektiği kendiliğinden ortaya çıkacak ve tahmin oyunundan mühendisliğe geçmiş olacaksınız.

## Retrieval'ı ayrı, generation'ı ayrı test etmek

Deneyimli ekiplerin sıradan ekiplerden ayrıldığı nokta, iki bileşeni ayrı ayrı test etme disiplinidir. Uçtan uca bir skor, size sistemin iyi ya da kötü olduğunu söyler; ama nerede kırıldığını söylemez. Bu yüzden değerlendirmeyi iki katmana bölmek gerekir.

Retrieval katmanını izole test etmek için, her soru için "altın bağlam" (golden context) diye adlandırdığımız, cevabı gerçekten içeren belge parçalarını önceden işaretlersiniz. Sonra retriever'ın bu altın parçaları getirip getirmediğine bakarsınız. Burada klasik bilgi getirme metrikleri devreye girer: precision, recall, ve sıralama kalitesini ölçen MRR (Mean Reciprocal Rank) ile nDCG. Eğer retriever altın parçaları ilk sıralara taşıyamıyorsa, generation ne kadar iyi olursa olsun sistem çürük temele oturur.

Generation katmanını izole test etmek içinse, retriever'ı devreden çıkarıp modele doğrudan altın bağlamı verirsiniz. Bu koşulda model hâlâ halüsinasyon yapıyorsa, sorun kesinlikle generation tarafında — prompt tasarımında ya da modelin bağlama sadakatinde. Bu ayrım, "hangi tarafı tamir edeyim?" sorusunu net biçimde yanıtlar.

Sahada bu iki katmanlı yaklaşımı kurduğumuzda, bir müşterimde uzun süredir "model kötü" diye suçlanan bir sistemin aslında retriever probleminden muzdarip olduğunu ortaya çıkardık. Model gayet iyiydi; ona doğru bağlam ulaşmıyordu. Chunking stratejisini ve retriever'ı düzelttikten sonra, tek satır model kodu değiştirmeden kalite belirgin biçimde yükseldi.

## Chunking ve retrieval kalitesinin görünmez etkisi

RAG değerlendirmesinde çoğu ekibin geç fark ettiği gerçek şu: kalitenin büyük kısmı, göz alıcı model katmanında değil, sıkıcı görünen chunking ve indeksleme katmanında belirleniyor. Belgeyi nasıl parçaladığınız, hangi boyutta chunk kullandığınız, örtüşme (overlap) bırakıp bırakmadığınız — bunların hepsi context recall ve precision'ı doğrudan etkiliyor.

Çok küçük chunk'lar bağlamı parçalıyor; model cümlenin yarısını görüp diğer yarısını kaçırıyor. Çok büyük chunk'lar ise gürültü getiriyor; ilgili bir cümlenin yanında dokuz alakasız cümle de bağlama giriyor ve precision düşüyor. İşte değerlendirme metrikleri tam da burada paha biçilmez: farklı chunk stratejilerini aynı değerlendirme setiyle test edip hangisinin daha yüksek recall/precision verdiğini sayıyla görebilirsiniz. Tahmin yerine ölçüm.

2026'da öne çıkan bir teknik, bağlamsal getirme (contextual retrieval): her chunk'a, ait olduğu belgenin bağlamını özetleyen kısa bir başlık eklemek. Bu, izole bir chunk'ın "neyin parçası" olduğunu modele hatırlatıyor ve retrieval kalitesini gözle görülür biçimde yükseltiyor. Ama bunu körlemesine uygulamak yerine, değerlendirme setinizle önce/sonra ölçüp gerçekten fayda sağlayıp sağlamadığını doğrulamak gerekir.

## Reranker eklemenin değerini ölçmek

Retrieval kalitesini yükseltmenin en etkili yollarından biri, ilk getirme adımından sonra bir yeniden sıralama (reranking) katmanı eklemek. Retriever hızlı ama kaba bir eşleşmeyle diyelim yirmi aday getiriyor; reranker ise daha pahalı ama daha isabetli bir modelle bu yirmi adayı yeniden sıralayıp en iyi beşini seçiyor. Bu iki aşamalı yapı, hem hızı hem kaliteyi dengeliyor.

Ancak reranker eklemek de körlemesine yapılacak bir şey değil; maliyeti ve gecikmeyi artırıyor. Karar vermenin tek sağlıklı yolu, değerlendirme setinizle reranker'lı ve reranker'sız iki senaryoyu karşılaştırmak. Context precision'daki artış, eklenen gecikmeyi haklı çıkarıyor mu? Bu soruyu ancak sayıyla yanıtlayabilirsiniz. Bir müşterimde reranker, context precision'ı belirgin biçimde yükseltti ve halüsinasyon şikâyetlerini üçte iki oranında azalttı; eklenen birkaç yüz milisaniyelik gecikme, bu kalite sıçraması yanında kabul edilebilirdi.

## Üretimde sürekli değerlendirme: offline'dan online'a

Şimdiye kadar anlattığım her şey, çoğunlukla offline değerlendirme — yani önceden hazırlanmış bir setle laboratuvar koşullarında test. Ama üretim, laboratuvarın öngöremediği sorular üretir. Bu yüzden olgun ekipler online değerlendirmeye de geçiyor: canlı trafikteki gerçek soru-cevap çiftlerini örnekleyip bunları da otomatik hakemle puanlıyorlar.

Online değerlendirmenin gücü, dağılım kaymasını (distribution shift) yakalaması. Kullanıcıların soru tarzı zamanla değişir; bilgi tabanınız güncellenir; mevsimsel konular gelir gider. Offline setiniz dünkü dünyayı temsil ederken, online izleme bugünkü dünyayı gösterir. İkisini birlikte kullanmak, hem regresyona hem de sürüklenmeye karşı çift koruma sağlar.

Bir de kullanıcı sinyalleri var: başparmak yukarı/aşağı, cevabın kopyalanması, sorunun yeniden sorulması. Bu örtük geri bildirimleri metriklerle birleştirmek, laboratuvar skorlarının kaçırdığı gerçek memnuniyeti ele veriyor. Sahada en sağlam kurulum, offline metrikler + online örnekleme + kullanıcı sinyallerinin üçlü sac ayağı üzerine oturuyor.

## KVKK ve değerlendirme verisinin gizliliği

Türkiye bağlamında sıkça atlanan bir nokta: değerlendirme veri setiniz, gerçek kullanıcı sorularından türetildiğinde kişisel veri içerebilir. Bir sağlık ya da finans RAG sistemini değerlendirirken, gerçek kullanıcı loglarını değerlendirme setine koymak KVKK açısından işleme faaliyetidir ve amaç, hukuki sebep, saklama süresi gibi soruları beraberinde getirir.

Pratik çözümüm şu: değerlendirme setini kurarken kişisel verileri maskeleyin ya da anonimleştirin; mümkünse sentetik ama gerçekçi sorularla zenginleştirin. Hakem olarak dışarıya API çağrısı yapan bir LLM kullanıyorsanız, o çağrıda kişisel veri gönderip göndermediğinizi bilinçli değerlendirin. KVKK'nın üretken yapay zekâ rehberi tam da bu tür "veri işleme kapsamının öngörülemez genişlemesi" riskine dikkat çekiyor. Değerlendirme, kaliteyi artırırken gizliliği zedelememelidir.

## Küçük başlayın, ama bugün başlayın

Bütün bu metrik ve araç yığını gözünüzü korkutmuş olabilir; oysa doğru başlangıç çok mütevazı. İlk gün için önerim şu: yirmi gerçek soru toplayın, sistemden geçirin, çıktıları bir tabloya yazın ve dört temel metriği — isterseniz elle, isterseniz Ragas ile — ölçün. Bu yirmi satır bile, sisteminizin sağlığı hakkında şimdiye dek sahip olmadığınız bir netlik verecek.

Sonraki hafta seti elliye çıkarın, uç durumları ve cevapsız soruları ekleyin, değerlendirmeyi otomatikleştirin. Üçüncü hafta CI hattına gömün. Bir ay sonra, her değişikliği sayıyla değerlendiren bir ekibe dönüşmüş olursunuz. Bu yolculuğun sırrı büyük bir altyapı kurmakta değil, küçük ama tutarlı bir ölçüm alışkanlığını bugün başlatmakta. Değerlendirme setinizin ilk yirmi satırını bu hafta yazın; RAG'ınızın gerçek kalitesiyle ilk kez yüzleşmenin, onu iyileştirmenin de başlangıcı olduğunu göreceksiniz.

## Metrikleri yanlış okumanın maliyeti

Ölçüm kültürü kurmak kadar, o ölçümleri doğru yorumlamak da önemli. Sahada en sık gördüğüm hata, tek bir metriği kutsallaştırıp diğerlerini görmezden gelmek. Faithfulness'ı %99'a çıkardığını söyleyen bir ekip gördüm; ama context recall'ları o kadar düşüktü ki sistem çoğu soruya "bu konuda bilgim yok" diyordu. Yani sadıktı, çünkü neredeyse hiçbir şey iddia etmiyordu. Sadakati yükseltmek için sistemi aşırı temkinli hâle getirmişlerdi ve kullanışlılık dibe vurmuştu.

Bu, metriklerin gerilim içinde olduğunu gösteriyor. Faithfulness ile answer relevance, precision ile recall çoğu zaman ters yönde çekiştirir. Sistemi çok temkinli yaparsanız halüsinasyon düşer ama fayda da düşer; çok cömert yaparsanız fayda artar ama halüsinasyon da. Doğru ayar, bu dengeyi iş bağlamınıza göre kurmaktır. Bir tıbbi RAG'da faithfulness tavizsizdir; bir fikir üretme aracında biraz daha esneklik kabul edilebilir. Metrikler size sayıyı verir; hangi dengenin doğru olduğuna iş sahibi karar verir.

## Değerlendirmeyi bir yönetişim aracına dönüştürmek

RAG değerlendirmesinin nihai değeri, teknik ekibin ötesine geçip bir yönetişim aracına dönüşmesinde. Düzenli üretilen bir skor kartı, yöneticiye "sistem sağlıklı mı" sorusunun cevabını sayıyla verir. KVKK ya da iç denetim bir gün "yapay zekâ sisteminizin doğruluğunu nasıl temin ediyorsunuz?" diye sorduğunda, elinizde aylardır tutulan faithfulness ve recall grafikleri olması, hesap verebilirliğin somut kanıtıdır.

Bu, EU AI Act'in ve KVKK rehberlerinin ruhuyla da örtüşüyor. Her iki çerçeve de yapay zekâ sistemlerinin doğruluğunu, güvenilirliğini ve izlenebilirliğini belgeleyebilmeyi istiyor. Sürekli değerlendirme, bu belgeyi kendiliğinden üretiyor. Yani kaliteyi artırmak için kurduğunuz ölçüm disiplini, aynı zamanda uyum dosyanızın bir parçası hâline geliyor. Bir taşla iki kuş.

Sonuçta RAG değerlendirmesi, bir araç seçiminden çok bir zihniyet meselesi. "İyi görünüyor" diyerek üretime çıkan ekiple, "faithfulness 0.91, context recall 0.87, geçen haftaya göre stabil" diyerek çıkan ekip arasındaki fark, amatörlükle profesyonellik arasındaki fark. Bu zihniyeti bugün küçük bir setle kurmaya başlayın; sistem büyüdükçe ölçüm de büyüsün. Ölçtüğünüz an, RAG'ınızı gerçekten yönetmeye başlarsınız; ölçmediğiniz sürece yalnızca umut edersiniz.