تقييم النماذج اللغوية الكبيرة المُدرَّبة على الشيفرات البرمجية

تدرّب GPT-3 على كمّ هائل من نصوص الإنترنت، فاكتسب فهماً قوياً للغة الطبيعية. لكن كتابة الشيفرات عالمٌ مختلف تماماً: الصياغة صارمة، والمنطق يجب أن يكون متّسقاً بالكامل، والشيفرة لا تُعدّ صحيحة ما لم تجتز اختبارات الوحدة. بعبارة أبسط: أن تُجيد كتابة مقال لا يعني أنك تستطيع كتابة دالة بايثون.

الفكرة الجوهرية في هذه الورقة أنّ البنية الانحدارية الذاتية نفسها التي تتفوّق في التنبؤ بالكلمة التالية في جملة، قادرة أيضاً على التنبؤ بـالرمز التالي في برنامج — بشرط أن تتدرّب على كمية كافية من الشيفرات. جمع الباحثون 159 غيغابايت من ملفات بايثون من 54 مليون مستودع عام على GitHub، ثم كيّفوا GPT-3 على هذه البيانات لإنتاج Codex.

والمفاجأة أنه رغم انطلاق Codex من GPT-3 الذي يملك أصلاً تمثيلات لغوية قوية، لم يُلاحَظ تحسّن في الأداء النهائي مقارنة بـالتدريب من الصفر. الفائدة الوحيدة من البدء بـ GPT-3 كانت تقارباً أسرع أثناء التدريب، لا دقة نهائية أعلى.

ثمّة تفصيل هندسي بالغ الأهمية: مُرمِّز GPT-3 صُمِّم أصلاً للغة الطبيعية حيث الفراغات قليلة ولا تحمل معنى كبيراً. لكن بايثون تعتمد اعتماداً جوهرياً على المسافات البادئة — كل مسافة وكل جدولة لها دلالة بنيوية. لذلك أضاف الباحثون رموزاً خاصة تمثّل تسلسلات الفراغات بأطوال مختلفة، فانخفض عدد الرموز بنحو 30%. قد يبدو هذا تعديلاً بسيطاً، لكن أثره كبير: رموز أقل لكل ملف تعني أن النموذج يرى مساحة أوسع من الشيفرة ضمن نافذة السياق الثابتة، كأنك توسّع له مجال الرؤية أثناء توليد البرامج.

السؤال المحوري: كيف تتأكّد أن الشيفرة التي ولّدها النموذج تعمل فعلاً؟ قبل هذه الورقة، كان التقييم يعتمد غالباً على مقياس BLEU المُستعار من الترجمة الآلية، وهو يقيس مدى التشابه النصّي بين الشيفرة المُولَّدة وحلّ مرجعي. المشكلة أن برنامجين مختلفين تماماً في الشكل قد يؤدّيان الوظيفة ذاتها، وبرنامجان يبدوان متطابقَين قد يسلكان سلوكاً مختلفاً كلياً بسبب تغيير حرف واحد.

لذلك قدّم الباحثون معيار HumanEval: 164 مسألة برمجية ببايثون كُتبت يدوياً، كل منها تضمّ توقيع دالة ووصفاً نصياً للمهمة ومتوسط 7.7 اختبار وحدة. الحلّ لا يُعدّ صحيحاً إلا إذا اجتاز جميع الاختبارات — وهو المعيار نفسه الذي يعمل به المطوّرون البشريون في التطوير المبني على الاختبارات.

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

المقياس الأساسي هو pass@k: ولِّد k عينة شيفرة لكل مسألة، وتُعدّ المسألة محلولة إذا نجحت أيّ عينة منها في اجتياز جميع اختبارات الوحدة. التقدير المباشر لهذا المقياس يعاني من تباين مرتفع، لذلك اشتقّ الباحثون مُقدِّراً غير منحاز. عملياً، يولّدون $n \geq k$ عينة (عادةً $n = 200$) ثم يعدّون الصحيح منها $c$ ويحسبون:

كما بيّن GPT-3 أن أداء النماذج اللغوية يتحسّن وفق قانون قوة منتظم مع الحجم، تكشف ورقة Codex أن النمط ذاته يستمرّ بعد التكييف على الشيفرات. خسارة الاختبار على مجموعة بايثون محجوزة تتبع العلاقة $\left(\frac{N}{5.92 \times 10^7}\right)^{-0.13}$ حيث $N$ عدد المعاملات غير التضمينية.

والأهمّ أن هذا القياس يمتدّ إلى المقياس الوظيفي الذي يهمّنا فعلاً: pass@k. حين ينمو النموذج من 12 مليون إلى 12 مليار معامل، يقفز pass@1 (عند درجة حرارة $T = 0.2$) من 2.0% إلى 28.8%، ويقفز pass@100 (عند $T = 0.8$) من 8.6% إلى 72.3%. العلاقة تتّخذ شكل منحنى سيني في لوغاريتم عدد المعاملات، ما يعني أن ثمّة حجماً حرجاً ينتقل عنده النموذج من توليد شيفرات معطوبة في أغلبها إلى توليد شيفرات تعمل في أغلبها.

هنا ملاحظة عملية مهمة: درجة الحرارة المثلى أثناء التوليد تتوقّف على عدد العينات التي ستولّدها. إن كان لديك محاولة واحدة فقط (pass@1)، فالأفضل حرارة منخفضة $T = 0.2$ حيث يلتزم النموذج بـالرموز الأكثر ترجيحاً ويتجنّب المغامرة. أما إن كان لديك محاولات كثيرة (pass@100)، فالأفضل حرارة أعلى $T = 0.8$ لأن التنوّع في العينات يرفع احتمال أن تحتوي إحداها على الحلّ الصحيح.

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

مقياس pass@k يفترض وجود «أوراكل» — أي أنك تعرف أيّ عينة صحيحة لأنك تملك اختبارات الوحدة. لكن في الواقع العملي، كأداة إكمال تلقائي مثلاً، لا تملك اختبارات. أنت تُولّد عدة حلول مرشّحة وعليك اختيار واحد تعرضه على المستخدم. فكيف تختار؟

قارن الباحثون ثلاث طرق. الأولى: الاختيار العشوائي ببساطة. الثانية: ترتيب العينات حسب متوسط الاحتمال اللوغاريتمي — أي اختيار العينة التي «يثق» بها النموذج أكثر من غيرها. الثالثة: الترجمة العكسية باستخدام Codex-D (الذي يُولّد أوصافاً نصية من الشيفرة)، واختيار العينة التي يصف كودها الوصف الأصلي بأفضل شكل.

النتيجة: ترتيب العينات بالاحتمال اللوغاريتمي تفوّق بوضوح على الاختيار العشوائي وتفوّق قليلاً على الترجمة العكسية. مع Codex-12B عند حرارة 0.8 و100 عينة، حقّق هذا الترتيب دقة 44.5% مقابل 77.5% للأوراكل. بعبارة أخرى: بدون تشغيل أي اختبار، تستطيع استعادة أكثر من نصف ميزة الأوراكل بسؤال بسيط: «أيّ إجابة يثق بها النموذج أكثر؟»

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

لتركيز Codex على المهمة، بنى الباحثون Codex-S بـتكييف إضافي بإشراف على مجموعة منتقاة من الدوال المستقلة المكتوبة بشكل صحيح. جاءت هذه الدوال من مصدرين: مواقع البرمجة التنافسية (لاختبار التفكير الخوارزمي) ومشاريع مفتوحة المصدر تعمل بالتكامل المستمرّ (لاختبار مهارات التنفيذ العملي). بلغ المجموع نحو 50,000 مسألة تدريبية.

وكانت خطوة ضبط الجودة حاسمة: استخدموا Codex-12B نفسه لتوليد 100 عينة لكل مسألة، ثم استبعدوا أيّ مسألة لم تنجح فيها أيّ عينة. بهذه الطريقة تخلّصوا من المسائل الغامضة أو المُفرطة الصعوبة التي كانت ستُدخل ضوضاء في التدريب.

النتائج كانت لافتة: حقّق Codex-S نسبة 37.7% في pass@1 و77.5% في pass@100، مقابل 28.8% و72.3% للنسخة الأساسية — أي أن Codex-S يصل إلى أداء مماثل بنموذج أصغر بمقدار رتبة إلى رتبتين من حيث عدد المعاملات.

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

لبناء Codex-D، أعاد الباحثون ترتيب بيانات التدريب: بدلاً من (التوقيع + الوصف + جسم الدالة)، استخدموا (التوقيع + جسم الدالة + الوصف) ودرّبوا النموذج على التنبؤ بالوصف النصي. وحين قُيِّمت النتائج يدوياً — إذ لا توجد طريقة آلية للحكم على جودة نصّ بشري — حقّق Codex-D نسبة 20.3% في pass@1 و46.5% في pass@10، وهي نسب قريبة من أداء Codex-S في توليد الشيفرات وإن كانت أقلّ قليلاً.

ومن الطرائف أن النموذج يعكس طبيعة بيانات تدريبه: فقد يُنتج أحياناً عبارات مثل «وجدت هذه الدالة على الإنترنت» أو «هذا الاختبار مكتوب بشكل خاطئ وليس من حلولي» — محاكياً أسلوب التوثيق العفوي المنتشر في مستودعات GitHub الحقيقية.

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

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

النمط الثاني هو أخطاء ربط المتغيّرات. حين يتضمّن الوصف النصي عدة عمليات على عدة متغيّرات، كثيراً ما يُطبّق Codex العملية الصحيحة على المتغيّر الخطأ. مثلاً: لو طلبت منه «أضف 3 إلى y واطرح 4 من x وw ثم أعِد حاصل ضرب الأربعة»، قد ينسى إنقاص w ويحسب الناتج بشكل خاطئ. السبب العميق أن النموذج يرى رموزاً متتالية ولا يملك جدول متغيّرات يتتبّع حالتها.

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

ثمّ تبرز مسألة المواءمة: حين يحتوي السياق المُدخَل على شيفرة فيها أخطاء، يميل Codex إلى محاكاة تلك الأخطاء بدلاً من تصحيحها. والمفارقة أن المشكلة تزداد سوءاً مع النماذج الأكبر — لأنها أمهر في محاكاة أسلوب المُدخَل بما فيه عيوبه. فالنموذج مُحسَّن للتنبؤ بما يلي السياق في توزيع التدريب، لا لأن يكون مفيداً للمستخدم. نموذج عالي القدرة لكنه غير مُوائَم قد يُنتج شيفرة مُموَّهة تبدو سليمة عند التدقيق لكنها تفعل شيئاً غير مرغوب.

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

ورقة Codex لحظة فاصلة في تاريخ المجال. قبلها كان توليد الشيفرات فضولاً أكاديمياً بلا فائدة عملية تُذكر. بعدها تحوّلت البرمجة بمساعدة الذكاء الاصطناعي إلى صناعة تُقدَّر بمليارات الدولارات. لا يزال HumanEval المعيار الأكثر استشهاداً في تقييم توليد الشيفرات، ومقياس pass@k الذي قدّمته هذه الورقة أصبح الطريقة القياسية لتقييم مولّدات الشيفرات. كل نموذج جاء بعدها — StarCoder وCode Llama وGPT-4 وClaude — يبني على الأساس الذي أرسته Codex.