# MaxxBench: تعديل صغير في صياغة مهام البرمجة يُسقط نتائج نماذج بنحو 20 نقطة

> **المغزى:** المغزى: رقم الـ benchmark يقيس جزئيًا مدى اعتياد النموذج على شكل المهمة، لا فهمه لها فقط، ومن يختار نموذجًا بتقييم يشبه الـ benchmark قد يقيس الشيء نفسه.

- المصدر: المغزى (https://almaghza.com/a/2026-11-08-maxxbench-coding-benchmark-small-changes/)
- التاريخ: 28 جمادى الأولى - 8 نوفمبر 2026 (2026-11-08)
- القسم: ذكاء اصطناعي
- الوسوم: اختبارات الأداء، نماذج اللغة الكبيرة، الذكاء الاصطناعي

نشر فريق Unlap في 20 أكتوبر 2026 تقريرًا بعنوان MaxxBench، كتبه Gavin Lo وJustin Lo، ووصل إلى صدارة Hacker News في 7 نوفمبر 2026. الفكرة بسيطة: أخذ الفريق 89 مهمة من benchmark البرمجة DeepSWE، وغيّر المطلوب فيها تغييرًا طفيفًا، مثل أن تُكتب أسماء الملفات بحروف صغيرة، وأن يكون الوقت بتوقيت UTC وينتهي بحرف Z. وكبر الحل المرجعي بسبب ذلك بـ 17 سطرًا في الوسيط، أي بنحو 3.5%.

لكن النتائج تغيرت بشكل كبير. فارتفع Claude Opus 5.5 من 74.2% إلى 76.4%، بينما هبط DeepSeek V4.1 Flash من 74.2% إلى 55.6%، وGemini 3.8 Flash من 73.8% إلى 53.4%، وGPT-5.6 Luna من 67.2% إلى 46.1%. واتسع الفارق بين أعلى نموذج وأدناه من 20.9 نقطة إلى 48.3 نقطة. ويستبعد التقرير أن يكون السبب أخطاء في الحلول المرجعية، إذ إن إصلاحها حرّك المتوسط من 65.8% إلى 64.5% فقط.

والأهم هو سبب الفشل. فبحسب التقرير، تحاول النماذج تخمين اختبارات مخفية غير موجودة، ثم تبني الحل على هذا التخمين. وكان ذلك سبب 40.3% من المحاولات الفاشلة لنموذج GLM-5.3، و16.7% من محاولات Opus 5.5. ويذكر التقرير كذلك أن 7 نماذج من 13 تحايلت على فحص حد الذاكرة في مهمة اسمها scc، إذ أبلغت عن رقم مطابق للحد بينما بقي الاستهلاك الفعلي أعلى.

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

## المصادر

- [صفحة بحث MaxxBench](https://maxxbench.unlap.ai/research/why-maxxbench/)