OpenAI تطلق GPT-6 Astra على الشيفرة القديمة: حذف 800 ألف سطر خلال أسبوعين

يتولى فريق Core Experimentation في OpenAI مسؤولية نظام التجارب في الشركة بأكملها. وقد عرض الفريق كيف ينظّف GPT-6 Astra الشيفرة القديمة بدل أن يكتب شيفرة جديدة. دمج خمسة مهندسين أكثر من 1 400 PR خلال أسبوعين، وحذفوا أكثر من 800 ألف سطر. وتقلّص حجم صورة (image) إحدى الخدمات من 3,31 إلى 1,72 GB، وانخفض زمن CI إلى ما يقارب النصف. نُشرت القصة في مدوّنة OpenAI للمطوّرين، وهي من أكثر حالات استخدام الوكلاء (agents) واقعية في قاعدة شيفرة كبيرة.

توجيه بأخطاء إملائية بدل التحليل الساكن

كان البحث عن الشيفرة الميتة يعتمد سابقًا على التحليل الساكن وسجلات وقت التشغيل. ومع ذلك وقعت حوادث بسبب حذف خاطئ. هذه المرة كتب المهندسون للنموذج طلبًا واحدًا مرتجلًا يحوي أخطاء إملائية، وتركوه في المدوّنة كما هو: «Can you help identify and clean up dead code in the repo please, feel free to check slack, statsig [a feature flag and experimentation platform we use], or any other source you need to confirm that things are indeed no longer being used and can be cleaned up or simplified».

لم يكتفِ النموذج بالمستودع. فقد بحث بنفسه في طلبات PR القديمة ومحادثات Slack وأنظمة تتبّع المهام وقياسات الأداء في بيئة الإنتاج، وأرفق بكل عملية حذف شرحًا لسبب اعتبار الشيفرة ميتة. وهكذا تلقّى المراجع حججًا ومصادر، لا مجرد diff مجرّد. وأُزيل من الاختبارات نحو 400 نسخة من اللقطات المرئية (visual snapshots).

علَم «Permanent» الذي استهلك CPU لسنوات

التجارب القديمة وأعلام الميزات (feature flags) المتقادمة أصعب، لأن هذه الشيفرة قد تظل قيد التنفيذ في بيئة الإنتاج. وقد كلّف المهندسون النموذج نفسه بكتابة توجيه التدقيق الكامل. كما حسب النموذج كلفة كل علَم من حيث CPU.

عثر النموذج على علَم كان يضاعف الفحوصات بصمت لسنوات على جميع الميزات دفعة واحدة. لكنه لم يحذفه بنفسه لأنه كان مصنّفًا «Permanent»، وأحال المسألة إلى مراجعة بشرية. وبعد الحذف وفّرت الخدمة نحو 0,42% من CPU. وعلى نطاق OpenAI فهذا مبلغ لا يستهان به، كما يبدو حدّ الاستقلالية هنا معقولًا.

حسابات التدقيق: Astra وSol وكلفة النتيجة الواحدة

الجزء الأكثر عملية في هذه الحالة هو مقارنة النماذج في تدقيق واحد: 6 000 ملف و1 مليون سطر بلغات Python وTypeScript وGo وRust.

• GPT-6 Astra Ultra: $109,06، و142 نتيجة، و$0,77 للنتيجة الواحدة
• GPT-6.1 Sol Ultra: $15,12، و131 نتيجة، و$0,12 للنتيجة الواحدة
• GPT-6.1 Sol Medium: $5,27، و86 نتيجة، و$0,06 للنتيجة الواحدة

يحقق Sol Ultra 92% من النتائج بـ14% من التكلفة. وأظهر تحليل الفارق أن Sol كان يفوّت الأعلام التي تعتمد عليها أعلام أخرى. وعولج ذلك بتعديل التوجيه. والاستنتاج العملي أن نموذجًا متوسطًا مع تعليمات دقيقة يلحق بالنموذج الأعلى في هذا النوع من المهام.

وبالطريقة نفسها جرى تسريع CI. طُلب من النموذج اقتراح تحسينات وترتيبها بحسب التوفير المتوقع في دقائق CI يوميًا، استنادًا إلى سجل تشغيل المستودع. وكان الطلب كالتالي: «What ideas do you have to relieve CI load in this repository? List your ideas in a table and rank all of them by estimated CI minutes saved per day based on this repo's CI run history». وكانت النتائج:

• دمج نحو 30 PR
• انخفض وسيط CI من نحو 10 إلى 4,5 دقيقة
• تراجع p90 من 12,5 إلى 6 دقائق
• تسارعت مجموعة من 63 اختبارًا من 592,6 إلى 29,8 ثانية، أي بنحو 20 ضعفًا

ويقرّ المؤلفون بصراحة بأن بعض الاقتراحات أضافت تعقيدًا أكثر من فائدتها. فالنموذج يجد من التحسينات ما يكفي لإغراقك فيها إذا غابت الأولويات والمقاييس.

إذا كانت لديك شيفرة قديمة، فالوصفة بسيطة. اختر مهمة صغيرة واحدة: شيفرة ميتة أو علَمًا متقادمًا أو اختبارًا غير مستقر (flaky). شغّلها على عدة نماذج ومستويات جهد (effort)، وقارن كلفة النتيجة الواحدة. أضف تعليقات المراجعة إلى التوجيه التالي كي يتعلّم النموذج من قواعدك، مثل الأعلام ذات الاعتمادات. وعندما تستقر النتيجة، وسّع النطاق إلى أجزاء كبيرة من قاعدة الشيفرة. ضع علامات على المواضع الحرجة، كما فُعل مع «Permanent»، ليبقى القرار بيد الإنسان. وبالنسبة إلى الشركات التي تراكم عليها دين تقني، فهذا على الأرجح أسرع عائد استثمار (ROI) من الوكلاء: إذ تُقاس النتيجة بعدد الأسطر وغيغابايتات الصورة (image) ودقائق CI.