أصبحت مراجعة الأكواد الوكيلة (Agentic code review) جزءًا أساسيًا من طريقة إتمام التطوير. فهي تساعدك على فحص طلبات السحب، واكتشاف المشكلات، وتحديد ما يستحق الانتباه قبل شحن الكود.
لكن جودة مراجعي الذكاء الاصطناعي الحاليين قد يصعب قياسها، وتحتاج إلى معرفة نقاط قوة المراجع قبل أن تعرف إن كان سيساعدك فعلًا. بعض المراجعين يكشفون مشكلات أكثر، وبعضهم ينتج ضجيجًا أقل، وبعضهم أقوى في اكتشاف المشكلات الحرجة بينما يكشف آخرون تحسينات أصغر أيضًا. وقد تحتاج مراجعة الكود لأداء أمور مختلفة ضمن سير عملك.
لهذا من المهم فهم كيفية المقارنة الفعلية بين المراجعين: ما الذي تكتشفه الأنظمة المختلفة، وما الذي تفوّته، وما المفاضلات التي تجريها. ينبغي لمعيار جيد لمراجعة الأكواد أن يعكس تنوع طلبات السحب الحقيقية، وأن يشمل مجموعة واسعة من نتائج المراجعة، وأن يدعم تفصيلًا ذا معنى حسب الخطورة والفئة وتفضيلات الدقة والاستدعاء (precision-recall). وبالنسبة للفرق التي تبني وكلاء مراجعة أكواد، ينبغي للمعيار أيضًا أن يوفر إشارة غير متصلة (offline) تتعقب بشكل موثوق ما إذا كانت التغييرات مرجحة لتحسين التجربة في الإنتاج. كثيرًا ما تجري المعايير الحالية مفاضلات بين جودة التسميات والتغطية ومدى تمثيلها لمراجعة الأكواد في الواقع، مما يترك فجوة أمام منهجية تقييم صارمة وقابلة للتكرار تجمع هذه العناصر معًا.
لقد بنينا ReviewBench، وهو معيار قياسي جديد غير متصل لمراجعة الأكواد، لسد تلك الفجوة، وهو متاح للاستخدام اليوم. يتبع لغة وحجم المستودعات وتوزيع أحجام طلبات السحب، المستمدة من نمذجة أكثر من 100 مليون طلب سحب حقيقي على GitHub. يستخدم مجموعة ذهبية متعددة المصادر ومعيار تقييم متسقًا، وقد تم التحقق منه بشكل مستقل من قبل مهندسين أولين. والأهم من ذلك، بمساعدة ReviewBench أصبح تقييمنا غير المتصل لمراجعة أكواد Copilot (CCR) أكثر فعالية في استباق اتجاه تجارب الإنتاج، مما يمنحنا ثقة أكبر بأن التحسينات المقاسة تعكس مكاسب ذات معنى للمستخدمين.
في هذا المقال، سنستعرض كيفية بناء ReviewBench، وكيف يُنشئ حقائق مرجعية وتقييمًا موثوقًا، وكيفية ضم نظام مراجعة الأكواد الخاص بك وتقديم النتائج.
ما الذي بنيناه
معيار واقعي وشامل لوكلاء مراجعة الأكواد بالذكاء الاصطناعي
103.9Mطلب سحب على GitHub
تحليل التوزيعات حسب اللغة وحجم المستودع وشكل التغيير.
مجموعة معيارية تمثيلية
219 طلب سحب عامًا عبر 19 لغة، متوافقة مع التوزيعات على مستوى GitHub مع الحفاظ على حالات مراجعة جوهرية.
مجموعة ذهبية متعددة المصادر
- مراجعون بشريون
- نماذج لغوية كبيرة حدّية
- تحليل ثابت
نتائج منظمة
كل نتيجة موسومة بالخطورة والفئة، ما يتيح شرائح مخصصة حسب المستخدم.
الخطورة
- حرجة
- متوسطة
- منخفضة
الفئة
- الصحة
- الأمان
- الموثوقية
- قابلية الصيانة
- الاختبار
- ......
مقاييس التقييم
تقيس أربعة مقاييس المشكلات المعروفة والمكتشفة حديثًا معًا.
- الدقة المرتكزة
- الاسترجاع المرتكز
- الدقة المُعزَّزة
- الاسترجاع المُعزَّز
تقييم موضوعي
قِس التحسّن وقارن عبر الوكلاء بموضوعية. ساعد المستخدمين في اختيار المُراجِع الذي يناسب احتياجاتهم بأفضل شكل.
كيف نحافظ على موثوقيته
سلسلة قابلة للتدقيق من المعيار إلى التحقق الخبير وفحوصات الإنتاج
معيار منشور
معيار واحد صريح لجميع النتائج.
مجموعة تطوير مُصنَّفة بشريًا
مهندسون كبار يؤسسون الحقيقة المرجعية.
مُقيِّم مُعايَر
متوافق مع الحكم البشري.
تصنيف موحّد
المعيار نفسه عبر جميع المصادر.
اتفاق منشور
تدقيق خبير لجودة المعيار المرجعي.
قابل للتدقيق من البداية إلى النهاية
اتفاق بنسبة 96.6%
قام مهندسون كبار بتصنيف الإيجابيات الصحيحة الذهبية بشكل مستقل قبل الإصدار.
إشارات غير متصلة تستبق الإنتاج
يتم التحقق من حركة المعيار المرجعي مقابل التجارب عبر الإنترنت.
- التحسينات تميل إلى الظهور عبر الإنترنت
- التراجعات تميل إلى الظهور عبر الإنترنت أيضًا
كيف يعمل ReviewBench
يُبنى معيارنا المرجعي حول خمسة مبادئ:
1. طلبات سحب تمثيلية، وليست مجموعة عرض توضيحي
حللنا 103.9 مليون طلب سحب على GitHub لتوصيف التوزيع الواقعي لأعباء عمل مراجعة الكود. يحتوي ReviewBench على 219 طلب سحب من 187 مستودعًا عامًا مفتوح المصدر مرخصًا تغطي 19 لغة، مع تطابق توزيعي اللغة وحجم المستودع مع GitHub الإجمالي بشكل وثيق. مجموعة بيانات المعيار الكاملة متاحة للجمهور.
نجري تعديلًا واحدًا متعمدًا على هذا التوزيع: بينما تعكس اللغة وحجم المستودع GitHub مباشرة، فإن حجم طلب السحب مرجَّح نحو الوسط والذيل القابلين للمراجعة. يقلل هذا من التمثيل الزائد للتغييرات الصغيرة ذات الملف الواحد مع الحفاظ على طلبات السحب الأكثر جوهرية ومتعددة الملفات حيث تهم جودة المراجعة أكثر من غيرها.
لمحة سريعة عن المدونة:
2. اكتشاف حقائق أساسية أوسع، يتم الحكم عليه بشكل مستقل
لا يمكن لأي مراجع منفرد، سواء كان بشريًا أو نموذجًا، أن يحدد كل ما يستحق العثور عليه في طلب سحب. لبناء مجموعة ذهبية أوسع وأكثر موثوقية للنتائج الأساسية، نتبع عملية من ثلاث مراحل:
- جمع النتائج المرشحة من مصادر متنوعة. نجمع النتائج من مراجعين بشريين حقيقيين، والمشكلات المستنتجة من التزامات المتابعة للمؤلفين، وأدوات التحليل الحتمية، والعديد من نماذج LLM الرائدة عبر عائلات النماذج.
- إزالة التكرار الدلالي للنتائج المتداخلة. ندمج النتائج التي تحدد المشكلة الأساسية نفسها، مما يوسع التغطية دون السماح للاتفاق بين المنتجين بتضخيم المجموعة الذهبية بشكل مصطنع أو جعلها تعتمد على النقاط العمياء لأي مصدر منفرد.
- التحقق من صحة النتائج وفق معايير مشتركة. لا يحدد مصدر النتيجة ما إذا كانت صحيحة: لا تُحسب النتيجة كإيجابية حقيقية إلا إذا كانت صائبة وذات صلة وغير بديهية. نستخدم Claude Sonnet 5 كمقيِّم LLM، ونطبق معيار تقييم متسق عبر جميع الإرساليات. ولأغراض الشفافية وقابلية إعادة الإنتاج، ننشر كمعيار التقييم والمقيِّم المستخدم لتطبيقه.
3. مقاييس تقيس المشكلات المعروفة والمكتشفة حديثًا على حد سواء
تقارب معظم المعايير الدقة والاستدعاء مقابل مجموعة ذهبية ثابتة. أما ReviewBench فيقدم ستة مقاييس في عائلتين:
- الدقة والاستدعاء ودرجة F1 المرتكزة تستخدم فقط ملصقات المجموعة الذهبية الحالية. وهي توفر مقارنة صارمة وعادلة على قدم المساواة: من المشكلات التي نعرفها بالفعل، كم وجد الوكيل منها، وما نسبة نتائجه التي طابقت مشكلة معروفة؟
- الدقة والاستدعاء ودرجة F1 الموسعة تقيّم أيضًا النتائج التي لا تطابق أي شيء في المجموعة الذهبية. يحدد المقيِّم بشكل مستقل ما إذا كانت تلك النتائج غير المطابقة إيجابية حقيقية أم كاذبة، مما يتيح للمراجع الحصول على تقدير لمشكلات صالحة لم يكشف عنها أي منتج في المجموعة الذهبية
يصبح هذا التمييز أكثر أهمية مع ازدياد قدرات وكلاء المراجعة. فالمجموعة الذهبية الثابتة تصبح حتمًا غير مكتملة مع اكتشاف الأنظمة لمشكلات لم يتوقعها منشئوها. وتتيح المقاييس الموسعة لـ ReviewBench الاعتراف بذلك السلوك بدلاً من معاقبته تلقائيًا. ولأن الاستدعاء الموسع يوسع المقام بناءً على ما يكتشفه كل وكيل، نستخدم الاستدعاء المرتكز كالمقارنة الرئيسية عبر الأنظمة والمقاييس الموسعة كأداة تشخيصية إضافية لكل نظام.
4. تقييم قابل للتهيئة وفق تفضيلات المراجعة المختلفة
لا توجد تجربة مراجعة واحدة مثالية للجميع. قد يرغب بعض المطورين في التركيز فقط على المشكلات الحرجة، بينما يقدّر آخرون أيضًا النتائج الأقل خطورة وغير مسببة للتعطيل. ويفضل البعض تغطية أوسع، بينما يعطي آخرون الأولوية للدقة والحد الأدنى من الضوضاء. وقد تكون لدى آخرين احتياجات متخصصة، مثل مراجعة تركز على الأمان أو الخصوصية.
تتيح ReviewBench تقسيم النتائج حسب الخطورة والفئة، بينما تلتقط الدقة والاستدعاء تفضيلات التشغيل المختلفة. ويمكن للمستخدمين أيضًا تعديل β في درجة Fβ لإعطاء وزن أكبر للاستدعاء لتغطية أوسع أو للدقة لتقليل الضوضاء. ومع تغير هذه التفضيلات، يُعاد ترتيب لوحة الصدارة وفقًا لذلك، مما يساعد المستخدمين على تحديد الأنظمة التي تطابق أولويات المراجعة لديهم على أفضل وجه.
5. تدقيق داخلي وتقييم قابل لإعادة الإنتاج
قبل الإصدار، طلبنا من مهندسين كبار لم يشاركوا في بناء بيانات المعيار أن يعيدوا وضع ملصقات مستقلة لكل نتيجة أساسية من الصفر. وكانت أحكامهم حول الإيجابيات الحقيقية/الكاذبة متوافقة مع ReviewBench بنسبة 96.6% من الوقت. نضع إصدارات لبيانات المعيار والمقيِّم والمطابق المستخدمة في كل تقييم، حتى يمكن مقارنة النتائج تحت نفس تهيئة المعيار وإعادة التحقق منها عند تغير المعيار. وننشر أيضًا منهجية التحقق وقياسات التوافق والتهديدات المعروفة للصلاحية، حتى يتمكن القراء من رؤية كيفية تقييم جودة المعيار وأين يبقى عدم اليقين.
استكشف ReviewBench
النسخة المعاينة البحثية من ReviewBench متاحة الآن عبر موقع ReviewBench، حيث يمكنك استكشاف المعيار الكامل ومقارنة وكلاء مراجعة الكود وإحضار وكيلك الخاص لتقييمه وتطويره.
مع ReviewBench، يمكنك:
- استكشاف بيانات المعيار الكاملة. بيانات ReviewBench الكاملة متاحة للعموم، بما في ذلك طلبات السحب والنتائج والملصقات وتوضيحات الخطورة والفئة. وهذا يتيح لك فحص ما تُقيَّم عليه الأنظمة بدقة وإعادة إنتاج نتائج المعيار.
- مقارنة الأنظمة على لوحة الصدارة. تُنشر نتائج وكلاء مراجعة الكود المقيَّمين باستخدام بيانات المعيار الكاملة على لوحة صدارة مشتركة، مع إطلالات عبر الأداء العام والخطورة والفئة وتفضيلات الدقة–الاستدعاء المختلفة.
- أحضر وكيلك الخاص واصعد تدريجيًا. بيانات المعيار الكاملة ومنهجية التقييم وprompt المقيِّم LLM وتهيئة نموذج المقيِّم وخدمة التشغيل الذاتي متاحة للعموم، حتى تتمكن من تقييم وكيل مراجعة الكود الخاص بك وفحص نقاط قوته وفجواته والتكرار مقابل نفس تهيئة المعيار.
كيف استخدمنا ReviewBench
لقد استخدمنا ReviewBench لتقييم Copilot code review (CCR) في التكرارات المتتالية، مما يمنحنا طريقة متسقة لقياس التقدم، ورصد حالات التراجع، وترتيب أولويات التغييرات الواعدة. ومع مرور الوقت، ساعدنا هذا في تحسين المنتج. ومن أهم الفوائد القيمة لـ ReviewBench أنه يوفر إشارة مبكرة دون اتصال بالإنترنت حول كيفية أداء أي تغيير في المنتج في بيئة الإنتاج على الأرجح. وفي التجارب التي قُيّمت باستخدام ReviewBench قبل اختبارات A/B، أشارت التغييرات دون الاتصال بالإنترنت باستمرار إلى الاتجاه نفسه الذي نراه لاحقًا في بيئة الإنتاج.
يوفر تجربة حديثة على المستوى الخفيف (lite-tier) مثالاً ملموساً على هذا النمط الأوسع. قدّمنا مراجعة مجمّعة متعددة النماذج تجمع عدة تشغيلات مستقلة للنموذج في مراجعة واحدة بدلاً من الاعتماد على تشغيل واحد. توقّعت ReviewBench دقة (precision) واستدعاء (recall) وحجم تعليقات أعلى، إلى جانب تكلفة أقل لكل مراجعة.
لمقارنة النتائج غير المتصلة بالإنترنت بنتائج الإنتاج، نستخدم إشارات مقابلة على الإنترنت. معدّل المعالجة (Addressed rate)، وهو المقابل على الإنترنت للدقة (precision)، هو النسبة المئوية لتعليقات CCR التي يحدد نموذج لغوي كبير (LLM) أنها دفعت مطوراً إلى إجراء تغيير مقابل في الشيفرة، بناءً على الفرق (diff) والمحادثة والتفاعلات وحالة الحل وشيفرة ما بعد المراجعة. أما الاستدعاء (recall)، فنقيس من خلاله مقدار المراجعة البشرية الإضافية التي ما زالت مطلوبة.
تحرك اختبار A/B عبر الإنترنت في نفس الاتجاه الذي توقّعته ReviewBench: ارتفع معدّل المعالجة (الدقة) بنسبة 8.0%، وارتفع الاستدعاء بنسبة 13.6%، وارتفع حجم التعليقات بنسبة 61%، بينما انخفضت التكلفة لكل مراجعة بنسبة 8.0%، وذلك كله مقارنة بمجموعة التحكم في الإنتاج.
غير أن حجم التعليقات وحده لا يعكس جودة التعليقات. فالنتائج الحرجة تعني شيئاً مختلفاً تماماً عن الملاحظات البسيطة منخفضة الخطورة. وقد التقطت التقييم على مستوى الخطورة في ReviewBench ذلك أيضاً: فقد توقّع زيادة بنسبة 227% في التعليقات الحرجة، مقارنة بنسبة 262% على الإنترنت، إلى جانب التحول الأوسع نفسه نحو تعليقات أكثر اعتدالاً وملاحظات بسيطة أقل.
يمنحنا هذا إشارة سريعة وقابلة للتكرار قبل إجراء تجارب الإنتاج. تظل التجارب عبر الإنترنت هي المقياس النهائي لتأثير المستخدم، لكن ReviewBench يمنحنا ثقة أكبر في التغييرات التي تستحق التجربة هناك.
كيفية تقديم تشغيلك الخاص
- سجّل الدخول باستخدام GitHub على ReviewBench الموقع الإلكتروني.
- سجّل وكيلك. قدّم صورة حاوية (container image) وتكوينك الخاص ومفتاح النموذج الخاص بك. نحن نوفر الحكم (judge).
- جرّبه على مجموعة الاختبار. شغّله على مجموعة اختبار من 25 طلب سحب (PR) مع تفاصيل لكل PR، وكرر ذلك أثناء ضبط التكوين.
- قم بتشغيل نهائي. عندما تكون جاهزاً، شغّل المجموعة الكاملة المكونة من 219 طلب سحب (ثلاث جولات)، مع التقييم من قبل الحكم نفسه المستخدم مع كل المشاركات الأخرى.
- انشر إلى لوحة الصدارة. تبقى نتائجك خاصة حتى يراجع أحد المشرفين المشاركة ويوافق عليها. تُنشر النتائج إلى لوحة الصدارة فقط إذا تجاوزت النتيجة الحالية للوكيل على لوحة الصدارة، أو إذا كانت هذه أول مشاركة للوكيل على لوحة الصدارة.
ندعوكم لاستكشاف ReviewBenchوتقييم أنظمتكم الخاصة وتحدي افتراضاتنا ومساعدتنا في تحسين المعيار. نتطلع بحماس إلى التعاون مع الباحثين والممارسين لجعل تقييم مراجعة الشيفرة أكثر انفتاحاً وموثوقية وفائدة—وفي نهاية المطاف المساعدة في دفع مراجعة الشيفرة بالذكاء الاصطناعي إلى الأمام.
شكر وتقدير
كانت ReviewBench جهد فريق مشترك بين GitHub وMicrosoft. نتقدم بالشكر للباحثين والمهندسين الذين بنوها: أولئك الذين صمموا المنهجية، ورتّبوا طلبات السحب، وبنوا المجموعة الذهبية وأنبوب التقييم، وجعلوا المعيار شيئاً يمكن لأي شخص تشغيله.
ظهرت المقالة ReviewBench: معيار مفتوح لمراجعة الشيفرة بالذكاء الاصطناعي أولاً على مدونة GitHub.