المحتوى
أظهر مقال Can Bölük بعنوان مشكلة إطار التشغيل تفوّق التعديلات بأسلوب hashline (المرتكزة على أرقام الأسطر، مثل 4#WB) على التعديلات التقليدية بوضع replace (مطابقة old_string/new_string) لدى وكلاء البرمجة.
كنت أجرّب بناء إطار تشغيل خاص بي (tau)، وأردت التحقّق من هذه النتيجة ومعرفة ما إذا كان عليّ التفكير في اعتماد hashline استراتيجيةً افتراضيةً للتعديل فيه.
لذلك أنشأت edit-bench لاختبار ذلك بنفسي عبر لغات ونماذج متعددة.
الإعداد
يولّد edit-bench اختبارات قائمة على الطفرات انطلاقًا من قواعد شيفرة موجودة. توجّه سكربتًا إلى مجلد، فيولّد طفرات مثل حذف تعليمة، أو قلب قيمة منطقية، أو تبديل مواضع الوسائط، وما إلى ذلك.
- اللغات: Python (من hive)، TypeScript (من oh-my-pi)، Rust (من irradiate)
- النماذج:
gpt-4.1-mini،google/gemini-3-flash-preview،qwen/qwen3.5-397b-a17b - أوضاع التعديل: replace (old_string/new_string) مقابل hashline (الارتكاز على أرقام الأسطر)
- 20 مهمة لكل لغة، في تشغيلات لمرة واحدة بمحاولة واحدة
- أضفت أيضًا مؤخرًا المطابقة التقريبية إلى
tau(تسلسل التشذيب:trim_end → trim_both → unicode normalization)، وأردت معرفة ما إذا كان ذلك يساعد
النتائج
وضع replace:
| النموذج | Python | TypeScript | Rust |
|---|---|---|---|
| gemini-3-flash | 95% | 80% | 95% |
| qwen3.5-397b | 90% | 85% | 85% |
| gpt-4.1-mini | 65% | 75% | 45% |
وضع hashline (من تشغيلات سابقة):
| النموذج | Python | TypeScript | Rust |
|---|---|---|---|
| gemini-3-flash | 70% | 85% | 90% |
| qwen3.5-397b | 85% | 85% | 90% |
| gpt-4.1-mini | 50% | 70% | 55% |
يؤثر hashline سلبًا على الأداء في Python بصورة ملحوظة، ويبدو أن أثره محايد تقريبًا في TypeScript وRust. هذا التأثر باللغة مثير للاهتمام — فقد تجعل المسافات البيضاء ذات الدلالة في Python التعديلات المرتكزة على الأسطر أكثر عرضةً للأخطاء.
هل تساعد المطابقة التقريبية؟
لا، على ما يبدو.
أضفت جمع بيانات التتبّع لمعرفة ما إذا كان تسلسل التشذيب التقريبي في tau يتفعّل أصلًا خلال تشغيلات وضع replace. وعبر 114 تعديلًا ناجحًا و20 تعديلًا فاشلًا (3 نماذج × 3 لغات)، كان عدد مرات تفعيل المطابقة التقريبية صفرًا.
من بين التعديلات الفاشلة الـ20:
- تعديل واحد احتوى على مسافات بيضاء في النهاية (يمكن إصلاحه نظريًا)
- نحو 8 تعديلات تضمّنت أرقام أسطر في
old_string(خلل في النموذج) - نحو 11 تعديلًا احتوى على محتوى مختلق بالكامل
عندما تصيب النماذج في old_string، تصيب في المسافات البيضاء أيضًا.
وعندما تخطئ، يكون خطؤها كبيرًا جدًا — ولا يفيد تسلسل التشذيب.
الاستنتاجات
-
لا يوجد فائز واضح بين hashline وreplace. يعتمد التأثير على اللغة والنموذج. يتراجع أداء hashline في Python؛ ويظل الأثر محايدًا في TypeScript؛ والنتيجة غير محسومة في Rust.
-
يصعب تعميم نتائج Can. يقتصر react-edit-benchmark على JavaScript ويستخدم LSP لتوفير ملاحظات التحقّق. تُظهر بيئة اختبارنا (بلا LSP، ومع لغات متعددة) صورة مختلفة. ومن المرجّح أن تمثّل حلقة التغذية الراجعة من LSP تحديدًا عاملًا مُربكًا. فتزويد النموذج بأخطاء الأنواع ليعيد المحاولة بناءً عليها يمنحه دفعة مؤثرة يتداخل أثرها مع صيغة التعديل.
-
لا تمثّل المطابقة التقريبية مشكلة للنماذج الحالية. تعيد النماذج اللغوية الكبيرة إنتاج النص المصدري بحذافيره، أو تختلق شيئًا مختلفًا تمامًا. فحالة الاختلاف الطفيف في المسافات البيضاء التي تستهدفها المطابقة التقريبية تكاد لا تحدث في الممارسة العملية.
-
بالنسبة إلى نماذج الجيل الحالي ضمن أطر التشغيل الحديثة، ليست صيغة التعديل هي عنق الزجاجة. الفارق بين النماذج (gemini-3-flash عند 90%+ مقابل gpt-4.1-mini عند 55-65%) يفوق بكثير الفارق بين صيغ التعديل. استثمر في اختيار النموذج وهندسة الموجّهات قبل الانشغال بصيغة التعديل.
التنويه الذي لا بدّ منه: حجم العينة صغير، والاختبار غير صارم إحصائيًا، فتعامل مع النتائج على هذا الأساس.
جميع البيانات: nwyin/edit-bench، في المسألتين #13 و#14.