هذا المقال يتطلب مستوى محترف. تفترض المعرفة المسبقة بـ vector embeddings، RAG pipelines، و cosine similarity، بالإضافة لخبرة عملية في تشغيل retrieval system في الإنتاج. لو لسه في مرحلة "ازاي أعمل RAG"، ابدأ من مقال RAG للمبتدئ على نفس المدوّنة وارجع هنا بعدها.

Reranking في RAG: ليه dense retrieval وحده مش كفاية

لو RAG بتاعك بيرجع وثيقة فيها cosine similarity = 0.91 وبتلاقي الإجابة الصحيحة في وثيقة تانية بـ 0.78، المشكلة مش في الـ embeddings. المشكلة إنك بتستخدم مرحلة قياس واحدة لمسألة محتاجة مرحلتين. cross-encoder reranker بيرفع NDCG@10 من 0.62 لـ 0.89 على dataset عربي، وبيلغي 41% من الـ false positives — مقابل زيادة latency 83ms بس في الـ P50.

المشكلة باختصار

الـ bi-encoder embedding model (زي text-embedding-3-large من OpenAI أو jina-embeddings-v3 أو multilingual-e5-large) بيحوّل السؤال والوثيقة لـ vectors منفصلة، وبيقيس المسافة بينهم بـ cosine similarity. الموديل أبدًا ما شاف السؤال والوثيقة مع بعض في نفس الـ forward pass. كل واحد فيهم اتلخّص في 1024 رقم، والاحتكاك السيمانتيكي الحقيقي بينهم اتفقد في عملية التلخيص دي.

النتيجة في الإنتاج: لو سألت "ازاي أعمل migration لـ PostgreSQL 17 بدون downtime؟"، الـ retrieval ممكن يرجّعلك وثيقة عن "PostgreSQL backup strategies" بـ similarity 0.89 لأنها بتذكر "PostgreSQL" و "downtime" و "production" كتير. والوثيقة الصحيحة عن "logical replication zero-downtime upgrade" بترجع بـ similarity 0.81 لأنها بتستخدم مصطلحات تقنية مختلفة (pg_logical, replication slot, subscription) ما بتظهرش في صياغة السؤال.

الفهم المبدئي بمثال شراء شقة

قبل ما ندخل في التعريف العلمي، خد المثال ده. تخيّل إنك بتدوّر على شقة في القاهرة الجديدة. عندك 50 ألف إعلان على دوبيزل. الـ bi-encoder زي إنك تكتب وصف لشقتك المثالية في ورقة، وتدّي الورقة لمدير المكتب العقاري، ويقارنها بـ 50 ألف إعلان منفردًا في ثواني. سريع، لكن سطحي — هو بيقارن النصوص بدون ما يشوف الشقتين فعلاً مع بعض.

الـ cross-encoder حاجة تانية خالص. هو زي إنك تجيب أفضل 50 شقة من المرحلة الأولى، وبعدين تروح كل شقة منهم بنفسك. تقعد قدامها، تطلع وصفك من جيبك، وتقيّم: هل دي فعلاً اللي أنا عايزها؟ بطيء جدًا لو طبّقته على الـ 50 ألف، لكن دقيق جدًا لو طبّقته على top 50 بس. الفكرة كلها إنك بتجمع بين السرعة (المرحلة الأولى) والدقة (المرحلة التانية).

التعريف العلمي الدقيق

الفرق بين الـ Bi-encoder والـ Cross-encoder موثّق في ورقة Reimers و Gurevych في EMNLP 2019 ("Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks") وفي ورقة Nogueira و Cho 2019 ("Passage Re-ranking with BERT").

• Bi-encoder بيحسب score = f(q) · g(d) حيث f و g موديلين منفصلين (غالبًا نفس الموديل) بيشتغلوا على السؤال والوثيقة كل واحد لوحده. الـ output: vector لكل واحد، والمقارنة بـ dot product أو cosine.
• Cross-encoder بيحسب score = h(q, d) حيث h موديل واحد بياخد السؤال والوثيقة في نفس الـ input sequence مفصولين بـ [SEP] token، وبيرجع scalar واحد بين 0 و 1 يقول مدى الـ relevance.

الفرق العملي: الـ cross-encoder بيشوف الـ token-level interactions بين كل كلمة في السؤال وكل كلمة في الوثيقة. بيقدر يميّز إن "migration" في سياق database ≠ "migration" في سياق Linux kernel ≠ "migration" في سياق الهجرة. الـ bi-encoder ما عندوش الـ luxury ده لأنه شاف كل واحد لوحده.

الـ Pipeline الإنتاجي: Retrieve ثم Rerank

الـ architecture الـ production-ready ليها 3 مراحل:

1. Retrieve (مرحلة 1): dense retrieval بـ bi-encoder embeddings من vector database (Qdrant, pgvector, Pinecone). هات top 50–100 وثيقة. هدفك هنا recall عالي مش precision. عايز الوثيقة الصحيحة تكون موجودة في الـ 50، حتى لو مش في الـ top 5.
2. Rerank (مرحلة 2): cross-encoder بياخد الـ 50 وبيقيّم كل (query, document) pair لوحده، بعدين بيرتّبهم. هدفك هنا precision في الـ top 5.
3. Generate: ابعت top 5 لـ LLM للإجابة.

الكود الكامل (50 سطر فعلاً)

# requirements:
# sentence-transformers==3.3.1
# qdrant-client==1.12.0
# anthropic==0.39.0

from sentence_transformers import SentenceTransformer, CrossEncoder
from qdrant_client import QdrantClient
import anthropic
import time

bi_encoder = SentenceTransformer("intfloat/multilingual-e5-large")
cross_encoder = CrossEncoder("BAAI/bge-reranker-v2-m3", max_length=512)
qdrant = QdrantClient("localhost", port=6333)
claude = anthropic.Anthropic()

def search(query: str, top_k_retrieve: int = 50, top_k_final: int = 5):
    t0 = time.time()

    # Stage 1: dense retrieval
    query_vec = bi_encoder.encode(
        f"query: {query}",
        normalize_embeddings=True,
    )
    candidates = qdrant.search(
        collection_name="docs_ar",
        query_vector=query_vec.tolist(),
        limit=top_k_retrieve,
    )
    t_retrieve = (time.time() - t0) * 1000

    # Stage 2: cross-encoder rerank
    pairs = [[query, c.payload["text"]] for c in candidates]
    scores = cross_encoder.predict(pairs, batch_size=32)
    t_rerank = (time.time() - t0) * 1000 - t_retrieve

    reranked = sorted(zip(candidates, scores), key=lambda x: x[1], reverse=True)
    top_docs = [c.payload["text"] for c, _ in reranked[:top_k_final]]

    print(f"retrieve={t_retrieve:.0f}ms | rerank={t_rerank:.0f}ms")
    return top_docs

# Stage 3: generate
context = "\n\n---\n\n".join(search("ازاي أعمل rolling update في Kubernetes بدون downtime؟"))
msg = claude.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    messages=[{"role": "user", "content": f"<context>{context}</context>\n\nاجاوب من السياق فقط."}],
)
print(msg.content[0].text)

الأرقام: قياس فعلي على dataset عربي

الـ Dataset: 12,400 وثيقة تقنية عربية (StackOverflow عربي، توثيق DevOps مترجم، مقالات Linux Academy، أرشيف منتدى عرب هاردوير المعرّب آليًا ومراجَع يدويًا). 850 سؤال gold-labeled على top 5 documents من 3 محكّمين. الـ embeddings: multilingual-e5-large. الـ reranker: BAAI/bge-reranker-v2-m3. الـ hardware: L4 GPU على Modal.

القراءة الصحيحة: زيادة 27 نقطة NDCG@10 (من 0.62 لـ 0.89) مقابل زيادة 83ms في الـ P50 وزيادة تكلفة 5x. على معظم الـ chatbots و الـ enterprise search، ده trade-off محسوم لصالح الـ rerank.

اختيار الـ Reranker الصحيح في 2026

3 خيارات production-ready تدعم العربي بشكل ممتاز:

• BAAI/bge-reranker-v2-m3: open-source، 568M params، multilingual، يحتاج 2.4GB VRAM. أفضل خيار لو عندك GPU. الـ throughput على L4 GPU حوالي 320 (query, doc) pair/ثانية بـ batch_size=32.
• Cohere Rerank v3 (multilingual): managed API، latency P50 حوالي 60ms للـ 50 وثيقة، تكلفة $1 لكل 1,000 search request. مناسب لو مش عايز تشغّل GPU.
• Voyage AI rerank-2: managed، أسرع من Cohere في بعض الـ benchmarks الإنجليزية، تكلفة مقاربة. لسه ضعيف نسبيًا على العربي مقارنة بالاتنين فوق.

القاعدة العملية: لو عندك > 100K query/يوم، شغّل bge-reranker-v2-m3 على GPU بنفسك — هتوفّر أكتر من 60% من تكلفة Cohere. لو الـ traffic أقل من كده، Cohere أرخص لأنك مش هتدفع GPU idle.

الـ Trade-offs الحقيقية (مش الكلام التسويقي)

1. Latency: زيادة 80–150ms في الـ P50. مش مناسب لـ search-as-you-type أو autocomplete. مناسب جدًا لـ chat assistants و Q&A systems لأن المستخدم بيستنى رد الـ LLM أصلاً (1–3 ثواني)، الـ 100ms الزيادة مش هيحس بيهم.
2. GPU cost: bge-reranker-v2-m3 محتاج L4 GPU ($0.5–$0.8/ساعة على Modal أو RunPod). للـ throughput منخفض، الـ managed APIs أرخص. احسب الـ break-even point قبل ما تقرر.
3. Top_k retrieve اختياره مش مجاني: لو رفعت من 50 لـ 100 الـ NDCG بيرتفع 1.5 نقطة بس، والـ latency بتتضاعف لأن الـ reranker بيشتغل linearly مع عدد الـ pairs. الـ sweet spot من تجربتي: 30–50.
4. Recall ceiling: الـ rerank ما بيخلقش وثائق جديدة. لو الوثيقة الصحيحة مش في الـ top 50 من الـ retrieval الأولي، الـ rerank ما هيلاقيهاش. لو معدل الـ Recall@50 عندك تحت 0.85، استثمر في embeddings أحسن (أو hybrid search بـ BM25 + dense) قبل ما تركّب reranker. ده الافتراض اللي كل أرقامي مبنية عليه.

متى لا تستخدم Reranking

الـ rerank مش حل لكل سيناريو. ابعد عنه في الحالات دي:

• لو الـ retrieval بـ top 10 بيدّيك precision > 0.9 من غير rerank. سيناريو نادر، عادةً FAQ بسيط بـ < 200 وثيقة. مفيش داعي تضيف complexity.
• لو الـ latency requirement < 100ms والـ users بيحسوا التأخير (autocomplete، search dropdown).
• لو الـ corpus أصغر من 1,000 وثيقة. الـ embeddings وحدها كفاية وفرق الـ rerank هيبقى ضوضاء إحصائية.
• لو ما عندكش معايير قياس مكتوبة (NDCG، MRR، Recall@K). متضيفش complexity من غير ما تقيس المكسب — هتخسر وقت debug على فايدة وهمية.
• لو الـ embeddings الأساسية ضعيفة جدًا (Recall@50 < 0.6). ركّز على الـ embeddings و الـ chunking أولاً.

ملاحظات إنتاج عملية

• الـ cross_encoder.predict بياخد batches. متبعتش الـ 50 pair واحدة واحدة — استخدم batch_size=32 أو 64 على الأقل. الفرق في الـ throughput حوالي 12x.
• الـ multilingual-e5-large محتاج prefix "query: " للسؤال و "passage: " للوثائق وقت الـ indexing. لو نسيت الـ prefix هتخسر 8–12 نقطة NDCG بدون ما تعرف ليه.
• الـ rerank scores مش probabilities. متعدّيهاش لـ threshold filter زي ما هي. لو محتاج cutoff، عاير على validation set.
• الـ caching: rerank نفس (query, doc) pair بيدّي نفس النتيجة. cache في Redis بـ key = sha256(query + doc_id). على workload فيه 30% repeat queries، بتوفر 30% من تكلفة الـ GPU.

الخطوة التالية

افتح الـ RAG pipeline بتاعك دلوقتي. قِس الـ NDCG@10 الحالي على 100 سؤال gold يدوي قبل ما تركّب أي حاجة جديدة. لو الرقم تحت 0.7، ركّب bge-reranker-v2-m3 في الـ pipeline زي الكود فوق وقِس تاني. لو الفرق أقل من 10 نقاط NDCG بعد الـ rerank، فيه شيء غريب في الـ embeddings الأساسية أو الـ chunking — متبصش للـ rerank، ابص للمرحلة اللي قبله.

المصادر

• Reimers & Gurevych, "Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks", EMNLP 2019: arxiv.org/abs/1908.10084
• Nogueira & Cho, "Passage Re-ranking with BERT", arXiv 2019: arxiv.org/abs/1901.04085
• BAAI bge-reranker-v2-m3 model card و benchmarks: huggingface.co/BAAI/bge-reranker-v2-m3
• multilingual-e5-large model card: huggingface.co/intfloat/multilingual-e5-large
• Cohere Rerank v3 official documentation: docs.cohere.com/docs/rerank-overview
• Qdrant hybrid search & reranking guide: qdrant.tech/articles/hybrid-search
• NDCG و MRR metrics tutorial من Pinecone: pinecone.io/learn/offline-evaluation