RAG Değerlendirmesi: Getirme ve Üretim Kalitesini Ayrı Ölçmek

RAG değerlendirme, bir RAG (Retrieval-Augmented Generation) sisteminin kalitesini tek bir uçtan uca skorla değil, getirme kalitesi ve üretim kalitesi olmak üzere iki ayrı katmanda ölçen ölçüm metodolojisidir. Bu ayrım kritiktir; çünkü "yanıt kötüydü" demek, sorunun yanlış belgeyi getirmekten mi yoksa doğru belgeyi yanlış kullanmaktan mı kaynaklandığını gizler.

Bir RAG sistemi kurmak görece kolaydır; onu güvenilir biçimde iyileştirmek zordur. İyileştirmenin ön koşulu ölçmektir — ve RAG'de ölçmek, yüzeyde göründüğünden çok daha incelikli bir iştir. Bu teknik rehberde rag değerlendirme konusunu bir mühendis titizliğiyle ele alıyoruz: tek skorun neden yanılttığını, getirme katmanının ölçütlerini (recall@k, precision@k, MRR, nDCG), üretim katmanının ölçütlerini (kaynak sadakati/faithfulness, yanıt ilgisi/answer relevance, groundedness), kaynak sadakatinin tam olarak nasıl hesaplandığını, LLM-as-a-judge yaklaşımını, hata tipine göre teşhisi, test kümesi kurmayı ve bakımını, regresyon testini ve sağlam bir ölçüm metodolojisinin gereklerini derinlemesine inceliyoruz. RAG'in temel mimarisini bilmiyorsanız önce RAG nedir kapsamlı rehberi ile başlamanızı öneririm; bu yazı o temeli, ölçüm ekseninde derinleştirir.

Tanım

RAG Değerlendirme (RAG Evaluation)

Bir RAG sisteminin kalitesini tek bir uçtan uca skorla değil, iki ayrı katmanda ölçen ölçüm metodolojisi: getirme kalitesi (doğru belge parçasının getirilip getirilmediği ve nasıl sıralandığı — recall@k, precision@k, MRR, nDCG) ve üretim kalitesi (yanıtın getirilen bağlama gerçekten dayanıp dayanmadığı — kaynak sadakati/faithfulness, yanıt ilgisi/answer relevance, groundedness). Katmanların ayrı ölçülmesi, sorunun getirmede mi üretimde mi olduğunu görünür kılar.

Ayrıca: RAG evaluation, RAG kalite ölçümü, getirme-üretim değerlendirmesi, RAG eval

RAG değerlendirmede en yaygın başlangıç hatası, sistemi tek bir "iyi mi kötü mü" skoruyla ölçmeye çalışmaktır. Bir dizi soruya yanıt üretirsiniz, bir hakem (insan veya model) bu yanıtları 1-5 arası puanlar, ortalamayı alırsınız ve "sistemimiz 3,8" dersiniz. Bu sayı bir şey söyler ama en kritik şeyi söylemez: yanıt neden kötüydü? Tek skor, bir RAG boru hattının birbirinden çok farklı iki başarısızlık modunu tek bir sayının altında ezer.

RAG mimarisinin iki büyük evresi vardır: getirme (retrieval) ve üretme (generation). Bir yanıt iki tamamen farklı nedenle kötü olabilir. Birinci senaryo: sistem yanlış belgeyi getirdi; model eline geçen alakasız bağlamla elinden gelenin en iyisini yaptı ama zaten kaybedilmiş bir eldi. İkinci senaryo: sistem tam doğru belgeyi getirdi ama model onu yok saydı, yanlış yorumladı veya bağlamda olmayan bir şey ekledi. Bu iki senaryonun uçtan uca skoru aynı olabilir — diyelim ikisi de "2/5" — ama gerektirdikleri müdahale taban tabana zıttır. Birincide chunking veya embedding'i, ikincide prompt'u veya modeli düzeltirsiniz.

İşte tek skorun maskelediği tam olarak budur. Uçtan uca bir sayı, "hastanın ateşi var" demek gibidir; teşhis koymaz. Oysa RAG değerlendirmenin amacı yalnızca not vermek değil, teşhis koymaktır. Bu yüzden olgun bir ölçüm metodolojisi, tek skoru bir üst düzey gösterge olarak tutar ama asıl kararları katman katman ölçümlere dayandırır. Getirme kalitesini ayrı, üretim kalitesini ayrı ölçersiniz; ancak o zaman "sistemim neden 3,8?" sorusuna eyleme dönüştürülebilir bir cevap verebilirsiniz.

Bir başka tuzak, uçtan uca skoru yanlış katmana atfetmektir. Ekipler çoğu zaman kötü yanıtları görünce refleksle daha büyük, daha pahalı bir üretim modeline geçer. Ama RAG hatalarının büyük kısmı üretimde değil getirmede doğar; getirme bozuksa dünyanın en güçlü modeli bile kurtaramaz. Bu refleksin neden yanlış olduğunu ve doğru teşhis akışını doğru dosya geliyor ama cevap neden yanlış yazısında somut örneklerle ele alıyorum.

RAG değerlendirmenin bel kemiği, sistemi iki bağımsız katman olarak görmektir. Bu katmanlar zincirleme çalışır: getirme, üretimin hammaddesini sağlar. Dolayısıyla getirme kalitesi bir tavan koyar — üretim, kendisine verilmeyen bilgiyi asla üretemez (uydurması hariç, ki tam da kaçınmak istediğimiz şey budur). Bu nedenle iki katmanı ölçerken sıralamaları da anlamlıdır: önce getirmeyi ölçersiniz, çünkü getirme kötüyse üretim skorunu yorumlamak anlamsızdır.

Getirme katmanı şu soruya cevap arar: "Sorunun cevabını içeren belge parçası, modele verilen bağlamın içine girdi mi ve ne kadar üstte sıralandı?" Bu katmanın çıktısı, üretim modeline gitmeden önce değerlendirilebilir; yani modeli hiç çağırmadan, yalnızca getirilen parçalara bakarak getirme kalitesini ölçebilirsiniz. Bu, ölçümü hem ucuz hem hızlı kılar. Getirme katmanının nasıl kurulduğunu — chunking, embedding, vektör araması, reranking — RAG mimarisi nasıl kurulur rehberinde ele alıyorum; değerlendirme, o mimarinin her halkasına bir ölçek tutar.

Üretim katmanı ise şu soruya cevap arar: "Model, kendisine verilen bağlamı kullanarak doğru, sadık ve eksiksiz bir yanıt yazdı mı?" Bu katmanı ölçmek doğası gereği daha zordur, çünkü "iyi yanıt" öznel bir kavramdır ve otomatik metriklerle yakalanması getirme metriklerinden daha incedir. Burada devreye kaynak sadakati, yanıt ilgisi ve eksiksizlik gibi ölçütler ile büyük ölçüde LLM-as-a-judge yöntemi girer.

RAG değerlendirmenin iki katmanı: ne sorar, neyle ölçülür, hangi katmanı düzeltir

Katman	Sorduğu soru	Örnek ölçütler	Kötüyse düzeltilecek yer
Getirme (retrieval)	Doğru parça bağlama girdi mi, ne kadar üstte?	recall@k, precision@k, MRR, nDCG, hit rate	Chunking, embedding, hibrit arama, reranking
Üretim (generation)	Yanıt bağlama sadık, ilgili ve eksiksiz mi?	Kaynak sadakati, yanıt ilgisi, eksiksizlik	Prompt, model seçimi, çıktı kısıtları
Bağlam (köprü)	Getirilen bağlam gereksiz gürültü taşıyor mu?	Context precision, context recall	Reranking, k sayısı, bağlam budama

Bu iki (aslında iki buçuk, çünkü bağlam bir köprü katmanıdır) katmanlı bakış, RAG değerlendirmeyi bir sanattan bir mühendislik disiplinine dönüştürür. Her katmanın kendi metrikleri, kendi test yöntemi ve kendi iyileştirme kaldıraçları vardır. İzleyen bölümlerde her katmanı tek tek, ölçütleriyle birlikte açıyoruz.

Getirme kalitesini ölçen metrikler bilgi getirimi (information retrieval) alanından gelir ve on yıllardır olgunlaşmıştır; RAG bu birikimi devralır. Bu metrikleri iki gruba ayırmak faydalıdır: sıralamadan bağımsız (bir belge ilk k içinde var mı, yok mu) ve sıralamaya duyarlı (var olması yetmez, ne kadar üstte olduğu da önemli).

Sıralamadan bağımsız metriklerin başında recall@k gelir. recall@k, bir soru için ilgili (doğru) belge parçalarının ne kadarının, getirilen ilk k parça içinde yer aldığını ölçer. Örneğin sorunun cevabını içeren tek bir altın parça varsa ve o parça ilk 5 sonuç içindeyse recall@5 = 1, değilse 0'dır. RAG için recall@k çoğu zaman en önemli metriktir; çünkü RAG'de temel kural şudur: doğru parça bağlama hiç girmezse, üretim modeli onu asla telafi edemez. Bu yüzden getirme değerlendirmesinde ilk hedef, recall@k'yı yüksek tutmaktır — model doğru bilgiyi hiç görmezse, gerisi konuşulmaz.

precision@k ise ilk k sonucun ne kadarının gerçekten ilgili olduğunu ölçer; yani getirilen bağlamın ne kadar "temiz" olduğunu gösterir. Düşük precision, modele bol miktarda alakasız gürültü verildiği anlamına gelir; bu hem maliyeti artırır hem de modelin dikkatini dağıtarak üretim kalitesini düşürür. RAG'de recall ile precision arasında bir denge vardır: k'yı büyütmek recall'ı artırır ama precision'ı düşürür. İşte reranking tam da bu dengeyi düzeltmek için vardır — geniş bir aday kümesiyle recall'ı yakalar, sonra en ilgili birkaçını öne alarak precision'ı yükseltir. Reranking'in bu roldeki değerini reranker nedir yazısında ayrıntılandırıyorum.

Sıralamaya duyarlı metriklerin en yaygını MRR (Mean Reciprocal Rank)'dır. MRR, ilk ilgili sonucun sıralamadaki konumunun tersini (1/sıra) alır ve tüm sorular üzerinden ortalar. İlk ilgili parça 1. sıradaysa katkı 1, 2. sıradaysa 0,5, 3. sıradaysa 0,33'tür. MRR, "kullanıcının veya modelin doğru cevaba ne kadar hızlı ulaştığı" sorusuna duyarlıdır; özellikle tek bir doğru cevabın olduğu senaryolarda anlamlıdır. nDCG (normalized Discounted Cumulative Gain) ise daha zengindir: hem birden fazla ilgili belgeyi hem de bunların alaka derecelerini (yalnızca ilgili/ilgisiz değil, "çok ilgili / az ilgili" gibi kademeli) dikkate alır ve üstteki isabetlere logaritmik olarak daha çok ağırlık verir. Sıralama tabanlı metriklerin ayrıntısı için mean average precision yazısı da faydalı bir referanstır.

Getirme metrikleri: ne ölçer, ne zaman öncelikli, dikkat noktası

Metrik	Ne ölçer	Ne zaman öncelikli	Dikkat
recall@k	İlgili parçaların k içinde yakalanma oranı	Neredeyse her RAG senaryosunda birincil	Altın etiket gerektirir; k seçimi kritik
precision@k	İlk k'nın ne kadarı gerçekten ilgili	Bağlam gürültüsü/maliyet önemliyse	Tek başına yanıltır; recall ile birlikte oku
MRR	İlk ilgili sonucun ortalama sırası	Tek doğru cevaplı sorularda	Birden çok ilgili belgeyi göz ardı eder
nDCG@k	Kademeli alaka + sıra ağırlığı	Çok ilgili belgeli, kademeli alaka	Kademeli etiketleme emeği ister

Pratik öneri: RAG değerlendirmeye recall@k ve nDCG@k ikilisiyle başlayın. recall@k size "doğru bilgiyi hiç getiriyor muyum" sorusunu, nDCG@k ise "getirdiğimde onu iyi sıralıyor muyum" sorusunu yanıtlar. k değerini, üretim modeline kaç parça verdiğinizle uyumlu seçin — bağlama 5 parça koyuyorsanız recall@5 anlamlı hedeftir. Bu metriklerin hepsi altın etiket (hangi parçanın doğru olduğu) gerektirir; test kümesi kurma bölümünde bu etiketleri nasıl oluşturacağımızı ele alacağız.

Getirme metrikleri ile üretim metrikleri arasında bir köprü katman vardır: getirilen bağlamın kalitesi. Bu, klasik recall@k'dan biraz farklı bir mercekle bakar; çünkü RAG'de "doğru belge geldi mi" sorusu kadar önemli olan "gelen bağlam, yanıtı üretmek için gereken ve yalnızca gereken bilgiyi içeriyor mu" sorusudur. Bu köprüyü ölçen iki kavram, context precision ve context recall'dır.

Context recall, sorunun altın cevabını üretmek için gereken tüm bilginin, getirilen bağlamda mevcut olup olmadığını ölçer. Bir yanıt üç olgu gerektiriyorsa ve bu üç olgudan yalnızca ikisi getirilen parçalarda varsa, context recall eksiktir; model üçüncü olguyu ya atlayacak ya da uyduracaktır. Bu metrik, getirme katmanının üretime yeterli hammadde sağlayıp sağlamadığını gösterir. Düşük context recall, neredeyse her zaman getirme tarafında bir soruna — yetersiz chunking, dar arama veya eksik belge — işaret eder.

Context precision ise getirilen bağlamdaki bilginin ne kadarının gerçekten yanıt için gerekli olduğunu ölçer; yani sinyal-gürültü oranını. Yüksek context precision, modele temiz bir bağlam verildiği; düşük context precision ise bağlamın alakasız parçalarla şişirildiği anlamına gelir. Bu önemlidir, çünkü dil modelleri bağlamdaki gürültüden olumsuz etkilenir ve özellikle uzun bağlamlarda ortadaki bilgiyi kaçırma eğilimindedir. Bağlamı reranking ile budamak ve k sayısını akıllıca sınırlamak, context precision'ı yükseltmenin başlıca yollarıdır. Hibrit aramanın bu köprü katmandaki katkısını hibrit arama ve RAG yazısında, chunking'in etkisini ise chunking stratejileri yazısında ele alıyorum.

Bu iki metrik, "getirme iyi mi" ile "üretim iyi mi" soruları arasındaki gri bölgeyi aydınlatır. Bazen getirme metrikleri (recall@k) iyi görünür ama üretim yine de zayıftır; nedeni çoğu zaman düşük context precision'dır — doğru parça geldi ama yanında o kadar çok gürültü geldi ki model boğuldu. Bu yüzden RAG değerlendirmede bağlam kalitesini ayrı bir mercek olarak tutmak, getirme ve üretim arasındaki nedenselliği çözmede çok işe yarar.

Getirme metriklerinin tamamı — recall@k, precision@k, nDCG — tek bir varsayıma dayanır: her soru için hangi belge parçasının "doğru" olduğunu biliyoruz. Bu bilgi, altın etiket (ground truth) olarak adlandırılır ve onu üretmek, RAG değerlendirmenin en zahmetli ama en belirleyici adımıdır. Etiket olmadan getirme metrikleri hesaplanamaz; kötü etiketle hesaplanan metrikler ise sizi güvenle yanlış yöne sürükler. Bu yüzden altın etiketlemenin nasıl yapıldığını iyi anlamak gerekir.

Altın etiketleme pratikte iki yaklaşımla yapılır. Birincisi, belge düzeyinde etiketleme: alan uzmanı, her soru için bilgi tabanındaki hangi belgenin (veya parçanın) cevabı içerdiğini işaretler. Bu en güvenilir yöntemdir ama emek yoğundur ve bilgi tabanı büyükse ölçeklenmesi zordur. İkincisi, cevaptan geriye etiketleme: önce altın cevap yazılır, sonra o cevabı destekleyen parçalar bilgi tabanında aranarak etiketlenir. Bu daha hızlıdır ama bir tuzak taşır — cevabı yazan kişi, yalnızca aklındaki tek kaynağı işaretleyip aynı bilgiyi içeren başka geçerli parçaları kaçırabilir; bu da sistemin aslında doğru ama "etiketlenmemiş" bir parça getirdiğinde haksız yere cezalandırılmasına yol açar.

Bu ikinci tuzak, getirme metriklerinde sistematik bir yanlılık yaratır ve fark edilmesi zordur. Çözümü, etiketlemeyi tekil değil çoğul yapmaktır: bir soru için cevabı içeren tüm geçerli parçaları işaretlemek. Ayrıca kademeli alaka (graded relevance) kullanmak — bir parçayı yalnızca "ilgili/ilgisiz" değil, "tam cevap / kısmi cevap / bağlamsal destek" gibi derecelerle işaretlemek — nDCG gibi kademeli metriklerin gerçek gücünü ortaya çıkarır. Kademeli etiketleme daha çok emek ister ama getirme kalitesinin çok daha ince bir resmini verir.

Altın etiketlemenin bir başka inceliği, etiketçiler arası uyumdur. Aynı soruya iki farklı uzman farklı parçalar işaretliyorsa, "doğru parça"nın tanımı belirsizdir ve metrikleriniz gürültülüdür. Bu yüzden ciddi bir değerlendirme kümesinde, en azından bir örneklem üzerinde birden çok etiketçi çalıştırılır ve aralarındaki uyum ölçülür; düşük uyum, ya soruların belirsiz ya da etiketleme rehberinin yetersiz olduğunu gösterir. Kısacası altın etiketleme, "birine sorup işaretletmek" değil, kendi başına bir kalite disiplini gerektiren bir süreçtir; getirme değerlendirmesinin tüm güvenilirliği bu temele dayanır. Chunking'in etiketlenebilir, anlamlı parçalar üretmedeki rolünü chunking stratejileri yazısında ele alıyorum.

Getirme doğru parçayı bağlama koyduktan sonra top üretim katmanına geçer. Üretim kalitesi, birbirini tamamlayan birkaç boyutta ölçülür ve bunları karıştırmamak önemlidir; çünkü bir yanıt bir boyutta mükemmel, başkasında berbat olabilir. Üç temel boyut öne çıkar: kaynak sadakati (faithfulness), yanıt ilgisi (answer relevance) ve eksiksizlik (completeness).

Kaynak sadakati (faithfulness), üretim katmanının kalbidir ve en çok konuşulan boyuttur: yanıttaki her iddia, getirilen bağlam tarafından destekleniyor mu? Yüksek sadakat, modelin yalnızca önündeki belgeye dayandığını; düşük sadakat, modelin bağlamda olmayan bir şeyi eklediğini (yani halüsinasyon yaptığını) gösterir. Kaynak sadakati, RAG'in en çok vaat ettiği faydanın — halüsinasyon azaltmanın — doğrudan sayısal ölçüsüdür. Halüsinasyonun doğasını ve neden tehlikeli olduğunu yapay zeka halüsinasyonu nedir yazısında ele alıyorum; kaynak sadakati, bu olguyu üretim ortamında yakalamanın sayısal aracıdır. Bir sonraki bölümü tümüyle bu metriğin nasıl hesaplandığına ayırıyorum.

Yanıt ilgisi (answer relevance), yanıtın sorulan soruyu gerçekten karşılayıp karşılamadığını ölçer. Bir yanıt tamamen sadık (bağlama %100 dayalı) olabilir ama soruyla alakasız olabilir — model doğru belgeden yola çıkıp yanlış soruya cevap verirse bu olur. Yanıt ilgisi, "bu cevap bu soruya mı yanıt veriyor" sorusunu ölçer ve genellikle yanıttan geriye doğru olası soruları üretip bunların orijinal soruyla benzerliğine bakarak hesaplanır. Sadakat ile ilgi birbirinden bağımsızdır: bir metni ölçerken ikisini ayrı tutmak şarttır.

Eksiksizlik (completeness / answer recall), yanıtın soruyu tam mı yoksa yarım mı yanıtladığını ölçer. Bağlamda cevabın üç parçası varken model yalnızca birini kullanıp cevabı yarım bırakırsa, sadakat yüksek (söyledikleri doğru) ama eksiksizlik düşüktür. Bu boyut, altın cevaptaki kaç anahtar noktanın üretilen yanıtta yer aldığını sayarak ölçülür. Bu üç boyuta pratikte iki tanesi daha eklenir: kaynak gösterme doğruluğu (yanıttaki atıflar gerçekten ilgili belgeyi mi işaret ediyor) ve güvenli ret / abstain (bilgi bağlamda yoksa model "bilmiyorum" diyebiliyor mu). İyi bir RAG sisteminin en değerli davranışlarından biri, cevap uydurmak yerine bilmediğini kabul etmesidir; bu davranışı ölçmek, RAG değerlendirmenin ihmal edilen ama kritik bir parçasıdır.

Kaynak sadakati soyut bir kavram gibi durur ama ölçümü şaşırtıcı derecede somut ve mekaniktir. Temel fikir şudur: bir yanıt, tek bir bütün olarak değil, içindeki tek tek iddialar (claim) düzeyinde değerlendirilir. Çünkü bir paragraf, doğru iddialar ile uydurma iddiaların bir karışımı olabilir; sadakati iddia düzeyinde ölçmek, bu karışımı ayrıştırır ve yüzeysel bir "genel olarak doğru görünüyor" izleniminden çok daha keskin bir sonuç verir.

Ölçüm süreci tipik olarak üç adımda işler. Birinci adım, iddia çıkarımıdır: üretilen yanıt, atomik (daha fazla bölünemeyen) doğrulanabilir ifadelere ayrıştırılır. Örneğin "Yıllık izin bir sonraki yıla devredilir ve en geç takip eden yılın sonuna kadar kullanılmalıdır" cümlesi iki ayrı iddiaya bölünür: (1) yıllık izin bir sonraki yıla devredilir, (2) devredilen izin takip eden yılın sonuna kadar kullanılmalıdır. İkinci adım, doğrulamadır: her iddia, getirilen bağlama karşı tek tek kontrol edilir — bu iddia bağlamdaki metinden çıkarılabiliyor mu, yoksa bağlamda hiç yok mu? Üçüncü adım, skorlamadır: sadakat skoru, bağlam tarafından desteklenen iddiaların toplam iddialara oranıdır. İki iddiadan ikisi de destekleniyorsa sadakat 1,0; biri destekleniyorsa 0,5'tir.

Bu sürecin her adımı pratikte bir dil modeli tarafından yürütülür — yani kaynak sadakati ölçümü, bir LLM-as-a-judge uygulamasıdır. Modelden önce iddiaları listelemesi, sonra her iddia için "bağlamda destekleniyor / desteklenmiyor" kararı vermesi istenir. Bu yaklaşım, açık kaynak değerlendirme kütüphanelerinde (örneğin Ragas gibi araçlarda) standartlaşmıştır; kaynak sadakati ve benzeri metriklerin bu araçlarla pratik uygulamasını RAG değerlendirme metrikleri ve faithfulness yazısında somutlaştırıyorum. Burada altını çizmek istediğim, mekanizmanın kendisidir: sadakat, "yanıta genel bir puan vermek" değil, "yanıtı iddialara bölüp her birini bağlama karşı denetlemek"tir.

Bu iddia-tabanlı ölçümün güzelliği, teşhise doğrudan bağlanmasıdır. Düşük bir sadakat skoru yalnızca bir sayı değildir; hangi iddiaların desteklenmediğini de gösterir. Böylece "model şu üç noktada bağlamın ötesine geçip uydurdu" gibi somut bir hata listesi elde edersiniz. Bu liste, prompt'u düzeltmek (örneğin "yalnızca bağlama dayan, bağlamda yoksa söyleme" talimatını güçlendirmek) veya modeli değiştirmek için doğrudan malzeme sağlar.

Nasıl Yapılır

Kaynak sadakati (faithfulness) skorunu hesaplama

Bir RAG yanıtının getirilen bağlama ne kadar sadık olduğunu iddia düzeyinde ölçmenin adımları.

1. 1

   İddiaları çıkar

   Üretilen yanıtı atomik, doğrulanabilir iddialara ayır; her cümleyi tek tek kontrol edilebilir ifadelere böl.

2. 2

   Her iddiayı bağlama karşı doğrula

   Her iddia için, getirilen bağlamdan çıkarılabilir mi diye 'destekleniyor / desteklenmiyor' kararı ver.

3. 3

   Skoru hesapla

   Desteklenen iddia sayısını toplam iddia sayısına böl; sonuç 0 ile 1 arası sadakat skorudur.

4. 4

   Desteklenmeyen iddiaları raporla

   Bağlamdan desteklenmeyen iddiaları teşhis için ayrıca listele; bunlar halüsinasyonun somut kanıtıdır.

5. 5

   Hakemi kalibre et

   İddia çıkarımı ve doğrulama kararlarının bir insan alt kümesiyle uyumunu düzenli olarak denetle.

Kaynak sadakati (faithfulness) ile yakın akraba ama ondan ayrı bir üretim kalitesi boyutu vardır: groundedness (dayanaklılık) ve onun somut yüzü olan atıf doğruluğu. Bu iki kavramı ayırmak önemlidir; çünkü RAG'in en değerli özelliklerinden biri olan "kaynak gösterme", ancak ayrı ölçüldüğünde güvenilir kalır. Bir RAG sistemi yalnızca doğru cevap vermekle kalmaz, o cevabı hangi belgeye dayandırdığını da göstermelidir — ve bu atıfların gerçekten doğru olması gerekir.

Groundedness, yanıtın bütününün getirilen bağlam tarafından desteklenip desteklenmediğini ölçer; faithfulness'ın iddia düzeyindeki ölçümüyle örtüşür ama daha çok "yanıt, bağlamın dışına taştı mı" sorusuna bütünsel bir bakıştır. Atıf doğruluğu ise daha spesifiktir: yanıtta gösterilen her kaynak (örneğin "[Belge 3]" veya bir dipnot), gerçekten o iddiayı destekleyen belgeyi mi işaret ediyor? Modeller bazen doğru cevap verir ama yanlış kaynağı gösterir — cevap doğrudur, atıf ise yanıltıcıdır. Bu, kullanıcı kaynağı tıklayıp doğrulamaya çalıştığında güveni sarsan, sinsi bir hata türüdür.

Atıf doğruluğunu ölçmek için yanıttaki her atıf tek tek denetlenir: gösterilen belge, o cümledeki iddiayı gerçekten içeriyor mu? Bu denetim, faithfulness ölçümüne benzer bir LLM-as-a-judge süreciyle otomatikleştirilebilir. İki metrik ortaya çıkar: atıf kapsamı (yanıttaki iddiaların ne kadarı bir kaynağa bağlanmış) ve atıf isabeti (bağlanan kaynakların ne kadarı gerçekten doğru). İyi bir RAG yanıtında ikisi de yüksek olmalıdır; düşük kapsam "model iddialarını kaynağa bağlamıyor", düşük isabet ise "model yanlış kaynağı gösteriyor" demektir.

Bu boyutun kurumsal önemi büyüktür. Hukuk, sağlık, finans gibi düzenlenen alanlarda bir yanıtın doğru olması yetmez; nereye dayandığının denetlenebilir olması gerekir. Atıf doğruluğu düşük bir sistem, doğru cevaplar verse bile denetime dayanamaz ve güven inşa edemez. Bu yüzden groundedness ve atıf doğruluğunu, faithfulness'tan ayrı bir mercek olarak RAG değerlendirmeye dahil etmek, özellikle yüksek riskli senaryolarda vazgeçilmezdir. Kaynak göstermeyi zorunlu kılan prompt tasarımı ile atıf doğruluğu ölçümünü birlikte kullanmak, halüsinasyonu hem azaltan hem görünür kılan güçlü bir ikilidir; halüsinasyonun bu bağlamdaki doğasını yapay zeka halüsinasyonu nedir yazısında ele alıyorum.

Üretim kalitesinin çoğu boyutu — sadakat, ilgi, eksiksizlik — insan tarafından değerlendirildiğinde en güvenilir sonucu verir; ama insan değerlendirmesi pahalı, yavaş ve ölçeklenemezdir. Binlerce yanıtı her sürümde elle puanlamak imkânsızdır. İşte LLM-as-a-judge tam bu boşluğu doldurur: bir dil modeli, başka bir modelin yanıtını belirli bir ölçüte göre puanlar. Bu, RAG değerlendirmeyi ölçekli ve tekrarlanabilir kılan anahtar tekniktir; ancak doğru kurulmazsa, güven verici görünen ama yanıltıcı skorlar üretir.

LLM-as-a-judge'ün güvenilirliği birkaç koşula bağlıdır. Birincisi net rubrik: hakem modele "bu iyi mi" diye sormak yerine, "yalnızca bağlamdan çıkarılabilen iddialar için 1 puan ver, bağlamda olmayan her iddia için 0 puan ver" gibi kesin bir ölçüt vermeniz gerekir. Muğlak talimat, tutarsız puan üretir. İkincisi düşük sıcaklık: hakem tekrarlanabilir olmalı, aynı girdiye aynı puanı vermelidir; bu yüzden değerlendirme çağrıları düşük sıcaklıkla yapılır. Üçüncüsü önyargı kontrolü: modeller uzun yanıtları daha iyi sanma (uzunluk önyargısı), ilk sunulan seçeneği tercih etme (konum önyargısı) ve kendi ürettiği metni kayırma (kendini kayırma) eğilimindedir; bu önyargılara karşı seçenek sırasını değiştirmek, uzunluğu normalize etmek gibi önlemler alınır.

En kritik disiplin ise hakemi denetlemektir. LLM-as-a-judge kurmak, ölçmeyi bir modele devretmektir; ama o modelin kendisi de bir ölçüm aracıdır ve kalibre edilmesi gerekir. Uygulamada bir insan alt kümesi tutulur: hakem modelin puanladığı örneklerin küçük ama düzenli bir bölümü insanlar tarafından da puanlanır ve iki puan seti arasındaki uyum (agreement) ölçülür. Uyum düşükse hakemin rubriği veya modeli düzeltilir. Bu yaklaşımın kurumsal ölçekte nasıl işletileceğini LLM-as-a-judge ve Ragas ile değerlendirme yazısında, genel model değerlendirme çerçevesini ise LLM değerlendirme nedir yazısında ele alıyorum.

RAG değerlendirmenin çoğu tartışması metriklerin doğruluğu üzerinedir; ama pratikte belirleyici bir kısıt daha vardır: maliyet. Kapsamlı bir değerlendirme ucuz değildir. Her sürümde yüzlerce soru üzerinde getirme metriklerini hesaplamak görece ucuzdur (model çağrısı yok), ama üretim metriklerini — faithfulness, yanıt ilgisi, atıf doğruluğu — LLM-as-a-judge ile ölçmek her soru için birden çok model çağrısı gerektirir. Büyük bir test kümesini her küçük değişiklikte tam ölçmek, hem para hem zaman açısından pahalıya patlar. Bu yüzden olgun ekipler bir otomasyon-maliyet dengesi kurar.

Bu dengeyi kurmanın birkaç pratik yolu vardır. Birincisi katmanlı ölçüm: her değişiklikte önce ucuz getirme metriklerini çalıştırın; yalnızca getirme iyileştiyse veya üretimi doğrudan etkileyen bir değişiklik yaptıysanız pahalı üretim değerlendirmesine geçin. İkincisi örnekleme: üretim metriklerini her sürümde tüm küme üzerinde değil, temsili bir alt küme üzerinde hesaplayın; tam ölçümü yalnızca yayın öncesi büyük kararlarda yapın. Üçüncüsü kademeli hakem: rutin regresyon için daha küçük ve ucuz bir hakem model, kritik kararlar için daha güçlü bir hakem kullanın — yeter ki ikisinin uyumunu önceden ölçmüş olun.

Maliyetin bir başka boyutu insan emeğidir. Altın etiketleme, altın cevap yazma ve hakem kalibrasyonu için insan zamanı gerekir ve bu, en pahalı kaynaktır. Bu yüzden insan emeğini en yüksek getirili yere odaklamak gerekir: rastgele örnekler yerine, otomatik metriklerin "belirsiz" veya "sınırda" işaretlediği örnekleri insana yönlendirmek (aktif öğrenme mantığı), aynı insan saatinden çok daha fazla değer üretir. Böylece insan, makinenin emin olduğu kolay örnekleri değil, gerçekten karar gerektiren zor örnekleri değerlendirir.

Doğru denge, körü körüne "her şeyi otomatikleştir" veya "her şeyi insana yaptır" değildir; ikisini akıllıca bölüştürmektir. Otomatik metrikler ölçeği ve tekrarlanabilirliği sağlar; insan, otomasyonun kalibrasyonunu ve zor kenar durumlarını üstlenir. Bu dengeyi bir kez kurup unutmak yerine, maliyeti ve kaliteyi birlikte izleyen bir pano üzerinden yönetmek gerekir. Değerlendirme altyapısının işletim maliyetini ve operasyonel yükünü LLMOps nedir yazısında daha geniş bir çerçevede ele alıyorum; RAG değerlendirme, bu operasyonun ölçülebilir ama maliyetli bir parçasıdır.

RAG değerlendirmede tekrar eden bir mimari soru şudur: sistemi bir bütün olarak mı (uçtan uca), yoksa her bileşeni ayrı ayrı mı (bileşen bazlı) ölçmeliyim? Doğru cevap "ikisi de, farklı amaçlarla"dır; çünkü bu iki yaklaşım birbirini tamamlayan farklı sorulara cevap verir ve birini diğerinin yerine koymak yaygın bir hatadır.

Bileşen bazlı değerlendirme, boru hattının her halkasını izole eder ve ayrı ölçer. Getirmeyi tek başına (üretim modelini hiç çağırmadan, yalnızca recall@k ve nDCG ile), reranking'i tek başına (reranking öncesi ve sonrası sıralama kalitesini karşılaştırarak), üretimi tek başına (getirmeyi sabit tutup yalnızca prompt/model değiştirerek) ölçebilirsiniz. Bu izolasyonun büyük değeri teşhistir: bir halka bozulduğunda hangisi olduğunu tam olarak gösterir. Ayrıca ucuzdur ve hızlıdır — getirme değerlendirmesi pahalı üretim modelini hiç çalıştırmaz. RAG'in bileşenlerini tek tek kurmayı kurumsal RAG sistemi tasarımı rehberinde ele alıyorum; değerlendirme de aynı bileşen sınırlarını izlemelidir.

Uçtan uca değerlendirme ise sistemi kullanıcının gördüğü haliyle, tüm halkalar birlikte çalışırken ölçer. Bunun değeri gerçekçiliktir: bileşenler ayrı ayrı iyi olabilir ama bir araya geldiklerinde etkileşim etkileri ortaya çıkar — örneğin getirme iyi, üretim iyi ama bağlam sıralaması modelin dikkatini yanlış yere çekiyor olabilir. Uçtan uca ölçüm, bu etkileşim hatalarını yakalar. Kullanıcının deneyimlediği gerçek kaliteyi yalnızca uçtan uca ölçüm gösterir.

Doğru strateji, ikisini bir hiyerarşi olarak kullanmaktır. Uçtan uca skor, üst düzey bir sağlık göstergesi olarak izlenir; düştüğünde alarm verir. Bileşen bazlı skorlar ise teşhis için devreye girer; "uçtan uca düştü, hangi bileşen suçlu" sorusunu yanıtlar. Bir başka güçlü teknik, ablasyondur: bir bileşeni geçici olarak devre dışı bırakıp (örneğin reranking'i kapatıp) uçtan uca skorun ne kadar değiştiğini görmek, o bileşenin gerçek katkısını sayısallaştırır. Bu, "reranking gerçekten değer katıyor mu, yoksa sadece maliyet mi" gibi soruları kanıta bağlar.

RAG değerlendirmenin belki de en pratik çıktısı, bir hatayı gördüğünüzde onu doğru katmana atfetmenizi sağlamasıdır. İki katmanı ayrı ölçtüğünüzde, dört olası durumun karşınıza çıktığını görürsünüz ve her biri farklı bir müdahale gerektirir. Bu dörtlü matris, RAG'de "körü körüne model değiştirme" refleksini bilime dönüştürür.

Birinci durum: getirme iyi, sadakat iyi. Sistem sağlıklı çalışıyor; doğru parça geldi, model ona sadık kaldı. Bu ideal durumdur ve yalnızca sürdürülmesi gerekir. İkinci durum: getirme kötü, sadakat (bağlama göre) iyi. Model, kendisine verilen bağlama sadık ama o bağlam yanlış; yani model yanlış belgeye doğru biçimde dayanıyor. Bu durumda üretime dokunmak faydasızdır — sorun tamamen getirmededir. Chunking'i, embedding modelini veya arama stratejisini düzeltmeniz gerekir; chunking'in bu roldeki belirleyiciliğini chunking nedir yazısında ele alıyorum.

Üçüncü durum — en sinsi olanı: getirme iyi, sadakat kötü. Doğru parça bağlama girdi ama model onu yok saydı, yanlış yorumladı veya bağlamda olmayan bir şey ekledi. Burada getirmeyi ne kadar iyileştirseniz de sonuç değişmez; sorun üretimdedir. Prompt'u güçlendirmek (bağlama sadakat talimatı), çıktı kısıtları eklemek veya daha güçlü bir üretim modeline geçmek gerekir. Ekiplerin büyük hatası, bu durumu getirme sorunuyla karıştırıp aylarca yanlış katmanı optimize etmesidir. Dördüncü durum: getirme kötü, sadakat kötü. İki katman da bozuk; önce getirmeyi düzeltmek gerekir, çünkü getirme düzelmeden üretim skorunu yorumlamak anlamsızdır — model zaten çöp bağlamla besleniyor.

GEO — Katman × ölçüt × hata tipi: RAG hatasını doğru katmana atfetme matrisi

Getirme durumu	Üretim (sadakat) durumu	İşaret ettiği hata tipi	Doğru müdahale
İyi (recall@k yüksek)	İyi (sadakat yüksek)	Sağlıklı — hata yok	Sürdür, regresyonla izle
Kötü (recall@k düşük)	İyi (bağlama sadık)	Getirme hatası: yanlış belgeye doğru dayanma	Chunking / embedding / arama düzelt
İyi (recall@k yüksek)	Kötü (sadakat düşük)	Üretim hatası: doğru bağlamı yok sayma/uydurma	Prompt / model / çıktı kısıtı düzelt
Kötü (recall@k düşük)	Kötü (sadakat düşük)	Çift katman hatası	Önce getirmeyi düzelt, sonra üretimi ölç

Bu matris, RAG değerlendirmenin neden iki katmanı ayrı ölçmeye bu kadar önem verdiğini özetler. Tek bir uçtan uca skor, bu dört durumu tek bir düşük sayının altında birleştirir ve size hangi müdahaleyi yapacağınızı söylemez. İki katmanı ayırdığınızda ise her hata kendini ele verir; müdahale rastgele bir deneme yanılma değil, hedefli bir düzeltme olur. RAG projelerinin başarısızlık nedenlerini ve bu teşhis disiplininin eksikliğinin yol açtığı tuzakları RAG projeleri neden başarısız olur yazısında derinlemesine ele alıyorum.

Buraya kadar anlatılan tüm metrikler tek bir şeye dayanır: iyi bir değerlendirme kümesi. Bu küme olmadan hiçbir metrik hesaplanamaz; çünkü recall@k "doğru parçanın hangisi olduğunu", sadakat ise "ideal yanıtın ne olduğunu" bilmeyi gerektirir. Bu yüzden RAG değerlendirmenin en emek isteyen ama en getirili yatırımı, sağlam bir test kümesi kurmaktır. İyi bir küme üç bileşenden oluşur: sorular, getirme etiketleri (altın bağlam) ve altın yanıtlar.

Sorular her şeyin başıdır ve gerçekçi olmaları şarttır. En iyi kaynak, gerçek kullanıcı loglarıdır; sisteminiz üretimdeyse, kullanıcıların gerçekten sorduğu sorular altın değerindedir çünkü gerçek dağılımı temsil eder. Sistem henüz üretimde değilse, alan uzmanlarıyla birlikte gerçekçi sorular yazılır. Kritik bir nokta çeşitliliktir: küme yalnızca kolay soruları değil, zor kenar durumları (belirsiz sorular, birden çok belgeyi gerektiren sorular, cevabı bilgi tabanında olmayan sorular) da içermelidir. Özellikle "cevabı yok" senaryolarını eklemek şarttır — çünkü iyi bir RAG sisteminin bilmediğinde susması gerekir ve bunu ancak bu senaryoları test ederek ölçebilirsiniz.

Getirme etiketleri, her soru için hangi belge parçasının (veya parçalarının) "doğru cevabı içerdiğini" işaretler. Bu etiketler recall@k, precision@k ve nDCG'nin hesaplanabilmesi için zorunludur. Etiketlemeyi alan uzmanları yapar; bu emek yoğun bir iştir ama pazarlık konusu değildir — etiketsiz bir küme, getirme metriklerini hesaplayamaz. Altın yanıtlar ise her soru için ideal cevabı gösterir ve eksiksizlik ile doğruluk ölçümünün referansıdır. Altın yanıtlar mutlaka insan tarafından yazılmalı veya en azından onaylanmalıdır.

Bu kümenin boyutu konusunda pratik bir denge vardır. Başlangıçta küçük ama temsili bir küme (birkaç düzine ilâ birkaç yüz soru) yeterlidir; amacınız istatistiksel mükemmellik değil, farklı hata modlarını yakalayabilecek kapsamdır. Zamanla küme, üretimden gelen gerçek hatalarla büyütülür: sistem yanlış yanıt verdiğinde, o soru düzeltilmiş altın yanıtıyla kümeye eklenir. Böylece küme, sisteminizin gerçek zayıflıklarının yaşayan bir kataloğuna dönüşür. Değerlendirme kümesi kurmanın operasyonel ayrıntılarını LLM değerlendirme çerçevesinde de ele alıyorum.

Bir değerlendirme kümesi, bir kez kurulup rafa kaldırılan bir belge değil, sistemle birlikte yaşayan bir varlıktır. RAG sistemleri sürekli değişir: belgeler güncellenir, chunking parametreleri ayarlanır, embedding veya üretim modeli yükseltilir, prompt revize edilir. Her değişiklik bir kaliteyi iyileştirebileceği gibi, fark edilmeden başka bir kaliteyi bozabilir. İşte değerlendirme kümesinin en güçlü kullanımı burada devreye girer: regresyon testi.

Regresyon testi mantığı yazılım mühendisliğinden gelir ve RAG'e birebir uygular: her değişiklikten sonra sabit test kümesini baştan sona çalıştırır, metrikleri önceki sürümle karşılaştırırsınız. Bir metrik iyileşirken bir başkası düştüyse — örneğin yeni chunking recall@k'yı artırdı ama precision'ı düşürdü — bunu değişikliği yayına almadan önce görürsünüz. Bu disiplin, RAG'de sessiz bozulmanın (silent regression) en büyük panzehridir; çünkü bir RAG sisteminde bir değişikliğin yan etkisi çoğu zaman görünmez ve yalnızca sistematik ölçümle yakalanır.

Kümenin bakımı da düzenli bir iştir. Bilgi tabanı değiştikçe bazı altın etiketler geçersizleşir — dün doğru olan belge parçası bugün güncellenmiş veya silinmiş olabilir; bu yüzden etiketler periyodik olarak gözden geçirilmelidir. Ayrıca kümenin, sistemin gerçek kullanımını temsil etmeye devam etmesi gerekir; kullanıcıların soru dağılımı zamanla kayarsa (yeni bir ürün, yeni bir konu), küme de güncellenmelidir. Bir başka tehlike, aşırı uyumdur (overfitting to the eval set): ekip aynı kümeye o kadar çok bakarak optimize eder ki, sistem o kümede mükemmel ama gerçek dünyada zayıf olur. Bunu önlemek için kümenin bir bölümü "kör" tutulur — düzenli optimizasyonda kullanılmaz, yalnızca ara ara genel sağlığı ölçmek için çalıştırılır.

Bu bakım disiplini, RAG değerlendirmeyi bir proje aşamasından bir işletim pratiğine taşır. Üretimdeki bir RAG sistemini ayakta tutan gözlemlenebilirlik ve operasyon disiplinini LLMOps nedir yazısında, üretim izleme araçlarını ise LLM gözlemlenebilirliği yazısında ele alıyorum; değerlendirme, bu operasyon döngüsünün ölçüm ayağıdır.

Şimdiye kadar anlattığımız her şey büyük ölçüde çevrimdışı değerlendirmedir: sabit bir test kümesi üzerinde, kontrollü koşullarda ölçüm. Ama gerçek dünya, test kümenizin öngöremediği sorular üretir. Bu yüzden olgun bir RAG değerlendirme yaklaşımı, çevrimdışı ölçümü çevrimiçi (üretimde, gerçek trafikte) ölçümle tamamlar. İkisi farklı sorulara cevap verir: çevrimdışı "bu değişiklik iyi mi", çevrimiçi "sistem gerçek kullanımda nasıl davranıyor".

Çevrimiçi değerlendirmenin en zengin kaynağı kullanıcı sinyalleridir. Açık geri bildirim (yanıtın altındaki beğen/beğenme, "bu yardımcı oldu mu"), üstü kapalı sinyaller (kullanıcı yanıtı kopyaladı mı, aynı soruyu yeniden sordu mu, konuşmayı terk etti mi) ve iş sonuçları (destek talebi çözüldü mü, insana devir gerekti mi) bir araya geldiğinde, gerçek kalitenin zengin bir resmini çizer. Bu sinyaller çevrimdışı metriklerle bir arada okunmalıdır: bazen çevrimdışı skorlar iyidir ama kullanıcı memnuniyeti düşüktür — bu, test kümenizin gerçek kullanımı temsil etmediğinin işaretidir ve kümeyi güncellemeniz gerektiğini söyler.

Çevrimiçi değerlendirmenin güçlü bir aracı A/B testidir: iki farklı RAG yapılandırmasını (örneğin iki farklı reranking stratejisini) gerçek trafiğin bölünmüş kısımlarına sunar ve iş metriklerindeki farkı ölçersiniz. Bu, çevrimdışı bir metrikteki iyileşmenin gerçek kullanıcı değerine dönüşüp dönüşmediğini kanıtlar — çünkü nDCG'deki küçük bir artış, kullanıcı memnuniyetinde her zaman fark yaratmayabilir. Ayrıca üretimde otomatik çevrimiçi ölçüm de kurulabilir: her gerçek yanıt için, örneklem bazında, bir LLM-as-a-judge ile sadakat skoru hesaplanıp bir panoya yazılır; sadakat belirli bir eşiğin altına düşerse alarm verilir.

Bu çevrimiçi-çevrimdışı döngü, RAG değerlendirmeyi kapalı bir devre haline getirir. Üretimden gelen gerçek hatalar ve düşük skorlu örnekler, çevrimdışı test kümesini besler; güncellenen küme, bir sonraki değişikliğin daha iyi değerlendirilmesini sağlar. Bu döngü ne kadar sıkı işlerse, sistem o kadar hızlı ve güvenilir biçimde iyileşir. RAG'i statik bir kurulum değil, bu döngüyle sürekli iyileşen bir ürün olarak görmek, üretim başarısının anahtarıdır.

RAG değerlendirmede en çok göz ardı edilen konu, ölçümün kendisinin bir metodoloji gerektirdiğidir. Bir metrik hesaplamak kolaydır; onu güvenilir, karşılaştırılabilir ve yanıltmayacak biçimde hesaplamak bir disiplindir. Sağlam bir ölçüm metodolojisi olmadan, ürettiğiniz skorlar sizi yanlış kararlara sürükler; iyileşme sandığınız şey gürültü, gerileme sandığınız şey rastlantı olabilir.

Birinci ilke yeterli örneklemdir. On soruluk bir kümede iki yanıtın düzelmesi, %20'lik bir "iyileşme" gibi görünür ama istatistiksel olarak gürültüdür. Metrikler arasında anlamlı karşılaştırma yapabilmek için kümenin yeterince büyük olması ve mümkünse skorlarla birlikte belirsizlik aralıklarının raporlanması gerekir. İkinci ilke sabit test kümesidir: iki sürümü karşılaştırırken tam olarak aynı soruları, aynı altın etiketlerle kullanmalısınız; küme değişirse skor farkının değişiklikten mi yoksa kümeden mi geldiğini bilemezsiniz. Üçüncü ilke değişkenleri izole etmektir: bir seferde tek bir şeyi değiştirin. Aynı anda hem chunking'i hem embedding modelini değiştirip skor iyileşirse, hangisinin işe yaradığını asla bilemezsiniz.

Sık yapılan hataların başında, hakem modelin belirleyiciliğini denetlememek gelir. LLM-as-a-judge'ün skorları, hakem modelin sürümü, sıcaklığı ve rubriği değiştikçe kayar; iki sürümü farklı hakem yapılandırmalarıyla ölçüp karşılaştırmak elmayla armutu karşılaştırmaktır. Bir başka hata, çevrimdışı metriği tek gerçek sanmaktır — nDCG'deki bir artış kullanıcı için hiçbir şey ifade etmeyebilir; metrikler vekildir, gerçek amaç değil. Üçüncü yaygın hata, "yanıt yok" senaryolarını göz ardı etmektir: sistemin uydurma yerine susma yeteneğini ölçmeyen bir değerlendirme, en tehlikeli hata sınıfını görmez. Dördüncüsü, test kümesine aşırı uyum: aynı kümeye sürekli optimize etmek, gerçek dünyada genellemeyen yapay kazanımlar üretir.

Sağlam görünen bir değerlendirme kümesi, iki sessiz kusur yüzünden yanıltıcı skorlar üretebilir: veri kaçağı ve zayıf temsil. Bu iki sorun, metrikler mükemmel çıksa bile sistemin gerçek dünyada beklendiği gibi çalışmayacağı anlamına gelir; bu yüzden RAG değerlendirmede özellikle dikkat edilmesi gereken tuzaklardır. İkisi de fark edilmesi zordur, çünkü yüzeyde her şey yolunda görünür — skorlar yüksektir, ekip memnundur, ama üretimde sistem hayal kırıklığı yaratır.

Veri kaçağı, test kümesindeki bilginin bir biçimde sistemin lehine "sızması"dır. En yaygın biçimi, sentetik soru üretiminde ortaya çıkar: bir model, belgelerden soru-cevap çiftleri ürettiğinde, sorular çoğu zaman belgedeki ifadeleri neredeyse birebir yansıtır. Böyle bir soru, gerçek kullanıcının kendi kelimeleriyle sorduğu sorudan çok daha kolaydır; sistem bu yapay soruları kolayca yanıtlar ve getirme metrikleri gerçekte olduğundan yüksek çıkar. Sonuç, gerçek kullanıcı diliyle test edildiğinde çöken sahte bir güvendir. Bu yüzden sentetik sorular mutlaka insan tarafından yeniden ifade edilmeli ve kümenin çekirdeği gerçek kullanıcı dilinden gelmelidir.

Temsil sorunu ise kümenin, sistemin gerçek kullanımını yansıtmamasıdır. Bir küme yalnızca kolay, sık sorulan sorulardan oluşuyorsa, yüksek skorlar sistemin gerçekten iyi olduğunu değil, yalnızca kolay soruları iyi yanıtladığını gösterir. Gerçek kullanım ise uzun kuyruk (long tail) sorularla, belirsiz ifadelerle, çok adımlı isteklerle ve cevabı bilgi tabanında olmayan sorularla doludur. Temsili bir küme, bu zorluk dağılımını bilinçli olarak içermelidir; kolay ve zor soruların oranı, gerçek trafiğin oranını yansıtmalıdır. Aksi halde metrikler, gerçek deneyimi değil, kümenin kolaylığını ölçer.

Bu iki sorunun ortak panzehiri, kümeyi gerçek üretim trafiğine sürekli bağlı tutmaktır. Sistem yanlış yanıt verdiğinde o soru, düzeltilmiş etiketiyle kümeye eklenir; kullanıcıların soru dağılımı kaydıkça küme güncellenir. Ayrıca kümenin bir bölümü "kör" tutularak — hiç optimizasyonda kullanılmadan — ara ara genel sağlığı ölçmek için çalıştırılır; bu, aşırı uyumu ve kaçağı yakalamanın etkili bir yoludur. Kısacası bir değerlendirme kümesi, ne kadar gerçek dünyayı temsil ederse o kadar değerlidir; laboratuvar koşullarında mükemmel ama gerçeği yansıtmayan bir küme, en tehlikeli türden bir öz güven üretir. RAG projelerinin bu tür değerlendirme kusurları yüzünden nasıl başarısız olduğunu RAG projeleri neden başarısız olur yazısında ayrıca ele alıyorum.

RAG değerlendirmenin genel ilkeleri dilden bağımsızdır; ama Türkçe içerikle çalışırken bazı özel zorluklar öne çıkar ve bunları göz ardı etmek skorları sessizce yanıltır. Türkçenin eklemeli (agglutinative) yapısı, zengin çekim sistemi ve morfolojik üretkenliği, hem getirme hem de üretim değerlendirmesini İngilizceden farklı kılar.

Getirme tarafında ilk zorluk, embedding kalitesinin ölçümüdür. Bazı çok dilli embedding modelleri Türkçeyi zayıf temsil eder; bu, recall@k'nın düşük çıkmasına yol açar ama nedeni her zaman görünmez. Bu yüzden Türkçe bir bilgi tabanında iki farklı embedding modelini aynı test kümesiyle karşılaştırmak — yani model seçimini genel popülariteye değil, sizin Türkçe verinizdeki getirme metriklerine dayandırmak — kritik önemdedir. Embedding'in getirme kalitesindeki belirleyici rolünü embedding nedir yazısında, anlamsal aramanın Türkçedeki inceliklerini ise semantik arama nedir yazısında ele alıyorum.

Üretim tarafında zorluk, kaynak sadakati ve yanıt ilgisi ölçümünün Türkçe metinlerde daha ince olmasıdır. İddia çıkarımı yapan LLM-as-a-judge, Türkçe cümleleri atomik iddialara bölerken İngilizceye göre daha çok hata yapabilir; çünkü Türkçenin uzun, çok yan cümleli yapısı iddia sınırlarını bulanıklaştırır. Bu yüzden hakem modelin Türkçe iddia çıkarımındaki tutarlılığını ayrıca denetlemek gerekir. Ayrıca altın yanıtların akıcı ve dilbilgisel olarak doğru Türkçe olması, eksiksizlik ölçümünün güvenilir olması için şarttır. Kısacası, Türkçe bir RAG sistemini değerlendirirken tüm kararları — embedding, chunking, üretim modeli, hakem modeli — Türkçe bir test kümesiyle doğrulamak, bu zorlukları yönetmenin en sağlam yoludur.

Otomatik metrikler ve LLM-as-a-judge, RAG değerlendirmeyi ölçekli kılar; ama insan değerlendirmesinin yerini tamamen alamazlar. Sorun şudur: otomatik ölçümlerin kendisi de vekildir ve zaman zaman gerçek kaliteden sapar. Bu sapmayı yakalayacak tek merci insandır. Bu yüzden insan değerlendirmesini "eskiden yapılan, artık otomasyonla aşılan" bir şey olarak görmek yanlıştır; doğru bakış, onu stratejik ve seçici biçimde kullanmaktır.

İnsan değerlendirmesinin vazgeçilmez olduğu birkaç durum vardır. Birincisi kalibrasyon: hakem modelin skorlarının gerçekle uyumunu ölçmek için düzenli olarak bir insan alt kümesi gerekir; bu olmadan LLM-as-a-judge'ün doğru ölçüp ölçmediğini asla bilemezsiniz. İkincisi yeni metrik veya rubrik tasarımı: bir ölçütü ilk tanımlarken, insan yargısı referans noktasıdır — otomatik metriği neye göre kalibre edeceğinizi insan belirler. Üçüncüsü öznel veya nüanslı boyutlar: ton, kültürel uygunluk, incelik veya bir hukuki ifadenin doğru derecelendirilmesi gibi konularda otomatik metrikler zayıftır; burada uzman insan yargısı şarttır.

Dördüncü ve belki en kritik durum, otomatik metriklerin çeliştiği veya şüphe uyandırdığı anlardır. Çevrimdışı skorlar yüksek ama kullanıcı memnuniyeti düşükse, ya da iki metrik zıt yönde işaret ediyorsa, aradaki gerçeği yalnızca insan incelemesi çözer. Bu yüzden olgun bir değerlendirme sürecinde insan, rutin ölçümü değil, otomasyonun denetimini ve zor kararları üstlenir. Bu, insan emeğini en değerli yere odaklayan bir iş bölümüdür: makine ölçeği, insan yargıyı sağlar.

Pratikte bu iş bölümü şöyle işler: otomatik metrikler sürekli çalışır ve büyük hacmi tarar; insan ise düzenli aralıklarla küçük ama dikkatli örneklemler değerlendirir, otomasyonu kalibre eder ve sınırda kalan örnekleri karara bağlar. Bu döngü, RAG değerlendirmeyi hem ölçekli hem güvenilir kılar. İnsanı tamamen devre dışı bırakan bir değerlendirme, kör bir otomasyona; insana tümüyle bağımlı bir değerlendirme ise ölçeklenemez bir darboğaza dönüşür. Ekiplerin bu dengeyi kurma yetkinliğini kazanması için gereken eğitim çerçevesini LLM değerlendirme nedir yazısında da ele alıyorum.

RAG değerlendirmeyi teorik olarak anlamak bir şey, onu bir sistemde adım adım kurmak başka bir şeydir. Aşağıdaki sıra, sıfırdan sağlam bir değerlendirme altyapısı kurmanın pratik yol haritasıdır. Sırayı takip etmek önemlidir; çünkü her adım bir öncekinin üzerine inşa edilir ve atlanan bir adım sonraki ölçümleri güvenilmez kılar.

Nasıl Yapılır

RAG değerlendirme altyapısını kurma sırası

Bir RAG sisteminde getirme ve üretim kalitesini ayrı ölçen bir değerlendirme altyapısını sıfırdan kurmanın adımları.

1. 1

   Değerlendirme kümesini kur

   Gerçek kullanıcı sorularından başlayarak, getirme etiketleri (altın bağlam) ve altın yanıtlarla küçük ama temsili bir küme oluştur; 'yanıt yok' senaryolarını dahil et.

2. 2

   Önce getirmeyi ölç

   Üretim modelini hiç çağırmadan recall@k, precision@k ve nDCG hesapla; getirme tavanını gör.

3. 3

   Bağlam kalitesini ölç

   Context precision ve context recall ile getirilen bağlamın yeterli ve temiz olup olmadığını değerlendir.

4. 4

   Üretimi ölç

   Kaynak sadakati (faithfulness), yanıt ilgisi ve eksiksizliği LLM-as-a-judge ile puanla; hakemi bir insan alt kümesiyle kalibre et.

5. 5

   Hata tipine göre teşhis et

   Getirme × üretim matrisine bakarak her hatayı doğru katmana ata; yanlış katmanı optimize etmekten kaçın.

6. 6

   Regresyon testine bağla

   Kümeyi her değişiklikte otomatik çalıştır; metrikleri önceki sürümle karşılaştırıp sessiz bozulmayı yakala.

7. 7

   Çevrimiçi sinyallerle kapat

   Üretimden kullanıcı sinyalleri ve düşük skorlu örnekleri toplayıp çevrimdışı kümeyi besle; döngüyü kapat.

Bu sıranın altında yatan tek bir ilke vardır: önce ucuz ve teşhis edici olanı ölç, sonra pahalı ve bütünsel olana geç. Getirme metrikleri ucuzdur (modeli çağırmaz) ve doğrudan teşhis eder; bu yüzden önce gelir. Üretim metrikleri pahalıdır (LLM-as-a-judge çağrıları gerektirir) ama daha bütünseldir. Çevrimiçi değerlendirme en gerçekçi ama en yavaş geri bildirimdir; en sona konur. Bu sırayı izleyen bir ekip, değerlendirme altyapısını hem hızlı kurar hem de her aşamada eyleme dönüştürülebilir bilgi üretir.

Metrikleri hesaplamak değerlendirmenin yalnızca yarısıdır; asıl değer, o skorları doğru yorumlayıp eyleme dönüştürmekten gelir. Ekiplerin sık düştüğü tuzak, bir skora bakıp "iyi" veya "kötü" demektir; oysa tek başına bir sayı — "faithfulness 0,82" — hiçbir anlam taşımaz. Bir skor ancak bir referansa göre anlam kazanır: önceki sürüme göre mi, bir hedefe göre mi, yoksa bir taban çizgisine göre mi? Yorumlamanın ilk kuralı, her skoru bir karşılaştırma bağlamına oturtmaktır.

İkinci kural, mutlak eşik yerine göreli değişime odaklanmaktır. RAG metriklerinin çoğu (özellikle LLM-as-a-judge kaynaklı olanlar) mutlak ölçekte gürültülüdür; bugünkü 0,82, dünkü 0,80'den anlamlı biçimde daha iyi olmayabilir. Ama aynı test kümesi, aynı hakem yapılandırmasıyla ölçülen iki sürüm arasındaki fark güvenilirdir. Bu yüzden "skorumuz kaç" sorusundan çok "değişiklik skoru hangi yöne, ne kadar oynattı" sorusu karar için daha kullanışlıdır. Mutlak skoru bir hedef gibi kovalamak, çoğu zaman gürültüyü kovalamaktır.

Üçüncü kural, tek bir metriğe değil metrik profiline bakmaktır. Getirme yükseldi ama üretim düştüyse, ya da faithfulness arttı ama eksiksizlik azaldıysa, bu bir kazanç değil bir takastır; hangi takasın kabul edilebilir olduğu, kullanım senaryosuna bağlıdır. Bir hukuk asistanında sadakat her şeyin önündedir; bir beyin fırtınası aracında eksiksizlik ve çeşitlilik daha değerli olabilir. Bu yüzden skorları yorumlarken, kurumun önceliğini metriklerin ağırlığına yansıtmak gerekir. Bu önceliklendirmeyi kurumsal bağlamda nasıl yapacağınızı RAG mimarisi nasıl kurulur yazısındaki tasarım kararlarıyla birlikte düşünmek faydalıdır.

Son olarak, skordan eyleme geçerken en değerli kaynak, skorun kendisi değil onun ardındaki hata örnekleridir. Düşük bir faithsizlik skoru size bir sayı verir; ama o skoru üreten desteklenmemiş iddialar listesi size tam olarak nerede müdahale edeceğinizi söyler. Bu yüzden olgun ekipler, toplu skorların yanında düşük skorlu somut örnekleri düzenli olarak inceler — çünkü gerçek iyileştirme fikirleri, ortalamalardan değil, tek tek başarısızlıkların incelenmesinden doğar. RAG değerlendirme, sonunda bir sayı üretmek için değil, bir sonraki iyileştirmeyi yönlendirmek için vardır.

Bir değerlendirme çerçevesi, ancak günlük geliştirme akışının bir parçası olduğunda gerçek değerini üretir. Kenarda duran, ara sıra elle çalıştırılan bir değerlendirme kümesi, zamanla ihmal edilir ve güncelliğini yitirir. Buna karşılık, değerlendirmeyi sürekli entegrasyon (CI) hattına bağlamak — yani her anlamlı değişiklikte otomatik çalışacak biçimde kurmak — RAG değerlendirmeyi bir niyetten bir güvenceye dönüştürür. Yazılımda testler nasıl her commit'te çalışıyorsa, RAG değerlendirme de her yapılandırma değişikliğinde çalışmalıdır.

Bunun pratik kurgusu şöyledir: chunking parametresi, embedding modeli, reranking ayarı veya prompt değiştiğinde, değerlendirme kümesi otomatik olarak baştan sona çalışır ve sonuç bir rapora yazılır. Rapor, kritik metrikleri önceki sürümle yan yana gösterir ve önemli bir düşüş varsa değişikliği "kırmızı" işaretler. Böylece bir iyileştirme sanılan değişikliğin aslında bir metriği bozduğu, yayına çıkmadan önce görülür. Bu, RAG'de en sinsi risk olan sessiz bozulmaya karşı en etkili savunmadır; çünkü otomatik kapı olmadan, bir gerileme çoğu zaman ancak kullanıcı şikayetiyle fark edilir — ki bu çok geçtir.

Bu entegrasyonun bir başka faydası, kararların nesnelleşmesidir. "Bu yeni embedding modeli daha iyi mi" tartışması, öznel izlenimlerle değil, aynı kümedeki getirme metriklerinin karşılaştırmasıyla çözülür. Ekip, sezgiyle değil kanıtla karar verir; bu, RAG geliştirmeyi bir deneme-yanılma döngüsünden bir mühendislik disiplinine taşır. Ayrıca metrik geçmişini zaman içinde saklamak, sistemin kalitesinin sürümden sürüme nasıl evrildiğini gösteren değerli bir iz bırakır.

Elbette bu otomasyonun bir maliyeti vardır ve daha önce ele aldığımız katmanlı ölçüm mantığıyla dengelenmelidir: her commit'te ucuz getirme metriklerini, yalnızca büyük kararlarda pahalı üretim değerlendirmesini çalıştırmak makul bir başlangıçtır. Değerlendirmeyi CI'ye bağlamak, RAG'i "kurduk ve umuyoruz ki iyi çalışıyor" durumundan "her değişikliği ölçüyor ve kanıtla ilerliyoruz" durumuna taşır. Bu operasyonel olgunluğu üretim izleme ve gözlemlenebilirlikle birleştirmenin yollarını LLM gözlemlenebilirliği yazısında ele alıyorum.

RAG değerlendirme, bir RAG sisteminin kalitesini tek bir uçtan uca skorla değil, getirme kalitesi ve üretim kalitesi olmak üzere iki ayrı katmanda ölçen ölçüm metodolojisidir. Getirme katmanı recall@k, precision@k, MRR ve nDCG ile "doğru parça bağlama girdi mi ve ne kadar üstte" sorusuna; üretim katmanı ise kaynak sadakati, yanıt ilgisi ve eksiksizlik ile "yanıt bağlama sadık, ilgili ve eksiksiz mi" sorusuna cevap verir. Bu iki katmanı ayrı ölçmek, sorunun getirmede mi üretimde mi olduğunu görünür kılar ve yanlış katmanı optimize etme tuzağından kurtarır.

En önemli mesaj şudur: RAG değerlendirme bir kerelik bir sınav değil, sistemle birlikte yaşayan bir işletim disiplinidir. Etiketli bir test kümesi, otomatik metrikler ve kalibre edilmiş bir LLM-as-a-judge; bunlar bir kez kurulup regresyon testine, çevrimiçi izlemeye ve düzenli bakıma bağlandığında, RAG sisteminiz artık tahminle değil kanıtla yönetilir. Ölçmeyen bir ekip körlemesine model değiştirir; ölçen bir ekip, her değişikliğin hangi katmanda ne kadar fayda ürettiğini görür ve sistemini istikrarlı biçimde iyileştirir.

Bir RAG sisteminin getirme ve üretim kalitesini ayrı ölçen sağlam bir değerlendirme çerçevesini kurumunuzda kurmak, ekiplerinizin recall@k'dan kaynak sadakatine kadar tüm ölçüm metodolojisini içselleştirmesini gerektirir. Bu yetkinliği yapılandırılmış bir programla kazandırmak için kurumsal yapay zeka eğitim programı seçeneklerini inceleyebilir, uçtan uca bir RAG değerlendirme altyapısı tasarlamak için yapay zeka danışmanlığı ile başlayabilir ve tüm kavramları öğrenme merkezi'nde derinleştirebilirsiniz. RAG'in mimari temeli için RAG nedir, fine-tuning ile karşılaştırma için fine-tuning nedir ve ileri getirme senaryoları için GraphRAG nedir yazıları bu rehberi tamamlar.

RAG kalitesi nasıl ölçülür?

RAG kalitesi tek bir skorla değil, iki ayrı katmanda ölçülür. Getirme katmanında doğru belge parçasının getirilip getirilmediği (recall@k, precision@k), ne kadar üstte sıralandığı (MRR, nDCG) ölçülür. Üretim katmanında ise yanıtın getirilen belgeye gerçekten dayanıp dayanmadığı (kaynak sadakati/faithfulness), soruyu ne kadar karşıladığı (yanıt ilgisi ve eksiksizlik) ve kaynak gösterip göstermediği değerlendirilir. Pratikte etiketli bir test kümesi, otomatik metrikler ve bir modelin başka bir modelin çıktısını puanladığı LLM-as-a-judge yaklaşımı birlikte kullanılır. Bu iki katmanlı rag değerlendirme, sorunun nerede olduğunu görünür kılar.

Sorun getirmede mi üretimde mi, nasıl anlarım?

Bunu anlamanın yolu iki katmanı ayrı ölçmektir. Getirme metrikleri iyiyse (doğru parça geldi ve üstte sıralandı) ama kaynak sadakati düşükse, sorun üretimdedir: model doğru bağlamı almış ama onu yanlış kullanıyor, uyduruyor ya da bağlamı yok sayıyor — bu bir prompt veya model sorunudur. Getirme metrikleri kötüyse (doğru parça hiç gelmedi veya çok geride kaldı), sorun getirmededir: chunking, embedding veya reranking katmanını düzeltmeniz gerekir. Bu ayrım, rag değerlendirmenin en pratik çıktısıdır; yanlış katmanı optimize edip zaman kaybetmenizi önler.

Kaynak sadakati (faithfulness) nedir?

Kaynak sadakati, bir RAG yanıtındaki her iddianın getirilen bağlam tarafından desteklenip desteklenmediğini ölçen üretim kalitesi metriğidir. Yüksek sadakat, modelin yalnızca önündeki belgeye dayandığını; düşük sadakat ise modelin bağlamda olmayan bir şeyi eklediğini (halüsinasyon) gösterir. Ölçüm için yanıt önce atomik iddialara bölünür, sonra her iddia getirilen bağlama karşı doğrulanır; skor, bağlamdan desteklenen iddiaların toplam iddialara oranıdır. Kaynak sadakati, RAG'in en çok vaat ettiği faydanın — halüsinasyon azaltmanın — doğrudan ve sayısal ölçüsüdür.

recall@k, precision@k, MRR ve nDCG arasındaki fark nedir?

Bunlar getirme kalitesini ölçen metriklerdir. recall@k, ilk k sonuç içinde ilgili belgelerin ne kadarının yakalandığını ölçer; RAG için genellikle en önemli metriktir, çünkü doğru parça hiç gelmezse üretim kurtaramaz. precision@k, ilk k sonucun ne kadarının gerçekten ilgili olduğunu ölçer. MRR (Mean Reciprocal Rank), ilk ilgili sonucun ortalama olarak kaçıncı sırada geldiğini ödüllendirir. nDCG, hem alaka derecesini hem de sırayı birlikte değerlendirir ve üstteki isabetlere daha çok ağırlık verir. RAG'de recall@k ile nDCG birlikte iyi bir başlangıç setidir.

RAG değerlendirme için test kümesi nasıl kurulur?

İyi bir test kümesi üç bileşenden oluşur: gerçekçi sorular, her soru için hangi belge parçasının doğru olduğunu gösteren getirme etiketleri (altın bağlam) ve ideal yanıtı gösteren altın cevaplar. Sorular öncelikle gerçek kullanıcı loglarından toplanır; kapsamı genişletmek için sentetik sorular üretilebilir ama mutlaka insan gözden geçirmesinden geçmelidir. Küme başlangıçta küçük ama temsili olmalı (farklı soru tiplerini, zor kenar durumları ve 'yanıt yok' senaryolarını kapsayacak şekilde), sonra üretimden gelen gerçek hatalarla büyütülmelidir. Bu küme, her değişiklikte çalıştırılan bir regresyon testi gibi kullanılır.

LLM-as-a-judge güvenilir mi, ne zaman kullanılır?

LLM-as-a-judge, bir dil modelinin başka bir modelin yanıtını belirli bir ölçüte (sadakat, ilgi, doğruluk) göre puanlaması yöntemidir ve insan değerlendirmesinin ölçeklenemediği yerlerde vazgeçilmezdir. Güvenilirliği koşulludur: net rubrikler, düşük sıcaklık, konum ve uzunluk önyargılarına karşı önlemler ve düzenli olarak bir insan alt kümesiyle kalibrasyon gerekir. Hakem modelin kendi tutarlılığı (aynı girdiye aynı puanı veriyor mu) ve insan etiketleriyle uyumu ölçülmelidir. İyi kurulduğunda LLM-as-a-judge, rag değerlendirmeyi ölçekli ve tekrarlanabilir kılar; körü körüne güvenilirse yanıltıcı olur.

Kısaca rag değerlendirme, bir RAG sisteminin kalitesini getirme kalitesi ve üretim kalitesi olmak üzere iki ayrı katmanda ölçen ölçüm metodolojisidir. Getirme katmanı recall@k, precision@k, MRR ve nDCG ile doğru parçanın bağlama girip girmediğini; üretim katmanı ise kaynak sadakati, yanıt ilgisi ve eksiksizlik ile yanıtın bağlama sadık, ilgili ve eksiksiz olup olmadığını değerlendirir. Katmanları ayrı ölçmek, hatayı doğru katmana atfetmenin ve yanlış optimizasyondan kaçınmanın tek yoludur. Sağlam bir ölçüm metodolojisi — etiketli test kümesi, kalibre edilmiş LLM-as-a-judge, regresyon testi ve çevrimiçi izleme — RAG'i tahminle değil kanıtla yönetmenizi sağlar.