💬 NLP

Precise Debugging Benchmark: Is Your Model Debugging or Regenerating?

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

المؤلفون الأصليون: Wang Bill Zhu, Miaosen Chai, Shangshang Wang, Yejia Liu, Song Bian, Honghua Dong, Willie Neiswanger, Robin Jia

نُشر 2026-04-21

📖 5 دقيقة قراءة🧠 قراءة متعمّقة

CC BY 4.0

المؤلفون الأصليون: Wang Bill Zhu, Miaosen Chai, Shangshang Wang, Yejia Liu, Song Bian, Honghua Dong, Willie Neiswanger, Robin Jia

البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل

إليك شرح لورقة البحث "Precise Debugging Benchmark: Is Your Model Debugging or Regenerating?" باستخدام لغة بسيطة وتشبيهات إبداعية.

الصورة الكبيرة: مشكلة "المبالغ في الهندسة"

تخيل أنك استأجرت ميكانيكيًا عبقريًا ولكنه متحمس أكثر من اللازم لإصلاح سيارتك. السيارة بها مشكلة واحدة صغيرة: برغي مرتخٍ في المصباح الأمامي الأيسر.

ما تريده أنت (التصحيح الدقيق - Precise Debugging): يذهب الميكانيكي، يشد ذلك البرغي الواحد، يفحص الضوء، ويقول: "انتهيت".
ما تفعله نماذج الذكاء الاصطنا1 غالبًا (إعادة التوليد - Regeneration): ينظر الميكانيكي إلى البرغي المرتخي، يهز كتفيه ويقول: "تعرف ماذا؟ هذه السيارة قديمة. دعنا نبني لك سيارة جديدة تمامًا من الصفر".

السيارة الجديدة تعمل بشكل مثالي! لقد اجتازت جميع اختبارات السلامة. لكنها كلفتك 100 ضعف التكلفة، واستغرقت 100 ضعف الوقت، وفقدت سيارتك الأصلية في هذه العملية.

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

الطريقة القديمة في الاختبار: فخ "النجاح/الفشل"

حتى الآن، كنا نختبر مبرمجي الذكاء الاصطناعي مثل المعلم الذي يصحح اختبار رياضيات.

السؤال: "إليك برنامجًا معطلًا. أصلحه".
الدرجة: هل اشتغل البرنامج دون أن يتوقف عن العمل (crash)؟
- نعم: A+ (درجة كاملة).
- لا: F.

العيب: هذا النظام لا يهتم كيف حصلت على درجة A+.

الطالب (أ): أصلح ذلك الخطأ المطبعي الوحيد. (A+).
الطالب (ب): حذف المقال بالكامل وكتب واحدًا جديدًا من الصفر. (A+).

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

الحل الجديد: إطار عمل PDB

ابتكر المؤلفون نظام اختبار جديدًا يسمى PDB (Precise Debugging Benchmark). فكر فيه كأنه "مجهر لإصلاحات الكود".

بدلاً من السؤال فقط "هل يعمل؟"، يسأل PDB: "كم غيرت؟"

كيف يعمل PDB (الوصفة)

الإعداد: يأخذون قطعة كود مثالية (مثل وصفة ناجحة لصنع كعكة).
التخريب: يستخدمون الذكاء الاصطناعي لتعطيلها عمدًا بطرق محددة وصغيرة جدًا (مثلاً: "غير مكونًا واحدًا"، "احذف خطوة واحدة"). هذا ينتج "كعكة معيبة".
الاختبار: يطلبون من الذكاء الاصطنا1 إصلاح الكعكة.
النتيجة (التقييم):
- درجة اختبار الوحدة (Unit Test Score): هل كان طعم الكعكة جيدًا؟ (هل يعمل الكود؟)
- درجة الدقة (Precision Score): هل قمت فقط باستبدال السكر بالملح، أم أنك رميت الوعلة بالكامل وخبزت واحدة جديدة؟

لقد ابتكروا مقياسين جديدين:

الدقة على مستوى التعديل (Edit-Level Precision): "كم عدد التغييرات غير الضرورية التي أجريتها؟" (إذا غيرت 10 أسطر لإصلاح خطأ واحد، فدقتك منخفضة).
الاستدعاء على مستوى الخطأ (Bug-Level Recall): "هل وجدت الخطأ المحدد وأصلحته بالفعل؟"

النتائج الصادمة

اختبر الباحثون أذكى نماذج الذكاء الاصطناعي (مثل GPT-5.1، وClaude، وDeepSeek) في هذا الاختبار الجديد. وكانت النتائج مذهلة:

وهم "النجاح": حصلت معظم نماذج الذكاء الاصطناعي على درجات عالية في اختبارات "النجاح/الفشل" القديمة. لقد أصلحوا الكود!
واقع "الدقة": عند النظر إليها عبر مجهر PDB، كانت دقتها سيئة جدًا (غالبًا أقل من 45%).
- حتى عندما طُلب منها صراحةً: "يرجى إجراء تغييرات دنيا"، استمرت نماذج الذكاء الاصطنا هذه في إعادة كتابة أجزاء ضخمة من الكود.
- التشبيه: الأمر يشبه إخبار طالب: "فقط أصلح الخطأ الإملائي"، فيرد بإعادة كتابة القصة بأكملها لأنه يعتقد أن هذه هي الطوال الوحيدة لتكون في أمان.

انقلاب التصنيف:

النموذج (أ) (مثل GPT-5.1): سجل معدل نجاح 76% ولكن دقة 39% فقط. كان "مُعيد توليد" (Regenerator).
النموذج (ب) (مثل Qwen3): سجل معدل نجاح 70% ولكن دقة 66%. كان "جراحًا" (Surgeon).
تحت النظام القديم، بدا النموذج (أ) أفضل. تحت النظام الجديد، النموذج (ب) هو الفائز الحقيقي.

لماذا لم يساعد "التصحيح المتكرر"؟

حاول المؤلفون مساعدة نماذج الذكاء الاصطنا1 من خلال منحهم "فرصة ثانية".

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

"لماذا" والمستقبل

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

ماذا يعني هذا بالنسبة لنا؟

الذكاء الاصطنا الحالي هو أداة "قوة غاشمة" (Brute Force): هو رائع لبدء مشاريع جديدة ولكنه خطير لصيانة المشاريع القديمة.
نحن بحاجة إلى تدريب جديد: لجعل الذكاء الاصطنا1 مفيدًا لصيانة البرمجيات في العالم الحقيقي، نحتاج إلى تدريبهم ليكونوا "متبسطين" (Minimalists)، وليس مجرد مولدين.
نحن بحاجة إلى مقاييس جديدة: لا يمكننا الاكتفاء بالسؤال "هل يعمل؟". يجب أن نسأل أيضًا: "هل أصلحت المشكلة دون هدم بقية المنزل؟"

ملخص التشبيه

تخيل أن لديك منزلًا به صنبور ماء يسرب.

الذكاء الاصطنا1 القديم: "سأصلحه!" يبدأ في هدم المطبخ بالكامل، وإعادة بناء السباكة، وتركيب خزائن جديدة. لقد اختفى التسريب! (لكنك فقدت مطبخك).
الذكاء الاصطنا1 الدقيق: "سأصلحه!" يستبدل القطعة الصغيرة داخل الصنبور. اختفى التسريب. (ومطبخك لا يزال كما هو).

هذه الورقة هي جرس إنذار: توقفوا عن الاحتفال بالذكاء الاصطنا1 الذي يعيد بناء المطبخ، وابدأوا في مكافأة الذكاء الاصطنا1 الذي يصلح الصنبور فحسب.

ملخص تقني لورقة بحثية: "مقياس تصحيح الأخطاء الدقيق: هل يقوم نموذجك بتصحيح الخطأ أم بإعادة التوليد؟"

1. بيان المشكلة

بينما أظهرت النماذج اللغوية الكبيرة (LLMs) قدرات استثنائية في توليد الكود البرمجي، لا تزال قدرتها على إجراء تصحيح دقيق للأخطاء (Precise Debugging) غير مقيمة بشكل كافٍ. لاحظ المؤلفون وجود عدم توافق حرج في مقاييس التقييم الحالية:

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

2. المنهجية: إطار عمل PDB

لمعالجة هذه الفجوات، قدم المؤلفون إطار عمل تصحيح الأخطاء الدقيق (PDB)، وهو مسار مؤتمت يحول مجموعات بيانات البرمجة الموجودة إلى معايير لتصحيح الأخطاء مع تقييم يراعي الدقة.

أ. مسار توليد البيانات

البيانات المصدرية: يستخدم إطار العمل معايير موجودة مثل BigCodeBench (استخدام واجهة برمجة التطبيقات API) و LiveCodeBench (الاستنتاج الخوارزمي).
توليد أخطاء ذرية (Atomic Bug Synthesis): يتم توجيه النماذج اللغوية لحقن أخطاء "ذرية" في الحلول الصحيحة. يتم تصنيف هذه الأخطاء باستخدام التصنيف المتعامد للعيوب (ODC) (مثل: التعيين، التحقق، الخوارزمية).
- أخطاء السطر الواحد: تضمن الذرية (أدنى تصحيح يتطلب سطرًا واحدًا).
- أخطاء متعددة الأسطر: تتكون من كتل متصلة من التعديلات.
تركيب الأخطاء: يتم تركيب أخطاء ذرية مستقلة متعددة في برامج واحدة لإنشاء سيناريوهات متعددة الأخطاء. يضمن "قيد الخطوة" (Stride Constraint) تباعد الأخطاء مكانياً للحفاظ على استقلاليتها.
التحقق: يتم التحقق من البرامج المعيبة المولدة لضمان فشلها في اختبارات الوحدة، ويتم تسجيل "سكربتات التعديل" (Edit Scripts) الدقيقة المطلوبة لإصلاحها.

ب. مقاييس التقييم الجديدة

ينتقل PDB إلى ما وراء درجات اختبار الوحدة الثنائية عبر تقديم مقييزين يقيمان جودة التعديل:

دقة مستوى التعديل (Edit-Level Precision): تقيس نسبة التعديلات الضرورية التي أجراها النموذج إلى إجمالي التعديلات المنفذة. وهي تعاقب الإفراط في التعديل (تعديل الكود الصحيح) والتغييرات الزائدة.
- الصيغة: $Precision = \frac{1}{|\hat{E}|} \sum_{i=1}^{k} F_U(\hat{C}_i) \cdot |E_i|$ (مع استخدام $\epsilon$ -relaxation للتعديلات الأساسية).
استدعاء مستوى الخطأ (Bug-Level Recall): يقيس كسر الأخطاء المتميزة التي تم حلها بنجاح بواسطة النموذج.
- الصيغة: $Recall = \frac{1}{k} \sum_{i=1}^{k} F_U(\hat{C}_i)$ .

C. مجموعات التقييم

أصدر المؤلفون مجموعتي معايير محددتين:

PDB-SINGLE-HARD: تضم 5,751 مثالاً تركز على أخطاء السطر الواحد، وتمت تصفيتها لاستبعاد الحالات "السهلة" التي تحقق فيها معظم النماذج درجات مثالية.
PDB-MULTI: تضم 256 مثالاً تركز على كتل أخطاء متعددة الأسطر المتصلة.

3. المساهمات الرئيسية

إطار عمل PDB: نظام جاهز للتشغيل (Plug-and-play) لتحويل مجموعات بيانات توليد الكود إلى معايير صارمة لتصحيح الأخطاء تقيم حد أدنى من التعديل وتحديد موقع الخطأ.
مقاييس جديدة: تقديم دقة مستوى التعديل و استدعاء مستوى الخطأ لقياس "دقة" تصحيح الأخطاء، والتمييز بين الإصلاحات المستهدفة وإعادة التوليد بالقوة الغاشمة.
معيار شامل: إصدار PDB-SINGLE-HARD و PDB-MULTI، اللذين يغطيان أنواع العيوب المختلفة ومستويات التعقيد.
التحليل التجريبي: تقييم منهجي للنماذج الرائدة (بما في ذلك GPT-5.1-Codex، و DeepSeek-V3.2، و Claude-4.5، إلخ) والذي يكشف عن انفصال جوهري بين الصحة الوظيفية ودقة تصحيح الأخطاء.

4. النتائج الرئيسية

تكشف التجارب على النماذج الرائدة عن تباين صارخ بين أداء اختبار الوحدة وقدرة تصحيح الأخطاء الدقيقة:

فجوة الدقة: غالباً ما تحقق النماذج معدلات اجتياز عالية لاختبارات الوحدة (>76%) ولكنها تظهر دقة منخفضة جداً في مستوى التعديل (<45%).
- مثال: حقق GPT-5.1-Codex معدل اجتياز اختبار وحدة بنسبة 76.1% ولكن دقة بلغت 39.7% فقط.
- مثال: حقق DeepSeek-V3.2-Thinking معدل اجتياز اختبار وحدة بنسبة 79.0% ولكن دقة بلغت 45.0% فقط.
- تباين: حقق Qwen3-Coder-480B درجة أقل في اختبار الوحدة (70.3%) ولكن دقة أعلى بكثير (65.8%)، مما يشير إلى استراتيجية تصحيح أخطاء أكثر استهدافاً.
انعكاس التصنيف: النماذج التي تؤدي بشكل أفضل في اختبارات الوحدة غالباً ما تؤدي بشكل أسوأ في الدقة، مما يشير إلى أن معدلات الاجتاز العالية مدفوعة بإعادة التوليد بدلاً من مهارة تصحيح الأخطاء.
عدم فعالية الاستراتيجيات التكرارية/الوكيلة (Agentic):
- السماح للنماذج بمحاولات متعددة (تكرارية) أو توفير تغذية راجعة للتنفيذ (وكيلية) يحسن معدلات اجتياز اختبار الوحدة والاستدعاء.
- ومع ذلك، فإن هذه الاستراتيجيات لا تحسن الدقة؛ وفي كثير من الحالات، تتدهور الدقة مع توسيع النماذج لنطاق التعديلات لـ "ضمان" الصحة.
حساسية التوجيه (Prompt Sensitivity): إن توجيه النماذج صراحةً للقيام بـ "أدنى التعديلات" يحسن الدقة مقارنة بالتوجيهات الحرة، لكن التحسن غير كافٍ لسد الفجوة مع سلوكيات إعادة التوليد الكثيفة.
تلوث البيانات: يشير التحليل إلى أن تلوث البيانات يلعب دوراً ثانوياً، وأن الميل إلى إعادة التوليد هو سلوك أصيل في مسارات التدريب اللاحقة (post-training) الحالية، وليس مجرد نتيجة للحفظ.

5. الأهمية والآثار المترتبة

إعادة التفكير في التقييم: تجادل الورقة بأن التقييم المعتمد على اختبار الوحدة فقط غير كافٍ لتقييم قدرات تصحيح الأخطاء. فهو يحجب الطبيعة "القائمة على القوة الغاشمة" لتصحيح الأخطاء في النماذج الحالية، وهو أمر مكلف ومخاطرة في صيانة البرمجيات الواقعية.
محدودية التدريب اللاحق (Post-Training): تسلط النتة الضوء على محدودية جوهرية في مسارات التدريب اللاحق لنماذج الكود البرمجي الحالية. النماذج مُحسّنة من أجل الصحة الوظيفية (اجتياز الاختبارات) بدلاً من مبادئ صيانة الكود (الحد الأدنى من التعديل، والحفاظ على القصد).
الاتجاهات المستقبلية: يدعو المؤلفون إلى تحول في أهداف التدريب لمكافأة تحديد موقع الخطأ و الحد الأدنى من التعديل بشكل صريح. يجب تدريب وكلاء تصحيح الأخطاء المستقبليين على فهم بنية البرنامج بعمق بما يكفي لإجراء تعديلات جراحية بدلاً من إعادة كتابة الحلول بالكامل.

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