BM25'ten LLM-as-a-Reranker’a: Kişisel RAG Projemde Hibrit Aramayı Kurarken Öğrendiklerim

Kişisel bir RAG sistemi kurmaya başladığımda, asıl zorluğun LLM seçimi, prompt mühendisliği veya değerlendirme tarafında olacağını düşünüyordum. Retrieval kolay kısım gibi görünüyordu ( yanılmışım. ) Gerçek karmaşıklık tam da oradaydı, işe yarayan bir şeye ulaşmam üç iterasyon sürdü.

Bu yazı o yolculuğu anlatıyor: neden saf vektör araması yetmedi, BM25 ve RRF tabanlı hibrit aramayı neden değerlendirdim ve sonunda neden skor füzyonu yerine LLM-as-a-Reranker yaklaşımını tercih ettim.

Vektör Araması Nerede Yetersiz Kalır?

Vektör araması, sorgunuzu ve belgelerinizi yüksek boyutlu embedding’lere dönüştürür, sonra kosinüs benzerliğiyle en yakın olanları bulur. Semantik anlama konusunda güçlüdür, kullanıcı “kaldıraçlı pozisyonların riskleri nedir” diye sorduğunda, “marj çağrıları ve zorla tasfiye” gibi ifadeler içeren bir chunk’ı bulabilir ( sorgu kelimelerinin hiçbiri orada geçmese bile. )

Ama vektör aramasının bir kör noktası var: tam terminoloji.

Teknik alanlarda ( hukuk, finans, tıp ) kelimelerin tam karşılığı önemlidir. “BDDK Tier 1 sermaye oranı” diye sorgulayan bir kullanıcı, tam olarak o terimleri içeren sonuçlar bekler; “banka çözümleme çerçeveleri” veya “sermaye yeterliliği” gibi semantik olarak yakın ama farklı içerikler değil. Embedding modelleri bu ayrımı düzleştirir. Tier 2 sermayeyle ilgili bir chunk, Tier 1 hakkındakiyle neredeyse aynı skoru alabilir ( çünkü semantik mesafe küçüktür. )

İşte burada anahtar kelime araması yeniden devreye girer.

BM25: Eski Ama Ölmedi

BM25 ( Best Match 25 ), terim sıklığı ve ters belge sıklığına dayanan klasik bir bilgi erişim algoritmasıdır. Anlam kavramaz, kelime eşleştirir. Bu zayıflık gibi görünebilir, ama tam terminolojinin önemli olduğu durumlarda tam olarak ihtiyacınız olan şeydir.

BM25 bir chunk’ı şu durumlarda yüksek puanlar:

• Sorgu terimleri o chunk’ta geçiyorsa ( terim sıklığı )
• O terimler corpus genelinde görece nadir ise ( ters belge sıklığı )

Formül şu şekilde:

score(D, Q) = Σ IDF(qi) (f(qi, D) (k1 + 1)) / (f(qi, D) + k1 (1 — b + b |D| / avgdl))

Burada f(qi, D) terimin belgede kaç kez geçtiği, |D| belge uzunluğu, avgdl ortalama belge uzunluğu, k1 ve b ise ayar parametreleridir ( genellikle 1.5 ve 0.75. )

Pratik sonuç: BM25 hızlı, deterministik ve domain-specific anahtar kelime sorguları için mükemmeldir. Sorgu ile belge farklı kelimeler kullandığında başarısız olur ( tam da vektör aramasının güçlü olduğu yer. )

Mantıklı adım: ikisini birleştirmek.

Hibrit Arama: İki Yaklaşım

Ağırlıklı Ortalama

En basit füzyon yöntemi. Her iki aramayı çalıştırır, ham skorları alır ve ağırlıklı toplamla birleştirirsiniz:

final_score = α vector_score + (1 — α) bm25_score

α = 0.7 ayarlarsanız “zamanın %70'inde semantik benzerliğe güveniyorum” demiş olursunuz. Sorun şu: BM25 ve vektör skorları farklı ölçeklerde yaşar. 0.85'lik bir kosinüs benzerliği ile 12.4'lük bir BM25 skoru doğrudan karşılaştırılamaz. Normalizasyon gerekir ve normalizasyon seçimi her şeyi etkiler.

Reciprocal Rank Fusion ( RRF )

RRF normalizasyon problemini tamamen devre dışı bırakır. Ham skorlar yerine sıralamayı kullanır:

RRF_score(d) = Σ 1 / (k + rank_i(d))

Burada rank_i(d), d belgesinin i. sıralama listesindeki pozisyonu, k ise genellikle 60 olan bir sabittir.

Sezgi şu: bir chunk vektör aramasında 1. sırada, BM25'te 3. sıradaysa yüksek kombine skor alır. Sadece bir listede görünüyorsa daha düşük skor alır. Sıralama sinyali, ham skor sinyalinden daha sağlamdır.

RRF ölçekten bağımsız, uygulaması kolay ve pratikte iyi çalışıyor. Pek çok prodüksiyon arama sisteminde varsayılan tercih ( ve çoğu zaman yeterli. )

İkisinin de Yetersiz Kaldığı Nokta

RRF’i implement ettim ve golden test setimde çalıştırdım. Sonuçlar saf vektör aramasından iyiydi ( şaşırtıcı değil. ) Ama belirli bir pattern’de başarısızlıklar görmeye devam ettim.

Çalıştığım domain yüksek bağlam bağımlı sorgular içeriyordu. “Çeyreklik eşik değer” gibi bir sorgu, belgenin hangi bölümüne bakıldığına göre düzenleyici bir sınırı, bir performans kriterini veya bir raporlama tarihini ifade edebilirdi. BM25, “çeyreklik” ve “eşik” kelimelerini içeren chunk’ları bağlam yanlış olsa bile yüksek sıralıyordu. Vektör araması bazen tam terimi kaçırıyordu ama doğru bağlamı buluyordu.

RRF bunu çözemedi. İki kısmen doğru sinyalin ortalamasını alıyordu ve sonuç odaksız bir retrieval’dı ( teknik olarak alakalı chunk’lar, ama o sorgu için en alakalı olanlar değil. )

Sorun füzyon formülü değildi. Sorun şuydu: bu domainde alaka düzeyi, chunk’ları okumayı gerektiriyordu, sadece skorlamayı değil.

LLM-as-a-Reranker Kararı

Fikir basit: skor füzyonu yapmak yerine, her iki pipeline’dan adayları alıp bir LLM’e hangi chunk’ın sorguyu daha iyi yanıtladığını sor.

prompt = f"""
Kullanıcı sorgusu: {query}

Aday A (vektör aramasından):
{chunk_a}

Aday B (anahtar kelime aramasından):
{chunk_b}

Hangi aday sorguyu daha iyi yanıtlıyor? Hiçbiri tam tatmin edici değilse,
ikisinin en alakalı kısımlarını birleştir. Sadece en iyi bağlamı döndür.
"""

LLM her iki chunk’ı okuyabilir, sorgu niyetini anlayabilir ve bir skor füzyon formülünün yapamayacağı yargı kararı verebilir. Bu, sıralama kararını matematiksel bir sezgiselden dil anlama görevine taşımak demek.

Ödünleşimler

Bu elbette bedava gerçekleşmiyor. Maliyetler konusunda dürüst olmak istiyorum:

Gecikme: RRF retrieval’ınıza ~0 ms ekler. LLM yeniden sıralama başka bir LLM çağrısı ekler ( benim kurulumumda yaklaşık 300–500ms. ) Gerçek zamanlı bir sistem için bu önemlidir ve mimarinize dahil edilmesi gerekir.

Maliyet: Her yeniden sıralama çağrısı faturalandırılabilir bir LLM çıkarımıdır. Ölçekte bu hızla birikerek artar. Bunu semantik önbellek ile azalttım ( gelen bir sorgu daha önce yanıtlanmış bir sorguya kosinüs benzerliği açısından yakınsa, eşik 0.90, tam pipeline’ı atlayıp önbellekten sonucu döndürüyorum. )

Tutarlılık: Matematiksel füzyon deterministiktir. LLM yeniden sıralama sıcaklık tabanlı varyansa sahiptir. Bunu en aza indirmek için yeniden sıralayıcıda sıcaklığı sıfıra yakın ayarladım ( ama izlemeye değer. )

Yargı önyargısı: LLM yeniden sıralayıcının kendi önyargıları var, daha kısa olanı daha kesin olsa bile daha uzun, daha ayrıntılı chunk’ları tercih edebilir. Bunu kısmen, yeniden sıralama için üretimden farklı bir model mimarisi kullanarak ele aldım ( farklı eğitim pipeline’larının aynı başarısızlık modlarını paylaşma olasılığı daha düşük. )

Hangi Yaklaşımı Ne Zaman Kullanmalı?

Üç iterasyonun ardından kafamdaki karar çerçevesi şöyle:

Saf vektör aramasını kullanın: corpus’unuz semantik açıdan zenginse, sorgularınız konuşma tonundaysa ve tam terminoloji çok önemli değilse.

RRF hibrit aramayı kullanın: domain’inizde belirli bir kelime dağarcığı varsa, hızlı ve ucuz bir çözüme ihtiyaç duyuyorsanız ve sorgu niyeti görece net ise. Bu, prodüksiyon RAG kullanım durumlarının büyük çoğunluğunu kapsar.

LLM-as-a-Reranker kullanın: domain’iniz yüksek uzmanlaşmış ise, sorgu niyeti belirsiz veya bağlam bağımlı ise ve ek gecikme ile maliyeti karşılayabiliyorsanız. Retrieval kalitesi iyileşmesi gerçek ( ama maliyet de öyle. )

Çoğu proje için RRF doğru varsayılandır. LLM yeniden sıralama, retrieval kalitesinin darboğazınız olduğunu ölçtüğünüzde yaptığınız bilinçli bir mimari yükseltmedir.

Son Düşünceler

Bu projeden çıkardığım en önemli ders: retrieval kalitesi, model seçiminden daha fazla yanıt kalitesini belirler. GPT-4'ü daha küçük bir modelle değiştirebilir ve biraz üretim kalitesi kaybedebilirsiniz. Ama retrieval yanlış bağlamı getirirse, hiçbir model yanıtı kurtaramaz.

BM25 ölmedi. RRF gerçekten iyi çalışıyor. Ve bazen doğru araç, adayları okuyup yargı kararı veren bir LLM ( tıpkı bir insanın yapacağı gibi. )