CuraLoc يبحث عن الأخطاء في المستودعات بخطة واحدة ويستهلك رموزًا أقل بنسبة 90%
نشر فريق بقيادة Sangeeta Warrier على arXiv طريقة CuraLoc لتحديد موضع الخطأ في مستودع كبير. بدل أن يسأل النظام النموذج عند كل خطوة عن الملف التالي الذي يجب فتحه، يطلب منه وضع خطة واحدة لفحص الشيفرة قبل تحميل الكود المصدري. على SWE-bench Verified ومع GPT-5.2، رفع CuraLoc مقياس Func@1 من 53.8% لدى LocAgent إلى 59.3%، مع استهلاك رموز مكتوبة أقل بنسبة 90.3%. تقوم الفكرة على أن يقتصر دور النموذج على الاستدلال في اختيار الشيفرة ومقارنتها، بينما يجري جلب الكود نفسه بطريقة حتمية. • حقق RepoSearcher نسبة 56.2% في Func@1، بينما حقق Agentless نسبة 39.6% فقط • على SWE-bench Lite سجّل CuraLoc نسبة 83.8% في Func@5 • جرى اختبار الطريقة على GPT-5.2 وGPT-6 Astra
معالج بواسطة الذكاء الاصطناعي من arXiv cs.LG؛ بتحرير Hamidun News
اقترح باحثون من فريق Sangeeta Warrier طريقة CuraLoc لتحديد الأخطاء على مستوى المستودع بأكمله. تستبدل الطريقة سلسلة طويلة من استدعاءات النموذج بخطة واحدة لفحص الشيفرة. على SWE-bench Verified ومع GPT-5.2، سجّل النظام 59.3% في Func@1 مقابل 53.8% لدى LocAgent، واستهلك رموزًا مكتوبة أقل بنسبة 90.3%. ظهرت النسخة الأولية من البحث على arXiv في 22 أكتوبر 2026، وصدرت نسخته الثانية في 26 أكتوبر.
لماذا لا يدل تقرير الخطأ على مكان الإصلاح؟
يصف تقرير الخطأ العَرَض: ما الذي تعطل وفي أي ظروف. أما الموضع الذي يجب تعديل الكود فيه تحديدًا، فنادرًا ما يرد فيه. لذلك تتضمن وكلاء إصلاح الأخطاء مرحلة مستقلة للتحديد (localization)، يجب فيها أن يعثر الوكيل بين آلاف الملفات والدوال على تلك التي ينبغي تعديلها.
تعالج معظم الطرق الحالية هذه المهمة بصورة تكرارية. ينظر النموذج إلى بنية المستودع، ويختار ملفًا، ويقرأه، ثم يقرر وجهته التالية، وهكذا في حلقة متواصلة. تعني كل خطوة استدعاءً جديدًا لـ LLM وكمية جديدة من الرموز في السياق. وترتفع الكلفة بسرعة، بينما تتوقف الجودة على ما إذا كان الوكيل سينحرف إلى مسار خاطئ في الخطوة الثالثة أو الخامسة.
يختبر مؤلفو CuraLoc فرضية مختلفة: يمكن التخطيط مسبقًا للقرارات المتعلقة بما يجب فحصه، قبل تحميل الكود المصدري.
خطة واحدة بدل سلسلة خطوات
يتألف خط المعالجة (pipeline) في CuraLoc من عدة مراحل. يختار النظام أولًا الملفات المرشحة، ويصف رموزها البرمجية (الدوال والفئات والطرائق) بأوصاف سلوكية وبنيوية موجزة. لا تصل الأكواد المصدرية نفسها إلى النموذج في هذه المرحلة.
بعد ذلك يأتي قرار تخطيطي واحد. في استدعاء واحد، ينجز النموذج ثلاثة أمور:
- يختار الرموز البرمجية الأولى للبدء منها؛
- يحدد الروابط التي ينبغي فحصها انطلاقًا من كل رمز (الاستدعاءات والتبعيات وغيرها من العلاقات البنيوية في الكود)؛
- يصوغ فرضيات حول التعديلات الأكثر احتمالًا.
بعدها يبدأ دور البحث الحتمي. يجمع هذا البحث الكود المصدري المطلوب دون مشاركة النموذج. ثم يجري النموذج الترتيب النهائي مستندًا إلى الفرضيات التي صاغها سابقًا. وهكذا يُصرف استدلاله على اختيار الكود ومقارنته، لا على إدارة كل خطوة من خطوات الجلب.
ماذا أظهرت الاختبارات المعيارية؟
اختبر المؤلفون الطريقة على SWE-bench Lite وSWE-bench Verified. المقياس الرئيسي على Verified هو Func@1، أي نسبة الحالات التي تحتل فيها الدالة الصحيحة المرتبة الأولى. أما على Lite فيُعرض مقياس Func@5، أي حين تقع الدالة الصحيحة ضمن أفضل خمس نتائج.
المقارنة على SWE-bench Verified مع GPT-5.2 بحسب Func@1:
- CuraLoc: 59.3%؛
- RepoSearcher: 56.2%؛
- LocAgent: 53.8%؛
- Agentless: 39.6%.
وفي استهلاك الرموز، يستخدم CuraLoc رموزًا مكتوبة أقل بنسبة 90.3% من LocAgent. وهذا ليس تحسينًا هامشيًا: فبدل عشرات الاستدعاءات للنموذج، تُختزل عملية التنقل كلها في أقل عدد ممكن منها.
على SWE-bench Lite سجّل CuraLoc نسبة 83.8% في Func@5. وهذا تحسن يتجاوز 15% قياسًا إلى Agentless.
كما بيّن المؤلفون أن الطريقة غير مرتبطة بنموذج واحد. فيُظهر CuraLoc دقة قوية في التحديد مع GPT-5.2 ومع GPT-6 Astra على حد سواء.
ما الذي يمكن الاستفادة منه عمليًا؟
الاستنتاج الرئيسي لمطوري الوكلاء هو أن تنقل النموذج المستقل في قاعدة الشيفرة لا يبرر كلفته دائمًا. فإذا نُقل جزء من القرارات إلى طبقة حتمية، وتُركت للنموذج المهام التي يتفوق فيها (صياغة فرضيات التعديل ومقارنة المرشحين)، أمكن تحقيق مكسب في الدقة والكلفة معًا في تحديد الأخطاء.
وبالنسبة إلى الفرق التي تبني وكلاء برمجة خاصة بها، يمثل ذلك سببًا لإعادة النظر في ميزانية الرموز المخصصة لمرحلة البحث. فالتحديد يسبق غالبًا توليد التصحيح (patch)، ويحدد ما إذا كان التصحيح معقولًا أصلًا. والمرحلة الأولى الرخيصة والمستقرة تخفض كلفة دورة الإصلاح كلها.
وهناك قيود تشير إليها طبيعة التجربة والمقاييس نفسها. فجميع النتائج مستمدة من SWE-bench Lite وVerified، وهي مستودعات Python ذات مهام معروفة. أما سلوك هذا النهج في المستودعات الأحادية المغلقة (monorepos) وفي لغات أخرى، فيحتاج إلى اختبار منفصل. لكن في مهمة «العثور على الدالة انطلاقًا من تقرير الخطأ»، يقدم CuraLoc حجة قوية لصالح التخطيط بدل التخبط.
نُشر البحث في قسم Machine Learning مع تصنيف مشترك هو Software Engineering (cs.SE)، ورقم DOI هو 10.48550/arXiv.2610.31809.
أسئلة وأجوبة حول الخبر
لماذا لا يدل تقرير الخطأ على مكان الإصلاح؟
يصف تقرير الخطأ العَرَض: ما الذي تعطل وفي أي ظروف. أما الموضع الذي يجب تعديل الكود فيه تحديدًا، فنادرًا ما يرد فيه. لذلك تتضمن وكلاء إصلاح الأخطاء مرحلة مستقلة للتحديد (localization)، يجب فيها أن يعثر الوكيل بين آلاف الملفات والدوال على تلك التي ينبغي تعديلها. تعالج معظم الطرق الحالية هذه المهمة بصورة تكرارية. ينظر النموذج إلى بنية المستودع، ويختار ملفًا، ويقرأه، ثم يقرر وجهته التالية، وهكذا في حلقة متواصلة. تعني كل خطوة استدعاءً جديدًا لـ LLM وكمية جديدة من الرموز في السياق. وترتفع الكلفة بسرعة، بينما تتوقف الجودة على ما إذا كان الوكيل سينحرف إلى مسار خاطئ في الخطوة الثالث
ماذا أظهرت الاختبارات المعيارية؟
اختبر المؤلفون الطريقة على SWE-bench Lite وSWE-bench Verified. المقياس الرئيسي على Verified هو Func@1، أي نسبة الحالات التي تحتل فيها الدالة الصحيحة المرتبة الأولى. أما على Lite فيُعرض مقياس Func@5، أي حين تقع الدالة الصحيحة ضمن أفضل خمس نتائج. المقارنة على SWE-bench Verified مع GPT-5.2 بحسب Func@1: CuraLoc: 59.3%؛ RepoSearcher: 56.2%؛ LocAgent: 53.8%؛ Agentless: 39.6%. وفي استهلاك الرموز، يستخدم CuraLoc رموزًا مكتوبة أقل بنسبة 90.3% من LocAgent. وهذا ليس تحسينًا هامشيًا: فبدل عشرات الاستدعاءات للنموذج، تُختزل عملية التنقل كلها في أقل عدد ممكن منها. على SWE-bench Lite سجّل
ما الذي يمكن الاستفادة منه عمليًا؟
الاستنتاج الرئيسي لمطوري الوكلاء هو أن تنقل النموذج المستقل في قاعدة الشيفرة لا يبرر كلفته دائمًا. فإذا نُقل جزء من القرارات إلى طبقة حتمية، وتُركت للنموذج المهام التي يتفوق فيها (صياغة فرضيات التعديل ومقارنة المرشحين)، أمكن تحقيق مكسب في الدقة والكلفة معًا في تحديد الأخطاء. وبالنسبة إلى الفرق التي تبني وكلاء برمجة خاصة بها، يمثل ذلك سببًا لإعادة النظر في ميزانية الرموز المخصصة لمرحلة البحث. فالتحديد يسبق غالبًا توليد التصحيح (patch)، ويحدد ما إذا كان التصحيح معقولًا أصلًا. والمرحلة الأولى الرخيصة والمستقرة تخفض كلفة دورة الإصلاح كلها. وهناك قيود تشير إليها طبيعة التجربة وا
Delegate Deep Research, Coding & Multi-Step Workflows to Nomad Agent
Deploy autonomous task execution with Nomad Agent (agent.nomadnet.ai) — automated web research, data synthesis, code generation, and MCP tool orchestration.
أهم ما في عالم الذكاء الاصطناعي — مرة كل أسبوع
سبع قصص مهمة فعلاً هذا الأسبوع، مختارة بعناية. بلا ضجيج ولا بيانات صحفية.
تم! تحقق من بريدك للتأكيد.