أطلقت Google نموذج Gemini Embedding 2 لـ RAG متعدد الوسائط مع الفيديو والصوت وPDF

أطلقت Google نموذج Gemini Embedding 2 — وهو نموذج تضمين يترجم ليس فقط النصوص، بل أيضًا الصور والصوت والفيديوهات وملفات PDF إلى فضاء متجه واحد. بالنسبة لـ RAG متعدد الأنماط، هذه خطوة مهمة: يمكن لاستعلام واحد الآن أن يجد كل من مقال في قاعدة معارف ومقطع الفيديو المطلوب من فيديو تدريبي.

ما الذي تغيّر في السابق، كان البحث عن أنواع محتوى مختلطة يتم بناؤه من

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

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

هذا يعني أن استعلام نصي مثل "كيفية إعداد التفويض" يمكن أن يطابق ليس فقط التوثيق، بل أيضًا مقطع فيديو ذي صلة أو صورة واجهة أو تعليمات PDF. بالنسبة للفرق التي تحتفظ بالمعرفة في تنسيقات متفرقة، هذا يزيل أحد الحدود الرئيسية لـ RAG الكلاسيكي.

كيفية بناء نظام لكن نموذج التضمين بحد ذاته لا يجعل RAG متعدد الأنماط

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

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

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

أين تكون الاختناقات الحد الرئيسي لم يختفِ في أي مكان: الكائن متعدد

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

استعلام مثل "كيفية إعداد التفويض" يمكن أن يعود ببحث وكل من المقالة

ومقطع الفيديو المطلوب. هذا يترتب عليه متطلبات هندسية: تحتاج إلى التفكير في تقسيم الفيديو والصوت، وتحديث الأوصاف عند استبدال الملفات، وتخزين الرموز الزمنية، والتحكم في التكاليف. يقلل البحث متعدد الأنماط الأصلي من فقدان المعلومات، لكنه لا يزيل الحاجة إلى بيانات جيدة. إذا كانت الأوصاف ضعيفة، فلن يتمكن LLM من تجميع إجابة بثقة حتى مع دقة البحث. لهذا السبب تنكشف القيمة الرئيسية لـ Gemini Embedding 2 حيث تكون الفريق مستعدًا لبناء فهرس كامل، بدلاً من مجرد تحميل الملفات والانتظار للسحر.

ما الذي يعنيه هذا بالنسبة لقواعد المعارف الشركاتية والدعم والتكامل

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