Anthropic تكشف: إعدادات البنية التحتية تغيّر نتائج Terminal-Bench بمقدار 6 نقاط مئوية

قد تُزيح البنية التحتية نتيجة اختبار البرمجة الخاص بالوكلاء بعدة نقاط مئوية، وأحياناً بأكثر من الفارق الذي يفصل بين المتصدرين في الجدول. هذا ما خلص إليه مهندسو Anthropic بعد تشغيل Terminal-Bench 2.0 في ست configurations مختلفة للموارد. بلغ الفارق بين أشد الإعدادات صرامة وأكثرها سخاءً 6 نقاط مئوية عند p < 0,01، في حين بقيت عناصر التجربة الأخرى ثابتة: النموذج والـ harness ومجموعة المهام.

كيف اكتُشفت المشكلة

تشغّل Anthropic اختبار Terminal-Bench 2.0 على كتلة Google Kubernetes Engine. وأثناء المعايرة لاحظ الفريق أن الدرجات لا تتطابق مع لوحة الصدارة الرسمية، وأن نسبة الأخطاء الناجمة عن البنية التحتية مرتفعة على نحو غير متوقع: فقد فشلت ما يصل إلى 6% من المهام بسبب أعطال في الـ pods لا علاقة لها بقدرات النموذج.

يعود السبب إلى طريقة تطبيق الحدود. فقد عاملت النسخة المنفذة على Kubernetes الموارد الموصى بها للمهمة على أنها حدّ أدنى مضمون وسقف صارم في الوقت نفسه. كانت الحاوية تحصل على مقدار الذاكرة المحدد بالضبط، وتُنهى عند أدنى تجاوز. وكان ارتفاع قصير في الاستهلاك يؤدي إلى OOM-kill، مع أن المهمة كان يمكن أن تكتمل بنجاح. أما مزوّد البيئات المعزولة (sandbox) الذي تستخدمه لوحة صدارة Terminal-Bench فهو أكثر تساهلاً: فهو يسمح بتجاوز مؤقت ولا يُنهي الحاوية.

ماذا أظهرت التجارب

شغّل المؤلفون الاختبار بدءاً من الالتزام الصارم بالمواصفات (1x) وصولاً إلى غياب الحدود تماماً. أبرز الأرقام:

• تنخفض نسبة أخطاء البنية التحتية بشكل رتيب: من 5,8% عند 1x إلى 0,5% دون قيود؛
• الانتقال من 1x إلى 3x يخفض الأخطاء من 5,8% إلى 2,1% (p < 0,001)؛
• في النطاق 1x–3x تتذبذب نسبة النجاح ضمن حدود الضجيج (p = 0,40)؛
• فوق 3x ترتفع نسبة النجاح أسرع مما تنخفض الأخطاء: انخفاض إضافي في الأخطاء بمقدار 1,6 نقطة مئوية يقابله ارتفاع في النجاح يقارب 4 نقاط مئوية؛
• الزيادة الإجمالية دون حدود مقارنة بـ 1x هي +6 نقاط مئوية (p < 0,01)؛
• في SWE-bench (227 مهمة، 10 عينات لكل مهمة، وذاكرة RAM حتى 5x) بلغت الزيادة 1,54 نقطة مئوية فقط.

حتى عتبة 3x تعالج الموارد الإضافية عدم الاستقرار: يصبح الاختبار أكثر موثوقية لكنه لا يصبح أسهل. وما فوق ذلك يبدأ الوكيل بحل ما كان عاجزاً عنه سابقاً: يحمّل تبعيات ثقيلة، ويشغّل عمليات فرعية مكلفة، ويجري اختبارات كثيفة الاستهلاك للموارد. وكانت أكبر الزيادات في المهمتين rstan-to-pystan وcompile-compcert.

ما الذي يقيسه الاختبار فعلاً

الحدود الضيقة تكافئ الاستراتيجيات المقتصدة، والحدود السخية تكافئ أساليب القوة الغاشمة. مثال على ذلك مهمة bn-fit-modify الخاصة بملاءمة شبكة بايزية. تثبّت بعض النماذج مكتبات pandas وnetworkx وscikit-learn فوراً. وهذا ينجح مع الحدود السخية، أما مع الحدود الصارمة فيتعطل الـ pod بسبب نقص الذاكرة أثناء التثبيت نفسه. وهناك أيضاً طريق أخف: تنفيذ الرياضيات بالمكتبة القياسية، وبعض النماذج تختاره فعلاً. إعدادات الموارد هي التي تحدد أي العادتين ستكون الرابحة.

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

استنتاجات عملية

يوصي المؤلفون بتحديد معاملين لكل مهمة، هما الحجم المضمون وعتبة إنهاء الحاوية، بدلاً من قيمة واحدة. ويجب معايرة الفجوة بينهما بحيث تقع الفروق بين درجات الحد الأدنى والحد الأعلى ضمن حدود الضجيج. وفي Terminal-Bench 2.0 خفّض السقف 3x أخطاء البنية التحتية بنحو الثلثين، ولم يضخّم النتيجة إلا قليلاً. ويجب نشر هذا المعامل مع النتائج.

أما لمن يقرأ لوحات الصدارة، فالخلاصة مباشرة: أي فارق أقل من 3 نقاط مئوية دون إعدادات موثّقة ينبغي التعامل معه بتشكك. فالتباين في النطاق المعتدل للموارد أقل بقليل من نقطتين مئويتين، ويتداخل مع فترات الثقة ذات الحدين المعتادة البالغة 1–2 نقطة مئوية، بينما يصل عند أطراف النطاق إلى 6. وعلى المختبرات أن تعامل الموارد كمتغير تجريبي كامل، مثل صيغة الـ prompt ودرجة الحرارة (temperature). وعلى القائمين على صيانة الاختبارات أن ينشروا المواصفات الموصى بها ومنهجية تطبيقها معاً. وإلا فقد تعني الصدارة بنقطتين أو ثلاث مجرد آلة افتراضية أقوى.