RAG test serisi · 01CPUÖn-kayıtlı

Regression gate'iniz yazı-tura mı atıyor? Küçük golden setlerde PASS/FAIL'in istatistiği

Açık bir test laboratuvarıyla ölçtük: RAG sistemlerinde küçük test setleriyle verilen PASS/FAIL kararları ne kadar güvenilir?

Bu yazıda RAG Gate Stats projesini ve test sonuçlarını anlatıyoruz.

Proje ne? RAG Gate Stats, RAG sistemlerinin arama katmanını ve bu katmanı denetleyen otomatik testleri sınamak için kurduğumuz açık bir deney düzeneği. Tamamı dizüstü bir bilgisayarın işlemcisinde, GPU olmadan çalışıyor.

Ne iş yapıyor? Tıp, finans ve bilim alanlarından üç açık veri setinde beş farklı arama yöntemini çalıştırıyor ve her sorunun sonucunu puanlıyor. Ardından bu puanlar üzerinde, CI hatlarındaki test koşularını taklit eden binlerce sanal test simüle ediyor ve her testin verdiği PASS/FAIL kararını bildiğimiz gerçekle karşılaştırıyor.

RAG'in hangi testlerini yapmak istedik? RAG test rehberleri, her değişiklikten sonra küçük bir soru setini (golden set) koşup sonucu sabit eşiklerle karşılaştıran bir regression gate önerir. Biz bu testin kendisini test etmek istedik:

Test sonuçları, kısaca:

Projeye ve kaynaklara buradan ulaşabilirsiniz:

Yazının geri kalanı bu başlıkları ayrıntılandırıyor: projenin ne yaptığı (Bölüm 1), neyi neden test etmek istediğimiz (Bölüm 2), testleri nasıl kurguladığımız (Bölüm 3) ve sonuçlar (Bölüm 4). RAG'e ya da istatistiğe yabancıysanız endişelenmeyin: gereken her kavramı yolda açıklıyoruz. Teknik ayrıntı diye başlayan paragrafları atlayabilirsiniz; terimlerin kısa açıklamaları yazının sonundaki sözlükte.

1. Proje: RAG Gate Stats ne yapıyor?

RAG (Retrieval-Augmented Generation), bir dil modelinin soruyu cevaplamadan önce bir belge koleksiyonunda arama yapması ve bulduğu metinlere dayanarak cevap yazması demek. Şirket içi asistanların çoğu böyle çalışır: soru gelir, arama bileşeni (retriever) en ilgili birkaç belgeyi bulur, dil modeli bu belgelere bakarak cevabı yazar.

Önemli bir not: bu projede kullanıcıyla konuşan bir sohbet botu yok. Bir RAG sisteminin arama katmanını ve onu test eden düzeneği kurduk, çünkü incelediğimiz gate'ler arama kalitesine (Recall@5) ve hıza bakıyor. Tam bir RAG'de aramanın ilk 5 sonucu dil modeline bağlam olarak verilir ve cevabı model yazar; o adım bu deneyin konusu değil.

1.1 Arama katmanı ne yapıyor? İki gerçek soru

Arama katmanının işi, bir soru geldiğinde binlerce belge arasından en ilgili birkaçını öne çıkarmak. Bu işin ne kadar iyi yapıldığını ölçmenin en yaygın yolu Recall@5: bir sorunun ilgili belgelerinden ne kadarının aramanın ilk 5 sonucu arasında çıktığı. Deneyde kullandığımız FiQA veri setinden iki gerçek soru bunu somutlaştırıyor. FiQA'da kişisel finans soruları ve bu sorulara yazılmış 57.638 cevap metni var; her sorunun hangi cevaplarla ilgili olduğu veri setiyle birlikte geliyor.

Soru 1: "Which colors can one use to fill out a check in the US?" (ABD'de çek doldururken hangi renkler kullanılabilir?) Veri setine göre ilgili tek bir belge var: çeklerin artık tarayıcıyla ya da fotoğrafla bozdurulduğunu, bu yüzden yazının yazılım tarafından ayırt edilebilmesi gerektiğini anlatan bir cevap.

Kelime eşleşmesi "renk" kelimesine takıldı, anlam araması ise sorunun aslında çekin okunabilirliğiyle ilgili olduğunu yakaladı. Bu iki sistemin farkı, gate'lerin karar vermek zorunda kaldığı değişikliklerin tipik bir örneği.

Soru 2: "What is considered high or low when talking about volume?" (Hisse işlem hacminde neye yüksek, neye düşük denir?) Bu sorunun 2 ilgili cevabı var. bge-small birini 1. sırada buldu, diğeri 6. sırada kaldı. İlgili belgelerin yarısı ilk 5'te olduğu için Recall@5 0,5.

Bir sistemin Recall@5'i, bu soru başına skorların ortalaması. Diğer iki veri setinde iş biraz farklı:

1.2 Deney düzeneği

Bir gate'in ne sıklıkla yanıldığını ölçmek için, doğru cevabı önceden bildiğimiz bir ortam gerekiyor. Bu yüzden gate'lerin kendisini test eden bir deney düzeneği kurduk. Düzenek beş adımdan oluşuyor:

Deney düzeneğinin beş adımı: gerçek veri, arama sistemleri ve değişiklikler, soru başına skor, 2000 sanal golden set, gate kararlarının gerçekle karşılaştırılması.

  1. Gerçek veri. Arama sistemlerini karşılaştırmak için yaygın kullanılan BEIR koleksiyonundan üç açık veri seti: tıp (NFCorpus; 323 soru, 3.633 belge), finans (FiQA-2018; 648 soru, 57.638 belge) ve bilim (SCIDOCS; 1.000 soru, 25.657 belge). Her sorunun ilgili belgeleri veri setiyle birlikte geliyor.
  2. Arama sistemleri ve değişiklikler. Kelime eşleşmesine dayanan klasik BM25; metni anlam vektörüne çeviren üç küçük embedding modeli (bge-small-en-v1.5, all-MiniLM-L6-v2, e5-small-v2); ve anlam aramasını büyük koleksiyonlarda hızlandıran yaklaşık arama indeksi HNSW (bge-small vektörleri üzerinde FAISS kütüphanesiyle; 4 farklı arama genişliği × 10 farklı kurulum). Bu sistemlerden, CI'da bir gate'in karar vereceği "önce / sonra" çiftleri oluşturduk (Bölüm 3.2'de anlatıyoruz).
  3. Soru başına skor. Her sistem her soruyu yanıtladı ve her soru için Recall@5 ile diğer metrikler kaydedildi.
  4. Sanal golden setler. Bu sorulardan 25–300 soruluk 2000 rastgele golden set çektik. Her set, CI hattınızdaki bir test koşusunun yerine geçiyor.
  5. Gate kararları. Her sette gate'ler PASS ya da FAIL dedi ve her kararı gerçekle karşılaştırdık.

Gömme vektörleri bir kez hesaplandıktan sonra, üç veri setinin bütün simülasyonu yaklaşık iki dakika sürüyor.

Kodun yanında projenin üç çıktısı var (bağlantılar yazının başında ve Bölüm 8'de):

2. Neyi test etmek istedik?

2.1 RAG nasıl test edilir?

Böyle bir sistemde işler birçok yerde ters gidebilir: doğru belge bulunamayabilir, bulunsa da model onu yanlış okuyabilir, yanlış kaynak gösterebilir ya da cevap çok geç gelebilir. Bu çalışmanın çıkış noktası olan iki Türkçe RAG test rehberinden biri, test stratejisinin temelini şöyle özetliyor:

"RAG başarısız oldu" demek yerine önce hangi katmanın başarısız olduğunu ayır: retrieval, context selection, generation, citation, security veya infrastructure.

Yani arama, bağlam seçimi, cevap üretimi, kaynak gösterme, güvenlik ve altyapı ayrı ayrı test edilmeli. Aynı rehber, arama kalitesinin dil modeli hiç çalıştırılmadan ölçülmesini de öneriyor. Böylece yanlış bir cevabın kaynağının arama mı yoksa üretim mi olduğu ayrılabiliyor.

Bu testlerin ortak malzemesi golden set: doğru cevabı ya da ilgili belgeleri önceden bilinen bir soru listesi. Arama katmanı için ölçü genellikle Bölüm 1.1'de anlattığımız Recall@5.

Bu ölçümlerin CI'a bağlanmış haline regression gate deniyor. Rehberin ifadesiyle: "Embedding modeli, chunk size, prompt, reranker, LLM veya vector DB değiştiğinde aynı test suite tekrar çalışmalı." Her değişiklikten sonra golden set yeniden koşulur ve sonuçlar sabit eşiklerle karşılaştırılır. Rehberlerden biri şu eşikleri örnek veriyor: Recall@5 >= 0.92, Faithfulness >= 0.95, Accuracy >= 0.90, P95 Latency <= 2.5s. Diğeri Recall@5 için 0.90 öneriyor ve "eşikler örnektir; domain ve risk seviyesine göre kalibre edilmelidir" notunu düşüyor.

Rehberlerin söylemediği şey şu: golden set kaç sorudan oluşmalı ve ölçülen değer eşiğe yakınken bu karar ne kadar güvenilir? Bu yazı test stratejisinin iki katmanına odaklanarak bu soruyu cevaplıyor: arama kalitesi (Recall@5) ve hız (latency). Cevap üretimi, kaynak gösterme ve güvenlik katmanlarını serinin sonraki projeleri ele alacak.

2.2 Sorun: 100 soru, 100 kişilik bir anket gibidir

Diyelim ki şirketinizin belgelerine dayanarak soru cevaplayan bir yapay zekâ asistanı geliştiriyorsunuz. Ekipten biri, asistanın belge aramak için kullandığı modeli değiştiriyor. CI hattınız her değişiklikte 100 soruluk bir test setini çalıştırıyor ve aramanın başarısını bir eşikle karşılaştırıyor. Ölçülen değer eşiğin biraz altında kalıyor: FAIL. Değişiklik geri alınıyor.

Peki aynı sistemi başka 100 soruyla test etseydiniz? Belki eşiğin üstünde kalacak ve PASS alacaktı. Ya da tersi: eşiği rahatça geçen bir sürüm, aslında gerçek bir kötüleşmeyi gizliyor olabilir. (Bu sahne kurgusal; aşağıdaki bütün sayılar ise ölçüm.)

Seçim anketleri bütün seçmenlere sormaz. Birkaç yüz ya da birkaç bin kişiye sorar ve sonucu bir hata payıyla verir; 1.000 kişilik bir anketin hata payı kabaca ±3 puandır. Kimse %50,5 çıkan bir anketten "kesin kazanır" sonucunu çıkarmaz.

Golden set de bir ankettir. Sistemin hayatta karşılaşacağı soruların küçük bir örneğidir ve 100 soruyla ölçülen Recall@5, gerçek değerin bir tahminidir. Aynı sistemi farklı 100 soruyla test ederseniz farklı bir sayı görürsünüz. Aşağıdaki grafik bunu gerçek veriyle gösteriyor.

FiQA veri setinde bge-small ile arama yapan aynı sistem, 2000 farklı 100 soruluk test setinde 0,26 ile 0,50 arasında Recall@5 ölçtü. Gerçek değer 0,379; eşik 0,359 olsaydı setlerin %29'u FAIL derdi.

FiQA veri setinde bge-small modeliyle arama yapan bir sistemin, 648 sorunun tamamında ölçülen gerçek Recall@5'i 0,379. Aynı sistemi 2000 farklı 100 soruluk setle ölçtüğümüzde sonuçlar 0,26 ile 0,50 arasında dağıldı. Eşik gerçek değerin 0,02 altında, yani 0,359 olsaydı, sistem aslında geçmesi gereken bir sistem olduğu halde test setlerinin %29'u FAIL derdi. Testin sonucu, sistemin kalitesi kadar hangi soruların sete düştüğüne de bağlı.

Bu yazıda ölçtüğümüz iki gürültü kaynağı daha var:

3. Test stratejimiz: gate'leri nasıl test ettik?

3.1 Cevabını bildiğimiz sınav

Gerçek hayatta golden setinizin dışındaki soruları bilmezsiniz; bu yüzden gate'in doğru karar verip vermediğini de bilemezsiniz. Deneyde durum farklı. Her veri setindeki bütün soruları, sistemin karşılaşacağı soruların tamamı (popülasyon) gibi kullandık. Bütün sorularda ölçülen değer, "gerçek" değer oldu. Ardından bu sorulardan küçük golden setler çektik ve her setin verdiği kararı gerçekle karşılaştırdık. Sıcaklığı bilinen bir suya batırarak bir termometreyi test etmek gibi.

3.2 Üç tür değişiklik

Gate'in karar vereceği her durum, bir "önce" (baseline) ve bir "sonra" (aday) sisteminden oluşuyor. Üç tür çift kurduk, çünkü her biri farklı bir soruyu cevaplıyor:

3.3 Karşılaştırdığımız gate'ler

Buradaki m, kabul edilebilir en büyük kayıp (marj): 0,01, 0,02 ya da 0,03. Bunu seçmek bir istatistik sorusu değil, bir ürün kararı.

Eşleştirmeyi bir benzetmeyle düşünün. İki sınavdan hangisinin daha zor olduğunu anlamak istiyorsunuz. İki farklı sınıfa birer sınav verip ortalamaları kıyaslarsanız, sınıflar arasındaki yetenek farkı sonucu bulandırır. Aynı öğrencilere iki sınavı da verip her öğrencinin iki notunu kıyaslarsanız, öğrenciler arasındaki fark ortadan kalkar ve sınavlar arasındaki gerçek fark çok daha net görünür. G3, aynı golden setteki her soruyu bu öğrenciler gibi kullanır.

G3'ün güven aralığını hesaplamak için bootstrap kullandık: elimizdeki soruları tekrar tekrar yeniden örnekleyerek "başka sorular gelseydi sonuç ne kadar oynardı?" sorusunu cevaplayan bir yöntem (Efron ve Tibshirani, 1993).

3.4 Kuralları önceden yazmak: ön-kayıt

Deneyi çalıştırmadan önce beş hipotezi ve her biri için "şu olursa destekledi sayacağız" kuralını bir dosyaya yazdık. Dosyanın parmak izi (SHA-256 özeti) her koşuyla birlikte kaydedildi. Böylece sonuçları gördükten sonra kuralları değiştiremezdik. Beş hipotezden tutmayan ikisini de bu yüzden olduğu gibi raporluyoruz.

3.5 Testlerin testi

Gate'leri test eden kodun kendisi de test edildi. Proje dokuz otomatik testle geliyor ve hepsi geçiyor:

Teknik ayrıntı. Golden set boyutu n ∈ {25, 50, 100, 200, 300}, popülasyonun yarısını geçmeyecek şekilde (NFCorpus'ta 200 ve 300 yok). Her n için R = 2000 iadesiz alt örnek; bütün senaryo ve gate'ler aynı alt örnekleri kullanıyor. Bootstrap B = 2000, percentile yöntemi, tek yönlü α = 0,05; ana seed 20261017. İkinci bir "gerçek" tanımında sorular ikiye bölünüyor: golden set bir yarıdan çekiliyor, gerçek öbür yarıda ölçülüyor. Dense modellerde max_seq_length = 256; HNSW için FAISS IndexHNSWFlat, M = 16, efConstruction = 200, ef_search ∈ {16, 32, 64, 128}, 10 farklı ekleme sırası.

4. Test sonuçları

Aşağıdaki bütün sayılar yayımlanan sonuç dosyalarından alınmıştır (bkz. 8. Kaynaklar ve tekrar üretim). Aksi belirtilmedikçe metrik Recall@5'tir ve her oran 2000 golden set üzerinden hesaplanmıştır.

4.1 Eşiğe yakın sistemlerde sabit eşik sık yanılıyor (H1)

Sabit eşiği dört sistemde sınadık: bge-small, e5-small, MiniLM ve BM25. Her sistem için eşiği iki yere koyduk: sistemin gerçek Recall@5'inin 0,02 altına (gate PASS vermeli) ve 0,02 üstüne (gate FAIL vermeli).

Golden set boyutu 25'ten 300'e çıktıkça G1'in hata oranı düşüyor: FiQA'da %39,2'den %10,7'ye, SCIDOCS'ta %28,4'ten %1,1'e; NFCorpus'ta 25 soruda %32,7, 100 soruda %13,7.

Ne bulduk? 100 soruluk setlerde yanlış karar oranı FiQA'da %28,1, NFCorpus'ta %13,7, SCIDOCS'ta %12,1 oldu. 25 soruda bu oran %28–39'a çıkıyor; 300 soruda SCIDOCS'ta %1,1'e iniyor.

Bu ne demek? Eşiğe yakın bir sistemde PASS ya da FAIL, sistemin kendisinden çok hangi soruların teste düştüğüne bağlı. Veri setleri arasındaki fark da öğretici. FiQA'da başarı sorudan soruya çok dalgalanıyor (bazı sorularda tam isabet, bazılarında sıfır); bu yüzden 100 soru orada daha az bilgi taşıyor. İyi haber şu: bu dalgalanmayı kendi golden setinizde ölçerek, sabit eşiğinizin ne kadar güvenilir olduğunu deney yapmadan kestirebilirsiniz.

Teknik ayrıntı. Oranlar dört sistemin ve eşiğin iki yönünün (sekiz durum) ortalaması. Ön-kayıtta H1 için "n = 100'de hata oranının güven aralığı alt sınırı %15'in üstünde, en az iki veri setinde" demiştik. Bu yalnız FiQA'da sağlandı (%28,1; CI %27,4–28,8). H1 ön-kayıtlı kuralıyla desteklenmedi. İkincil metrik nDCG@10 ile aynı kural üç veri setinde de sağlandı (FiQA %26,3, NFCorpus %21,9, SCIDOCS %17,2). Hatayı belirleyen, eşiğe uzaklığın standart hataya oranı. Soru başına Recall@5'in standart sapması FiQA'da 0,39, diğer ikisinde 0,18–0,22. Normal yaklaşım (hata ≈ Φ(−|d| / SE), sonlu popülasyon düzeltmesiyle) n = 100'de gözlenen oranları 1 puandan az farkla öngördü: FiQA'da %28,7 öngörü, %28,1 gözlem; NFCorpus'ta %13,6 ve %13,7; SCIDOCS'ta %12,0 ve %12,1. Golden set soruların bir yarısından çekilip "gerçek" öbür yarıda ölçüldüğünde FiQA'daki hata %31,9'a çıktı; bu tek bir rastgele bölmeye dayandığı için yalnız betimsel olarak raporlanıyor.

4.2 Eşiğin rahatça üstünde: gerçek düşüşler görünmüyor (H2)

Ekibinizin eşiği mevcut sistemin 0,05 altına koyduğunu düşünün: rahat bir pay (headroom). Yeni sürüm Recall@5'i gerçekte 0,03 düşürüyor (ctl03). Kabul edilebilir en büyük kayıp 0,02 ise bu gerçek bir kötüleşme ve yakalanmalı.

n = 100'de 0,03'lük düşüşü G1 golden setlerin %70,2–88,2'sinde, G2 %13,5–24,0'ında, G3 ise yalnız %1,3–3,8'inde geçirdi.

Ne bulduk? Sabit eşik (G1) bu kötüleşmeyi test setlerinin %70–88'inde geçirdi (FiQA %70,2, NFCorpus %88,2, SCIDOCS %87,9). Basit fark (G2) %13–24 oranında geçirdi. Eşleştirilmiş gate (G3) yalnız %1–4 oranında geçirdi ve tasarımdaki %5 sınırının altında kaldı. Recall@5'i 0,05 düşüren daha büyük bir bozulmayı (ctl05) bile sabit eşik test setlerinin %46–49'unda geçirdi; G3'te bu oran %0–0,3 oldu.

Bu ne demek? Sabit eşik değişime değil seviyeye bakar. Sisteminiz eşiğin rahatça üstündeyse, gerçek kayıplar eşiğe değene kadar görünmez kalır. Basit fark değişime bakıyor ama ölçüm belirsizliğini hesaba katmadığı için hâlâ sık yanılıyor.

Eşleştirilmiş gate de sınırda kusursuz değil. Kayıp tam marj kadarken (ctl02, gerçek kayıp ≈ 0,02), G3'ün tasarım gereği test setlerinin en fazla %5'inde PASS vermesi gerekirdi. 100 soruda bu oran %11–16 oldu (FiQA %13,6, NFCorpus %16,1, SCIDOCS %11,4). Fark soru sayısı arttıkça kapanıyor: 300 soruda FiQA'da %3,2, SCIDOCS'ta %4,1. Olası açıklama şu: bu bozulmalar kaybı az sayıda soruda topluyor; bu yüzden soru başına farkların dağılımı çok çarpık ve küçük setlerde bootstrap aralığı olması gerekenden dar kalıyor. Aynı karşılaştırmayı işaret-çevirme testiyle (G3′) yaptığımızda da tablo değişmedi (%12–18). Urbano, Lima ve Hanjalic (2019) da bilgi erişimi deneylerinde bootstrap tabanlı bir testin küçük örneklerde sistematik olarak küçük p-değerleri verdiğini, yani yanlış pozitifleri şişirdiğini göstermişti. Pratik anlamı: ölçülen fark marja çok yakınsa, 100 soruluk G3'ün PASS kararına tam güvenmeyin.

Teknik ayrıntı. Ön-kayıtlı kural: G1 PASS oranı ≥ %50 ve golden set başına (G1 PASS − G3 PASS) farkının güven aralığı sıfırın üstünde, en az iki veri setinde. Fark FiQA'da 0,66 [0,64; 0,69], NFCorpus'ta 0,86 [0,84; 0,87], SCIDOCS'ta 0,87 [0,85; 0,88]. H2 desteklendi (3/3).

4.3 Soru soru karşılaştırmak neden bu kadar önemli? (H3)

Ne bulduk? Hiçbir şeyin değişmediği durumlarda, eşleştirmesiz yöntem (G3u) 100 soruluk setlerin neredeyse hepsinde yanlış alarm verdi; veri seti başına PASS oranı en fazla %1,4 oldu. Eşleştirilmiş yöntem (G3) aynı setlerde çok daha az alarm verdi. Eşleştirmesiz yöntemin her 100 test setinde verdiği fazladan yanlış alarm sayısı:

Bu ne demek? Sınav benzetmesine dönersek: iki sistemin ortalamasını ayrı ayrı belirsizlikleriyle kıyaslamak, iki farklı sınıfın ortalamasını kıyaslamak gibi. İki ortalamanın belirsizliği toplanınca 0,02'lik marjdan çok daha geniş oluyor ve gate neredeyse hiç PASS veremiyor. Projenin birim testlerinden biri bunu en uç haliyle gösteriyor: iki sistem birebir aynıyken eşleştirilmiş gate her zaman PASS, eşleştirmesiz gate ise hiçbir zaman PASS vermiyor (sentetik veri, 50 soru, m = 0,01). Golden set iki sistem için de aynıysa her zaman eşleştirin; bunun hiçbir maliyeti yok.

Eşleştirilmiş gate'in de bir sınırı var. Kayıp marjın yarısı kadarken (ctl01, kayıp ≈ 0,010) G3, 100 soruda test setlerinin ancak yarısında PASS verdi (%49–54). "En fazla 0,02 kaybettik" diyebilmek için daha fazla soru gerekiyor; SCIDOCS'ta bu oran 300 soruda %77'ye çıkıyor. Bölüm 4.6 bunu sayılaştırıyor.

Teknik ayrıntı. Sayılar, no-op ailesinde (iki ef_search ayarı × 9 yeniden kurulum) m = 0,02 için golden set başına (G3u FAIL − G3 FAIL) farkının ortalaması. Bütün güven aralıkları ±0,01 genişliğinde ve sıfırın üstünde. H3 desteklendi (3/3).

4.4 Hiçbir şey değişmediğinde bile: arama indeksi gürültüsü (H4)

Aynı bge-small vektörleri, aynı HNSW ayarları; tek fark belgelerin indekse eklenme sırası. 10 farklı sırayla kurulan indekslerin sonuçlarını karşılaştırdık.

10 farklı ekleme sırasıyla kurulan HNSW indeksleri arasında Recall@10 farkının 95. persentili ef_search arttıkça düşüyor: FiQA'da 0,018'den 0,003'e, NFCorpus'ta 0,010'dan 0,004'e, SCIDOCS'ta 0,003'ten 0,001'e.

Ne bulduk? Düşük arama genişliğinde (ef_search = 16) Recall@10'u en az bir kurulumda değişen soruların payı FiQA'da %25,6, NFCorpus'ta %34,7, SCIDOCS'ta %11,1. Genişlik 128'e çıkınca bu pay %3,6, %3,1 ve %0,7'ye iniyor. Bu gürültü gate'e doğrudan yansıyor. FiQA'da ef_search = 16 ile hiçbir şey değiştirmeden indeksi yeniden kurmak, 100 soruda G3'ü test setlerinin %42'sinde FAIL ettirdi (PASS %58,4). ef_search = 128'de bu oran %12'ye düştü. Aynı durumda güvenilir PASS (%94,7) ancak 300 soruda geldi.

Dikkat çekici bir ayrıntı: FiQA'da yeniden kurulan dokuz indeks, ilk indeksten ortalamada 0,011 daha yüksek Recall@5 veriyor. Yani aday gerçekte biraz daha iyi; yine de G3 her beş test setinden ikisinde FAIL veriyor. Sorun bir kayıp değil, gürültü: soru başına farklar çok dağınık (standart sapma 0,19) ve 100 soruda bu belirsizlik 0,02'lik marjın büyük kısmını yiyor.

Bu ne demek? Hız için kullanılan yaklaşık arama, testinize kendi gürültüsünü ekliyor. Gate'i gürültülü bir indeksle koşarsanız, bu gürültü kabul edebileceğiniz kaybın bir kısmını yer.

Teknik ayrıntı. Kurulumlar arası Recall@10 farkının 95. persentili ef_search = 16'da FiQA'da 0,018, NFCorpus'ta 0,010, SCIDOCS'ta 0,003; 128'de 0,003, 0,004 ve 0,001. Ön-kayıtlı kural: fark 16'da sıfırdan büyük ve ef_search arttıkça artmıyor. H4 desteklendi.

4.5 Hız testi: P95'i tek ölçümden okumak (H5)

Hızı FiQA'da, Hugging Face'in ücretsiz CPU sunucusunu taklit eden 2 iş parçacığıyla ölçtük: 6 sistem × 648 sorgu × 10 koşu. Burada yalnız arama süresi var (sorgunun vektöre çevrilmesi + arama). Rehberlerdeki 2,5 saniyelik eşik ise dil modeli dahil uçtan uca süre içindir. Hatırlatma: P50, sorguların yarısının daha hızlı bittiği süre; P95, sorguların %95'inin daha hızlı bittiği süre.

P95 güven aralığının P50 güven aralığına oranı: BM25 3,75, HNSW ef 16 2,74, HNSW ef 128 2,60; exact aramada e5-small 1,87, MiniLM 1,60, bge-small 1,50. Ön-kayıtlı eşik 2.

Ne bulduk? P95'in belirsizliği yönteme göre çok değişiyor. İşi sorgudan sorguya değişen yöntemlerde (BM25, HNSW) P95'in belirsizliği P50'ninkinin 2,6–3,8 katı. Exact dense aramada ise 1,5–1,9 katı; orada her sorgu aynı işi yapıyor (kısa bir sorguyu kodlayıp bütün vektörleri tarıyor), bu yüzden P95 neredeyse P50 kadar kararlı.

Asıl risk, tek bir koşudan ölçülen P95'i sabit bir sınırla karşılaştırmak. Sınır gerçek P95'in %5 altına konduğunda, yani sistem gerçekte sınırı aştığında, tek koşudan alınan ölçüm bazı sistemlerde gate'i %61'e varan oranda geçirdi (BM25, 50 sorguluk ölçüm). Güven aralığına bakan gate bile HNSW'de %17'ye kadar PASS verdi; tasarlanan %5'in üç katından fazla. Sınır gerçek P95'in %5 üstündeyken, yani sistem gerçekte geçerken, aynı gate ölçümlerin yalnız %24–79'unda PASS verdi.

Bu ne demek? P95'i tek bir koşudan ölçüp sabit bir sınırla karşılaştırmak, yöntemden bağımsız olarak kırılgan. Bir koşunun içindeki güven aralığı, koşudan koşuya değişen makine koşullarını görmüyor.

Teknik ayrıntı. Ön-kayıtlı kural: 6 sistemin en az 4'ünde hem P95/P50 güven aralığı oranı ≥ 2 hem de koşular arası değişim katsayısı CV(P95) > CV(P50). Bu yalnız 3 sistemde sağlandı: BM25 (CV %9,1'den %12,4'e), HNSW ef_search = 16 (%3,7'den %6,0'a) ve 128 (%4,4'ten %7,4'e). Exact aramada oran 2'nin altında kaldı; e5-small ve MiniLM'de P95'in koşular arası oynaması P50'ninkinden büyük bile değildi. H5 desteklenmedi.

4.6 Kaç soru yeter?

Eşleştirilmiş gate için gereken soru sayısını belirleyen asıl şey, iki sistemin soru başına farklarının ne kadar dağınık olduğu. Bu dağınıklığa sd(d) diyelim: iki sistem çoğu soruda aynı sonucu veriyorsa küçük, birçok soruda farklı yönlere ayrışıyorsa büyük. Normal yaklaşımla gereken soru sayısı:

n ≈ ((z₁₋α + z₁₋β) · sd(d) / (m + Δ))²

Burada Δ beklenen gerçek değişiklik (kayıp negatif), m marj. α = 0,05 ve %80 güçte parantezin içindeki katsayı yaklaşık 2,49. sd(d) değişiklik türüne göre çok değişiyor; aşağıda her durum için sd(d) ve 100 ile 1000 soruda ayırt edilebilen en küçük fark var:

Model değişimi soruların çoğunu iki yönde birden etkilediği için sd(d) yüksek. FiQA'da bge → e5 değişikliği gerçekte 0,013 kaybettiriyor. "Kayıp 0,02'yi geçmedi" diyebilmek için formül on binden fazla soru istiyor; bu, FiQA'nın bütün test setinden fazla. Simülasyon da bunu doğruladı: bu değişiklikte G3, denediğimiz hiçbir golden set boyutunda %11'in üstünde PASS vermedi. Üstelik oran soru sayısı arttıkça düştü: 25 soruda %10,8, 300 soruda %4,5. Küçük setlerde ortalama daha çok oynadığı için alt sınır şans eseri marjın üstüne çıkabiliyor; set büyüdükçe ortalama gerçek değere (−0,013) yaklaşıyor, ama güven aralığı bu farkı marjdan ayıracak kadar daralmıyor. Yani bu veride, böyle bir değişikliğin 0,02 içinde kaldığını küçük bir golden setle kanıtlamak mümkün değil. Ya marj genişletilmeli ya da çok daha fazla soru toplanmalı.

Teknik ayrıntı. Formül, farklar az sayıda soruda yoğunlaştığında (HNSW gürültüsü, ayarlı bozulmalar) ve n küçükken G3'ün PASS oranını belirgin şekilde yanlış tahmin ediyor. 25 soruda simülasyonla arasındaki medyan mutlak fark FiQA'da 0,31, NFCorpus'ta 0,18, SCIDOCS'ta 0,06; 100 soruda 0,06 / 0,01 / 0,001. Küçük golden setlerde gücü formülle değil, kendi soru başına skorlarınız üzerinde bootstrap simülasyonuyla hesaplayın. Space'teki hesaplayıcı, seçilen senaryonun simülasyon sonuçlarını da bu yüzden gösteriyor.

5. Ne yapmalı?

1. Sabit eşik yerine eşleştirilmiş gate kullanın. Eski ve yeni sistemi aynı golden sette koşun, soru başına skorları saklayın ve farkın güven aralığını kabul edilebilir kayıpla karşılaştırın. Bu projenin CI komutu tam olarak bunu yapıyor; FAIL durumunda sıfırdan farklı bir çıkış koduyla dönüyor:

python -m gatestats.gates baseline.csv candidate.csv --metric recall@5 --margin 0.02

2. Marjı ürün kararı olarak seçin, soru sayısını ona göre hesaplayın. Kabul edilebilir kayıp bir istatistik sorusu değil, bir ürün kararıdır. sd(d)'yi gerçek bir değişiklik çiftinden ölçün ve soru sayısını Bölüm 4.6'daki formülle (küçük setlerde simülasyonla) belirleyin. Gereken soru sayısı sd(d)'nin karesiyle büyüdüğü için değişiklik türüne göre onlarca kat farklı olabilir. Ölçülen fark marja çok yakınsa küçük setlerde G3 de yanlış PASS verebilir (Bölüm 4.2); bu durumda soru sayısını artırın.

3. Gate'i arama indeksi gürültüsünden arındırın. Golden seti exact aramayla ya da yüksek ef_search ile koşun. Bu mümkün değilse, en az bir "hiçbir şey değişmedi" koşusuyla gürültü tabanını ölçün; bu taban marjınızdan küçük olmalı.

4. Sabit eşiği bırakamıyorsanız üçüncü bir sonuç ekleyin. Ölçülen değer eşiğin yaklaşık ±2 standart hata yakınındaysa sonucu PASS ya da FAIL değil "belirsiz" olarak raporlayın. Standart hata = soru başına metriğin standart sapması / √n.

5. P95'i tek koşudan ölçmeyin. Hızı birkaç ayrı koşuda ölçün ve koşular arası farkı da belirsizliğe katın. Bu, işi sorgudan sorguya değişen yöntemlerde (BM25, HNSW) özellikle önemli.

6. Literatürde ne biliniyor?

Sistemleri karşılaştırırken anlamlılık ve güç sorusu, bilgi erişimi (IR) ve NLP literatüründe uzun süredir tartışılıyor:

Bu yazı, aynı soruları bir RAG regression gate'inin somut kararlarına taşıyor: sabit eşikli gate'in eşiğe yakın sistemlerde ve eşiğin üstündeki kötüleşmelerde ne sıklıkla yanıldığını, arama indeksi gürültüsünün hiçbir şey değişmemişken gate'i nasıl FAIL ettirdiğini ve tek koşudan ölçülen P95 hız testinin ne kadar kırılgan olduğunu ölçüyor.

7. Sınırlamalar

8. Kaynaklar ve tekrar üretim

Deneyi baştan üretmek için:

git clone https://huggingface.co/bunyamineymen/rag-gate-stats-code
cd rag-gate-stats-code
uv sync
uv run python scripts/run_all.py
uv run python scripts/latency.py
uv run python scripts/report.py
uv run python scripts/figures.py
uv run pytest -q

Kaynakça

Yöntem ve istatistik

Arama yöntemleri ve modeller

Veri setleri

Kavramlar

Yazıda geçen terimlerin kısa açıklamaları.

RAG ve arama

Test

İstatistik