| # 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: | |
| - 100 soruluk bir setle verilen PASS/FAIL kararı ne kadar güvenilir? | |
| - Sabit eşik yerine kullanılabilecek daha sağlam bir yöntem var mı? | |
| - Arama indeksinin kendi gürültüsü ve hız (latency) ölçümü bu kararları nasıl etkiliyor? | |
| **Test sonuçları, kısaca:** | |
| - **Eşiğe yakın sistemlerde sabit eşik sık yanılıyor.** Sistemin gerçek başarısı eşiğe 0,02 yakınken 100 soruluk bir test, veri setine göre kararların %12 ile %28'inde yanlış karar verdi. | |
| - **Eşiğin rahatça üstündeki sistemlerde sabit eşik gerçek kötüleşmeleri kaçırıyor.** Gerçek bir 0,03'lük düşüşü test setlerinin %70–88'inde fark etmedi. Değişikliği soru soru karşılaştıran bir yöntem bu oranı %1–4'e indirdi. | |
| - **Hiçbir şey değişmediğinde bile test gürültü üretebiliyor.** Arama indeksini aynı ayarlarla yeniden kurmak bir veri setinde soruların %26'sının sonucunu değiştirdi ve iyi kurulmuş bir testi bile %42 oranında yanlış alarma sürükledi. | |
| - **Daha iyi yöntem de sihirli değil.** Kayıp tam kabul sınırındayken, 100 soruluk testte o yöntem bile gereğinden sık PASS verdi (%11–16; hedef %5). Gereken soru sayısı, değişikliğin türüne göre onlarca kat değişiyor. | |
| - **Hız testinde tek ölçüm yanıltıcı.** Yavaş sorguların süresi (P95) tek bir koşudan ölçüldüğünde, sistem gerçekte hız sınırını aşarken bile bazı yöntemlerde test %61'e varan oranda PASS verdi. | |
| **Projeye ve kaynaklara buradan ulaşabilirsiniz:** | |
| - **Etkileşimli sonuçlar ve soru sayısı hesaplayıcısı:** [bunyamineymen/rag-gate-stats](https://huggingface.co/spaces/bunyamineymen/rag-gate-stats) | |
| - **Bütün sonuç verileri:** [bunyamineymen/rag-gate-stats-results](https://huggingface.co/datasets/bunyamineymen/rag-gate-stats-results) | |
| - **Kod:** [bunyamineymen/rag-gate-stats-code](https://huggingface.co/bunyamineymen/rag-gate-stats-code) | |
| 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. | |
| - **bge-small (anlam benzerliğiyle arama)** bu cevabı 3. sırada buldu. İlgili belge ilk 5'te olduğu için bu sorunun Recall@5'i 1. | |
| - **BM25 (kelime eşleşmesiyle arama)** ilk sıraya, içinde "colors" kelimesi geçen bir çanta reklamını koydu. İlgili cevap ilk 100 sonucun içinde bile yok; Recall@5'i 0. | |
| 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ı: | |
| - **NFCorpus:** "deafness" ya da "dietary scoring" gibi kısa sağlık ve beslenme sorguları; belgeler tıbbi makale özetleri. Soru başına ortalama 38 ilgili belge var. Hepsi ilk 5 sonuca sığamayacağı için Recall@5 burada doğal olarak düşük. | |
| - **SCIDOCS:** Soru bir bilimsel makalenin başlığı; ilgili belgeler, o makaleyle atıf ilişkisi bulunan makaleler (soru başına ortalama 4,9). | |
| ### 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: | |
|  | |
| 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): | |
| - **Sonuç veri seti** (Hugging Face Dataset): bütün soru başına skorlar ve simülasyon sonuçları. Veri setlerinin metinleri yeniden dağıtılmıyor; yalnız soru kimlikleri var. | |
| - **Etkileşimli sayfa** (Hugging Face Space): grafikler ve kendi golden setiniz için soru sayısı hesaplayıcısı. | |
| - **CI komutu:** Kendi hattınızda kullanabileceğiniz, bu yazıda önerdiğimiz gate. Bölüm 5'te örneği var. | |
| ## 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 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: | |
| - **Yaklaşık arama gürültüsü.** Büyük koleksiyonlarda hız için kullanılan yaklaşık arama indeksleri (en yaygını HNSW), belgeler farklı sırayla eklendiğinde biraz farklı kurulur. Hiçbir şey "değişmemişken" bazı soruların sonucu değişebilir. | |
| - **Hız ölçümü gürültüsü.** P95, sorguların %95'inin altında kaldığı süredir; yani en yavaş %5'in başladığı yer. Birkaç yavaş sorgu bu değeri belirgin biçimde kaydırabilir. | |
| ## 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: | |
| - **Hiçbir şeyin değişmediği durumlar (no-op):** Aynı ayarlarla, yalnız belgelerin eklenme sırası değiştirilerek yeniden kurulan HNSW indeksi. Kullanıcı açısından değişen bir şey yok; gate PASS vermeli. Bu durumlar yanlış alarmları ölçüyor. | |
| - **Gerçekçi değişiklikler:** Embedding modelini değiştirmek, BM25'e geçmek, indeksin arama genişliğini düşürmek, koleksiyondan %5 ya da %10 belge silmek. Gate'lerin gerçek hayattaki değişikliklere nasıl tepki verdiğini gösteriyor. | |
| - **Büyüklüğünü bizim ayarladığımız bozulmalar:** Rastgele seçilen sorularda ilgili belgeleri sonuçların dışına iterek Recall@5'i tam 0,01, 0,02, 0,03 ya da 0,05 düşürdük. Bunlara `ctl01` … `ctl05` diyoruz. Kaybın ne kadar olduğunu bildiğimiz için, gate'in onu yakalayıp yakalamadığını kesin olarak söyleyebiliyoruz. | |
| ### 3.3 Karşılaştırdığımız gate'ler | |
| - **G1, sabit eşik:** "Yeni sistemin ortalaması eşiğin üstünde mi?" Rehberlerin yöntemi. Yalnız yeni sistemin seviyesine bakar. | |
| - **G2, basit fark:** "Yeni sistem eskisinden en fazla m kadar mı kötü?" İki ortalamayı karşılaştırır ama ölçüm belirsizliğini hesaba katmaz. | |
| - **G3, eşleştirilmiş güven aralıklı karşılaştırma:** Her soru için yeni ve eski sistemin skor farkını alır. Bu farkların ortalaması için bir güven aralığı hesaplar ve "en kötü ihtimalle bile kayıp m'yi geçmiyor" diyebiliyorsa PASS verir. Bu tasarımın adı non-inferiority testi ve klinik araştırmalardan geliyor (Wellek, 2010). | |
| - **G3u, eşleştirmesiz karşılaştırma:** G3 ile aynı soruyu sorar ama iki sistemin belirsizliğini ayrı ayrı hesaplar. Eşleştirmenin ne kazandırdığını görmek için. | |
| - **G3′, çapraz kontrol:** G3 ile aynı soru, başka bir istatistik yöntemiyle (işaret-çevirme testi). | |
| 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. | |
| - **H1:** Gerçek değer eşiğe yakınken sabit eşik sık yanılır. | |
| - **H2:** Sistem eşiğin rahatça üstündeyken sabit eşik gerçek bir kötüleşmeyi kaçırır. | |
| - **H3:** Soru soru eşleştirmek, zararsız değişikliklerde yanlış alarmı azaltır. | |
| - **H4:** HNSW indeksini yeniden kurmak, hiçbir şey değişmeden sonuçları oynatır; arama genişliği arttıkça bu oynama azalır. | |
| - **H5:** Hızın kuyruk değeri (P95), ortancasından (P50) belirgin şekilde daha belirsiz ölçülür. | |
| ### 3.5 Testlerin testi | |
| Gate'leri test eden kodun kendisi de test edildi. Proje dokuz otomatik testle geliyor ve hepsi geçiyor: | |
| - **Metrikler bağımsız bir kütüphaneyle aynı.** bge-small sonuçları üzerinde hesapladığımız Recall@5, Recall@10, MRR@10 ve nDCG@10 değerlerini, bilgi erişimi araştırmalarında kullanılan ranx kütüphanesiyle üç veri setinde de karşılaştırdık; sonuçlar soru soru aynı çıktı. | |
| - **Arama tekrarlanabilir.** BM25 ve bge-small ile exact arama, NFCorpus'ta yeniden koşulduğunda kayıtlı sonuçla bit düzeyinde aynı çıkıyor. | |
| - **İstatistik doğru çalışıyor.** Bootstrap alt sınırının gerçek ortalamayı beklenen oranda (%93–97 aralığında) kapsaması, iki sistem birebir aynıyken gate'lerin beklenen kararı vermesi, işaret-çevirme testinin yalnız net farkları yakalaması ve diğer hesapların bilinen değerlerle tutması ayrı testlerle kontrol ediliyor. | |
| - **Simülasyon yeniden üretilebilir.** Her golden set tek bir seed'den türetiliyor. Bölüm 2.2'deki grafiği yazı için yeniden çizdiğimizde, aynı setlerden aynı FAIL oranı çıktı. | |
| **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). | |
|  | |
| **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ı. | |
|  | |
| **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ı: | |
| - **50 soruda:** FiQA 70, NFCorpus 89, SCIDOCS 97 | |
| - **100 soruda:** FiQA 73, NFCorpus 95, SCIDOCS 100 | |
| **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. | |
|  | |
| **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. | |
| - **Exact dense arama (bge-small, e5-small, MiniLM):** P50 12,6–23,0 ms, P95 16,2–29,1 ms | |
| - **HNSW (`ef_search` 16 / 128):** P50 21,4 / 22,1 ms, P95 29,3 / 30,0 ms | |
| - **BM25:** P50 0,38 ms, P95 1,62 ms | |
|  | |
| **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: | |
| - **Embedding modeli değişimi (bge → e5):** sd(d) FiQA'da 0,300, SCIDOCS'ta 0,127, NFCorpus'ta 0,102. En küçük fark 100 soruda 0,075 / 0,032 / 0,026; 1000 soruda 0,024 / 0,010 / 0,008. | |
| - **Koleksiyondan %10 belge silme:** sd(d) FiQA'da 0,149, SCIDOCS'ta 0,061. En küçük fark 100 soruda 0,037 / 0,015; 1000 soruda 0,012 / 0,005. | |
| - **HNSW'yi yeniden kurmak, FiQA (medyan):** sd(d) `ef_search` = 16'da 0,191, 128'de 0,048. En küçük fark 100 soruda 0,047 / 0,012. | |
| 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: | |
| ```bash | |
| 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: | |
| - Smucker, Allan ve Carterette (2007) TREC verisinde randomizasyon, bootstrap ve t testlerinin pratikte benzer sonuç verdiğini gösterdi. Wilcoxon ve işaret testlerinin ise bırakılmasını önerdi. | |
| - Webber, Moffat ve Zobel (2008) gücü, belli bir üstünlüğü yakalamaya yetecek konu (soru) sayısı olarak ele aldı. Varyansı önceki verilerden tahmin etmenin geniş hata payı bıraktığını da gösterdi. | |
| - Sakai (2016), SIGIR ve TOIS makalelerinde hem aşırı güçsüz hem de gereğinden güçlü deneyler buldu ve örneklem büyüklükleri önerdi. | |
| - Urbano, Lima ve Hanjalic (2019), 25–100 konuluk simülasyonlarda bootstrap-shift testinin küçük p-değerlerine doğru sistematik bir yanlılık gösterdiğini raporladı. | |
| - NLP'de Card vd. (2020) yaygın test setleriyle yapılan deneylerin çoğu zaman güçsüz olduğunu gösterdi. Dror vd. (2018) anlamlılık testlerinin sık sık atlandığını ya da yanlış kullanıldığını buldu. | |
| - RAG değerlendirmesinde ARES (Saad-Falcon vd., 2024), az sayıda insan etiketiyle sistemleri güven aralıklarıyla sıralamak için prediction-powered inference kullanı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 | |
| - BEIR veri setleri bir şirketin kendi belgeleri değil; soru başına skor dağılımları sizin verinizde farklı olabilir. Üç veri seti de İngilizce. | |
| - Deney yalnız arama kalitesini ve hızı kapsıyor. Dil modeline dayalı metriklerde (faithfulness, doğruluk) üretimin rastgeleliği ek bir gürültü kaynağıdır; serinin sonraki projeleri bunu ele alacak. | |
| - Ayarlı bozulmalar, kaybı soruların küçük bir kısmında topluyor. Gerçek değişiklikler çoğu soruyu iki yönde birden etkiler; gerçekçi değişiklikler bu yüzden ayrıca raporlandı. | |
| ## 8. Kaynaklar ve tekrar üretim | |
| - **Etkileşimli sonuçlar ve soru sayısı hesaplayıcısı:** [bunyamineymen/rag-gate-stats](https://huggingface.co/spaces/bunyamineymen/rag-gate-stats) | |
| - **Sonuç veri seti:** [bunyamineymen/rag-gate-stats-results](https://huggingface.co/datasets/bunyamineymen/rag-gate-stats-results) | |
| - **Kod:** [bunyamineymen/rag-gate-stats-code](https://huggingface.co/bunyamineymen/rag-gate-stats-code) | |
| - **Ön-kayıt SHA-256:** `f2c4563bdeed4ae6e9496982ed40f8a63aef4de172698701d9fb33669f964567` (`results/env.json`) | |
| Deneyi baştan üretmek için: | |
| ```bash | |
| 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** | |
| - Card, D., Henderson, P., Khandelwal, U., Jia, R., Mahowald, K. ve Jurafsky, D. (2020). With Little Power Comes Great Responsibility. EMNLP 2020. [aclanthology.org/2020.emnlp-main.745](https://aclanthology.org/2020.emnlp-main.745/) | |
| - Dror, R., Baumer, G., Shlomov, S. ve Reichart, R. (2018). The Hitchhiker's Guide to Testing Statistical Significance in Natural Language Processing. ACL 2018. [aclanthology.org/P18-1128](https://aclanthology.org/P18-1128/) | |
| - Efron, B. ve Tibshirani, R. J. (1993). *An Introduction to the Bootstrap*. Chapman & Hall. | |
| - Saad-Falcon, J., Khattab, O., Potts, C. ve Zaharia, M. (2024). ARES: An Automated Evaluation Framework for Retrieval-Augmented Generation Systems. NAACL 2024. [aclanthology.org/2024.naacl-long.20](https://aclanthology.org/2024.naacl-long.20/) | |
| - Sakai, T. (2016). Statistical Significance, Power, and Sample Sizes: A Systematic Review of SIGIR and TOIS, 2006-2015. SIGIR 2016. [doi.org/10.1145/2911451.2911492](https://doi.org/10.1145/2911451.2911492) | |
| - Smucker, M. D., Allan, J. ve Carterette, B. (2007). A comparison of statistical significance tests for information retrieval evaluation. CIKM 2007. [doi.org/10.1145/1321440.1321528](https://doi.org/10.1145/1321440.1321528) | |
| - Urbano, J., Lima, H. ve Hanjalic, A. (2019). Statistical Significance Testing in Information Retrieval: An Empirical Analysis of Type I, Type II and Type III Errors. SIGIR 2019. [doi.org/10.1145/3331184.3331259](https://doi.org/10.1145/3331184.3331259) | |
| - Webber, W., Moffat, A. ve Zobel, J. (2008). Statistical power in retrieval experimentation. CIKM 2008. [doi.org/10.1145/1458082.1458158](https://doi.org/10.1145/1458082.1458158) | |
| - Wellek, S. (2010). *Testing Statistical Hypotheses of Equivalence and Noninferiority* (2. baskı). Chapman & Hall/CRC. | |
| **Arama yöntemleri ve modeller** | |
| - Douze, M. vd. (2024). The Faiss library. [arXiv:2401.08281](https://arxiv.org/abs/2401.08281) | |
| - Lù, X. H. (2024). BM25S: Orders of magnitude faster lexical search via eager sparse scoring. [arXiv:2407.03618](https://arxiv.org/abs/2407.03618) | |
| - Malkov, Y. A. ve Yashunin, D. A. (2016). Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs. [arXiv:1603.09320](https://arxiv.org/abs/1603.09320) | |
| - Reimers, N. ve Gurevych, I. (2019). Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks. EMNLP-IJCNLP 2019. [aclanthology.org/D19-1410](https://aclanthology.org/D19-1410/) | |
| - Wang, L. vd. (2022). Text Embeddings by Weakly-Supervised Contrastive Pre-training (e5). [arXiv:2212.03533](https://arxiv.org/abs/2212.03533) | |
| - Wang, W. vd. (2020). MiniLM: Deep Self-Attention Distillation for Task-Agnostic Compression of Pre-Trained Transformers. NeurIPS 2020. [arXiv:2002.10957](https://arxiv.org/abs/2002.10957) (`all-MiniLM-L6-v2` bu modelden türetilmiş bir sentence-transformers modelidir.) | |
| - Xiao, S., Liu, Z., Zhang, P., Muennighoff, N., Lian, D. ve Nie, J.-Y. (2024). C-Pack: Packed Resources For General Chinese Embeddings (bge). SIGIR 2024. [arXiv:2309.07597](https://arxiv.org/abs/2309.07597) | |
| **Veri setleri** | |
| - Boteva, V., Gholipour, D., Sokolov, A. ve Riezler, S. (2016). A Full-Text Learning to Rank Dataset for Medical Information Retrieval (NFCorpus). ECIR 2016. [doi.org/10.1007/978-3-319-30671-1_58](https://doi.org/10.1007/978-3-319-30671-1_58) | |
| - Cohan, A., Feldman, S., Beltagy, I., Downey, D. ve Weld, D. S. (2020). SPECTER: Document-level Representation Learning using Citation-informed Transformers (SCIDOCS). ACL 2020. [aclanthology.org/2020.acl-main.207](https://aclanthology.org/2020.acl-main.207/) | |
| - Maia, M. vd. (2018). WWW'18 Open Challenge: Financial Opinion Mining and Question Answering (FiQA). The Web Conference 2018 Companion. [doi.org/10.1145/3184558.3192301](https://doi.org/10.1145/3184558.3192301) | |
| - Thakur, N. vd. (2021). BEIR: A Heterogenous Benchmark for Zero-shot Evaluation of Information Retrieval Models. [arXiv:2104.08663](https://arxiv.org/abs/2104.08663) | |
| ## Kavramlar | |
| Yazıda geçen terimlerin kısa açıklamaları. | |
| **RAG ve arama** | |
| - **RAG:** Dil modeli cevap vermeden önce bir belge koleksiyonunda arama yapar ve bulduğu metni kullanır. | |
| - **Corpus:** Aramanın yapıldığı belgelerin tamamı. | |
| - **BM25:** Kelime eşleşmesine dayalı klasik arama yöntemi. | |
| - **Embedding / dense arama:** Metin bir sayı vektörüne çevrilir; arama anlam benzerliğiyle yapılır. | |
| - **Top-K:** Aramanın döndürdüğü ilk K sonuç. | |
| - **Exact arama, ANN:** Exact arama her belgeye bakar. Yaklaşık arama (ANN) hız için bazı belgeleri atlar ve bazen en iyi sonucu kaçırır. | |
| - **HNSW, `ef_search`:** En yaygın ANN yöntemi. `ef_search` aramanın ne kadar geniş tutulacağını belirler; düşük değer daha hızlı ama daha hatalıdır. | |
| **Test** | |
| - **Golden set:** Doğru cevabı veya ilgili belgeleri bilinen test soruları. | |
| - **qrels:** Her soru için hangi belgelerin ilgili olduğunu gösteren etiketler. | |
| - **Recall@5:** Bir sorunun ilgili belgelerinden ne kadarının ilk 5 sonuç içinde bulunduğu. | |
| - **MRR:** İlk doğru sonucun sırasının tersi; doğru belge 2. sıradaysa 0,5. | |
| - **nDCG:** Sıralama kalitesi: ilgili belgeler ne kadar üstte. | |
| - **Regression gate:** Her değişiklikten sonra golden seti koşup sonucu PASS ya da FAIL diye özetleyen kontrol. | |
| - **Baseline, aday:** Kullanımdaki sistem ve yerine denenen yeni sistem. | |
| - **No-op değişiklik:** Sonucu değiştirmemesi beklenen değişiklik; örneğin indeksi aynı ayarlarla yeniden kurmak. | |
| - **Headroom (eşik payı):** Sistemin ölçülen değeri ile sabit eşik arasındaki boşluk. Pay büyükse gerçek bir düşüş, sistem eşiğin altına inmediği sürece görünmez kalır. | |
| - **P50, P95 latency:** Sorguların sırasıyla yarısının ve %95'inin altında kaldığı yanıt süresi. | |
| **İstatistik** | |
| - **Örneklem, popülasyon:** Golden set, sistemin gerçekte karşılaşacağı tüm soruların (popülasyon) küçük bir örneğidir. | |
| - **Standart hata:** Küçük bir örnekten ölçülen değerin gerçek değerden tipik sapma miktarı. | |
| - **Güven aralığı (CI):** Gerçek değerin yüksek olasılıkla içinde bulunduğu aralık. | |
| - **Bootstrap:** Soruları tekrar tekrar yeniden örnekleyerek güven aralığı hesaplama yöntemi. | |
| - **Eşleştirilmiş karşılaştırma:** İki sistemi aynı sorular üzerinde soru soru kıyaslamak. | |
| - **Non-inferiority, marj (m):** "Yeni sistem eskisinden en fazla m kadar kötü olabilir" iddiasını sınayan test. | |
| - **Yanlış FAIL, yanlış PASS:** İyi bir değişikliği engellemek ve kötü bir değişikliği kaçırmak (Tip I ve Tip II hata). | |
| - **Güç, MDE:** Testin gerçek bir farkı yakalama olasılığı ve yakalayabildiği en küçük fark. | |
| - **Ön-kayıt:** Hipotezleri ve karar kurallarını sonuçları görmeden yazıp sabitlemek. | |