EmbeddingGemma 2 من Google: نموذج ذكاء اصطناعي متعدد الوسائط يعمل على الجهاز ويحوّل البحث بين النصوص والصور والصوت والفيديو

تاريخ النشر: 6 أكتوبر 2026

أعلنت Google DeepMind رسميًا عن EmbeddingGemma 2، وهو جيل جديد من نماذج التضمين المفتوحة المصممة خصيصًا لتشغيل تطبيقات البحث والاسترجاع والذكاء الاصطناعي على الأجهزة المحلية مثل الهواتف والحواسيب والأجهزة الطرفية Edge Devices.

ويأتي هذا الإطلاق بتغيير جوهري مقارنة بالجيل الأول من EmbeddingGemma. فبينما ركز النموذج السابق بصورة أساسية على إنشاء تمثيلات متجهية عالية الجودة للنصوص، يوسع EmbeddingGemma 2 الفكرة إلى عالم متعدد الوسائط، حيث يستطيع النموذج التعامل مع النص، والشيفرة البرمجية، والصور، والفيديو، والصوت، ووضع تمثيلاتها في فضاء متجهي موحد.

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

وهذه النقطة هي التي تجعل الإعلان مهمًا بالنسبة إلى مستقبل البحث المحلي والذكاء الاصطناعي على الهواتف.

ما الذي أعلنت عنه Google بالضبط؟

بحسب Google DeepMind، فإن EmbeddingGemma 2 هو نموذج تضمين متعدد الوسائط مفتوح الأوزان، مبني على تقنيات معمارية من عائلة Gemma 4، ويحتوي في صورته الكاملة على 740 مليون معلمة.

النموذج مصمم لإنشاء تمثيلات متجهية للمحتوى بدلًا من كونه نموذجًا للمحادثة مثل نماذج الدردشة التقليدية. هذه نقطة مهمة جدًا؛ لأن EmbeddingGemma 2 ليس بديلًا مباشرًا لنموذج محادثة مثل Gemini أو ChatGPT.

وظيفته الأساسية تقع في مرحلة مختلفة من نظام الذكاء الاصطناعي: تحويل المعلومات إلى تمثيل رقمي يمكن للبرمجيات مقارنته والبحث من خلاله.

وتقول Google إن النموذج يستطيع وضع النصوص والصور والفيديو والصوت في فضاء متجهي موحد بحجم 768 بُعدًا. وهذا يفتح الباب أمام البحث المتقاطع بين الوسائط، بحيث لا تكون قاعدة البيانات مقسمة بالضرورة إلى عالم للنصوص وعالم للصور وعالم للصوت.

أولًا: ما معنى Embedding أصلًا؟

لفهم أهمية EmbeddingGemma 2، يجب أولًا فهم مصطلح Embedding، أو التضمين المتجهي.

عندما يرى الإنسان صورة لسيارة حمراء، يستطيع أن يفهم فورًا أنها سيارة، وأنها حمراء، وربما يستطيع معرفة أنها متوقفة في شارع أو أنها سيارة رياضية أو شاحنة.

لكن الحاسوب لا يتعامل مع هذه المفاهيم بالطريقة البشرية نفسها. لكي تستطيع الخوارزميات مقارنة المحتوى وفهم درجة التشابه بين الأشياء، يمكن تحويل المحتوى إلى مجموعة طويلة من الأرقام.

هذه المجموعة الرقمية تسمى Vector Embedding.

يمكن تخيلها كإحداثيات لمعلومة داخل فضاء رياضي ضخم.

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

الأمر نفسه يمكن تطبيقه على الصور والصوت وأنواع أخرى من البيانات.

المثير في EmbeddingGemma 2 هو أن Google لا تريد فقط أن تكون صورة قريبة من صورة أخرى، أو نص قريبًا من نص آخر، بل تريد أن يكون بإمكان أنواع مختلفة من البيانات الوصول إلى فضاء متجهي مشترك.

لماذا الفضاء المتجهي المشترك مهم؟

لنفرض أن لديك هاتفًا يحتوي على آلاف الصور ومئات التسجيلات الصوتية وعشرات الفيديوهات.

في نظام تقليدي، قد تكون عملية البحث عن هذه البيانات معتمدة على أسماء الملفات أو البيانات الوصفية أو تحويل الصوت إلى نص ثم البحث في النص الناتج.

أما في نظام متعدد الوسائط يعتمد على EmbeddingGemma 2، فيمكن للتطبيق إنشاء تمثيلات متجهية للمحتوى المختلف ثم مقارنتها.

على سبيل المثال، يمكن نظريًا أن تكتب:

«ابحث عن الفيديو الذي سجلت فيه السيارة الحمراء أمام المنزل.»

أو تستخدم تسجيلًا صوتيًا مرتبطًا بموضوع معين، ثم يبحث النظام عن محتوى مرئي قريب من المعنى الموجود في التسجيل.

هذه ليست مجرد ميزة تجميلية؛ إنها تغير الطريقة التي يمكن بها بناء أنظمة البحث المحلية.

من البحث بالكلمات إلى البحث بالمعنى

البحث التقليدي يعتمد بدرجة كبيرة على المطابقة النصية.

إذا بحثت عن كلمة «هاتف»، فإن النظام يبحث عن نتائج تحتوي على الكلمة أو كلمات مرتبطة بها.

لكن البحث الدلالي Semantic Search يحاول الذهاب إلى مستوى مختلف.

إذا كتبت:

«جهاز محمول ببطارية تدوم طوال اليوم»

فليس من الضروري أن تحتوي الوثيقة أو الصورة المرتبطة بالنتيجة على الجملة نفسها.

المهم هو أن يكون محتوى النتيجة قريبًا من المعنى المقصود.

وهنا تظهر أهمية نماذج التضمين.

EmbeddingGemma 2 لا يحتاج إلى أن يكون النموذج الذي تتحدث معه مباشرة. يمكن أن يكون طبقة خلفية تعمل داخل تطبيق البحث، حيث تقوم بتحويل المحتوى إلى متجهات، ثم تستخدم قاعدة بيانات متجهية للعثور على العناصر الأكثر صلة.

ما الجديد مقارنة بـ EmbeddingGemma الأول؟

أطلقت Google الجيل الأول من EmbeddingGemma بهدف توفير نموذج خفيف وعالي الجودة لإنشاء تضمينات نصية يمكن تشغيلها مباشرة على أجهزة المستهلكين.

وبحسب Google، تجاوز عدد تنزيلات الجيل الأول 20 مليون عملية تنزيل، وهو ما أعطى الشركة أساسًا لتوسيع المشروع إلى المجالات متعددة الوسائط.

لكن EmbeddingGemma 1 كان يركز على النص.

أما EmbeddingGemma 2 فيضيف إلى المنظومة:

• النص.
• الشيفرة البرمجية.
• الصور.
• الفيديو.
• الصوت.

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

كيف يتكون نموذج EmbeddingGemma 2؟

تكشف بطاقة النموذج الرسمية أن إجمالي حجم النموذج يبلغ 740 مليون معلمة.

لكن هذه المعلمات ليست كتلة واحدة يجب استخدامها دائمًا.

يتكون التصميم من:

• 130 مليون معلمة للـ Transformer backbone.
• 140 مليون معلمة لطبقة التضمين.
• 170 مليون معلمة لمشفّر الرؤية Vision Encoder.
• 300 مليون معلمة لمشفّر الصوت Audio Encoder.

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

التصميم المعياري: نقطة مهمة جدًا للمطورين

هذه واحدة من أكثر النقاط أهمية في الإعلان.

لو كان التطبيق يحتاج فقط إلى البحث الدلالي داخل المستندات النصية، فلا يوجد سبب عملي لتحميل مشفر الصور والفيديو والصوت بالكامل.

لذلك يسمح التصميم المعياري باستخدام:

• 270 مليون معلمة تقريبًا للنص فقط.
• نحو 440 مليون معلمة للنص والصورة.
• نحو 570 مليون معلمة للنص والصوت.
• 740 مليون معلمة للنظام متعدد الوسائط بالكامل.

هذا النوع من التصميم مهم جدًا في الأجهزة محدودة الموارد؛ لأن الهاتف لا يمتلك موارد خادم مركز بيانات ضخم.

وكلما استطاع المطور تشغيل الجزء الضروري فقط من النموذج، أمكن تقليل استهلاك الذاكرة والطاقة وزمن الاستجابة.

هل يعمل EmbeddingGemma 2 على الهاتف فعلًا؟

نعم. وهذه إحدى النقاط الرئيسية التي ركزت عليها Google.

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

وتقول Google إن نسخة النموذج بعد التكميم Quantization يمكن أن تعمل على هاتف Google Pixel 11 Pro باستخدام نحو 191 ميغابايت من الذاكرة النشطة عند تشغيل الأوزان النصية فقط، بينما يصل الاستهلاك إلى نحو 567 ميغابايت عند استخدام النموذج متعدد الوسائط بالكامل.

هذه الأرقام مهمة لأنها تعطي صورة أوضح عن الهدف الحقيقي للمشروع.

Google لا تحاول بناء نموذج ضخم يحتاج دائمًا إلى مركز بيانات. بل تحاول دفع جزء من قدرات الذكاء الاصطناعي إلى الجهاز نفسه.

لماذا الذكاء الاصطناعي على الجهاز مهم؟

في نماذج الذكاء الاصطناعي السحابية، عادةً ما تنتقل البيانات من الجهاز إلى الخادم، تتم معالجتها، ثم تعود النتيجة إلى المستخدم.

هذا النموذج له فوائد ضخمة، لكنه يخلق أيضًا مجموعة من القيود:

• الحاجة إلى اتصال بالإنترنت.
• زمن تأخير بسبب إرسال البيانات واستقبال النتائج.
• تكلفة تشغيل الخوادم.
• مشكلات تتعلق بخصوصية بعض البيانات.
• اعتماد التطبيق على خدمة خارجية.

أما المعالجة المحلية، فيمكنها تقليل أو إزالة بعض هذه القيود.

إذا كان الهاتف قادرًا على إنشاء embeddings محليًا، فلا يحتاج كل ملف بالضرورة إلى مغادرة الجهاز من أجل إنشاء التمثيل المتجهي.

الخصوصية: واحدة من أهم فوائد المعالجة المحلية

تخيل تطبيقًا يستخدم الذكاء الاصطناعي للبحث في مكتبة شخصية تحتوي على:

• صور عائلية.
• مذكرات صوتية.
• مقاطع فيديو.
• وثائق شخصية.
• ملفات عمل.

في نظام سحابي، يجب التفكير في كيفية نقل هذه البيانات وحمايتها أثناء المعالجة.

أما عندما تتم عملية التضمين على الجهاز، يمكن للتطبيق الاحتفاظ بالمحتوى محليًا وإنشاء المتجهات محليًا أيضًا.

هذا لا يعني تلقائيًا أن كل تطبيق مبني على EmbeddingGemma 2 سيكون خاصًا أو آمنًا؛ فالمطور هو الذي يقرر أين تُخزن البيانات وكيف يتم إرسالها وما هي البيانات التي تغادر الجهاز.

لكن وجود نموذج يمكن تشغيله محليًا يمنح المطور خيارًا معماريًا مهمًا.

البحث بين النص والصورة

من الاستخدامات المباشرة لـ EmbeddingGemma 2 بناء محرك بحث يمكنه ربط النص بالصور.

تخيل تطبيقًا يحتوي على عشرات الآلاف من الصور.

بدلًا من الاعتماد فقط على أسماء الملفات، يستطيع التطبيق إنشاء embeddings للصور.

بعد ذلك يمكن إنشاء embedding للاستعلام النصي ومقارنته بتمثيلات الصور.

إذا كان المستخدم يبحث عن:

«صورة لشاطئ عند غروب الشمس»

يمكن للنظام البحث في فضاء المتجهات عن الصور الأقرب إلى هذا المعنى.

وهنا لا يحتاج المستخدم بالضرورة إلى معرفة اسم الملف أو المجلد الذي توجد فيه الصورة.

البحث بالصوت داخل الفيديو

هذه من أكثر الحالات التي أبرزتها Google.

يمكن تخيل مستخدم لديه تسجيل صوتي يصف حدثًا أو مشهدًا معينًا، ويريد العثور على فيديو مرتبط به.

إذا كانت التمثيلات المتجهية للصوت والفيديو موجودة في فضاء مشترك، يستطيع نظام الاسترجاع البحث عن العناصر الأقرب دلاليًا.

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

وهذه القدرة يمكن أن تكون مفيدة جدًا في تطبيقات الأرشفة وإدارة الوسائط.

الفيديو لا يُعامل ببساطة كصورة واحدة

الفيديو أكثر تعقيدًا من الصورة لأنه يحتوي على بعد زمني.

لذلك يتعامل EmbeddingGemma 2 مع الفيديو من خلال إطارات Frames يتم أخذ عينات منها، وتوضح وثائق Google أن الإعداد الافتراضي لمعالجة الفيديو يعتمد على أخذ عينة بمعدل إطار واحد في الثانية، مع إمكانية تغيير معدل أخذ العينات.

وهذا مهم لأن الفيديو الطويل قد يحتوي على آلاف الإطارات.

لا يمكن ببساطة إرسال كل شيء إلى النموذج بلا حدود؛ يجب تحقيق توازن بين التفاصيل المطلوبة واستهلاك الموارد.

السياق أصبح أكبر

يأتي EmbeddingGemma 2 مع نافذة سياق تصل إلى 8,192 رمزًا.

وتقول Google إن هذا يمثل زيادة كبيرة مقارنة بالجيل السابق، ويسمح بالتعامل مع مجموعات من النصوص والصور والإطارات والفترات الصوتية ضمن سياق مشترك.

لكن يجب الانتباه إلى أن 8K هنا ليست مجرد عدد كلمات يمكن وضعها في نموذج نصي.

الوسائط المختلفة تستهلك جزءًا من ميزانية السياق.

وفق بطاقة النموذج:

• الصورة الواحدة تستهلك افتراضيًا نحو 280 رمزًا.
• إطار الفيديو يستهلك افتراضيًا نحو 140 رمزًا.
• الصوت يستهلك نحو 25 رمزًا في الثانية.
• النص يستهلك الرموز وفق تقسيمه المعتاد إلى subwords.

لذلك عندما يخلط التطبيق بين النص والصورة والفيديو والصوت، فإن هذه المدخلات تشترك في نافذة السياق نفسها.

ماذا يعني 740 مليون معلمة؟

قد يبدو الرقم كبيرًا، لكنه صغير نسبيًا عند مقارنته بالعديد من نماذج الذكاء الاصطناعي الحديثة.

وهذا مقصود.

EmbeddingGemma 2 ليس مصممًا لكي يكون نموذج محادثة عامًا قادرًا على كتابة المقالات أو إنشاء الصور أو إدارة مهام معقدة.

إنه نموذج متخصص في إنشاء تمثيلات متجهية.

لذلك يمكن لنموذج أصغر بكثير أن يكون مفيدًا جدًا إذا كان مصممًا بكفاءة لمهمة محددة.

وهذه نقطة مهمة في تطور الذكاء الاصطناعي: ليس كل نموذج صغير نموذجًا ضعيفًا، وليس كل نموذج ضخم هو الخيار الأفضل لكل مهمة.

أداء قوي مقارنة بحجمه

بحسب بطاقة النموذج الرسمية، حقق EmbeddingGemma 2 نتائج متعددة في اختبارات النص والشيفرة والصور والفيديو والصوت.

في اختبار MTEB متعدد اللغات سجل النموذج 61.36، مقارنة بـ 61.15 للجيل الأول.

لكن القفزة الأكثر وضوحًا تظهر في مهام الشيفرة البرمجية، حيث ارتفع أداء MTEB Code من 68.76 في EmbeddingGemma 1 إلى 78.68 في EmbeddingGemma 2 وفق الأرقام التي نشرتها Google.

كما تم تقييم النموذج في اختبارات متعددة الوسائط تشمل الصور والوثائق المرئية والفيديو والصوت.

هذا يعني أن Google لا تقدم النموذج باعتباره مجرد نسخة أكبر من نموذج نصي، بل كنظام مصمم منذ البداية للتعامل مع عدة أنواع من البيانات.

ميزة مهمة: Matryoshka Representation Learning

من أكثر الجوانب التقنية إثارة للاهتمام في النموذج دعمه لما يسمى Matryoshka Representation Learning.

الفكرة ببساطة هي أن embedding الناتج لا يجب أن يستخدم دائمًا بكل أبعاده الـ768.

يمكن تقليص التمثيل إلى:

• 768 بُعدًا.
• 512 بُعدًا.
• 256 بُعدًا.
• 128 بُعدًا.

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

وتقول Google إن استخدام تمثيلات أقصر يمكن أن يؤدي إلى تخفيض كبير في تكاليف التخزين، مع الحفاظ على جودة قريبة من الكاملة عند بعض الأحجام، بينما قد يكون الانخفاض إلى 128 بُعدًا أكثر تأثيرًا خصوصًا في المهام متعددة الوسائط.

لماذا تخفيض أبعاد الـEmbedding مهم؟

لنفترض أن شركة لديها ملايين المستندات والصور والفيديوهات.

إذا تم إنشاء متجه مكون من 768 قيمة لكل عنصر، فإن قاعدة البيانات المتجهية يمكن أن تصبح ضخمة جدًا.

لكن إذا كانت المهمة تستطيع العمل بجودة جيدة مع 256 بُعدًا، فإن حجم البيانات المطلوبة لكل عنصر ينخفض بصورة كبيرة.

وهذا يؤثر على:

• تكلفة التخزين.
• سرعة البحث.
• الذاكرة المطلوبة.
• حجم الفهرس.
• كفاءة التطبيقات المحلية.

ولهذا تعتبر Matryoshka Representation Learning أكثر من مجرد ميزة تقنية صغيرة؛ إنها جزء من جعل البحث المتجهي قابلًا للتوسع.

هل يستطيع EmbeddingGemma 2 إنشاء إجابات مثل ChatGPT؟

لا، وهذا توضيح مهم جدًا.

EmbeddingGemma 2 ليس نموذج محادثة عام.

هو لا يُفترض أن تكتب له سؤالًا ثم تنتظر منه مقالًا طويلًا أو إجابة حوارية مثل النماذج التوليدية.

وظيفته مختلفة.

يمكن أن يكون EmbeddingGemma 2 جزءًا من نظام أكبر.

على سبيل المثال:

المستخدم → سؤال → EmbeddingGemma 2 → البحث في قاعدة المعرفة → استرجاع المعلومات → نموذج توليدي → الإجابة.

وهذا هو جوهر كثير من أنظمة RAG أو Retrieval-Augmented Generation.

ما علاقة EmbeddingGemma 2 بـ RAG؟

RAG تعني Retrieval-Augmented Generation.

بدل أن يعتمد النموذج التوليدي على المعلومات التي تعلمها أثناء التدريب فقط، يتم إعطاؤه القدرة على البحث في قاعدة بيانات خارجية قبل إنشاء الإجابة.

هنا يأتي دور embedding.

عندما يقوم المطور بتخزين آلاف المستندات، يمكن تحويلها إلى embeddings.

وعندما يطرح المستخدم سؤالًا، يتم تحويل السؤال نفسه إلى embedding.

بعد ذلك يبحث النظام عن المستندات ذات المتجهات الأقرب إلى سؤال المستخدم.

تُرسل النتائج الأكثر صلة إلى النموذج التوليدي، الذي يستخدمها لإنشاء الإجابة.

ميزة EmbeddingGemma 2 هي أن هذه الطبقة لا تقتصر على النص.

يمكن نظريًا بناء RAG يحتوي على:

• مستندات نصية.
• صور.
• ملفات صوتية.
• مقاطع فيديو.
• شيفرة برمجية.

وهذا يفتح الباب أمام أنظمة RAG متعددة الوسائط تعمل محليًا.

الفرق بين نموذج التضمين والنموذج التوليدي

يمكن تبسيط الفرق بهذه الطريقة:

النموذج التوليدي	نموذج التضمين
ينشئ نصًا أو محتوى جديدًا	ينشئ تمثيلًا رقميًا للمحتوى
يجيب عن الأسئلة	يساعد على العثور على المعلومات
مناسب للمحادثة	مناسب للبحث والاسترجاع والتصنيف
قد يكون كبيرًا جدًا	يمكن أن يكون صغيرًا نسبيًا

ولهذا فإن أهمية EmbeddingGemma 2 لا تأتي من قدرته على استبدال ChatGPT أو Gemini، وإنما من قدرته على أن يكون طبقة بحث وفهم دلالي داخل التطبيقات.

البحث في الصور بدون كتابة وصف يدوي

إحدى المشكلات القديمة في تنظيم الصور هي الحاجة إلى البيانات الوصفية.

إذا كان لديك 100 ألف صورة، فإن إنشاء وصف يدوي لكل صورة عملية غير عملية.

النماذج متعددة الوسائط يمكنها تحويل المحتوى المرئي إلى تمثيل يمكن استخدامه في البحث.

وبالتالي يمكن للتطبيق إنشاء فهرس للصور عند إضافتها، ثم استخدام استعلامات طبيعية للبحث عنها لاحقًا.

بدلًا من:

IMG_48392.jpg

يمكن أن يصبح البحث أقرب إلى:

«صور رحلة فيها جبال وثلوج».

وكلما تطورت جودة التمثيلات، أصبحت إمكانية البحث الدلالي أكثر فائدة.

البحث في التسجيلات الصوتية

الصوت مجال آخر يمكن أن يستفيد كثيرًا.

تخيل أرشيفًا يحتوي على آلاف التسجيلات الصوتية.

الحل التقليدي قد يتطلب تحويل التسجيلات إلى نص أولًا باستخدام نظام Speech-to-Text، ثم إجراء البحث في النص الناتج.

لكن EmbeddingGemma 2 يمكنه إنشاء embeddings للصوت مباشرة.

وهذا لا يعني أن النظام يلغي الحاجة دائمًا إلى Speech-to-Text، ولكنه يوفر طريقة مختلفة للوصول إلى المحتوى الصوتي واسترجاعه.

وبالنسبة لبعض التطبيقات، يمكن أن يؤدي ذلك إلى تبسيط بنية النظام.

البحث في الفيديو

الفيديو يمثل تحديًا أكبر لأنه يجمع بين الصورة والحركة والصوت والزمن.

ومن هنا تأتي أهمية النموذج متعدد الوسائط.

يمكن للتطبيق تحليل أجزاء من الفيديو وإنشاء تمثيلات يمكن البحث فيها.

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

وهذا مفيد في:

• إدارة مكتبات الفيديو.
• الأرشيف الإعلامي.
• البحث داخل المحتوى التعليمي.
• التطبيقات الأمنية المشروعة.
• إدارة المحتوى الرقمي.
• أنظمة البحث داخل مكتبات الشركات.

دعم أكثر من 100 لغة

تقول Google إن EmbeddingGemma 2 يدعم أكثر من 100 لغة، مع اعتماد بيانات تدريب واسعة متعددة اللغات. وتشير بطاقة النموذج إلى أن بيانات التدريب النصية شملت أكثر من 140 لغة، مع بيانات أخرى خاصة بالصور والفيديو والصوت.

وهذه النقطة مهمة لأن البحث الدلالي متعدد اللغات يمكن أن يكون أكثر تعقيدًا من البحث داخل لغة واحدة.

فإذا كتب المستخدم سؤالًا بالعربية وكانت الوثيقة بالإنجليزية، فإن النموذج يحتاج إلى تمثيل المعنى بطريقة تسمح بالمقارنة بين اللغتين.

وهنا يمكن أن تصبح النماذج متعددة اللغات مفيدة في بناء تطبيقات عالمية.

ماذا عن الشيفرة البرمجية؟

الشيفرة البرمجية مدعومة أيضًا ضمن مسار النص.

وهذا مهم للمطورين الذين يريدون بناء محركات بحث ذكية داخل مستودعات Git أو قواعد شيفرة محلية.

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

والتحسن الذي أظهره EmbeddingGemma 2 في معيار MTEB Code مقارنة بالجيل الأول يلفت الانتباه بشكل خاص إلى هذا الاستخدام.

Zero-shot Classification: استخدام آخر مهم

لا يقتصر النموذج على البحث.

توضح Google أن EmbeddingGemma 2 يمكن استخدامه أيضًا في التصنيف دون الحاجة إلى تدريب نموذج تصنيف خاص بكل مهمة.

الفكرة بسيطة.

يمكن تحويل المحتوى إلى embedding، وتحويل مجموعة من التصنيفات أو الأوصاف إلى embeddings، ثم قياس التشابه.

مثلًا، يمكن أن تكون التصنيفات:

• أخبار تقنية.
• أخبار رياضية.
• أخبار اقتصادية.
• محتوى تعليمي.

ثم يمكن للنظام تحديد الفئة الأقرب للمحتوى.

هذه القدرة يمكن أن تكون مفيدة جدًا للتطبيقات التي تحتاج إلى تصنيف سريع محليًا.

الذكاء الاصطناعي الطرفي Edge AI

إطلاق EmbeddingGemma 2 يرتبط باتجاه أكبر في صناعة الذكاء الاصطناعي يسمى Edge AI.

الفكرة هي نقل بعض عمليات الذكاء الاصطناعي من مراكز البيانات إلى الأجهزة الموجودة بالقرب من المستخدم.

هذه الأجهزة قد تكون:

• الهواتف الذكية.
• الحواسيب المحمولة.
• الكاميرات الذكية.
• الأجهزة المنزلية.
• السيارات.
• الأجهزة الصناعية.
• الأجهزة القابلة للارتداء.

كلما أصبحت النماذج أصغر وأكثر كفاءة، أصبح بالإمكان تشغيل المزيد من الذكاء الاصطناعي مباشرة على هذه الأجهزة.

هل هذا يعني نهاية الذكاء الاصطناعي السحابي؟

بالتأكيد لا.

الأرجح أن المستقبل سيكون هجينًا.

المهام الصغيرة والحساسة للخصوصية أو التي تحتاج إلى استجابة فورية يمكن تنفيذها محليًا.

أما المهام الضخمة التي تحتاج إلى نماذج توليدية كبيرة جدًا، فقد تستمر في الاعتماد على السحابة.

وبالتالي يمكن تصور نظام يجمع الاثنين:

الجهاز المحلي → البحث الأولي → تحديد المعلومات المهمة → إرسال الجزء الضروري فقط إلى السحابة → إنشاء الإجابة النهائية.

وهذا يمكن أن يقلل كمية البيانات التي يتم إرسالها إلى الخادم.

ما الذي يعنيه ذلك لمطوري تطبيقات الهواتف؟

المطور الذي يريد بناء تطبيق بحث ذكي لا يحتاج بالضرورة إلى إنشاء بنية سحابية ضخمة منذ البداية.

يمكن استخدام EmbeddingGemma 2 لبناء طبقة محلية للتضمين والبحث.

على سبيل المثال، يمكن أن يكون هناك تطبيق لإدارة الصور الشخصية.

عند إضافة صورة جديدة، يتم إنشاء embedding محليًا.

عند كتابة المستخدم استعلامًا، يتم إنشاء embedding للاستعلام نفسه، ثم يتم البحث في الفهرس المحلي.

وبذلك يمكن أن تحدث عملية البحث بسرعة ومن دون إرسال مكتبة الصور كاملة إلى خادم خارجي.

لكن هناك تحديات مهمة

رغم أهمية الإعلان، لا ينبغي التعامل مع EmbeddingGemma 2 على أنه حل سحري لكل مشاكل البحث متعدد الوسائط.

هناك عدة قيود يجب أخذها بعين الاعتبار.

1. جودة embedding لا تعني فهمًا بشريًا كاملًا

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

إذا كانت المهمة تحتاج إلى معرفة دقيقة جدًا بمعلومة صغيرة داخل صورة، يجب اختبار الأداء على البيانات الحقيقية للتطبيق.

2. الفيديو الطويل يمثل تحديًا

الفيديوهات الطويلة لا يمكن التعامل معها بلا حدود ضمن نافذة السياق.

يحتاج المطور إلى اختيار طريقة تقسيم الفيديو وأخذ العينات المناسبة.

3. الموارد محدودة على الأجهزة

رغم أن النموذج خفيف نسبيًا، فإن تشغيل النموذج الكامل ليس مجانيًا من ناحية الذاكرة والطاقة.

ولهذا توفر البنية المعيارية إمكانية تحميل الأجزاء المطلوبة فقط.

4. جودة اللغات ليست بالضرورة متساوية

دعم أكثر من 100 لغة لا يعني أن النموذج يقدم الجودة نفسها في كل لغة وفي كل نوع من المهام.

يجب على المطور اختبار اللغة والمجال الذي يستهدفه.

5. التضمين ليس قاعدة بيانات

EmbeddingGemma 2 ينشئ المتجهات، لكنه لا يحل وحده كل مشكلة تخزين واسترجاع.

يحتاج التطبيق إلى آلية فهرسة وبحث مناسبة، مثل قاعدة بيانات متجهية أو نظام استرجاع محلي.

الترخيص: نقطة مهمة للشركات

أصدرت Google النموذج تحت ترخيص Apache 2.0، وهو ترخيص مفتوح يسمح بمجموعة واسعة من الاستخدامات بما فيها الاستخدامات التجارية، مع الالتزام بشروط الترخيص.

وهذا يجعل النموذج جذابًا للشركات والمطورين الذين يريدون بناء منتجات تعتمد على التضمين المحلي بدلًا من الاعتماد الكامل على API مغلق.

ومع ذلك، يجب على كل شركة مراجعة شروط الترخيص وسياسات Gemma ومتطلبات التطبيق الخاص بها قبل إدخال النموذج في منتج تجاري.

ماذا عن استهلاك التخزين؟

هنا تظهر ميزة التكميم وتقليل أبعاد المتجهات.

ليس المهم فقط حجم النموذج نفسه، بل أيضًا حجم البيانات التي سينتجها النموذج.

تطبيق لديه مليون ملف يمكن أن ينشئ مليون embedding.

إذا كان كل embedding كبيرًا، يصبح الفهرس نفسه مشكلة.

أما إذا استطاع المطور استخدام أبعاد أصغر مع الحفاظ على جودة مناسبة، فيمكن تخفيض حجم قاعدة البيانات بشكل كبير.

وهذه نقطة تجعل دعم Matryoshka Representation Learning مهمًا جدًا في التطبيقات التي تعمل على نطاق واسع.

هل يمكن استخدامه دون الإنترنت؟

الهدف الأساسي من النموذج هو دعم الاستخدام المحلي على الجهاز، ولذلك يمكن بناء تطبيقات لا تحتاج إلى اتصال دائم بالخادم لإنشاء embeddings.

وهذا لا يعني أن كل تطبيق يستخدم EmbeddingGemma 2 سيعمل تلقائيًا دون إنترنت؛ فذلك يعتمد على بنية التطبيق وما إذا كان يستخدم خدمات خارجية أخرى.

لكن النموذج نفسه مصمم لتوفير طبقة ذكاء محلية.

أين يمكن للمطورين الحصول عليه؟

أعلنت Google عن إتاحة EmbeddingGemma 2 عبر قنواتها ومجتمع النماذج المفتوحة، بما في ذلك Hugging Face وKaggle وGoogle AI Edge. كما توفر Google وثائق وبطاقة نموذج رسمية توضّح البنية وطرق الاستخدام والقيود.

لماذا يعتبر الإطلاق مهمًا لصناعة الذكاء الاصطناعي؟

أهمية EmbeddingGemma 2 لا تكمن فقط في رقم 740 مليون معلمة.

الأهم هو الاتجاه الذي يمثله.

الذكاء الاصطناعي كان لفترة طويلة مرتبطًا بالنماذج السحابية الضخمة.

ثم بدأت الصناعة تنتقل تدريجيًا إلى نماذج أصغر قادرة على العمل محليًا.

لكن المرحلة الجديدة ليست فقط تشغيل نموذج لغوي صغير على الهاتف.

المرحلة التالية هي جعل الجهاز قادرًا على فهم وفهرسة وربط أنواع مختلفة من المعلومات.

وهنا يأتي EmbeddingGemma 2.

من الهاتف الذكي إلى جهاز يفهم محتواه

يمكن تخيل مستقبل يكون فيه الهاتف أكثر قدرة على فهم مكتبته المحلية.

بدل وجود مجلدات تحتوي على آلاف الصور والفيديوهات والتسجيلات، يمكن أن يصبح المحتوى قابلًا للبحث بطريقة أقرب إلى السؤال الطبيعي.

تقول:

«أرني الصور التي التقطتها في مكان فيه جبال.»

أو:

«ابحث عن التسجيل الذي تحدثت فيه عن مشروع معين.»

أو:

«اعثر على الفيديو الذي يظهر فيه المنتج أثناء الاختبار.»

هذه التطبيقات لا تتطلب بالضرورة نموذج محادثة عملاقًا.

تحتاج إلى تمثيل جيد للمحتوى ومحرك بحث قادر على التعامل مع تلك التمثيلات.

ماذا يمكن أن يحدث في السيارات؟

يمكن أن يكون Edge AI مهمًا جدًا في السيارات.

السيارة الحديثة تحتوي على كميات متزايدة من البيانات القادمة من الكاميرات وأجهزة الاستشعار والأنظمة الصوتية.

وجود نماذج خفيفة قادرة على إنشاء تمثيلات محلية يمكن أن يساعد في بناء أنظمة بحث وتصنيف وربط للمعلومات دون إرسال كل شيء إلى السحابة.

لكن التطبيقات المتعلقة بالسلامة والقيادة تحتاج إلى متطلبات تحقق واعتمادية أعلى بكثير من مجرد تشغيل نموذج embedding.

ماذا يمكن أن يحدث في الروبوتات؟

الاتجاه نفسه مهم في الروبوتات.

الروبوت قد يتعامل مع:

• صور من الكاميرات.
• أوامر صوتية.
• بيانات نصية.
• مقاطع فيديو.
• بيانات بيئية.

وجود فضاء تمثيلي موحد يمكن أن يساعد في ربط بعض هذه المدخلات.

لكن يجب التأكيد أن EmbeddingGemma 2 وحده ليس نظام تحكم للروبوت ولا نموذجًا للقيادة الذاتية. هو طبقة يمكن أن تدخل ضمن منظومة أكبر.

ماذا يعني ذلك للمؤسسات والشركات؟

الشركات لديها مشكلة متزايدة: كمية البيانات أكبر من قدرة الموظفين على البحث فيها يدويًا.

هناك:

• ملفات PDF.
• وثائق داخلية.
• صور.
• عروض تقديمية.
• تسجيلات اجتماعات.
• فيديوهات تدريبية.
• شيفرات برمجية.

تقليديًا، كانت هذه الأنواع من البيانات تعالج بأنظمة مختلفة.

أما نموذج متعدد الوسائط، فيمكن أن يساعد في بناء طبقة بحث موحدة.

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

هل يمكن أن يغير RAG على الأجهزة؟

ربما يكون هذا أحد أهم الآثار طويلة المدى.

معظم النقاش حول RAG يركز على الخوادم السحابية.

لكن إذا أصبحت نماذج embedding القوية صغيرة بما يكفي للعمل على الأجهزة، يمكن بناء On-device RAG.

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

ويقوم نموذج embedding بفهرسة المعلومات، بينما يقوم نموذج لغوي محلي أو سحابي بإنتاج الإجابة.

هذا قد يسمح بتطبيقات ذكاء اصطناعي أكثر خصوصية وأقل اعتمادًا على الاتصال الدائم بالإنترنت.

أين تكمن النقلة الحقيقية؟

النقلة الحقيقية ليست أن Google أضافت الصور والصوت إلى نموذج جديد.

النقلة هي محاولة جعل المعنى نفسه قابلًا للمقارنة عبر أنواع مختلفة من البيانات.

في العالم التقليدي:

النص → نظام نصي

الصورة → نظام رؤية

الصوت → نظام صوت

الفيديو → نظام فيديو

أما في نموذج متعدد الوسائط مثل EmbeddingGemma 2:

النص + الصورة + الصوت + الفيديو → فضاء تمثيلي مشترك.

وهذا يقلل التعقيد في بعض أنواع التطبيقات.

لكن يجب عدم المبالغة في الخبر

هناك نقطة مهمة جدًا عند قراءة الإعلان.

قول Google إن EmbeddingGemma 2 يستطيع ربط النص والصورة والصوت والفيديو لا يعني أن النموذج «يفهم كل شيء» بمعنى بشري شامل.

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

كما أن جودة النظام النهائي تعتمد على البيانات، وطريقة الفهرسة، وطريقة اختيار العينات، وجودة الاستعلام، واحتياجات التطبيق.

ماذا تقول النتائج الرسمية عن النموذج؟

وفق بطاقة النموذج الرسمية، حصل EmbeddingGemma 2 على نتائج في عدة فئات من الاختبارات، منها:

• MTEB للنصوص متعددة اللغات.
• MTEB للشيفرة البرمجية.
• MIEB للصور.
• MMEB للصور والوثائق المرئية.
• MMEB للفيديو.
• MSEB للصوت.

وهذا يعكس اتساع نطاق النموذج مقارنة بالجيل الأول الذي كان موجهًا أساسًا إلى التضمين النصي.

هل 740 مليون معلمة كافية؟

هذا السؤال يعتمد على المهمة.

إذا كان الهدف هو إنشاء نموذج محادثة ينافس أكبر النماذج التوليدية، فلا يمكن الاستدلال من 740 مليون معلمة على ذلك.

لكن إذا كان الهدف هو إنشاء embeddings فعالة للبحث والاسترجاع، فإن حجم النموذج ليس المقياس الوحيد.

المهم هو:

• جودة التمثيلات.
• جودة المحاذاة بين الوسائط.
• الأداء على المهمة المستهدفة.
• استهلاك الذاكرة.
• زمن الاستجابة.
• حجم النموذج.
• تكلفة الفهرسة والبحث.

ولهذا يمكن لنموذج أصغر ومتخصص أن يكون أفضل عمليًا من نموذج ضخم في تطبيق محدد.

ماذا يعني هذا للمستخدم العادي؟

المستخدم العادي قد لا يسمع باسم EmbeddingGemma 2 داخل التطبيق الذي يستخدمه مستقبلًا.

لأن embedding غالبًا يعمل في الخلفية.

قد يرى المستخدم فقط ميزة مثل:

«ابحث في الصور»

أو:

«ابحث في الفيديوهات باستخدام سؤال طبيعي»

أو:

«اعثر على تسجيل صوتي معين»

لكن خلف هذه الواجهة البسيطة يمكن أن توجد طبقة embeddings تقوم بتحويل المحتوى إلى متجهات ومقارنتها.

ماذا يعني هذا لمستقبل البحث؟

قد يتحول البحث تدريجيًا من البحث في أسماء الملفات والكلمات المفتاحية إلى البحث في المعنى والسياق.

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

قد يكون الاستعلام نصًا والنتيجة صورة.

وقد يكون الاستعلام صوتًا والنتيجة فيديو.

وقد تكون البيانات المخزنة خليطًا من النصوص والصور والمقاطع الصوتية والفيديوهات.

هذه هي الفكرة الأساسية وراء الفضاء المتجهي المشترك.

الجانب الاقتصادي

تشغيل البحث على الجهاز يمكن أن يغير اقتصاد بعض التطبيقات.

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

أما إذا تم إنشاء embeddings محليًا، يمكن تقليل الاعتماد على الخادم في بعض العمليات.

هذا لا يعني أن تشغيل النموذج محليًا مجاني؛ فهناك تكلفة مرتبطة بالطاقة والذاكرة والتخزين والتطوير، لكن توزيع العمل بين الجهاز والسحابة يمكن أن يغير نموذج التكلفة.

الجانب الأمني والخصوصية

هناك أيضًا سؤال مهم: هل embedding نفسه آمن؟

لا ينبغي اعتبار المتجهات بيانات غير حساسة تلقائيًا.

إذا كانت embeddings تمثل محتوى شخصيًا أو مؤسسيًا، فيجب تصميم النظام بطريقة مناسبة لحماية البيانات والوصول إليها.

وتشير Google نفسها في بطاقة النموذج إلى ضرورة تطبيق المطورين لإجراءات حماية مناسبة، واختبار الانحياز، ووضع ضوابط على كيفية استخدام التمثيلات الناتجة.

الخلاصة: لماذا يستحق EmbeddingGemma 2 الاهتمام؟

إطلاق EmbeddingGemma 2 يمثل خطوة مهمة في اتجاه الذكاء الاصطناعي المحلي ومتعدد الوسائط.

النموذج ليس نموذج محادثة جديدًا ينافس Gemini أو ChatGPT مباشرة، وليس الهدف منه كتابة المقالات أو إنشاء الصور. قوته في مكان مختلف: تحويل أنواع متعددة من البيانات إلى تمثيلات متجهية يمكن مقارنتها والبحث فيها.

ويتميز النموذج بعدة نقاط رئيسية:

• 740 مليون معلمة في صورته متعددة الوسائط الكاملة.
• دعم النص والشيفرة والصور والفيديو والصوت.
• فضاء embedding موحد بحجم 768 بُعدًا.
• نافذة سياق تصل إلى 8K tokens.
• تصميم معياري يسمح بتحميل مكونات الرؤية والصوت عند الحاجة.
• إمكانية العمل على الأجهزة المحلية.
• دعم تقنيات تقليل أبعاد embeddings عبر Matryoshka Representation Learning.
• دعم أكثر من 100 لغة.
• ترخيص Apache 2.0.
• إمكانية استخدامه في البحث الدلالي وRAG والتصنيف والتجميع واسترجاع المحتوى.

وتبرز الأرقام الرسمية أيضًا تحسنًا واضحًا في بعض المجالات مقارنة بالجيل الأول، خصوصًا في مهام الشيفرة، إلى جانب إضافة قدرات جديدة في الصور والفيديو والصوت.

الحكم النهائي

EmbeddingGemma 2 ليس مجرد تحديث لـ EmbeddingGemma، بل توسعة لفكرة مهمة: جعل البحث الدلالي متعدد الوسائط ممكنًا على الأجهزة الصغيرة نسبيًا.

إذا نجح المطورون في استغلاله بالشكل الصحيح، فقد تظهر تطبيقات تستطيع البحث في مكتبات الصور والفيديو والصوت والوثائق من دون الحاجة إلى إرسال كل البيانات إلى السحابة.

والأهم أن Google اختارت أن تجعل النموذج مفتوح الأوزان وتوفره ضمن منظومة Gemma وGoogle AI Edge، ما يسمح للمطورين والباحثين بتجربة هذه الفكرة وبناء تطبيقات جديدة فوقها.

لذلك فإن أهمية EmbeddingGemma 2 لا تكمن فقط في عدد المعلمات، بل في الاتجاه الذي يمثله: انتقال الذكاء الاصطناعي من مجرد توليد النصوص إلى تنظيم وفهم وربط كل أنواع البيانات، وبشكل متزايد مباشرة على الجهاز الذي يستخدمه الإنسان.

ومع استمرار تطور نماذج Edge AI، قد تصبح القدرة على البحث في المحتوى الشخصي بالصوت والصورة والنص والفيديو ميزة عادية داخل الهواتف والحواسيب، بدل أن تكون تقنية تعتمد بالكامل على مراكز البيانات السحابية.

وبهذه الصورة، يمكن اعتبار EmbeddingGemma 2 أحد النماذج التي تعكس تحولًا أوسع في الصناعة: المستقبل ليس فقط في نماذج أكبر، بل أيضًا في نماذج أصغر وأكثر تخصصًا وكفاءة تستطيع العمل بالقرب من المستخدم.

المصادر الرسمية

تم التحقق من المعلومات الأساسية في هذا المقال بالاعتماد على إعلان Google الرسمي، ومدونة Google AI Edge، وبطاقة نموذج EmbeddingGemma 2 الرسمية من Google AI for Developers.

وتشير المصادر الرسمية إلى أن النموذج أُعلن عنه في 6 أكتوبر 2026، وأنه نموذج مفتوح متعدد الوسائط بقدرة على تضمين النصوص والصور والفيديو والصوت في فضاء متجهي موحد، مع 740 مليون معلمة في التكوين الكامل.