RefactorAssist: Agentic Refinement for Reliable Code Refactoring
تقدم هذه الورقة البحثية RefactorAssist، وهو إطار عمل وكيل (agentic framework) يجمع بين الإصلاح الاستاتيكي والتحسين التكراري الموجه بالاختبارات باستخدام سجلات الأخطاء واسترجاع السياق لتحسين الصحة الوظيفية وموثوقية عمليات إعادة صياغة الكود (refactoring) الناتجة عن النماذج اللغوية الكبيرة بشكل كبير.
البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل
تخيل أنك مهندس معماري ماهر أمضيت سنوات في تصميم قلعة رائعة ومعقدة. الآن، تخيل أنك وظفت مساعداً آلياً (روبوت) فائق الذكاء والسرعة لمساعدتك في تجديدها. هدفك ليس تغيير كيفية عمل القلعة — فلا يزال يتعين على الناس الانتقال من المطبخ إلى غرفة النوم دون السقوط عبر الأرضية — ولكن جعل الممرات أوسع، والغرف أكثر إشراقاً، والهيكل أسهل في الصيانة. هذا هو عالم إعادة هيكلة الكود (Code Refactoring): عملية تنظيف وتنظيم كود الكمبيوتر لجعله أفضل، دون كسر البرمجيات التي يشغلها.
لفترة طويلة، امتلكنا أدوات تعمل مثل مدققات الأخطاء الإملائية الأساسية للكود: تشير إلى التنسيق الفوضوي أو الأخطاء الواضحة. ولكن مؤخراً، وصل نوع جديد من "الروبوتات": نماذج اللغات الكبيرة (LLMs). فكر في هذه النماذج كأنها مساعدون آليون قرأوا كل كتاب، ودليل، وورقة تعليمات كُتبت على الإطلاق. إنهم مذهلون في كتابة قصص جديدة أو إصلاح الجمل المكسورة. ومع ذلك، عندما تطلب منهم تجديد قلعة معقدة (مشروع برمجيات)، فإنهم أحياناً يصبحون مبدعين أكثر من اللازم. قد ينقلون جداراً يدعم السقف، أو يعيدون تسمية باب بطريقة تربك كل من يحاول العثور على المطبخ. السؤال الكبير الذي يواجه العلماء والمهندسين هو: هل يمكننا الوثوق بهذه الروبوتات الذكية للقيام بعملية التجديد بأمان، أم أنهم بحاجة إلى مشرف بشري للتحقق من عملهم؟
هذا هو بالضبط ما تبحث فيه ورقة البحث "RefactorAssist: التكرار الوكيل لإعادة الهيكلة الموثوقة للكود". أراد الباحثون، جوناثان كورديرو، وشايان نوي، وينغ زو، معرفة ما إذا كان بإمكان هذه الروبوتات الذكية إصلاح الكود دون كسره، وإذا كانت قد كسرت شيئاً ما، فهل يمكن لـ "وكيل إصلاح" ذكي أن يصلح أخطاء الروبوت؟
محاولة الروبوت الأولى: مزيج متناقض
بدأ الفريق بسؤال عدة نماذج ذكاء اصطناعي مختلفة (بما في ذلك بعض النماذج مفتوحة المصدر مثل StarCoder2 والنماذج التجارية القوية مثل GPT-4o) للقيام بعمليات تجديد على مشاريع برمجية حقيقية بلغة Java. لقد عاملوا البرمجيات ككائن حي لديه نظام "فحص صحة" مدمج يسمى اختبارات الوحدة (unit tests). هذه الاختبارات تشبه سلسلة من نقاط التفتيش: إذا تم تغيير الكود بشكل صحيح، يتجاوز الروبوت الاختبار؛ وإذا كسر الروبوت وظيفة ما بالخطأ، يفشل الاختبار.
كانت النتائج صادمة نوعاً ما. حتى أفضل نماذج الذكاء الاصطناني، مثل GPT-4o، نجحت في إتمام عملية التجديد بشكل صحيح بنسبة 80.8% فقط. وهذا يعني أنه في حوالي مرة واحدة من كل 5 مرات، حاول الذكاء الاصطناعي تحسين الكود ولكنه كسر شيئاً ما بالخطأ، مما تسبب في فشل البرمجيات في اختبارات الصحة الخاصة بها. وجد الباحثون أن مجرد إعطاء الذكاء الاصطناعي المزيد من الأمثلة حول كيفية التجديد (تقنية تسمى "few-shot prompting") لم يساعد كثيراً. لم تكن المشكلة في أن الذكاء الاصطناعي لا يعرف كيف يقوم بالتجديد؛ بل في أنه لم يفهم السياق جيداً بما يكفي لتجنب ارتكاب أخطاء دقيقة وخطيرة.
لماذا فشلت الروبوتات؟
لمعرفة ما حدث، تصرف الباحثون كالمحققين، حيث فحصوا "مسارح الجريمة" للكود الفاشل. واكتشفوا أن أخطاء الذكاء الاصطناعي تندرج تحت ثماني فئات رئيسية، وأكثرها شيوعاً هي:
- الهلوسة وارتباك السياق (24.3%): كان الذكاء الاصطناعي يخترع ميزات جديدة أو يغير أشياءً لم تكن بحاجة للتغيير لأنه أساء فهم قصة الكود.
- إعادة التسمية غير المتسقة (15.3%): كان الذكاء الاصطناعي يعيد تسمية متغير (مثل تسمية "الباب" بـ "البوابة") في مكان ما، لكنه ينسى تحديث الاسم في كل مكان آخر، مما يترك الكود في حالة ارتباك.
- إضافة أشياء جديدة (13.7%): كان الذكاء الاصطناعي يضيف عن طريق الخطأ متغيرات أو وظائف جديدة لم يكن من المفترض أن تكون موجودة.
- الكود غير المكتمل (11.3%): كان الذكاء الاصطناعي يتوقف عن كتابة الكود في منتصف الطريق، تاركاً قطعاً ناقصة.
- أخطاء بناء الجملة والهيكل (9.7%): أخطاء أساسية مثل نسيان قوس إغلاق أو فاصلة منقوطة.
- الحالات الاستثنائية (9%): نسي الذكاء الاصطناعي التعامل مع الحالات النادرة، مثل ماذا يحدث إذا أدخل المستخدم صفراً بدلاً من رقم.
- التعامل مع الأنواع (8.7%): الخلط بين أنواع مختلفة من البيانات، مثل محاولة وضع رسالة نصية في صندوق أرقام.
- مشكلات النطاق (8%): محاولة استخدام متغير في مكان لا يوجد فيه.
دخول RefactorAssist: المفتش الخارق
أدرك الباحثون أن مجرد طلب المحاولة مرة أخرى من الذكاء الاصطناعي ليس كافياً. كانوا بحاجة إلى نظام يمكنه رصد هذه الأخطاء وإصلاحها تلقائياً. لذا، قاموا ببناء RefactorAssist، وهو "وكيل إصلاح" ذكي يعمل كمفتش مراقبة جودة مكون من مرحلتين.
المرحلة 1: الإصلاح السريع (الإصلاح الاستاتيكي)
قبل حتى سؤال الذكاء الاصطناعي ليفكر مجدداً، يقوم RefactorAssist بتشغيل فحص سريع قائم على القواعد. إنه يشبه مدقق الإملاء الذي لا يحتاج لفهم القصة، بل يحتاج فقط لفهم القواعد. إنه يصلح الأشياء الواضحة مثل الاستيرادات (imports) المفقودة، والأقواس غير المتوازنة، وأخطاء الأنواع البسيطة. هذه الخطوة رخيصة وسريعة لأنها لا تستخدم "الدماغ" الثقيل للذكاء الاصطناعي. ومن المثير للدهشة أن هذه الخطوة البسيطة أصلحت جزءاً كبيراً من المشكلات، حيث رفعت معدل النجاح من 66.1% إلى 74.4% (وصولاً إلى 80.3% في أفضل إعداداتهم) بمجرد تنظيف بناء الجملة (syntax).
المرحة 2: عمل المحقق (الإصلاح الوكيل)
بالنسبة للكود المكسور المتبقي (الذي لا يزال فاشلاً بعد الإصلاح السريع)، ينتقل RefactorAssist إلى "وضع الوكيل". إنه يجمع كل الأدلة: رسائل الخطأ من الاختبارات الفاشلة، والتغييرات المحددة التي أجراها الذكاء الاصطناعي ("الفرق" أو الـ diff)، وسياق الكود المحيط. ثم يطلب من ذكاء اصطناعي قوي (مثل GPT-4o) أن يعمل كمحقق، ليشرح لماذا فشل الكود ويقترح حلاً. هذا المحقق لا يخمن فحسب؛ بل يستخدم الأدلة لتوجيه عملية الإصلاح.
كانت نتائج هذه العملية المكونة من مرحلتين مثيرة للإعجاب. فبعد محاولة الذكاء الاصطناعي الأولية، والإصلاح الاستاتيكي، ثم العمل التحقيقي التكراري، ارتفع معدل النجاح ليصل إلى 94.2%. والأهم من ذلك، أن النظام كان قادراً على إصلاح 70.8% من حالات الفشل التي بقيت بعد خطوة الإصلاح الاستاتيكي الأولية. وهذا يعني أنه بالنسبة لمجموعة عمليات التجديد التي أفسدها الذكاء الاصطناعي ولم يستطع فحص القواعد إصلاحها، نجح وكيل المحقق في RefactorAssist في استعادة الغالبية العظمى، مما رفع معدل النجاح الإجمالي إلى ما يقرب من المثالية.
ما الذي لم ينجح؟
اختبر الباحثون أيضاً بعض الأفكار التي ظنوا أنها قد تساعد، ولكن تبين أنها أقل فائدة. على سبيل المثال، جربوا إضافة نظام "استرجاع" (retrieval) يبحث في المشروع بأكمده للحصول على سياق إضافي لتزويد الذكاء الاصطناعي بمزيد من المعلومات الخلفية. وبينما ساعد هذا قليلاً في الثواني الأولى من الإصلاح، إلا أنه لم يساعد الذكاء الاصطناعي فعلياً في حل المشكلات الأكثر صعوبة على المدى الطويل. تشير الورقة إلى أن امتلاك شرح واضح ودقيق لسبب حدوث الخطأ (التشخيص) هو أكثر أهمية بكثير من امتلاك كم هائل من السياق الإضافي.
الخلاصة
لا تدعي هذه الورقة أن الذكاء الاصطناعي يمكنه إعادة هيكلة الكود بشكل مثالي بمفرده بعد. في الواقع، هي تثبت أنه بدون مساعدة، يرتكب الذكاء الاصطناعي أخطاءً بنسبة 20% تقريباً. ومع ذلك، فهي توضح أنه من خلال الجمع بين "فحص قواعد" بسيط وسريع و"وكيل محقق" ذكي يعتمد على الأدلة، يمكننا إصلاح معظم تلك الأخطاء.
النتيجة الرئيسية هي أن RefactorAssist يمكنه أخذ عملية تجديد فوضوية ومكسورة أنتجها الذكاء الاصطناعي وتحويلها إلى تحديث كود آمن ويعمل بنسبة نجاح تصل إلى 94.2%. إنها تشير إلى أن مستقبل هندسة البرمجيات لا يقتصر فقط على امتلاك ذكاء اصطناعي أكثر ذكاءً، بل يتعلق ببناء فريق يقوم فيه الذكاء الاصطناعي بالأعمال الشاقة، بينما يقوم وكيل إصلاح متخصص بالإمساك بالأخطاء قبل وصولها إلى المستخدم. إنها تذكير بأنه حتى الروبوتات فائقة الذكاء تحتاج إلى فريق مراقبة جودة جيد للقيام بأفضل أعمالها.
غارق في أبحاث مجالك؟
تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.