RAG Sistemi Nasıl Test Edilir?

Şirket içi belgeleri kullanan bir yapay zekâ asistanı doğru cevap veriyor mu? Soruyla ilgili belgeyi bulabiliyor mu, yanıtını gerçekten o belgeye dayandırıyor mu, yoksa eksik bilgileri kendisi mi tamamlıyor? Bir RAG sistemi geliştirirken bu soruların yanıtını yalnızca birkaç örnek deneyerek anlamak mümkün değildir.

RAG (Retrieval-Augmented Generation), kullanıcının sorusuyla ilgili belgeleri arayan ve bulunan içeriği büyük dil modeline (LLM) bağlam olarak sunan bir yaklaşımdır. Bu mimaride başarının iki ayrı bileşeni vardır: doğru bilginin bulunması ve bulunan bilginin doğru bir yanıt üretmek için kullanılması.

Bu rehberde RAG sisteminin nasıl test edileceğini, hangi metriklerin izlenmesi gerektiğini, Python ile temel ölçümlerin nasıl hesaplanabileceğini ve sonuçlardan nasıl teknik hata teşhisi çıkarılabileceğini ele alıyoruz.

Kurum içinde çalışan LLM sistemlerinin genel mimarisi için On-Premise Yapay Zekâ ve Kurum İçi LLM Rehberi yazımıza, model sunumu ve çıkarım altyapısı için de vLLM Rehberi yazımıza göz atabilirsiniz.

RAG sistemi neden test edilmelidir?

Bir RAG uygulamasının yanıtı akıcı ve ikna edici görünebilir; ancak bu, yanıtın doğru olduğu anlamına gelmez. Sistem yanlış belgeyi getirebilir, önemli bir paragrafı atlayabilir veya doğru bilgileri yanlış yorumlayabilir.

Bu nedenle yalnızca son yanıtı kontrol etmek yeterli değildir. Belge arama aşamasını, modele sunulan bağlamı ve oluşturulan yanıtı ayrı ayrı değerlendirmek gerekir.

Örneğin, şirketin izin politikasını açıklayan bir asistanda üç farklı hata görülebilir:

• Belge bulma hatası: Sistem güncel izin politikasını bulmak yerine eski bir belgeyi getirir.
• Bağlam kullanma hatası: Doğru belge bulunur ancak önemli bir istisna modele sunulan metinde yer almaz veya model tarafından göz ardı edilir.
• Yanıt hatası: Model ilgili belgeyi görmesine rağmen izin süresini yanlış aktarır ya da kaynakta olmayan bir kural ekler.

Bu hatalar farklı nedenlere sahip olduğundan çözüm de aynı değildir. İlk durumda arama ve sıralama mekanizmasını, ikinci durumda belge parçalama ve bağlam seçimini, üçüncü durumda ise model davranışını ve yanıt üretme sürecini incelemek gerekir.

Güvenilir bir değerlendirme süreci, yalnızca sistemin doğru yanıt verip vermediğini değil, başarısız olduğunda hangi aşamada ve neden hata yaptığını da göstermelidir.

1. RAG testleri için veri kümesi nasıl hazırlanır?

Sağlıklı bir değerlendirme sürecinin başlangıç noktası, gerçek kullanım senaryolarını temsil eden bir test veri kümesidir. Her test kaydı mümkün olduğunca soruyu, beklenen bilgiyi, ilgili kaynak belgeleri ve kabul edilebilir yanıtı içermelidir.

Kurum içi doküman asistanı örneğinde test kümesini şu senaryolarla oluşturabilirsiniz:

• Cevabı bulunan sorular: Yanıtın hangi belgede ve bölümde yer aldığı bilinen sorular.
• Birden fazla belge gerektiren sorular: Yanıt için farklı kaynaklardaki bilgilerin birlikte değerlendirilmesi gereken durumlar.
• Güncel ve eski belgeler: Bir politika veya prosedürün eski sürümüyle güncel sürümünü ayırt etmeyi gerektiren sorular.
• Belirsiz sorular: Kullanıcıdan ek bilgi istenmesi gereken durumlar.
• Cevabı bulunmayan sorular: Bilgi tabanında destekleyici bir yanıt bulunmadığında sistemin bunu açıkça belirtmesi gereken durumlar.
• Yetki gerektiren sorular: Farklı kullanıcıların yalnızca erişim izni olan belgelerden yanıt alabildiğini sınayan senaryolar.

Her test için yalnızca örnek bir ideal yanıt yazmakla yetinmeyin. Gerektiğinde kabul edilebilir alternatifleri, beklenen kaynakları ve başarısızlık koşullarını da tanımlayın.

Örneğin bir sorunun yanıtlanması için iki ayrı belge gerekiyorsa, test kaydında her iki belgeyi de beklenen kaynak olarak işaretleyin. Aksi hâlde sistem gerekli kanıtlardan yalnızca birini getirse bile değerlendirme sonucu olduğundan başarılı görünebilir.

Test verilerini mümkün olduğunca eğitim veya ayar optimizasyonunda kullanılan örneklerden ayrı tutun. Aynı test kümesine defalarca bakarak sistemi iyileştirip ardından aynı kümede yüksek puan almak, gerçek kullanıcı sorularındaki başarıyı olduğundan iyi gösterebilir.

Test kayıtlarında hangi bilgiler bulunmalı?

Tekrarlanabilir bir değerlendirme için her test kaydında aşağıdaki alanların tutulması yararlıdır:

• Test sorusu ve senaryonun kimliği.
• Yanıtı destekleyen beklenen belge ve parça kimlikleri.
• Varsa referans yanıt ve kabul edilebilir alternatifler.
• Getirilen ilk k sonuç ve bunların sıralaması.
• Modelin ürettiği yanıt.
• Otomatik değerlendirme puanları ve gerektiğinde insan incelemesi sonucu.
• Kullanılan veri kümesi, embedding modeli, arama ayarları, istem ve LLM sürümü.

Bu bilgiler, iki sistem sürümü arasındaki farkı karşılaştırmayı ve bir değişikliğin hangi sonuçları etkilediğini belirlemeyi kolaylaştırır. Kullanıcı verileri veya kurum içi belgeler testlerde kullanılıyorsa gizlilik, erişim izinleri ve veri saklama politikaları da gözetilmelidir.

2. Belge getirme başarısı nasıl ölçülür?

RAG sisteminin ilk görevi soruyla ilgili belgeleri bulmaktır. Bu aşamadaki kalite yetersizse, güçlü bir dil modeli bile doğru yanıt üretmekte zorlanabilir.

Bilgi erişimi başarısını değerlendirmek için kullanılan temel metriklerden bazıları şunlardır:

• Precision@k: İlk k sonuç içinde bulunan ilgili belge veya parçaların, getirilen toplam sonuçlara oranını ölçer. İlgisiz sonuçların ne kadar fazla olduğunu anlamaya yardımcı olur.
• Recall@k: İlgili olduğu önceden belirlenmiş tüm belge veya parçaların ne kadarının ilk k sonuç içinde bulunduğunu ölçer. Sistemin gerekli bilgileri kaçırıp kaçırmadığını gösterir.
• MRR (Mean Reciprocal Rank): Her test sorgusu için ilk ilgili sonucun sırasının tersini hesaplar. İlk ilgili sonuç birinci sıradaysa puan 1, ikinci sıradaysa 1/2, dördüncü sıradaysa 1/4 olur. İlgili sonuç bulunamazsa sorgunun puanı 0 kabul edilir. MRR, bu puanların tüm test sorguları üzerinden ortalamasıdır.

Bu metrikleri hesaplamak için hangi belge veya parçaların gerçekten ilgili olduğunu belirleyen bir referans değerlendirme seti gerekir. İlgililik etiketleri uzman incelemesiyle oluşturulabilir. Bir dil modelinden değerlendirme amacıyla yararlanılıyorsa sonuçların güvenilirliği ayrıca kontrol edilmelidir.

Önemli ayrım: Precision@k ve Recall@k, getirilen sonuçların ilgililiğini ve kapsama oranını inceler. MRR ise yalnızca ilk ilgili sonucun sırasına odaklanır. Yanıtın oluşturulması için birden fazla belge gerekiyorsa MRR tek başına yeterli değildir.

Chunking ve overlap ayarları sonuçları nasıl etkiler?

Belge parçalama (chunking) ayarları erişim metriklerini doğrudan etkileyebilir. Çok küçük parçalar, yanıt için gerekli bilgiyi farklı parçalara bölebilir. Çok büyük parçalar ise ilgili bilginin çevresine gereksiz içerik ekleyebilir.

Parçalar arasındaki örtüşme (overlap), sınırda kalan bilgilerin kaybolmasını azaltabilir. Ancak aşırı örtüşme, birbirine çok benzeyen parçaların ilk k sonuçta yer kaplamasına ve farklı ilgili bilgilerin geri çağrılamamasına neden olabilir.

Bu nedenle chunk boyutu ve overlap için bütün sistemlerde geçerli tek bir ideal değer varsayılmamalıdır. Aynı test veri kümesi üzerinde farklı ayarlar denenmeli; Precision@k, Recall@k ve yanıt kalitesi sonuçları birlikte karşılaştırılmalıdır.

Doğru belge hiç getirilmiyorsa sorgu işleme, embedding modeli, metadata filtreleri veya parçalama stratejisi incelenebilir. Doğru belge getiriliyor ancak gerekli kanıtların tamamı bulunamıyorsa, daha fazla sonuç getirmek, sorguyu alt sorulara bölmek ya da arama sıralamasını iyileştirmek değerlendirilebilir. Hangi müdahalenin işe yaradığı ölçümle doğrulanmalıdır.

Belge getirme metriklerinin açıklamaları ve test yöntemleri için Microsoft Learn – RAG Bilgi Erişimi Değerlendirmesi rehberini inceleyebilirsiniz.

Uygulamalı örnek: RAG arama sonuçlarından hata teşhisi çıkarmak

Metrikleri tek tek tanımlamak, bir RAG sisteminin neden başarısız olduğunu anlamak için yeterli değildir. Bunun için beklenen kaynak parçalarını, arama sonuçlarını ve üretilen yanıtı birlikte incelemek gerekir.

Aşağıdaki tablo, şirket içi doküman asistanı için hazırlanmış temsili bir test kümesini gösterir. Belge kimlikleri örnek amaçlıdır; bunlar Absonet üzerinde gerçekleştirilmiş bir ölçümün veya herhangi bir üretim sisteminin gerçek sonuçları değildir.

Bu temsili dört sorgunun ortalama Precision@3 sonucu 0,25; Recall@3 ve MRR sonuçları ise 0,625’tir. Bu değerler bir kalite standardı veya kabul eşiği değildir. Amaç, metriklerin birbirinden farklı sorunları nasıl gösterebildiğini ortaya koymaktır.

Sonuçları nasıl yorumlamalı?

İkinci testte MRR katkısı 1,00 olmasına rağmen Recall@3 yalnızca 0,50’dir. Çünkü arama ilk sırada ilgili bir parça getirmiştir; ancak yanıt için gereken ikinci parça olan harcama limiti bulunamamıştır. Yalnızca ilk ilgili sonucun sırasına bakmak bu eksikliği gizleyebilir.

Üçüncü testte güncel 2026 belgesi yerine eski sürümlerin getirilmesi, yalnızca yanıt üreten modeli değiştirmekle çözülemeyebilecek bir veri erişimi veya sürüm filtreleme problemine işaret eder. Önce güncel belgenin sisteme alınıp alınmadığı ve arama katmanında doğru sürümün seçilip seçilmediği kontrol edilmelidir.

Dördüncü testte arama sonuçlarında beklenen parça bulunuyor olsa bile, bu durum kullanıcının belgeye erişim yetkisi olduğunu kanıtlamaz. Gerçek bir güvenlik testinde yetkisiz kullanıcının bu içeriği arama sonuçlarında veya yanıt içinde alamadığı ayrıca doğrulanmalıdır.

Bu örneklerin temel mesajı şudur: Tek bir genel puana bakmak yerine, her sorunun hangi kanıtları gerektirdiğini ve sistemin bu kanıtlardan hangilerini getirdiğini incelemek gerekir.

Python ile Precision@k, Recall@k ve MRR hesaplama

Aşağıdaki kod, herhangi bir ek Python kütüphanesi gerektirmeden temsili test kayıtları üzerinden üç metriği hesaplar. Kendi sisteminizde kullanırken örnek belge kimliklerini, beklenen kaynaklarınız ve arama sisteminizin döndürdüğü sonuçlarla değiştirmeniz gerekir.

from statistics import mean

tests = [
    {
        "expected": {"HR-2026-01"},
        "retrieved": [
            "HR-FAQ-02",
            "HR-2026-01",
            "HR-2025-01",
        ],
    },
    {
        "expected": {"IT-HW-03", "FIN-LIMIT-02"},
        "retrieved": [
            "IT-HW-03",
            "IT-FAQ-01",
            "HR-2025-01",
        ],
    },
    {
        "expected": {"HR-REMOTE-2026"},
        "retrieved": [
            "HR-REMOTE-2024",
            "HR-FAQ-02",
            "HR-REMOTE-2025",
        ],
    },
    {
        "expected": {"SEC-ACL-02"},
        "retrieved": [
            "SEC-ACL-02",
            "SEC-GUIDE-01",
            "HR-FAQ-02",
        ],
    },
]


def precision_at_k(expected, retrieved, k=3):
    expected = set(expected)
    top_k = retrieved[:k]

    if not top_k:
        return 0.0

    relevant_found = len(expected.intersection(top_k))
    return relevant_found / len(top_k)


def recall_at_k(expected, retrieved, k=3):
    expected = set(expected)

    if not expected:
        return 0.0

    relevant_found = len(expected.intersection(retrieved[:k]))
    return relevant_found / len(expected)


def reciprocal_rank(expected, retrieved):
    expected = set(expected)

    for rank, chunk_id in enumerate(retrieved, start=1):
        if chunk_id in expected:
            return 1.0 / rank

    return 0.0


precision_scores = [
    precision_at_k(test["expected"], test["retrieved"], k=3)
    for test in tests
]

recall_scores = [
    recall_at_k(test["expected"], test["retrieved"], k=3)
    for test in tests
]

rr_scores = [
    reciprocal_rank(test["expected"], test["retrieved"])
    for test in tests
]

print(f"Precision@3: {mean(precision_scores):.3f}")
print(f"Recall@3:    {mean(recall_scores):.3f}")
print(f"MRR:         {mean(rr_scores):.3f}")

Bu kodun örnek veri kümesi için beklenen çıktısı şöyledir:

Precision@3: 0.250
Recall@3:    0.625
MRR:         0.625

Bu hesaplamalar, her sorgu için ilgili olduğu önceden belirlenmiş kaynak parçalarını referans alır. Gerçek sistemlerde referans kaynakların eksik etiketlenmesi, farklı parçaların aynı kanıtı tekrar etmesi veya sorunun yanıtı için birden fazla belge gerekmesi sonuçların yorumlanmasını etkileyebilir. Bu nedenle metrikler, test senaryoları ve hata kayıtlarıyla birlikte değerlendirilmelidir.

3. Yapay zekâ yanıtının kalitesi nasıl ölçülür?

Doğru belgelerin bulunması tek başına yeterli değildir. RAG sisteminin bu belgeleri kullanarak soruya uygun, eksiksiz ve kaynaklarla desteklenen bir yanıt üretmesi gerekir.

Yanıt değerlendirmesinde dört önemli boyut bulunur:

• Kaynağa bağlılık (faithfulness veya groundedness): Yanıttaki iddiaların modele sunulan bağlam tarafından desteklenip desteklenmediğini değerlendirir.
• İlgililik (relevance): Yanıtın kullanıcının asıl sorusunu ne ölçüde karşıladığını inceler.
• Tamlık (completeness): Yanıtın sorunun gerektirdiği önemli bilgileri atlayıp atlamadığını değerlendirir.
• Doğruluk (correctness): Yanıtın referans cevap veya güvenilir kaynaklar karşısında olgusal olarak doğru olup olmadığını değerlendirir.

Bu metrikler birbirinin yerine geçmez. Örneğin bir yanıt, modele verilen belgeye tamamen bağlı olabilir ama kaynak belgenin kendisi eskiyse gerçek durum açısından yanlış olabilir. Benzer şekilde yanıt doğru bilgi içerse bile kullanıcının sorusunun önemli bir bölümünü cevaplamamış olabilir.

Değerlendirme sonuçlarını yorumlarken bu ayrımı korumak önemlidir. Tek bir genel puan, problemin belge aramada mı, kaynakların güncelliğinde mi, yoksa yanıt üretiminde mi olduğunu her zaman göstermez.

Yanıtı referansla karşılaştırmak

Referans yanıt kullanılan testlerde sistemin ürettiği yanıt; doğru bilgi, eksik bilgi, çelişkili bilgi ve kaynakta desteklenmeyen iddialar açısından incelenebilir. Ancak ifadelerin kelimesi kelimesine aynı olması her zaman gerekmez. Önemli olan, yanıtın sorunun gerektirdiği anlamı ve kanıtları doğru şekilde karşılamasıdır.

Özellikle kritik kurumsal süreçlerde yalnızca otomatik benzerlik skoruna güvenmek yerine, örnek yanıtları uzman incelemesiyle değerlendirmek ve hata türlerini kaydetmek gerekir.

4. RAG değerlendirmesinde kullanılabilecek araçlar

Testleri elle yapmak küçük bir prototip için yeterli olabilir. Ancak sistem büyüdükçe testlerin otomatik çalıştırılması ve sonuçların sürümler arasında karşılaştırılması daha kullanışlı hâle gelir.

Ragas

Ragas, RAG ve diğer LLM uygulamalarını değerlendirmek için çeşitli metrikler sunan açık kaynaklı bir araçtır. RAG değerlendirmesinde aşağıdaki metrikler özellikle yararlı olabilir:

• Context Precision: Getirilen bağlam parçalarının ilgililiğini ve ilgili parçaların sıralamada ne kadar üstte yer aldığını değerlendirir.
• Context Recall: Yanıt için gereken referans bilgilerin getirilen bağlamda ne ölçüde bulunduğunu inceler.
• Faithfulness: Oluşturulan yanıttaki iddiaların sunulan bağlam tarafından desteklenip desteklenmediğini değerlendirir.
• Response Relevancy: Yanıtın kullanıcının sorusuyla ne ölçüde örtüştüğünü değerlendirir.

Bu metrikler aynı şeyi ölçmez. Örneğin Context Recall yüksekken Faithfulness düşükse, gerekli bilgiler modele sunulmuş olsa da model bunları doğru kullanamamış olabilir. Faithfulness yüksek, Response Relevancy düşükse yanıt kaynaklara bağlı kalmış ancak kullanıcının asıl sorusunu yeterince karşılamamış olabilir.

Ragas metriklerinin bazıları referans cevaplar veya referans bağlamlar gerektirirken bazıları değerlendirme amacıyla bir dil modelinden yararlanabilir. Kullanılan metriğin neyi ölçtüğü, hangi girdileri gerektirdiği ve hangi sürümde bulunduğu resmî dokümantasyondan kontrol edilmelidir.

Ragas puanlarını tek başına mutlak kalite göstergesi olarak ele almayın. Sonuçları gerçek test soruları, uzman incelemeleri ve sistemin kullanım amacıyla birlikte değerlendirin.

Microsoft RAG değerlendirme rehberi

Microsoft’un RAG uçtan uca değerlendirme rehberi, belge getirme başarısını ve son yanıt kalitesini birlikte ele alır. Kaynağa bağlılık, tamlık, ilgililik ve doğruluk gibi ölçütlerin bir arada değerlendirilmesine yardımcı olur.

Bir aracın puan üretmesi, sistemin otomatik olarak güvenilir olduğu anlamına gelmez. Ölçüm sonuçlarının gerçek kullanım örnekleriyle karşılaştırılması ve hatalı değerlendirmelerin belirlenmesi gerekir.

5. LLM ile otomatik değerlendirme yapılırken nelere dikkat edilmeli?

Yanıtları değerlendirmek için başka bir büyük dil modelinden yararlanmak, insan incelemesine harcanan zamanı azaltabilir. Bu yaklaşımda değerlendirici model, üretilen yanıtı önceden belirlenmiş ölçütlere göre puanlar veya referans yanıtla karşılaştırır.

Ancak değerlendirici modelin kendisi de hata yapabilir. Puanlar model seçimine, değerlendirme talimatlarına ve test örneklerine duyarlı olabilir. Bu nedenle:

• Değerlendirme kriterlerini açık ve tutarlı biçimde tanımlayın.
• Otomatik puanları örnek bir insan incelemesiyle karşılaştırın.
• Model veya istem değiştiğinde değerlendirmeyi yeniden çalıştırın.
• Yalnızca ortalama puana değil, başarısız olan sorulara ve hata türlerine de bakın.
• Kritik kararları tek başına bir değerlendirici modelin sonucuna bağlamayın.
• Değerlendirme girdilerindeki belge içeriğinin, değerlendirme modeli tarafından talimat olarak yorumlanması ihtimalini dikkate alın.

Özellikle kurum içi bilgi asistanlarında yanlış bir yanıtın maliyeti, sorunun türüne göre değişebilir. İnsan kaynakları, finans, hukuk veya bilgi güvenliği gibi alanlarda testlerin risk seviyesine uygun hazırlanması gerekir.

6. RAG sistemlerinde güvenlik testleri

RAG değerlendirmesi yalnızca yanıtın doğru olup olmadığını ölçmekten ibaret değildir. Sistem, kullanıcıların erişim yetkisi olmayan belgeleri getirmemeli ve belge içindeki kötü niyetli talimatları güvenilir sistem komutları gibi uygulamamalıdır.

Test planında şu senaryolara da yer verin:

• Erişim kontrolü: Farklı yetki seviyelerine sahip kullanıcıların yalnızca izin verilen içerikleri alabildiğini doğrulayın.
• Prompt injection: Belgelerin veya kullanıcı girdilerinin modele istenmeyen talimatlar uygulattırmaya çalıştığı durumları test edin.
• Hassas bilgi sızıntısı: Gizli bilgilerin yanıtlar, loglar veya hata mesajları üzerinden açığa çıkmadığını kontrol edin.
• Kaynak güncelliği: Eski veya çelişkili belgelerin yanıltıcı yanıtlara yol açıp açmadığını inceleyin.
• Yanıtın sınırları: Sistem cevabı destekleyen bilgi bulamadığında tahmin yürütmek yerine belirsizliği ifade edebiliyor mu?

Erişim kontrolünü yalnızca modele verilen talimatlara bırakmayın. Kullanıcının belgeye erişim yetkisi, arama ve veri erişimi katmanında da uygulanmalıdır. Modelin “gizli bilgiyi paylaşma” talimatına uyması tek başına yeterli bir güvenlik kontrolü değildir.

Erişim kontrolü için basit bir test tasarımı

Örneğin İnsan Kaynakları ekibinin okuyabildiği bir belge ile yalnızca Finans ekibinin erişebildiği bir belge olduğunu varsayalım. Aynı soru, iki farklı yetki seviyesine sahip kullanıcıyla çalıştırılır. Her kullanıcı için beklenen belge listesi önceden belirlenir ve getirme sonuçları incelenir.

Yetkisiz kullanıcı, belge içeriğini doğrudan yanıt olarak almamalı; aynı zamanda gizli belgeyi arama sonuçlarında veya sistemin başka bir çıktısında da görmemelidir. Bu testler, yalnızca yanıt metnini kontrol etmekten ibaret olmamalı; belge erişim katmanındaki izin denetimlerini de kapsamalıdır.

LLM uygulamalarındaki güvenlik risklerini daha kapsamlı incelemek için OWASP GenAI LLM Top 10 2026 rehberine başvurabilirsiniz.

7. RAG için tekrarlanabilir bir test süreci oluşturun

Bir RAG uygulaması geliştirildiğinde testler yalnızca ilk sürümde yapılmamalıdır. Belge kaynakları, parçalama stratejisi, embedding modeli, arama parametreleri, istemler veya kullanılan LLM değiştiğinde sistemin davranışı da değişebilir.

Bu nedenle test sürecini düzenli bir geliştirme döngüsünün parçası olarak planlayın:

1. Başlangıç ölçümü: Temsili test sorularını mevcut sistemde çalıştırın ve sonuçları kaydedin.
2. Hata sınıflandırması: Yanlış belge, eksik bağlam, kaynak dışı iddia, eksik yanıt ve erişim ihlali gibi hata türlerini ayırın.
3. Tek bir değişikliği test edin: Örneğin chunk boyutu, overlap oranı veya retrieval parametresini değiştirin; sonuçları aynı test kümesi üzerinde karşılaştırın.
4. Önceki testleri tekrarlayın: Yeni sürümün bir alanda iyileşirken başka bir alanda gerilemediğini kontrol edin.
5. Üretim izleme: Gerçek kullanımda görülen hataları, gizlilik kurallarına uygun biçimde, gelecekteki test senaryolarına dönüştürün.

Her test çalıştırmasında en azından test veri kümesinin sürümü, retrieval ayarları, chunking stratejisi, model ve istem sürümleri ile elde edilen metrikleri kaydetmek yararlıdır. Böylece bir sonuç değiştiğinde hangi teknik değişikliğin etkili olmuş olabileceği incelenebilir.

Sonuçları karşılaştırırken mümkün olduğunca aynı test kümesini kullanın; ancak model ayarlamak için kullanılan verilerden bağımsız bir test kümesini de koruyun. Küçük puan değişikliklerini kesin iyileşme olarak yorumlamadan önce sonuçların tekrarlanabilirliğini değerlendirin.

RAG testleri için kontrol listesi

• Gerçek kullanıcı sorularını temsil eden bir test kümesi hazırlandı mı?
• İlgili belgelerin hangileri olduğu önceden belirlendi mi?
• Birden fazla belge gerektiren sorular test kümesinde bulunuyor mu?
• Belge getirme kalitesi ile yanıt kalitesi ayrı ölçülüyor mu?
• Precision@k, Recall@k ve MRR gibi erişim metrikleri değerlendiriliyor mu?
• Chunk boyutu ve overlap değişikliklerinin retrieval başarısına etkisi ölçülüyor mu?
• Kaynağa bağlılık, doğruluk, ilgililik ve tamlık değerlendiriliyor mu?
• Cevabı bulunmayan sorular ve belirsiz durumlar test ediliyor mu?
• Kullanıcı izinleri ve hassas bilgilere erişim ayrıca sınanıyor mu?
• Otomatik değerlendirme sonuçları gerektiğinde insan incelemesiyle karşılaştırılıyor mu?
• Model veya arama ayarları değiştiğinde önceki testler tekrarlanıyor mu?
• Değerlendirme sonuçları, kullanılan test kümesi ve sistem sürümüyle birlikte saklanıyor mu?

Kurumsal yapay zekâ uygulamalarında doğru değerlendirme

RAG sistemlerinde başarılı sonuç almak yalnızca güçlü bir dil modeli seçmekle sağlanmaz. Belge kalitesi, arama mekanizması, erişim izinleri, bağlam yönetimi ve yanıt üretimi birlikte ele alınmalıdır. Düzenli ve tekrarlanabilir testler, sistemin nerede hata yaptığını anlamaya ve yapılan iyileştirmelerin gerçek etkisini görmeye yardımcı olur.

Özellikle kurumsal kullanımda değerlendirme sürecinin amacı yalnızca yüksek bir puan elde etmek değil, sistemin hangi koşullarda güvenilir olduğunu ve hangi durumlarda başarısız olabileceğini anlamaktır. Test veri kümesi, ölçümler ve hata kayıtları bu nedenle geliştirme sürecinin ayrılmaz bir parçası olmalıdır.

Kurumsal yapay zekâ altyapısı, yerel LLM mimarileri ve veri güvenliği hakkında daha fazla bilgi için On-Premise Yapay Zekâ Rehberi sayfamızı inceleyebilirsiniz. Kurumsal yapay zekâ eğitimleri ve uygulama stratejileri için Kurumsal Yapay Zekâ Eğitimleri sayfamıza da göz atabilirsiniz.

Kurumunuzda RAG tabanlı bir asistan geliştirmeyi veya mevcut yapay zekâ sistemlerini değerlendirmeyi planlıyorsanız, ihtiyaçlarınızı görüşmek için Absonet ekibiyle iletişime geçebilirsiniz.

Kaynaklar ve ileri okuma

• Microsoft Learn – RAG Bilgi Erişimi Değerlendirmesi
• Microsoft Learn – RAG Uçtan Uca Değerlendirme
• Ragas – Değerlendirme Metrikleri
• OWASP GenAI LLM Top 10 2026

Hazırlayan: Absonet Teknik Ekibi

Son güncelleme: Ekim 2026