OpenAI توقف لقطات GPT-4o وGPT-4.1 في API: رحّل بلا تراجع

أعلنت OpenAI في 14 أكتوبر 2026 أن خمس لقطات مؤرخة من سلسلة GPT-4 ستُزال من API في 14 يناير 2027: لقطتان من GPT-4o، وGPT-4o mini، وGPT-4.1، وGPT-4.1 mini. وتوصي الشركة بـGPT-6 Luna بديلًا لها جميعًا. الاستجابة الصحيحة ليست استبدال اسم النموذج في سطر واحد؛ بل جرد كل مسار إنتاجي، وتثبيت مجموعة اختبار ممثلة، وتحديد إصدار لعقد الطلب كاملًا، ومقارنة المخرجات وسلوك الأدوات، ثم الإطلاق عبر Shadow Traffic وCanary قابل للرجوع. يهم ذلك فرق الاستخراج المنظم واستدعاء الأدوات ودعم العملاء وتدفقات المحتوى، خصوصًا أن النماذج المضبوطة Fine-tuned ترث موعد الإيقاف نفسه.

صفحة إيقافات OpenAI الرسمية هي مرجع الإعلان والتواريخ. تذكر `gpt-4o-2024-08-06` و`gpt-4o-2024-11-20` و`gpt-4o-mini-2024-07-18` و`gpt-4.1-2025-04-14` و`gpt-4.1-mini-2025-04-14` للإزالة في 14 يناير 2027، وتقترح `gpt-6-luna` بديلًا. هذه المعرّفات والتواريخ والبديل حقائق موثقة. أما خطة الاختبار والتوجيه والإطلاق أدناه فهي تحليل هندسي لتقليل الخطر؛ ولم تقل OpenAI إن كل تطبيق سيحافظ على السلوك نفسه بمجرد تغيير النموذج.

ما الذي سيتوقف بالضبط؟

يستهدف الإشعار لقطات صريحة مؤرخة، لا اسم عائلة مجردًا. وهذا مهم لأن الأنظمة الإنتاجية قد تخفي معرّف النموذج وراء Alias أو متغير بيئة أو أداة لإدارة Prompts أو قيمة افتراضية في SDK أو مهمة Batch أو ناتج Fine-tuning أو بوابة مزود. ابحث في الإعدادات والكود وأبعاد المراقبة وملفات النشر عن المعرّفات الدقيقة، وافحص قوالب الطلبات المخزنة والمهام المجدولة التي تعمل بوتيرة أقل من المسار الرئيسي.

أنشئ صفًا لكل مسار يتضمن المالك وEndpoint ومعرّف النموذج واللقطة أو النموذج المضبوط وإصدار Prompt وإصدار Schema والأدوات وحجم الحركة وتصنيف البيانات وSLO للزمن والبديل وآخر طلب ناجح وموعد الإزالة. اعتبر أي صف بلا مالك أو معرّف واضح دينًا تشغيليًا. لوحة تعرض الاسم المرئي فقط لا تكفي إذا كانت البوابة تعيد كتابة الطلب الحقيقي.

تحتاج النماذج المضبوطة إلى مسار منفصل. تنص OpenAI على أن النسخ Fine-tuned من النماذج المدرجة تتبع موعد الإيقاف نفسه لنموذج الأساس. وصفحة GPT-6 Luna الرسمية تضع Fine-tuning حاليًا في حالة غير مدعومة. لذلك لا تفترض إمكان إعادة إنشاء نموذجك المضبوط مباشرة على Luna. استرجع بيانات التدريب والتحقق الأصلية، ووثّق السلوك الذي أضافه الضبط، واختبر هل يمكن لـPrompt أو Retrieval أو كود حتمي أن يحل محله، ولا تختر مسارًا بديلًا إلا بعد مراجعة أحدث توثيق رسمي.

وحدة الترحيل هي عقد الطلب

تغيير `model` وحده يتجاهل الأجزاء الأكثر احتمالًا لإحداث تراجع. حدّد إصدار النموذج مع التعليمات وأدوار الرسائل وReasoning Effort وتعريفات الأدوات وJSON Schema وParser وسياسة Retry وTimeout وفحوص الأمان واستراتيجية حالة المحادثة وحدود التكلفة والزمن. يجب أن يشير الإصدار إلى حزمة عقد ثابتة حتى يمكن إعادة تشغيل المسارين القديم والجديد ومقارنتهما.

تذكر وثائق GPT-6 Luna نافذة سياق قدرها 1.05 مليون Token وحدًا أقصى للمخرجات 128 ألف Token، وإدخال نص وصورة، وStructured Outputs وFunction Calling وضبط Reasoning Effort. وتقول كذلك إن الأدوات المضمنة وFunction Calling تستخدم Responses API، بينما يدعم Chat Completions استدعاء الدوال فقط عندما تكون قيمة Reasoning Effort هي `none`. هذه قدرات مفيدة، لكنها ليست دليلًا على توافق Prompt أو Schema أو سياسة الأدوات لديك. اختبر Endpoint والمعاملات التي ستنشرها فعلًا.

contract: support-ticket-v12
model: gpt-6-luna
endpoint: responses
instructions: sha256:...
tools: sha256:...
output_schema: sha256:...
reasoning_effort: none
timeout_ms: 12000
max_output_tokens: 900
fallback: gpt4-contract-v11

قيم Hash هنا مثال لإعداد قابل للتتبع وليست صيغة تفرضها OpenAI. الفكرة أن يكشف أي Incident الحزمة التي أنتجت الاستجابة، والحزمة الموثوقة التي يمكن إعادة الحركة إليها.

افصل ترحيل النموذج عن ترحيل Endpoint

توصي OpenAI باستخدام Responses API للمشاريع الجديدة، ويشرح دليل الترحيل إلى Responses أن Chat Completions ما زال مدعومًا وأن الفريق يستطيع ترحيل User Flow واحد كل مرة. إذا كان مسار GPT-4 الحالي يستخدم Chat Completions، فقرر هل ستغير النموذج والواجهة في تجربة واحدة مضبوطة أم إصدارين. الإصداران يعزلان سبب التغيير، بينما قد يكون الإصدار الواحد منطقيًا إذا كان السلوك المستهدف يعتمد على أدوات لا تتوفر إلا في Responses.

في Responses يمكن حمل الحالة صراحة أو عبر Previous Response ID، وتأتي المخرجات في مصفوفة عناصر Typed، وتنتقل Structured Outputs إلى `text.format`. أي Parser ينتظر `choices[0].message.content` لن ينجو من هذا التغيير. أضف اختبارات عقد للنص الناجح والرفض والمخرج الناقص وتعدد استدعاءات الأدوات وخطأ الأداة وTimeout والإلغاء وأحداث Streaming. ولا تخزن بيانات حساسة فقط لتسهيل الترحيل؛ حافظ على ضوابط البيانات القائمة في التطبيق.

ابنِ مجموعة تقييم ممثلة

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

قيّم عقد المستخدم النهائي لا التشابه الأسلوبي مع جواب النموذج القديم. في التصنيف، قس Precision وRecall لكل فئة. وفي الاستخراج، تحقق من الحقول وقيود العمل. وفي الدعم، اختبر Groundedness والالتزام بالسياسة وقرار التصعيد. وفي الوكلاء، قس اختيار الأداة وصحة المعاملات وتفويض الآثار الجانبية وحدود الدوران وصحة الحالة النهائية. تابع P50 وP95 للزمن وعدد Tokens ونسبة Retry والتكلفة لكل مهمة مقبولة مع الجودة.

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

المخرجات المنظمة والأدوات بوابات إصدار

يوضح دليل Structured Outputs أن Strict Schema تقيد المخرج ضمن جزء مدعوم من JSON Schema، بينما يبقى على التطبيق التعامل مع الرفض والاستجابات الناقصة. أعد تشغيل كل Schema إنتاجية. تحقق من الحقول المطلوبة وEnum وحدود التداخل وسلوك الحد الأقصى للمخرجات ومعالجة Parser للرفض أو القطع. الالتزام بالشكل ضروري لكنه غير كافٍ؛ فقد يحتوي كائن صحيح البنية قرارًا تجاريًا خاطئًا.

وبالنسبة للأدوات، اتبع التدفق متعدد الخطوات في دليل Function Calling: يطلب النموذج الدالة، وينفذها التطبيق، ثم يعيد النتيجة ويحصل على الاستجابة التالية. أثناء الترحيل قارن اختيار الأداة والمعاملات والترتيب وسلوك الإكمال. أبقِ التفويض في كود التطبيق. قد يقترح النموذج Refund أو تعديل حساب، لكن يجب أن تتحقق سياسة حتمية من Tenant والصلاحية والقيمة وIdempotency قبل أي أثر جانبي.

يجب تعطيل الكتابة في Shadow Testing. شغّل عقد Luna بجانب المسار الحالي على عينة من الحركة، ونفذ العمليات الحقيقية فقط في Control، واستبدل أدوات Candidate بنتائج مسجلة أو Read-only. وإلا قد يكرر الاختبار بريدًا أو خصمًا أو تعديل قاعدة بيانات. سجل قرارات Candidate في Namespace منفصل، وضع حدودًا للـToken والوقت والأدوات حتى لا تستهلك حلقة سيئة قدرة الإنتاج.

معمارية إطلاق مع رجوع حقيقي

ضع الاختيار خلف Model Gateway على الخادم. حدد Cohort ثابتًا قبل الطلب، وأرفق إصدار العقد، ونفذ مسارًا واحدًا، وتحقق من الاستجابة، وسجل مقاييس النتيجة، وأتح Kill Switch يعيد الحركة إلى المسار السابق. لا توجه بناء على قيمة عشوائية مؤقتة إذا كانت المحادثة نفسها تحتاج اتساقًا.

التسلسل الآمن هو Offline Replay، ثم Shadow للقراءة فقط، ثم حركة اصطناعية أو داخلية، ثم Cohort إنتاجي صغير وثابت، ثم توسع مرحلي وCutover كامل. لا ترقِّ الإصدار إلا إذا بقيت الجودة وصحة Schema وأمان الأدوات والزمن والتكلفة ضمن حدود واضحة على حركة تغطي الشرائح المهمة. أوقف تلقائيًا عند مخالفة سياسة خطرة أو محاولة أداة غير مفوضة أو أخطاء Parser أو تراجع KPI تجاري أو نمو غير مفسر للتكلفة.

يجب أن يعيد Rollback عقد الإصدار السابق كاملًا لا معرّف النموذج فقط. احتفظ بـPrompt القديم وSchemas الأدوات وParser وEndpoint قابلين للنشر حتى يستقر المسار الجديد. ولأن اللقطات القديمة تختفي في 14 يناير 2027، فالرجوع آلية أمان مؤقتة وليس استراتيجية ترحيل. أكمل مبكرًا بما يكفي لإصلاح المشكلات ولا تضع Cutover النهائي قرب موعد الإزالة.

جدول قرار لمالكي المسارات

المسار الذي يستخدم لقطة GPT-4 صريحة بلا أدوات يحتاج أولًا اختبارات جودة ورفض وزمن وتكلفة مقابل Luna. ومسار الاستخراج المنظم يحتاج فوق ذلك تحقق Schema ومعنى الحقول. والوكيل الذي يستعمل أدوات يحتاج اختبارات لاختيار الأداة والمعاملات والتفويض والآثار الجانبية. وتدفق السياق الطويل يجب أن يختبر موضع المعلومات المهمة والتكلفة على أحجام مستندات واقعية لا الحد الأقصى المعلن وحده. أما Fine-tuned descendant فيدخل مسار إعادة تصميم لأن Luna موثق حاليًا بأنه لا يدعم Fine-tuning.

إذا كانت قاعدة العمل قابلة للتعبير بحتمية، ففكر في إخراج LLM من القرار بدل إعادة بنائه. SQL أفضل لحالة الحساب الدقيقة، والكود أفضل للصلاحيات والحسابات، وSearch أو Retrieval أفضل للوصول إلى الدليل. استخدم النموذج للتفسير أو التوليد فقط حيث يكون عدم اليقين متوقعًا ومقاسًا.

أفضل الممارسات والأنماط الخاطئة

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

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

القيود وما الذي لا نعرفه بعد

تعطي صفحة الإيقاف المعرّفات المتأثرة والبديل المقترح وموعد الإزالة. لكنها لا تمنح شهادة سلوك مطابق لكل Prompt أو Tool أو Fine-tune أو Workload. وقد تختلف الأسعار وRate Limits والقدرات حسب الفئة أو تتغير، لذا يجب قراءة صفحة النموذج والتسعير الحالية قبل قرار إنتاجي بدل نسخ رقم ثابت. ولا يستطيع هذا المقال إثبات نجاح ترحيلك من دون آثار تطبيقك ومعايير القبول الخاصة به.

لمنصة OpenAI Evals القائمة مواعيد انتقال معلنة بدورها، فلا تجعل انتهاء منتج تقييم معين عائقًا. الأصل المستدام هو Dataset وGraders ومعايير النجاح بإصدارات واضحة. يمكن تشغيلها في مسار OpenAI حديث أو داخل CI لديك ما دامت المدخلات والمخرجات والقرارات قابلة لإعادة الإنتاج.

قائمة تنفيذية

أولًا، اعثر على كل Model ID مدرج وكل نسخة Fine-tuned منه. ثانيًا، عيّن مالكًا وثبّت مجموعة تقييم ممثلة. ثالثًا، أنشئ عقد طلب محدد الإصدار لـLuna وقرر هل ترحيل Endpoint منفصل. رابعًا، أثبت معنى المخرجات وSchemas والأدوات والرفض والزمن والتكلفة. خامسًا، استخدم Shadow بلا كتابة وCanary على Cohort ثابت وتدرب على Rollback للعقد كاملًا. وأخيرًا، احذف اللقطات والتنبيهات القديمة قبل 14 يناير 2027 بينما يبقى للفريق وقت لإصلاح الفشل.

الموعد ثابت، لكن الترحيل لا يحتاج إلى تهور. تعامل معه كتغيير إنتاجي قائم على الأدلة: جرد، قِس، قيّد، أطلق تدريجيًا، ثم أزل القديم.

إعداد: Noor Yasser