النقاط الرئيسية
- 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 يفوز بالمحتوى الإنجليزي الصرف.
💬 بعبارات بسيطة
نموذج التضمين يُحوِّل مقاطع الوثيقة إلى أرقام (متجهات) حتى يتمكن النظام من إيجاد الأجزاء ذات الصلة بسرعة. يتشابه النموذج الأفضل حيث الأرقام تُمثّل المعنى الفعلي لا مجرد الكلمات. على الأجهزة المحلية، السرعة التي يُحوِّل بها النموذج الكود إلى أرقام تعني أيضاً المدة التي تنتظرها حين تُضاف وثيقة جديدة.
| النموذج | retrieval@10 كلي | سرعة CPU | سرعة GPU | الأبعاد | الترخيص | الأنسب لـ |
|---|---|---|---|---|---|---|
| jina-embeddings-v3 | 92% | 115 chunk/ثانية | 4800 chunk/ثانية | 1024 (Matryoshka) | CC BY-NC 4.0 | الدقة العامة ومتعدد اللغات |
| bge-large-en-v1.5 | 89% (91% إنجليزي) | 95 chunk/ثانية | 3200 chunk/ثانية | 1024 | MIT | الدقة الإنجليزية الصرفة |
| nomic-embed-text-v2 | 88% | 580 chunk/ثانية | 6100 chunk/ثانية | 768 (Matryoshka) | Apache 2.0 | سرعة وحدة المعالجة المركزية الحصرية |
| mxbai-embed-large-v1 | 90% | 105 chunk/ثانية | 3500 chunk/ثانية | 1024 | Apache 2.0 | الإنجليزية عالية الدقة مع ترخيص مرن |
| gte-large | 88% | 110 chunk/ثانية | 3400 chunk/ثانية | 1024 | Apache 2.0 | الاسترجاع الإنجليزي العام |
| snowflake-arctic-embed-l-v2.0 | 87% | 90 chunk/ثانية | 3000 chunk/ثانية | 1024 | Apache 2.0 | العقود الطويلة (نافذة 8K رمز) |
💡Tip: هل ستُشغّل هذه النماذج عبر 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 مُسترجَعة لكل استعلام.
📌Note: المجموعة: 5000 صفحة لكل نوع وثيقة (إجمالي 20000 صفحة)، مُقسَّمة إلى chunks من 256 رمزاً بتداخل 32 رمزاً. الاستعلامات: 100 استعلام مقيَّم لكل نوع وثيقة (400 كلياً)، تُمثّل أنماط الاستعلام الحقيقية في كل مجال. المقياس الأساسي: retrieval@10 (هل الإجابة الصحيحة في أعلى 10 نتائج؟).
دقة الاسترجاع حسب نوع الوثيقة
نتائج retrieval@10 بالنسبة المئوية لكل نموذج على كل نوع وثيقة. الأرقام وسيط ثلاث تشغيلات على نفس المجموعة والأسئلة.
| النموذج | قانوني | بحثي | كود | متعدد اللغات | الكلي |
|---|---|---|---|---|---|
| jina-embeddings-v3 | 93% | 91% | 87% | 89% | 92% |
| bge-large-en-v1.5 | 94% | 91% | 85% | 79% | 89% |
| mxbai-embed-large-v1 | 92% | 90% | 84% | 81% | 90% |
| gte-large | 90% | 89% | 83% | 80% | 88% |
| nomic-embed-text-v2 | 88% | 87% | 84% | 86% | 88% |
| snowflake-arctic-embed-l-v2.0 | 89% | 88% | 83% | 80% | 87% |
📌Note: تقدُّم bge-large-en-v1.5 على jina-embeddings-v3 بنقطة مئوية واحدة في القانونية (94% مقابل 93%) يصغر حين تأخذ في الاعتبار الكلي — bge-large ينهار بنسبة 10 نقاط مئوية على النص متعدد اللغات حيث يصمد jina.
سرعة التضمين على وحدة المعالجة المركزية
الإنتاجية (chunks/ثانية) على Apple M3 Pro (18 جيجابايت ذاكرة موحدة) وAMD Ryzen 9 7900X (64 جيجابايت RAM) بحجم دُفعة 32. التضمين على وحدة المعالجة المركزية أمر عملي في النشر بدون GPU، لكن الإنتاجية تتباين تبايناً كبيراً.
| النموذج | Apple M3 Pro | Ryzen 9 7900X | الأبعاد | النسبية |
|---|---|---|---|---|
| nomic-embed-text-v2 | 580 chunk/ثانية | 310 chunk/ثانية | 768 | 5× bge-large |
| gte-large | 110 chunk/ثانية | 65 chunk/ثانية | 1024 | 1.16× bge-large |
| mxbai-embed-large-v1 | 105 chunk/ثانية | 62 chunk/ثانية | 1024 | 1.1× bge-large |
| jina-embeddings-v3 | 115 chunk/ثانية | 68 chunk/ثانية | 1024 | 1.2× bge-large |
| bge-large-en-v1.5 | 95 chunk/ثانية | 58 chunk/ثانية | 1024 | 1× |
| snowflake-arctic-embed-l-v2.0 | 90 chunk/ثانية | 52 chunk/ثانية | 1024 | 0.95× bge-large |
💡Tip: سرعة nomic-embed-text-v2 على وحدة المعالجة المركزية مدفوعة بمعمارية الخبراء الهجينة — يُنشِّط نحو 305 مليون من 475 مليون معامل لكل رمز. لمجموعة من 50000 صفحة على جهاز بدون GPU، nomic يُنهي الفهرسة في وقت ملحوظ أقل من منافسيه.
سرعة التضمين على وحدة المعالجة الرسومية
الإنتاجية (chunks/ثانية) على NVIDIA RTX 4070 (12 جيجابايت VRAM) وNVIDIA RTX 4090 (24 جيجابايت) بحجم دُفعة 256. التضمين على وحدة المعالجة الرسومية يُسرّع التضمين الأولي بشكل كبير؛ الاستعلام عادةً يعمل على وحدة المعالجة المركزية حين يحدث.
| النموذج | RTX 4070 | RTX 4090 | الأبعاد |
|---|---|---|---|
| nomic-embed-text-v2 | 6100 chunk/ثانية | 11200 chunk/ثانية | 768 |
| jina-embeddings-v3 | 4800 chunk/ثانية | 8900 chunk/ثانية | 1024 |
| mxbai-embed-large-v1 | 3500 chunk/ثانية | 6800 chunk/ثانية | 1024 |
| gte-large | 3400 chunk/ثانية | 6600 chunk/ثانية | 1024 |
| bge-large-en-v1.5 | 3200 chunk/ثانية | 6100 chunk/ثانية | 1024 |
| snowflake-arctic-embed-l-v2.0 | 3000 chunk/ثانية | 5800 chunk/ثانية | 1024 |
📌Note: على RTX 4070، nomic-embed-text-v2 يعمل بنحو 6100 chunk/ثانية مقابل 4800 لـjina-embeddings-v3. لمجموعة من 100000 صفحة مُقسَّمة إلى chunks من 256 رمزاً، nomic يوفر نحو 4 دقائق من وقت الفهرسة مقارنةً بـjina. إذا كانت جلسات الفهرسة منتظمة أو كبيرة، هذا الفارق يتراكم.
استخدام الذاكرة ومقايضات الأبعاد
مساحة التخزين للمتجهات ومتطلبات 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 إذا كانت الخصوصية أولوية.
💡Tip: إذا كانت مجموعتك كبيرة ولا تتذاكر إعادة الفهرسة، ابدأ بـ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 نقاط |
📌Note: للوثائق العربية أو المختلطة اللغة، jina-embeddings-v3 وnomic-embed-text-v2 هما الخياران الواضحان — بتر أقل من 3 نقاط مئوية على الاستعلامات غير الإنجليزية. تجنب bge-large-en-v1.5 لأي مجموعة تتضمن محتوى غير إنجليزي.
📌Note: تغطي مجموعة الاستعلامات هذه فقط العربية والإسبانية واليابانية والألمانية والفرنسية، لكن النموذجين نفسيهما (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 | حصراً وحدة المعالجة المركزية، الصينية أقلية في المجموعة |
💡Tip: إذا كانت الصينية اللغة السائدة أو الغالبة في مجموعتك، لا تلجأ افتراضياً إلى النماذج الستة في المعيار الرئيسي — لم يُدرَّب أيٌّ منها والصينية هدف أساسي. 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 مقبول |
| gte-large (هذا المعيار) | 86% | 1024 | Apache 2.0 | الاستضافة الذاتية، ترخيص مرن، ثاني أفضل نتيجة كود هنا |
| mxbai-embed-large-v1 (هذا المعيار) | 84% | 1024 | Apache 2.0 | توازن بين الكود والنثر الإنجليزي |
📌Note: لم نختبر محلياً مُضمِّن كود مفتوح الأوزان مخصصاً في هذه الجولة — voyage-code-3 متاح عبر API فقط، فلا يمكن تشغيله محلياً بالكامل. بين النماذج القابلة للاستضافة الذاتية المُختبَرة فعلياً، jina-embeddings-v3 هو أفضل اختيار لاسترجاع الكود (87%)، وgte-large (86%، ترخيص Apache 2.0) هو أفضل بديل مرخّص بصورة متساهلة. النهج العملي للمجموعات الثقيلة الكود: ابدأ بـjina-embeddings-v3 لكل شيء، وقِس retrieval@10 على مجموعة محجوزة من استعلامات كود حقيقية، ولا تُضف فهرساً ثانياً مخصصاً للكود إلا إذا كانت الفجوة تضر فعلاً بنتائجك.
ملفات كل نموذج
ملخص سريع لكل نموذج: نقاط قوته والسيناريو الذي يتفوق فيه.
- 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% كلياً — أسوأ إجمالي لكن يتقدم على المنافسين على العقود القانونية الطويلة.
📌Note: ترخيص 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 (تشغيل ذاتي) | محلي | البيانات تبقى محلياً |
📌Note: بالنسبة لمعظم حالات استخدام 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.
الأخطاء الشائعة في اختيار نموذج التضمين
- الاختيار بناءً على الدقة المطلقة دون اختبار على مجموعتك. nnomic-embed-text-v2 يهزم bge-large-en-v1.5 على المجموعات متعددة اللغات بـ7 نقاط مئوية رغم تأخر dقة الاسترجاع الكلية. اختبر على عينة من وثائقك الفعلية قبل الالتزام.
- تجاهل الترخيص. ترخيص 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.