نتائج OpenAI للغات قليلة الموارد: رحّل الأنظمة القديمة بالسلوك لا بالترجمة

تشير تقييمات OpenAI الجديدة للغات البرمجة قليلة الموارد إلى أن نماذج البرمجة الحالية تستطيع تقديم عمل أكثر فائدة في COBOL وFortran وPascal ولغات لا تغطيها الاختبارات الشائعة جيدًا. لكن الدرس العملي ليس أن تطلب من النموذج «ترجمة المستودع». المطلوب هو تعريف السلوك الظاهر كعقد، وبناء اختبارات Characterization حوله، وترحيل أجزاء محدودة، وفرض تطابق حتمي قبل أي انتقال إنتاجي. يناسب ذلك فرق تحديث الأنظمة القديمة، لكنه لا يثبت أن نموذجًا مستقلًا يستطيع استبدال خبراء المجال بأمان.

نشرت OpenAI النتائج في 19 أكتوبر 2026. قدمت MultiLangBench التي تطلب بناء محرك متوافق مع SQLite عبر 20 لغة، وتقييمًا منفصلًا لترحيل COBOL يتحقق من الحفاظ على السلوك عند النقل إلى C++ وJava وKotlin وPython وRust. الأرقام التالية نتائج أبلغت عنها OpenAI، وليست قياسات مستقلة أو ضمانات إنتاجية.

ماذا قاست OpenAI فعلًا؟

تختبر MultiLangBench قدرة النموذج على تنفيذ نظام كبير نسبيًا بلغات تشمل لغات قليلة الموارد، لا مجرد حل مسائل Syntax قصيرة. تقول OpenAI إن GPT-6 Astra حقق متوسط 87.4% مقابل 26.8% لـGPT-5.6 Sol. كما تذكر أن GPT-6 Luna حقق 40.3% بتكلفة API تقديرية أقل بنحو 78% من GPT-5.6 Sol في ذلك التقييم.

أما تقييم COBOL فهو الأقرب لمشاريع التحديث. فهو يتحقق مما إذا كان النموذج يستطيع إعادة كتابة البرامج مع الحفاظ على السلوك الظاهر. أبلغت OpenAI عن 86.6% لـGPT-6.1 Sol بجهد Reasoning منخفض مقابل 5.4% لـGPT-5.6 Sol، وعن 97.9% لـGPT-6.1 Sol عند جهد أعلى. وتوضح الشركة صراحة أن تحديث الإنتاج ما يزال يحتاج مراجعة الخبراء واختبار قواعد العمل والاعتماديات.

تدعم هذه النتائج استنتاجين محدودين: تحسنت قدرة النماذج في اللغات الأقل تمثيلًا، ويجب أن يقيس التقييم سلوك البرنامج لا شكل الكود المقنع. لكنها لا تثبت أن النموذج يعرف سياسة محاسبية غير موثقة، أو جدول Batch إنتاجيًا، أو التزامًا نظاميًا، أو حلول المشغلين اليدوية، أو كل عقود الملفات الخارجية حول البرنامج القديم.

اجعل السلوك عقد الترحيل

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

ابدأ بتسجيل السلوك قبل توليد البديل. ابنِ Characterization Tests من حالات إنتاج ممثلة بعد إزالة البيانات الحساسة. أضف حدود التواريخ والملفات الفارغة وأقصى عرض للحقول والقيم السالبة والسجلات المكررة والترميزات غير الصالحة وانقطاع Batch. التقط كل Byte من الخرج عندما يكون التنسيق الدقيق جزءًا من الواجهة.

تحتاج الدلالات العددية في COBOL اهتمامًا خاصًا. قد تغير تعريفات Fixed-point والاقتطاع والتقريب والفيض والدقة الوسيطة نتيجة مالية رغم نجاح Compile. وقد تسبب Encoding وCollating Sequence وPacked Decimal وRecord Layout وسلوك نهاية الملف اختلافات صامتة. لذلك يجب أن يقارن الاختبار نتيجة العمل والواجهة المتسلسلة، لا قيمة مطبوعة في المسار السعيد فقط.

افهم النظام قبل اختيار النموذج

يبدأ تحديث النظام القديم بخريطة اعتماديات. حدد نقاط الدخول وCopybooks وInclude Files ومخططات قواعد البيانات وصيغ الرسائل وJob-control Scripts والـSchedulers والتقارير اللاحقة ونقل الملفات وإجراءات الاستعادة التشغيلية. صنف المكونات حسب أثرها؛ Report Formatter ليس مساويًا لحساب تسوية مالية.

استخدم نموذج Reasoning أقوى لفهم المستودع وتحليل الاعتماديات بين الملفات والتحويلات عالية الخطر. يمكن لنموذج أقل تكلفة المساعدة في جرد الوحدات أو اقتراح الاختبارات أو ترحيل وحدات متكررة منخفضة المخاطر، لكن كل ناتج يعبر البوابات الحتمية نفسها. Model Routing قرار تكلفة وكمون داخل العملية، ولا يخفف عقد القبول.

احفظ نسخة من الحزمة الكاملة: Model Snapshot وإعداد Reasoning وتعليمات النظام والسياق والأدوات والقطع المولدة. من دونها لن تستطيع إعادة إنتاج عيب أو مقارنة نموذج لاحق بعدل. يشرح دليل ترحيل GPT-4 API تخطيط التوافق والـSnapshots، ويشرح عقد تقييم AI القابل للنقل تثبيت معايير الإصدار عبر المزودين.

استخدم Strangler Workflow بدل إعادة كتابة شاملة

قسّم النظام عند حد يمكن ملاحظته: خطوة Batch أو تقرير أو نوع معاملة أو Service Boundary. جمّد البرنامج القديم كمرجع لذلك الجزء، وابنِ البديل، ثم شغل التنفيذين على المدخل المنقح نفسه. يجب أن تصنف خدمة المقارنة كل فرق إلى متوقع أو عيب أو قاعدة ملتبسة أو خطأ في Fixture.

المسار الآمن يكون كالتالي:

1. اجرد الاعتماديات ورتب مخاطر العمل؛ 2. التقط Golden Inputs وOutputs وانتقالات الحالة؛ 3. ولّد الاختبارات قبل الكود البديل؛ 4. رحّل مكونًا محدودًا واحدًا؛ 5. نفذ Compile وScan واختبارات تطابق حتمية؛ 6. شغل المسارين القديم والجديد في Shadow Mode؛ 7. راجع الفروق غير المفسرة مع مالكي المجال؛ 8. أطلق Canary صغيرة مع Rollback جاهز؛ 9. توسع فقط ما دام التطابق والأهداف التشغيلية سليمين.

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

اقرأ الاختبار كنقطة بداية لا كـSLA

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

ابنِ تقييمًا خاصًا من وحدات ترحيل حقيقية. قس نجاح Compile والتطابق الوظيفي والتطابق الدقيق للخرج ونتائج الأمان وتصحيحات المراجع والعيوب الهاربة والوقت حتى قبول التغيير وتكلفة النموذج الكلية. قسّم النتائج حسب اللغة والنظام الفرعي ودرجة الخطر وإعداد النموذج. نسبة 95% بلا معنى إذا احتوت الـ5% الباقية عيوبًا مالية أو صلاحيات خاطئة.

احتفظ بـHoldout لا يراه مؤلفو Prompt. أعد تشغيله عند تغيير النموذج أو جهد Reasoning أو التعليمات أو الأدوات أو Compiler. يجب أن تفشل بوابة الإصدار عند أثر ممنوع أو Regression أمني أو فرق عالي الخطر بلا تفسير، حتى لو تحسن المتوسط.

أمّن حدود Coding Agent

غالبًا تحتوي المستودعات القديمة Credentials ومعرفات عملاء وProduction Endpoints وخوارزميات حساسة تجاريًا. احذف الأسرار قبل وصول النموذج، وقلل صلاحيات المستودع والشبكة، وشغل Compilers والاختبارات في بيئات معزولة مؤقتة. امنح Agent قراءة افتراضيًا، واجعل الكتابة عبر Patches مراجعة.

عامل Tool Output كمدخل غير موثوق. قد يحتوي Build Log أو README أو تعليق داخل المصدر تعليمات تناقض سياسة الترحيل. يجب أن يعامل Orchestrator نص المستودع كبيانات، ويبقي Authorization خارج النموذج، ويقيد الأوامر بـAllowlist. يشرح دليل معمارية OpenAI Agents API الموافقات والعزل وضوابط Trace عند التنفيذ الوكيلي.

لا ترسل كودًا منظمًا أو سريًا إلى خدمة قبل موافقة مالكي القانون والأمن وحوكمة البيانات على شروط المعالجة والاحتفاظ. احمِ Evaluation Fixtures كبيانات شبيهة بالإنتاج، ولا تنسخ المصدر الخام أو سجلات العملاء إلى أنظمة Observability واسعة الصلاحية.

متى يناسب الترحيل بمساعدة AI؟

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

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

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

إعداد: Noor Yasser