معايير قياس البرمجة بالذكاء الاصطناعي معطّلة: ماذا نقيس؟

كل مختبر ذكاء اصطناعي يطلق نموذج برمجة يتصدّر إعلانه بنتيجة معيار قياس. وكل فريق هندسي يختار نموذجًا يقرأ تلك النتائج. وطوال معظم عام 2026، كانت النتيجة التي يستشهد بها الجميع صادرة عن SWE-Bench Pro.

وصار لدينا اليوم دليل متين على أنّ ذلك الرقم كان يقيس شيئًا آخر غير ما ظنناه.

في أواخر مايو 2026، نشرت Datacurve تدقيقًا مرافقًا لمعيارها الجديد DeepSWE. وكانت النتيجة صريحة: في SWE-Bench Pro، يُقيَّم نحو ثلث المحاولات تقييمًا خاطئًا. ومنذ ذلك الحين نقلت Artificial Analysis تقييماتها البرمجية بعيدًا عن SWE-Bench Pro تمامًا. إذا كان اختيارك للنموذج أو قرار الشراء أو رهانك المعماري يستند إلى تلك اللوحة، فمن الجدير فهم ما حدث بالضبط.

التدقيق: نمطا فشل، وكلاهما سيّئ

أخذت Datacurve عيّنة من 30 مهمة من كل من DeepSWE وSWE-Bench Pro، ثم أجرت ثلاث جولات عبر عشرة إعدادات لنماذج متقدمة — 735 جولة على DeepSWE مقابل 789 جولة على SWE-Bench Pro. بعد ذلك حكم محلّل مستقل يعتمد على نموذج لغوي على ما إذا كان كل تصحيح ينفّذ فعليًا السلوك المطلوب، بدلًا من الوثوق بحكم المعيار نفسه.

الفجوة ليست طفيفة:

اقرأ عمودَي الخطأ بعناية، لأنهما يفشلان في اتجاهين متعاكسين.

الإيجابيات الكاذبة تعني أن المعيار منح درجة نجاح لتصحيح لم ينفّذ السلوك المطلوب. أي أن واحدًا من كل اثني عشر "نجاحًا" لم يكن نجاحًا.

السلبيات الكاذبة هي الرقم الأكبر والأخطر. فقد صُنّف ما يقارب ربع التصحيحات الصحيحة على أنه فشل. هذا ليس ضجيجًا عشوائيًا يمكن تلاشيه بالمتوسط — إنه يضغط لوحة النتائج بشكل منهجي. كل نموذج يُجرّ نحو المنتصف، والنماذج الأفضل فعليًا لا تستطيع إظهار تفوّقها. وهذا بالتحديد سبب إنتاج SWE-Bench Pro للسردية المريحة القائلة بأن جميع النماذج المتقدمة تتقارب. إنها لا تتقارب. المسطرة هي التي كانت تضغطها.

على DeepSWE، تباعدت الإعدادات العشرة نفسها عبر مدى يبلغ 70 نقطة. أما على SWE-Bench Pro فتجمّعت داخل 30 نقطة. النماذج كانت دائمًا بهذا التباعد. أداة القياس هي التي أخفته.

الوكلاء كانوا يقرأون الإجابات

لقصة الإيجابيات الكاذبة آلية محدّدة ومُقلِقة. يستمدّ SWE-Bench Pro مهامه من التزامات (commits) حقيقية في المستودعات، وقد احتفظت الحاويات المسلّمة إلى الوكيل بمجلد .git الخاص بالمستودع.

والوكلاء وجدوه.

من بين حالات النجاح غير السليمة التي رصدتها Datacurve على SWE-Bench Pro، شملت 87% منها استرجاع الوكيل للحل من سجل git. وفي 33 من أصل 38 محاولة من هذا النوع، شغّل الوكيل صراحةً الأمر git log أو git show. وقد لوحظ أن Claude Opus 4.7 يقرأ سجل git في أكثر من 12% من حاويات SWE-Bench Pro.

هذا ليس سوء سلوك من النموذج. فالبحث في السجل بحثًا عن سياق هو تمامًا ما يفعله مهندس كفؤ، وتمامًا ما نريد من الوكيل فعله في مستودع حقيقي. إنه فشل في بناء المعيار. كانت المهمة "نفّذ هذه الميزة"؛ وكانت البيئة تحتوي بهدوء على التزام ينفّذ الميزة. الوكيل القادر بما يكفي يجد أقصر طريق، وأقصر طريق كان git show.

والدرس يتجاوز هذا المعيار الواحد: كلما كان وكيلك أكثر قدرة، زاد استغلاله العدواني لأي شيء تسرّبه بيئة التقييم لديك. أي منظومة تقييم تبنيها داخليًا معرّضة للأمر نفسه. البيئات المُحكَمة ليست رفاهية.

ما الذي يفعله DeepSWE بشكل مختلف

بُني DeepSWE لسدّ الثغرتين معًا. يضم 113 مهمة عبر 91 مستودعًا في خمس لغات — TypeScript وGo وPython وJavaScript وRust — مع أربعة خيارات تصميمية مهمة:

1. مهام خالية من التلوّث. تُكتب المهام من الصفر بدلًا من استخراجها عكسيًا من التزامات قائمة. لا يوجد التزام أصلي يمكن العثور عليه، لأن الحل لم يوجد قط في سجل المستودع.
2. مُحقِّقات سلوكية مكتوبة يدويًا. بدلًا من وراثة مجموعة اختبارات المستودع (التي قد تنجح لأسباب خاطئة أو تفشل بسبب تقلبات غير ذات صلة)، تأتي كل مهمة بمحقّقات مصممة خصيصًا للتحقق من السلوك المطلوب. وهذا ما يخفض معدل السلبيات الكاذبة من 24.0% إلى 1.1%.
3. نطاق طويل المدى وحقيقي. تضيف الحلول المرجعية 668 سطرًا في المتوسط عبر 7 ملفات. هذا تغيير بحجم ميزة كاملة، لا تصحيح من سطر واحد.
4. تنوّع المستودعات. 91 مستودعًا مقابل 113 مهمة يعني حدًّا أدنى من التداخل. والمستودعات نشطة الصيانة، ذات تراخيص متساهلة، وتحمل 500 نجمة على GitHub على الأقل.

والجدير بالذكر أن مطالبات DeepSWE أقصر — 2,158 حرفًا في المتوسط مقابل 4,614 في SWE-Bench Pro. توجيه أقل، واستدلال مطلوب أكثر، وتصحيحات أكبر متوقعة. والتصنيفات المنشورة متباعدة تبعًا لذلك: GPT-5.5 بنسبة 70% ± 3%، وGPT-5.4 بنسبة 56% ± 2%، وClaude Opus 4.7 بنسبة 54% ± 5%، وClaude Sonnet 4.6 بنسبة 32% ± 2%.

هذه أرقام يمكنك فعلًا اتخاذ قرار بناءً عليها.

النصف الآخر من المشكلة: منظومتك هي المتغيّر

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

منهجيتهم تستحق التقدير بذاتها. تُشتقّ المهام من طلبات دمج حقيقية، مُرشَّحة بحسب الحداثة والتأليف البشري وجودة مجموعات الاختبار والنطاق المكتفي ذاتيًا، عبر Python وGo وTypeScript وScala وRust وJava. استخرج المهندسون النية يدويًا من كل طلب دمج، وكتبوا مطالبات خالية من تلميحات الحل، وعزلوا الاختبارات ذات الصلة. والأهم — ومع استيعاب واضح لدرس SWE-Bench Pro — أنهم أحكموا إغلاق سجل git حتى لا يتمكن الوكلاء من قراءة الإجابة.

ثلاث نتائج تبرز.

النماذج المفتوحة بلغت الطبقة العليا. حقّق GLM 5.2 مستوى Opus 4.8 في الجودة بتكلفة 1.28 دولارًا للمهمة مقابل 1.94 دولارًا لـ Opus. وخلاصة Databricks أن النماذج المفتوحة صارت خيارًا يوميًا صالحًا للعمل البرمجي الاعتيادي، لا مجرد بديل اقتصادي. إذا كنت تعامل GLM-5.2 كخيار موفّر، فالبيانات تقول إنه خيار متقدّم.

سعر الرمز لا يتنبأ بسعر المهمة. Sonnet 5 أرخص بنحو 1.7 مرة لكل رمز من Opus 4.8. ومع ذلك كلّف أكثر لكل مهمة: 2.09 دولارًا مقابل 1.94 دولارًا، مع نتيجة أدنى بست نقاط. النموذج الأقل كفاءة في الاستدلال يحرق رموزًا أكثر للوصول إلى المكان نفسه، فيتبخّر الخصم على مستوى الرمز. أي نموذج تكلفة مبني على أسعار الرموز المعلنة يقيس الوحدة الخاطئة. التكلفة لكل مهمة مكتملة هي الرقم الوحيد الذي يدفع فاتورتك.

المنظومة ضاعفت التكلفة مرتين بجودة مطابقة. تشغيل النموذج نفسه عبر منظومات مختلفة أنتج فروق تكلفة تتجاوز الضِّعف عند مستوى الجودة نفسه. أرسلت منظومة Pi الداخلية لدى Databricks سياقًا أقل بثلاث مرات لكل دورة، وأنهت المهام بجولات أقل من Claude Code أو Codex. النموذج نفسه. جودة المخرجات نفسها. نصف الإنفاق.

هذه النقطة الأخيرة هي الأكثر استهانة بها لدى الفرق. أنت لا تختار نموذجًا فحسب — بل تختار نموذجًا ومنظومة، والمنظومة تؤدي دورًا لا يقل عن أوزان النموذج. وهذه هي الحجة العملية لمعاملة هندسة المنظومات كتخصص من الدرجة الأولى لا كسباكة جانبية.

ماذا تفعل يوم الاثنين

الخلاصة ليست "لا تثق بأي معيار". بل إن اللوحات العامة تجيب عن سؤال يخص مستودع شخص آخر، ويقيّمه مُحقِّق شخص آخر. إليك كيف تحصل على رقم يعني شيئًا لقاعدة شفرتك.

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

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

اكتب مُحقِّقات سلوكية، لا اختبارات موروثة. تحقّق من وجود السلوك المطلوب. فاختبارات المستودع كُتبت لغرض مختلف وستخطئ التقييم في الاتجاهين، تمامًا كما فعل SWE-Bench Pro.

قِس التكلفة لكل مهمة مكتملة، لا لكل رمز أبدًا. تتبّع الرموز المستهلكة والزمن الفعلي وعدد المحاولات لكل مهمة. تتفاوت كفاءة الاستدلال بين النماذج بما يكفي لقلب الترتيب الذي يوحي به التسعير بالرمز.

قيّم المنظومة كمحور مستقل. ثبّت النموذج وغيّر المنظومة. ثم ثبّت المنظومة وغيّر النموذج. إن اختبرت الأزواج المحزومة فقط، فلن تعرف أيّ نصف مسؤول عن النتيجة.

أعد التشغيل مع كل إصدار نموذج. الحدود المتقدمة تتحرك شهريًا. المعيار الذي يُشغَّل مرة واحدة لقطة، لا أداة قياس.

النقطة الأوسع

قصة SWE-Bench Pro تذكير جيّد بأن بنية التقييم بنية تحتية حقيقية، وأنها تتآكل. فمعيار يسرّب الحلول بهدوء عبر .git ويخطئ في تقييم ربع التصحيحات الصحيحة سيظل ينتج لوحة نتائج نظيفة المظهر، تُنشر في البيانات الصحفية، وتُستشهد بها في قرارات الشراء، وتُستخدم لتبرير رهانات معمارية. لا شيء في المخرجات يشير إلى أن المسطرة معوجّة.

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

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

هل تحتاج مساعدة في بناء منظومة تقييم لوكلاء البرمجة بالذكاء الاصطناعي داخل قاعدة شفرتك؟ تحدّث إلى فريق نقطة — نصمّم ونطلق بنية الوكلاء التحتية لمؤسسات هندسية عبر منطقة الشرق الأوسط وشمال إفريقيا.