1. تاريخان ومساران مختلفان للاستبدال

تذكر ملاحظات Gemini API المؤرخة في 2 نوفمبر 2026 أن Gemini 2.5 Pro و2.5 Flash أصبحا ضمن النماذج المتقادمة ولم يعودا قابلين للاختيار في Google AI Studio. أما تغيير API فمقرر في 1 ديسمبر: ستوجه طلبات gemini-2.5-pro إلى gemini-3.8-flash، وطلبات gemini-2.5-flash إلى gemini-3.5-flash-lite، مع احتساب رسوم النموذج البديل.

عند مراجعتنا في 4 نوفمبر، كان الوصول إلى هذين النموذجين عبر API مقصورا على من استخدمهما فعليا في السابق. النموذج المختلف gemini-2.5-flash-lite ليس مشمولا بهذا الإيقاف التدريجي. نجاح طلب بالاسم القديم اليوم لا يثبت ثبات السلوك بعد الموعد، والإعلان الذي قرأناه لا يحدد ساعة التحويل أو منطقتها الزمنية.

تخص هذه التصريحات Gemini Developer API وAI Studio. وهي لا تثبت جدولا مماثلا لتطبيق Gemini الاستهلاكي أو مزايا الاشتراك أو جميع عمليات النشر على Vertex AI. سجل واجهة الخدمة ومسؤول المشروع في كل مهمة ترحيل قبل اختيار البديل.

Google: ملاحظات Gemini API في 2 نوفمبر · Google: التقادم والوصول وجدول إعادة التوجيه

2. احصر عقد التطبيق قبل تغيير اسم النموذج

راجع إعدادات التطبيق والعمال الخلفيين ودفاتر العمل والمهام الدفعية والأسماء البديلة في بوابتك. قد يشير متغير بيئة إلى pro بينما تحله البوابة أو مشغل المهام إلى نموذج آخر. سجل النموذج المضبوط وأي هوية نموذج تكشفها الاستجابة؛ رمز HTTP 200 وحده لا يثبت أن المسار المقصود قد اختبر.

افصل ترحيل النموذج عن ترحيل نقطة النهاية. ما زالت Google تدعم GenerateContent، وتوصي باستخدام Interactions للمشروعات الجديدة. تغيير النموذج وSDK ونقطة النهاية والتعليمات وبروتوكول الأدوات في إصدار واحد يصعب تفسير فشل الإعادة. ثبت أولا خط أساس قابلا للتكرار، ثم غير عنصرا واحدا كل مرة.

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

Google: حالة Interactions وإعدادات الدور والتخزين · Google: مفاتيح API والمشروعات وبيانات الاعتماد

3. استبدل الافتراضات بمصفوفة توافق للطلبات

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

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

فحوص توافق مقترحة في مشروع اختبار منفصل؛ لا تمثل نتائج قياس
الافتراض السابقإجراء الترحيلدليل القبول
يمكن نقل رقم thinking_budget كما هواختر thinking_level يدعمه النموذج الهدفالطلب الفعلي ونتيجة قبول المهمة
تحافظ temperature / top_p / top_k على السلوكاحذف معاملات أخذ العينات المتقادمةغياب الحقول مع اجتياز معايير المخرجات
ما زال candidate_count مدعومااحذفه في Gemini 3 وما بعدهالتطبيق لا يفترض وجود عدة مرشحين
بادئة model الأخيرة تفرض التنسيقاستخدم تعليمات النظام أو المخرجات المنظمةلا دور model معبأ مسبقا؛ التنسيق والقيم صحيحان
السجل النصي وحده كافاحتفظ بحالة النموذج الكاملة التي يتطلبها البروتوكولاكتمال دورة أدوات متعددة الأدوار دون فقد السياق
الاسم القديم يوفر تراجعاجهز إعدادا بديلا ما زال مدعومااختيار صريح للبديل وقبول مستقل له

Google: قائمة ترحيل Gemini 3.8 Flash · Google: تغييرات Gemini 3.6 و3.5 Flash-Lite

4. حدد جهد التفكير صراحة ثم اختبره

يدعم Gemini 3.8 Flash المستويات low وmedium وhigh؛ الافتراضي medium، أما minimal فغير مدعوم. لا تنقل إعداد Flash-Lite دون تحقق. على الموجه التحقق من زوج النموذج ومستوى التفكير بدلا من إلحاق الإعداد نفسه بجميع النماذج.

جسم طلب Interactions REST التالي مثال لم ينفذ لحالة اصطناعية للقراءة فقط. نقطة النهاية هي POST https://generativelanguage.googleapis.com/v1beta/interactions، مع مفتاح محفوظ في الخادم. يوضح شكل الطلب ولا يمثل إعداد إنتاج أو نتيجة مقاسة. لا يتوافق store=false مع التنفيذ الخلفي، ويمنع المتابعة اللاحقة باستخدام previous_interaction_id؛ وليس ضمانا عاما لغياب كل احتفاظ بالبيانات لدى المزود.

قارن low وmedium على حالات القبول نفسها قبل زيادة الجهد. سقف المخرجات والمهلة وميزانية استدعاءات الأدوات ضوابط منفصلة. قد يقطع السقف القصير المخرج المطلوب، فلا تستخدمه بديلا عن تحديد مستوى الاستدلال.

{
  "model": "gemini-3.8-flash",
  "store": false,
  "input": "حالة اصطناعية: اذكر المعرفات المكررة في [7, 3, 7]. لا تستدع أدوات خارجية.",
  "generation_config": {
    "thinking_level": "low"
  }
}

Google: قائمة ترحيل Gemini 3.8 Flash · Google: حالة Interactions وإعدادات الدور والتخزين · Google: تجربة تكلفة المهمة في 3 نوفمبر

5. احتفظ بالتوقيعات خلال دورة أدوات كاملة

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

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

  • أعد على الأقل طلب المستخدم واستدعاء الأداة ونتيجتها والجواب النهائي؛ تحية من دور واحد لا تختبر استمرارية الحالة.
  • اختبر الاستجابة المتدفقة وغير المتدفقة كل واحدة على حدة. احتفظ بالأحداث المكتملة، ومنها تغير التوقيع؛ بدء النص لا يثبت انتهاء الدور.
  • أضف حالات حذف خطوة thought وبتر توقيع وإسقاط المسلسل حقولا غير معروفة. سجل الخطأ الفعلي أو المتابعة الخاطئة دون افتراض رمز HTTP واحد لجميع الواجهات.

Google: التفكير والتوقيعات وحالة التدفق

6. طابق نتائج الأدوات وامنع تكرار الآثار

في بروتوكول Interactions تحدد function_result الاستدعاء المقابل بواسطة call_id واسم الدالة. ينبغي أن يعيد محول التطبيق نتيجة واحدة مطابقة لكل استدعاء، بما في ذلك نتيجة فشل واضحة. لا تطابق النتائج المتوازية بترتيب المصفوفة فقط؛ قد يكون لاستدعاءين الاسم نفسه ومعاملات مختلفة.

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

تبقى tools وsystem_instruction وgeneration_config خاصة بالتفاعل الحالي في Interactions حتى مع ربط التاريخ. أعد إرسال السياسة والإعداد المقصودين في كل دور. حفظ المحادثة لا يثبت أن أذونات الأدوات أو مستوى التفكير السابق قد انتقلت تلقائيا.

Google: استدعاء الدوال ومطابقة النتائج · Google: حالة Interactions وإعدادات الدور والتخزين

7. تحقق من عقد المخرجات وكل نوع من الوسائط

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

تذكر مراجع النموذجين الهدفين مدخلات النص والصورة والفيديو والصوت وPDF، مع مخرجات نصية. قراءة الصوت لا تعني توليد الكلام، وقراءة الصورة لا تعني إنشاءها. تحتاج نقاط Live وتوليد الصوت والصور إلى مراجعة خاصة، لا تطبيق بدائل النماذج النصية هذه عليها.

  • للوثائق استخدم صفحة وإجابة معلومتين، واطلب القيمة وموقع الدليل لا مجرد صياغة مقنعة.
  • أضف رسما بمحور أو وحدة ملتبسة، واقبل التعبير الصريح عن عدم اليقين بدلا من تخمين رقم.
  • لاستخراج JSON اختبر البيانات الناقصة والمعرفات المكررة والحقول الزائدة، وافصل صحة الصيغة عن قواعد المجال.
  • عندما تعيد أداة وسائط، تحقق من حفظ نوع المحتوى والحمولة الصحيحة، لا اسم ملف أو وصف نصي فقط.

Google: المخرجات المنظمة وحدود المخطط · Google: إمكانات Gemini 3.8 Flash · Google: إمكانات Gemini 3.5 Flash-Lite

8. أنشئ اختبارات تستطيع رفض جواب يبدو مقنعا

استخدم حالات اصطناعية أو بيانات منزوعة الهوية ومصرحا بها مع نتائج أدوات ثابتة. احتفظ بمجموعة منفصلة لا تستعمل لضبط التعليمات. اكتب النتيجة المتوقعة وسبب أهمية كل حالة. ميز بين جواب مدعوم ورفض صحيح وتسليم آمن؛ ليس كل رد مكتمل مهمة ناجحة.

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

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

Google: التفكير والتوقيعات وحالة التدفق · Google: استدعاء الدوال ومطابقة النتائج · Google: المخرجات المنظمة وحدود المخطط

9. أدخل المحاولات الفاشلة في تكلفة العمل المقبول

تبحث مقالة Google الهندسية في 3 نوفمبر التوجيه بحسب تكلفة المهمة الناجحة. تجربتها من 50 طلبا وتشغيل واحد لكل إعداد وتقييم محدود هي حالة نشرها المزود، وليست قياسنا أو ترتيبا مستقلا أو ضمانا للإنتاج. الفكرة المفيدة هي مقارنة المهمة كاملة بدلا من سعر الرمز وحده.

في تقييمك اجمع الرسوم الفعلية للنماذج والموجه والمحاولات والأدوات الخارجية والبنية المفوترة بصورة مستقلة خلال فترة القياس. اقسم على المهام التي اجتازت معايير مستقلة. إن لم تنجح أي مهمة فاذكر ذلك مع الإنفاق؛ لا تقسم على صفر ولا تحذف المحاولات الفاشلة. لا تحتسب رموز التفكير مرتين إذا كانت داخلة في إجمالي الفاتورة.

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

تكلفة_المهمة_المقبولة = إجمالي_التكلفة_المتحقق_منها / المهام_المقبولة

# سجل تقييم يقترحه التطبيق، وليس حقول Gemini API
case_id, model, endpoint, sdk_version, prompt_digest
thinking_level, state_mode, tool_schema_digest
accepted, failure_category, latency_ms, retry_count
reconciled_cost, rate_date, cache_condition, intended_effects

Google: تسعير Gemini Developer API · Google: تجربة تكلفة المهمة في 3 نوفمبر

10. لا تضف الموجه قبل مقارنته بخط أساس بسيط

قارن أولا سياسات ثابتة قليلة: Flash-Lite لكل العمل الملائم، و3.8 Flash بمستوى low، ثم medium. احتفظ بمتطلبات الجودة ومجموعة الاختبار نفسها. بعدها قارن موجه الاختيار بين التركيبات المدعومة. وإلا قد يبدو الموجه المعقد اقتصاديا لمجرد سوء إعداد خط الأساس.

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

قيم السياق الدافئ والبارد منفصلين واحتفظ ببيانات تفسر تبديل النموذج. قد يغير التوجيه إعادة استخدام السياق وشروط حالة المحادثة. اختبر التبديل أثناء الجلسة؛ نجاح طلب جديد لا يثبت صحة الاستمرار. يجب أن يدعم النموذج التالي أنواع الوسائط الموجودة بالفعل في المحادثة كمدخلات.

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

Google: حالة Interactions وإعدادات الدور والتخزين · Google: تجربة تكلفة المهمة في 3 نوفمبر

11. انشر مع بديل يبقى صالحا بعد 1 ديسمبر

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

بعد التحويل المعلن، إعادة الإعداد إلى gemini-2.5-pro أو gemini-2.5-flash لن تستعيد النموذج السابق. البديل الحقيقي إعداد صريح ما زال مدعوما واجتاز الحالات المطلوبة، أو طابور بشري معتمد. الاحتفاظ بالمحول القديم لا يعني الاحتفاظ بإتاحة النموذج لدى المزود.

  • حدد شروط التوقف عند تكرار الآثار أو تعطل روابط الأدلة أو استمرار الطلبات غير الصالحة أو تجاوز الميزانية.
  • اختبر البديل بقيود البيانات وأذونات الأدوات نفسها؛ يجب ألا يوسع مسار الإنقاذ الوصول بصمت.
  • أنجز الترحيل قبل الموعد بدلا من الرهان على ساعة تحويل غير موثقة أو تمديد غير معلن.
  1. حصر المسارات وحدود البيانات
  2. تثبيت خط الأساس والحالات الاصطناعية
  3. قبول الطلبات والحالة وعقد الأدوات
  4. قياس العمل المقبول والتكلفة الكاملة
  5. ظل بلا آثار ثم نشر محدود
  6. رصد ثم بديل مختبر أو تسليم بشري
مسار إصدار مقترح: تنتج كل بوابة مخرجا قابلا للمراجعة

Google: ملاحظات Gemini API في 2 نوفمبر · Google: التقادم والوصول وجدول إعادة التوجيه

12. اترك سجلا يستطيع مهندس آخر إعادة إنتاجه

سجل تاريخ مراجعة المصادر والمسارات المتأثرة والإعدادات الدقيقة وبصمات الحالات وقواعد التقييم وأمثلة الفشل ومسؤول البديل. افصل النتائج المقاسة عن الفحوص المخطط لها. راجعنا وثائق المقال في 4 نوفمبر 2026؛ جسم الطلب والمصفوفات ومسار النشر أمثلة لم تنفذ. لم نتحقق من أهلية حساب بعينه أو حصته أو التأخر أو التوفير.

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

راجع ترحيل Gemini 2.5 دون استدعاء API مدفوعة أو تغيير الإنتاج.
1. احصر معرفات النماذج ونقطة النهاية وSDK والتعليمات ومحولات الأدوات.
2. اربط كل مسار بهدف مدعوم ومستوى تفكير صريح.
3. حدد أدوار model المعبأة والمعاملات المحذوفة والحالة المفقودة.
4. اقترح حالات اصطناعية للأدوات المتسلسلة والمتوازية والتدفق الناقص والآثار المكررة.
5. أنتج مصفوفة قبول وسجل تكاليف وخطة تحقق للبديل.
ميز ما تحقق من الشفرة، وما تدعمه وثائق رسمية مؤرخة، والاستنتاج، وما لا يزال مجهولا.

Google: ملاحظات Gemini API في 2 نوفمبر · Google: قائمة ترحيل Gemini 3.8 Flash · Google: تغييرات Gemini 3.6 و3.5 Flash-Lite · Google: مفاتيح API والمشروعات وبيانات الاعتماد