نظام CuraLoc يحدد موقع الأخطاء في الشيفرة بدقة أعلى بنسبة 59.3% من المنافسين ويستهلك عشر أضعاف أقل من الرموز

لماذا كانت الأساليب القديمة مكلفة

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

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

يختبر CuraLoc فكرة مختلفة: ماذا لو تم تخطيط مسار فحص الشيفرة بالكامل مسبقاً، بقرار واحد، بدلاً من اتخاذه من جديد في كل خطوة؟

كيف يعمل CuraLoc

يعمل النظام على ثلاث مراحل، تتعمق كل منها أكثر في الشيفرة:

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

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

ماذا أظهرت الاختبارات

تم اختبار الطريقة على مجموعتين من الأخطاء الحقيقية من مشاريع مفتوحة المصدر — SWE-bench Lite (274 مهمة) و SWE-bench Verified (454 مهمة)، بمقارنتها بثلاث طرق موجودة: LocAgent و RepoSearcher و Agentless، باستخدام نموذج GPT-5.2.

• في SWE-bench Verified، ارتفعت دقة تحديد الموقع الدقيق للتصحيح (مقياس Func@1) من 53.8% لـ LocAgent إلى 59.3% لـ CuraLoc — مع انخفاض استهلاك الرموز بنسبة 90.3%.
• تفوّق CuraLoc أيضاً على RepoSearcher (56.2%) و Agentless (39.6%) في نفس المقياس.
• في SWE-bench Lite، حقق CuraLoc دقة 83.8% في أفضل خمس تنبؤات، وهو تحسن نسبي بنسبة 15% مقارنة بـ Agentless.
• تم اختبار الطريقة أيضاً على النموذج الجديد GPT-6 Astra — وبقيت النتائج مرتفعة بشكل ثابت، مما يعني أن النهج غير مرتبط بنموذج محدد واحد.

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

ما يعنيه ذلك عملياً

بالنسبة للفرق العاملة على الإصلاح الآلي للشيفرة أو بناء وكلاء ذكاء اصطناعي للتطوير، يُظهر CuraLoc بديلاً عملياً للوكلاء المكلفين القائمين على الخطوات التدريجية: يمكن استبدال عشرات الاستعلامات التكرارية بخطة واحدة محسوبة لفحص الشيفرة، والحصول على دقة لا تقل، بل قد تتفوق، مع استهلاك أقل بأضعاف للرموز. هذا الأمر مهم بشكل خاص للشركات التي تريد دمج البحث الآلي عن الأخطاء في خطوط CI/CD، حيث تكون تكلفة وسرعة كل استعلام أمراً حاسماً.