GitHub تطلق ReviewBench لقياس أداء وكلاء مراجعة الشيفرة بالذكاء الاصطناعي

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

معيار مبني على طلبات دمج واقعية

صممت GitHub مجموعة ReviewBench بالاستناد إلى تحليل توزيع أكثر من 103.9 مليون طلب دمج على المنصة. وتضم المجموعة 219 طلب دمج من 187 مستودعاً عاماً مرخصاً مفتوح المصدر، تغطي 19 لغة برمجة، مع مواءمة توزيع اللغات وأحجام المستودعات مع نمط GitHub العام. ومع ذلك، أعيد وزن حجم التغييرات لصالح الطلبات متوسطة وكبيرة الحجم والقابلة للمراجعة، بدلاً من تركيز مفرط على التغييرات الصغيرة في ملف واحد.

لا يعتمد ما تسميه GitHub «مجموعة الحقيقة» على مصدر واحد. فقد جُمعت النتائج المحتملة من مراجعين بشريين، وتغييرات لاحقة أجراها مؤلفو الطلبات، وأدوات تحليل ثابت، وعدة نماذج لغوية متقدمة. بعد إزالة النتائج المتداخلة دلالياً، جرى تقييمها وفق معيار موحد يحدد أن النتيجة الصحيحة يجب أن تكون صحيحة وذات صلة وغير هامشية. وتستخدم GitHub نموذج Claude Sonnet 5 بوصفه المُقيِّم اللغوي، مع نشر rubric وإعدادات التقييم بهدف تعزيز القابلية للتدقيق وإعادة الإنتاج.

مقاييس لا تعاقب اكتشاف الأخطاء الجديدة

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

هذا التفريق مهم لأن مجموعة ثابتة من الأخطاء لا يمكن أن تكون مكتملة بالضرورة؛ فقد يكتشف وكيل جديد مشكلة لم يرصدها معدّو المعيار. وتستخدم GitHub grounded recall كمؤشر رئيسي للمقارنة بين الأنظمة، بينما تقدم المقاييس الموسعة تشخيصاً إضافياً لكل نظام.

تقييم قابل للضبط وقابل للتدقيق

يمكن تقسيم النتائج بحسب شدة المشكلة وفئتها، مثل الصحة والأمن والاعتمادية وقابلية الصيانة والاختبارات. كما يسمح معيار Fβ بتغيير الوزن بين الاستدعاء والدقة، بحيث يفضل المستخدم تغطية أوسع أو عدد تعليقات أقل وأكثر دقة. وقبل الإطلاق، أعاد مهندسون كبار لم يشاركوا في بناء البيانات وسم جميع النتائج، وبلغت نسبة الاتفاق مع أحكام ReviewBench 96.6%. وتقول GitHub إنها تثبت إصدارات البيانات والمُقيِّم وأداة المطابقة المستخدمة في كل عملية تقييم.

ما الذي يثبت عملياً؟

استخدمت GitHub ReviewBench لتقييم الإصدارات المتعاقبة من Copilot Code Review، وقالت إن اتجاه التحسن أو التراجع في الاختبارات غير المتصلة تطابق مع تجارب الإنتاج. وفي تجربة لنظام مراجعة يجمع عدة تشغيلات لنماذج مختلفة، توقّع المعيار ارتفاع الدقة والاستدعاء وعدد التعليقات وانخفاض تكلفة المراجعة. وجاء اختبار A/B في الإنتاج في الاتجاه نفسه: ارتفع معدل التعليقات التي دفعت إلى تعديل في الشيفرة 8.0%، والاستدعاء 13.6%، وحجم التعليقات 61%، بينما انخفضت التكلفة لكل مراجعة 8.0% مقارنة بالتحكم. كما توقع المعيار زيادة التعليقات الحرجة 227%، مقابل 262% في الإنتاج.

القراءة التحريرية من certi.news: القيمة الأهم في ReviewBench ليست إطلاق أداة جديدة، بل محاولة تحويل تقييم وكلاء مراجعة الشيفرة إلى عملية قابلة للمقارنة والتدقيق، مع الاعتراف بأن «المزيد من التعليقات» لا يعني بالضرورة مراجعة أفضل. غير أن المصدر نفسه يقر بأن تجارب الإنتاج تظل المقياس النهائي لأثر المستخدم، كما أن اعتماد جزء من التقييم على مُقيِّم لغوي يترك سؤالاً مفتوحاً حول حدود اتساق الحكم الآلي.

تتيح GitHub نسخة بحثية أولية من المعيار، مع البيانات والمنهجية وإعدادات المُقيِّم وأداة تشغيل ذاتية. ويمكن اختبار الوكلاء على مجموعة من 25 طلب دمج، ثم تشغيل التقييم الكامل على 219 طلباً عبر ثلاث جولات قبل طلب نشر النتيجة في لوحة المتصدرين.