Qodo تقارن بين نماذج LLM في مراجعة الشيفرة: الأخطاء المكتشفة والضوضاء وكلفة الفحص

تصدر النماذج المتقدمة (frontier) اليوم تقريباً كل شهر، وكل نموذج منها يغيّر التوازن بين الجودة والسعر والسرعة. في 12 أكتوبر 2026 نشرت Qodo، الشركة التي تبني منتجات لمراجعة الشيفرة والحوكمة (governance)، في مدونتها مقالاً بعنوان «Which LLM should review your code?». تقارن فيه النماذج وفق ثلاثة معايير: عدد الأخطاء التي يعثر عليها النموذج، وحجم الضوضاء التي يولّدها، وكلفة الفحص الواحد. لا يتضمن الإعلان المتاح أي أرقام نهائية أو تصنيف، لذلك نستعرض أدناه طريقة طرح السؤال نفسها وما يهم فيها.

لماذا مراجعة الشيفرة تحديداً

تصلح المراجعة للمقارنة بين النماذج لأن المقايضات فيها تظهر فوراً. فالخطأ الذي يفوت المراجعة يصل إلى بيئة الإنتاج وتكون كلفته عالية. أما الملاحظات الزائدة فتستهلك وقت المطورين، وتعوّدهم مع الوقت على تجاهل الروبوت. وتزداد فاتورة الرموز (tokens) مع حجم طلب السحب (pull request) ومع عمق استدلال النموذج. ولا تعطي معايير الدردشة (chat benchmarks) هذه الصورة، فليس فيها كلفة للخطأ ولا فريق حي عليه أن يثق بالنتيجة.

وإضافة إلى ذلك، فنتيجة هذه المهمة قابلة للتحقق. فالخطأ إما موجود في الـ diff وإما غير موجود، والملاحظة إما قبلها المؤلف وإما رفضها.

ثلاثة محاور تستحق المقارنة

تضع Qodo ثلاث قيم في المركز. أما السرعة، التي ورد ذكرها في الإعلان منفصلةً، فتُضاف محوراً رابعاً.

• الشمولية (recall): نسبة العيوب الفعلية التي جرى العثور عليها. والمهم هنا التفصيل حسب النوع: الأخطاء المنطقية، والأمان، والحالات الحدّية، وخرق القواعد المعتمدة في الفريق.
• الضوضاء (precision): كم من الملاحظات مفيد، وكم منها بلا معنى أو يكرر ما تقوله أداة linter أو يتعلق بالأسلوب. قد يخسر النموذج الذي يجد أخطاء أكثر لكنه ينتج ثلاثة أضعاف الحشو أمام نموذج أكثر حذراً.
• كلفة المراجعة: سعر المرور الواحد على PR نموذجي، مع احتساب سياق الإدخال ورموز الاستدلال. وبالنسبة إلى فريق لديه مئات الـ PR أسبوعياً، يتحول فارق السعر بعدة أضعاف لكل فحص سريعاً إلى بند ملحوظ في الميزانية.
• السرعة: الزمن الذي يمضي حتى ظهور التعليقات. فالمراجعة التي تصل بعد 20 دقيقة تندمج في سير العمل بصورة أسوأ من تلك الجاهزة في دقيقتين.

الصعوبة الرئيسية أن هذه المحاور تشدّ في اتجاهات مختلفة. فالنموذج الأقوى يجد عادةً أكثر لكنه أغلى وأبطأ. أما النموذج الرخيص السريع فيوفّر الميزانية لكنه يفوّت الأخطاء الدقيقة بصورة أكبر.

ما الذي لا يتضمنه الإعلان

ينقطع المقتطف في خلاصة RSS عند الجزء التمهيدي. لا نعرف أي النماذج شاركت، ولا على أي مجموعة من طلبات PR والأخطاء أُجري الاختبار، ولا كيف عُرّف «الخطأ المكتشف»، ولا أي إعدادات استدلال استُخدمت. وهذه كلها تؤثر كثيراً في الاستنتاجات. كما أن Qodo تبيع منتجاً للمراجعة، وهي بالتالي معنية بأن تبدو منهجيتها مقنعة. وهذا ليس سبباً لعدم الوثوق بالبيانات، لكنه سبب للتحقق من المنهجية في النسخة الكاملة من المقال بمجرد وصولكم إلى الجداول.

كيف تختار نموذجاً لفريقك

يمنحك تصنيف الآخرين نقطة انطلاق لا إجابة. وعملياً ينجح الترتيب التالي.

1. اجمعوا من 50 إلى 100 من طلبات PR المغلقة لديكم التي عُرفت أخطاؤها مسبقاً: من تقارير post-mortem، وعمليات التراجع (rollbacks)، وcommits الإصلاح العاجل (hotfix). هذه هي مجموعة الاختبار الخاصة بكم.

2. مرّروها عبر 2–3 نماذج بالموجّه (prompt) والسياق نفسيهما. احسبوا الأخطاء المكتشفة، ونسبة الملاحظات المقبولة، والكلفة الإجمالية.

3. فكّروا في مخطط من مستويين: نموذج رخيص يراجع كل طلبات PR، ونموذج قوي يُستدعى للتغييرات الخطرة، مثل المصادقة والمدفوعات وعمليات الترحيل (migrations). 4.

أعيدوا النظر في الاختيار مرة كل ربع سنة، أو عند صدور إصدار لافت. وإذا لم يكن خط المعالجة (pipeline) مرتبطاً بنموذج واحد، فإن التبديل يستغرق ساعات لا أسابيع. 5.

تابعوا نسبة الملاحظات المرفوضة. فإذا ارتفعت، بدأ الفريق يتجاهل الروبوت، وهذا أهم من أي سطر في أي معيار قياس (benchmark).

يستحق تقرير Qodo الكامل القراءة من أجل المنهجية والأرقام المحددة. أما القرار بشأن النموذج الذي سيراجع شيفرتكم، فالأفضل أن يُتخذ بناءً على النتائج على مستودعكم أنتم.