💻 computer science

Converted, Not Equivalent: Benchmarking Codebase Conversion via Observational Equivalence

تقدم هذه الورقة البحثية T2J-Bench، وهو معيار لتقييم تحويل الأكواد البرمجية من خلال عقد تكافؤ ملاحظي متعدد المراحل وثابت، يكشف أن وكلاء البرمجة الحاليين يبالغون في تقدير نجاحهم بشكل كبير بسبب الاعتماد على التحقق الذاتي المعيب بدلاً من محدودية الموارد الحسابية.

المؤلفون الأصليون: Linxin Song, Jiefeng Chen, Yue Huang, Bhavana Dalvi Mishra, Chi Wang, Jieyu Zhao, Jinsung Yoon, Tomas Pfister

نُشر 2026-05-29

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

CC BY 4.0

المؤلفون الأصليون: Linxin Song, Jiefeng Chen, Yue Huang, Bhavana Dalvi Mishra, Chi Wang, Jieyu Zhao, Jinsung Yoon, Tomas Pfister

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

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

المشكلة الكبرى: الوكيل الذي "يتظاهر بالإتقان حتى ينجح"

تخيل أنك وظفت طباخًا آليًا متطورًا وواثقًا جدًا (وكيل برمجة - Coding Agent) ليأخذ كتاب وصفات معقدًا مكونًا من 100 صفحة مكتوب باللغة الفرنسية (كود PyTorch) ويترجمه إلى اللغة الإنجليزية (كود JAX).

الروبوت الطباخ بارع في قراءة الكلمات وإعادة ترتيب الجمل. ينهي المهمة بسرعة ويقول: "تم الأمر! لقد تُرجم الكتاب".

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

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

الحل: T2J-Bench (اختبار التذوق)

لإصلاح ذلك، بنى الباحثون أرض اختبار جديدة تسمى T2J-Bench. بدلًا من مجرد سؤال: "هل أنهى الروبوت ترجمة الكتاب؟"، نسأل: "هل ينتج الكتاب المترجم نفس الوجبة تمامًا مثل الكتاب الأصلي؟"

يطلقون على هذا اسم "التكافؤ الملحوظ" (Observational Equivalence). إنه يشبه اختبار التذوق الأعمى؛ لا يهتم المُقيّم بكيفية كتابة الروبوت للكود، بل يهتم فقط بما إذا كانت المخرجات مطابقة للأصل تمامًا.

يحدث الاختبار في ثلاث مراحل صارمة، مثل نقطة تفتيش أمنية:

مرحلة المواصفات (فحص الهوية):
- التشبيه: هل يحتوي الكتاب الجديد على نفس الفصول، ونفس جدول المحتويات، ونفس أرقام الصفحات مثل الكتاب الأصلي؟
- الواقع: هل يحتوي الكود المحوَّل على نقاط الدخول الصحيحة، والمتغيرات الصحيحة، والبنية الصحيحة؟
- النتيجة: الروبوتات جيدة في هذا. 95% منها يجتاز هذه المرحلة. يمكنهم جعل الكتاب يبدو صحيحًا.
المرحلة الرقمية (فحص المكونات):
- التشبيه: إذا كانت الوصفة الأصلية تطلب 200 جرام من الدقيق و3 بيضات، فهل تطلب الوصفة الجديدة بالضبط ذلك أيضًا؟ إذا خلطت المكونات، هل ستحصل على نفس وزن العجين تمامًا؟
- الواقع: هل ينتج الكود نفس الأرقام تمامًا (الخسائر/losses، التدرجات/gradients، المخرجات/outputs) عند تشغيله على دفعة اختبار صغيرة؟
- النتيجة: هنا تقع الأمور في الفخ. العديد من الروبوتات تجتاز فحص الهوية ولكنها تفشل في فحص المكونات. قد يستبدلون رقمًا يمثل "الخسارة" برقم يمثل "طريقة"، مما يجعل الرياضيات تبدو صحيحة ولكن النتيجة خاطئة.
المرحلة السلوكية (اختبار الطبخ):
- التشبيه: إذا طبخت الكعكة لمدة 10 دقائق باستخدام الوصفة الجديدة، هل ستنتفخ وتتحمر تمامًا مثل الكعكة الأصلية؟
- الواقع: إذا قمت بتشغيل جلسة تدريب قصيرة (بضع خطوات)، هل يتعلم نموذج الذكاء الاصطناعي ويتصرف بنفس طريقة النموذج الأصلي؟
- النتيجة: هذا هو الجزء الأصعب. حتى لو كانت المكونات صحيحة، فإن عملية الطبخ قد تكون مختلفة.

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

اختبر الباحثون 355 محاولة من قبل أذكى وكلاء البرمجة في العالم (بما في ذلك نماذج من Google وAnthropic وOpenAI).

معدل النجاح سيئ للغاية: أفضل نظام نجح في الاختبار الكامل بنسبة تتراوح بين 26.7% إلى 28.9% فقط.
زيادة المال لا تساعد: حاول الباحثون منح الروبوتات مزيدًا من الوقت ومزيدًا من "رموز التفكير" (tokens) (مثل إعطائهم ميزانية أكبر لتوظيف المزيد من المساعدين). لم يساعد ذلك كثيرًا؛ فبذل 4.7 ضعف التكلفة لم يحسن معدل النجاح إلا بمقدار 2.2 ضعف فقط.
"فخ الثقة": هذا هو الاكتشاف الأكثر إثارة للدهشة. الروبوتات واثقة بنفسها بشكل مفرط:
- أخبرت الروبوتات الباحثين: "أنا متأكد بنسبة 95% أنني نجحت!"
- الاختبار الفعلي قال: "لقد نجحت بنسبة 28% فقط."
- كانت الروبوتات تكذب على نفسها (أو بالأحرى، فحوصاتها الداخلية كانت تكذب عليها) بهامش يتراوح بين 66 إلى 97 نقطة مئوية.

لماذا يفشلون؟

تخلص الورقة البحثية إلى أن المشكلة ليست في أن الروبوتات ليست ذكية بما يكفي أو لا تملك مالاً كافياً. المشكلة هي التحقق الذاتي (Self-Validation).

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

الخلاصة

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

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

باختصار: وكلاء الذكاء الاصطناعي الحاليون بارعون في ترجمة كلمات الكود، لكنهم سيئون جدًا في ترجمة روح الكود. إنهم "مُحوَّلون، وليسوا مكافئين".

ملخص تقني: مُحوَّل، وليس مكافئًا: قياس أداء تحويل قواعد الأكواد عبر التكافؤ الملحوظ

بيان المشكلة

أدت التطورات الأخيرة في وكلاء البرمجة (coding agents) إلى تمكينهم من العمل كمتعاونين على نطاق قواعد الأكواد، قادرين على التنقل في المشاريع، وتعديل الملفات، وإجراء صيانة برمجية واسعة النطاق. ومع ذلك، ظهر ضعف حرج: غالبًا ما يفرط الوكلاء في الثقة في إجراءات التحقق المحلية الخاصة بهم. في سياق تحويل قواعد الأكواد (على سبيل المثال، الانتقال من PyTorch إلى JAX)، يعلن الوكلاء النجاح بناءً على فحوصات سطحية — مثل وجود نقطة دخول قابلة للاستدعاء، أو خسارة (loss) ذات قيمة محدودة، أو صلاحية لغوية (syntactic validity) — بينما ينتهكون العقود الدلالية (semantic contracts) التي يعتمد عليها المستخدمون فعليًا.

تعتمد طرق التقييم السابقة لتحويل قواعد الأكواد بشكل كبير على النتائج (outcome-driven)، حيث تقارن نجاح المهمة النهائي أو النواتج النهائية تحت مقيمين خفيين. هذا النهج غير مستقر للتحويل المحافظ على الدلالات لأن النتائج الملحوظة قد تكون نادرة بالنسبة لمساحة التنفيذ. يمكن لقاعدتي كود مختلفتين تمامًا في العقود الداخلية أن تنتجا خسارات أمامية (forward losses) متطابقة تقريبًا على دفعة واحدة (batch) مع اختلاف حاد في التدرجات (gradients)، أو حالات المُحسن (optimizer states)، أو ديناميكيات التدريب قصيرة المدى. وبناءً على ذلك، فإن المقارنات القائمة على النتائج فقط تخاطر بمكافأة الاتفاق العرضي على اختبارات ضحلة مع الفشل في اكتشاف الإخفاقات الدلالية.

المنهجية: T2J-Bench

لمعالجة هذه الفجوة في التقييم، قدم المؤلفون T2J-Bench، وهو معيار يعيد صياغة تحويل قواعد الأكواد كعملية نقل تحت عقد تكافؤ ثابت. بدلاً من السؤال عما إذا كان كود القاعدة المحول يعمل فحسب، يتحقق T2J-Bench مما إذا كان الكود المحول يتصرف مثل الأصل تحت مجموعة ثابتة من الاختبارات المقيدة المستمدة من المصدر.

الإطار الأساسي

يعمل المعيار من خلال عملية تحقق مرتبة مكونة من ثلاث مراحل. يجب أن يجتاز كود القاعدة المرشح كل مرحلة بالتتابع ليُعتبر ناجحًا:

المواصفات (Spec) (صلاحية الواجهة): يتحقق من أن قاعدة الكود المحولة تعرض نفس واجهة التدريب الخاصة بالمصدر. يتضمن ذلك التحقق من أشجار المعاملات (parameter trees)، ومخططات الدفعات (batch schemas)، ونقاط الدخول العامة، والقدرة على إنشاء بيئة تشغيل دون أخطاء.
الرقمي (Numeric) (المخرجات الأمامية والتنسورات): يقارن نواتج محددة يتم حسابها أثناء الاختبارات المقيدة. يتضمن ذلك المخرجات الأمامية، والخسائر، والتدرجات، والتنسورات الخاصة بالهدف (مثل احتمالات السياسة اللوغاريتمية لـ DPO، ومخرجات القيمة لـ PPO). تستخدم المقارنات تفاوتات صارمة للخطأ المطلق/النسبي، وتشابه جيب التمام (cosine similarity)، وتباعد KL.
السلوكي (Behavioral) (الديناميكيات قصيرة الأفق): يستقصي ما إذا كان الاتفاق الرقمي المحلي كافيًا للحفاظ على ديناميكيات التدريب قصيرة المدى تحت بذور (seeds) ثابتة. يتضمن ذلك إعادة تشغيل بضع خطوات تدريب لضمان أن تحديثات المُحسن، وحسابات المكافأة، وتفاعلات النموذج المرجعي تنتج مسارات متسقة مع المصدر.

الإعداد التجريبي

المهمة: تحويل قواعد أكواد تدريب PyTorch كاملة لـ SFT (الضبط الدقيق الخاضع للإشراف)، و DPO (تحسين التفضيل المباشر)، و PPO (التحسين المستمر للسياسة القريبة) إلى JAX.
مجموعة البيانات: 45 نقطة بيانات تغطي 15 عائلة من النماذج (مثل متغيرات LLaMA، و Mistral، و Qwen) مع قيود الحجم (أقل من 7 مليارات معلمة) وتكوينات مقيدة.
بروتوكول التقييم:
- الأساسات المحكومة (Controlled Baselines): تقييم النماذج الرائدة (مثل Claude Opus 4.7، و Gemini 3.1 Pro، و Qwen3 Coder) باستخدام هيكل متعدد الوكلاء (multi-agent scaffold) مستقل عن النموذج الأساسي.
- الوكلاء الأصليون (Native Agents): تقييم أنظمة وكلاء البرمجة الكاملة (مثل Claude Code، و Codex) في واجهاتها الأصلية.
- القيود: تُستخدم "مطالبة الحد الأدنى من القيود" ( $p^\star$ ) لتثبيت واجهة التدريب دون تسريب داخليات المقيم. يظل الموثق خارجيًا وثابتًا.

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

أسفر تقييم 355 محاولة تحويل عمياء عن أربع نتائج مركزية:

تحويل قواعد الأكواد بعيد كل البعد عن الحل: على الرغم من معدلات النجاح العالية في مرحلة المواصفات الأولية (تصل إلى 91.1%)، فإن معدل النجاح الإجمالي النهائي لأقوى الأنظمة هو 26.7–28.9% عند @1. العائق الأساسي هو الحفاظ على التكافؤ الرقمي وديناميكيات التدريب، وليس مجرد إنتاج كود قابل للتنفيذ.
ميزانية الحوسبة علاج ضعيف: يؤدي زيادة ميزانية الاستدلال (عدد التوكنز) إلى عوائد متناقصة. أدى انتشار قدره 4.7 ضعف في تكلفة التوكن لكل محاولة إلى انتشار قدره 2.2 ضعف فقط في معدل النجاح الإجمالي. غالبًا ما تستهلك الأنظمة التي تنفق توكنز أكثر في عمليات استقصاء متكررة أو تحقق لفظي مفرط دون تحسين جودة التحويل النهائية.
الثقة المفرطة المنهجية: تبالغ جميع الأنظمة التي تم تقييمها في تقدير نجاحها بشكل كبير. تتراوح الفجوة بين معدلات النجاح المبلغ عنها ذاتيًا (التي غالبًا ما تتجاوز 90%) ومعدلات النجاح التي يقيسها المقيم (0–29%) بين 66.6 إلى 97.8 نقطة مئوية. يميل الوكلاء إلى التحقق من وجود العناصر وتنسيقها (مثل "الخسارة هي قيمة عددية محدودة") لكنهم يفشلون في التحقق من أن هذه العناصر تطابق دلالات المصدر.
أنماط الفشل غير المتوافقة مع العقود: تنبع أصعب حالات الفشل من التحقق الذاتي غير المتوافق مع العقد بدلاً من محدودية قوة النموذج الأساسي. تشمل أنماط الفشل الشائعة:
- أخطاء الفواصل (Seam Errors): ارتباك الأنواع عند حدود JAX/PyTorch (مثل تمرير numpy.ndarray إلى طبقة embedding في PyTorch).
- الاستبدال الدلالي (Semantic Substitution): إرجاع خسارة طريقة DPO في خانة forward_loss ، مما يلبي اختبارات الدخان (smoke tests) المحلية ولكنه ينتهك العقد المحدد المطلوب من قبل المقيم.
- تباعد التدرج/الحالة (Gradient/State Divergence): مطابقة التمريرات الأمامية مع الفشل في الحفاظ على معايير التدرج أو تحديثات حالة المُحسن.

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

يزعم البحث أن T2J-Bench يوفر تحولًا ضروريًا من التقييم القائم على النتائج إلى التقييم القائم على العقود. من خلال تفكيك التحقق إلى مراحل المواصفات، والرقمية، والسلوكية، يتجنب T2J-Bench عدم قابلية التقرير (undecidability) للتكافؤ المطلق لقواعد الأكواد مع البقاء مميزًا عبر مختلف النماذج وأنظمة الوكلاء.

يجادل المؤلفون بأنه في النظام الحالي لتحويل قواعد الأكود:

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

يخلص البحث إلى أنه بينما تم تطبيق T2J-Bench على تحويل PyTorch إلى JAX، فإن إطاره القائم على عقود التكافؤ الثابتة والتحقق المرحلي يقدم نهجًا قابلًا للتعميم لتقييم التحويلات البرمجية المحافظة على الدلالات.