Gemini Decision مقابل Gemini Decision 1: أحدهما اسم، والآخر معرّف نموذج

ابحث عن Gemini Decision وستجد تغطية الإطلاق، وإدخالًا في لوحة الصدارة، وصف تسعير، ومرجعًا لواجهة API، وكلها تستخدم كلمات مختلفة قليلًا للشيء نفسه. ابحث عن Gemini Decision 1 وستجد معرّف النموذج الذي يعمل فعليًا. تختلف السلسلتان بحرف واحد وتتصرفان بشكل مختلف تمامًا في الشيفرة: إحداهما هي ما يسميه الناس المنتج، والأخرى هي القيمة الوحيدة التي سيقبلها POST /v1beta/decisions. إذا كنت قد أمضيت فترة بعد الظهر في مواجهة 404 تتساءل لماذا لا يمكن العثور على نموذج موجود بوضوح، فهذا هو المقال الذي كان سينقذك.

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

إلى ماذا يُحَلّ الاسمان

ابدأ بالتعيين، لأن كل شيء آخر يتبع منه.

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

• Gemini Decision 1 — النموذج، والمعرّف gemini-decision-1. هذه هي القيمة التي تعمل. وهو النموذج الوحيد الذي تخدمه واجهة Decisions API، وتنص الوثائق على ذلك صراحةً: نقطة النهاية متاحة فقط مع G​emini Decision 1.

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

حيث يستمر ظهور الاسم الثاني

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

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

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

كيفية التحقق مما يمكن لمفتاح معيّن استدعاؤه فعليًا

قبل كتابة طلب، اسرد النماذج التي يحق للمفتاح استخدامها. إن استدعاء list-models القياسي على Generative Language API يعيد النماذج المتاحة لمشروعك مع معرّفاتها، وتشغيله مرة واحدة يحسم المسألة نهائيًا لذلك المفتاح.

إذا ظهر ‎gemini-decision-1، فلديك صلاحية الوصول، وهذا النص الدقيق هو ما يُوضع في الطلب. وإذا لم يظهر، فالمشكلة تتعلق بالاستحقاق أو المنطقة لا بالإملاء، ولن يفيد أي قدر من إعادة التسمية. وما لن تجده في تلك القائمة هو مُدخل باسم ‎gemini-decision، لأنه لا يوجد نموذج بهذا الاسم.

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

الأخطاء الثلاثة التي يسبّبها هذا الغموض فعليًا

• خطأ 404 الخاص بالنموذج غير المعروف. الخطأ الواضح. وجود gemini-decision في جسم الطلب يُرجع خطأً يبدو كمشكلة أذونات لكنه ليس كذلك. إذا ذكر الخطأ النموذج بدلاً من المشروع، فافحص السلسلة قبل أن تفحص حساب الفوترة.

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

• افتراض نقطة النهاية الخاطئة. والأمر أكثر خفاءً: فبما أن النموذج موجود والاسم صحيح، فإن إرسال gemini-decision-1 إلى نقطة نهاية generate-content عادية يظل يفشل. فالنموذج غير قابل للاستدعاء بهذه الطريقة على الإطلاق. إنه هدف مخصص للاحتمالات فقط على نقطة نهاية decisions، وأي طلب يطلب منه نصًا نثريًا إنما يطلب شيئًا لا ينتجه. وأي مكتبة عميل تعتمد افتراضيًا على chat completions ستكون بحاجة إلى مسار صريح.

ماذا يقول هذا عن النموذج، وليس عن اسمه فحسب

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

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

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

إذا كنت تختار بين السلسلتين النصيتين في نموذج

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

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

الخلاصة

استخدم gemini-decision-1 في كل جسم طلب ومسار نقطة نهاية وقيمة إعدادات، واستخدم "G​emini Decision" فقط حيث يقرأه إنسان. لا يوجد اسم مستعار يمكن الرجوع إليه، ولا نموذج ثانٍ يختبئ خلف الاسم الأقصر، ولا مسار chat-completions للاسم الأطول. تكلفة الخطأ في هذا صغيرة — خطأ 404 واحد، وبعد ظهر واحد مرتبك — لكن تكلفة افتراض وجود اسم مستعار أكبر، لأن ذلك الخطأ ينجو من المراجعة ويفشل في الإنتاج. ثبّت المعرّف، وسجّل النموذج الذي يسميه الرد، وتعامل مع اسم العائلة كنص عادي.