Michael Johnsonقد يترك مراجع الذكاء الاصطناعي عشرات التعليقات، ومع ذلك يفوته عيب مهم للإصدار. في 5 أكتوبر 2026، أعلنت GitHub عن ReviewBench، وهو إصدار بحثي أولي لمعيار يقارن الوكلاء بناءً على المشكلات التي يكتشفونها ويفوتونها ودقة ملاحظاتهم.
بالنسبة إلى المطورين، يكمن التحول المهم في الانتقال من عدّ التعليقات إلى التحقق من مضمونها. يقارن المعيار مخرجات الوكيل بمجموعة مرجعية من المشكلات في طلب السحب، ويأخذ في الحسبان على نحو منفصل خطورة النتائج وفئتها.
ما الذي يقيسه ReviewBench تحديدًا؟
تضم المجموعة 219 طلب سحب عامًا من 187 مستودعًا مفتوح الترخيص، وتحتوي على شيفرات بـ19 لغة. وتفيد GitHub بأنها حللت توزيع أكثر من 103.9 ملايين طلب سحب عند إعداد المجموعة. واختيرت أحجام المستودعات واللغات مع مراعاة العينة العامة على GitHub، فيما جرى عمدًا ترجيح التغييرات الأكبر حجمًا نحو طلبات سحب أكثر ثراءً بالمحتوى وملائمة للمراجعة.
يحتفظ المعيار لكل طلب سحب بملاحظات مرجعية مصنفة بحسب الخطورة والفئة، مثل الصحة والأمان والموثوقية وقابلية الصيانة والاختبار. ويحسب ReviewBench الدقة: نسبة تعليقات الوكيل التي تتوافق مع مشكلات فعلية؛ والاستدعاء: نسبة المشكلات المعروفة التي اكتشفها الوكيل. ويتيح مقياس Fβ تغيير الوزن النسبي لهذين المعيارين: فالتركيز الأكبر على الاستدعاء يناسب البحث عن عدد أكبر من المشكلات، بينما يناسب التركيز الأكبر على الدقة الحد من الملاحظات المشوشة.
كيف نقرأ أرقام GitHub؟
يشير المنشور إلى توافق بنسبة 96.6% بين تصنيفات ReviewBench وإعادة تحقق مستقلة أجراها مهندسون كبار. وهذا مقياس لاتساق تقييم الخبراء للنتائج المرجعية، وليس مقياسًا لدقة أي وكيل من وكلاء الذكاء الاصطناعي.
كما وصفت GitHub، على نحو منفصل، اختبار A/B داخليًا لمجموعة من النماذج المستخدمة في مراجعة الشيفرات عبر Copilot. ووفقًا للشركة، مقارنةً بالمجموعة الضابطة، ارتفعت نسبة التعليقات التي أعقبتها تغييرات مناسبة في الشيفرة بنسبة 8.0%، وارتفع الاستدعاء بنسبة 13.6%، وزاد حجم التعليقات بنسبة 61%، فيما انخفضت تكلفة المراجعة بنسبة 8.0%. هذه نتائج تجربة واحدة أجرتها GitHub؛ ولا تمثل تقييمًا لجميع الوكلاء أو ضمانًا بتحقيق الأثر نفسه لدى الفرق الأخرى.
يفيد فصل المقاييس على نحو خاص عندما يختار الفريق إعدادات المراجعة. فقد يترافق العدد الكبير من الملاحظات مع زيادة النتائج المفيدة، لكنه لا يبين وحده كم منها تأكدت صحته. كما يصنف ReviewBench النتائج بحسب الخطورة والفئة، لكي يتمكن الفريق من النظر على حدة، مثلًا، في العيوب الحرجة أو مسائل الأمان.
كيفية تجربة المعيار
وفقًا لوصف GitHub، يتيح الإصدار البحثي الأولي الاطلاع على مجموعة البيانات كاملة، ومقارنة النتائج المنشورة، وتشغيل وكيل خاص بك. ويتاح تشغيل تمهيدي على 25 طلب سحب؛ أما التشغيل الكامل فيغطي 219 طلب سحب على ثلاث جولات. ويقدم المشارك صورة حاوية وإعدادات ومفتاح النموذج الخاص به، فيما يجري التقييم باستخدام محكّم مشترك. وتظل النتائج خاصة إلى حين مراجعة المشاركة والموافقة عليها.
المغزى العملي من هذا التشغيل هو الحصول على نقطة انطلاق قابلة للمقارنة، ثم اختبار النظام وفق قواعد المراجعة الخاصة بالفريق والتغييرات المعتادة في مستودعه. فقد تختلف ظروف الفريق المحددة—كاللغات والبنية والحدود الدنيا للخطورة ومستوى الضوضاء المقبول—عن تركيبة المجموعة العامة.
وتقول GitHub إن التغييرات في التقييمات غير المتصلة بالإنترنت على ReviewBench توافقت، في تجاربها، من حيث الاتجاه مع النتائج في بيئة التشغيل الفعلية. وتتعلق القياسات المنشورة باختبارات الشركة نفسها. لذلك، فإن الاستخدام الأكثر موثوقية للمعيار حاليًا هو مقارنة الوكلاء على عينة مشتركة وتشخيص نقاط قوتهم؛ أما قرار الاعتماد، فينبغي أن يستند أيضًا إلى التحقق ضمن سير العمل الفعلي للفريق المعني.