GPT-6.1 Sol على COBOL: 86.6% مقابل 5.4%، ولا يمكن إعادة تشغيل سوى واحد من الاختبارين

في 19 أكتوبر 2026، نشرت OpenAI تقييمين برمجيين للغات منخفضة الموارد، ويعود الرقم الرئيسي إلى GPT-6.1 Sol: نجحت 86.6% من مهام ترحيل COBOL عند جهد استدلال منخفض، مقابل 5.4% لـGPT-5.6 Sol عند الإعداد نفسه، وترتفع إلى 97.9% عند زيادة الجهد. التقييم الثاني، MultiLangBench، قصة نموذج مختلف — GPT-6 Astra حقّق متوسط 87.4% عبر عشرين لغة عند أقصى جهد — لكنه النصف الأكثر فائدة من الإصدار، لأن OpenAI وضعت أداة الاختبار الخاصة بها على GitHub بموجب Apache-2.0 ويمكنك تشغيلها بنفسك بعد ظهر اليوم. تقييم ترحيل COBOL، الذي يحمل نسبة 86.6%، مسألة مختلفة: اختباراته مخفية، ومعيار نجاحه هو تطابق المخرجات بايتًا ببايت مع حالات لم يرها أحد خارج OpenAI، ولم يكرّره أي طرف ثالث. هذا التفاوت هو القصة كلها، ويجدر قوله بوضوح قبل أن يُقتبس أي من الرقمين في دراسة جدوى لترحيل. تُجمع حالات فشل الذكاء الاصطناعي وحوادث الوكلاء الموثقة التي تقف وراء إصدارات كهذا في أرشيف حوادث OrcaRouter AI حيث يحمل كل مدخل مصادره الخاصة ودرجة الخطورة ودرجة الثقة وعلامة النزاع.

تاريخ واحد يجب ألا تختلط فيه الأمور. GPT-6.1 Sol نفسه يعود إلى 29 سبتمبر 2026 — وهذا ليس إطلاقًا، ولا شيء هنا يغيّر أوزان النموذج أو سعره أو بطاقة أسعاره. ما حدث في 19 أكتوبر هو أن OpenAI نشرت أدلة على ما يستطيع النموذج فعله في فئة لم تكن قد وثّقتها من قبل، وأصدرت معيارًا قياسيًا يمكن لأي شخص إعادة تشغيله. هذا هو الحدث الذي يتناوله هذا المقال.

ما الذي نُشر فعليًا، وما الغرض من كل نصفٍ منه

يجيب التقييمان عن سؤالين مختلفين، وصياغة OpenAI الخاصة تفصل بينهما. يسأل MultiLangBench عما إذا كان بإمكان نموذج أن يبني شيئًا بلغة لا يتدرّب عليها أحد: تنفيذ SQLite 3.40.1 من الصفر بإحدى لغات البرمجة العشرين، ثم اجتياز مجموعة اختبارات توافق قواعد البيانات. يسأل تقييم ترحيل COBOL عما إذا كان بإمكان نموذج أن ينقل شيئًا: يترجم برامج COBOL إلى C++ أو Java أو Kotlin أو Python أو Rust مع الحفاظ على السلوك الملحوظ بدقة تامة.

الأول اختبار للحد الأدنى من القدرات. أما الثاني فهو ما تهتم به المؤسسات فعلاً، لأن COBOL ليس مجرد فضول في معايير الأداء — فتقديرات IBM الراسخة تضع COBOL وراء أكثر من 40% من أنظمة الخدمات المصرفية عبر الإنترنت وحوالي 95% من معاملات الصراف الآلي، كما أن الكود تتم صيانته بواسطة قوة عاملة لا يجري استبدالها.

• MultiLangBench، بأقصى جهد — GPT-6 Astra 87.4%، وGPT-6 Luna 40.3%، وGPT-5.6 Sol 26.8%. حقق Astra نسبة 83% في 19 من أصل 20 لغة؛ وكان COBOL أضعف نقاطه عند 72.1% مقابل 10.9% لـ GPT-5.6 Sol، وهو ما يخبرك أن أصعب لغة في المجموعة لا تزال تلك التي تمتلك أقدم الأدوات.

• ترحيل COBOL بجهد منخفض — GPT-6.1 Sol 86.6%، وGPT-5.6 Sol 5.4%، بتكلفة تقديرية تبلغ 61% من تكلفة واجهة API للطراز الأقدم في تشغيل التقييم، أي أقل بنسبة 39%.

• ترحيل COBOL، جهد أعلى — GPT-6.1 Sol 97.9%، وهو ما تصفه OpenAI بأنه قريب من التشبع.

• تفاصيل لكل لغة نشرتها OpenAI بالفعل — Fortran بنسبة 83.5% لـ Astra مقابل 21.4% لـ GPT-5.6 Sol؛ Visual Basic بنسبة 89.4% مقابل 27.5%؛ OCaml بنسبة 85.8% مقابل 25.6%؛ GPT-6 Luna بنسبة 17.1% على COBOL، و31.4% على Fortran، و34.1% على OCaml و41.6% على Visual Basic.

• تكلفة كل عينة على MultiLangBench — بتكلفة مقدّرة تبلغ 0.77 دولارًا لـ GPT-6 Luna مقابل 3.48 دولارًا لـ GPT-5.6 Sol، أي أقل بنحو 78%، وهو الرقم الذي يجعل أضعف نموذج على اللوحة هو الخيار المثير للاهتمام بالنسبة إلى خط أنابيب توليد البناء.

التقييم الذي يمكنك إعادة تشغيله: ما الذي يطلبه MultiLangBench فعليًا

المستودع موجود على github.com/openai/MultiLangBench، بترخيص Apache-2.0، وقراءة أداة الاختبار (harness) أكثر إفادة من قراءة لوحة الصدارة. المهمة محددة بما يكفي بحيث لا يستطيع النموذج التلاعب بها: أنتِج ملفًا تنفيذيًا يأخذ مسار قاعدة بيانات كوسيط سطر أوامر، ويقرأ استعلام SQL من الإدخال القياسي، ويتصرف مثل SQLite 3.40.1. تأتي الاختبارات من مجموعة اختبارات TCL الخاصة بـ SQLite — نحو 51,000 اختبار إجمالًا، حُوِّل منها قرابة 24,000 إلى الثلاثيات التي تستخدمها أداة الاختبار: قاعدة بيانات أولية، واستعلام مستخدم، واستعلام تحقق. أسماء الاختبارات هي تجزئات SHA-256 لتلك المكونات، لذا لا يمكن حفظ مجموعة الاختبارات عن ظهر قلب بالاسم.

القواعد هي حيث تكمن الصعوبة، وكل واحدة منها تُغلق طريقًا مختصرًا:

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

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

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

• يتضمن التشغيل السريع 272 اختبارًا، وليس 24,000. يوصي README بتشغيل فقط الاختبارات التي تبدأ أسماؤها بـ00، 01 أو 02 عندما تريد رقمًا قابلًا للمقارنة. هذا هو التفصيل الذي ينبغي ملاحظته قبل مقارنة نتيجتك بنتيجة O​penAI: فتشغيل المجموعة الكاملة والتشغيل السريع ليسا القياس نفسه، وREADME يقول ذلك.

هذا معيار قياس حقيقي وقابل للتحقق. وهو يخبرك أيضًا بشيء لم تذكره التغطية الصحفية: أن رقم 87.4% الرئيسي قِيس على مجموعة اختبارات يمكنك توجيهها إلى نموذجك الخاص، وهو أمر نادر بما يكفي ليكون جديرًا بالتنزيل.

التقييم الذي لا يمكنك إعادة تشغيله، ولماذا لا يُعد ذلك فضيحة تلقائيًا

تقييم ترحيل COBOL مُصمَّم من O​penAI، ويُدار بواسطة O​penAI، ويُقيَّم بواسطة O​penAI، وحالات اختباره غير منشورة. عتبة النجاح مُعلنة بدقة — فلا يُحتسب الترحيل إلا إذا أنتج كل اختبار مخفي مخرجات قابلة للملاحظة متطابقة بايتًا ببايت — وهذه الدقة تحديدًا هي ما يجعل النتيجة غير قابلة للتحقق من الخارج: فنسبة 86.6% هي قياس O​penAI مقابل حالات O​penAI المخفية الخاصة بها. وواحدة فقط من التقييمين الواردين في الإصدار هي ما يستطيع القارئ إعادة إنتاجه.

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

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

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

ما الذي ينبغي أن يغيّره 86.6% و97.9% في قرار؟

القراءة الأمينة أضيق نطاقًا من العناوين الرئيسية وأكثر فائدة منها. فخط أساس بنسبة 5.4% ليس نموذجًا يعمل بشكل جزئي؛ بل نموذج لا يكاد ينتج ترجمة تحافظ على السلوك، لذا لم يكن الجيل الأقدم مرشحًا لهذا العمل قط. أما GPT-6.1 Sol عند 86.6% فهو ضمن النطاق الذي تنقلب فيه المعادلة الاقتصادية: أداة تضع مسودة لمعظم الترجمة وتترك للمراجع التحقق منها هي منتج مختلف عن أداة لا تنتج شيئًا صالحًا للاستخدام.

نسبة 97.9% عند الجهد الأعلى هي الرقم الذي ينبغي التشكيك فيه، لا لأنه خاطئ بل لأنه مشبع. فبمجرد أن يقترب معيار قياس من سقفه، يتوقف عن التمييز بين النماذج ويبدأ في قياس مجموعة الاختبارات، وهذا ما يقوله OpenAI صراحةً. لأغراض التخطيط، تعامل مع 86.6% عند الجهد المنخفض كنقطة تشغيل منخفضة التكلفة، ومع 97.9% كسقف لما يمكن أن يُظهره التقييم — لا كوعد بالدقة ينطبق على قاعدة شفرتك.

هناك أيضًا تحقق متقاطع يستحق العناء، وهو يتعارض مع الضجة الترويجية. في اختبار البناء، بقي COBOL أضعف لغة لدى GPT-6 Astra عند 72.1% رغم أن Astra هو النموذج الأقوى إجمالًا بمتوسط 87.4%. واللغة صعبة في كلا الاتجاهين. النموذج الذي يهاجر شيفرة COBOL جيدًا في تقييم خفي ليس جيدًا في COBOL بذلك؛ بل هو جيد في النمط الذي تعاينه أداة التقييم.

الشيء الآخر الذي حدث هذا الأسبوع: ادعاء أثر الاستدلال

قال منشور واسع الانتشار في 21 أكتوبر إن تتبعات استدلال GPT-6.1 Sol "مقروءة بالكامل، ولا شيء يدعو للقلق". لا شيء في منشور OpenAI في 19 أكتوبر، ولا شيء في صفحة توثيق النموذج نفسه، يدعم ذلك بوصفه تغييراً في ما تعيده واجهة API. ويوضح دليل الاستدلال لدى OpenAI صراحةً أن رموز الاستدلال الخام غير مكشوفة — إذ تبقى عناصر الاستدلال غير شفافة — وأن ما يمكنك طلبه هو ملخص للاستدلال عبر summary كمعامل، مع إعادة تشغيل محتوى الاستدلال المشفّر عبر الجولات. يدعم GPT-6.1 Sol صيغة all_turns لتلك الإعادة. قناة الملخص ليست أثراً مقروءاً، والخلط بين الاثنين هو كيف تُصاغ ادعاءات السلامة عبر لقطة شاشة.

ما يمكن قياسه قريب الصلة وأكثر إثارة للاهتمام لأي شخص يدقق في وكيل. وجد تقييم Sonar في 9 أكتوبر لـ GPT-6.1 Sol، الذي شُغّل مقابل GPT-6 Sol بجهد متوسط على 4,444 مهمة Java، أن رموز الاستدلال انخفضت بنسبة 51.4% — من 2.64M إلى 1.28M — بينما انخفضت حصة الاستدلال من المخرجات من 41.8% إلى 19.5%، وارتفعت المخرجات، وتحسّن معدل النجاح الوظيفي من 83.09% إلى 85.29%. ووجد التشغيل نفسه أن كثافة الثغرات انخفضت بنسبة 32.4% لكن نتائج الموثوقية ذات الخطورة الحرجة ارتفعت من 21 إلى 46، مع أخطاء التزامن كأكبر فئة عند 196 نتيجة. هذه مقايضة يمكن للمراجع أن يتصرف بناءً عليها. أما «التتبعات قابلة للقراءة» فليست كذلك، لأن التتبعات ليست ما يتم إرجاعه.

بالنسبة لمشروع ترحيل، يهم هذا بطريقة ملموسة واحدة: أثر التدقيق لديك هو الفرق ومخرجات الاختبار، وليس سرد النموذج. خصّص سعة المراجعة وفقًا لذلك — فنتيجة Sonar بأن كودًا مولّدًا أكثر بنسبة 39.4% أنتج 12,982 نتيجة إجمالية مقابل 9,859 هي شكل التكلفة التي تختبئ خلف درجة معيارية.

أن تشغّل كلا الذراعين بنفسك

المشكلة العملية في مقارنة كهذه هي أن ذراع خط الأساس والذراع الجديدة عادةً ما تكونان عقدين ومفتاحين وعلاقتَي فوترة، وهو قدر من الاحتكاك يكفي ألّا يشغّل أحد خط الأساس. كلا النموذجين متاحان في كتالوجنا عبر مفتاح واحد: openai/gpt-6.1-sol و openai/gpt-5.6-sol، بأسعار OpenAI المعلنة بهامش ربح 0%، أي نفس سعر 2.00 دولار للإدخال و10.00 دولارات للإخراج لكل مليون رمز ستدفعه إلى المورّد، مع الإدخال المخزّن مؤقتًا بسعر 0.10 دولار وكتابات الذاكرة المؤقتة بسعر 2.50 دولار، والشريحة التي تتجاوز 272K تُمرَّر بسعر 4.00 و0.20 و5.00 و15.00 دولار. أي تغيير في أسعار المورّد يصبح ساريًا هنا في يوم نشره بدلًا من مراجعة العقد التالية.

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

أداة الاختبار MultiLangBench متاحة للعموم، أما حالات ترحيل COBOL فليست كذلك، لذا فإن الاختبار الصادق الوحيد لنسبة 86.6% هو الذي تبنيه بنفسك: خُذ عينة من بضع مئات من برامج COBOL الخاصة بك، وترجمها، ثم قارن المخرجات بايتًا بايت مقابل السلوك الأصلي. ذلك عمل يستغرق أسبوعًا، وهو يستحق أكثر من جدول المورّد.

ماذا تشاهد بعد ذلك

ثمة ثلاثة أمور من شأنها أن تغيّر هذه الصورة، ولم يحدث أي منها بعد. نشر OpenAI لحالات ترحيل COBOL، أو إعادة مختبر مستقل تشغيلها، سيحوّل رقمًا صادرًا عن مورّد إلى قياس. وإعادة طرف ثالث إنتاج جدول MultiLangBench حسب اللغة ستخبرنا ما إذا كانت نسبة 72.1% الخاصة بـ COBOL سمةً للغة أم لمجموعة الاختبارات. وسجل النموذج المستقل في المعايير — إذ تضع Artificial Analysis حاليًا GPT-6.1 Sol عند مؤشر Intelligence Index بقيمة 52، في المرتبة الثانية عشرة من بين 214 نموذجًا، وبسرعة 55.2 رمز إخراج في الثانية وبتكلفة 0.72 دولار لكل مهمة مؤشر — هو الفحص الذي لا يعتمد على تقييمات OpenAI الخاصة إطلاقًا.

حتى ذلك الحين، الملخص المفيد قصير. GPT-6.1 Sol نموذج من 29 سبتمبر وُثّقت قدرته على التعامل مع الشيفرة القديمة في 19 أكتوبر، في تقييم واحد تستطيع تشغيله وآخر لا تستطيع. التقييم القابل للتشغيل يقول إن الجيل الجديد في فئة مختلفة فيما يخص اللغات قليلة الموارد. أما غير القابل للتشغيل فيقول إن ترحيل COBOL أصبح يستحق تجربة أولية. قاعدة الشيفرة الخاصة بك وحدها يمكنها تحويل أيٍّ منهما إلى قرار.