RAG için Reranker: Cohere, Cross-Encoder ve Performans 2026

RAG sistemlerinde rerank rag katmanı, ilk aşamada toplanan 50-200 aday dokümanı sorgu-doküman bağlamına göre yeniden sıralayan ikinci aşama puanlama mekanizmasıdır. 2026 itibarıyla üretim hattındaki kurumsal RAG kurulumlarının büyük kısmı sade dense retrieval ile yetinmiyor: bi-encoder (ör. text-embedding-3-large veya BGE-M3) ile geri çağrılan adayları, cross-encoder bir reranker üzerinden geçirip top-K’yı 5-10 dokümana indirgeyen iki kademeli mimari standart hâline geldi. Cohere Rerank 3.5, BAAI bge-reranker-v2-m3, Jina Reranker v2 ve mxbai-rerank-large-v1 gibi modeller arasındaki seçim; latency bütçesi, dil kapsamı, throughput hedefi ve API’ye karşı self-host kararına bağlıdır.

Bu yazı, reranker’ın matematiksel mantığından başlayıp Cohere API ile self-host cross-encoder arasındaki maliyet ve gecikme dengesine, NDCG@10 ve MRR ölçüm yöntemine, üretim ortamında batch boyutu ve GPU bellek planlamasına kadar uçtan uca pratik çerçeve sunuyor. Hedef; embedding tabanlı geri çağırma ile cross-encoder rerank’in birbirini tamamladığı iki kademeli boru hattını, ölçülebilir kalite kazancıyla devreye almaktır.

Reranker neden gerekli: bi-encoder’ın yapısal sınırı

Bi-encoder mimaride sorgu ve doküman ayrı ayrı vektöre dönüştürülür; benzerlik ise nokta çarpım veya kosinüs üzerinden hesaplanır. Bu yaklaşım milyarlarca doküman üzerinde milisaniye altı arama yapabilmeyi mümkün kılar, ancak sorgu ile doküman arasındaki çapraz dikkat (cross-attention) etkileşimini kaybeder. Cross-encoder reranker ise sorgu ve doküman çiftini tek bir transformer dizisine yollar, [CLS] üzerinden ikili alaka skoru üretir. Bu nedenle çok daha hassas; ama her çift için ayrı forward pass gerektirdiği için maliyetli.

BEIR benchmark sonuçlarında BM25 + cross-encoder ikili boru hattı, sade BM25’e göre ortalama NDCG@10 değerini 0.43 seviyesinden 0.53 üzerine taşıyabilmektedir. MTEB sıralamasında üst sıralardaki dense retriever’lara cross-encoder reranker eklendiğinde, MS MARCO dev MRR@10 metriği tipik olarak 0.36-0.38’den 0.41-0.43 bandına çıkmaktadır. Bu, sıralama kalitesinde yaklaşık %12-18’lik göreceli iyileşme demektir.

Cross-attention’ın gücü, dilbilgisel uyumdan negasyona, çok cümleli sorgudan kavramsal benzetmeye kadar bi-encoder’ın eksik kaldığı bağlamı yakalamasından gelir. Üretim ortamında bu kazanç, halüsinasyon oranlarının düşmesi ve son cevabın LLM hallucination azaltma stratejilerinde groundedness skorunun yükselmesi olarak somutlaşır.

İki kademeli RAG mimarisi: retriever + reranker boru hattı

Tipik üretim hattı şu sırayı izler: kullanıcı sorgusu → hybrid retrieval (BM25 + dense) → top-N aday (N tipik 50-200) → cross-encoder reranker → top-K (K tipik 5-10) → LLM bağlamı. Bu mimari hem geri çağırma adımının geniş tarama avantajını hem de rerank adımının hassasiyet kazancını birleştirir.

Boru hattı tasarımı genelde şu kararları içerir: hangi N değeri seçilecek, reranker hangi model olacak (API mi, self-host mu), batch boyutu ne olacak, latency bütçesi nasıl dağılacak, hangi durumda rerank atlanacak (cache hit veya kısa-yol). N değeri ne kadar büyürse rerank latency’si lineer artar ama recall artışı 100’den sonra hızla düz çizgiye yaklaşır.

Mimari katman	Tipik gecikme	Top-N büyüklüğü	Asıl kazanç
BM25 (Elasticsearch / OpenSearch)	10-30 ms	200-500	Tam eşleşme, jargon
Dense retrieval (Qdrant / Pinecone)	15-50 ms	50-200	Semantik yakınlık
Hybrid füzyon (RRF)	+2-5 ms	100-200	BM25 + dense birleşimi
Cross-encoder rerank	80-300 ms	50→10	Çapraz dikkat hassasiyeti
LLM generation	1-4 s	Top-5 doküman	Cevap üretimi

Reranker katmanının gecikme bütçesi, son kullanıcı yanıt süresinin tipik olarak %5-15’ini kaplar. LLM jenerasyon hâlâ baskın maliyet kalemi; ama rerank kalitesinin LLM’in halüsinasyon riski üzerindeki etkisi, bu küçük bütçeyi kat be kat geri öder. RAG altyapı kurulumu rehberinde tüm boru hattını uçtan uca ele aldık.

Cohere Rerank 3.5: yönetilen API yaklaşımı

Cohere’in Rerank 3.5 modeli, multilingual desteğiyle (100+ dil, Türkçe dahil) yönetilen reranker pazarında lider konumda. API üzerinden çağrılan model, geliştirici tarafında GPU yatırımı gerektirmemesi, ölçeklenmenin Cohere tarafında yönetilmesi ve düşük gecikme bölgeleri (AWS Bedrock, Azure AI Foundry üzerinden dağıtık) sayesinde hızlı go-live sağlar.

Resmi Cohere Rerank dokümantasyonu tek bir POST isteğiyle query, documents ve top_n parametresi alıp sıralı skorlu liste döndüren basit bir arayüz sunar. Pricing modeli “1.000 arama başına” formülüne dayanır; tek arama içinde 100 dokümana kadar değerlendirme yapılabilir. 2026 itibarıyla yayımlanmış vendor sayfasında Rerank 3.5 listesi 1000 search başına 2 USD bandında konumlanmakta; tam fiyat coğrafya ve sözleşmeye göre farklılaşabilir.

Özellik	Cohere Rerank 3.5	Voyage rerank-2	Jina Reranker v2 Base
Tür	Yönetilen API	Yönetilen API	API + self-host (Apache 2.0)
Dil kapsamı	100+ dil, Türkçe iyi	İngilizce ağırlıklı	Multilingual, 100+ dil
Maks doküman/istek	~1.000 (chunk’lanır)	~1.000	1024 token pencere
Bağlam penceresi	4.096 token	16.000 token (long context)	8.192 token
Self-host opsiyonu	Yok (API only)	Yok	Var (HuggingFace)
Tipik p50 gecikme (100 doc)	180-250 ms	200-300 ms	160-220 ms (API)

Cohere’in tercih edilme gerekçeleri; çok dilli kalite (Türkçe sorgu + Türkçe doküman çiftinde tutarlı NDCG kazancı), Bedrock/Azure entegrasyonu (compliance bölgesinde tutma), düşük operasyonel yük. Dezavantaj olarak çıkan başlıklar; API bağımlılığı, dış data residency (kontratla yönetilse de hassas sektörde bariyer), API quota planlama gereksinimi.

• Ne zaman seç: Hızlı POC, çok dilli kurumsal arama, operasyon ekibi minimal, regülasyon Cohere/Bedrock bölgesinde rahat.
• Ne zaman kaçın: Kapalı ortam (air-gapped), saniyede binlerce sorgu, doküman içerik gizliliği üst düzey.
• Avantaj: Sıfır GPU planlama, anında ölçeklenme, çoklu dil kalitesi.
• Dezavantaj: Per-call ücret, vendor lock-in, fine-tuning yok.

Açık kaynak cross-encoder modeller: BGE, Jina, MXBai

Self-host tarafında öne çıkan üç aile var: BAAI bge-reranker (v2-m3, v2-gemma), Jina Reranker v2, mxbai-rerank (large-v1). Bu modeller Apache 2.0 veya benzeri açık lisansla HuggingFace üzerinden indirilebilir ve sentence-transformers ya da TEI (Text Embeddings Inference) çatısı altında servis edilebilir.

BGE Reranker v2-m3, 568M parametre civarındaki XLM-RoBERTa tabanlı multilingual modeldir; MTEB ve C-MTEB reranking görevlerinde sıklıkla üst sıralarda yer alır. Jina Reranker v2 Base Multilingual benzer büyüklükte, FlashAttention destekli ve daha hızlı (yaklaşık 1.5x throughput kazancı raporlanır). mxbai-rerank-large-v1 ise English ağırlıklı, BEIR’da rekabetçi skorlarla bilinir.

Model	Parametre	Lisans	BEIR NDCG@10 (avg)	Multilingual	Tipik VRAM
bge-reranker-v2-m3	~568M	Apache 2.0	0.55-0.57 bandı	Evet (100+ dil)	~2.5 GB (fp16)
bge-reranker-v2-gemma	~2B	Apache 2.0	0.58-0.60 bandı	Kısmen	~5 GB (fp16)
jina-reranker-v2-base-multilingual	~278M	Apache 2.0	0.53-0.56 bandı	Evet	~1.2 GB (fp16)
mxbai-rerank-large-v1	~435M	Apache 2.0	0.54-0.56 bandı	Kısmen	~1.8 GB (fp16)
ms-marco-MiniLM-L-12-v2	~33M	Apache 2.0	0.47-0.50 bandı	Hayır	~140 MB

HuggingFace üzerindeki BAAI bge-reranker-v2-m3 model kartı ve Jina v2 base multilingual sayfası; eğitim verisi, lisans ve kullanım örneklerini barındırır. MiniLM tabanlı küçük modeller (33-66M), düşük gecikme bütçesinde Türkçe olmayan iş yüklerinde hâlâ tercih edilir.

Self-host tarafında kararlı stack genelde Hugging Face TEI veya BentoML üzerine kurulur. Türkçe dahil çok dilli senaryolarda bge-reranker-v2-m3 ve Jina v2 multilingual, Cohere alternatifi olarak NDCG@10 farkı %2-4 bandında kalır; bu küçük açığa karşılık API maliyeti tamamen ortadan kalkar ve veri sınır içinde tutulur. Embedding modelleri karşılaştırma yazısında retriever tarafındaki tercihleri detaylandırdık.

Latency ve throughput: batch, FP16, GPU planlaması

Cross-encoder gecikmesi temelde üç değişkenle yönetilir: model boyutu, batch boyutu ve donanım. 568M parametreli bir XLM-RoBERTa modeli için NVIDIA A10G üzerinde, 512 token sorgu+doküman çifti, batch=32, fp16 ile tipik latency 80-120 ms aralığındadır. Aynı model T4 üzerinde batch=16 ile 180-260 ms’ye çıkar; L4 veya L40S üzerinde 50-90 ms bandına iner. CPU only deployment (Xeon Sapphire Rapids, ONNX + AVX-512) 600-900 ms civarındadır ve genelde önerilmez.

Donanım	Model	Batch	p50 latency (100 doc)	RPS (tek replika)
NVIDIA T4 (16 GB)	bge-v2-m3, fp16	16	~220 ms	3-4
NVIDIA A10G (24 GB)	bge-v2-m3, fp16	32	~110 ms	7-9
NVIDIA L4 (24 GB)	bge-v2-m3, fp16	32	~85 ms	9-12
NVIDIA L40S (48 GB)	bge-v2-gemma, fp16	16	~140 ms	5-7
CPU Xeon SPR (32 vCPU)	MiniLM-L12, ONNX int8	16	~210 ms	2-3

Gerçek üretim ortamında batch boyutunu seçerken hedef p99 gecikme sınırı baskın kriterdir. Eğer kullanıcıya 800 ms altı bir end-to-end yanıt vaat ediliyorsa ve LLM streaming 400 ms TTFT’yi yiyorsa, rerank için 100-150 ms’lik kati bütçe kalır. Bu durumda L4 + bge-v2-m3 + batch=32 + top-N=50 tipik bir tercihtir.

1. FP16 / BF16 zorunlu: FP32’ye göre 1.8-2.2x throughput, doğrulukta kayıp <%0.5.
2. Dinamik batching: TEI veya Triton Inference Server ile gelen istekleri 5-10 ms pencereye toplayıp birlikte forward.
3. ONNX + TensorRT: Statik şekil ve fp16 ile %20-30 ek gecikme kazancı.
4. Top-N kontrolü: N=100 yerine N=50 seçmek genelde NDCG@10 farkını 0.005-0.01 bandında bırakırken latency’yi yarıya indirir.
5. Replikasyon: Yatay ölçek için HPA kuralı GPU utilization >%70 değil, p95 latency >hedef olmalı.

Ölçüm: NDCG@10, MRR, Recall@K ve Türkçe değerlendirme

Reranker’ın değerini ölçmek, doğru veri seti ve doğru metrik seçimine bağlıdır. BEIR (18 görev), MTEB Reranking, MS MARCO ve TREC-DL yaygın referanslar. Türkçe için tek başına yeterli açık benchmark yok; pratikte mevcut iç içerik üzerinden bir altın küme (query-doc ground truth) hazırlanması zorunludur.

Önerilen ölçüm protokolü; 100-300 sorgu için her sorguya 3-10 ilgili doküman etiketleyen anotasyon seti, BM25 ile top-200 toplama, sonra dense retriever ve rerank varyantlarını sırayla ölçme. Tipik metrik üçlüsü:

Metrik	Ne ölçer	Yorum bandı	Tipik bi-encoder → +rerank kazancı
NDCG@10	Sıralama kalitesi (graded)	0.45 zayıf, 0.55 iyi, 0.65 üst düzey	+0.08 ila +0.14
MRR@10	İlk doğru cevabın sırası	0.30 zayıf, 0.40 iyi, 0.50 üst	+0.06 ila +0.10
Recall@5	İlk 5’te yakalama oranı	0.60 zayıf, 0.75 iyi, 0.85 üst	+0.05 ila +0.12
Hit@1	İlk sonuç doğru mu	0.25 zayıf, 0.40 iyi, 0.55 üst	+0.04 ila +0.09

BEIR ve MS MARCO için resmi kod ve veri setleri beir-cellar/beir GitHub deposunda mevcut. RAGAS ve TruLens çerçeveleri ise rerank’in sonraki LLM cevabı üzerinden faithfulness ve context precision metrikleriyle dolaylı ölçümünü sunar; bu konuyu RAG evaluation yazısında ayrıntılandırdık.

Türkçe değerlendirme için pratik gözlem; multilingual cross-encoder’lar BEIR İngilizce skorlarının yaklaşık %85-92’sini Türkçe sorgu+doküman çifti üzerinde koruyor. Türkçe’ye özel fine-tune edilmiş tabanlar (BGE-M3 + LoRA, ~5.000 örnek) küçük seriler için bu farkı %1-3 bandına indirebilir. NLP çözümleri Türkçe yazısında dil-spesifik tahkim noktalarına değindik.

Hybrid retrieval + rerank: BM25, dense ve RRF füzyonu

Modern üretim RAG hatlarının çoğu, rerank’i tek başına dense retriever’ın üstüne koymak yerine; önce BM25 ile dense retriever sonuçlarını Reciprocal Rank Fusion (RRF) altında birleştirip ardından cross-encoder ile yeniden sıralıyor. Bu yaklaşım iki sorunu birlikte çözer: BM25 nadir terim ve tam eşleşmede güçlüdür; dense retriever semantik yakınlıkta. Füzyon, ikisinin kuvvetlerini birleştirir.

RRF formülü basittir: her sıralı liste için skor = 1 / (k + rank), k=60 standart. Birden çok listenin (BM25, dense-v1, dense-v2) RRF toplamı tek bir birleşik sıralamayı verir. Cross-encoder rerank bu birleşik top-N (genelde 100-200) üzerinde çalışır.

Strateji	NDCG@10 (tipik)	p95 latency	Açıklama
BM25 tek başına	0.42-0.46	~30 ms	Tam eşleşme güçlü, semantik zayıf
Dense tek başına	0.46-0.52	~50 ms	Semantik güçlü, nadir terimde zayıf
BM25 + Dense (RRF)	0.50-0.55	~60 ms	İki yöntemin tamamlayıcılığı
BM25 + Dense + Rerank	0.56-0.62	~200 ms	Üretim altın standart
Multi-vector (ColBERT)	0.54-0.59	~120 ms	Rerank’siz tek aşamada güçlü

ColBERT ve ColBERTv2 gibi multi-vector yaklaşımlar, bi-encoder ve cross-encoder arasında bir orta yol sunar; geç etkileşimli (late interaction) hesaplama ile cross-encoder’a yakın kalite, bi-encoder’a yakın gecikme hedefler. Ancak storage maliyeti (her token için ayrı embedding) klasik dense retrievera göre 8-20x artar; bu yüzden büyük korpus’ta tercih daralır.

Cohere API vs self-host: TCO ve karar çerçevesi

Toplam sahip olma maliyeti (TCO) hesaplamada üç kalem var: rerank başına ücret (Cohere) veya GPU+ops maliyeti (self-host), entegrasyon eforu ve operasyonel risk. Aylık 1 milyon arama (her aramada top-100 reranking) senaryosu için kabaca:

• Cohere Rerank 3.5: 1M arama × 2 USD / 1.000 ≈ 2.000 USD/ay. Sıfır GPU, sıfır MLOps. SLA Cohere tarafında.
• Self-host bge-v2-m3 (L4, AWS): g6.xlarge ~1.000 USD/ay × 1-2 replika = 1.000-2.000 USD/ay altyapı + MLOps ekip eforu (tipik 0.2-0.4 FTE).
• Break-even: Yaklaşık aylık 500K-1M arama üzeri self-host TCO avantajı belirginleşir; altta API daha rasyonel.

Senaryo	Aylık arama	Önerilen yol	Birincil gerekçe
POC / 1. demo	<50K	Cohere API	Hızlı go-live, GPU yok
Erken üretim	50K-500K	Cohere API + cache	Mühendislik fokusu LLM’de
Yüksek hacim B2C	>1M	Self-host bge / Jina	TCO ve data residency
Regüle sektör (finans/sağlık)	Tüm seviyeler	Self-host (VPC içi)	Veri sınır içi zorunluluk
Çok dilli kurumsal	100K-1M	Cohere veya Jina v2	Türkçe + 50 dil kalitesi

Kurumsal yapay zeka entegrasyonu kapsamında tasarım kararını verirken, salt fiyat değil; veri konum gereksinimi, ekip kapasitesi ve diğer LLM bileşenleriyle ortak GPU kullanım fırsatları da hesaba katılmalı. Aynı GPU üzerinde reranker + small LLM (örn. Mistral 7B AWQ) eş zamanlı barındırılabiliyorsa self-host ekonomisi belirgin biçimde lehe döner.

Production örnek: TEI ile bge-reranker servis etmek

Hugging Face Text Embeddings Inference (TEI) çatısı, cross-encoder modelleri tek bir Docker container ile servis etmenin standart yoludur. TEI; dinamik batching, FP16, ONNX export ve OpenAI uyumlu REST API destekler. huggingface/text-embeddings-inference GitHub deposu 2024 sonu itibarıyla 3.000+ yıldıza ulaşmıştır ve aktif geliştirme altındadır.

Tipik dağıtım komutu (özet): docker run --gpus all -p 8080:80 -v $HOME/data:/data ghcr.io/huggingface/text-embeddings-inference:1.5 --model-id BAAI/bge-reranker-v2-m3 --dtype float16 --max-batch-tokens 16384. Bu container; sağlık kontrolü, Prometheus metrikleri, /rerank endpoint’i ile birlikte gelir. Kubernetes üzerinde Helm chart, HPA p95 latency tetikleyicisi ve PodDisruptionBudget standart hijyendir.

• Health probe: /health endpoint 200 dönüyor mu.
• Metric: tei_request_duration_seconds_bucket (Prometheus histogram) p50/p95/p99.
• Logging: Yapısal JSON, sorgu+top-N+latency+model ID alanları.
• Backpressure: Concurrent request limit (genelde 32-64), aşımda 503.
• Canary: Yeni model sürümünü %5 trafikle test edip NDCG dashboard’unda regresyon eşiğini izleme.

Üretim mimarisinde rerank servisi tek başına izole bir microservice olarak çalışır; retriever ile aynı pod’a koymak antipattern’dir, çünkü ölçeklendirme profilleri farklıdır. Bu ayrım, modüler tool çağırma desenleri ve kurumsal otomasyon mimarileriyle de uyumludur. Servis sınırı, GPU kaynağını rerank-only iş yüküne dedike etmeyi ve ileride model güncellemesini retriever’dan bağımsız ele almayı sağlar.

Reranker’ın bilinen tuzakları ve karşı önlemler

Cross-encoder rerank her zaman kalite getirmez; yanlış kurgulanmış senaryolarda gecikmeyi artırıp net fayda sağlamayabilir. Üretim hatlarında en sık karşılaşılan beş tuzak şudur:

1. Çok kısa doküman parçaları: 50-100 token chunk’lar cross-encoder’ın çapraz dikkat avantajını boşa çıkarır. Önerilen chunk 256-512 token, ~%10 overlap.
2. Aşırı büyük top-N: N=200 yerine N=50 seçmek genelde NDCG@10’da fark yaratmaz, latency’yi 4x düşürür.
3. Dil uyumsuzluğu: İngilizce eğitilmiş MiniLM modelini Türkçe sorguya uygulamak NDCG kazancını sıfıra indirebilir veya negatife döndürebilir.
4. Negatif sample eksikliği: Fine-tune yapılıyorsa hard negatives (BM25 top-10 ama altın kümede olmayan) zorunludur; sadece random negative ile eğitim zayıf kalır.
5. Cache atlanması: Sık tekrar eden sorgular için (sorgu, top-N) key ile in-memory cache (Redis, 60 dk TTL) toplam çağrıyı %30-50 azaltır.

Bir başka az konuşulan konu, “skor kalibrasyonu”. Cross-encoder ham skorları logit’tir; sigmoid sonrası 0-1 aralığına gelse de eşik (örn. 0.5’in altı atılsın) belirleme tehlikelidir. Tavsiye: eşik yerine top-K (5-10) ile çalış, eşiği yalnızca tüm sonuçlar düşük skorluysa “alaka yok” geri dönüşü için kullan.

Son tuzak; reranker’ın LLM cevabı üzerindeki dolaylı etkisi. Rerank sonucu top-5 hâlâ yanlış dokümanlar içeriyorsa LLM hâlâ halüsinasyon üretebilir. Bu yüzden değerlendirme ve groundedness uygulamaları rerank ile birlikte ele alınmalıdır. Ömer Önal danışmanlık projelerinde bu üçlüyü (retriever + reranker + groundedness değerlendirme) tek bir gözlemlenebilirlik panelinde izleriz.

SSS – Sıkça Sorulan Sorular

Sonuç

2026 itibarıyla rerank katmanı; üretim seviyesindeki RAG sistemleri için seçenek değil temel bir kalite eşiğidir. Bi-encoder geri çağırmanın yapısal sınırını cross-encoder çapraz dikkat tamamlar; NDCG@10 ve MRR metriklerinde 0.06-0.14 bandında somut iyileşme sağlar. Sıralama kalitesindeki bu kazanım, halüsinasyon oranı ve müşteri memnuniyetinde doğrudan yansır.

Cohere Rerank 3.5 hızlı go-live ve çok dilli kalite için, BGE / Jina multilingual cross-encoder’lar yüksek hacim ve veri konum kısıtlı senaryolar için optimal tercihtir. Karar verirken aylık arama hacmi, p95 latency hedefi, dil kapsamı ve compliance konumu sırasıyla değerlendirilmelidir. Performans açısından L4 sınıfı GPU + bge-reranker-v2-m3 + fp16 + dinamik batching + top-N=50 kombinasyonu, çoğu kurumsal iş yükünde sağlam başlangıç noktasıdır.

RAG boru hattınızın retriever, reranker, groundedness değerlendirme ve LLM jenerasyon katmanlarını uçtan uca optimize etmek için iletişim sayfası üzerinden ulaşabilir; mevcut mimarinize özel NDCG/MRR ölçüm ve maliyet modeli çıkarımı için danışmanlık görüşmesi planlayabilirsiniz.