اختيار موديل Embeddings للاسترجاع العربي-الإنجليزي من القرارات التي تبدو سهلة على الورق وتصبح مكلفة جدًا في الإنتاج.

صور الـ leaderboards تجعل القرار نظيفًا وبسيطًا. الأنظمة الحقيقية لا تعمل بهذا الترف.

إذا كانت بنيتك ستخدم البحث الثنائي، وترتيب المحتوى المرتبط، واكتشاف الأرشيف، واستعلامات مختلطة اللغة، فالسؤال الحقيقي ليس: “أي موديل يبدو أقوى في جدول benchmark؟” بل: “ما أول شيء سيتكسر عندما يلمس هذا الموديل كوربسنا وحدود السرعة وسير العمل التحريري؟”

ثلاث إشارات موديلات تستحق الفهم الآن

السطح الحالي على Hugging Face مفيد لأن هذه الموديلات لا تحاول حل المشكلة بالطريقة نفسها.

  • BAAI/bge-m3 يقدّم نفسه كموديل استرجاع متعدد الوظائف: dense وsparse وmulti-vector معًا، مع دعم أكثر من 100 لغة وإدخال يصل إلى 8192 token.
  • google/embeddinggemma-300m يذهب في اتجاه مختلف: موديل بحجم 300M موجه للبحث والاسترجاع عبر 100+ لغة منطوقة مع قصة واضحة حول الكلفة المنخفضة والنشر الأقرب للأجهزة.
  • perplexity-ai/pplx-embed-v1-0.6b يراهن على retrieval بحجم web-scale وسياق 32K وسير لا يحتاج إلى instruction prefixes تُربك فضاء الـ embeddings مع الوقت.

وهذا الفرق مهم. موديل قد يسمح لك بدمج dense وsparse في طبقة أقرب، وآخر قد يكون أسهل في النشر، وثالث قد يتعامل مع chunks أطول بمرونة أعلى. هذه رهانات تشغيلية مختلفة، لا أسماء مختلفة فقط.

الإشارة البحثية تقول إن التقييم يجب أن يكون متعدد اللغات ومرتبطًا بالمهمة

هناك إشارتان بحثيتان مفيدتان جدًا هنا.

  • MINERS تقول إن الاسترجاع الدلالي متعدد اللغات يجب أن يُختبر عبر نطاق لغوي واسع فعلًا، بما في ذلك اللغات الأقل موردًا والسيناريوهات العابرة للغات.
  • Arctic-Embed 2.0 تضيف درسًا آخر: الكفاءة متعددة اللغات لا تكفي إذا انهارت جودة الإنجليزية، كما أن الكفاءة التخزينية تصبح مهمة لحظة دخول الـ embeddings إلى الإنتاج.

والدرس المشترك بينهما مزعج لمن يريد رقمًا سحريًا واحدًا: موديل الاسترجاع الجيد لمنصة ثنائية اللغة يجب أن ينجح في وظائف متوازية:

  • جودة الاسترجاع بالإنجليزية
  • جودة الاسترجاع بالعربية
  • الاستدعاء العابر للغات
  • الكفاءة التخزينية أو الفهرسية
  • الملاءمة التشغيلية مع reranking والـ lexical fallback

ولهذا تقودنا الحماسة الزائدة لbenchmark عام إلى قرارات نشر سيئة أكثر مما نتخيل.

ما الذي يجب أن أختبره قبل اختيار أي طبقة؟

في الاسترجاع التحريري العربي-الإنجليزي، لن أثق بأي قرار قبل اختبار خمسة مستويات على الأقل:

  1. الاستدعاء العابر للغات
  2. سلوك الاستعلامات المختلطة
  3. أداء chunks الطويلة
  4. جودة الـ lexical fallback
  5. تعقيد التشغيل على الفريق

الاستدعاء العابر للغات هو الأوضح. هل يستطيع استعلام عربي استرجاع أفضل دليل إنجليزي؟ وهل يستطيع استعلام إنجليزي كشف المادة العربية الصحيحة؟

سلوك الاستعلامات المختلطة هو العطب التالي غالبًا. كثير من الاستعلامات الحقيقية ليست عربية خالصة ولا إنجليزية خالصة، بل تحمل أسماء منتجات وواجهات APIs وأرقام إصدارات واختصارات تعيش بين اللغتين.

وسلوك المستندات الطويلة مهم لأن طبقات الاسترجاع لا تعمل على فقرات عرض مثالية، بل على أرشيفات وشروح ومواد غير متساوية الكثافة.

أما الـ lexical fallback فضروري لأن التشابه الدلالي وحده لن ينقذك عندما يبحث المستخدم عن error string محدد، أو package name، أو CVE، أو model ID.

أما تعقيد التشغيل فهو القاتل الصامت. إذا كان الموديل يحتاج إلى prompt prefixes هشة، أو normalization مربك، أو تخزين أصعب من الفائدة التي يحققها، فبنيتك ستتدهور مع الزمن حتى لو بدا benchmark الأول جميلًا.

الفروق العملية أهم من العنوان الكبير

BGE-M3 جذاب عندما تريد hybrid retrieval وتحكمًا موحدًا في dense وsparse معًا. بطاقته نفسها تدفعك نحو hybrid retrieval وreranking، وهذا بالضبط النوع من النص الإنتاجي الذي أثق به أكثر من الوعود اللامعة.

EmbeddingGemma جذاب عندما تكون footprint والنشر المرن أهم من السعي وراء الحجم الأكبر. موديل 300M يدعم أكثر من 100 لغة يغيّر النقاش فعلًا للفرق الأصغر أو البيئات الحساسة للكلفة.

pplx-embed-v1-0.6b جذاب عندما يهمك السياق الأطول وبساطة الفهرسة. غياب instruction-prefix maintenance ليس تفصيلًا شكليًا، بل عامل يقلل هشاشة خطوط الفهرسة الحقيقية.

كل هذا لا يخبرك من الرابح النهائي. بل يخبرك أي نوع من المشكلات صُمّم كل موديل ليحله.

ماذا سأشحن أولًا في الواقع؟

سأبدأ بطبقة متحفظة عمدًا:

مقتطف شيفرة

ts 

    export async function retrieve(query: string) {
  const lexical = await runBm25(query);
  const dense = await runEmbeddings(query, { model: "BAAI/bge-m3" });
  const merged = mergeSignals(lexical, dense);
  return rerank(merged);
}

لماذا أبدأ بهذا؟ لأن hybrid retrieval يمنحك مساحة تنفّس بينما تتعلم أين يكون كوربسك الثنائي قويًا وأين يكون هشًا.

بعد ظهور traces الحقيقية تستطيع أن تسأل الأسئلة الأصعب:

  • هل أحتاج footprint أصغر؟
  • هل أحتاج سياقًا أطول؟
  • هل أحتاج تخزينًا أكثر كفاءة؟
  • هل أحتاج reranking أقوى؟

وهذا تسلسل صحي أكثر من بناء القرار كله على benchmark واحد ثم اكتشاف أن الكوربس نفسه لا يوافقك.

رؤية DroidNexus هنا

سبق أن كتبنا عن البنية العامة في بنية البحث الثنائية في 2026 وعن منطق النماذج الأصغر في لماذا تفوز نماذج الاسترجاع الأصغر. هذه القطعة تضيف الحلقة المفقودة: كيف تختار ما الذي تختبره أصلًا قبل أن تتصلب الطبقة وتتحول إلى عادة.

وهذا فرق مهم. قد تكون استراتيجية البحث صحيحة، بينما يكون أول اختيار للموديل خاطئًا.

الأصل العام

هذا الإطار التقييمي لم يعد فكرة داخلية فقط، بل صار خلفه benchmark asset عام من DroidNexus.

وتوجد الآن أيضًا Collection حية على Hugging Face تجمع هذا الـdataset مع نماذج الخط الأساسي وأوراق التقييم داخل مسار استرجاع واحد قابل لإعادة الاستخدام. إذا كنت تريد الحزمة المرجعية الكاملة لا الملفات الخام فقط، فابدأ من

DroidNexus retrieval collection

يمكنك مراجعة بطاقة الأصل الكاملة داخل DroidNexus Labs أو تنزيل الملفات الخام بصيغتي JSON و CSV.

الخلاصة

الاسترجاع العربي-الإنجليزي في 2026 لم يعد يفتقر إلى الموديلات. ما ينقصه غالبًا هو انضباط التقييم.

إذا اختبرت الاستدعاء العابر للغات، والاستعلامات المختلطة، والـ lexical fallback، والمستندات الطويلة، وكلفة التشغيل، ستصبح الطبقة المناسبة أوضح بكثير. أما إذا لم تفعل، فأنت في الغالب تختار marketing مغطى بالـ vectors فقط.