Transparency in Software Defect Prediction: A Dual Approach using Explainability and Tradeoff Analysis

تخيل أنك محقق يحاول العثور على خائن واحد مختبئ وسط حشد من ألف مواطن بريء. مهمتك هي الإشارة إلى هوية الخائن قبل أن يتسبب في أي مشكلة. هذا هو الواقع اليومي لمهندسي البرمجيات، الذين يعملون ككشافين رقميين يطاردون "الأخطاء البرمجية" (bugs) أو العيوب في الكود المصدري. وفي عالم هندسة البرمجيات، تسمى هذه المطاردة التنبؤ بعيوب البرمجيات (Software Defect Prediction). إنها لعبة عالية المخاطر، حيث الهدف هو رصد الكود السيئ قبل أن يتسبب في تعطل النظام.

لعب هذه اللعبة، يستخدم المهندسون برامج حاسوبية تسمى نماذج تعلم الآلة (Machine Learning models). فكر في هذه النماذج كأنها مساعدون أذكياء للغاية قد قرأوا ملايين الأسطر من الكود في الماضي. إنهم ينظرون إلى قطعة جديدة من الكود ويعطونها "درجة اشتباه" تتراوح بين 0 و1. الدرجة 0 تعني "بريء تماماً"، والدرجة 1 تعني "مذنب كما هو متوقع". الجزء الصعب هو تحديد أين ترسم الخط الفاصل. إذا وضعت الخط منخفضاً جداً، فقد تتهم أشخاصاً أبرياء (إنذارات كاذبة)، مما يهدر وقت الجميع. وإذا وضعته مرتفعاً جداً، فقد تسمح للخائن الحقيقي بالإفلات (أخطاء فائتة)، وهو أمر قد يكون كارثياً. لفترة طويلة، استخدم معظم المحققين قاعدة قياسية واحدة: "إذا كانت الدرجة فوق 0.5، فهو مذنب". ولكن كما يشير هذا البحث الجديد، فإن تلك القاعدة القياسية قد تكون مخطئة.

---

فكرة الورقة البحثية: إيجاد الخط المثالي

في ورقتهم البحثية بعنوان "الشفافية في التنبؤ بعيوب البرمجيات: نهج مزدوج باستخدام القابلية للتفسير وتحليل المقايضة"، يجادل نيتين سام بومي، وأوماماهيسوارا شارما بهوتامابورام، وأتول نيجي، بأن القاعدة القديمة "0.5" تشبه استخدام قبعة واحدة تناسب الجميع لحشد من الناس ذوي أحجام رؤوس مختلفة تماماً؛ فهي ببساطة لا تناسب الجميع.

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

الحيلة رقم 1: تغيير مكان المرمى (العتبة المثالية)

تتعلق الحيلة الأولى بتعديل "خط الاشتباه". اختبر الباحثون ثلاثة أنواع مختلفة من المساعدين المحققين: الانحدار اللوجستي (Logistic Regression)، ونايف بايز (Naïve Bayes)، والشبكات العصبية (Neural Networks). ووجدوا أن الرقم السحري لم يكن 0.5 لأي منها.

• بالنسبة لمساعد الانحدار اللوجستي، كانت النقطة المثالية حوالي 0.35.
• بالنسبة لـ نايف بايز، كانت أقل من ذلك، عند 0.3.
• بالنسبة لـ الشبكة العصبية، كانت 0.38.

فكر في الأمر كضبط جهاز الراديو. إذا تركت القرص في المنتصف، فقد تسمع ضجيجاً. ولكن إذا حركته قليلاً لليسار أو اليمين، فجأة ستصل الموسيقى بوضوح تام. من خلال خفض العتبة (إلى حوالي 0.3 أو 0.4)، أصبحت هذه النماذج أفضل بكثير في رصد العيوب الحقيقية مع الحفاظ على عدد منخفض من الإنذارات الكاذبة. في اختباراتهم عبر 36 إصداراً مختلفاً لـ 10 مشاريع برمجية، تفوقت هذه العملية البسيطة باستمرار على الطريقة القياسية.

الحيلة رقم 2: لعبة "ماذا لو" (التفسيرات المضادة للواقع)

الحيلة الثانية أكثر سحراً. استخدم المؤلفون ما يسمى التفسيرات المضادة للواقع (Counterfactual Explanations). تخيل أن لديك صورة لمشتبه به "مذنب" (وحدة كود معيبة). النموذج يقول: "هذا سيء". الآن، تخيل أنه يمكنك سؤال النموذج: "ماذا لو غيرت هذا الشيء الصغير؟ هل سيصبح بريئاً؟".

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

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

ما وجدوه (وما لم يجدوه)

كانت النتائج واعدة ولكنها محددة. قاس المؤلفون نجاحهم باستخدام أداتين رئيسيتين:

1. معدل الإغفال الخاطئ (FOR): كم مرة فاتهم عيب حقيقي؟ (أرادوا أن يكون هذا منخفضاً).
2. نسبة الميزانية الموفرة (PSB): مقدار الوقت والمال الذي وفروه بعدم اختبار الكود النظيف.

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

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

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

لماذا يهم هذا الأمر

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