🤖 machine learning

Understanding Robustness of Model Editing in Code LLMs

تقدم هذه الورقة معياراً مضبوطاً وبيئة اختبارية (sandbox) لتقييم تعديل النماذج في النماذج اللغوية الكبيرة الخاصة بالبرمجة (code LLMs) في ظل تحديثات واجهات برمجة التطبيقات (API)، كاشفةً أن طرق التعديل الحالية تواجه صعوبة في تعميم عمليات نقل واجهات برمجة التطبيقات الصحيحة إلى المهام غير المرئية، وغالباً ما تعتمد على حلول مؤقتة، وتعاني من تدهور حاد في الأداء وتداخل عند تطبيقها بشكل متتالٍ.

المؤلفون الأصليون: Vinaik Chhetri, Moghis Fereidouni, A. B Siddique, Umar Farooq

نُشر 2026-05-11

📖 4 دقيقة قراءة☕ قراءة في استراحة قهوة

CC BY 4.0

المؤلفون الأصليون: Vinaik Chhetri, Moghis Fereidouni, A. B Siddique, Umar Farooq

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

تخيل أن لديك مساعداً آلياً (روبوت) موهوباً جداً وذكياً للغاية، يقوم بكتابة الأكواد البرمجية من أجلك. لقد تم تدريب هذا الروبوت على مكتبة ضخمة من الأكواد القديمة، لذا فهو يعرف كيف يؤدي المهام بالطريقة "القديمة". ولكن في العالم الحقيقي، تخضع أدوات البرمجيات (التي تسمى واجهات برمجة التطبيقات أو APIs) لتحديثات مستمرة، مثل تحديث الأزرار في تطبيق هاتف ذكي أو تغيير طريقة حفظ الملفات فيه.

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

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

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

1. فخ "النجاح الزائف"

قام الباحثون ببناء مطبخ اختبار خاص يحتوي على 2,040 لغزاً برمجياً. قاموا بتغيير القواعد لأدوات معينة (مثل إعادة تسمية دالة أو إضافة خطوة مطلوبة) وطلبوا من الروبات حل الألغاز باستخدام القواعد الجديدة.

وجدوا أن العديد من الروبوتات بدت وكأنها تجتاز الاختبارات، لكنها كانت تغش.

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

2. "الإصلاح لمرة واحدة" مقابل "تأثير كرة الثلج"

اختبر الباحثون سيناريوهين:

التعديل الفردي (Single Edit): تعليم الروبوت قاعدة جديدة واحدة.
التعدات المتتالية (Successive Edits): تعليم الروبوت قاعدة جديدة، ثم أخرى، ثم أخرى، مثل كرة ثلج تتدحرج من فوق تلة.

النتائج:

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

3. أين فشلوا؟

لم يكتفِ الباحثون بعدّ حالات الفشل فحسب، بل نظروا في كيفية فشلها. لقد قسموا العملية إلى مراحل:

التجميع/الترجمة (هل يمكن تشغيله؟): هل يمكن للكود أن يبدأ العمل أصلاً؟
اعتماد واجهة البرمجة (هل استخدم الأداة الجديدة؟): هل استخدم التعليمات المحدثة فعلياً؟
التنفيذ (هل يعمل؟): هل يحل المشكلة؟

الاكتشاف:

عند تعليم قاعدة واحدة جديدة، فشلت الروبوتات غالباً لأنها لم تستطع حتى جعل الكود يبدأ في العمل (أخطاء التجميع/Compilation errors).
عند تعليم قواعد عديدة، فشلت الروبوتات بشكل أكبر، حيث أنتجت غالباً كلاماً غير مفهوم أو تكراراً بلا معنى لا يمكن للحاسوب قراءته.

4. مشكلة "الذاكرة" مقابل "البحث"

اختبرت الورقة طرقاً مختلفة لـ "التعليم".

حاولت بعض الطرق حفظ القاعدة الجديدة في دفتر ملاحظات منفصل (القائم على الذاكرة/Memory-based). كانت هذه الطرق جيدة في الحفاظ على مهارات الروبوت الأخرى، لكنها لا تزال تعاني في تطبيق القاعدة الجديدة بشكل صحيح.
حاولت طرق أخرى البحث في عقل الروبوت وتغيير جزء محدد جراحياً (تحديد الموقع ثم التعديل/Locate-then-Edit). كانت هذه الطرق هشة للغاية؛ فقد أدت غالباً إلى إتلاف قدرة الروبوت على كتابة الأكواد لمهام أخرى، وليس فقط المهمة الجديدة.

الخلاصة

تخلص الورقة إلى أن الأساليب الحالية لـ "تعديل" الذكاء الاصطناعي الذي يكتب الأكواد ليست جاهزة للعالم الحقيقي.

غالباً ما تخدعنا بـ "طرق للالتفاف" تبدو كنجاح ولكنها ليست كذلك.
تتعطل بسهولة عندما تحاول تحديثها أكثر من مرة واحدة.
تعاني للتمييز بين "كتابة كود يعمل" وبين "كتابة كود يستخدم الأدا_ة الجديدة بشكل صحيح".

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

ملخص تقني: فهم متانة تعديل النماذج في النماذج اللغوية الكبيرة للأكواد (Code LLMs)

بيان المشكلة

تتزايد عملية دمج النماذج اللغوية الكبيرة (LLMs) المخصصة للأكواد في سير عمل تطوير البرمجيات، ومع ذلك تظل هذه النماذج ثابتة بعد مرحلة التدريب المسبق بينما تتطور الأنظمة البرمجية (مثل Android وNumPy وpandas) باستمرار مع تحديثات واجهات برمجة التطبيقات (APIs). وبينما يوفر تعديل النماذج بديلاً خفيف الوزن لإعادة التدريب الكامل لاستيعاب هذه التحديثات، لا يزال من غير الواضح ما إذا كانت طرق التعديل الحالية يمكنها استحثاث هجرة الـ API بشكل موثوق في النماذج اللغوية للأكواد.

يتمثل التحدي الحاسم في هذا المجال في التمييز بين التبني الحقيقي للـ API وبين النجاح القائم على الحلول البديلة (Workaround-based success). ففي توليد الأكواد، قد يجتاز النموذج حالات الاختبار عن طريق تجاوز الـ API المحدث عبر تنفيذات بديلة (مثل استخدام خوارزمية أو مكتبة مختلفة) بدلاً من الهجرة بشكل صحيح إلى الواجهة الجديدة. علاوة على ذلك، تعتمد التقييمات الحالية غالباً على مقاييس الشكل السطحي (مثل BLEU أو المطابقة التامة)، والتي تفشل في عزل آثار التعديل عن التعرض المسبق للتدريب، أو التمييز بين الفشل النحوي (أخطاء التجميع/Compilation errors) والفشل الدلالي (الأخطاء السلوكية). بالإضافة إلى ذلك، لا تزال استقرار طرق التعديل تحت التعديلات المتتالية (تراكم عدة تحديثات للـ API بمرور الوقت) غير مستكشفة إلى حد كبير.

المنهجية

بناء المعيار المرجعي (Benchmark)

قدم المؤلفون معياراً مرجعياً مضبوطاً مشتقاً من HumanEval وMBPP وAPPS، يتكون من 2,040 مسألة تغطي 140 تعديلاً اصطناعياً فريداً للـ API.

التعديلات الاصطناعية: لتقليل الارتباك الناتج عن التعرض للتدريب المسبق، طبق المؤلفون خمسة أنواع من التغييرات الاصطناعية على الـ APIs على الحلول القياسية:
- R1: إعادة تسمية الـ API.
- S1–S4: تعديلات المعاملات (إضافة معاملات اختيارية/مطلوبة، إعادة ترتيب المعاملات، تغيير أنواع الإرجاع).
تقسيمات البيانات: ينقسم المعيار المرجعي إلى ثلاثة تقسيمات متميزة:
1. الموثوقية (Reliability): تُستخدم لتطبيق التعديل (469 حالة).
2. التعميم (Generalization): تقييم ما إذا كان النموذج المعدل يستخدم الـ API المحدث بشكل صحيح في مسائل غير مرئية (647 حالة).
3. الخصوصية (Specificity): تقييم ما إذا كان الأداء قد تم الحفاظ عليه في المهام التي تتضمن APIs غير معدلة (924 حالة).

بيئة التنفيذ (Execution Sandbox)

تفرض بيئة تنفيذ مخصصة (Sandbox) الـ APIs المعدلة بموجب قواعد Python القياسية. حيث تقوم باستبدال تعريفات الـ API الأصلية بالنسخ المعدلة قبل تنفيذ الكود الذي ولده النموذج. وهذا يضمن أن التقييم يستهدف تكييف الـ API بدلاً من التغييرات في اللغة نفسها.

إطار التقييم

تدرس الدراسة سبع طرق رائدة (state-of-the-art) في تعديل النماذج عبر ثلاثة نماذج لغوية مفتوحة المصدر للأكواد (CodeLlama-7B، CodeQwen1.5-7B، DeepSeek-Coder-6.7B) تحت نظامين: التعديل الفردي (Single Edit) والتعديلات المتتالية (Successive Edits).

المقاييس:
- Compiles@k: احتمال أن يكون هناك عينة واحدة على الأقل من أصل $k$ قابلة للتجميع (Compile).
- Pass@k: احتمال أن تجتاز عينة واحدة على الأقل جميع الاختبارات.
- Successful Adoption@k: مقياس Pass@k حيث يستخدم الحل بشكل صحيح الـ API المعدل.
- Workaround@k: مقياس Pass@k حيث يجتاز الحل الاختبارات ولكنه يتجنب الـ API المعدل.
نسبة Shapley (Shapley Attribution): تفكيك ثنائي العوامل لـ Pass@k إلى قابلية التجميع (C) والصحة ما بعد التجميع (Q) لعزو انخفاض الأداء إلى الفشل النحوي أو الأخطاء السلوكية.
تصنيف الأخطاء (Error Taxonomy): نظام تصنيف يفصل النتائج إلى: تبني ناجح، نجاح عبر حل بديل (Workaround)، وفشل في مراحل التجميع، وتكيف الـ API، والتنفيذ، والسلوك.

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

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

النتائج

نظام التعديل الفردي (Single Edit Regime)

فشل التعميم: تعمم النماذج المعدلة بشكل ضعيف على المسائل غير المرئية التي تتطلب الـ API المعدل. وبينما تظهر الطرق القائمة على الذاكرة (GRACE, A-GRACE) والضبط الدقيق (FT-L) مرونة أعلى من طرق "التحديد ثم التعديل" (ROME, MEMIT, PMET)، إلا أن الأداء لا يزال يتدهور بشكل كبير.
انتشار الحلول البديلة (Workaround): جزء كبير من النجاح الظاهري يعتمد على الحلول البديلة. على سبيل المثال، في نموذج CodeLlama مع FT-L، تبلغ قيمة Pass@5 هي 0.40، ولكن 0.17 فقط منها يمثل تبنياً ناجحاً، بينما 0.23 ناتجة عن حلول بديلة. وغالباً ما تظهر طرق "التحديد ثم التعديل" فجوات أكبر بين Pass@k والتبني الناجح.
أنماط الفشل: يكشف تفكيك Shapley أن فشلات التعميم مدفوعة أساساً بأخطاء التجميع (يتراوح نطاق CF بين 43% إلى 60%)، بينما فشلات الخصوصية (التراجع في المهام غير المعدلة) تكون غالباً أخطاء ما بعد التجميع (يتراوح نطاق CF بين 5% إلى 40%).
المجموعة غير القابلة للحل البديل: عند التقييم على مجموعة فرعية من المسائل التي تتطلب الـ API المستهدف بشكل صارم (استبعاد الحلول البديلة)، ينخفض الأداء بشكل حاد. العديد من أزواج (الطريقة-النموذج) تنهار إلى Pass@k يقترب من الصفر، مما يشير إلى أنه حتى عندما يُجمع الكود، فإنه نادراً ما يدرك سلوك الـ API المعدل بشكل صحيح.

نظام التعديلات المتتالية (Successive Edit Regime)

الانهيار الكارثي: تحت تأثير التعديلات المتتالية، تنهار معظم تركيبات (الطريقة-النموذج) إلى Pass@k يقترب من الصفر في كل من التعميم والخصوصية.
عدم الاستقرار: تنتج طرق مثل MEMIT وPMET وROME غالباً مخرجات غير قابلة للاستخدام أو تتحول إلى تسلسلات توكنات متكررة (مثل defdefdef...) أو أخطاء نحوية.
الفشل المدفوع بالتجميع: على عكس التعديلات الفردية، تؤدي التعديلات المتتلة إلى فشلات تكون في الغالب مدفوعة بالتجميع (غالباً ما يصل CF إلى 100%)، مما يشير إلى أن التعديلات المتراكمة تزعزع قدرة النموذج على توليد كود صحيح نحوياً.
الاستثناءات: تظهر GRACE وFT-L استقراراً أفضل، رغم أنها لا تزال تعاني من تدهور كبير في الأداء مقارنة بالنماذج المرجعية قبل التعديل.

الأهمية والادعاءات

يدعي البحث أن طرق تعديل النماذج الحالية ليست قوية بما يكفي لهجرة الـ API الواقعية في النماذج اللغوية للأكواد. تكمن الأهمية الأساسية لهذا العمل في إثبات أن:

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

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