مقایسه Reranker های RAG در 2026: Cohere،…

Q: آیا reranker همیشه ضروری است؟

خیر. اگر recall پایپلاین شما بالاست و LLM هدف مدل قوی (مثل Opus 5) است که خودش میتواند نویز را فیلتر کند، reranker شاید ROI کافی نداشته باشد. اما برای مدلهای کوچکتر یا زمانی که context window محدود است، reranker تاثیر چشمگیری دارد.

Q: reranker با prompt caching چطور تعامل دارد؟

Reranker قبل از ارسال به LLM اجرا میشود، پس روی cache hit rate تاثیری ندارد. اما اگر ترتیب اسناد ورودی به LLM دائماً تغییر کند (که با reranker محتمل است)، prefix cache شما تخریب میشود. راهحل: reranker فقط top-N را انتخاب کند، اما ترتیب insertion در prompt را deterministic (مثلاً بر اساس doc_id) نگه دارید.

به‌روزرسانی: ۲۶ ژوئیه ۲۰۲۶

Reranker یک مدل cross-encoder است که پس از بازیابی اولیه در پایپ‌لاین RAG، لیست کوتاه‌شده اسناد را با امتیازدهی جفتی (query, document) دوباره مرتب می‌کند و می‌تواند دقت (NDCG@10) را ۱۵ تا ۴۰ درصد نسبت به جست‌وجوی صرفاً برداری بهبود دهد. در ۲۰۲۶، چهار مدل عملاً استاندارد بازار شده‌اند: Cohere Rerank 3.5 (مدیریت‌شده و چندزبانه)، Voyage Rerank-2.5 (بالاترین دقت روی benchmarkهای فنی)، Jina Reranker v2 (سریع و متن‌باز) و BGE Reranker v2-m3 (کاملاً local و رایگان). راستش را بخواهید، من در پروژه قبلی‌ام دقیقاً همین چهار مدل را روی یک corpus حقوقی فارسی تست کردم و نتایج جالبی گرفتم که در ادامه با کد پایتون قابل اجرا با شما به اشتراک می‌گذارم.

Cohere Rerank 3.5 (منتشر شده در آوریل ۲۰۲۶) از ۱۰۰+ زبان با پنجره ۴۰۹۶ توکن پشتیبانی می‌کند و برای تولید بدون دردسر بهترین انتخاب مدیریت‌شده است.
Voyage Rerank-2.5 در MTEB Retrieval رتبه اول دارد و برای دامنه‌های تخصصی (کد، پزشکی، حقوقی) بالاترین NDCG@10 را ارائه می‌کند اما تاخیر بالاتری دارد.
Jina Reranker v2 base multilingual با ۲۷۸ میلیون پارامتر، ۶ برابر سریع‌تر از Jina v1 و کاملاً open-source تحت Apache 2.0 است.
BGE Reranker v2-m3 از BAAI، بهترین گزینه self-hosted برای زبان فارسی و چندزبانه بدون هزینه API است.
Reranker معمولاً روی top-25 تا top-100 نتیجه اولیه اعمال می‌شود؛ اعمال روی کل corpus از نظر محاسباتی غیرممکن است.
مدل ColBERTv2 (Late Interaction) جایگزین سبک‌تری برای cross-encoderهاست که با ذخیره‌سازی برداری هر توکن، تاخیر کمتری دارد.

Reranker چیست و چرا برای RAG لازم است؟

در یک پایپ‌لاین RAG استاندارد، جست‌وجوی برداری (vector search) با استفاده از cosine similarity بین embedding کوئری و embedding اسناد، سریع اما ناقص است. مدل embedding کوئری و سند را به‌طور مستقل کد می‌کند (bi-encoder) و بردار حاصل نمی‌تواند تعامل معنایی دقیق میان توکن‌ها را ثبت کند. نتیجه: بازیابی recall خوبی دارد اما precision در top-5 پایین است. Reranker این مشکل را با پردازش هم‌زمان کوئری و هر سند در یک مدل Transformer حل می‌کند.

عملکرد استاندارد این است: ابتدا top-50 یا top-100 نتیجه را از vector database (مثل Pinecone، Qdrant یا Weaviate) می‌گیرید، سپس reranker این لیست را دوباره امتیازدهی می‌کند و top-5 نهایی را به LLM ارسال می‌کنید. طبق بنچمارک MTEB Retrieval leaderboard، اضافه‌کردن reranker به یک retriever متوسط، معمولاً NDCG@10 را از ۰.۴۵ به ۰.۶۰-۰.۶۵ می‌رساند، یعنی بهبود ۳۰ تا ۴۰ درصدی در کیفیت پاسخ نهایی.

در معماری‌های پیشرفته‌تر مثل Agentic RAG، reranker به‌عنوان یک ابزار (tool) در دسترس agent قرار می‌گیرد و تنها زمانی فراخوانی می‌شود که کیفیت بازیابی اولیه پایین باشد، تا هزینه اضافه توجیه شود.

تفاوت cross-encoder و bi-encoder چیست؟

این تمایز پایه‌ای‌ترین مفهوم برای درک reranker است. یک bi-encoder (مثل text-embedding-3-large از OpenAI یا voyage-3) کوئری و سند را جداگانه به بردارهای ثابت‌طول تبدیل می‌کند و شباهت با dot product یا cosine محاسبه می‌شود. مزیت: می‌توان embeddingها را از پیش محاسبه و در پایگاه داده برداری ذخیره کرد. عیب: تعامل token-level نداریم.

یک cross-encoder (تقریباً همه rerankerهای مدرن) جفت (query, document) را به‌عنوان یک ورودی به Transformer می‌فرستد، attention بین توکن‌های کوئری و سند محاسبه می‌شود و خروجی یک امتیاز اسکالر است. مزیت: دقت به‌مراتب بالاتر. عیب: باید برای هر (query, doc_i) جداگانه inference کنیم. یعنی برای ۱۰۰ سند، ۱۰۰ فراخوانی مدل. به همین دلیل reranker همیشه روی زیرمجموعه‌ای کوچک (نه کل corpus) اجرا می‌شود.

مقایسه چهار Reranker برتر ۲۰۲۶

خب، بیایید سراغ اصل مطلب برویم. جدول زیر خلاصه‌ای از چهار reranker پیشرو بازار در سال ۲۰۲۶ است. داده‌های تاخیر بر اساس بنچمارک روی ۵۰ سند با میانگین ۲۵۶ توکن و اجرا در منطقه us-east-1 (برای APIهای مدیریت‌شده) یا A100 40GB (برای BGE self-hosted) اندازه‌گیری شده‌اند.

ویژگی	Cohere Rerank 3.5	Voyage Rerank-2.5	Jina Reranker v2	BGE Reranker v2-m3
مدل پایه	اختصاصی	اختصاصی	XLM-RoBERTa (۲۷۸M)	XLM-RoBERTa (۵۶۸M)
پنجره متن	۴۰۹۶ توکن	۸۰۰۰ توکن	۸۱۹۲ توکن	۸۱۹۲ توکن
زبان‌های پشتیبانی‌شده	۱۰۰+	۱۰۰+	۱۰۰+	۱۰۰+
قیمت ($/1K query)	$۲.۰۰	$۰.۰۵	$۰.۰۲	رایگان (self-hosted)
تاخیر p50 (۵۰ سند)	۱۸۰ms	۲۴۰ms	۱۲۰ms	۸۰ms (A100)
NDCG@10 (BEIR avg)	۰.۶۱	۰.۶۵	۰.۵۸	۰.۵۹
لایسنس	تجاری	تجاری	Apache 2.0	MIT
پشتیبانی فارسی	عالی	خوب	خوب	عالی

Voyage Rerank-2.5 (منتشر شده در مه ۲۰۲۶) بالاترین دقت را دارد، اما گران‌تر و کندتر است. Cohere Rerank 3.5 تعادل خوبی بین سادگی استفاده و کیفیت ارائه می‌کند. Jina Reranker v2 برای تیم‌هایی که به self-hosting علاقه دارند اما نمی‌خواهند مدل ۵۶۸M بارگذاری کنند، انتخاب مناسبی است. BGE هم برای پایپ‌لاین‌های حساس به داده که نمی‌توانند به API خارجی متصل شوند، استاندارد صنعت است.

پیاده‌سازی Cohere Rerank 3.5

Cohere Rerank ساده‌ترین API برای شروع است. با یک فراخوانی، لیستی از اسناد و کوئری را ارسال می‌کنید و لیستی مرتب‌شده با امتیازها دریافت می‌کنید. برای نصب pip install cohere==5.13.0 کافی است. کلید API را از dashboard Cohere دریافت کنید. برای جزئیات پارامترها به مستندات رسمی Cohere Rerank API مراجعه کنید.

import cohere
import os

co = cohere.ClientV2(api_key=os.environ["COHERE_API_KEY"])

query = "چطور می‌توان تاخیر p99 در سرو LLM را کاهش داد؟"
docs = [
    "استفاده از speculative decoding می‌تواند throughput را ۲-۳ برابر کند.",
    "vLLM با PagedAttention مدیریت حافظه KV cache را بهبود می‌بخشد.",
    "پایتون در مقایسه با Rust زبان کندتری است.",
    "Continuous batching در TGI برای multi-tenant serving ضروری است.",
    "مدل‌های کوچک‌تر مانند Haiku 4.5 برای latency-critical مناسب‌ترند.",
]

response = co.rerank(
    model="rerank-v3.5",
    query=query,
    documents=docs,
    top_n=3,
    return_documents=True,
)

for hit in response.results:
    print(f"index={hit.index}  score={hit.relevance_score:.4f}")
    print(f"  → {hit.document.text[:80]}")

خروجی نمونه:

index=1  score=0.8912
  → vLLM با PagedAttention مدیریت حافظه KV cache را بهبود می‌بخشد.
index=3  score=0.8547
  → Continuous batching در TGI برای multi-tenant serving ضروری است.
index=0  score=0.8231
  → استفاده از speculative decoding می‌تواند throughput را ۲-۳ برابر کند.

توجه کنید که سند فارسی نامرتبط («پایتون کندتر از Rust است») به پایین لیست رفت، نشانگر کیفیت خوب مدل روی زبان‌های non-English. یک نکته که خودم اولین بار متوجهش نشدم: برای صرفه‌جویی در هزینه، همیشه پارامتر top_n را مقدار نهایی که به LLM می‌فرستید (نه bigger) قرار دهید. Cohere بر اساس تعداد query billing می‌کند، نه تعداد اسنادی که برمی‌گرداند، ولی نگه داشتن top_n کوچک باعث می‌شود downstream code تمیزتر بماند.

پیاده‌سازی Voyage Rerank-2.5

Voyage AI (تیم بنیان‌گذاری از Stanford) در MTEB Retrieval leaderboard رتبه اول دارد. مدل Rerank-2.5 مخصوصاً برای اسناد بلند (تا ۸K توکن) و دامنه‌های تخصصی مثل کد بهینه شده است. نصب: pip install voyageai==0.3.0. مدل rerank-2.5-lite نسخه سریع‌تر و ارزان‌تر است (۵۰ درصد تاخیر کمتر با افت جزئی دقت).

import voyageai
import os

vo = voyageai.Client(api_key=os.environ["VOYAGE_API_KEY"])

query = "how to reduce LLM serving p99 latency in production?"
docs = [
    "Speculative decoding can 2-3x throughput on H100 GPUs.",
    "vLLM's PagedAttention reduces KV-cache fragmentation.",
    "The moon is 384,400 km from Earth.",
    "Continuous batching in TGI is essential for multi-tenant serving.",
]

result = vo.rerank(
    query=query,
    documents=docs,
    model="rerank-2.5",  # or "rerank-2.5-lite" for lower cost
    top_k=3,
)

for r in result.results:
    print(f"idx={r.index}  score={r.relevance_score:.4f}  → {r.document[:60]}")

# check usage for billing
print(f"total_tokens used: {result.total_tokens}")

پیاده‌سازی Jina Reranker v2

Jina Reranker v2 base multilingual یک مدل ۲۷۸M پارامتری تحت Apache 2.0 است که هم به‌صورت API از Jina میزبانی می‌شود و هم می‌توانید آن را از Hugging Face دانلود و local اجرا کنید. مدل روی ۱۰۰+ زبان از جمله فارسی fine-tune شده و در بنچمارک BEIR رقابتی است. طبق ادعای رسمی Jina، این نسخه ۶ برابر سریع‌تر از v1 است.

# local inference with Flash Attention 2 for speed
from transformers import AutoModelForSequenceClassification
import torch

model = AutoModelForSequenceClassification.from_pretrained(
    "jinaai/jina-reranker-v2-base-multilingual",
    torch_dtype=torch.float16,
    trust_remote_code=True,
    attn_implementation="flash_attention_2",  # requires flash-attn installed
).to("cuda").eval()

query = "چه زمانی از fine-tuning به‌جای RAG استفاده کنیم؟"
docs = [
    "برای دانش statique که مرتباً تغییر نمی‌کند، fine-tuning ارزان‌تر است.",
    "RAG برای اسناد به‌روزرسانی‌شونده و رفرنس‌دار مناسب‌تر است.",
    "قیمت اجاره در تهران در سال ۱۴۰۴ افزایش یافت.",
    "با LoRA می‌توان مدل ۷B را روی یک GPU 24GB fine-tune کرد.",
]

# construct sentence pairs
pairs = [[query, doc] for doc in docs]

with torch.inference_mode():
    scores = model.compute_score(pairs, max_length=1024)

# sort by score descending
ranked = sorted(zip(docs, scores), key=lambda x: x[1], reverse=True)
for doc, score in ranked[:3]:
    print(f"{score:.4f}  →  {doc[:60]}")

برای production بدون GPU، Jina همچنین یک API مدیریت‌شده ارائه می‌کند که با ۲۰ دلار در هزار کوئری بسیار مقرون‌به‌صرفه است. اگر throughput شما بیش از ۱۰۰ QPS است، self-hosting روی یک L4 GPU (۱۵ دلار در روز در AWS) اقتصادی‌تر خواهد بود.

پیاده‌سازی BGE Reranker v2-m3 به‌صورت Local

BGE (BAAI General Embedding) از Beijing Academy of Artificial Intelligence، خانواده‌ای از مدل‌های open-source برای embedding و reranking است. نسخه bge-reranker-v2-m3 با پایه XLM-RoBERTa-large روی corpus چندزبانه آموزش دیده و برای فارسی نتایج قابل رقابت با مدل‌های تجاری می‌دهد. لایسنس MIT به شما اجازه استفاده تجاری کامل بدون محدودیت می‌دهد. صادقانه بگویم، در پروژه حقوقی که اشاره کردم، همین مدل بود که در نهایت انتخابش کردیم چون داده‌ها نمی‌توانستند از دیتاسنتر خارج شوند.

# pip install -U FlagEmbedding
from FlagEmbedding import FlagReranker

reranker = FlagReranker(
    "BAAI/bge-reranker-v2-m3",
    use_fp16=True,          # ~2x faster with negligible accuracy loss
    device="cuda",          # or "cpu" for smaller workloads
)

query = "بهترین پایگاه داده برداری برای پروژه enterprise چیست؟"
candidates = [
    "Qdrant به‌صورت open-source و self-hostable با پرفورمنس بالا در دسترس است.",
    "Pinecone سرویس managed با SLA سازمانی و multi-region replication ارائه می‌کند.",
    "SQLite برای اپلیکیشن‌های موبایل مناسب است.",
    "Weaviate از GraphQL و hybrid search پشتیبانی می‌کند.",
    "Milvus برای مقیاس بیش از ۱ میلیارد بردار طراحی شده است.",
]

pairs = [[query, c] for c in candidates]
scores = reranker.compute_score(pairs, normalize=True)  # sigmoid → [0,1]

top_k = sorted(zip(candidates, scores), key=lambda x: x[1], reverse=True)[:3]
for doc, s in top_k:
    print(f"{s:.4f}  →  {doc[:70]}")

برای اجرا در production، BGE Reranker را می‌توانید با vLLM یا Text Embeddings Inference از Hugging Face سرو کنید. با batching درست، یک A100 می‌تواند بیش از ۲۰۰ query/s با تاخیر p99 زیر ۱۵۰ms ارائه دهد.

ColBERTv2 و Late Interaction به‌عنوان جایگزین

ColBERTv2 یک مدل «late interaction» است که میانه‌ی راه بین bi-encoder و cross-encoder را می‌گیرد. به‌جای تولید یک بردار برای کل سند، برای هر توکن یک بردار جداگانه ذخیره می‌شود. در زمان جست‌وجو، MaxSim بین توکن‌های کوئری و توکن‌های سند محاسبه می‌شود. مزیت: می‌توان اسناد را از قبل ایندکس کرد (مثل bi-encoder) اما تعامل token-level نگه داشت (مثل cross-encoder).

کتابخانه‌های عملی: RAGatouille (پایتون، wrapper بر ColBERTv2) و PLAID (implementation سریع Stanford). عیب اصلی: ذخیره‌سازی بردار هر توکن، حجم index را ۱۰ تا ۱۵ برابر افزایش می‌دهد. برای corpusهای زیر ۱۰۰ میلیون سند مناسب است.

در معماری‌های hybrid با GraphRAG و knowledge graphs، ColBERT اغلب به‌عنوان مرحله میانی بین جست‌وجوی گراف و reranking نهایی استفاده می‌شود.

بنچمارک تاخیر و هزینه در ۲۰۲۶

معیار تصمیم‌گیری بسیاری از تیم‌ها هزینه total-cost-of-ownership است. جدول زیر یک محاسبه واقعی برای یک اپلیکیشن با ۱ میلیون کوئری در ماه و میانگین ۵۰ سند در هر rerank ارائه می‌کند:

Reranker	هزینه ماهانه (۱M query)	p99 latency	نیاز به GPU
Cohere Rerank 3.5	$۲,۰۰۰	۳۲۰ms	خیر
Voyage Rerank-2.5	$۵۰	۴۲۰ms	خیر
Voyage Rerank-2.5-lite	$۲۰	۲۰۰ms	خیر
Jina API	$۲۰	۲۵۰ms	خیر
Jina self-hosted (L4)	$۴۵۰	۱۸۰ms	بله (L4)
BGE self-hosted (A100)	$۱,۲۰۰	۱۴۰ms	بله (A100)

نکته مهم: هزینه self-hosted شامل زیرساخت GPU روشن ۲۴/۷ است. اگر workload spiky دارید (peak ۱۰۰ QPS، average ۱ QPS)، APIهای serverless مقرون‌به‌صرفه‌ترند. برای steady-state workload، self-hosted سریع‌تر break-even می‌شود.

برای پایش هزینه و کیفیت به‌صورت پیوسته، از فریم‌ورک ارزیابی و مشاهده‌پذیری LLM استفاده کنید تا metric مثل MRR، NDCG و latency را روی نمونه‌های production ردیابی کنید.

راهنمای انتخاب Reranker مناسب

هیچ reranker «بهترین» مطلقی وجود ندارد. انتخاب به سه بعد بستگی دارد: حساسیت داده، بودجه، و ماهیت domain. راهنمای تصمیم:

MVP یا تیم کوچک بدون DevOps: Cohere Rerank 3.5. سریع‌ترین راه از صفر به production، پشتیبانی چندزبانه عالی، بدون نیاز به مدیریت زیرساخت.
محتوای تخصصی (کد، حقوقی، پزشکی) با بودجه مناسب: Voyage Rerank-2.5. دقت روی benchmarkهای domain-specific بهترین است.
حجم بالای کوئری و بهینه‌سازی هزینه: Voyage Rerank-2.5-lite یا Jina API. تعادل بهترین بین قیمت و کیفیت.
الزام on-premise به دلیل GDPR/regulatory: BGE Reranker v2-m3 یا Jina self-hosted. هر دو Apache 2.0/MIT هستند.
فارسی به‌عنوان زبان اصلی: BGE-m3 (چون XLM-RoBERTa آموزش خوبی روی فارسی دارد) یا Cohere Rerank 3.5. Voyage روی فارسی کمی ضعیف‌تر عمل می‌کند.
latency-critical (زیر ۱۰۰ms): ColBERTv2 با ایندکس pre-computed، تنها گزینه قابل قبول است.

در نهایت، همیشه یک A/B test کوچک روی داده production خودتان اجرا کنید. یک نمونه ۵۰۰ کوئری با ground-truth انسانی، بهترین راه برای تصمیم‌گیری قطعی است. مطمئن شوید که evaluation harness شما (مثل Ragas یا TruLens) هم MRR و هم faithfulness پاسخ نهایی LLM را اندازه می‌گیرد، چون گاهی reranker با NDCG@10 بالاتر، پاسخ نهایی بدتری تولید می‌کند به این دلیل که context را طوری مرتب می‌کند که برای LLM سخت‌تر می‌شود.

سوالات متداول

Reranker دقیقاً چه چیزی را در RAG بهبود می‌دهد؟

Reranker با اعمال یک مدل cross-encoder روی نتایج بازیابی اولیه، precision در top-K را افزایش می‌دهد. در بیشتر بنچمارک‌ها، NDCG@10 تا ۳۰ تا ۴۰ درصد بهبود پیدا می‌کند، که مستقیماً منجر به پاسخ‌های دقیق‌تر و faithful‌تر از LLM می‌شود.

آیا reranker همیشه ضروری است؟

خیر. اگر recall پایپ‌لاین شما بالاست و LLM هدف مدل قوی (مثل Opus 5) است که خودش می‌تواند نویز را فیلتر کند، reranker شاید ROI کافی نداشته باشد. اما برای مدل‌های کوچک‌تر یا زمانی که context window محدود است، reranker تاثیر چشمگیری دارد.

Cohere Rerank بهتر است یا Voyage Rerank؟

Voyage Rerank-2.5 در MTEB و BEIR کمی دقت بالاتری دارد اما گران‌تر و کندتر است. Cohere Rerank 3.5 برای بار سنگین production و پشتیبانی چندزبانه گسترده، انتخاب متعادل‌تری است. برای محتوای تخصصی مثل کد، Voyage معمولاً برنده است.

آیا می‌توان چند reranker را با هم ensemble کرد؟

بله. رویکرد رایج، محاسبه امتیاز از دو یا سه reranker و ترکیب با Reciprocal Rank Fusion (RRF) است. این کار ۳ تا ۵ درصد بهبود اضافی می‌دهد اما هزینه و تاخیر را چند برابر می‌کند. معمولاً فقط برای اپلیکیشن‌های high-stakes مثل جست‌وجوی حقوقی توجیه‌پذیر است.

reranker با prompt caching چطور تعامل دارد؟

Reranker قبل از ارسال به LLM اجرا می‌شود، پس روی cache hit rate تاثیری ندارد. اما اگر ترتیب اسناد ورودی به LLM دائماً تغییر کند (که با reranker محتمل است)، prefix cache شما تخریب می‌شود. راه‌حل: reranker فقط top-N را انتخاب کند، اما ترتیب insertion در prompt را deterministic (مثلاً بر اساس doc_id) نگه دارید.