CodeCureAgent: Automatic Classification and Repair of Static Analysis Warnings
تقدم هذه الورقة CodeCureAgent، وهو إطار عمل وكيل يعتمد على النماذج اللغوية الكبيرة (LLM) يقوم تلقائياً بتصنيف وإصلاح تحذيرات التحليل الساكن من خلال جمع السياق بشكل تكراري وتطبيق آلية تحقق ثلاثية الخطوات، محققاً معدل إصلاح معقول بنسبة 96.8% ومعدل إصلاح صحيح بنسبة 86.3% على مجموعة بيانات جافا واسعة النطاق، متفوقاً بشكل كبير على النماذج المرجعية الحالية.
المؤلفون الأصليون:Pascal Joos, Islem Bouzenia, Michael Pradel
تخيل أنك مدير لمكتبة ضخمة وصاخبة (وهي تمثل الكود البرمجي الخاص بك). لقد وظفت أمين مكتبة صارمًا وشديد اليقظة (أداة تحليل ثابت - Static Analysis Tool) ليتجول في الممرات ويشير إلى أي انتهاكات للقواعد.
أمين المكتبة بارع في إيجاد المشكلات: "هذا الكتاب في الرف الخطأ!"، "هذه الصفحة ممزقة!"، "هذه القصة بها فجوة في الحبكة!".
ولكن، هناك عقبة:
أمين المكتبة مفرط في الحماس: أحيانًا، يصرخ أمين المكتبة: "هذا الكتاب يفتقر إلى غلاف!" بينما الكتاب في الواقع نسخة رقمية خاصة لا تحتاج إلى غلاف. هذه هي النتائج الإيجابية الخاطئة (False Positives).
الإصلاح صعب: أحيانًا يكون أمين المكتبة محقًا، لكن إصلاح المشكلة يتطلب نقل كتب عبر ثلاث غرف مختلفة، وإعادة كتابة الفهرس، والتحقق مما إذا كان الترتيب الجديد سيؤثر على القصة. هذا أمر مرهق للمديرين البشريين.
النتيجة: نظرًا لأن إصلاح هذه المشكلات مرهق للغاية، فإن المديرين البشر غالبًا ما يتجاهلون ملاحظات أمين المكتبة. فتصبح المكتبة فوضوية، وفي النهاية يصبح النظام بأكمله غير موثوق به.
إليك CodeCureAgent.
فكر في CodeCureAgent كأنه متدرب ذكاء اصطناعي فائق الذكاء والدؤوب يعمل بجانبك. وبدلاً من مجرد إصلاح كل شيء يشير إليه أمين المكتبة بشكل أعمى، يمتلك هذا الذكاء الاصطناعي قوة خارقة من ثلاث خطوات: الاكتشاف، والقرار، والإصلاح.
1. مرحلة المحقق (التصنيف)
قبل أن يلمس الذكاء الاصطناعي أي كتاب، فإنه يعمل كمحقق.
الطريقة القديمة: كانت الأدوات السابقة تشبه الروبوتات التي تتبع أوامر أمين المكتبة بشكل أعمى. إذا قال أمين المكتبة "أصلح هذا"، يحاول الروبوت إصلاحه، حتى لو كان أمين المكتبة مخطئًا. وهذا غالبًا ما يؤدي إلى كسر الأشياء.
طريقة CodeCure: يسأل الذكاء الاصطناعي: "مهلًا لحظة. هل أمين المكتبة محق حقًا هنا؟"
يقرأ كتاب القواعد (توثيق الكود).
ينظر في سياق الكتاب المحدد.
القرار: إذا كان أمين المكتبة مخطئًا (نتيجة إيجابية خاطئة)، يقول الذكاء الاصطناعي: "تجاهل هذه الملاحظة"، ويضع عليها علامة "رجاء عدم الإزعاج". أما إذا كان أمين المكتبة محقًا (نتيجة إيجابية حقيقية)، فيقول: "حسنًا، نحتاج لإصلاح هذا".
2. مرحلة المهندس المعماري (الإصلاح)
بمجرد أن يقرر الذكاء الاصطناعي أن الإصلاح مطلوب، فإنه لا يكتفي بمجرد كتابة ملاحظة سريعة، بل يعمل كمهندس معماري بارع.
السياق هو الملك: إذا قال أمين المكتبة "هذا الرف مرتفع جدًا"، فإن الذكاء الاصطناعي لا يكتفي بخفض الرف فحسب، بل يتحقق مما إذا كانت الكتب الموجودة على الرف أعلاه ستسقط، أو ما إذا كان الشخص الذي يقرأها عادةً سيتمكن من الوصول إليها. إنه ينظر إلى المكتبة بأكملها، وليس فقط إلى رف واحد.
الإصلاحات متعددة الطوابق: أحيانًا يتطلب إصلاح مشكلة واحدة نقل كتب في القبو، والعليّة، والقاعة الرئيسية. الذكതി الاصطناعي ذكي بما يكفي لتنسيق التغييرات عبر ملفات (غرف) متعددة في وقت واحد، وهو أمر لم تستطع الأدوات القديمة القيام به.
3. مرحلة مراقبة الجودة (التحقق)
هذا هو الجزء الأهم. قبل أن يسلم الذكاء الاصطناعي العمل إليك، فإنه يجري فحص سلامة صارم:
اختبار البناء: هل لا تزال المكتبة قائمة؟ (هل يعمل الكود/Compile؟)
فحص القواعد: هل توقف أمين المكتبة عن الصراخ بشأن هذه المشكلة تحديدًا؟ (هل اختفت التحذيرات؟)
عدم خلق مشكلات جديدة: هل تسببنا بالخطأ في خلق فوضى جديدة أثناء تنظيف الفوضى القديمة؟
اختبار القصة: هل لا تزال القصة منطقية؟ (هل تجتاز الاختبارات الآلية؟)
إذا فشل الإصلاح في أي من هذه الفحوصات، فإن الذكاء الاصطناعي لا يستسلم، بل يقول: "عذرًا، لقد أفسدتُ القصة"، ثم يحاول نهجًا مختلفًا، مستخدمًا التغذية الراجعة للتعلم والتحسن.
لماذا يعد هذا أمرًا بالغ الأهمية؟
أرخص من البشر: تشير الورقة البحثية إلى أن هذا الذكاء الاصطناعي يكلف حوالي 2.9 سنتًا (أقل من سنت واحد!) ويستغرق حوالي 4 دقائق لكل تحذير. قد يقضي المطور البشري ساعات في نفس المهمة.
أكثر ذكاءً: في الاختبارات التي أجريت على 1,000 تحذير من العالم الحقيقي، نجح هذا الذكاء الاصطناعي في إصلاح أو تجاهل 96.8% منها بشكل صحيح. بينما تمكنت الأدوات التالية له في الكفاءة من تحقيق حوالي 60-70% فقط.
يوقف عادة "التجاهل": نظرًا لأن الذكاء الاصطناعي يقوم بالعمل الممل والمتكرر بهذا المستوى من الجودة، يمكن للمطورين أخيرًا التوقف عن تجاهل ملاحظات أمين المكتبة. وهذا يحافظ على نظافة الكود، وأمانه، وصحته.
باختد ع، CodeCureAgent ليس مجرد ذكاء اصطناعي "يصلح الأخطاء البرمجية". بل هو ذكاء اصطناعي يحدد أولاً ما إذا كان الخطأ حقيقيًا، ثم يصلحه بعناية دون كسر أي شيء آخر، ثم يدقق في عمله مرتين. إنه يحول مهمة مملة ومليئة بالأخطاء إلى عملية سريعة، موثوقة، ورخيصة الثمن.
إليك ملخص تقني مفصل لورقة البحث بعنوان "CodeCureAgent: التصنيف والإصلاح التلقائي لتحذيرات التحليل الساكن".
1. بيان المشكلة
تعد أدوات التحليل الساكن (مثل SonarQube) ضرورية لاكتشاف الأخطاء، والثغرات الأمنية، ورائحة الكود (code smells). ومع ذلك، فإن اعتمادها العملي يعوقه الجهد اليدوي المطلوب لحل التحذيرات. يواجه المطورون أربعة تحديات رئيسية:
صعوبة التصنيف: التمييز بين الإيجابيات الحقيقية (TP) (الأخطاء التي تحتاج إلى إصلاح) والإيجابيات الكاذبة (FP) (التحذيرات التي يمكن تجاهلها بأمان). غالبًا ما تفترض الأدوات المؤتمتة الحالية أن جميع التحذيرات هي إيجابيات حقيقية، مما يؤدي إلى كسر الكود عند محاولة "إصلاح" الإيجابيات الكاذبة.
التعقيد السياقي: يتطلب تحديد الإصلاح الصحيح فهم سياق الكود بما يتجاوز موقع التحذير المباشر (على سبيل المثال، كيفية استخدام متغير عبر ملفات متعددة).
نطاق التغييرات: تتطلب العديد من التحذيرات تعديلات تمتد عبر أسطر متعددة، أو قطع كود (hunks) متعددة، أو حتى ملفات متعددة، وهو ما تجد الأدوات المؤتمتة الحالية صعوبة في التعامل معه.
فجوات التحقق: تفتقر أدوات الإصلاح الحالية غالبًا إلى التحقق القوي، حيث تفشل في التحقق مما إذا كان الإصلاح قد استحدث تحذيرات جديدة، أو كسر عملية البناء (build)، أو تسبب في تراجع في الاختبارات (test regressions).
2. المنهجية: CodeCureAgent
CodeCureAgent هو إطار عمل وكيل (agentic framework) يستفيد من النماذج اللغوية الكبيرة (LLMs) لتحليل وتصنيف وإصلاح تحذيرات التحليل الساكن بشكل مستقل. بخلاف النهج القائم على القواعد أو نهج النموذج اللغوي الواحد (single-shot) السابق، فإنه يعمل في حلقة تكرارية باستخدام مجموعة من الأدوات المتخصصة.
البنية الأساسية
يتكون النظام من ثلاث مراحل رئيسية:
التحضير: يتم تشغيل أداة التحليل الساكن (SonarQube) على المشروع المستهدف لإنشاء قائمة بالتحذيرات.
الوكيل الفرعي للتصنيف:
الهدف: تحديد ما إذا كان التحذير عبارة عن إيجابية حقيقية (TP) أم إيجابية كاذبة (FP).
العملية: يقوم الوكيل ببناء المطالبات (prompts) بشكل تكراري، واستعلام النموذج اللغوي الكبير، وتنفيذ الأدوات (مثل ReadDocumentation و ReadLines و FindReferences و FindDefinition) لجمع السياق.
القرار: يجيب على أسئلة تصنيف محددة (مثل "هل انتهاك القاعدة صحيح؟" أو "هل الانتهاك مقصود؟") قبل إصدار حكم نهائي.
الوكيل الفرعي للإصلاح:
الهدف: إما إصلاح الكود (إذا كان TP) أو تجاهل (suppress) التحذير (إذا كان FP).
العملية:
بالنسبة للإيجابيات الحقيقية (TPs): يضع الوكيل خطة، ويجمع السياق اللازم (عبر ملفات متعددة محتملة)، ويقترح تعديلات الكود باستخدام أداة WriteFix. يمكنه التعامل مع التغييرات متعددة الملفات ومتعددة القطع (multi-hunk).
بالنسبة للإيجابيات الكاذبة (FPs): يقوم الوكيل بإدراج آليات التجاوز (مثل تعليقات //NOSONAR أو وسوم @SuppressWarnings).
مُعتمد التغيير (حلقة التحقق):
قبل قبول أي إصلاح، يخضع لعملية تحقق صارمة من ثلاث خطوات:
البناء (Build): يجب أن يتم تجميع المشروع دون أخطاء.
إعادة تشغيل التحليل الساكن: يجب أن يختفي التحذير المستهدف، وألا يتم استحداث أي تحذيرات جديدة.
مجموعة الاختبارات (Test Suite): يجب أن تنجح جميع الاختبارات الحالية لمنع حدوث تراجع في الوظائف.
إذا فشل التحقق، يتم إلحاق تغذية راجعة بالخطأ بسجل الوكيل، مما يدفعه إلى تحسين الإصلاح في الدورة التالية.
الميزات التقنية الرئيسية
الحلقة الوكيلية (Agentic Loop): لا يتبع النظام خوارزمية محددة مسبقًا؛ بل يقرر ديناميكيًا الأدوات التي سيستدعيها بناءً على التحذير المحدد.
التعديل متعدد الملفات: على عكس العديد من النماذج المرجعية المقيدة بملف واحد، يمكن لـ CodeCureAgent تعديل ملفات ومواقع متعددة في خطوة واحدة.
التحسين القائم على التغذية الراجعة: يتعلم الوكيل من أخطاء البناء وأخطاء الاختبار لتحسين رقع (patches) الإصلاح بشكل تكراري.
3. المساهمات الرئيسية
أول وكيل LLM للتحليل الساكن: أول نظام يستكشف مستودع الكود بشكل مستقل ويطبق التعديلات عبر أدوات مخصصة لتحذيرات التحليل الساكن، بدلاً من مجرد إصلاح الأخطاء البرمجية.
خط إنتاج ثلاثي المراحل: تصميم مبتكر يفصل بين التصنيف (TP مقابل FP) والإصلاح (إصلاح مقابل تجاهل) والتحقق (بناء، إعادة تحليل، اختبار).
تقييم شامل: تقييم واسع النطاق على مجموعة بيانات مكونة من 1,000 تحذير من SonarQube عبر 106 مشروع جافا حقيقي تغطي 291 قاعدة متميزة.
مفتوح المصدر: الكود والبيانات متاحة للعموم.
4. النتائج التجريبية
قام المؤلفون بتقييم CodeCureAgent مقابل أفضل النماذج المرجعية: Sorald (القائم على القواعد)، و iSMELL، و CORE (القائم على LLM).
معدل الإصلاح المعقول (Plausible Fix Rate): أنتج CodeCureAgent إصلاحات معقولة لـ 96.8% من الـ 1,000 تحذير.
يتفوق على iSMELL (62.8%) و CORE (67.6%) بفارق 29.2% إلى 34.0%.
يتفوق على Sorald حتى في مجموعة القواعد التي يدعمها Sorald (100% مقابل 69.4%).
الدقة (الفحص اليدوي): في مجموعة فرعية تم التحقق منها يدويًا مكونة من 291 تحذيرًا:
دقة التصنيف: 91.8% (تحديد TP مقابل FP بشكل صحيح).
معدل الإصلاح الصحيح: تم إصلاح أو تجاهل 86.3% من إجمالي التحذيرات بشكل صحيح.
التعامل مع التعقيد:
نجح في التعامل مع الإصلاحات متعددة الأسطر (44.4% من الحالات) والإصلاحات متعددة الملفات (3.6% من الحالات).
فشلت النماذج المرجعية إلى حد كبير في السيناريوهات متعددة الملفات.
الكفاءة والتكلفة:
الوقت: متوسط وقت المعالجة حوالي 4.4 دقيقة لكل تحذير.
التكلفة: متوسط تكلفة LLM حوالي 2.9 سنت (دولار أمريكي) لكل تحذير.
ملاحظة: استغرقت التحذيرات غير المُصلحة وقتًا أطول (14 دقيقة) وتكلفة أعلى (21 سنتًا) بسبب استنفاد ميزانية الدورات.
5. الأهمية والأثر
تقليل عبء المطور: من خلال أتمتة دورة التحليل والتصنيف والإصلاح والتحقق، يعالج CodeCureAgent "إجهاد التحذيرات" الذي يجعل المطورين يتجاهلون أدوات التحليل الساكن.
التعامل مع الإيجابيات الكاذبة: من خلال تصنيف التحذيرات صراحةً قبل الإصلاح، يمنع النظام الخطأ الشائع المتمثل في "إصلاح" مشكلات غير موجودة، مما يؤدي غالبًا إلى كسر وظائف الكود.
المتانة: يضمن تضمين التحقق من البناء والاختبار أن الرقع المولدة ليست صحيحة برمجياً فحسب، بل سليمة وظيفياً أيضاً.
القابلية للتوسع: تشير الطبيعة المؤتمتة والتكلفة المنخفضة إلى إمكانية دمج هذه الأداة في مسارات CI/CD لمنع تراكم الديون التقنية في الوقت الفعلي.
6. القيود والعمل المستقبلي
خصوصية اللغة: يقترج حاليًا على لغة Java و SonarQube. يتطلب التكيف مع لغات أخرى أدوات تحليل (parsers) وأوامر بناء واختبار جديدة.
هلوسة LLM: نُسبت بعض الإخفاقات إلى تجاهل الـ LLM للسياق أو اتخاذ قرارات هلوسة، خاصة في سيناريوهات التصنيف المعقدة.
النطاق: لا يمكن للأداة حاليًا إنشاء ملفات أو إعادة تسميتها أو حذفها، مما يحد من قدرتها على إصلاح بعض المشكلات الهيكلية.
في الختام، يمثل CodeCureAgent خطوة كبيرة للأمام في الصيانة الآلية للبرمجيات، حيث يثبت أن الوكلاء القائمين على LLM يمكنهم التعامل بموثوقية مع تعقيدات تحذيرات التحليل الساكن بشكل أفضل من النهجات السابقة القائمة على القواعد أو النهج أحادي المحاولة.