أطلقت Google DeepMind Gemini Decision 1 وواجهة برمجة تطبيقات Decisions المخصصة، في محاولة لفصل المهام التقييمية المغلقة الكثيرة في أنظمة الوكلاء — مثل "أي أداة يجب استدعاؤها؟" و"هل تتوافق مع السياسات؟" و"إلى أي نوع من النماذج يجب توجيهها؟" و"ما مدى المخاطر؟" — عن النماذج العامة للإنشاء. يمكن للمطورين إرسال ما يصل إلى 256,000 رمز نصي أو صورة أو صوت أو فيديو أو ملف PDF مرة واحدة، وطرح ما يصل إلى 1000 سؤال مستقل حول نفس المادة؛ لا يولد النموذج شرحًا حرفًا بحرف، بل يعطي مباشرة احتمالات ومستويات ثقة للخيارات في حساب تقدمي واحد. تُظهر Google تأخيرًا طرفيًا نموذجيًا يتراوح بين 150 و250 مللي ثانية، بسعر 0.10 دولار لكل مليون رمز إدخال، مع إخراج مجاني. ومع ذلك، تستند هذه البيانات عن التأخير بشكل أساسي إلى اختبارات لا تتجاوز 16,000 رمزًا وأكثر من 100 سؤال، ولا تثبت أن السرعة ستظل نفسها عند استخدام السياق الكامل و1000 سؤال؛ كما صنّفها التقييم المستقل في المرتبة التاسعة بين 18 نموذجًا للقرار، مما يشير إلى أن قدراته في الضبط والمتعددة الوسائط متميزة، لكنه ليس الفائز الشامل في جميع مهام القرار.مؤلف المقال، المصدر: Google DeepMind
لا يتعين على الوكيل أن يتخذ كل قرار بطريقة "كتابة مقال".
حاليًا، حتى عندما يحتاج العديد من الوكلاء إلى الإجابة بـ"نعم أو لا" فقط، فإنهم يستدعيون نماذج توليد كاملة. تحتاج النماذج إلى قراءة السياق، والتفكير، وإخراج النص حسب الرموز، ثم تقوم التطبيق بتحليل قيمة منطقية أو فئة من الإجابة.
هذه الطريقة مرنة، لكنها مُهدرة في سير العمل عالي التردد. قد يحتاج وكيل خدمة العملاء إلى تقييم نية المستخدم، ومخاطر الحساب، والسياسات المناسبة، وصلاحيات الأدوات، وطابور الترقية، ونموذج الرد بالترتيب؛ كل خطوة تستدعي نموذج توليد، مما يؤدي إلى تراكم التأخير والتكاليف وأخطاء تحليل التنسيق.
يستخدم Gemini Decision 1 نهجًا مختلفًا: حيث يُعرّف المطورون أولًا مجموعة محدودة من الإجابات المحتملة، ويقتصر دور النموذج على تقييم هذه الخيارات فقط. إنه ليس نموذج محادثة، ولا يُعدّ مسودات تفسيرية، بل هو أقرب إلى طبقة عامة للتصنيف والترتيب واتخاذ القرارات الاستراتيجية، قادرة على فهم السياقات الطويلة والمعلومات متعددة الوسائط.
توفر Google ثلاثة أشكال من الأسئلة:
- تقييم "نعم/لا"، إرجاع احتمال تحقق الشرط؛
- اختر من 2 إلى 255 خيارًا، وارجع احتمالات معيارية لكل خيار؛
- تقييم وفقًا لمقياس كمي مُعرَّف مسبقًا، مع إرجاع احتمالات كل درجة ودرجة موزونة.
يأتي كل نتيجة مع ثقة تتراوح بين 0 و1. يمكن للتطبيق تحديد عتبة: تنفيذ تلقائي عند ثقة عالية، أو تحويلها إلى نموذج أقوى أو مراجعة بشرية عند انخفاض الثقة.blog.google
يمكن لمواد واحدة قبول 1000 فحص في نفس الوقت
يمكن أن تحتوي الطلبية الواحدة على ما يصل إلى 256,000 رمز، وتطرح 1000 سؤال مستقل على نفس المدخل.
على سبيل المثال، يمكن للشركات التأمينية تقديم نسخة ممسوحة ضوئيًا من نموذج المطالبة، وصور للأضرار في الموقع، وتسجيلات لمكالمات العملاء، وبيانات الحساب، ثم طلب من النموذج تقييم ما إذا كانت المواد كاملة، وأي نوع من الحوادث تنتمي إليه، وما إذا كانت هناك إشارات احتيال، وأي فريق يجب تعيينها له، ومدى إلحاح معالجتها.
يتم فرض تكلفة واحدة فقط على المواد المشتركة، ويتم إضافة توكينات الأوامر والخيارات فقط لكل سؤال. وبالتالي، عندما تحتاج عشرات الفحوصات إلى قراءة نفس الملف الطويل، فإنه سيكون أكثر اقتصادًا من إرسال الملف مرات عديدة. السعر الرسمي هو 0.10 دولار لكل مليون توكين إدخال، ولا تُفرض أي تكاليف على توكينات الإخراج، ولا توجد رسوم منفصلة لتحويل OCR أو تحويل الصوت إلى نص.
لكن يجب أن تكون هذه الأسئلة الـ1000 مستقلة تمامًا عن بعضها البعض. لن يسمح النموذج للحكم الثاني بقراءة نتيجة الحكم الأول. إذا كان سير العمل هو "تحديد نوع المستند أولاً، ثم تطبيق قواعد مراجعة مختلفة حسب النوع"، فلا يزال على المطورين ربط الخطوتين في الكود، أو استدعاء واجهة برمجة التطبيقات مرة أخرى. عند الحاجة إلى إنشاء نص توضيحي، أو استخراج أي حقل، أو كتابة رد، لا يزال يلزم استخدام نموذج توليد أو استخراج معلومات.
يوجد حدود تطبيق واضحة بين 150 و250 مللي ثانية
قرار Gemini 1 يتجاوز فك الترميز التدريجي للرموز، ويعطي تقييمًا لجميع الخيارات في حساب تقدمي واحد. تشير Google إلى أن متوسط وقت الحساب للنموذج يتراوح بين 50 و100 مللي ثانية، مع تأخير إجمالي يتراوح بين 150 و250 مللي ثانية بعد إضافة خدمات الشبكة.
أظهرت الاختبارات الرسمية أنه عند استخدام مدخلات متعددة الوسائط لا تتجاوز 16,000 رمزًا، فإن زيادة الطلب الواحد من سؤال واحد إلى 100 سؤال لا تؤدي إلى تغيير جوهري في التأخير. وفي نفس المعيار، يُزعم أن تكلفته أقل بخمس مرات تقريبًا مقارنة باستخدام واجهة برمجة تطبيقات Interactions لاستدعاء Gemini 3.5 Flash-Lite.
لا يمكن التعميم المباشر لهذه الأرقام على جميع الحالات. على الرغم من أن النموذج يسمح بـ 256,000 رمز و1000 سؤال، إلا أن Google لم تثبت أن استخدام كلا الحدين الأقصى في نفس الوقت سيؤدي إلى إكمال العملية في غضون 250 مللي ثانية؛ كما أن وقت رفع الفيديوهات الكبيرة والصوت وملفات PDF غير مشمول في وقت حساب النموذج. يجب إعادة قياس الأداء الفعلي أثناء النشر باستخدام طول الملفات وعدد الأسئلة وموقع الشبكة الخاصين بك.
التكامل متعدد الوسائط هو الفرق الرئيسي مقارنةً بالتصنيفات التقليدية
عادةً ما تكون المصنفات التقليدية موجهة لتنسيق بيانات ثابت مسبقًا، بينما يمكن لـ Gemini Decision 1 قراءة النصوص والصور والصوت والفيديو وPDF معًا في نفس الطلب.
قدم المثال الرسمي من قبل النموذج صورة لسطح مساحة الشاي ونصًا توضيحيًا، وسأل عن ثلاثة أمور: ما إذا كانت هناك سوائل غير ممسوحة، وما إذا كان ينبغي مسحها أو طلب خدمة التنظيف، وما مدى خطورة الموقف. قرر النموذج وجود كمية صغيرة من السائل المسكوب، واقترح مسحه بقماش، وقدم احتمالات لكل خيار.
يمكن للمطورين أيضًا خفض دقة الصور أو الفيديوهات لتقليل الرموز والرسوم على حساب بعض التفاصيل. بالنسبة للClaims، ومراجعة المحتوى، أو فحص المنتجات، أو التعرف على أحداث الفيديو، فإن هذا أسهل في التنفيذ من تشغيل OCR وتمييز الصوت والنماذج البصرية ومحركات القواعد بشكل منفصل؛ لكن النموذج الموحّد يعني أنه بمجرد أن يخطئ في فهم المحتوى البصري أو الصوتي، فقد تتأثر عدة قرارات لاحقة في آنٍ واحد.
القيادة في المعيار الرسمي لا تعني التصنيف الأول في التقييم الشامل
تُظهر Google أن Gemini Decision 1 تتفوق في معايير التوجيه والاستدلال والترتيب والفهم متعدد الوسائط، وتحقق أقل خطأ في التوحيد. في المقارنات الرسمية، حقق النموذج 92.2% على JevBench، وهو أعلى من 90.9% لـ GPT‑6 Luna و90.0% لـ Jev 1.14؛ مع خطأ توحيد قدره 0.0250، أي ما يقارب نصف خطأ Jev البالغ 0.0494.
لكنه لا يغطي جميع المهام. تفوق Jev على Gemini بنسبة 86.8% مقابل 86.2% في مهمة تقرير المتصفح Mind2Web Multimodal، كما تفوق عليه بنسبة 82.0% مقابل 79.9% في When2Call عند تحديد متى يجب استدعاء الأدوات.
مؤشر قرار التحليل الاصطناعي المستقل v2.1 منح قرار Gemini 1 درجة 66، واحتل المرتبة التاسعة بين 18 نموذج قرار. وقد تصدر في فئات المعرفة والاستدلال، لكنه حقق فقط 33% من الأوراق التي أجابت بشكل صحيح على جميع الأسئلة في اختبار AA-Paperclip الذي يتطلب فهمًا صحيحًا في نفس الوقت لسيرة ذاتية أو فاتورة أو إيصال أو ورقة بحثية كاملة؛ بينما حقق Drex Max v1.1 63%. كما تأخر في اختبار When2Call المستقل أمام Drex Max و Jev.
هذا يوضح أن "الضبط الجيد للثقة" و"كل حكم دقيق قدر الإمكان" ليسا شيئًا واحدًا. النماذج المُضبطَة جيدًا تفهم بشكل أفضل متى قد تخطئ، مما يساعد في تحديد عتبات المراجعة البشرية؛ لكن إذا تم استخدامها بشكل خاطئ باعتبار أن الثقة العالية ضمانًا للحقيقة، فقد لا تزال تنفذ قرارات خاطئة تلقائيًا.
قمت جوجل أولاً بنشره كطبقة تحكم لمنتج داخلي
لقد استخدمت جوجل هذه الواجهة البرمجية في عدة منتجات. يستخدم Gemini Notebook لتحديد أي نموذج يجب توجيه الاستعلام إليه ومستوى التفكير المناسب، وتدّعي الشركة أن التأخير في الاستعلامات العادية انخفض بنسبة تصل إلى 40٪؛ يستخدمه Stitch للرد بسرعة على التعديلات التصميمية الناتجة عن الصوت أو النقر؛ ويستخدمه Google Labs CC لاختيار ردود من بين أكثر من 200 رمز تعبيري؛ بينما تضعه Google Search قبل استدعاء أدوات MCP لاكتشاف السلوكيات المضادة والمحتوى الخطر.
تُظهر هذه الحالات التحديد الحقيقي: إنه ليس الذكاء الذي يراه المستخدم في النهاية، بل هو مستوى التحكم خلف الوكيل. تُعنى النماذج التوليدية بكتابة الكود وتنظيم اللغة وحل المشكلات المفتوحة؛ بينما تُعنى نماذج اتخاذ القرار بتحديد ما الذي يجب استدعاؤه التالي، وما إذا كان ينبغي السماح بالاستدعاء، وما مدى قوة النموذج المطلوب، ومتى يجب إيقاف الأتمتة وتسليم المهمة للإنسان.
قد يكون هذا التقسيم للعمل أكثر ملاءمة لأنظمة الوكلاء الكبيرة من مجرد توسيع النماذج العامة، لأن العديد من الخطوات اليومية لا تتطلب "الكتابة بشكل أفضل"، بل فقط اختيار الفروع الصحيحة بسرعة وكفاءة وتكلفة منخفضة وبدرجة موثوقة من الناحية الاحتمالية.
يُتاح قرار Gemini 1 حاليًا عبر نقطة النهاية `v1beta` لـ Gemini Developer API، ولا يزال دعم Google Cloud مُشارًا إليه بأنه "قريبًا". لم تُنشر من Google معلمات النموذج، أو بيانات التدريب، أو قوة الحوسبة المستخدمة للتدريب، أو الهيكل المحدد، أو بطاقة النظام الكاملة، لذا لا يمكن تحديد ما إذا كان مستمدًا من نماذج Gemini الحالية، ولا يمكن التحقق بشكل مستقل من ادعاءات الأمان وبيانات التدريب.




