جوجل تطلق gemini-decision-1: نموذج يعيد احتمالات بدل النص خلال 150–250 مللي ثانية

مشهد مألوف: عليك أن تقرر في أي قائمة انتظار تضع طلب العميل. تأخذ نموذجًا لغويًا كبيرًا، وتطلب منه «الرد بصيغة JSON»، وتنتظر حتى يولّد النص رمزًا بعد رمز، ثم تحلّل الرد وتدعو ألا يضيع قوس ما. كل ذلك من أجل قرار واحد من نوع «الفرع أ أم الفرع ب». أصدرت جوجل أداة تزيل هذه الطبقة بالكامل.

ما الذي أُطلق بالضبط

يُسمّى النموذج gemini-decision-1، وهو متاح كنقطة وصول مستقلة، وما زال في المعاينة ضمن AI Studio. الفارق الرئيسي عن Gemini المعتاد أنه لا يولّد رموزًا إطلاقًا. بدلًا من ذلك يقيّم خيارات الإجابة في مرور أمامي واحد (forward pass) ويعيد احتمالات. رموز الإخراج صفر، ويمكن للكود أن يتفرّع مباشرة بحسب الأرقام.

يمكن تقديم نص وصور وصوت وفيديو وملفات PDF كمدخلات، بإجمالي يصل إلى 262,144 رمزًا. ويُسمح بطرح ما يصل إلى 1000 سؤال مستقل على مدخل واحد. والأسئلة من ثلاثة أنواع:

• نعم/لا، والإجابة في المدى 0.01–0.99؛
• اختيار من 2 إلى 255 خيارًا؛
• تقييم وفق معيار (rubric) مع متوسط مرجّح.

الأسئلة لا ترى بعضها، ولذلك لا تؤثر الإجابات على بعضها. ووفق بيانات الإعلان، لا يكاد زمن الاستجابة يزداد: 50–100 مللي ثانية للنموذج نفسه و150–250 مللي ثانية من البداية إلى النهاية، سواء لسؤال واحد أو لمئة سؤال.

كيف يبدو ذلك في مثال

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

• «هل هذه مشكلة دفع؟» — نعم/لا؛
• «إلى أي فريق تُحوَّل؟» — اختيار من خمسة خيارات؛
• «ما مدى الاستعجال وفق المعيار؟» — تقييم حسب المعايير.

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

ونموذج الدفع لطيف أيضًا. تدفع مقابل المدخل المشترك مرة واحدة، وكل سؤال يضيف تعليماته ومعاييره فقط. لا فواتير منفصلة لرموز التفكير (thinking) ولا لتفريغ الصوت ولا لـ OCR. السعر: 0.10 دولار لكل مليون رمز إدخال و0 دولار للإخراج. وفي المستوى المجاني يتوفر 200 طلب في الدقيقة و50 ألف رمز في الدقيقة و10,000 طلب في اليوم. وفي Tier 1 ترتفع الحدود إلى 1,500 RPM و1M TPM، وفي Tier 3 إلى 15,000 RPM و10M TPM.

لمن هذا وأين الفخ

يصف كاتب التحليل الأصلي هذا بأنه أكثر أنواع الإصدارات التي لا تُقدَّر حق قدرها، ويراهن على الوكلاء (agents). فإذا كانت لديك سلسلة من عشر خطوات وعليك في كل خطوة اختيار أداة، فإن التوفير، بحسب تقديره، لا يُقاس بالنسب المئوية بل بمرتبة كاملة: زمن استجابة أقل، ومال أقل، ولا تحليل. هذا تقدير كاتب المنشور وليس اختبار أداء مقيسًا، لكن المنطق مفهوم. فكثير من استدعاءات LLM في الإنتاج هي في جوهرها مصنِّفات: توجيه، وإشراف على المحتوى، ومرشحات، وفرز أولي (triage)، وتقييم بقائمة تحقق. وبالنسبة لها لم يكن توليد النص سوى وسيط.

الآن القيود.

• هذه معاينة. قد تتغير الحدود والأسعار وسلوك النموذج قبل الإصدار.
• لا يدعم Batch API ولا تخزين السياق مؤقتًا. وإن كان لديك سياق كبير متكرر، كتعليمات طويلة أو قاعدة معرفة، فسيتعيّن عليك دفع ثمنه في كل مرة.
• لا توجد في الوصف مقاييس جودة. ولا يُعرف مدى جودة معايرة الاحتمالات، ولا كيف يتعامل النموذج مع الصياغات الدقيقة للمعايير. وإذا كنت ستتخذ قرارًا ذا عواقب قانونية أو مالية عند عتبة 0.7، فتحقّق أولًا من المعايرة على بياناتك.
• هذه نقطة وصول من جوجل، لذا يبقى الارتباط بالمزوّد قائمًا.

ماذا تفعل عمليًا

دوّن استدعاءات LLM لديك وحدّد تلك التي ينتهي فيها الرد إلى تسمية أو علامة أو رقم. هذه هي أولى المرشحات. اجمع عينة موسومة من بضع مئات من الأمثلة، ومرّرها عبر المستوى المجاني في AI Studio، وقارن الدقة وزمن الاستجابة بحلّك الحالي. إذا لم تكن الجودة أسوأ وانخفض التأخير إلى 150–250 مللي ثانية، فمن المجدي نقل التوجيه والإشراف على المحتوى إلى هنا. أما توليد النص للمستخدم فاتركه بالطبع للنماذج المعتادة.