Reranker Nedir? RAG Arama Kalitesini Artırma

Şirket içi dokümantasyon üzerinde RAG sistemi kuruyorsunuz. Vektör araması hızlı çalışıyor, alaka puanları da mantıklı görünüyor. Ama LLM’e gönderdiğiniz top-5 belgeyi incelediğinizde bazıları yanlış sırada: en kritik paragraf dördüncü belgede, LLM’in önce gördüğü belgeler ise soruyu çevre bağlamdan yanıtlıyor. Cevap yanlış değil, ama eksik.

Bu senaryo, vektör aramasının tek başına nasıl bir tavan yarattığını gösteriyor. Embedding modeli sorguyu ve belgeyi ayrı ayrı anlıyor; aralarındaki gerçek ilişkiyi derinlemesine değerlendirme şansı yok. Reranker bu boşluğu kapatır.

Reranker nedir?

Reranker, bir retrieval pipeline’ının ikinci aşamasında görev yapan bir puanlama modelidir. İlk aşamada vektör araması onlarca aday belge döndürür; reranker bu adayların her birini sorguyla birlikte tekrar değerlendirip 0 ile 1 arasında bir alaka skoru atar. En yüksek puanlı belgeler LLM’e iletilir, geri kalanlar süzülür.

Temel fikir şu: hız ve hassasiyet ikilemi. Büyük belge koleksiyonlarında milisaniyelerde sonuç döndürmek için embedding araması gerekir. Ancak embedding araması, sorgu ile belge bağlamını tam olarak kesiştiremez. Reranker bu sorunu farklı bir mimariyle çözer: sorguyu ve belgeyi aynı anda, yan yana işler. Bu çapraz dikkat (cross-attention) mekanizması, basit vektör benzerliğinin yakalayamadığı nüanslı alaka örüntülerini ortaya çıkarır.

İki aşamalı retrieval akışı şöyle görünür:

1. Yüksek recall aşaması: Embedding modeli sorguyu vektöre dönüştürür, vektör veritabanı en yakın 50-100 belgeyi döndürür. Bu adım hızlıdır; belgeler önceden indekslenmiş ve sorgu geldiğinde ek hesaplama gerektirmez.
2. Yüksek precision aşaması: Reranker bu 50-100 adayın her birini sorguyla birleştirip ayrı ayrı değerlendirir. Sonuçta en alakalı 5-10 belge listesi oluşturulur. Bu liste LLM’e girer.

Ekstra adım, latency ve maliyet ekler. Buna karşın sistem yanıt kalitesi üretim ortamlarında ölçülebilir biçimde artar.

Bi-encoder vs cross-encoder farkı

RAG sistemlerinde iki temel mimari var. Bunların farkını kavramadan reranker’ı doğru konumlandırmak güçleşir.

Bi-encoder (embedding modeli)

Sorgu ve belgeyi ayrı ayrı encode eder. Her biri bağımsız bir vektöre dönüştürülür; alaka puanı bu iki vektör arasındaki kosinüs benzerliğinden hesaplanır. Belgeler önceden encode edilip veritabanına kaydedilebildiğinden, bir sorgu geldiğinde yalnızca sorgu encode edilir ve vektör karşılaştırması yapılır. Bu yaklaşım milyonlarca belge üzerinde milisaniyelerde çalışır. Embedding modelleri yazısında bu mimarinin nasıl çalıştığını adım adım inceledik.

Bi-encoder’ın zayıf noktası şu: sorgu ve belge hiçbir zaman aynı anda işlenmiyor. Model iki bağlamı birbirine karıştırmıyor; bu yüzden ince anlam farklılıklarını yakalamakta zorlanabiliyor.

Cross-encoder (reranker)

Sorgu ve belgeyi tek bir girdi olarak alır. Transformer, her iki metnin tüm token’larına aynı anda dikkat uygular. Çapraz dikkat sayesinde sorgudaki her kelime, belgedeki her kelimeyle etkileşime giriyor. Bu çok daha zengin bir temsil üretiyor.

Dezavantaj: belgeler önceden encode edilemiyor. Her yeni sorgu için, her aday belge ayrı ayrı işlenmeli. Hesaplama maliyeti belge sayısıyla doğrusal artıyor; bu yüzden cross-encoder doğrudan geniş koleksiyonlarda arama için kullanışsız.

İkisi birbirinin alternatifi değil, tamamlayıcısı. Bi-encoder hızlı bir eleme yapar; cross-encoder bu elemeyi hassaslaştırır.

RAG pipeline’ına reranker ekleme

RAG sistemi, kullanıcının sorusunu yanıtlamak için harici belgelerden bilgi çeken bir mimaridir. Temel akışa reranker eklemek görece kolaydır; tek bir adım eklenir.

Reranker olmadan:

Kullanıcı sorusu → Embedding → Vektör araması (top-5) → LLM → Cevap

Reranker ile:

Kullanıcı sorusu → Embedding → Vektör araması (top-50) → Reranker (top-5 seç) → LLM → Cevap

Önemli bir nokta: reranker eklendiğinde vektör aramasından kaç belge alındığı da değişir. Önceden top-5 almak yeterliydi; reranker ile top-20 ile top-100 arasında aday toplamak mantıklı hale gelir. Daha fazla aday recall’ı artırır, ancak reranker maliyeti de büyür. Tipik üretim başlangıç konfigürasyonu: vektör aramasından top-50, reranker çıktısından top-5.

Agentic RAG sistemlerinde reranker daha kritik bir işlev üstlenir. Çok adımlı retrieval döngüsünde her iterasyonda farklı alt sorgular üretiliyor; reranker her adımın çıktısını temizleyerek ajanın doğru yönde ilerlediğini pekiştirir. Özellikle çelişen belgeler arasında öncelik sıralaması yapmak, tek bir modelin görev kapsamını aşar; iki kademeli mimari bu yükü paylaştırır.

Popüler reranker modelleri

2024-2026 döneminde birkaç model öne çıktı. Seçim, kullanım senaryonuza ve kısıtlarınıza bağlı.

Cohere Rerank

API tabanlı bir servis. rerank-multilingual-v3.0 sürümü Türkçe dahil 100’den fazla dili destekliyor. Pek çok benchmark’ta açık kaynak alternatiflerin önünde yer aldı. Kurumsal entegrasyonlar için tercih edilen bir seçenek; kullanım başına ücretlendirme modeli var. Özellikle LangChain ve LlamaIndex entegrasyonu birkaç satır kod gerektiriyor.

BGE Reranker (BAAI)

Beijing Academy of Artificial Intelligence’ın açık kaynak model ailesi. BAAI/bge-reranker-v2-m3 modeli çok dilli görevlerde güçlü performans sergiliyor. Yerel olarak çalışır; API maliyeti olmadığından veri gizliliği gerektiren ortamlar için iyi bir seçenek. GPU gerektiriyor; CPU’da da çalışır ama çok yavaşlar.

Jina Reranker

jina-reranker-v2-base-multilingual modeli, küçük boyutuna karşın rekabetçi sonuçlar veriyor. Hugging Face’ten indirilebilir. Jina, hem API hem de yerel kullanım seçeneği sunuyor.

MS MARCO tabanlı modeller

Microsoft’un MS MARCO veri seti üzerinde fine-tune edilmiş modeller, arama odaklı uygulamalar için sağlam bir başlangıç noktası. cross-encoder/ms-marco-MiniLM-L-6-v2 minimal donanım kullanımıyla üretimde çalışabilen küçük bir model. Türkçe desteği sınırlı; Türkçe içerikte BGE Reranker veya Cohere tercih edilmeli.

Python ile uygulama

İki yaklaşımı pratikte gösterelim: yerel model ve API.

sentence-transformers ile yerel cross-encoder

from sentence_transformers import CrossEncoder

model = CrossEncoder("BAAI/bge-reranker-v2-m3")

query = "Python'da vektör araması nasıl yapılır?"
candidates = [
    "Pinecone ile vektör veritabanı kurulumu",
    "Python liste sıralaması için sorted() fonksiyonu",
    "FAISS ve ChromaDB ile ANN araması",
    "SQLite ile ilişkisel veritabanı tasarımı",
    "OpenAI embedding API'yi Python'da kullanmak",
]

# Her (sorgu, belge) çifti için puan hesapla
pairs = [(query, doc) for doc in candidates]
scores = model.predict(pairs)

# Yüksekten düşüğe sırala
ranked = sorted(zip(scores, candidates), reverse=True)
for score, doc in ranked:
    print(f"{score:.3f}  {doc}")

Beklenen çıktıda “FAISS ve ChromaDB ile ANN araması”, “Pinecone ile vektör veritabanı kurulumu” ve “OpenAI embedding API’yi Python’da kullanmak” üst sıralara çıkar. “Python liste sıralaması için sorted()” ve “SQLite ile ilişkisel veritabanı tasarımı” ise alaka puanı düşük olduğundan alta iner.

Cohere Rerank API ile

import cohere

co = cohere.Client("COHERE_API_KEY")

results = co.rerank(
    model="rerank-multilingual-v3.0",
    query="Python'da vektör araması nasıl yapılır?",
    documents=candidates,
    top_n=3,
)

for hit in results.results:
    idx = hit.index
    print(f"Sıra {idx}: {candidates[idx]} (skor: {hit.relevance_score:.3f})")

Cohere API özellikle çok dilli senaryolarda güvenilir. Türkçe sorgular ve belgeler için rerank-multilingual-v3.0 iyi bir başlangıç noktası.

LlamaIndex entegrasyonu — LlamaIndex kullanıyorsanız reranker’ı birkaç satırla pipeline’a ekleyebilirsiniz:

from llama_index.postprocessor import CohereRerank
from llama_index import VectorStoreIndex, SimpleDirectoryReader

documents = SimpleDirectoryReader("data").load_data()
index = VectorStoreIndex.from_documents(documents)

reranker = CohereRerank(api_key="COHERE_API_KEY", top_n=3)

query_engine = index.as_query_engine(
    similarity_top_k=20,
    node_postprocessors=[reranker],
)

response = query_engine.query("RAG sisteminde latency nasıl azaltılır?")

similarity_top_k=20 ile ilk aşamada 20 belge alınıyor; reranker bunları 3’e indirgiyor.

Reranker ne zaman gerekli?

Her RAG sistemi reranker gerektirmez. Eklemenin anlamlı olduğu durumlar şunlar:

Uzun belgeler: Embedding modelleri genellikle 256-512 token penceresini iyi temsil eder; belgenin geri kalanı kısmen gözden kaçar. Cross-encoder tam metni işlediğinden uzun pasajlarda fark belirginleşir.

Bileşik sorgular: “X nasıl çalışır ve Y’den farkı ne?” gibi çok parçalı sorularda bi-encoder ortalamaya yakın bir temsil üretir. Cross-encoder bu iki koşulu ayrı ayrı değerlendirebilir.

Yüksek hassasiyet gerektiren alanlar: Hukuki belgeler, tıbbi kayıtlar, finansal raporlar. Yanlış bir pasajın LLM’e girmesinin bedeli yüksektir; ikinci bir eleme katmanı bu riski düşürür.

Düşük sorgu hacmi: Reranker eklenen gecikme süresini ve maliyeti, düşük hacimlerde fark etmek güçleşir. Günde birkaç yüz sorgu yapan kurumsal uygulamalarda bu fark önemsiz kalır.

Eklemek gerekmeyebilir:

• Belgeler kısa ve homojen (128 token altında chunk’lar), vektör araması zaten yüksek precision veriyor.
• Arama sorguları dar ve tekrarlı; kullanım senaryosu sabit ve öngörülebilir.
• Latency bütçesi sıkı ve mevcut sistem doğruluğu kabul edilebilir seviyelerde.

Vektör veritabanı seçimi de bu hesabı etkiler. Bazı vektör veritabanları hybrid search (yoğun vektör + BM25 anahtar kelime) sunarak reranker’dan beklenen kısmi kazancı zaten karşılar. Pinecone Hybrid Search veya Weaviate’in BM25+dense konfigürasyonu iki sinyal birleştirdiğinden, reranker’ın marjinal katkısı bu sistemlerde daha küçük olabilir.

Sık sorulan sorular

Reranker embedding modelinin yerini alır mı?

Hayır. Reranker, embedding modelleri ile birlikte çalışır; onların yerini almaz. Embedding modeli büyük bir koleksiyonda hızla aday belirler. Reranker bu adayları ikinci kez değerlendirir. İkisi farklı sorunu çözüyor ve her biri kendi aşamasına ait.

Kaç aday reranker’a verilmeli?

Üretim sistemlerinde 20-100 aday alınıp 3-10 belge seçilmesi yaygın bir aralık. 50 aday iyi bir başlangıç noktasıdır; kendi veri kümenizde NDCG@k veya Precision@k ölçerek ayarlayın. Aday sayısını artırmak recall’ı büyütür ama reranker maliyeti ve latency de yükselir.

Açık kaynak model mi, API mi kullanmalıyım?

Cohere gibi API’ler kurumsal SLA, izleme ve hazır dil desteği sunar; entegrasyon kolaylığı öne çıkar. BGE Reranker ve Jina gibi açık kaynak modeller ise veri gizliliği gerektiren ortamlarda veya yüksek işlem hacminde maliyet açısından avantajlıdır. İkisini de küçük bir test seti üzerinde kıyaslamak, seçimi kolaylaştıracaktır.

Reranker nasıl değerlendirilir?

NDCG@10 (Normalized Discounted Cumulative Gain) ve MRR (Mean Reciprocal Rank) en yaygın metrikler. Kendi veri kümenizde etiketli bir test seti oluşturup reranker öncesi ve sonrasını karşılaştırmak en güvenilir yol.

Reranker fine-tune edilebilir mi?

Evet. BGE Reranker gibi açık kaynak modeller, alan özgü verilerle ince ayar yapılabilir. Eğitim için (sorgu, ilgili belge, ilgisiz belgeler) üçlülerine ihtiyaç var. Bu veri genellikle mevcut log’lardan veya LLM ile sentetik olarak üretilebilir. Cohere de enterprise planında özel fine-tuning seçeneği sunuyor.

Latency kaç ms artar?

Bu sorunun cevabı modele, donanıma ve aday sayısına göre değişir. Cohere Rerank API tipik olarak 200-500 ms ekler. Yerel BGE Reranker GPU’da 50 adayı 100-300 ms içinde işleyebilir; CPU’da bu süre 1-3 saniyeye çıkabilir. Kullanıcıya yönelik gerçek zamanlı sistemlerde bu gecikme kritik; iç araçlarda ya da asenkron pipeline’larda daha kabul edilebilir.