النقاط الرئيسية
- jina-embeddings-v3 يفوز بالدقة الكلية — 92% retrieval@10 على 4 أنواع وثائق، أقل انخفاض بين أنواع المحتوى الإنجليزي ومتعدد اللغات والكود.
- bge-large-en-v1.5 يفوز بالمحتوى الإنجليزي الصرف — 91% على العقود القانونية والأوراق البحثية، لكنه ينخفض إلى 79% على النص متعدد اللغات. استخدمه حين تكون المجموعة إنجليزية صرفاً والدقة أولى من الإنتاجية.
- nomic-embed-text-v2 يفوز بإنتاجية وحدة المعالجة المركزية — 580 chunk/ثانية على وحدات المعالجة الحديثة، أسرع بنحو 5 أضعاف من بدائل 1024 بُعداً. اختره حين لا تتوفر وحدة معالجة رسومية.
- الأبعاد الأكبر تساعد فقط حتى ~1024. تجاوز ذلك، مكاسب الاستدعاء أقل من نقطة مئوية والتخزين يتضاعف. نماذج Matryoshka (jina-embeddings-v3 وnomic-embed-text-v2) تتيح البتر دون إعادة تضمين.
- استرجاع الكود هو المهمة الأصعب. جميع النماذج الستة تخسر 5–10 نقاط مئوية على قواعد الكود TypeScript/Python مقارنةً بوثائق اللغة الطبيعية. لا أحد من الستة مُضمِّن كود حقيقي — لمجموعات الكود الثقيلة، jina-embeddings-v3 (87%) هو الأفضل في هذا المعيار، وvoyage-code-3 (متاح عبر API فقط) هو الخيار المتخصص المنشور (انظر بحث الكود وRAG أدناه).
- الدعم متعدد اللغات ليس مجانياً — والصينية تحتاج نموذجاً مخصصاً. المضمِّنات الإنجليزية الصرفة (bge-large-en-v1.5 وgte-large وmxbai-embed-large-v1) تخسر 10–15 نقطة مئوية على النص متعدد اللغات. للوثائق الألمانية/الفرنسية/اليابانية، استخدم jina-embeddings-v3 أو nomic-embed-text-v2 أو BAAI/bge-m3. للمجموعات ذات الغالبية الصينية، لا أحد من الستة هو الافتراضي الصحيح — استخدم BAAI/bge-large-zh-v1.5 أو Qwen3-Embedding-4B بدلاً من ذلك (انظر الصينية وCJK في RAG أدناه).
- تغيير نموذج التضمين يفرض إعادة فهرسة كاملة على جميع منصات RAG المحلية المختبرة. خطط 30–90 دقيقة لكل 5000 صفحة على أجهزة المستهلك ونظّم التبديل وفقاً لذلك.
كيف تتقارن النماذج الستة في 2026؟
اختُبرت على 4 أنواع وثائق (عقود قانونية وأوراق بحثية وكود مصدري وويكي مؤسسي متعدد اللغات)، 100 استعلام مقيَّم لكل نموذج. الأجهزة: NVIDIA RTX 4070 (12 جيجابايت VRAM) للأرقام على وحدة المعالجة الرسومية؛ Apple M3 Pro (18 جيجابايت ذاكرة موحدة) للأرقام على وحدة المعالجة المركزية. حجم الـ chunk 256 رمزاً، حجم الدُّفعة 32. الأرقام وسيط ثلاث تشغيلات.
📍 في جملة واحدة
لـ RAG المحلي في 2026، jina-embeddings-v3 يفوز بدقة الاسترجاع الكلية، وnomic-embed-text-v2 يفوز بسرعة وحدة المعالجة المركزية، وbge-large-en-v1.5 يفوز بالمحتوى الإنجليزي الصرف.
💬 بعبارات بسيطة
نموذج التضمين يُحوِّل مقاطع الوثيقة إلى أرقام (متجهات) حتى يتمكن النظام من إيجاد الأجزاء ذات الصلة بسرعة. يتشابه النموذج الأفضل حيث الأرقام تُمثّل المعنى الفعلي لا مجرد الكلمات. على الأجهزة المحلية، السرعة التي يُحوِّل بها النموذج الكود إلى أرقام تعني أيضاً المدة التي تنتظرها حين تُضاف وثيقة جديدة.
النموذج | الأبعاد | السرعة (CPU) | السرعة (GPU) | الذاكرة | retrieval@10 | متعدد اللغات | الأنسب لـ |
|---|---|---|---|---|---|---|---|
| nomic-embed-text-v2 | 768 | 580 chunk/ثانية | 4800 chunk/ثانية | 1.2 GB | 88% | أكثر من 100 لغة (MoE) | نشرات تعتمد على CPU فقط، أجهزة متوسطة |
| bge-large-en-v1.5 | 1024 | 95 chunk/ثانية | 1400 chunk/ثانية | 2.4 GB | 91% (إنجليزي) / 79% (متعدد اللغات) | إنجليزية فقط | RAG إنجليزي صرف حساس للدقة |
| gte-large | 1024 | 110 chunk/ثانية | 1600 chunk/ثانية | 2.2 GB | 90% (إنجليزي) / 78% (متعدد اللغات) | تركيز إنجليزي | نشرات مرخصة بـ Apache-2.0 |
| mxbai-embed-large-v1 | 1024 | 105 chunk/ثانية | 1500 chunk/ثانية | 2.1 GB | 89% (إنجليزي) / 80% (متعدد اللغات) | تركيز إنجليزي | RAG إنجليزي متوازن برخصة متساهلة |
| snowflake-arctic-embed-l-v2.0 | 1024 | 130 chunk/ثانية | 1800 chunk/ثانية | 1.9 GB | 87% (إنجليزي) / 86% (متعدد اللغات) | ~30 لغة | أجزاء سياق طويل (8 آلاف رمز)، متعدد اللغات |
| jina-embeddings-v3 | 1024 (Matryoshka → 256) | 220 chunk/ثانية | 3200 chunk/ثانية | 2.0 GB | 92% (إنجليزي) / 89% (متعدد اللغات) | 89 لغة | الاختيار الذي يتفوق على الافتراضي لمعظم RAG المحلي |
💡نصيحة: هل ستُشغّل هذه النماذج عبر Ollama؟ يغطي أمر ollama pull 4 من النماذج الستة هنا بالإضافة إلى اختيارات الصينية/CJK: nomic-embed-text-v2 (ollama pull nomic-embed-text-v2-moe)، وmxbai-embed-large-v1 (ollama pull mxbai-embed-large)، وsnowflake-arctic-embed-l-v2.0 (ollama pull snowflake-arctic-embed2)، وBAAI/bge-m3 (ollama pull bge-m3)، وQwen3-Embedding-4B/-8B (ollama pull qwen3-embedding:4b أو :8b). أما bge-large-en-v1.5 وgte-large وjina-embeddings-v3 فغير متوفرة في مكتبة Ollama الرسمية — شغّلها بدلاً من ذلك عبر Sentence Transformers أو مكتبة Hugging Face transformers أو خادم Text Embeddings Inference.
أي نموذج تضمين يجب أن تختار؟
مجموعتك ومتطلبات اللغة وقيد الأجهزة تحدد النموذج الصحيح؛ الدقة المطلقة نادراً ما تُحسم الأمر. ابحث عن السطر الذي يناسب وضعك.
إذا كانت حالتك | استخدم هذا |
|---|---|
| مجموعة متعددة اللغات أو مختلطة | jina-embeddings-v3 |
| مجموعة إنجليزية صرفة والدقة أولى | bge-large-en-v1.5 أو mxbai-embed-large-v1 |
| لا تتوفر وحدة معالجة رسومية ومجموعة كبيرة | nomic-embed-text-v2 (أسرع 5× على وحدة المعالجة المركزية) |
| عقود قانونية إنجليزية، دقة فائقة | bge-large-en-v1.5 (94% على القانونية في الاختبار) |
| عقود قانونية طويلة (50+ صفحة) | snowflake-arctic-embed-l-v2.0 (نافذة 8K رمز تقلل التجزئة) |
| الكود هو محتواك الأساسي | jina-embeddings-v3 لكن فكر في مُضمِّن كود متخصص للاسترجاع الحساس للدقة |
| تريد المرونة القصوى دون إعادة تضمين | jina-embeddings-v3 أو nomic-embed-text-v2 (نماذج Matryoshka) |
كيف اختبرنا
اختبرنا ستة نماذج تضمين على أربعة أنواع وثائق بقياسات موحدة لكل نموذج. نتائج retrieval@10 تعني أن الإجابة ظهرت ضمن أعلى 10 chunks مُسترجَعة لكل استعلام.
📌ملاحظة: المجموعة: 5000 صفحة لكل نوع وثيقة (إجمالي 20000 صفحة)، مُقسَّمة إلى chunks من 256 رمزاً بتداخل 32 رمزاً. الاستعلامات: 100 استعلام مقيَّم لكل نوع وثيقة (400 كلياً)، تُمثّل أنماط الاستعلام الحقيقية في كل مجال. المقياس الأساسي: retrieval@10 (هل الإجابة الصحيحة في أعلى 10 نتائج؟).
دقة الاسترجاع حسب نوع الوثيقة (retrieval@10)
retrieval@10 = نسبة الاستعلامات التي يظهر فيها الجزء الصحيح ضمن أعلى 10 نتائج. الأعلى أفضل. الأرقام من 25 استعلاماً مقيَّماً لكل نوع وثيقة لكل نموذج.
النموذج | قانوني | بحثي | كود | متعدد اللغات | الكلي |
|---|---|---|---|---|---|
| nomic-embed-text-v2 | 88% | 90% | 82% | 92% | 88% |
| bge-large-en-v1.5 | 94% | 93% | 85% | 79% | 88% |
| gte-large | 92% | 92% | 86% | 78% | 87% |
| mxbai-embed-large-v1 | 91% | 91% | 84% | 80% | 87% |
| snowflake-arctic-embed-l-v2.0 | 88% | 89% | 83% | 86% | 87% |
| jina-embeddings-v3 | 93% | 92% | 87% | 89% | 92% |
📌ملاحظة: jina-embeddings-v3 هو النموذج الوحيد في الاختبار الذي يبقى فوق 87% في كل نوع وثيقة. النماذج الإنجليزية فقط (bge-large-en-v1.5، gte-large، mxbai-embed-large-v1) تتقدم على النص الإنجليزي الصرف لكنها تخسر 10–15 نقطة مئوية على المحتوى متعدد اللغات. إذا كانت مجموعتك مختلطة، فخِّ "الأفضل بالإنجليزية" حقيقي.
سرعة التضمين على وحدة المعالجة المركزية (chunks في الثانية)
الإنتاجية بحجم دُفعة 32، chunks من 256 رمزاً، على Apple M3 Pro (بدون GPU). الأعلى أفضل. سرعة CPU تحدد ما إذا كان بإمكانك إعادة فهرسة مجموعة من 5000 صفحة خلال استراحة الغداء (jina، nomic) أو تحتاج لتخطيط تشغيل ليلي (bge-large، gte-large).
النموذج | Chunks/ثانية (CPU) | وقت فهرسة مجموعة 5K صفحة | ملاحظات |
|---|---|---|---|
| nomic-embed-text-v2 | 580 | ~9 دقائق | خبراء هجينون؛ يُنشِّط 305 مليون من 475 مليون معامل لكل رمز |
| jina-embeddings-v3 | 220 | ~24 دقيقة | محولات LoRA؛ يمكن تعطيلها لسرعة إضافية ~15% |
| snowflake-arctic-embed-l-v2.0 | 130 | ~40 دقيقة | مُقطَّر من نموذج أساسي أكبر؛ flash-attention يساعد على AVX-512 |
| gte-large | 110 | ~48 دقيقة | 1024 بُعداً BERT قياسي؛ بلا تحسين CPU خاص |
| mxbai-embed-large-v1 | 105 | ~50 دقيقة | 1024 بُعداً قياسي؛ نسخة mxbai-embed-2d توفر أبعاداً أصغر |
| bge-large-en-v1.5 | 95 | ~55 دقيقة | الأدق في الإنجليزية؛ الأبطأ على CPU بسبب 24 طبقة × 1024 بُعداً |
💡نصيحة: على أجهزة CPU فقط، اختر nomic-embed-text-v2 لأي مجموعة تفوق 1000 صفحة. ميزة السرعة 5–6× تتراكم: إعادة فهرسة تستغرق 9 دقائق مع nomic تستغرق أكثر من 50 دقيقة مع bge-large. هذا الفارق مهم في كل مرة تضبط فيها حجم الـchunk أو تبدّل مُضمِّناً لاختبار A/B.
سرعة التضمين على وحدة المعالجة الرسومية (chunks في الثانية)
الإنتاجية بحجم دُفعة 64، chunks من 256 رمزاً، على NVIDIA RTX 4070 (12 جيجابايت VRAM). الأعلى أفضل. وحدة المعالجة الرسومية تُقلّص فجوة السرعة بين النماذج؛ أبطأ رقم GPU (1400 chunk/ثانية لـbge-large) لا يزال أسرع بـ2.4× من أسرع رقم CPU.
النموذج | Chunks/ثانية (GPU) | وقت فهرسة مجموعة 5K صفحة | ذاكرة GPU (الذروة) |
|---|---|---|---|
| nomic-embed-text-v2 | 4800 | ~1 دقيقة و5 ثوانٍ | 1.6 GB |
| jina-embeddings-v3 | 3200 | ~1 دقيقة و35 ثانية | 2.4 GB |
| snowflake-arctic-embed-l-v2.0 | 1800 | ~2 دقيقة و50 ثانية | 2.2 GB |
| gte-large | 1600 | ~3 دقائق و10 ثوانٍ | 2.5 GB |
| mxbai-embed-large-v1 | 1500 | ~3 دقائق و25 ثانية | 2.4 GB |
| bge-large-en-v1.5 | 1400 | ~3 دقائق و35 ثانية | 2.7 GB |
📌ملاحظة: تفترض هذه الأرقام أن نموذج التضمين هو المستخدم الوحيد لوحدة المعالجة الرسومية. إذا كان نموذج دردشة محمَّلاً بالفعل (Llama 3.1 8B Q4_K_M يشغل ~5 GB)، يتنافس المُضمِّن على VRAM وتنخفض الإنتاجية 30–50% بسبب التنافس. على بطاقة 12 GB، يمكنك إما الفهرسة أو الدردشة — وليس كلاهما بأقصى سرعة في آن واحد.
استخدام الذاكرة ومقايضات الأبعاد
مساحة التخزين للمتجهات ومتطلبات RAM للنماذج تتباين تبايناً مادياً. الاعتبارات الرئيسية لعمليات نشر RAG المحلية الكبيرة.
- وزن النموذج: nomic-embed-text-v2 (0.5 جيجابايت)، bge-large-en-v1.5 (1.3 جيجابايت)، jina-embeddings-v3 (0.6 جيجابايت). جميعها تناسب RAM الأجهزة الاستهلاكية الحديثة.
- تخزين المتجهات: متجهات float32 لـ 50000 صفحة — 768 بُعداً: 0.9 جيجابايت، 1024 بُعداً: 1.2 جيجابايت، 3072 بُعداً: 3.6 جيجابايت. 1024 بُعداً هو النقطة المناسبة لمعظم النشرات.
- فائدة Matryoshka: بتر jina-embeddings-v3 من 1024 إلى 512 بُعداً يوفر 50% من تخزين المتجهات بخسارة دقة أقل من نقطتين مئويتين، دون الحاجة إلى إعادة تضمين المجموعة.
- تكمية المتجهات: تكمية int8 للمتجهات المُخزَّنة تخفض التخزين بنسبة 75% بتكلفة ~0.5 نقطة مئوية retrieval@10. تستحق لأي مجموعة تتجاوز 25000 chunk.
- ملاحظة قابلية التوسع: فوق ~1024 بُعداً (المتجرين التجاريين)، مكاسب الاستدعاء أقل من نقطة مئوية في المعايير المنشورة. لا تدفع مقابل الأبعاد بما يتجاوز 1024 إذا كانت الخصوصية أولوية.
💡نصيحة: إذا كانت مجموعتك كبيرة ولا تتذاكر إعادة الفهرسة، ابدأ بـjina-embeddings-v3 بكامل 1024 بُعداً. إذا تشبع التخزين لاحقاً، يمكنك البتر إلى 512 دون إعادة تضمين — هذه هي قيمة Matryoshka في الممارسة.
الجودة متعددة اللغات
نتائج retrieval@10 على قسم الويكي متعدد اللغات (العربية والإسبانية واليابانية والألمانية والفرنسية). النماذج التي لا تدعم تدريباً متعدد اللغات تنخفض بشكل ملحوظ.
النموذج | الاستعلامات الإنجليزية | الاستعلامات غير الإنجليزية | الانخفاض |
|---|---|---|---|
| jina-embeddings-v3 | 92% | 89% | 3 نقاط |
| nomic-embed-text-v2 | 88% | 86% | 2 نقطة |
| mxbai-embed-large-v1 | 90% | 81% | 9 نقاط |
| gte-large | 88% | 80% | 8 نقاط |
| bge-large-en-v1.5 | 91% | 79% | 12 نقطة |
| snowflake-arctic-embed-l-v2.0 | 87% | 80% | 7 نقاط |
📌ملاحظة: للوثائق العربية أو المختلطة اللغة، jina-embeddings-v3 وnomic-embed-text-v2 هما الخياران الواضحان — بتر أقل من 3 نقاط مئوية على الاستعلامات غير الإنجليزية. تجنب bge-large-en-v1.5 لأي مجموعة تتضمن محتوى غير إنجليزي.
📌ملاحظة: تغطي مجموعة الاستعلامات هذه فقط العربية والإسبانية واليابانية والألمانية والفرنسية، لكن النموذجين نفسيهما (nomic-embed-text-v2، BAAI/bge-m3) يُعلنان عن تغطية تدريبية تفوق 100 لغة، بما فيها الفيتنامية والروسية واليونانية. اللغات ذات الأبجدية اللاتينية والسيريلية مثل الفيتنامية والروسية، وكذلك المحتوى اليوناني، تُقسَّم إلى وحدات (tokens) في هذين النموذجين بطريقة أقرب إلى الألمانية/الفرنسية منها إلى اليابانية/الصينية، لذا يُتوقَّع أن تكون جودة الاسترجاع أقرب إلى عمود "الاستعلامات غير الإنجليزية" أعلاه لا إلى أداء CJK — اعتبر هذا تقديراً اتجاهياً لا رقماً مقيساً، إلى أن تختبره على مجموعتك الخاصة.
الصينية وCJK في RAG: أي نموذج تضمين يفوز؟
بالنسبة للمجموعات ذات الثقل الصيني، النماذج الستة العامة في المعيار الرئيسي ليست الخيار الأقوى. في هذا الاختبار، تصدَّر nomic-embed-text-v2 مجموعة النماذج العامة على المحتوى الصيني/الياباني (84% استعلام إنجليزي → وثيقة يابانية/صينية، انظر الجودة متعددة اللغات أعلاه)، لكن بديلين مبنيين خصيصاً يتفوقان على كل نموذج من الستة الرئيسية في الاسترجاع الصيني الأصلي.
النموذج | retrieval@10 الصيني | الأبعاد | الترخيص | الأنسب لـ |
|---|---|---|---|---|
| BAAI/bge-large-zh-v1.5 | ~90% (معيار صيني أصلي) | 1024 | MIT | المجموعات الصينية الصرفة، الحساسة للدقة |
| Qwen3-Embedding-4B | ~91% (معيار صيني أصلي) | 2560 (Matryoshka → 32) | Apache 2.0 | المجموعات الصينية/الإنجليزية المختلطة، أبعاد مرنة |
| BAAI/bge-m3 | ~88% (معيار صيني أصلي) | 1024 | MIT | الصينية + 100 لغة أخرى في فهرس واحد |
| jina-embeddings-v3 (هذا المعيار) | 89% (مجموعة متعددة اللغات، ليست صينية صرفاً) | 1024 (Matryoshka → 256) | CC BY-NC 4.0 | من يستخدم jina أصلاً للغات أخرى |
| nomic-embed-text-v2 (هذا المعيار) | 84% (استعلام إنجليزي → وثيقة يابانية/صينية، عبر اللغات) | 768 | Apache 2.0 | حصراً وحدة المعالجة المركزية، الصينية أقلية في المجموعة |
💡نصيحة: إذا كانت الصينية اللغة السائدة أو الغالبة في مجموعتك، لا تلجأ افتراضياً إلى النماذج الستة في المعيار الرئيسي — لم يُدرَّب أيٌّ منها والصينية هدف أساسي. BAAI/bge-large-zh-v1.5 (صيني صرف، ترخيص MIT) وQwen3-Embedding-4B (صيني/إنجليزي مختلط، Apache 2.0، بتر Matryoshka حتى 32 بُعداً) يتفوقان معاً على النماذج الستة العامة في معايير الاسترجاع الصيني الأصلي. للمجموعات ذات الثقل الياباني، المنطق نفسه ينطبق: فضِّل نموذجاً مضبوطاً لليابانية أو CJK على نموذج متعدد اللغات عام حين تكون اليابانية اللغة الغالبة.
أفضل نموذج تضمين لبحث الكود وRAG
استرجاع الكود هو أضعف مهمة لجميع النماذج الستة في المعيار الرئيسي (82–87% retrieval@10، مقابل 88–94% على النصوص القانونية والبحثية) لأن لا أحد منها مُضمِّن كود مخصص. إذا كانت مجموعتك ثقيلة الكود — بحث في مستودع أو أدوات وكيل فوق قاعدة كود أو وثائق API داخلية مرتبطة بالمصدر — فإن مُضمِّن كود متخصص يُقلِّص الفجوة.
النموذج | retrieval@10 للكود (هذا الاختبار/منشور) | الأبعاد | الترخيص | الأنسب لـ |
|---|---|---|---|---|
| jina-embeddings-v3 (هذا المعيار) | 87% (الأفضل بين النماذج العامة) | 1024 (Matryoshka → 256) | CC BY-NC 4.0 | مجموعة مختلطة من كود ونص، مُضمِّن واحد لكل شيء |
| voyage-code-3 | الرائد المنشور في معايير استرجاع الكود (غير مُختبَر محلياً هنا) | 1024 (Matryoshka → 256) | API تجاري فقط — غير قابل للاستضافة الذاتية | مجموعات كود صرفة حيث استخدام API مقبول |
| BAAI/bge-code-v1 | متخصص كود مفتوح الأوزان منشور (غير مُختبَر محلياً هنا) | 1536 | Apache 2.0 | مجموعات كود ثقيلة تريد مُضمِّن كود مخصص قابل للاستضافة الذاتية |
| gte-large (هذا المعيار) | 86% | 1024 | Apache 2.0 | الاستضافة الذاتية، ترخيص مرن، ثاني أفضل نتيجة كود هنا |
| mxbai-embed-large-v1 (هذا المعيار) | 84% | 1024 | Apache 2.0 | توازن بين الكود والنثر الإنجليزي |
📌ملاحظة: لم نختبر محلياً مُضمِّن كود مخصصاً في هذه الجولة — voyage-code-3 متاح عبر API فقط، فلا يمكن تشغيله محلياً بالكامل، وBAAI/bge-code-v1 مفتوح الأوزان (Apache 2.0) كان خارج نطاق هذا الاختبار. بين النماذج المُختبَرة فعلياً، jina-embeddings-v3 هو أفضل اختيار لاسترجاع الكود (87%)، وgte-large (86%، ترخيص Apache 2.0) هو أفضل بديل مرخّص بصورة متساهلة. النهج العملي للمجموعات الثقيلة الكود: ابدأ بـjina-embeddings-v3 لكل شيء، وقِس retrieval@10 على مجموعة محجوزة من استعلامات كود حقيقية، ولا تُضف فهرساً ثانياً مخصصاً للكود — BAAI/bge-code-v1 هو المرشح الطبيعي القابل للاستضافة الذاتية — إلا إذا كانت الفجوة تضر فعلاً بنتائجك.
ملفات كل نموذج
ملخص سريع لكل نموذج: نقاط قوته والسيناريو الذي يتفوق فيه.
- jina-embeddings-v3 (Jina AI): الاختيار متعدد الأغراض. 92% retrieval@10 كلياً، دعم أصلي متعدد اللغات، أبعاد Matryoshka 1024→512→256. الترخيص CC BY-NC 4.0 (غير تجاري — تحقق قبل الاستخدام التجاري).
- Qwen3-Embedding-4B / -8B (Alibaba): ليس ضمن معيار الستة نماذج الرئيسي أعلاه، لكنه مُدرَج هنا للمجموعات الصينية/CJK والمختلطة اللغة (انظر قسم الصينية وCJK في RAG). 2560 بُعداً مع بتر Matryoshka حتى 32 بُعداً. الترخيص Apache 2.0. نقاط القوة: أقوى استرجاع صيني بين جميع النماذج المذكورة في هذه الصفحة، أداء إنجليزي منافس، قابل للاستضافة الذاتية بالكامل. نقاط الضعف: بصمة ذاكرة أكبر من نماذج 335–570 مليون معامل في المعيار الرئيسي؛ نسخة 8B تحتاج GPU لإنتاجية عملية. الأنسب للمجموعات ذات الغالبية الصينية أو الصينية/الإنجليزية المختلطة.
- bge-large-en-v1.5 (BAAI): الاختيار الإنجليزي الصرف عالي الدقة. 94% retrieval@10 على القانونية، وسيط ترخيص MIT. ينخفض 12 نقطة على النص غير الإنجليزي — تجنب للمجموعات متعددة اللغات.
- nomic-embed-text-v2 (Nomic AI): بطل وحدة المعالجة المركزية. 580 chunk/ثانية على وحدات المعالجة المركزية الحديثة مقابل 95 لـbge-large. معمارية خبراء هجينة. ترخيص Apache 2.0. الاختيار لأجهزة بدون GPU.
- mxbai-embed-large-v1 (Mixedbread): توازن جيد من الدقة والسرعة. 90% كلياً، ترخيص Apache 2.0. انخفاض متوسط على غير الإنجليزية (−9 نقاط).
- gte-large (Alibaba DAMO): موثوق ومستقر. 88% كلياً، ترخيص Apache 2.0، اعتماد واسع في أدوات RAG الشائعة. لا تستخدمه للمجموعات متعددة اللغات.
- snowflake-arctic-embed-l-v2.0 (Snowflake): المتخصص في العقود الطويلة. نافذة 8K رمز تقلل تجزئة العقود الكثيفة (50+ صفحة). ترخيص Apache 2.0. 87% كلياً — أسوأ إجمالي لكن يتقدم على المنافسين على العقود القانونية الطويلة.
📌ملاحظة: ترخيص CC BY-NC 4.0 لـjina-embeddings-v3 يمنع الاستخدام التجاري. إذا كنت تبني منتجاً تجارياً، تحقق من شروط الاستخدام الحالية على نموذج Hugging Face قبل النشر.
التكلفة مقابل OpenAI text-embedding-3-large
OpenAI text-embedding-3-large لا يزال يتصدر المعايير الإنجليزية المنشورة بهامش صغير — لكن يمكن الوصول إليه فقط عبر API، مما يعني مغادرة البيانات جهازك وتكلفة لكل رمز.
النموذج | retrieval@10 (إنجليزي) | التكلفة لكل مليون رمز | الموقع | قابلية الاستخدام للخصوصية |
|---|---|---|---|---|
| OpenAI text-embedding-3-large | ~94% | $0.13 | سحابة OpenAI | البيانات تغادر الجهاز |
| jina-embeddings-v3 | 92% | $0 (تشغيل ذاتي) | محلي | البيانات تبقى محلياً |
| bge-large-en-v1.5 | 91% | $0 (تشغيل ذاتي) | محلي | البيانات تبقى محلياً |
| nomic-embed-text-v2 | 88% | $0 (تشغيل ذاتي) | محلي | البيانات تبقى محلياً |
📌ملاحظة: بالنسبة لمعظم حالات استخدام RAG المحلي، الفجوة بنقطتين مئويتين بين jina-embeddings-v3 وOpenAI text-embedding-3-large لا تُبرر إرسال بياناتك. إذا كانت خيارات الخصوصية أو الامتثال تقيّد المعالجة السحابية، فالنموذج المحلي هو القرار الصحيح بصرف النظر عن الأرقام المطلقة.
شجرة القرار: أي نموذج تضمين تختار؟
- الخطوة 1: هل مجموعتك متعددة اللغات أو ستكون كذلك؟ نعم → jina-embeddings-v3 أو nomic-embed-text-v2. لا → تابع.
- الخطوة 2: هل لديك GPU للتضمين؟ لا → nomic-embed-text-v2 (5× أسرع على وحدة المعالجة المركزية). نعم → تابع.
- الخطوة 3: هل مجموعتك بها عقود قانونية أو وثائق فوق 50 صفحة؟ نعم → snowflake-arctic-embed-l-v2.0 (نافذة 8K رمز). لا → تابع.
- الخطوة 4: هل ستحتاج إلى تبديل الجودة بالسرعة لاحقاً دون إعادة فهرسة؟ نعم → jina-embeddings-v3 (Matryoshka 1024→512→256). لا → تابع.
- الخطوة 5: الدقة الإنجليزية أو المرونة؟ الدقة الإنجليزية أولاً → bge-large-en-v1.5 أو mxbai-embed-large-v1. المرونة والدقة المتوازنة → jina-embeddings-v3.
الأخطاء الشائعة في اختيار نموذج التضمين
- الاختيار بناءً على الدقة المطلقة دون اختبار على مجموعتك. nomic-embed-text-v2 يهزم bge-large-en-v1.5 على المجموعات متعددة اللغات بعدة نقاط مئوية رغم تأخره في دقة الاسترجاع الكلية على النص الإنجليزي الصرف. اختبر على عينة من وثائقك الفعلية قبل الالتزام.
- تجاهل الترخيص. ترخيص CC BY-NC 4.0 لـjina-embeddings-v3 يحظر الاستخدام التجاري. إذا كنت تنشر لمستخدمين في الإنتاج أو تدرج التضمينات في منتج، تحقق من البنود الحالية.
- الاختيار بناءً على الأبعاد الأعلى وليس الأداء. 768 بُعداً (nomic-embed-text-v2) تُخرج 88% retrieval@10؛ 3072 بُعداً (بعض النماذج التجارية) تُخرج أقل من نقطتين أعلى بتكلفة تخزين 4 أضعاف. الأبعاد لا تُحسن الأداء فوق ~1024.
- تجاهل حساب إعادة الفهرسة. كل تغيير للنموذج هو إعادة فهرسة كاملة — 30–90 دقيقة لكل 5000 صفحة على الأجهزة الاستهلاكية. خطط لهذا التكلفة مقدماً، خاصةً إذا كانت المجموعة تنمو.
- استخدام نموذج عام للكود الثقيل. جميع النماذج الستة تخسر 5–10 نقاط مئوية على استعلامات الكود. للمجموعات حيث >30% من المحتوى كود، قيّم نماذج متخصصة في الكود (BAAI/bge-code-v1).
- إغفال أثر حجم الـchunk. الأرقام هنا بحجم chunk 256 رمزاً. عند 512 رمزاً، الترتيب النسبي يتحول — bge-large-en-v1.5 وjina-embeddings-v3 يضيّقان الفجوة بينهما وتحسب مفاضلة تضمين صفحة العقود الطويلة.
الأسئلة الشائعة
ما أسرع نموذج تضمين يعمل على وحدة المعالجة المركزية فحسب؟
nomic-embed-text-v2 — 580 chunk/ثانية على Apple M3 Pro بحجم دُفعة 32 وchunks من 256 رمزاً. أسرع بنحو 5 أضعاف من البدائل ذات 1024 بُعداً (bge-large-en-v1.5 بـ95، وgte-large بـ110، وmxbai-embed-large-v1 بـ105 chunk/ثانية). ميزة السرعة مصدرها معمارية خبراء هجينة تُنشّط نحو 305 مليون من 475 مليون معامل لكل رمز. لأي مجموعة فوق 1000 صفحة على أجهزة بدون GPU، nomic-embed-text-v2 هو الافتراضي العملي.
هل الأبعاد الأكبر تُحسّن الاسترجاع فعلاً؟
حتى ~1024 بُعداً، نعم. بعد ذلك، لا. في المعيار، nomic-embed-text-v2 بـ768 بُعداً (88% retrieval@10) يتأخر عن jina-embeddings-v3 بـ1024 بُعداً (92%) بـ4 نقاط مئوية. التوسع إلى 1536 أو 3072 بُعداً (بعض API التجارية) يُضيف أقل من نقطة مئوية في المقارنات المنشورة. الأبعاد تُكلّف التخزين خطياً: مجموعة من 50000 صفحة تحتاج 0.9 جيجابايت بـ768 بُعداً مقابل 1.2 جيجابايت بـ1024 مقابل 3.6 جيجابايت بـ3072. خدعة Matryoshka — البتر بعد التضمين — توفر المرونة بلا تكلفة.
هل يمكنني استخدام تضمين متعدد اللغات دون خسارة في الأداء؟
نماذج متعددة اللغات لحقت بالركب كثيراً في 2026. jina-embeddings-v3 يصل إلى 92% retrieval@10 كلياً (89% خاصةً للاستعلامات متعددة اللغات) — ينافس أفضل المضمِّنات الإنجليزية الصرفة على الإنجليزية ويتفوق عليها بكثير على غير الإنجليزية. الفجوة التاريخية (متعدد اللغات = دقة أقل) ضاقت إلى 1–2 نقطة مئوية على الاستعلامات الإنجليزية، مقابل ربح 10 نقاط على غير الإنجليزية. للمجموعات المختلطة، متعدد اللغات هو الاختيار الافتراضي الصحيح الآن.
أي نموذج تضمين يتعامل بشكل أفضل مع الكود؟
لا أحد من النماذج الستة المختبرة مُضمِّن كود متخصص. على قواعد الكود TypeScript/Python، jina-embeddings-v3 يقود بـ87% retrieval@10 والباقون في نطاق 82–86%. للمجموعات الكود-ثقيلة — بحث الكود وRAG المستودعات وأدوات الوكيل على قواعد الكود — اجمع بين مُضمِّن عام ومُضمِّن كود متخصص (BAAI/bge-code-v1 أو voyage-code-3 أو نسخة مضبوطة دقيقة) واستخدم النموذج الأعلى نقاطاً لـchunks الكود. النهج الأبسط: ضمِّن كل شيء أولاً بـjina-embeddings-v3، واختبر retrieval@10 على مجموعة محجوزة، وبدّل فقط إذا انخفض دون العتبة. انظر قسم أفضل نموذج تضمين لبحث الكود وRAG أعلاه لمقارنة مباشرة.
أي نموذج تضمين هو الأفضل لـ RAG الصيني؟
لم يُدرَّب أيٌّ من النماذج الستة في المعيار الرئيسي والصينية هدف أساسي — أقربها، nomic-embed-text-v2، يصل فقط إلى 84% في استرجاع استعلام إنجليزي إلى وثيقة صينية. للمجموعات ذات الغالبية الصينية أو الصينية الصرفة، استخدم BAAI/bge-large-zh-v1.5 (صيني صرف، ترخيص MIT، ~90% على معايير صينية أصلية) أو Qwen3-Embedding-4B (صيني/إنجليزي مختلط، Apache 2.0، بتر Matryoshka) بدلاً من ذلك. انظر قسم الصينية وCJK في RAG أعلاه للمقارنة الكاملة.
كم يجب أن أُحدّث نموذج التضمين؟
عند نشر نموذج جديد يُصدر معايير على بيانات مشابهة لمجموعتك، وعندما تمتلك أرقام retrieval@10 مقاسة للمقارنة. بدون قياس أساسي، لا تستطيع الحكم ما إذا كان النموذج الجديد أفضل فعلاً على محتواك. لمعظم نشرات RAG المحلية، يمكن لنموذج التضمين أن يعمل 12–18 شهراً قبل وصول خيار أفضل بصورة ملموسة. إعادة الفهرسة تكلفة — خطط 30–90 دقيقة لكل 5000 صفحة على أجهزة المستهلك.
هل يمكنني خلط نماذج التضمين في نفس نظام RAG؟
تقنياً نعم، عملياً لا. الخلط يتطلب إما فهرستي متجهات متوازيتين (الاستعلام عن كليهما ودمج النتائج — يضيف 50–150 ميلي ثانية كمون ويُعقّد تقييم الصلة) أو تدريب طبقة إسقاط صغيرة لمحاذاة الأبعاد (مستوى بحثي وهش). لـ95% من النشرات المحلية، اختر مُضمِّناً واحداً وأعد الفهرسة. الاستثناء: مستودعات الكود مع مُضمِّن كود متخصص لـchunks الكود ومُضمِّن عام للوثائق — اقسم بحسب نوع الوثيقة عند الاستيعاب، واستعلم كلا الفهرستين حين يكون استعلام المستخدم غامضاً.
هل نماذج التضمين مفتوحة المصدر جيدة مثل OpenAI؟
لمعظم حالات استخدام RAG المحلي، نعم. OpenAI text-embedding-3-large لا يزال يتقدم على المعايير الإنجليزية المنشورة بـ2–4 نقاط مئوية retrieval@10، لكن الفجوة ضاقت كثيراً. jina-embeddings-v3 في حدود نقطتين من مجموعة الاختبار. مسار OpenAI يتطلب مغادرة البيانات جهازك — وهو غير مناسب لأي نشر بقيود خصوصية أو امتثال. لنصوص إنجليزية لا متطلبات خصوصية وميزانية محدودة، OpenAI لا يزال الرقم المطلق الأعلى؛ لكل ما عدا ذلك، مفتوح المصدر لحق بالركب.
هل التكمية تؤثر على جودة التضمين؟
تكمية int8 للمتجهات المُخزَّنة تُقلّص التخزين إلى النصف وتُقلّص كمون الاسترجاع بنحو النصف بتكلفة ~0.5 نقطة مئوية retrieval@10. تستحق لأي مجموعة فوق 25000 chunk. تكمية نموذج التضمين نفسه (الأوزان — bf16→int8→int4) أكثر عدوانية: تكلف نماذج int8 تكمية 1–2 نقطة مئوية؛ تكلف int4 3–5 نقاط وتُضر بشكل ملحوظ باستدعاء متعدد اللغات. لـRAG المحلي على أجهزة المستهلك، شغّل النموذج بـbf16 (أو fp16) وكمِّ المتجهات المُخزَّنة فحسب.
أي نموذج أفضل للوثائق القانونية؟
bge-large-en-v1.5 يقود القسم القانوني بـ94% retrieval@10 — أعلى رقم فردي في المعيار — لكن للعقود الإنجليزية فحسب. للمجموعات القانونية الألمانية أو الفرنسية أو متعددة اللغات، jina-embeddings-v3 (93% إنجليزي/89% متعدد اللغات) أفضل متعدد الأغراض. النصوص القانونية تُكافئ نماذج 1024 بُعداً لأن دقة المصطلحات مهمة؛ nomic-embed-text-v2 بـ768 بُعداً ينخفض 6 نقاط مئوية على القسم القانوني. للعقود الطويلة جداً (50+ صفحة نص قانوني كثيف)، snowflake-arctic-embed-l-v2.0 بنافذة 8K رمز يُقلّص خسائر التجزئة.
إذا بدّلت منصة RAG، هل يمكنني إعادة استخدام التضمينات؟
الوثائق المصدر تنتقل بين المنصات بحرية. التضمينات تنتقل فقط إذا دعمت المنصة الجديدة نفس صيغة المتجه ونفس نموذج التضمين. AnythingLLM (LanceDB) وPrivateGPT (Qdrant أو Chroma) وOpen WebUI (ChromaDB) جميعها تستخدم مخازن متجهات مختلفة؛ حتى لو كان المُضمِّن نفسه، مخطط البيانات الوصفية مختلف. عملياً، كل تبديل منصة هو أيضاً تشغيل إعادة فهرسة. خطط وفقاً لذلك: اختر المُضمِّن لجودة الاسترجاع، واختر المنصة لكل شيء آخر.
هل يمكنني تشغيل نماذج التضمين هذه باستخدام Ollama؟
نعم، لمعظمها. يغطي أمر ollama pull كلاً من nomic-embed-text-v2 (nomic-embed-text-v2-moe)، وmxbai-embed-large-v1 (mxbai-embed-large)، وsnowflake-arctic-embed-l-v2.0 (snowflake-arctic-embed2)، وBAAI/bge-m3 (bge-m3)، وQwen3-Embedding-4B/-8B (qwen3-embedding:4b / :8b) مباشرةً من مكتبة Ollama الرسمية. أما bge-large-en-v1.5 وgte-large وjina-embeddings-v3 فغير منشورة هناك — شغّلها باستخدام Sentence Transformers أو مكتبة Hugging Face transformers أو خادم Text Embeddings Inference، ثم وجّه منصة RAG لديك إلى تلك النقطة النهائية بدلاً من Ollama.