SWE-QA: Can Language Models Answer Repository-level Code Questions?
تقدم هذه الورقة SWE-QA، وهو معيار مرجعي للإجابة على أسئلة الأكواد البرمجية على مستوى المستودعات مستمد من 77,100 من مشكلات GitHub، والذي يعالج أوجه القصور في مجموعات البيانات الحالية القائمة على مقتطفات الأكواد من خلال تقييم النماذج اللغوية الكبيرة في مهام الاستنتاج المعقدة متعددة الملفات عبر مجموعة منسقة من 576 سؤالاً وإطار عمل وكيل مرتبط بها.
تخيل أنك تحاول فهم كيفية عمل مكتبة ضخمة مكونة من 10 طوابق.
المشكلة: فخ "القصاصة" (The Snippet Trap) حتى الآن، كانت معظم الاختبارات لـ "الأدمغة البرمجية" للذكاء الاصطناعي تشبه عرض صفحة واحدة معزولة من كتاب عليها وسؤالهم: "ما معنى هذه الجملة؟". وبينما قد ينجح الذكاء الاصطناعي في ذلك، إلا أن البرمجيات في العالم الحقيقي ليست مجرد صفحات منفردة؛ إنها المكتبة بأكملها. للإجابة على سؤال مثل: "لماذا يُغلق الباب الأمامي تلقائياً عند غروب الشمس؟"، عليك أن تمر عبر القبو، وتفحص الأسلاك في العلية، وتقرأ المخططات في مكتب المدير. يجب عليك ربط النقاط عبر ملفات مختلفة تماماً.
فشلت اختبارات الذكاء الاصطناعي السابقة لأنها لم تجبر الذكاء الاصطناعي على القيام بـ "جولة المكتبة" هذه. لقد اختبرت فقط ما إذا كان بإمكان الذكاء الاصطناعي قراءة صفحة واحدة.
الحل: SWE-QA (جولة المكتبة) قام مؤلفو هذه الورقة البحثية ببناء اختبار جديد يسمى SWE-QA. فكر فيه كأنه "امتحان جولة في المكتبة" صارم للذكاء الاصطناعي.
المادة المصدرية: لم يقوموا بتأليف أسئلة من خيالهم. بل ذهبوا إلى 15 "مكتبة" برمجية حقيقية ومشهورة (مستودعات GitHub) وبحثوا في 77,000 سؤال حقيقي طرحها المبرمجون البشريون على بعضهم البعض.
التصنيف (الخريطة): قاموا بتنظيم هذه الأسئلة في خريطة. سألوا: هل نسأل ما هو هذا؟ أم لماذا بُني بهذه الطريقة؟ أم أين يختبئ الكود؟ أم كيف يعمل؟
البناء: أنشأوا 720 سؤالاً عالي الجودة. للإجابة عليها، لا يمكن للذكاء الاصطناعي مجرد التخمين، بل يجب عليه:
إيجاد الملف الصحيح (مثل العثور على الرف الصحيح).
قراءة الكود في ذلك الملف.
الانتقال إلى ملف آخر ليرى كيف يتصلان (الاستنتاج متعدد الخطوات).
صياغة إجابة تشرح النظام بأكمله.
التجربة: اختبار أمناء المكتبة الآليين أخذ الباحثون ستة من أذكى نماذج الذكاء الاصطناعي المتاحة (مثل GPT-5.1، وGemini، وغيرها) وأعطوهم امتحان "جولة المكتبة" هذا. واختبروهم بثلاث طرق مختلفة:
"الحافظ" (التحفيز المباشر - Direct Prompting): سألوا الذكاء الاصطناعي السؤال مباشرة دون إعطائه كتب المكتبة.
النتيجة: فشل الذكاء الاصطناعي فشلاً ذريعاً. كان الأمر أشبه بسؤال شخص عن وصف مكتبة لم يزرها قط.
"مكتشف الفهرس" (RAG): أعطوا الذكاء الاصطناعي أداة للبحث عن الصفحات ذات الصلة قبل الإجابة.
النتيجة: أفضل بكثير! استطاع الذكاء الاصطناعي إيجاد الصفحات الصحيحة، لكنه أخطأ أحياناً في الربط بينها.
"الوكيل المحقق" (أطر عمل الوكيل - Agent Frameworks): أعطوا الذكاء الاصطناعي "حقيبة أدوات المحقق" (أدوات مثل OpenHands) التي تسمح له بالتفكير، والبحث، والقراءة، والبحث مجدداً، وربط النقاط بنفسه.
النتيجة: كان هذا هو الفائز. الذكاء الاصطناعي الذي تصرف كمحقق، واستكشف قاعدة الكود بنشاط، حقق أعلى الدرجات (حوالي 70 من 100).
النتائج: ما يستطيع وما لا يستطيع الذكاء الاصطناعي فعله
الأخبار الجيدة: أصبح الذكاء الاصطناعي جيداً جداً في شرح لماذا بُنيت الأشياء بهذه الطريقة (المنطق التصميمي) أو كيف تعمل ميزة معينة، خاصة إذا كان الشرح مكتوباً بوضوح في تعليقات الكود.
الأخبار السيئة: لا يزال الذككاء الاصطناعي يعاني مع أسئلة "أين" (إيجاد مكان تعريف متغير محدد بدقة عبر 10 ملفات) والأسئلة المعقدة من نوع "ماذا" التي تتطلب تتبع سلسلة طويلة من التبعيات. الأمر يشبه أن الذكاء الاصطناعي يمكنه فهم قصة المكتبة، لكنه يضيع أحياناً في محاولة العثور على المفتاح المحدد للباب الخلفي.
التكلفة: نهج "المحقق" هو الأفضل، لكنه مكلف. فهو يستخدم قوة حوسبة (Tokens) تزيد بمقدار 100 مرة عن مجرد التخمين. إنه الفرق بين نظرة سريعة وتحقيق جنائي كامل.
الخلاصة تقدم هذه الورقة اختباراً جديداً، أصعب، وأكثر واقعية للذكاء الاصطناعي. وهي تظهر أنه بينما يبدو الذكاء الاصطناعي واعداً في فهم البرمجيات، إلا أنه لا يزال بحاجة إلى مساعدة للتنقل في الطبيعة المعقدة والمترابطة للكود في العالم الحقيقي. أفضل النتائج تأتي من وكلاء الذكاء الاصطناعي الذين يمكنهم "السير" بنشاط عبر ملفات الكود بدلاً من مجرد قراءة قصاصة صغيرة.
باختصار: لقد بنينا اختباراً أصعب لنرى ما إذا كان بإمكان الذكاء الاصطناعي فهم مشروع برمجي كامل، وليس مجرد جزء صغير منه. الذكاء الاصطناعي يتحسن، لكنه لا يزال بحاجة إلى خريطة جيدة وعقلية محقق لحل الألغاز الأكثر تعقيداً.
إليك ملخص تقني مفصل لورقة البحث بعنوان: "SWE-QA: هل تستطيع النماذج اللغوية الإجابة على أسئلة مستوى المستودع البرمجي؟"
1. بيان المشكلة
أظهرت النماذج اللغوية الكبيرة (LLMs) الحالية واعدية في فهم الأكواد، لكن المعايير المرجعية الحالية (مثل CoSQA وCodeQA) تركز بشكل أساسي على مقتطفات برمجية معزولة، أو دوال، أو واجهات برمجة تطبيقات (APIs). وتفشل هذه الإعدادات في محاكاة تعقيد هندسة البرمجيات في العالم الحقيقي، حيث يتعين على المطورين:
التنقل عبر مستودعات أكواد ضخمة ومترابطة تمتد عبر ملفات متعددة.
فهم بنية البرمجيات ومنطق التصميم (Design Rationales).
تتبع التبعيات طويلة المدى والقيام بالاستنتاج متعدد الخطوات (Multi-hop reasoning).
توليف المعرفة الهيكلية للإجابة على أسئلة معقدة من نوع "لماذا" و"كيف".
هناك نقص في المعايير المرجعية عالية الجودة والمحققة بشرياً والتي تقيم النماذج اللغوية الكبيرة على مستوى الإجابة على الأسئلة (QA) على مستوى المستودع (Repository-level)، والتي تتطلب سياقاً عميقاً متعدد الملفات وفهماً هيكلياً.
2. المنهجية: بناء معيار SWE-QA
يقترح المؤلفون SWE-QA، وهو معيار مرجعي للإجابة على أسئلة الأكواد على مستوى المستودع، تم بناؤه عبر خط إنتاج مكون من أربع مراحل (الشكل 2) يتضمن 15 مستودع بايثون متنوعاً (12 من SWE-Bench، و3 من SWE-Bench-Live).
أ. جمع البذور وبناء التصنيف (Taxonomy)
مصدر البيانات: تم استخراج 77,100 مشكلة (Issue) من GitHub من 12 مستودعاً شهيراً.
التصفية: تم اختيار 41,955 مشكلة ذات محتوى جوهري (>1,000 حرف) واستُخدم نموذج لغوي كبير لاستخراج 127,415 سؤالاً صريحاً متعلقاً بالكود.
التصنيف: قام خبيران بشريان بخبرة تزيد عن 3 سنوات بتحليل 1,000 سؤال عينة يدوياً لإنشاء تصنيف ذي مستويين:
المستوى الأول (الاستفهامي): ماذا (What)، لماذا (Why)، أين (Where)، كيف (How).
المستوى الثاني (القصد): 12 فئة دقيقة (مثل: تتبع التبعيات، منطق التصميم، تحديد موقع الميزة، تنفيذ الخوارزمية).
التوزيع: أسئلة "كيف" (35.2%) وأسئلة "أين" (28.4%) هي الأكثر تكراراً، مما يعكس الحاجة إلى المعرفة الإجرائية والمكانية.
التوليد: تم اختيار عناصر بؤرية (مثل فئة محددة) ودمج سياقها الهيكلي مع نماذج (Templates) بذرية مستمدة من التصنيف.
العملية: قام نموذج لغوي كبير بتوليد أسئلة مخصصة لمستودعات محددة، مما يضمن أنها تتطلب استنتاجاً متعدد الخطوات ولا يمكن الإجابة عليها بمجرد الاسترجاد البسيط.
ج. جمع الإجابات والتحقق منها
خط أنابيب RAG: تم توليد الإجابات باستخدام نهج التوليد المعزز بالاسترجاع (RAG)، عبر استرجاع مقتطفات الكود ذات الصلة، والوثائق، والبيانات الوصفية.
الإنسان في الحلقة (Human-in-the-Loop):
المراجعة من قبل الخبراء: قام مطوران رفيعا المستوى بمراجعة كل إجابة للتأكد من الدقة الواقعية، والاكتمال، والوضوح باستخدام أدوات مثل Cursor. وتم حل الخلافات بواسطة خبير ثالث.
تصفية الجودة: تم استبعاد الأزواج إذا كانت غامضة، أو غير صحيحة واقعياً، أو تفتقر إلى أساس كافٍ في الكود.
البيانات النهائية: 720 زوجاً عالي الجودة من الأسئلة والأجوبة (48 لكل مستودع)، تغطي 13,300 ملف وأكثر من 3.4 مليون سطر كود.
3. المساهمات الرئيسية
معيار SWE-QA: معيار مرجعي للإجابة على أسئلة الأكواد على مستوى المستودع يضم 720 زوجاً من الأسئلة والأجوبة المحققة بشرياً عبر 15 مستودع بايثون. يتميز بدمجه الفريد بين الاستنتاج متعدد الخطوات، والتبعيات عبر الملفات، والفهم الهيكلي.
خط إنتاج توليد مرن: إطار عمل معياري يسمح بإنشاء مجموعات بيانات الأسئلة والأجوبة شبه مؤتمتة لأي مستودع مفتوح المصدر جديد باستخدام النماذج البذرية والتحليل الساكن للكود.
تقييم شامل: تقييم صارم للنماذج اللغوية الكبيرة تحت استراتيجيات تعزيز سياق مختلفة (التلقين المباشر، RAG، أطر عمل الوكلاء/Agents).
4. النتائج التجريبية
قام المؤلفون بتقييم ستة نماذج لغوية كبيرة متطورة (بما في ذلك GPT-5.1، وGemini 2.5 Pro، وGLM-4.6، وQwen3-Coder) باستخدام استراتيجيات مختلفة:
تأثير تعزيز السياق:
التلقين المباشر (Direct Prompting): كان الأداء ضعيفاً (على سبيل المثال، سجل Kimi K2 حوالي 51/100)، مما يبرز ضرورة سياق المستودع.
RAG (النافذة المنزلقة/تقطيع الدوال): حسن الأداء بشكل ملحوظ (على سبيل المثال، +10–14 نقطة).
أطر عمل الوكلاء (OpenHands, SWE-agent): حققت أفضل النتائج من خلال تمكين الاستنتاج التكراري واستخدام الأدوات. حقق OpenHands مع GPT-5.1 أعلى درجة وهي 70.79/100.
أداء النماذج:
تصدر كل من GPT-5.1 و GLM-4.6 (مع OpenHands) القائمة.
عانت النماذج الأصغر (مثل Qwen3-30B) مع أطر عمل الوكلاء، حيث كان أداؤها مشابهاً أو حتى أسوأ من RAG، مما يشير إلى قيود في الذاكرة طويلة المدى والتخطيط للأدوات.
قدمت الأدوات التجارية (Cursor، Tongyi Lingma) أداءً تنافسياً (69–70)، مما يؤكد صحة الحلول المدعومة بالأدوات من طرف إلى طرف.
تحليل التصنيف:
تفوقت النماذج في أسئلة "لماذا" (منطق التصميم) وأسئلة "كيف" المتعلقة بدعم واجهة برمجة التطبيقات (API)، حيث تكون المعلومات غالباً صريحة في التعليقات التوضيحية (Docstrings).
واجهت النماذج صعوبة في أسئلة "ماذا" (استكشاف البنية) و "أين" (تحديد موقع الميزة)، والتي تتطلب إعادة بناء المنطق المشتت عبر الملفات.
التعميم عبر المستودعات:
تباين الأداء حسب تعقيد المستودع. كان "Flask" الأسهل (75.42)، بينما كان "Pylint" (62.01) و "Conan" (64.51) الأكثر صعوبة.
كانت المستودعات من SWE-Bench-Live (الأقل تسريباً للبيانات) أصعب من تلك الموجودة في SWE-Bench.
5. الأهمية والتوجهات المستقبلية
تقييم واقعي: ينتقل SWE-QA لما هو أبعد من اختبار مستوى المقتطفات لتقييم فهم "المستودع الكامل" المطلوب لمهام هندسة البرمجيات في العالم الحقيقي.
أطر عمل الوكلاء (Agent Frameworks): تشير النتائج إلى أنه بينما يساعد RAG، فإن أطر عمل الوكلاء هي حالياً النهج الأكثر فعالية للتنقل في قواعد الأكواد المعقدة ومتعددة الملفات، رغم ارتفاع تكلفة الرموز (Tokens).
القيود: المعيار حالياً مقتصر على لغة بايثون ويعتمد على لقطات ثابتة (Static Snapshots). يهدف العمل المستقبلي إلى التوسع ليشمل لغات أخرى ومستودعات ديناميكية ومتطورة.
التحديات المفتوحة: تسلط الورقة الضوء على أن النماذج اللغوية لا تزال تواجه صعوبة في تتبع التبعيات العميقة والاستنتاج المكاني الدقيق، مما يشير إلى الحاجة إلى دمج أفضل للرسوم البيانية للكود وقدرات الاستنتاج.
تخلص الورقة إلى أنه بينما تظهر النماذج اللغوية الكبيرة واعدية في الإجابة على أسئلة مستوى المستودع، خاصة عند تعزيزها بالوكلاء، إلا أن تحديات كبيرة تظل قائمة في التعامل مع التبعيات متعددة الخطوات المعقدة والاستنتاج الهيكلي.