واجهة برمجة تطبيقات Decisions API من Google تجيب عن 1,000 سؤال ولا تفرض رسومًا على المخرجات

الجزء الأرخص من Gemini Decision 1 هو الجزء الذي لا وجود له. وضعت Google النموذج خلف Gemini Decisions API جديد في 11 نوفمبر 2026، وتُدرج صفحة التسعير المخرجات بسعر صفر — ليس رخيصًا، ولا مخفّضًا، بل غائبًا، لأن POST /v1beta/decisions لا يحتوي على نص نثري لتوليده. تُرسل كتلة واحدة من المدخلات المشتركة بالإضافة إلى ما يصل إلى 1,000 سؤال محدد النوع؛ فتحصل على إجابة معايرة واحدة لكل سؤال ولا شيء غير ذلك. حصل رقم لوحة الصدارة على الانتباه يوم الإطلاق. بند الفوترة هو الذي يغيّر ما تبنيه، ويستحق إجراء الحسابات قبل أن تنسخ مخطط بنية أي شخص.

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

ماذا تفعل رموز الإخراج الصفرية بالحساب؟

تخيّل مهمة واقعية لتقييم المستندات: سياسة أو عقد من 40,000 رمز، و1,000 سؤال تريد الإجابة عنها. طلب واحد إلى Decisions API يفوتر 40,000 رمز إدخال مرة واحدة، بسعر $0.10 لكل مليون، أي أربعة أعشار السنت — $0.004 لجميع الإجابات الألف.

الآن اطرح الأسئلة الـ1,000 نفسها بالطريقة التي كنت ستطرحها بها قبل أسبوع، في صورة 1,000 استدعاء منفصل لـ generate-content. يجب أن يحمل كل استدعاء المستند، لأن نقطة نهاية محادثة لا تملك وسيلة للاحتفاظ به عبر الاستدعاءات. هذا يعني 40 مليون رمز إدخال، أو $4.00 بالمعدل نفسه لكل رمز، وتتسع الفجوة بمجرد إضافة رموز الإخراج التي كان كل من تلك الاستدعاءات سينتجها. الغلاف ليس ميزة راحة. إنه فرق في التكلفة بمقدار ألف ضعف على العمل نفسه، وهو ناتج عن خيار تصميمي واحد: تُقيَّم الأسئلة مقابل سياق مشترك واحد في تمريرة واحدة، لا واحدة لكل رحلة ذهاب وإياب.

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

المظروف: 262,144 رمزًا، مشترك، ومحدود بـ1,000 سؤال

تغطي نافذة السياق المدخل المشترك وكل سؤال في الطلب معًا، عند 262,144 توكنًا. وضمن هذه الميزانية يمكنك طرح ما بين 1 و1,000 سؤال. الرقم المهم هو الحد الأعلى: فوجود 1,000 سؤال في نداء واحد ليس من مجال المصنّفات، بل هو قدر من التقدير يعادل محرك قواعد كاملًا مضغوطًا في تمريرة واحدة. يمكن فحص تذكرة دعم مقابل أربعين بندًا من بنود السياسة؛ ويمكن اختبار ملف قرض مقابل كل قاعدة اكتتاب دفعة واحدة.

هناك خاصيتان في بنية الطلب يسهل تفويتهما ويكلف اكتشافهما لاحقًا. تُقيَّم الأسئلة بشكل مستقل — فإجابة سؤال لا تؤثر في السؤال التالي، لذا لا يمكنك تسلسل الاستدلال بطرح سؤال متابعة يعتمد على رد سابق. كما لا يرى النموذج مفاتيح أسئلتك أبدًا، بل يرى نص التعليمات الذي تكتبه فقط؛ لذا فالمفاتيح لمجرد تنظيمك الداخلي، ويجب أن تكون التعليمات قائمة بذاتها.

ثلاثة أشكال للأسئلة، والفخّ الكامن في كلٍّ منها

• نعم/لا — يُرجع نوع noul احتمالًا يتراوح بين 0.01 و0.99 بالإضافة إلى درجة ثقة. يتم تثبيت الحد عند الطرفين، لذا فإن حد التوجيه المضبوط على 0.995 لن يُفعّل أبدًا، بغض النظر عن مدى يقين النموذج. اختر حدودًا ضمن النطاق الذي يمكن لواجهة API فعليًا إرجاعه.

• اختيار — من خيارين إلى 255 خيارًا مسمّى، ويعيد الخيار الفائز، واحتمالًا لكل خيار مجموعها واحد، ودرجة ثقة. قبل التقييم، ترتّب الواجهة البرمجية (API) مفاتيح خياراتك أبجديًا وفق ترتيب بايتات UTF-8، ما يعني أن ترتيب مفاتيح JSON غير ذي صلة، وأن التعادل التام يُحسم لصالح المفتاح الذي يأتي أولًا في الترتيب. إرشادات Google تنبع من ذلك: سمِّ خيارك الشامل other، لأن اسمًا مثل none_of_the_above يأتي قبل معظم الفئات الحقيقية وسيفوز بتعادلات كان يجدر به خسارتها.

• الدرجة — من مستويين إلى 255 مستوى ترتيبيًا في معيار التقييم، ويُوصى باستخدام مستويين إلى عشرة. القيمة المُعادة هي مستوى متوقّع مرجّح احتماليًا، ولأن القيمة المتوقعة تحسب متوسط مؤشرات المصفوفة بدلًا من التسميات، فإن مقياسًا مكتوبًا على هيئة 1/10/100/1000 يُنتج رقمًا ليس على مقياسك. حافظ على تباعد متساوٍ في معيار التقييم من حيث المؤشرات، أو حوّل المؤشر المتوقّع إلى تسمية بنفسك.

ما تُدرجه الوثائق على أنه غير متاح

الفجوات كلها في الاتجاه نفسه: هذه نقطة نهاية ذات استدعاء واحد لا يلتف حولها أي شيء. لا يوجد تخزين مؤقت للسياق، لذا فإن مستند سياسة يُعاد استخدامه عبر الطلبات يُحتسب again بالكامل في كل مرة. لا توجد Batch API، ما يستبعد معالجة ليلية بنصف السعر لتذاكر العام الماضي. لا توجد طبقة Flex أو Priority. النموذج متاح على Gemini Developer API فقط، بالإصدار v1beta، دون إدراج Vertex AI في الوثائق التي أصدرتها Google — وهو تفصيل يهم كل من تتم مشترياته عبر عقد سحابي بدلاً من مفتاح API.

الوسائط واسعة بشكل غير معتاد ومحدودة بشكل غير معتاد في الوقت نفسه. يُرسل النص والصورة والفيديو والصوت وPDF كلها في طلب واحد. الحدود هي 100 ميغابايت من {{1}}base64 المضمّن{{/1}}، و50 ميغابايت لملف PDF، و15 ميغابايت لكل رابط HTTPS خارجي. لا تُقبل روابط YouTube ولا عناوين URI من نوع gs://؛ بل تمرّر مراجع ملفات مرفوعة، أو عناوين URL موقّعة، أو بيانات بايت.

تبدأ حدود المعدل عند 200 طلب و50,000 رمز في الدقيقة في الطبقة المجانية، ثم تنتقل إلى 1,500 طلب ومليون رمز في الدقيقة عند الطبقة 1، وتصل إلى 5,000 طلب وأربعة ملايين رمز في الدقيقة عند الطبقة 2 مع عدم وجود حد يومي للطلبات. الطبقة المجانية مجانية دون مقابل، لكنها موثقة على أنها تُستخدم لتحسين منتجات Google، ما يجعلها غير صالحة لأي استخدام يخضع لبند سرية.

النتيجة، باختصار.

على Artificial Analysis Decision Index v2.1 يسجّل النموذج 66 — 65.98 دون تقريب — ويحلّ تاسعًا من بين ثمانية عشر نموذج قرار تصنّفها اللوحة. وهو الأول منفردًا في مكوّنين من المكوّنات الستة، AA-Omniscience-Decision v1.1 وHLE-MultiChoice v1.1، وكلاهما بوزن 15%، وفي منتصف الجدول في AA-Paperclip بوزن 30%، وهو المكوّن الذي يحسم معظم النتيجة المركّبة. التكلفة المقيسة 345 دولارًا لكل مليون مهمة، وزمن الاستجابة 211 مللي ثانية لكل مهمة، مقابل وسيط للمجال قدره 209. لم تنشر Google أي جدول قياسات مرجعية خاص بها مع الإصدار؛ وكل رقم أداء هنا مأخوذ من اللوحة المستقلة، وفق إطار الاختبار الخاص بها. الحساب الكامن وراء 66 مسألة منفصلة ومقال منفصل.

دمجه في خط أنابيب تقوم بتوجيهه بالفعل

لا يوفر OrcaRouter النموذج gemini-decision-1، والسبب بنيوي لا تجاري: فنقطة نهاية تُرجع الاحتمالات فقط ليست هدفًا لتكميلات المحادثة، لذا لا يوجد شيء يستطيع موجّه بهذه البنية أن يضعه خلف مفتاح واحد. النصف الذي نخدمه من خط المعالجة هو النصف الآخر. فخدمة القرار تتألف غالبًا من استدعاءين — شيء يصوغ الإجابة المرشحة أو معايير التقييم أو القائمة المختصرة، وشيء يقيّمها — والاستدعاء الخاص بالصياغة هو حيث تكون مسألة اختيار النموذج مطروحة فعليًا.

يمكن لذلك الاستدعاء أن يعمل عبر أكثر من 200 نموذج على نقطة نهاية واحدة، بسعر قائمة أسعار المورّد الممرَّر دون أي هامش ربح (0%)، لذا عندما يخفض أحد المورّدين السعر، يصبح الرقم الجديد ساريًا لدينا في اليوم نفسه بدلًا من دورة الفوترة التالية. يثبت دمج النماذج جدارته هنا بطريقة لا تتوفر في واجهة دردشة: يولّد مُعدّا المسودات إجابتين مرشحتين متنافستين، وتقيّم واجهة Decisions API كلتيهما مقابل المعيار نفسه في طلب واحد، مما يحوّل اختبار A/B إلى قرار لكل سجل.

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

الخلاصة

تستحق واجهة Decisions API التبنّي لسبب واحد، وهو ليس موقعها في لوحة المتصدرين: فهي تختزل ألف رحلة ذهاب وإياب في مدخل واحد مفوتر، وهذا يغيّر أي الأسئلة يصبح طرحها رخيصًا. اِبنِ عليها إذا كانت مشكلاتك تشبه أحكامًا كثيرة على كائن واحد كبير — عقد، أو ملف مطالبة، أو ساعة فيديو — وتوقّع أن تُبقي موجّهاتك ضمن طلب واحد، لأن كل ما يجعلها رخيصة يحدث بين أول رمز وآخر رمز في نداء واحد. أما إذا كانت مشكلاتك تشبه سؤالًا واحدًا حول ألف كائن صغير، فلن يفيدك الغلاف بشيء، وسعر الإدخال ببساطة ثلاثة أضعاف ما يتقاضاه نموذج قرار أرخص.