LLM tabanlı sistemlerde kaliteyi değerlendirmek, klasik “doğru–yanlış” eksenine indirgenemeyecek kadar çok boyutlu bir problemdir. Bu durum, özellikle Retrieval Augmented Generation (RAG) mimarilerinde daha da belirgin hâle gelir; çünkü üretilen cevabın kalitesi yalnızca modelin dil yeteneğine değil, geri döndürülen bağlamın doğruluğuna, yeterliliğine ve model tarafından nasıl kullanıldığına doğrudan bağlıdır. Dolayısıyla RAG mimarili bir LLM’i test etmek, tekil metrikler yerine farklı kalite boyutlarını birlikte ele alan sistematik bir değerlendirme yaklaşımı gerektirir.
Bu noktada derecelendirme puanı (Rubrics Score), RAG tabanlı sistemlerde üretilen cevapların genel kalitesini bütüncül biçimde değerlendirmek için kritik bir rol oynar. Rubrics yaklaşımı, cevap uygunluğu, bağlama sadakat, olgusal doğruluk ve eksiksizlik gibi birden fazla kalite kriterini tek bir yorumlanabilir skor altında toplar. Böylece, tek tek metriklerin sunduğu parçalı bakış açısı yerine, çıktının genel kalite seviyesini temsil eden standartlaştırılmış bir değerlendirme çerçevesi sunar.
Bu bölümde, Rubrics Score’un neyi ölçtüğünü, hangi kalite boyutlarını kapsadığını ve RAG mimarili LLM’lerin QA süreçlerinde neden vazgeçilmez bir metrik olarak konumlandığını ele alacağız.
İçerikler
Derecelendirme Puanı (Rubrics Score)
Derecelendirme puanı (Rubrics Score), önceden tanımlanmış kalite seviyeleri üzerinden üretilen cevabın genel kalitesini bütüncül olarak değerlendirmek amacıyla kullanılan bir metriktir. Bu yaklaşımda, üretilen cevabın tanımlı kalite seviyeleri içerisinde hangi puan aralığına karşılık geldiği belirlenir.
Puanlandırma seviyeleri genellikle 1 ile 10 arasında tanımlanır; ancak kullanılacak ölçek aralığı, sistemin ihtiyaç duyduğu hassasiyet seviyesine göre değişebilir. Tanımlanan her bir seviye için net, ayırt edici ve yorumlanabilir açıklamalar bulunur. Kaç adet seviye tanımlandıysa, her seviye için ilgili kalite beklentisini açıklayan karşılıklar yer alır.
Değerlendirme sürecinde, üretilen cevabın kalitesi; bu önceden tanımlanmış seviyeler esas alınarak yorumlayıcı (qualitative) bir yaklaşımla derecelendirilir ve karşılık gelen puan atanır. Bu sayede rubrics score, cevabın kalitesini yorumlanabilir, karşılaştırılabilir ve standartlaştırılmış tek bir puan olarak ifade eder.
Rubrics Score’un Kapsamı
Derecelendirme puanı, cevap uygunluğu (response relevancy), olgusal doğruluk (factual correctness), bağlama sadakat (faithfulness), açıklık ve tutarlılık, eksiksizlik (completeness) gibi kriterleri aynı anda dikkate alarak genel bir kalite değerlendirmesi yapar. Bu metrik, söz konusu kriterleri matematiksel olarak tek tek hesaplamaz; bunun yerine hepsini birlikte değerlendirerek yaklaşık ve bütüncül bir kalite puanı üretir.
Örnek Bir Puanlama Mantığı
Maksimum 5 puan üzerinden bir derecelendirme sistemi kurgulandığında, rubrics score aşağıdaki şekilde düşünülebilir:
Bağlama sadakati düşükse, 5 puan alamaz.
Bağlam sadakati ile birlikte cevap uygunluğu da düşükse 3 puan seviyesine düşer.
Olgusal doğruluğu da düşükse o zaman derecelendirme puanı 2-1 seviyesine düşer.
Bu yaklaşımda rubrics score, tek bir metriğin sonucunu değil, birden fazla kalite boyutunun birlikte değerlendirilmesini yansıtır.
Bir başka örnek olarak kalite seviyeleri aşağıdaki gibi tanımlanabilir :
rubrics = {
"5 Skor": "Soruya doğrudan cevap verir, olgusal olarak doğru, bağlama sadık, açık ve eksiksizdir.”,
"4 Skor": "Genel olarak doğru ve uygundur; küçük eksikler veya ifade sorunları içerir.”,
"3 Skor": "Kısmen doğru, yüzeysel ya da bazı kritik noktaları eksik bırakır.”,
"2 Skor": "Büyük eksikler içerir, alakasız bölümler barındırır veya yanlış yönelime sahiptir.”,
"1 Skor": "Soruya cevap vermez veya ciddi hatalar içerir.”
}Üretilen cevap, yukarıda tanımlanan kriterler referans alınarak değerlendirilir ve karşılık geldiği kalite seviyesine göre skorlandırılır. Burada verilen seviye tanımlamaları yalnızca örnek niteliğindedir. Daha önce de belirtildiği gibi, bu yapı sistemin ihtiyaç duyduğu hassasiyet düzeyine bağlı olarak 1–10 aralığında veya farklı ölçeklerde yeniden düzenlenebilir.
Bu noktaya kadar; dış kaynak olarak sağlanan dokümanların vektör veritabanında saklanması üzerine kurulu RAG mimarisini, bu mimarinin çalışma akışlarını değerlendirmek için kullanılan standart metrikleri, ayrıca bu metriklerin nasıl hesaplandığını ve neyi ifade ettiğini ele aldık.
Tahmin edileceği üzere, tüm bu metrikleri manuel olarak hesaplamak ve bu hesaplamaları sürekli biçimde tekrarlamak pratik ve sürdürülebilir değildir. Ancak bu ölçümler, kod aracılığıyla hesaplanabilir ve hatta tamamen otomatize edilebilir.
Özellikle sistemde gerçekleştirilen olağan güncellemeler, yeni dokümantasyon entegrasyonları veya mimari değişiklikler sonrasında, RAG tabanlı sistemin beklenen başarı kriterlerinin üzerinde performans gösterip göstermediğini doğrulamak amacıyla, sürekli çalışan otomatik testlere ihtiyaç duyulabilir. Bu sayede sistemin kalite seviyesi, zaman içerisinde ölçülebilir, izlenebilir ve sürdürülebilir hâle gelir.
Bu metriklerin otomatik olarak hesaplanabilmesi için, öncelikle LLM’in API erişimine sahip olunması gerekir. Özellikle üretilen cevap (response), geri döndürülen bağlam (retrieved chunks) ve mümkünse retrieval aşamasına ait ara çıktılar gibi bilgilere erişilmeden, sağlıklı bir ölçüm ve skorlandırma yapmak mümkün değildir.
Bazı metriklerin hesaplanmasında, geri döndürülen ilgili chunk’lar ya da vektör veritabanında yer alan tüm ilgili chunk’lar referans alınmaktadır. Örneğin bağlam hassasiyeti (context precision) ve bağlam kapsayıcılığı (context recall) gibi metriklerin otomatik olarak ölçülebilmesi için, geri döndürülen her bir chunk’ın kullanıcı sorusuyla gerçekten ilişkili olup olmadığının belirlenmesi gerekir. Bu noktada devreye bir “Judge LLM” (hakem model) girer.
Judge LLM, geri döndürülen chunk’ları kullanıcı sorusu bağlamında değerlendirerek, her bir chunk’ın ilgili veya ilgisiz olduğunu etiketler. Metrik hesaplamaları, bu etiketler üzerinden gerçekleştirilir. Bu amaçla, ChatGPT, Gemini gibi ayrı bir LLM hakem olarak kullanılabilir. Teknik olarak aynı modelin hem cevap üretimi hem de değerlendirme için kullanılması mümkün olsa da, bu yaklaşım bias (yanlılık) riski taşır. Bu riski azaltmak için genellikle; farklı bir modelin Judge LLM olarak kullanılması veya aynı modelin farklı bir konfigürasyonla (örneğin daha düşük temperature, farklı system prompt’lar) çalıştırılması tercih edilir. Böylece değerlendirme süreci daha objektif ve güvenilir hâle getirilir.
Şimdiye kadar, dış kaynak olarak sağlanan harici dokümanlar üzerinden çalışan RAG mimarisini ve bu akışın nasıl değerlendirildiğini ele aldık. Bir sonraki adımda ise, doküman tabanlı RAG’den farklı olarak, sistemin internet üzerinden yaptığı aramalarla çalışan RAG mimarisinin nasıl işlediğine bakalım.
İnternetten yapılan aramalarda sistem, ilgili anahtar kelimeler üzerinden bir arama motorunu veya belirli bir bilgi kaynağını tarar. Bu süreç sonucunda elde edilen içerikler, metin veya doküman parçaları hâlinde geri döndürülür. Sistem, bu metinsel verileri anlık olarak kendi içindeki alakalılık, benzerlik ve kalite filtrelerinden geçirerek LLM’in anlayabileceği bir bağlam yapısına dönüştürür ve prompt içerisine ekler.
İnternet üzerinden filtrelenerek elde edilen bu bilgiler, kalıcı olarak vektör veritabanına kaydedilmez. Bu akışta temel amaç, vektör tabanlı uzun süreli bir bilgi depolaması yapmak değil; arama sonuçlarının içerik uygunluğu, anahtar kelime bazlı alakalılığı ve kaynak güvenilirliği gibi faktörleri dikkate alarak, LLM’e geçici bir bağlam sunmaktır. Dolayısıyla internet araması sonucu elde edilen bilgiler, anlık bir geri döndürme (retrieval) işlemi olarak değerlendirilir ve vektör veritabanına dönüştürülerek saklanmaz.
İnternetten çekilen bilgi, veritabanını beslemek için değil; LLM’e gönderilen promptu zenginleştirerek, modelin daha doğru ve daha ilgili bir cevap üretmesini sağlamak amacıyla kullanılır. Sistem, internetten anlık olarak elde ettiği bilgileri kullanıcı sorusuyla birlikte tek bir prompt hâline getirir ve LLM bu geçici bağlam üzerinden cevabı üretir. Her yeni kullanıcı sorgusunda süreç baştan başlar; yeni bir arama yapılır ve önceki arama sonuçları bağlamdan çıkarılır.
RAG mimarisi, ister kullanıcı tarafından sağlanan harici dokümanlar üzerinden çalışsın ister internet araması yapsın, değerlendirme açısından aynı standart metriklerle ölçülür. Ancak bu metriklerin yorumu ve güvenilirliği, kullanılan bağlamın türüne göre farklılık gösterir.
Private RAG senaryosunda kaynaklar kontrollüdür, bağlam daha temizdir, sonuçlar daha stabildir ve ölçülen metrikler doğrudan sistem kalitesini yansıtır. Buna karşılık Internet RAG senaryosunda kaynaklar daha gürültülüdür, bağlam değişkendir, sonuçlar non-deterministic davranır ve metrikler sistem kalitesi ile internet kaynaklarının kalitesini birlikte ölçer.
RAG mimarili LLM’lerin güvenilir şekilde üretime alınabilmesi, yalnızca mimari doğrulamayla değil; ölçülebilir, tekrarlanabilir ve anlamlı QA metrikleriyle mümkün olur. Bu metrikler, sistemin nerede güçlü olduğunu ve hangi aşamalarda iyileştirmeye ihtiyaç duyduğunu net biçimde ortaya koyar.
AILLMJ7Q4MZ9T2X5N8R1K6VP3
