أتمتة مراجعة الكود: كيف تنتزع الشبكات العصبية الأعمال الروتينية من المطورين

لماذا الأتمتة ضرورية؟

في شركة Avito، يُنشأ ألف طلب دمج (pull request) أسبوعياً — ويصل العدد في ساعات الذروة إلى 300 طلب في الوقت نفسه. يفرض ذلك ضغطاً هائلاً على المطورين الذين ينشغلون عن عملهم الأساسي لإجراء مراجعة الكود. والنتيجة: قد تبقى طلبات الدمج أياماً في طابور الانتظار، ويزداد زمن وصول الميزات الجديدة إلى السوق (time-to-market)، ويتعرض الفريق للإرهاق مما قد يؤدي إلى تجاهل أخطاء حرجة.

وضع فريق مهندسي النماذج اللغوية الكبيرة 3 أهداف لهذه الأتمتة:

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

بنية النظام

يتكون النظام من 3 مكونات مرتبطة في مسار عمل واضح:

1. Stash — الواجهة التي يترك فيها المطور تعليق ai_review في طلب الدمج 2. خدمة Go — تستقبل الحدث من Data Bus، تحلّل الأمر، وتجلب الاختلافات (diff) وبيانات المستودع الوصفية، وتضع المراجعة في قاعدة البيانات بحالة STATE_REQUESTED، ثم ترسل طلب RPC إلى خدمة التعلم الآلي 3. خدمة Python ML Pipeline — تعالج السياق وتُعيد التعليقات المولّدة

وتستجيب خدمة التعلم الآلي فوراً برمز 200 OK لتجنب حجب خدمة Go — فقد يستغرق التوليد وقتاً طويلاً.

خط أنابيب التعلم الآلي: ثلاث مراحل

RuleChecker (التوليد). يحدد النموذج جميع المشكلات المحتملة، معتمداً على تصنيف للأخطاء مستخرَج من طلبات دمج حقيقية للفريق. وهو مُحسَّن لتحقيق استرجاع (Recall) عالٍ، حتى لو تضمّن ذلك نتائج موجبة زائفة (false positives). والناتج هو ملف JSON يحتوي على أرقام الأسطر والتوصيات.

ReviewFilter (التحقق من الصحة). يرفع هذا التمرير الثاني الدقة (Precision). ويعمل النموذج وفق نمط Conclusion First — إذ يستقبل نفس السياق مع تعليق محدد، ويجيب: هل هذه الملاحظة مهمة أم لا. ويستبعد هذا النموذج 90% من الهلوسات والنتائج الموجبة الزائفة.

CommentAggregator (إزالة التكرار). يبني النظام تمثيلات متجهية (embeddings) للتعليقات باستخدام BAAI/bge-m3، ثم يحسب التشابه الجيب-تمام (cosine similarity). فإذا تجاوز التشابه 0.85، تُجمَّع التعليقات معاً. ويبقى من كل مجموعة تعليق واحد فقط، وهو الأكثر ثراءً بالمحتوى. والناتج النهائي قائمة من الملاحظات الفريدة.

اختيار النموذج والأداء

وفقاً لمقياس MERA-RuCodeReviewer (689 مثالاً بلغات Java و Python و Scala و Go)، يتصدر نموذج Gemini 2.5 Flash القائمة، لكن الفريق اختار Qwen3-Coder-30B-Instruct-FP8 (المرتبة الثانية) — لأنه مفتوح المصدر ويسمح باستضافته على البنية التحتية الخاصة بالشركة. وهذا أمر حاسم: فالكود لا يغادر إلى واجهات برمجة خارجية (API)، إضافة إلى أن الاستضافة الذاتية أقل تكلفة عند الأحجام الكبيرة (تتطلب طلبات الدمج ما بين 2000 إلى 10000 رمز/توكن).

الأداء: • طلبات الدمج الصغيرة (حتى 3 ملفات): 10 إلى 20 ثانية • طلبات الدمج الكبيرة (10 ملفات أو أكثر): نحو 60 ثانية • الحد الأقصى 650 مراجعة متوازية

تُجمع مقاييس الجودة من خلال إعجابات المطورين (likes): • الدقة (Precision): 85% من التعليقات مصنفة على أنها جيدة • نسبة التقادم (Outdated rate): 32% (تعليقات أغلقها المطور بعد إجراء تصحيح). وترتفع هذه النسبة إلى 60% في قسمي Infra و DevOps.

أهم الاستنتاجات

الفكرة الأساسية: فصل الاسترجاع (Recall) عن الدقة (Precision) يعمل بشكل أفضل من استعلام واحد موحّد. فحتى مع سياق طويل، يفقد النموذج تركيزه، ولذلك يصبح النظام متعدد المراحل ضرورياً. والتحقق الذي يستبعد الهلوسات أمر بالغ الأهمية — فهو الأساس الذي تُبنى عليه ثقة المستخدمين.

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