🔍 RAG Pipeline Testi

RAG Pipeline Testi: Bir RAG pipeline'ını test etmek, tek bir cümleyi doğrulamak değil, bir araştırma makalesini notlamaktır — ve mekanizma gevşek değil, birebir örtüşür: bir hake

Bir RAG pipeline'ını test etmek, tek bir cümleyi doğrulamak değil, bir araştırma makalesini notlamaktır — ve mekanizma gevşek değil, birebir örtüşür: bir hakem sadece "bu sonuç doğru mu?" diye sormaz, her biri bağımsız olarak başarısız olabilecek üç ayrı soru sorar — DOĞRU kaynaklar mı gösterildi (retrieval), her İDDİA gerçekten gösterilen bir kaynağa mı dayanıyor (grounding/faithfulness) ve makale gerçekten araştırma sorusunu CEVAPLIYOR mu (relevance)? Yanlış kaynakları gösteren parlak, iyi yazılmış bir makale, doğru kaynakları gösterip onlardan desteksiz sonuçlar çıkaran özensiz bir makale kadar başarısız olur. Üzerinde durmaya değer soru şu: RAG chatbot'un doğru politika belgesini getirdi VE yanıtı tamamen kendinden emin görünüyor — o zaman neden tek bir "yanıt doğru görünüyor mu?" kontrolü yeterli değil? Çünkü bir model mükemmel bağlamı getirip yine de içinde hiç olmayan bir detay uydurabilir — retrieval'ın başarılı olması, ÜRETIM adımının kendisine verilene sadık kalıp kalmadığı hakkında hiçbir şey söylemez; bu tam olarak bir önceki sekmenin "prompt vs RAG vs fine-tune" kararıyla bu sekme arasındaki farktır: RAG'ı seçmek sadece modelin bilgiyi NEREDEN aldığını çözer, onu doğru KULLANIP kullanmadığını değil. Java karşılaştırması: bu tek bir assertTrue(response.contains(expected)) değildir — assertSourceMatches(), assertClaimsAreGrounded() ve assertAnswersQuestion() gibi üç bağımsız assertion'dır, her biri diğerlerinin kaçıracağı bir hatayı yakalar. QA açısından önemi: yanlış bir iade penceresi uyduran RAG destekli bir destek botu, "bilmiyorum" diyen bir bottan daha kötüdür — grounding'i relevance'tan ayrı ölçmek, akıcı, kendinden emin ve tamamen yanlış bir yanıtı bir müşteri yakalamadan ÖNCE yakalamanın yoludur; bu tam olarak Token Lab'ın turuncu düşük-olasılık yolunda yaşadığın mekanizmanın, şimdi gerçek bir iş belgesine uygulanmış halidir.

Üç Bağımsız Başarısızlık Noktası

Bir RAG pipeline'ının üç aşaması vardır ve her biri kendi başına başarısız olabilir: (1) Retrieval — sistem, bilgi tabanındaki her şey arasından gerçekten cevabı içeren pasajı mı getirdi? (2) Grounding / Faithfulness — üretilen yanıttaki her somut iddia, getirilen bağlamda gerçekten var olan bir şeye mi dayanıyor, yoksa model orada hiç olmayan detaylar mı ekledi? (3) Relevance — yanıt, grounded olup olmadığından bağımsız olarak, gerçekten kullanıcının sorusunu ele alıyor mu? Bir model mükemmel şekilde grounded olabilir (her kelime kaynağa kadar izlenebilir) ama alakasız olabilir (sorulan sorudan farklı bir soruyu cevaplıyor), ve tamamen grounded olmadan alakalı ve akıcı olabilir (kendinden emin bir halüsinasyon). RAGAS ve benzeri değerlendirme çerçeveleri tam olarak bu yüzden bunları ayrı sayılar olarak puanlar — hepsini tek bir "kalite" puanına sıkıştırmak hangi aşamanın gerçekten bozulduğunu gizler.

🎬 RAG Boru Hattı: Bir Sorunun Yolculuğu

Kullanıcı soruyor: "İade penceresi kaç gün?" — soru pipeline'a girer. Model bu cevabı ezbere BİLMİYOR; bilgiyi şirket belgesinden getirmesi gerekecek.

Adım 1 — Embed: soru, embedding modeliyle bir sayı dizisine (vektöre) çevrilir. Anlamca benzer metinler, benzer vektörler üretir.

Adım 2 — Retrieve: vektör, vector store'da aranır; soruya anlamca en yakın pasajlar bulunur. Yanlış pasaj gelirse zincirin geri kalanı ne kadar iyi olursa olsun cevap yanlış olur.

Retrieval başarılı: doğru politika belgesi bulundu — "İadeler 14 gün içinde kabul edilir." Ama dikkat: bu, yolculuğun sonu DEĞİL; model bu belgeye sadık kalacak mı, henüz bilmiyoruz.

Adım 3 — Augment: getirilen pasaj + kullanıcının sorusu tek bir prompt'ta birleştirilir. Modele "SADECE bu bağlama dayanarak cevapla" talimatı da burada verilir.

Adım 4 — Generate: LLM, prompt'taki bağlama dayanarak yanıtı üretir: "İade süreniz 14 gündür." Bağlamdaki gerçek, kullanıcının diline çevrildi — mutlu son... şimdilik.

Final sahnesi — aynı pipeline, farklı koşum: retrieval yine DOĞRU çalıştı ama model bu kez bağlamda hiç olmayan bir detay uydurdu: "aynı gün para iadesi". Retrieval'ın başarısı grounding'i garanti etmez — bu yüzden RAG testinde retrieval, grounding ve relevance AYRI AYRI ölçülür (aşağıdaki lab'da kendin deneyeceksin).

Aşağıda, aynı iade-politikası bilgi tabanı, aynı soruyu iki aday yanıtla cevaplamak için kullanılır — biri grounded, diğeri sessizce ekstra politika detayları uyduruyor. Analizi ikisinde de çalıştır ve üç ring'den hangisinin düştüğünü izle: grounded yanıt üçünde de yüksek puan alır; halüsinasyonlu olan makul bir relevance puanı korur (hâlâ doğru konu "hakkında"dır) ama grounding ve faithfulness çöker, çünkü uydurulan detaylar (daha uzun bir pencere, aynı gün iade, bir politika istisnası) kaynak metinde basitçe yoktur — Yargıç Oyun Alanı'nın "belirsiz rapor"uyla aynı mekanizma, ama bu sefer bir rubrik yerine bir belgeye karşı kontrol edilen tüm bir üretilmiş paragrafa uygulanmış hali.

Adım Adım: RAG Pipeline'ının Üç Katmanı

Kullanıcı sorusuna en alakalı doküman parçaları bir vektör veritabanından ARANIR.