تم إصدار مجموعة بيانات DeNovoSWE لإنشاء كود على مدى طويل

مع تحسّن قدرات وكيل LLM للرمز، أدرك عدد متزايد من الباحثين أن الوقت قد حان للانتقال إلى المرحلة التالية: المهام الطويلة التي تتماشى بشكل أقرب مع احتياجات السيناريوهات الواقعية. وقد ظهرت بعض مجموعات تقييم المهام الطويلة مثل NL2RepoBench وBeyondSWE. وبدأت التوقعات من وكيل الرمز تتحول تدريجيًا من دور مُحافظ على المستودع إلى دور مهندس معماري، قادر على التخطيط وإكمال مهام طويلة المدى تشمل كود المستودع بأكمله.

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

رابط الورقة البحثية: https://arxiv.org/pdf/2606.10728

رابط المستودع: https://github.com/AweAI-Team/DeNovoSWE

رابط البيانات: https://huggingface.co/collections/AweAI-Team/denovoswe

تم إنشاء مجموعة بيانات عالية الجودة من خلال آليات Divide & Conquer و Critic & Repair، وتحقيق النمو الناجح لمهام SWE الطويلة المدى، مما أدى إلى بناء مجموعة بيانات مفتوحة المصدر عالية الجودة تحتوي على 4,818 بيانات حقيقية لمهام SWE الطويلة المدى — هذه النتيجة وفرت كمية كبيرة من البيانات لتدريب قدرات Code Agent على المهام الطويلة المدى، وعززت بشكل كبير قدرات Code Agent على تنفيذ هذه المهام.

كما قدمت الورقة وسيلة لتصفية النقاط بناءً على صعوبة السؤال، مما يخفف بشكل فعال مشكلة التوازن بين نسبة الأسئلة الصعبة وجودة المسار.

أظهرت التجارب أن Qwen3-30B-A3B-Instruct المدرب على DeNovoSWE تحسن من 5.8% إلى 47.2% على BeyondSWE-Doc2Repo، ومن 4.3% إلى 23.0% على NL2RepoBench، مما يُظهر تحسينًا ملحوظًا في قدرة توليد الكود على مستوى المستودعات بفضل البيانات الطويلة المدى.

على مدار العام الماضي، مع تزايد حجم بيانات SWE مثل Scale-SWE، تحسّنت وكيلات الكود بسرعة في مهام هندسة البرمجيات الحقيقية مثل SWE-bench. لكن مع تحسن النماذج في "إصلاح مشكلة" أو "تعديل بضعة أسطر من الأخطاء"، بدأ ظهور سؤال أكثر أهمية: هل تمتلك الوكلاء فعلاً قدرات هندسة برمجيات طويلة المدى؟ ومن نتائج النماذج الرائدة مثل BeyondSWE-Doc2Repo و NL2RepoBench، يبدو أن الأداء غير مرضٍ.

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

بعبارة أخرى، التحدي يكمن في توليد مستندة إلى مستودع على المدى الطويل: من وثيقة مهمة، توليد مستودع برمجي كامل وقابل للتنفيذ والتحقق. وهذا بالضبط ما يهدف DeNovoSWE إلى حلّه.

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

يجب أن يلبي مستند المهمة عالي الجودة على الأقل معيارين أساسيين.

أولاً، يجب أن يكون منظمًا جيدًا.

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

ثانيًا، يجب أن يُبنى من منظور تقييم موثوق.

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

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

هذا أيضًا هو الفكرة الأساسية لـ DeNovoSWE: جعل الوثائق قابلة للقراءة، والتنفيذ، والتحقق.

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

في مرحلة Divide، يحلل النظام المستودع الهدف، ويفصله إلى عدة قدرات مستودع.

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

في الوقت نفسه، سيقوم DeNovoSWE بتشغيل اختبارات الوحدة الأصلية وجمع trace التنفيذ، لتحديد أي وظائف وفئات وواجهات تؤثر حقًا على التقييم، وتمييز المكونات المباشرة والمكونات غير المباشرة الأساسية والمكونات غير المباشرة غير الأساسية: يجب توثيق الواجهات التي تُستدعى مباشرة من قبل الاختبار بالتفصيل؛ كما يجب تغطية المكونات غير المباشرة الأساسية التي تؤثر على السلوك القابل للملاحظة؛ بينما يمكن ترك التنفيذ الداخلي غير الأساسي للوكيل ليتصرف بحرية.

في مرحلة Conquer، يستخدم DeNovoSWE آلية Draft-Critic-Repair لإنشاء الوثائق بشكل تدريجي حسب القدرة. يقوم وكيل Draft بكتابة المسودة الأولى؛ ثم يتحقق وكيل Critic من عدم نقص أي واجهات برمجة تطبيقات رئيسية، أو عقود سلوكية، أو معلومات هيكلية؛ ثم يقوم وكيل Repair بإصلاح الوثيقة بناءً على الملاحظات. وتستمر هذه الدورة بشكل تكراري حتى تصبح كل فقرة من فقرات القدرة واضحة وكاملة ومتوافقة مع التقييم.

في النهاية، سيتم دمج وثائق القدرات المختلفة في مستند مهام كامل كأساس وحيد ل-Agent لإنشاء مستودع من الصفر.

الصعوبة: لماذا هذه مهمة طويلة المدى؟

صعوبة مهمة DeNovoSWE تأتي من تغيير جوهري: فهي لم تعد تصحيحًا على مستوى المشكلة، بل إنشاءًا كاملًا للمستودع.

في مهام SWE التقليدية، يواجه الوكيل عادةً مستودعًا موجودًا، ويتطلب فقط تحديد العطل، وتعديل جزء من الكود، والمرور بالاختبارات.

في DeNovoSWE، يواجه الوكيل بيئة تم تنظيفها: تم إزالة الكود المصدر الأصلي والاختبارات، وأُعيد تعيين سجل git، وتم تنظيف قنوات التسرب المحتملة مثل ذاكرة التخزين المؤقت، ومخلفات site-packages، وعجلات pip، ومنتجات التجميع المؤقتة. هذا يعني أن الوكيل يجب أن يعتمد حقًا على الوثائق لإعادة بناء المستودع بالكامل. فهو بحاجة إلى تخطيط هيكل المشروع، وإنشاء ملفات الوحدات، وتعريف واجهات public، وتنفيذ التفاعل عبر الملفات، ومعالجة التبعيات والتكوين، وإصلاح الأخطاء باستمرار خلال جلسات تحرير واختبار متعددة.

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

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

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

قام DeNovoSWE ببناء 4818 مثالًا عالي الجودة لمهمات document-to-repository. بيئة برمجية طويلة المدى قابلة للتنفيذ والتقييم والتدريب.

أظهرت نتائج التجربة أن DeNovoSWE قدم تحسينًا ملحوظًا في قدرة النموذج على توليد مستودعات طويلة المدى. على نموذج Qwen3-30B-A3B-Instruct، كان أداء النموذج الأصلي فقط 5.8% على BeyondSWE-Doc2Repo و4.3% على NL2RepoBench. يمكن لـ Scale-SWE-Agent المدرب باستخدام بيانات SWE على مستوى المشكلة رفع الأداء إلى 29.2% و18.3%، مما يشير إلى أن بيانات SWE العادية لها تأثير نقل فعلي. لكن عندما تم تدريب النموذج باستخدام DeNovoSWE، ارتفع الأداء إلى 47.2% و23.0%.

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

على نواة Qwen3.5-35B-A3B الأقوى، يوفر DeNovoSWE أيضًا عوائد مستقرة: ارتفع BeyondSWE-Doc2Repo من 43.8% إلى 50.0%، وارتفع NL2RepoBench من 23.5% إلى 27.1%. وهذا يُظهر بشكل إضافي أن عوائد DeNovoSWE ليست نتيجة تكيف عرضي مع نموذج واحد، بل تأتي من جودة البيانات الطويلة المدى نفسها.

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

قمت DeNovoSWE ببناء هذا الهدف كمجموعة بيانات قابلة للتدريب والتحقق والتوسيع بشكل منهجي. إنها تجيب على سؤال أساسي: ما نوع البيانات الذي يمكنه حقًا تدريب وكيل يمتلك قدرات هندسة برمجيات طويلة المدى؟

الإجابة ليست مزيدًا من الشيفرات المجزأة، ولا مسائل أبسط، بل مهام توليد كاملة للمستودع بجودة عالية، ومنظمة، ومتوافقة مع التقييم، ومضادة للتسريب.

ابدأ بمستند واحد، وأعد بناء المستودع بالكامل. هذا هو الحد الذي يجب على وكيل الكود طويل المدى تجاوزه.

المراجع: https://arxiv.org/pdf/2606.10728

هذا المقال من حساب WeChat "New Intelligence Yuan"، تحرير: LRST