🤖 machine learning

The Path Not Taken: Duality in Reasoning about Program Execution

تقدم هذه الورقة DexBench، وهو معيار اختبار صُمم لتقييم الفهم الديناميكي للأكواد البرمجية لدى النماذج اللغوية الكبيرة من خلال تقييم قدرتها على الاستنتاج حول تنفيذ البرامج عبر مهمتين متكاملتين: التنبؤ بالسلوك بناءً على المدخلات، واستنتاج طفرات المدخلات لتحقيق أهداف سلوكية محددة.

المؤلفون الأصليون: Eshgin Hasanov, Md Mahadi Hassan Sibat, Santu Karmaker, Aashish Yadavally

نُشر 2026-04-24

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

CC BY 4.0

المؤلفون الأصليون: Eshgin Hasanov, Md Mahadi Hassan Sibat, Santu Karmaker, Aashish Yadavally

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

تخيل أنك تعلم روبوتاً كيف يقود سيارة.

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

الفكرة الجديدة (هذه الورقة البحثية):
يجادل مؤلفو هذه الورقة بأنه لكي نختبر حقاً ما إذا كان الذكاء الاصطناعي "يستوعب" كيفية عمل الكود البرمجي، نحتاج إلى اختباره على جانبي العملة نفسها في آن واحد. وقد أطلقوا على ذلك اسم التفكير ثنائي المسار (Dual-Path Reasoning).

فكر في الأمر كأنه كتاب "اختر مغامرتك الخاصة":

المسار الأمامي (اختبار "ماذا حدث"):
تعطي الذكاء الاصطناعي قصة وخياراً محدداً (مثلاً: "أنت تنعطف يساراً"). يجب على الذكاء الاصطناعي التنبؤ بما سيحدث بعد ذلك في القصة بدقة.

بالتعبير البرمجي: "إليك برنامجاً ومدخلاً معيناً. ما هي أسطر الكود التي ستعمل؟"

المسار الخلفي (اختبار "ماذا لو"):
الآن، تخبر الذكاء الاصطناعي: "أريد للقصة أن تسلك مساراً مختلفاً (مثلاً: الانعطاف يميناً بدلاً من اليسار). ما هو الخيار الذي كان عليّ اتخاذه في البداية لجعل ذلك يحدث؟"

بالتعبير البرمجي: "إليك برنامجاً. أريد أن يعمل جزء معين من الكود لم يعمل من قبل. ما هو المدخل الذي أحتاج لتغييره لجعل ذلك يحدث؟"

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

إليكم ما وجدوه، باستخدام تشبيهات بسيطة:

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

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

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

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

إليك ملخص تقني مفصل لورقة البحث بعنوان "المسار الذي لم يُسلك: الثنائية في الاستدلال حول تنفيذ البرامج."

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

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

حدد المؤلفون قصورين حرجين في النهج الحالي:

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

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

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

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

أ. مهام الاستدلال المزدوجة

الاستدلال الأمامي (الاستدلال على التنفيذ):
- المهمة: بالنظر إلى برنامج $P$ ومدخل $I_{exec}$ ، التنبؤ بالسلوك الملحوظ $\phi(\tau_{exec})$ (مثل تغطية الكود، أو المخرجات).
- الهدف: تقييم قدرة النموذج على محاكاة حالة البرنامج للأمام من مدخل معين.
الاستدلال الخلفي (الاستدلال المضاد للواقع):
- المهمة: بالنظر إلى $P$ و $I_{exec}$ وهدف سلوكي مطلوب $\phi^*$ (مثل الوصول إلى فرع غير مغطى)، استنتاج المدخل المعدل $I_{cf}$ المطلوب لتحقيق ذلك الهدف.
- الهدف: تقييم قدرة النموذج على الاستدلال عكسياً من أثر مرغوب إلى الشروط السببية الضرورية (اضطرابات المدخلات) لاستحثاث مسار تنفيذ مضاد للواقع $\pi_{cf}$ .

ب. المعيار المرجعي: DEXBENCH

لتشغيل هذا الإطار، أنشأ المؤلفون DEXBENCH، وهو معيار يتكون من 445 حالة مزدوجة مستمدة من ثلاث مجموعات بيانات: CruxEval و HumanEval و PythonSaga.

البناء: يتم اختيار البرامج إذا كانت تحتوي على تدفق تحكم (حلقات/جمل شرطية) وتنتج تغطية كود جزئية تحت حالة اختبار معينة.
تعريف المهام:
- الأمامي: التنبؤ بمجموعة الأسطر المنفذة (تغطية العبارات) للمدخل المعطى.
- الخلفي: توليد مدخل جديد يجبر البرنامج على تنفيذ فرع محدد لم يتم تغطيته سابقاً (تعظيم زيادة التغطية).
مقياس التقييم: يُستخدم مؤشر النجاح المشترك ( $S_{dual}$ )، والذي يتطلب من النموذج أن يتنبأ بشكل متزامن بالتغطية الأصلية الصحيحة ويولد أيضاً مدخلاً مضاداً للواقع صالحاً. يُعرف النجاح بـ $S_{exec} \land S_{cf}$ .

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

الإطار المفاهيمي: صياغة "الثنائية في الاستدلال"، والحجج بأن الفهم الحقيقي للبرنامج يتطلب الاستدلال السببي عبر كل من التنفيذ الأمامي والتعديل الخلفي المضاد للواقع.
معيار DEXBENCH المرجعي: تقديم معيار صارم وثنائي المسار يقلل من مخاطر تلوث البيانات من خلال اشتراط الاستدلال الدقيق على حالات البرنامج الوسيطة بدلاً من مجرد رسم خرائط بسيطة بين المدخلات والمخرجات.
التقييم الشامل: تقييم 13 نموذجاً لغوياً كبيراً (9 مفتوحة المصدر و4 مغلقة المصدر) تتراوح أحجامها من 3 مليار إلى 72 مليار معلمة، بما في ذلك النماذج المتخصصة في الاستدلال.

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

تكشف التجارب عن نتائج غير متوقعة فيما يتعلق بقدرات النماذج اللغوية الكبيرة:

عدم تماثل الأداء: الأداء القوي في العزل (سواء كان أمامياً أو خلفياً) لا يضمن النجاح في التقييم المشترك. تفشل العديد من النماذج في التنبؤ بالتغطية رغم نجاحها في التنبؤ بها، أو العكس.
قوانين القياس لا تضمن الاستدلال:
- النماذج الصغيرة (أقل من 10 مليارات معلمة) تفشل تماماً في الاستدلال ثنائي المسار.
- النماذج متوسطة الحجم (20-30 مليار معلمة) غالباً ما تتفوق على النماذج الأكبر. على سبيل المثال، يتفوق نموذج Qwen2.5-32B بشكل كبير على Qwen2.5-72B في الاستدلال ثنائي المسار.
- التدريب اللاحق الموجه للاستدلال لا يحسن الأداء باستمرار. فالنسخ غير الموجهة للاستدلال (مثل Mistral Small 24B و Qwen2.5-32B) غالباً ما تتفوق على نظيراتها الموجهة للاستدلال (مثل Magistral Small و QwQ-32B) في هذه المهمة المحددة.
هيمنة النماذج مغلقة المصدر: تحقق النماذج مغلقة المصدر (مثل Claude Sonnet 4 و Grok-4 Reasoning و GPT-5 Mini) أعلى الدرجات عموماً، رغم أنها لا تزال تعاني مع تدفق التحكم المعقد في مجموعة بيانات PythonSaga.
تحليل الأخطاء:
- الأخطاء الأمامية غالباً ما تنتج عن سوء قراءة المطالبة (Prompt) أو الهلوسة في بنية الكود.
- الأخطاء الخلفية تنبع تكراراً من سوء الفهم الدلالي لسلوك واجهة برمجة التطبيقات (API) (مثل الخلط بين split() و splitlines()) أو الفشل في الحفاظ على الاتساق السببي في انتقالات الحالة.

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

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

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