النقاط الرئيسية
- 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 مقارنةً بوثائق اللغة الطبيعية. لا أحد منها مُضمِّن كود حقيقي — لمجموعات الكود الثقيلة، فكر في الجمع مع نماذج كود متخصصة.
- الدعم متعدد اللغات ليس مجانياً. المضمِّنات الإنجليزية الصرفة (bge-large-en-v1.5 وgte-large وmxbai-embed-large-v1) تخسر 10–15 نقطة مئوية على النص متعدد اللغات. للوثائق الألمانية/الفرنسية/اليابانية/العربية، استخدم jina-embeddings-v3 أو nomic-embed-text-v2 أو BAAI/bge-m3.
- تغيير نموذج التضمين يفرض إعادة فهرسة كاملة على جميع منصات 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 رمز) |
أي نموذج تضمين يجب أن تختار؟
مجموعتك ومتطلبات اللغة وقيد الأجهزة تحدد النموذج الصحيح؛ الدقة المطلقة نادراً ما تُحسم الأمر. ابحث عن السطر الذي يناسب وضعك.
| إذا كانت حالتك | استخدم هذا |
|---|---|
| مجموعة متعددة اللغات أو مختلطة | 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 لأي مجموعة تتضمن محتوى غير إنجليزي.
ملفات كل نموذج
ملخص سريع لكل نموذج: نقاط قوته والسيناريو الذي يتفوق فيه.
- jina-embeddings-v3 (Jina AI): الاختيار متعدد الأغراض. 92% retrieval@10 كلياً، دعم أصلي متعدد اللغات، أبعاد Matryoshka 1024→512→256. الترخيص CC BY-NC 4.0 (غير تجاري — تحقق قبل الاستخدام التجاري).
- 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-2 أو نسخة مضبوطة دقيقة) واستخدم النموذج الأعلى نقاطاً لـchunks الكود. النهج الأبسط: ضمِّن كل شيء أولاً بـjina-embeddings-v3، واختبر retrieval@10 على مجموعة محجوزة، وبدّل فقط إذا انخفض دون العتبة.
كم يجب أن أُحدّث نموذج التضمين؟
عند نشر نموذج جديد يُصدر معايير على بيانات مشابهة لمجموعتك، وعندما تمتلك أرقام 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) جميعها تستخدم مخازن متجهات مختلفة؛ حتى لو كان المُضمِّن نفسه، مخطط البيانات الوصفية مختلف. عملياً، كل تبديل منصة هو أيضاً تشغيل إعادة فهرسة. خطط وفقاً لذلك: اختر المُضمِّن لجودة الاسترجاع، واختر المنصة لكل شيء آخر.