RAG Değerlendirme: RAGAS ile Faithfulness, Context Precision ve Recall

TL;DR — RAG (Retrieval-Augmented Generation) sistemleri artık kurumsal AI projelerinin varsayılan mimarisi haline geldi; mühendislik ekiplerinin yaklaşık %70'i bir şekilde RAG kullanıyor. Ama "çalışıyor" ile "güvenilir" arasında ciddi bir uçurum var. Bu yazıda RAGAS çatısının dört temel metriğini — faithfulness, answer relevancy, context precision, context recall — birlikte nasıl bir panel gibi okuyacağınızı, RAGAS/TruLens/DeepEval araçlarının farklarını, 0.85 üzeri "iyi", 0.70 altı "ciddi sorun" eşiklerini nasıl yorumlayacağınızı, ortaya çıkan beşinci boyut olan "context trustworthiness"i (sahiplik, güncellik, kaynak izlenebilirliği) ve golden test seti kurma, LLM-as-judge tuzakları, CI entegrasyonu ile Türkiye'deki kurumsal/KVKK bağlamını anlatıyorum. Amaç basit: RAG'ı bir kere test edip unutmak değil, sürekli ölçen bir disipline dönüştürmek.

Son bir buçuk yıldır kurumsal danışmanlık ve eğitim verdiğim şirketlerin neredeyse tamamında aynı sahneyi izliyorum: bir ekip, dahili doküman havuzunu, prosedürleri, ürün kataloğunu ya da müşteri hizmetleri bilgi tabanını alıyor, bir vektör veritabanına gömüyor, üstüne bir LLM koyuyor ve "sohbet botumuz hazır" diyor. Demo günü herkes etkileniyor. Üç hafta sonra ise bambaşka bir tablo var: kullanıcılar "bu cevap yanlış", "bu bilgiyi nereden buldu anlamadım", "geçen ay değişen politikayı hâlâ eski haliyle söylüyor" gibi şikayetler getirmeye başlıyor.

Bunun nedeni RAG'ın kötü bir mimari olması değil. Sorun, çoğu ekibin RAG sistemini bir kez "çalışıyor mu" testinden geçirip sonra üretime almasında. Oysa RAG, klasik yazılımdan farklı bir hayvan: girdi-çıktı ilişkisi deterministik değil, retrieval katmanı zamanla bozulabilir (doküman güncellenir, embedding modeli değişir, indeks büyür), ve generation katmanı hafızasında olmayan bir şeyi "uydurma" eğiliminde. Bu yüzden RAG'ı sürekli, sistematik ve ölçülebilir biçimde değerlendirmek — bir kerelik kalite kontrolü değil, kalıcı bir mühendislik disiplini olarak — rekabet avantajı haline geliyor. Bunu yapan ekiplerle yapmayan ekipler arasındaki fark, altı ay sonra çok net görünür hale geliyor.

Bu yazıda, sahada en çok kullanılan değerlendirme çatısı olan RAGAS'ı merkeze alarak dört temel metriği, bunların birlikte nasıl okunması gerektiğini, hangi araçların ne sunduğunu ve pratikte bir değerlendirme hattını nasıl kuracağınızı anlatacağım. Teorik bir makale değil bu; sahada karşılaştığım sorunlardan damıttığım pratik bir rehber.

Geleneksel yazılım testinde beklenen çıktı bellidir: fonksiyona X verirsin, Y beklersin, eşleşmezse test kırmızı yanar. RAG sistemlerinde böyle net bir eşleşme yok. Aynı soruya iki farklı, ama ikisi de doğru olan cevap verilebilir. Üstelik hata iki farklı katmanda ortaya çıkabilir:

1. Retrieval katmanı — sistem doğru dokümanları bulabiliyor mu?
2. Generation katmanı — bulduğu dokümanlardan doğru, tutarlı bir cevap üretebiliyor mu?

Bir RAG sistemi kötü cevap verdiğinde, bunun retrieval mi yoksa generation mı kaynaklı olduğunu ayırt edemezseniz, neyi düzelteceğinizi de bilemezsiniz. Embedding modelini mi değiştireceksiniz, chunk boyutunu mu küçülteceksiniz, yoksa prompt'u mu iyileştireceksiniz? Bu ayrımı yapabilmek, RAG değerlendirmesinin can alıcı noktası. RAGAS'ın (Retrieval Augmented Generation Assessment) tasarım felsefesi de tam olarak bunun üzerine kurulu: retrieval kalitesini ve generation kalitesini ayrı ayrı ölçüp, sonra birlikte yorumlamak.

Burada bir noktayı özellikle vurgulamak istiyorum: bu dört metriği tek tek, izole biçimde okumak sizi yanıltır. Faithfulness'ı yüksek ama context recall'u düşük bir sistem, "halüsinasyon yapmıyor ama eksik bilgi veriyor" demektir — kullanıcıya yarım doğru söylüyor olabilir. Context precision yüksek ama answer relevancy düşük bir sistem ise, doğru dokümanları bulmuş ama soruyu cevaplamak yerine konuyu dağıtmış olabilir. Dört metriği bir panel, bir kontrol paneli gibi birlikte okumak gerekiyor.

Faithfulness (Sadakat) — halüsinasyonu yakalar

Faithfulness, üretilen cevaptaki iddiaların kaç tanesinin gerçekten retrieved (getirilen) bağlam tarafından desteklendiğini ölçer. Pratikte şöyle çalışır: cevap önce atomik iddialara (claim) bölünür, sonra her iddia bağlamla karşılaştırılarak "bu iddia bağlamdan çıkarılabiliyor mu" sorusu sorulur. Desteklenen iddia sayısının toplam iddia sayısına oranı faithfulness skorunu verir.

Bu metriğin hedef aldığı hata modu net: halüsinasyon. Bir LLM, elindeki bağlamda olmayan bir bilgiyi kendi parametrik hafızasından (ön eğitim verisinden) çekip cevaba sokabilir. Bazen bu bilgi doğru olabilir bile — ama RAG sisteminin bütün amacı, cevabı doğrulanabilir, kaynağa dayalı hale getirmekti. Bağlamda olmayan bir iddia, doğru olsa dahi, sistemin güvenilirliğini zedeler çünkü denetlenemez.

Sahada gördüğüm tipik örnek: bir İK chatbot'u, izin politikası dokümanından "yıllık izin 14 gündür" bilgisini getiriyor ama cevabında "ayrıca hastalık izni de bu sürenin içine dahildir" gibi bir cümle ekliyor — bu ikinci cümle bağlamda yok, modelin kendi genellemesi. Faithfulness metriği tam olarak bunu yakalamak için var.

Answer Relevancy (Cevap İlgisi) — konudan sapmayı yakalar

Answer relevancy, üretilen cevabın asıl soruyu ne kadar doğrudan adresleyip adresleşmediğini ölçer. Teknik olarak, cevaptan geriye doğru birkaç olası soru üretilir (LLM ile), bu üretilmiş sorular ile orijinal kullanıcı sorusu arasındaki anlamsal benzerlik (embedding cosine similarity) hesaplanır. Cevap, orijinal soruyla ne kadar "eşleşen" sorular üretiyorsa, o kadar ilgili sayılır.

Bu metriğin hedef aldığı hata modu şu: sistem doğru bilgiyi bulmuş ve bağlama sadık kalmış olabilir, ama soruyu cevaplamamış olabilir. Örneğin kullanıcı "İzmir ofisinde uzaktan çalışma politikası nedir?" diye soruyor, sistem şirketin genel uzaktan çalışma politikasını anlatan uzun, doğru ama İzmir'e özgü olmayan bir metin döktürüyor. Bağlama sadık, halüsinasyon yok — ama kullanıcının asıl sorduğu şeye net bir cevap yok. Answer relevancy düşük çıkar.

Bunu faithfulness'tan ayırmak önemli çünkü ikisi birbirinden bağımsız eksenler: yüksek faithfulness + düşük answer relevancy kombinasyonu, "doğru ama alakasız" cevap üreten sistemleri işaret eder — genelde prompt tasarımı ya da soru anlama (query understanding) katmanında sorun vardır.

Context Precision (Bağlam Kesinliği) — retrieval gürültüsünü yakalar

Context precision, getirilen (retrieved) bağlam parçalarından kaçının gerçekten soruyla alakalı olduğunu ölçer. RAGAS'ta genelde sıralama duyarlı bir hesaplama kullanılır: en alakalı parçaların sıralamada üstte olması ödüllendirilir (bu, bilgi erişimindeki precision@k mantığına benzer).

Bu metrik saf retrieval kalitesini ölçer, generation'la ilgisi yoktur. Hedef aldığı hata modu: gürültülü retrieval. Sistem 5 doküman parçası getiriyor ama bunlardan sadece 1-2 tanesi soruyla ilgili, geri kalanı alakasız ya da kısmen ilgili. Bu durumda iki risk birden ortaya çıkar: (1) context window'u gereksiz bilgiyle dolduğu için model asıl önemli bilgiyi "kaybedebilir", (2) alakasız parçalar modelin dikkatini dağıtıp yanlış bir sentez yapmasına yol açabilir.

Düşük context precision genelde şu nedenlerden kaynaklanır: chunk boyutu çok büyük veya çok küçük seçilmiş, embedding modeli domain'e uygun değil, ya da retrieval sırasında re-ranking (yeniden sıralama) katmanı eksik.

Context Recall (Bağlam Kapsayıcılığı) — eksik retrieval'ı yakalar

Context recall, doğru cevabı üretmek için gerekli olan bilginin ne kadarının gerçekten retrieved bağlamda yer aldığını ölçer. Bunu hesaplamak için genelde bir referans (ground truth) cevap kullanılır: referans cevaptaki iddialar tek tek alınır, her biri için "bu iddia getirilen bağlamdan destekleniyor mu" sorulur. Desteklenen iddiaların oranı context recall'u verir.

Hedef aldığı hata modu context precision'ın aynasıdır: eksik retrieval. Sistem getirdiği parçaların hepsi alakalı olabilir (yüksek precision) ama cevap için gereken kritik bir bilgiyi hiç getirmemiş olabilir (düşük recall). Örneğin bir sözleşme sorgusunda, ilgili maddenin bir istisnası ayrı bir bölümde geçiyorsa ve retrieval o bölümü hiç getirmemişse, model o istisnayı bilemez — çünkü elinde yok. Bu, faithfulness açısından "suçsuz" bir hata gibi görünür (model uydurmuyor), ama iş sonucu açısından eksik ve potansiyel olarak yanlış bir cevaba yol açar.

Context recall, sistemin index'i, chunking stratejisi ve top-k (kaç parça getirileceği) ayarıyla doğrudan ilgilidir. Bu metrik, referans cevap gerektirdiği için genelde sadece kürasyonu yapılmış bir "golden set" üzerinde ölçülebilir — üretimdeki canlı trafikte değil.

Bu dört metriği tek tek değil, birlikte, bir teşhis panosu gibi okumak gerekiyor. Aşağıdaki tablo, hangi kombinasyonun hangi kök nedeni işaret ettiğini özetliyor — sahada ekiplerle çalışırken en çok başvurduğum pratik çerçeve bu:

Bu tablonun asıl değeri şurada: retrieval kalitesi (context precision + context recall) ile generation kalitesi (faithfulness + answer relevancy) birbirinden matematiksel olarak ayrık ölçüldüğü için, bir düşüş gördüğünüzde nereye bakacağınızı biliyorsunuz. Bu ayrım olmadan, "cevap kötü" gibi genel bir şikayetle karşılaştığınızda embedding modelini mi değiştireceğinizi, prompt'u mu revize edeceğinizi, yoksa chunk boyutunu mu ayarlayacağınızı kestirmek neredeyse kör atış oluyor. Danışmanlık yaptığım ekiplerde en çok gördüğüm zaman kaybı, bu ayrımı yapmadan "biraz her şeyi değiştirip tekrar deneyelim" moduna girmek.

RAGAS metrikleri 0 ile 1 arasında normalize edilmiş skorlar üretir. Sahada gördüğüm ve genel kabul gören yorumlama aralıkları şöyle:

Bu eşikleri mutlak hakikat gibi değil, bir başlangıç pusulası gibi kullanmanızı öneririm. Örneğin yasal veya sağlık gibi yüksek riskli alanlarda çalışan bir sistem için 0.85 bile yeterli olmayabilir; oysa iç kullanım için hazırlanmış, düşük riskli bir bilgi asistanında 0.80 civarı kabul edilebilir olabilir. Önemli olan, kendi domain'iniz için bir taban çizgisi (baseline) belirlemeniz ve zaman içindeki değişimi izlemeniz. Skor tek başına bir sayı değil, bir trend olarak anlamlı: geçen ay 0.88 olan faithfulness skorunun bu ay 0.78'e düşmesi, mutlak değerden bağımsız olarak alarm zilidir — muhtemelen kaynak dokümanlar değişti, embedding modeli güncellendi ya da model sağlayıcısı arka planda bir versiyon güncellemesi yaptı.

Bir uyarı daha: bu skorlar LLM-as-judge yöntemiyle üretiliyor (bir sonraki bölümde detaylandıracağım), yani kendi içlerinde bir belirsizlik payı taşıyorlar. Aynı test setini iki kez çalıştırdığınızda skorlarda birkaç puanlık oynama görmeniz normal. Bu yüzden tek bir ölçümden ziyade, birden fazla çalıştırmanın ortalamasına ve trend çizgisine güvenmenizi öneririm.

Şimdi, sahada giderek daha sık karşılaştığım ve klasik RAGAS dörtlüsünün yakalayamadığı bir sorunu anlatmak istiyorum. Bir sistem faithfulness'ta 0.95 alabilir — yani ürettiği her iddia, getirdiği bağlamdan tam olarak destekleniyor olabilir — ve yine de işletme açısından tamamen yanlış, hatta zararlı bir cevap verebilir. Nasıl mı?

Diyelim ki sisteminiz getirdiği bağlama tamamen sadık kalıyor, hiçbir şey uydurmuyor. Ama getirdiği bağlam, altı ay önce güncellenmiş ama indekslenmemiş bir fiyat listesi. Ya da iki farklı departmanın çelişen prosedür dokümanlarından, yanlış olanı öne çıkarıyor. Ya da bir eski çalışanın kişisel notlarından oluşan, hiçbir zaman resmi kaynak olarak onaylanmamış bir belgeyi "kaynak" olarak kullanıyor. Bu üç durumda da faithfulness skoru yüksek çıkar — çünkü model gerçekten de bulduğu bağlama sadık kalmıştır. Ama cevap yanlıştır, çünkü bağlamın kendisi güvenilir değildir.

Bunu "beşinci boyut" olarak adlandırıyorum: context trustworthiness (bağlam güvenilirliği). Klasik dört metrik, "retrieved bağlam ile cevap arasındaki ilişkiyi" ölçer; ama bağlamın kendisinin ne kadar güvenilir bir kaynaktan geldiğini ölçmez. Bu, üç alt boyuta ayrılabilir:

• Sahiplik (ownership): Bu doküman kim tarafından onaylanmış, kim sorumlu? Resmi bir kaynak mı, yoksa bir kullanıcının kişisel notu mu?
• Güncellik (freshness): Bu bilgi ne zaman güncellendi? Sistemde hâlâ eski, iptal edilmiş bir versiyon mu duruyor?
• Kaynak izlenebilirliği (lineage): Bu bilgi hangi orijinal, kanonik kaynaktan türetildi? Birden fazla versiyon varsa, hangisi "doğru" kabul ediliyor?

Kurumsal RAG projelerinde bu üç sorunu gördüğüm en yaygın senaryo şu: bir şirket, yıllar içinde birikmiş SharePoint, Confluence, e-posta ekleri, eski sunumlar gibi karmaşık bir doküman yığınını olduğu gibi vektör veritabanına gömüyor. Hiçbir kürasyon, hiçbir "bu doküman güncel mi, kim onayladı" kontrolü yapılmıyor. Sonuç: sistem teknik olarak kusursuz çalışıyor (faithfulness, precision, recall hepsi yüksek), ama gerçek dünyada yanlış, güncelliğini yitirmiş cevaplar veriyor — çünkü beslendiği kaynak zaten güvenilmez.

Bunun pratik çözümü, değerlendirme hattınıza context trustworthiness kontrollerini eklemek:

1. Metadata zorunluluğu: Her doküman parçasına sahip birim, son güncelleme tarihi, onay durumu gibi metadata alanları ekleyin ve retrieval sırasında bunları filtreleme/ağırlıklandırma için kullanın.
2. Yaşlanma (staleness) uyarıları: Belirli bir tarihten eski dokümanları otomatik olarak "gözden geçirilmeli" işaretleyin, retrieval önceliğini düşürün.
3. Kanonik kaynak eşleştirmesi: Aynı konuda birden fazla doküman varsa, hangisinin "tek doğru kaynak" (single source of truth) olduğunu belirleyin ve çelişen versiyonları arşivleyin ya da retrieval'dan çıkarın.
4. Periyodik doküman denetimi: İnsan gözden geçirmesiyle, indekslenen içeriğin hâlâ doğru ve sahiplenilmiş olduğunu düzenli aralıklarla teyit edin.

Bu beşinci boyutu ölçmek, klasik RAGAS metrikleri kadar standartlaşmış değil henüz — sektörde bunun için tek, evrensel kabul görmüş bir metrik yok. Ama benim önerim, kendi organizasyonunuz için basit bir "trust score" tanımlamanız: örneğin retrieved parçaların yüzde kaçının son 6 ay içinde güncellenmiş ve sahiplenilmiş dokümanlardan geldiğini izleyen bir gösterge. Bu, RAGAS panelinize beşinci bir sütun olarak eklenebilir ve özellikle regülasyona tabi, yüksek riskli kurumsal kullanım senaryolarında faithfulness kadar kritik hale gelir.

Piyasada RAG değerlendirmesi için birkaç olgun açık kaynak çatısı var. Üçünü de farklı projelerde kullandım; her birinin güçlü ve zayıf yanları var.

RAGAS, adından da anlaşılacağı gibi özellikle RAG değerlendirmesi için doğmuş bir kütüphane. Faithfulness, answer relevancy, context precision, context recall gibi metrikleri hazır fonksiyonlar olarak sunuyor, LangChain ve LlamaIndex gibi popüler RAG çatılarıyla kolayca entegre oluyor. Hafif, hızlı kurulur, dokümantasyonu iyi. Özellikle "hızlı başlangıç" ve "RAG'a özel, derinlemesine metrik seti" isteyen ekipler için ilk tercihim.

TruLens, daha geniş bir "LLM uygulaması gözlemlenebilirliği" (observability) yaklaşımı sunuyor. RAG metriklerini de destekliyor ama asıl güçlü yanı, "feedback function" adını verdikleri esnek bir yapıyla kendi özel metriklerinizi tanımlayabilmeniz ve bunları canlı trafik üzerinde, dashboard'lar üzerinden izleyebilmeniz. Üretimdeki bir sistemi sürekli izlemek, zaman içindeki trend grafiklerini görmek isteyen ekipler için daha uygun.

DeepEval, "LLM için pytest" felsefesiyle geliştirilmiş bir kütüphane. RAG metriklerini de içeriyor ama kapsamı daha geniş: genel LLM çıktı değerlendirmesi, güvenlik (bias, toxicity) testleri, custom metrik tanımlama gibi özellikler sunuyor. Test-driven geliştirme kültürüne alışkın ekipler, DeepEval'i CI/CD pipeline'larına entegre etmeyi çok doğal buluyor çünkü sözdizimi gerçekten pytest'e benziyor.

Kısa bir karşılaştırma:

Pratikte bu üçü birbirini dışlamıyor; birçok ekip RAGAS'ı çekirdek metrik hesaplaması için, DeepEval'i CI/CD'de otomatik regresyon testi için, TruLens'i de üretimde sürekli izleme için birlikte kullanıyor. Benim önerim, küçük başlamak: önce RAGAS ile golden set üzerinde offline değerlendirme kurun, sistem olgunlaştıkça CI entegrasyonu ve canlı izleme katmanlarını ekleyin.

Hiçbir metrik, üzerinde çalıştığı test setinden daha iyi olamaz. RAG değerlendirmesinin en çok ihmal edilen ama en kritik adımı, iyi bir "golden set" — yani soru, beklenen bağlam ve referans cevaptan oluşan kürasyonu yapılmış bir test seti — oluşturmak.

İyi bir golden set şu unsurları içermeli:

• Gerçekçi sorular: Gerçek kullanıcı loglarından, destek taleplerinden, sık sorulan sorulardan derlenmiş sorular. Sentetik, "temiz" sorular yerine, kullanıcıların gerçekte nasıl yazdığını yansıtan (yazım hataları, eksik bağlam, birden fazla soruyu tek cümlede sorma gibi) örnekler içermeli.
• Zorluk çeşitliliği: Basit tek-doküman soruları kadar, birden fazla dokümanı sentezlemeyi gerektiren, ya da cevabı "hayır böyle bir bilgi yok" olması gereken sorular da olmalı (negatif örnekler, sistemin ne zaman "bilmiyorum" demesi gerektiğini test eder).
• Referans cevaplar: Domain uzmanları tarafından onaylanmış, doğru kabul edilen cevaplar. Bu, özellikle context recall hesaplaması için zorunlu.
• Edge case'ler: Çelişen bilgi içeren dokümanlar, güncelliğini yitirmiş içerik, çok teknik jargon içeren sorular gibi sınır durumlar.

Kaç soru yeterli diye sorarsanız, net bir sayı vermek yanıltıcı olur ama pratik deneyimim şu: birkaç düzine soruyla başlayıp (30-50 civarı), sistemin farklı kullanım senaryolarını (departman, konu başlığı, soru tipi) kapsayacak şekilde zamanla yüzlere çıkarmak makul bir yol. Önemli olan sayı değil, temsil gücü — üretimde karşılaşacağınız soru dağılımını gerçekten yansıtıp yansıtmadığı.

Golden set'i bir kere oluşturup rafa kaldırmayın. Kaynak dokümanlar değiştikçe, kullanıcı davranışı evrildikçe, yeni özellikler eklendikçe golden set'i de güncelleyin. Ben danışmanlık verdiğim ekiplere golden set'i "canlı bir doküman" gibi görmelerini, ürün yöneticisi ya da domain uzmanının düzenli olarak (örneğin aylık) gözden geçirip yeni örnekler eklemesini öneriyorum.

RAGAS, TruLens ve DeepEval gibi araçların çoğu, metrikleri hesaplamak için bir LLM'i "hakem" (judge) olarak kullanır — yani faithfulness'ı hesaplamak için bir başka (ya da aynı) LLM'e "bu iddia bu bağlamdan çıkarılabilir mi" diye sorarsınız. Bu yaklaşım güçlü çünkü ölçeklenebilir ve insan değerlendirmesine kıyasla çok daha ucuz. Ama bazı tuzakları var, bunları bilmeden kullanmak yanıltıcı sonuçlara yol açabilir:

Hakem modelin kendi önyargıları. LLM-as-judge, kendi eğitildiği verinin önyargılarını taşır. Örneğin bazı çalışmalar, hakem modellerin daha uzun cevapları sistematik olarak daha "iyi" değerlendirme eğiliminde olduğunu gösteriyor (uzunluk önyargısı). Kısa ama isabetli bir cevap, uzun ama gevşek bir cevaptan daha düşük puan alabilir.

Hakem ile üretici aynı model ailesi olduğunda öz-değerlendirme yanlılığı. Eğer cevabı üreten model ile onu değerlendiren model aynı aile/sağlayıcıdansa (örneğin ikisi de aynı şirketin modeliyse), model kendi tarzını "daha doğal" bulup sistematik olarak daha yüksek puan verme eğilimine girebilir. Mümkünse, üretici ve hakem modelleri farklı sağlayıcılardan seçmek daha sağlıklı bir sinyal verir.

Determinizm eksikliği. LLM tabanlı hakemler, aynı girdiye her seferinde birebir aynı puanı vermeyebilir. Bu yüzden tek seferlik bir ölçüme aşırı güvenmek yerine, birden fazla çalıştırmanın ortalamasına bakmak, mümkünse sıcaklık (temperature) parametresini düşük tutmak faydalı.

İnce nüansları kaçırma. LLM hakemler, yüzeysel olarak "doğru görünen" ama aslında ince bir şekilde yanlış olan cevapları her zaman yakalayamaz — özellikle sayısal hesaplamalar, tarih/zaman mantığı, ya da domain'e özgü teknik terimler söz konusu olduğunda. Bu tür kritik alanlarda, LLM-as-judge skorlarını mutlak gerçek olarak değil, bir ön filtre olarak kullanıp, düşük skor alan ya da riskli görünen örnekleri insan gözden geçirmesine yönlendirmek en sağlıklı yaklaşım.

Kısacası: LLM-as-judge, insan değerlendirmesinin yerine geçen değil, onu ölçeklendiren bir araç olarak görülmeli. Ben ekiplere şunu öneriyorum: LLM-as-judge'ı geniş ölçekli, sürekli izleme için kullanın; ama belirli aralıklarla (örneğin çeyreklik), golden set'in bir alt kümesini insan uzmanlara da değerlendirtip, LLM hakemin skorlarıyla insan skorları arasındaki korelasyonu kontrol edin. Korelasyon düşükse, hakem prompt'unu ya da hakem modelini gözden geçirin.

RAG değerlendirmesinin gerçek değeri, onu geliştirme döngüsünün doğal bir parçası haline getirdiğinizde ortaya çıkıyor. Bunun en pratik yolu, RAGAS ya da DeepEval gibi araçları CI/CD pipeline'ınıza entegre etmek — yani her kod değişikliği, her prompt güncellemesi, her embedding modeli değişikliği, otomatik olarak golden set üzerinde çalıştırılıp skorlar üretiliyor ve eşik değerin altına düşen bir metrik varsa build başarısız oluyor.

Basit bir örnek akış şöyle görünebilir:

# .github/workflows/rag-eval.yml (kavramsal örnek)
name: RAG Evaluation
on: [pull_request]
jobs:
  evaluate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Golden set üzerinde RAGAS değerlendirmesi çalıştır
        run: python scripts/run_ragas_eval.py --dataset golden_set.jsonl
      - name: Eşik kontrolü
        run: |
          python scripts/check_thresholds.py \
            --faithfulness-min 0.85 \
            --context-recall-min 0.80 \
            --fail-on-regression

Bu tarz bir kurulumun getirdiği en büyük fayda, regresyonu erken yakalamak. Bir mühendis prompt'u "iyileştirmek" için değiştirdiğinde, farkında olmadan faithfulness'ı düşürebilir. Chunk boyutunu değiştiren bir ekip, context recall'da sessiz bir düşüşe neden olabilir. Bu değişiklikler, otomatik değerlendirme olmadan genelde haftalar sonra, kullanıcı şikayetleri üzerinden fark edilir. CI'a entegre bir eval seti, bu tür regresyonları merge edilmeden önce yakalar.

Pratik öneriler:

• Eşik değerleri kademeli koyun. Başta gevşek eşiklerle başlayıp (örneğin 0.75), sistem olgunlaştıkça sıkılaştırın (0.85'e doğru).
• Her metrik için ayrı eşik tanımlayın. Tek bir "ortalama skor" yerine, faithfulness, context recall gibi metriklerin her biri için ayrı minimum değer belirleyin — çünkü bir metrikteki iyileşme diğerindeki kötüleşmeyi maskeleyebilir.
• Maliyeti kontrol edin. LLM-as-judge çağrıları maliyetli olabilir; her PR'da tüm golden set'i çalıştırmak yerine, temsili bir alt küme kullanıp, ana branch'e merge öncesinde tam seti çalıştırmak makul bir denge olabilir.
• Sonuçları görünür kılın. Skorları sadece CI loglarında bırakmayın; bir dashboard'a (TruLens gibi araçlar bunu doğal olarak sunuyor) aktarıp trend olarak izleyin.

Somutlaştırmak için, sahada sık karşılaştığım bir senaryoyu anlatayım. Bir Türk bankası ya da finans kuruluşu düşünün: müşteri hizmetleri temsilcilerine yardımcı olmak için, iç prosedürler, ürün şartları, kampanya koşulları ve mevzuat dokümanlarını içeren bir RAG asistanı kuruluyor. Temsilci bir soru soruyor ("kredi kartı ekstre itirazında süre sınırı nedir?"), sistem ilgili prosedürden cevap üretiyor.

Bu senaryoda dört metriğin hepsi kritik ama farklı nedenlerle:

• Faithfulness kritik çünkü temsilci, sistemin söylediğini müşteriye doğrudan aktarabilir; bir halüsinasyon, müşteriye yanlış bilgi verilmesine, hatta düzenleyici kurumlarla (BDDK, SPK gibi) sorun yaşanmasına yol açabilir.
• Context recall kritik çünkü mevzuata dayalı süreçlerde (itiraz süreleri, faiz oranı değişiklik bildirimleri gibi) bir istisna ya da güncel değişikliğin atlanması, hem müşteri mağduriyetine hem de kurumsal riske yol açar.
• Context trustworthiness (beşinci boyut) burada özellikle kritik: finans sektöründe mevzuat sık değişiyor, kampanya koşulları dönemsel. Sistem geçen çeyreğin kampanya koşullarını güncel diye sunarsa, teknik olarak "sadık" bir cevap vermiş olsa bile iş sonucu yanlıştır.

Bu tür bir sistemde önerim, golden set'i sadece genel sorulardan değil, düzenli olarak güncellenen mevzuat ve kampanya dokümanlarından türetilmiş, "bu bilgi güncel mi" testlerini de içerecek şekilde kurmak. Ayrıca faithfulness ve context recall için eşikleri genel kullanım senaryolarına göre daha sıkı tutmak (örneğin 0.90 üzeri) makul, çünkü hata maliyeti yüksek.

KVKK ve veri yönetimi boyutu

Golden test seti oluştururken, özellikle bankacılık, sağlık ya da İK gibi hassas veri içeren alanlarda, KVKK (Kişisel Verilerin Korunması Kanunu) kapsamında dikkat edilmesi gereken birkaç nokta var:

• Gerçek müşteri verisiyle test seti kurmak riskli. Golden set'i gerçek üretim loglarından türetirken, kişisel verileri (isim, TC kimlik no, hesap numarası, telefon gibi) anonimleştirmek ya da maskelemek gerekiyor. Test/eval ortamında bile, gerçek kişisel veri kullanmak KVKK kapsamında bir "işleme" faaliyetidir ve amaca uygunluk, veri minimizasyonu gibi ilkelere tabi.
• Sentetik veriyle destekleme. Mümkün olduğunca, gerçekçi ama sentetik (üretilmiş) test senaryoları kullanmak, hem KVKK riskini azaltır hem de test setini istediğiniz edge case'lerle zenginleştirmenizi kolaylaştırır.
• Denetlenebilirlik (auditability). Değerlendirme sürecinin kendisi de denetlenebilir olmalı — hangi golden set kullanıldı, hangi eşikler uygulandı, hangi versiyon üretime alındı gibi kayıtların tutulması, hem iç denetim hem de olası düzenleyici inceleme durumunda önemli. RAG sisteminizin faithfulness ve context trustworthiness skorlarını zaman içinde loglamak, "bu sistemi nasıl doğruladık" sorusuna somut bir cevap vermenizi sağlar.

Bu, sadece bir uyumluluk formalitesi değil; aynı zamanda güven inşa etmenin bir yolu. Kurumsal müşterilerime hep şunu söylüyorum: bir RAG sisteminin ne kadar iyi çalıştığını gösteren bir metrik panosu, sadece mühendislik ekibi için değil, risk, uyum (compliance) ve üst yönetim için de bir güvence aracı. "Sistemimiz halüsinasyon yapmıyor" demek yerine, "faithfulness skorumuz son üç ayda ortalama 0.91, ve context trustworthiness kontrolümüz her ay dokümanların güncelliğini teyit ediyor" demek, çok daha ikna edici ve savunulabilir bir pozisyon.

RAG değerlendirmesini bir kerelik proje teslim kriteri gibi değil, ürünün yaşam döngüsüne gömülü sürekli bir alışkanlık gibi kurmanızı öneririm. Mühendislik ekiplerinin büyük çoğunluğu artık bir şekilde RAG kullanıyor; bu, RAG kurmanın artık ayırt edici olmadığı, ama RAG'ı güvenilir ve ölçülebilir şekilde işletmenin ayırt edici hale geldiği anlamına geliyor. Faithfulness, answer relevancy, context precision ve context recall'u bir panel olarak izleyen, bunu CI/CD'ye gömen, golden set'ini canlı tutan ve context trustworthiness'i göz ardı etmeyen ekipler, sahada gördüğüm kadarıyla altı ay - bir yıl içinde belirgin biçimde öne çıkıyor: daha az kullanıcı şikayeti, daha hızlı hata teşhisi, ve en önemlisi, sistemlerine güvenen kullanıcılar.

Bu disiplini kurmak başta ekstra iş gibi görünebilir — golden set hazırlamak, eşik belirlemek, CI'a entegre etmek zaman alır. Ama bunu yapmamanın maliyeti çok daha yüksek: üretimde sessizce bozulan bir sistem, güven kaybı, ve en kötü ihtimalle regülasyona tabi bir sektörde ciddi bir uyum sorunu. Ben danışmanlık verdiğim her ekibe aynı şeyi söylüyorum: RAG'ı kurmak işin kolay kısmı, onu güvenilir tutmak asıl iş.