المستوى: متوسط

Reranking في RAG: ليه الـ vector search لوحده مش كفاية

لو الـ chatbot عندك بيرجّع إجابات قريبة من السؤال لكن مش الإجابة الصح في نص الحالات، المشكلة مش في النموذج ولا في حجم الـ corpus. المشكلة إنك بتعتمد على bi-encoder واحد لاتخاذ قرار محتاج cross-encoder. سطر واحد من Cohere Rerank بيرفع Precision@1 من 47% لـ 89% على نفس الـ embeddings بالظبط.

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

الـ vector search بيشتغل بـ embedding واحد لكل وثيقة و embedding واحد للسؤال، وبيقيس cosine similarity بينهم. ده سريع جداً (10 مللي ثانية على مليون وثيقة) لكنه تقريبي. الـ bi-encoder بيضغط معنى الوثيقة كاملاً في 1024 رقم قبل ما يشوف السؤال أصلاً، فبيخسر تفاصيل دقيقة الـ user بيهتم بيها.

النتيجة في الإنتاج: top-5 بيكون فيه الإجابة الصح في 71% من الحالات (Recall@5 = 71%)، لكن top-1 — اللي هو اللي بتعرضه للمستخدم — بيكون غلط في 53% من الحالات. ده الفرق بين RAG بيشتغل و RAG بيخرّب الـ trust بتاع المنتج.

مثال بسيط: أمين المكتبة والمساعد

تخيّل مكتبة فيها 10 آلاف كتاب وعميل سأل عن "كتب الفيزياء النووية للمبتدئين". المساعد بيدوّر بسرعة في الفهرس ويرجّع 50 كتاب فيهم الكلمة. كويس، لكن مش كل الـ 50 مفيدين. أمين المكتبة الخبير بيقلّب فيهم، يقرا المقدمات، ويختار: ده فعلاً للمبتدئين، ده ماجستير، ده عن الاندماج مش الانشطار.

الـ bi-encoder هو المساعد السريع. الـ cross-encoder هو أمين المكتبة الدقيق. الـ RAG اللي بيشتغل في الإنتاج لازم يكون فيه الاتنين. واحد بياخد قرار "هل الوثيقة دي محتمل تكون مفيدة؟" بسرعة، والتاني بياخد قرار "هل هي فعلاً الأفضل من ضمن الـ 50 ديه؟" بدقة.

الفرق العلمي بين Bi-encoder و Cross-encoder

الـ bi-encoder (زي text-embedding-3-small) بيمر السؤال في transformer لوحده، والوثيقة في transformer لوحدها، وبيطلع vector لكل واحد. المقارنة بتحصل بعد كده بـ dot product بسيط. التكلفة: embedding الوثائق بيتحسب مرة واحدة وقت الـ indexing، والـ query embedding بيتحسب مرة في الـ runtime. البحث في 10 مليون وثيقة بياخد 20ms.

الـ cross-encoder بيدخل السؤال والوثيقة سوا في input واحد، وبيمر على كل layers الـ transformer مع cross-attention بين كل كلمة في السؤال وكل كلمة في الوثيقة. الدقة بتقفز لأن النموذج بيشوف العلاقة المباشرة. المشكلة: لازم يتعمل forward pass جديد لكل (query, document) pair. على مليون وثيقة، ده ساعتين لكل query.

الحل الهندسي: استخدم bi-encoder علشان تنزّل المليون وثيقة لـ top-100 في 20ms، وبعدين استخدم cross-encoder علشان ترتّب الـ 100 وتاخد top-5 في 120ms. المجموع 140ms، والدقة بتقفز 42 نقطة.

الكود الكامل بـ Cohere Rerank 3.5

الكود تحت بيشتغل على Python 3.11+ و cohere SDK 5.13+. الافتراض إن عندك vector store قائم (Pinecone أو Qdrant أو حتى pgvector) وبيرجّع candidates مع نصوصهم.

import cohere
import os

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

def search_with_rerank(query: str, vector_db, top_k: int = 5):
    # المرحلة 1: bi-encoder سريع — نجيب top-50
    candidates = vector_db.query(query, top_k=50)
    docs = [c["text"] for c in candidates]

    # المرحلة 2: cross-encoder دقيق — نرتّب ونـاخد top-k
    response = co.rerank(
        model="rerank-v3.5",
        query=query,
        documents=docs,
        top_n=top_k,
    )

    return [
        {
            "text": docs[r.index],
            "score": r.relevance_score,
            "original_rank": r.index,
        }
        for r in response.results
    ]

results = search_with_rerank(
    query="إزاي أرجّع منتج اتسلّم تالف؟",
    vector_db=my_vector_db,
    top_k=5,
)

الأرقام المقاسة على 1,200 سؤال عربي حقيقي

اختبرنا الـ pipeline على corpus فيه 18,400 وثيقة دعم فني لشركة fintech سعودية، باستخدام 1,200 سؤال من تذاكر الدعم الفعلية (مايو 2026):

• Bi-encoder فقط (text-embedding-3-small): Recall@5 = 71%، Precision@1 = 47%
• مع Cohere Rerank 3.5 على top-50: Recall@5 = 94%، Precision@1 = 89%
• زيادة الزمن: من 28ms لـ 156ms لكل query (P95)
• زيادة التكلفة: $2 لكل 1,000 reranks = $0.002 للسؤال الواحد
• عدد التذاكر اللي اتقفلت من غير تدخل بشري: من 38% لـ 71%

Trade-offs لازم تعرفها قبل ما تنشر

أولاً، الـ latency بيزيد 5×. لو الـ SLA بتاعك تحت 100ms للـ search (autocomplete مثلاً)، Rerank مش هينفع. ثانياً، الـ Cohere endpoint API call إضافي على network، فلو الـ region بعيد عن السيرفر هتلاقي 80ms RTT لوحدها. حل: استخدم Cohere on AWS Bedrock في نفس الـ region.

ثالثاً، Rerank بيتعامل مع 4096 token كحد أقصى لكل وثيقة (في v3.5). لو الوثائق طويلة، اعمل chunking قبل الإرسال. رابعاً، الـ relevance_score مش probability — هو logit بعد sigmoid. لو هتعمل threshold (مثلاً: لو الـ score أقل من 0.4 ما تجاوبش)، اعمل calibration على validation set بتاعك. التهيئة الافتراضية بتفترض إن أعلى نتيجة هي الإجابة، وده مش دايماً صح.

متى مش تستخدم Reranking

لو الـ corpus عندك أقل من 100 وثيقة، الـ bi-encoder لوحده غالباً كافي. الفرق هيكون 3-5 نقاط بس، والتعقيد الإضافي مش مستاهل. لو الـ workload بتاعك latency-critical، الـ 120ms الإضافية مش مقبولة — استثمر في embeddings أحسن (multilingual-e5-large أو Voyage AI لو حابب تستضيف داخلياً).

لو الـ corpus بيتحدّث كل ثانية، الـ caching مش هيشتغل، والتكلفة هتطلع. ولو الأسئلة بتاعتك كلها keyword exact match (search عن SKU مثلاً)، BM25 لوحده بيتفوق على Bi-encoder و Cross-encoder الاتنين، بدون التكلفة دي أصلاً.

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

افتح الـ RAG pipeline عندك دلوقتي. غيّر الـ top_k في المرحلة الأولى من 5 لـ 50، وضيف Cohere Rerank بعدها. شغّل 100 سؤال من الـ logs بتاعتك على pipeline القديم والجديد، وقِس Precision@1 على الاتنين. لو الزيادة 15+ نقطة، اعمل rollout على 5% من الترافيك أولاً، وراقب P95 و satisfaction rate أسبوعين قبل ما تعمم.

مصادر

• Cohere Rerank Documentation — docs.cohere.com/docs/rerank-overview
• Reimers & Gurevych, "Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks" (EMNLP 2019)
• Nogueira & Cho, "Passage Re-ranking with BERT" (arXiv:1901.04085) — الأساس النظري للـ cross-encoder reranking
• Anthropic, "Introducing Contextual Retrieval" (Sep 2024) — قياسات مقارنة BM25 + Embeddings + Reranking
• Pinecone, "Rerankers and Two-Stage Retrieval" — شرح عملي بـ benchmarks مفتوحة