When Uncertainty Isn't Enough: An Empirical Study of Self-Correction in Code Generation

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

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

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

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

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