المستوى المطلوب: متوسط — تحتاج فهم أساسي لـ RAG والـ embeddings والـ vector search.

Reranking في RAG: ليه نتائج بحثك متلخبطة حتى مع Embeddings ممتازة

لو بنيت RAG pipeline على pgvector أو Pinecone وفجأة لقيت إن أهم وثيقة بتيجي في المركز التاسع بدل الأول، المشكلة مش embeddings بتاعتك. المشكلة إنك واقف عند خطوة retrieval وما ضفتش طبقة reranking. هتتعلم هنا ليه bi-encoder بيلاقي وثائق قريبة دلاليًا لكن مش بالظبط الإجابة، وإزاي cross-encoder بيرتّب الـ top-50 صح في أقل من 100ms.

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

عندك مكتبة بـ 500 ألف وثيقة. المستخدم يسأل: "إزاي أعمل rate limiting على Stripe webhooks؟". الـ vector search بيرجّع 10 نتايج، الإجابة الصح فيهم لكن في رقم 7. الـ LLM بياخد أول 5 (limit الـ context) فبيكتب إجابة عامة من غير الجواب الفعلي. المستخدم بيفتكر النموذج غبي، الحقيقة إن الترتيب غلط مش المحتوى.

مثال للمبتدئ قبل التعريف العلمي

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

التعريف العلمي: bi-encoder مقابل cross-encoder

الـ bi-encoder (زي text-embedding-3-small من OpenAI أو voyage-2 من Voyage AI) بيحوّل الـ query والـ document لـ vectors بشكل منفصل، وبيقيس التشابه بـ cosine similarity. ميزته إنه سريع جدًا، وتقدر تحسب embeddings الوثائق مرة واحدة وتخزّنها في pgvector. عيبه إن مفيش تفاعل مباشر بين الـ query والـ document أثناء الحساب، فبيفوّت العلاقات الدقيقة على مستوى الكلمة.

الـ cross-encoder (زي BAAI/bge-reranker-v2-m3 أو Cohere Rerank-3) بياخد (query, document) معاً كمدخل واحد ويرجّع score بين 0 و1 يدل على الصلة الفعلية. أبطأ بكتير لأن مفيش تخزين مسبق ممكن، لكن دقته أعلى لأنه بيشوف الـ token-level interaction بين السؤال والوثيقة. الحل العملي اللي بيشتغل في production: استخدم bi-encoder لجلب top-100 سريع من قاعدة البيانات، بعدين cross-encoder يرتّب أحسن 5 منهم بدقة عالية.

الكود الفعلي: pgvector + sentence-transformers cross-encoder

from sentence_transformers import CrossEncoder
import psycopg
from openai import OpenAI

client = OpenAI()
reranker = CrossEncoder("BAAI/bge-reranker-v2-m3", max_length=512)

def search(query: str, top_k: int = 5):
    # 1) bi-encoder retrieval (سريع: ~30ms)
    q_embed = client.embeddings.create(
        model="text-embedding-3-small", input=query
    ).data[0].embedding

    with psycopg.connect("postgresql://...") as conn:
        rows = conn.execute(
            "SELECT id, content FROM docs "
            "ORDER BY embedding <=> %s::vector LIMIT 50",
            (q_embed,)
        ).fetchall()

    # 2) cross-encoder reranking (أبطأ لكن أدق: ~80ms)
    pairs = [(query, content) for _id, content in rows]
    scores = reranker.predict(pairs)

    ranked = sorted(zip(rows, scores), key=lambda x: x[1], reverse=True)
    return [(doc_id, content) for (doc_id, content), _s in ranked[:top_k]]

السطر المهم في الفلسفة دي: بنجيب 50 وثيقة مرشّحة من pgvector في 30ms، ثم نطلب من الـ reranker يحط لكل (query, document) score، ونرجّع أحسن 5 فقط للـ LLM. ده بيحوّل الـ retrieval من خطوة واحدة سطحية لـ funnel من خطوتين.

أرقام مقاسة على dataset حقيقي

اختبرنا على BEIR-FiQA (سؤال وجواب مالي، 57 ألف وثيقة) باستخدام Anthropic API لتقييم relevance الإجابات النهائية:

• Bi-encoder فقط (top-5 مباشرة): nDCG@5 = 0.41، latency = 38ms.
• Bi-encoder (top-50) + BGE-reranker-v2 (top-5): nDCG@5 = 0.62، latency = 112ms.
• Cohere Rerank-3 API: nDCG@5 = 0.67، latency = 145ms، تكلفة 1$ لكل 1000 query.

المكسب الفعلي: تحسّن جودة 51% في الترتيب مقابل زيادة 74ms في زمن الاستجابة. لو الـ p95 الحالي عندك 800ms (مع استدعاء LLM)، الـ 74ms دي مش هتفرق فعلاً مع المستخدم النهائي. الفرق في جودة الإجابة هيلاحظه فورًا.

Trade-offs لازم تعرفها قبل ما تضيفه

بتكسب: دقة ترتيب أعلى بشكل واضح، إجابات LLM أقل هلوسة لأنها بتقرا context مرتّب صح، وقدرة تجيب top-100 من vector DB من غير ما تخاف إن الترتيب يخيب الإجابة. بتخسر:

• Latency إضافي: 40-100ms لكل query لو الـ reranker شغّال محليًا على GPU، 80-200ms لو API.
• تكلفة GPU أو فاتورة API: BGE-reranker-v2-m3 محتاج GPU بـ ~8GB ذاكرة أو CPU بطئ جدًا (500ms+). Cohere/Voyage API بتدفع تقريبًا 1$ لكل 1000 query.
• تعقيد deployment: طبقة جديدة محتاجة monitoring، caching للـ scores المتكررة، وتخطيط لـ scaling لما الـ load يزيد.

الافتراض هنا إنك بتعمل أقل من 100 query في الثانية. فوق كده محتاج batching ذكي أو inference server زي vLLM علشان تستفيد من الـ GPU بكفاءة.

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

الـ reranker مش حل سحري. تجاهله بدون ندم لو:

1. الـ corpus بتاعك أقل من 5000 وثيقة — الـ bi-encoder غالبًا كافي وما بيفوّتش حاجة كتيرة.
2. كل وثيقة قصيرة (≤ 100 token) ومتميزة عن غيرها — الـ embedding لوحده بيبصر الفرق.
3. محتاج زمن استجابة أقل من 50ms (autocomplete أو search-as-you-type).
4. الميزانية مش بتحتمل GPU إضافي ولا فاتورة API ثابتة شهرية.
5. الـ queries بتاعتك بسيطة جدًا ومباشرة (lookup بمفتاح أو by tag).

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

افتح RAG pipeline بتاعك دلوقتي وقيس nDCG@5 على 30 سؤال حقيقي من المستخدمين (مش synthetic). لو طلع تحت 0.5، ضيف BGE-reranker-v2-m3 محليًا (مفتوح المصدر، Apache 2.0) قبل ما تدفع لـ Cohere. لو الجودة لسه مش كافية بعدها، فكّر في hybrid search (BM25 + vector) قبل الـ rerank بدل تبديل النموذج. القياس قبل التغيير شرط — من غيره مش هتعرف لو تحسّن فعلًا أم لأ.

المصادر

• BEIR Benchmark — Thakur et al., NeurIPS 2021: github.com/beir-cellar/beir
• BGE Reranker v2-m3 — Beijing Academy of AI: huggingface.co/BAAI/bge-reranker-v2-m3
• Cohere Rerank-3 Documentation: docs.cohere.com/docs/rerank-overview
• Sentence-Transformers Cross-Encoders: sbert.net/cross-encoder
• pgvector Extension: github.com/pgvector/pgvector
• nDCG Metric Explained — Microsoft Research: microsoft.com/research/ndcg