2025-11-12T15:16:15.308508

Diff-XYZ: A Benchmark for Evaluating Diff Understanding

Glukhov, Conti, Bogomolov et al.
Reliable handling of code diffs is central to agents that edit and refactor repositories at scale. We introduce Diff-XYZ, a compact benchmark for code-diff understanding with three supervised tasks: apply (old code $+$ diff $\rightarrow$ new code), anti-apply (new code $-$ diff $\rightarrow$ old code), and diff generation (new code $-$ old code $\rightarrow$ diff). Instances in the benchmark are triples $\langle \textit{old code}, \textit{new code}, \textit{diff} \rangle$ drawn from real commits in CommitPackFT, paired with automatic metrics and a clear evaluation protocol. We use the benchmark to do a focused empirical study of the unified diff format and run a cross-format comparison of different diff representations. Our findings reveal that different formats should be used depending on the use case and model size. For example, representing diffs in search-replace format is good for larger models in the diff generation scenario, yet not suited well for diff analysis and smaller models. The Diff-XYZ benchmark is a reusable foundation for assessing and improving diff handling in LLMs that can aid future development of diff formats and models editing code. The dataset is published on HuggingFace Hub: https://huggingface.co/datasets/JetBrains-Research/diff-xyz.
academic

Diff-XYZ: معيار لتقييم فهم الفروقات البرمجية

المعلومات الأساسية

  • معرّف الورقة: 2510.12487
  • العنوان: Diff-XYZ: A Benchmark for Evaluating Diff Understanding
  • المؤلفون: Evgeniy Glukhov, Michele Conti, Egor Bogomolov, Yaroslav Golubev, Alexander Bezzubov (JetBrains Research)
  • التصنيف: cs.SE (هندسة البرمجيات)، cs.LG (التعلم الآلي)
  • المؤتمر: المؤتمر الـ 39 لأنظمة معالجة المعلومات العصبية (NeurIPS 2025) - ورشة عمل: التعلم العميق للأكواد في عصر الوكلاء الذكيين
  • رابط الورقة: https://arxiv.org/abs/2510.12487

الملخص

تقدم هذه الورقة معيار Diff-XYZ لتقييم قدرة نماذج اللغة الكبيرة على فهم فروقات الأكواد (diff). يتضمن المعيار ثلاث مهام تعلم موجهة: التطبيق (الكود القديم + الفرق → الكود الجديد)، والتطبيق العكسي (الكود الجديد - الفرق → الكود القديم)، وتوليد الفروقات (الكود الجديد - الكود القديم → الفرق). تأتي بيانات المعيار من الالتزامات الحقيقية في CommitPackFT، وتتضمن 1000 ثلاثية نموذجية ⟨الكود القديم، الكود الجديد، الفرق⟩. أظهرت الدراسة أن صيغ الفروقات المختلفة يجب اختيارها وفقاً لحالات الاستخدام وحجم النموذج، مما يوفر أساساً مهماً لتطوير نماذج تحرير الأكواس المستقبلية.

الخلفية البحثية والدافع

المشاكل الأساسية

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

  1. نقص البحث المنهجي في اختيار الصيغة: بينما توجد صيغ تمثيل فروقات متعددة (unified diff، search-replace، إلخ)، إلا أن هناك نقصاً في الدراسات المقارنة المنهجية للصيغ
  2. تعقيد التقييم: تمزج المعايير الشاملة الحالية (مثل SWE-bench) عوامل متعددة (الاسترجاع، استخدام الأدوات، إلخ)، مما يصعب عزل تأثير صيغة الفروقات
  3. تنوع أنماط الفشل: قد تفشل الرقع بسبب أخطاء بناء جملة أو عدم تطابق السياق أو أخطاء منطقية، مما يتطلب تحليلاً أكثر دقة

أهمية البحث

  • القيمة العملية: معالجة فروقات الأكواد هي القدرة الأساسية لمهام تحرير الأكواس الآلي وإصلاح الأخطاء وإصلاح بناء CI
  • الأهمية النظرية: فهم كيفية معالجة نماذج اللغة الكبيرة للمعلومات الهيكلية للتحرير له أهمية كبيرة في تحسين نماذج توليد الأكواس
  • القيمة الهندسية: توفير إرشادات مدفوعة بالبيانات لاختيار صيغة الفروقات المناسبة

المساهمات الأساسية

  1. اقتراح معيار Diff-XYZ: إطار عمل تقييم خفيف الوزن وقابل للتكرار يتضمن ثلاث مهام متكاملة
  2. مقارنة منهجية للصيغ: أول مقارنة منهجية لصيغ تمثيل فروقات متعددة مع التحكم في المتغيرات
  3. إنشاء خطوط أساس الأداء: تأسيس خطوط أساس أداء مفصلة للنماذج الملكية والنماذج مفتوحة المصدر في مهام فهم الفروقات
  4. إرشادات اختيار الصيغة: اكتشاف العلاقات بين حجم النموذج ونوع المهمة واختيار الصيغة الأمثل
  5. مجموعة بيانات مفتوحة: نشر مجموعة بيانات تقييم عالية الجودة على HuggingFace Hub

شرح المنهجية

تعريف المهام

بناءً على المعادلة الفرق = الكود الجديد - الكود القديم، يتم تعريف ثلاث مهام:

X. مهمة التطبيق (Apply Task)

  • الإدخال: الكود القديم + الفرق
  • الإخراج: الكود الجديد
  • الهدف: اختبار الامتثال للصيغة والدقة على مستوى الأحرف

Y. مهمة التطبيق العكسي (Anti-Apply Task)

  • الإدخال: الكود الجديد + الفرق
  • الإخراج: الكود القديم
  • الهدف: استكشاف قابلية عكس الصيغة وعدم فقدان البيانات

Z. مهمة توليد الفروقات (Diff Generation Task)

  • الإدخال: الكود القديم + الكود الجديد
  • الإخراج: الفرق
  • الهدف: اختبار قدرة تجميع الفروقات الموثوقة

بناء مجموعة البيانات

مصدر البيانات: الالتزامات الحقيقية مفتوحة المصدر من مجموعة بيانات CommitPackFT

استراتيجية التصفية:

  • الاحتفاظ فقط بالالتزامات التي تعدل ملف واحد
  • استبعاد الملفات الثنائية والأكواس المولدة وأدلة المورّدين
  • حد عدد الأسطر في الملف: 40-1000 سطر
  • استبعاد التغييرات التي تتضمن فقط أحرف مسافات

الأخذ العينات الطبقية:

  • توزيع اللغات: Python و JavaScript و Java و Kotlin و Rust بـ 200 عينة لكل منها
  • تعقيد التحرير: تقسيم طبقي حسب عدد كتل التغيير وحجم التغيير
    • التحرير الصغير: ≤7 أسطر تغيير (40%)
    • التحرير المتوسط: 8-24 سطر تغيير (40%)
    • التحرير الكبير: >24 سطر تغيير (20%)
  • أنواع التغييرات: 81.5% تتضمن إضافة وحذف، 16.3% إضافة فقط، 2.2% حذف فقط

مقاييس التقييم

مهام التطبيق والتطبيق العكسي:

  • المطابقة الدقيقة المحررة (Stripped Exact Match - EM): معدل المطابقة الدقيقة بعد إزالة أسطر المسافات
  • تقاطع الاتحاد المحرر (Stripped Intersection over Union - IoU): النسبة على مستوى الأسطر

مهمة توليد الفروقات:

  • معدل التحليل (Parsing Rate): نسبة الفروقات القابلة للتحليل
  • معدل التطبيق (Applying Rate): نسبة الفروقات التي يمكن تطبيقها بنجاح
  • EM/IoU بعد التطبيق: معدل المطابقة الدقيقة و IoU بعد تطبيق الفرق
  • F1+ / F1-: درجات F1 للأسطر المضافة والمحذوفة

نقاط الابتكار التقني

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

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

صيغ المقارنة

  1. udiff: صيغة unified diff القياسية
  2. udiff-h: unified diff مع تخفيف رؤوس الكتل
  3. udiff-l: unified diff مع علامات صريحة (ADD/DEL/CON)
  4. search-replace: صيغة البحث والاستبدال

النماذج المختبرة

النماذج الملكية:

  • GPT-4o, GPT-4o-mini
  • GPT-4.1, GPT-4.1-mini, GPT-4.1-nano
  • Claude 4 Sonnet
  • Gemini 2.5 Flash

النماذج مفتوحة المصدر:

  • سلسلة Qwen2.5-Coder (0.5B-32B)

استراتيجيات الإشارات

  • بدون صيغة (w/o format): إشارة مساعد عامة
  • مع صيغة (w/ format): إشارة نظام تتضمن وصف الصيغة

نتائج التجارب

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

أداء النماذج الملكية:

  • Claude 4 Sonnet يحقق أفضل أداء في مهمة التطبيق (EM: 0.95-0.96)
  • GPT-4.1 يحقق أداء قوية في جميع المهام، لكنه حساس للإشارات
  • النماذج الملكية الأصغر (مثل GPT-4.1-nano) تظهر انخفاضاً كبيراً في المهام المعقدة

قوانين التوسع للنماذج مفتوحة المصدر:

  • تحسن الأداء بوضوح مع حجم النموذج
  • Qwen2.5-Coder-32B يقترب من مستوى GPT-4o في مهام التطبيق والتطبيق العكسي
  • لكن لا يزال هناك فجوة كبيرة في مهمة توليد الفروقات

نتائج مقارنة الصيغ

الاكتشافات الرئيسية:

  1. الاعتماد على المهمة:
    • التطبيق والتطبيق العكسي: صيغة udiff تحقق أفضل أداء
    • توليد الفروقات: search-replace أفضل للنماذج الكبيرة
  2. تأثير حجم النموذج:
    • النماذج الكبيرة: search-replace متفوقة في مهام التوليد
    • النماذج الصغيرة: udiff-l (مع العلامات الصريحة) هي الأفضل
  3. تحليل خصائص الصيغة:
    • مميزات search-replace: تجنب القيود العامة، استقلالية التعديلات المحلية
    • عيوب udiff-h: إزالة أرقام الأسطر تسبب التباساً في البنية
    • مميزات udiff-l: العلامات الصريحة تقلل تضارب العلامات

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

تأثير الإشارات:

  • مهمة توليد الفروقات حساسة جداً لوصف الصيغة
  • GPT-4.1 بدون وصف الصيغة يميل إلى إخراج صيغة V4A
  • مهمة التطبيق نسبياً قوية تجاه تغييرات الإشارات

الاختلافات اللغوية:

  • الأداء نسبياً متسقة عبر خمس لغات برمجية
  • أداء أفضل قليلاً على Python و JavaScript مقارنة باللغات الأخرى

الأعمال ذات الصلة

معايير توليد الأكواس

  • HumanEval/MBPP: توليد أكواس على مستوى الدوال
  • BigCodeBench: مهام استدعاء المكتبات المعقدة
  • القيود: تركز بشكل أساسي على التوليد من الصفر، لا تتعلق بتمثيلات التحرير

معايير التحرير وحل المشاكل

  • SWE-bench: حل مشاكل GitHub الحقيقية
  • CodeEditorBench: تحرير متابعة التعليمات
  • القيود: تقييم شامل، يصعب عزل تأثير الصيغة

موضع هذه الورقة

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

الخلاصة والنقاش

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

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

القيود

  1. تبسيط المهام: مهام المعيار هي وكيل مبسط للتطبيقات النهائية
  2. نطاق التقييم: يعتبر فقط فك التشفير الجشع، لا يتعلق بالاستدلال أو استخدام الأدوات
  3. تغطية الصيغ: لا تغطي صيغ AST أو الرقع المنظمة
  4. الاتصال النهائي: نقص الارتباط الكمي بين أداء المعيار والتأثير الفعلي للتطبيق

الاتجاهات المستقبلية

  1. توسيع الصيغ: استكشاف تمثيلات التحرير على مستوى الشجرة و AST
  2. الاتصال النهائي: إنشاء ارتباط بين أداء المعيار والتأثير الفعلي للتطبيق
  3. القدرة على الاستدلال: تقييم سيناريوهات الاستدلال متعدد الخطوات واستخدام الأدوات
  4. استرجاع الأخطاء: البحث عن معالجة الفروقات الجزئية أو التالفة

التقييم المتعمق

المميزات

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

أوجه القصور

  1. عمق نظري محدود: تحليل نظري غير كافٍ لآليات اختلاف الصيغ
  2. أبعاد التقييم أحادية: التركيز بشكل أساسي على الصحة، نقص الكفاءة والقابلية للقراءة
  3. تغطية النموذج غير كاملة: النماذج مفتوحة المصدر تركز بشكل أساسي على سلسلة Qwen
  4. حدود حالات الاستخدام: لم تأخذ في الاعتبار سيناريوهات التحرير التفاعلي والتحديثات الإضافية

التأثير

  1. القيمة الأكاديمية: ملء فراغ مهم في تقييم تحرير الأكواس، قد تحفز الأبحاث اللاحقة
  2. القيمة الهندسية: توفير دعم بيانات لاختيار صيغة الفروقات في الصناعة
  3. مساهمة المجتمع: المعايير المفتوحة ومجموعات البيانات ستفيد مجتمع البحث بأكمله
  4. إمكانية التوحيد: قد تصبح معياراً قياسياً لتقييم قدرات تحرير الأكواس

حالات الاستخدام

  1. تطوير النماذج: تقييم وتحسين قدرات نماذج تحرير الأكواس
  2. تصميم الصيغ: التحقق من فعالية صيغ الفروقات الجديدة
  3. اختيار الأدوات: اختيار استراتيجية الصيغة لأدوات تحرير الأكواس
  4. أساس البحث: اختبار القدرات الأساسية لمهام تحرير الأكواس المعقدة

المراجع

تستشهد الورقة بـ 31 مرجعاً ذا صلة، تتضمن بشكل أساسي:

  • معايير توليد الأكواس: HumanEval, MBPP, BigCodeBench وغيرها
  • تقييم التحرير: SWE-bench, CodeEditorBench وغيرها
  • تقارير تقنية النماذج: GPT-4o, Claude, Qwen2.5-Coder وغيرها
  • الأدوات والصيغ: Aider, GNU diffutils وغيرها

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