ملخص تقني: InfraBench

بيان المشكلة

أصبحت إدارة البنية التحتية للحوسبة الحديثة تزداد صعوبة بسبب التوسع والتعقيد المتزايدين، حيث تمتد عبر بيئات غير متجانسة من المجموعات المحلية (on-premises) إلى التفاعلات السحابية. وبينما تقدم التطورات الأخيرة في الوكلاء القائمين على الذكاء الاصطناعي (AI agents) حلاً محتملاً لأتمتة هذه المهام، إلا أن المعايير المرجعية الحالية تفشل في استيعاب الطيف الكامل لإدارة البنية التحتية. فتقييمات اليوم غالباً ما تكون محدودة بسيناريوهات بسيطة (مثل الحاويات أحادية العقدة)، وتفتقر إلى تغطية دورة الحياة التشغيلية الكاملة (من النشر حتى إيقاف التشغيل)، وكثيراً ما تغفل تقييمات المخاطر. وبناءً على ذلك، لا يزال من غير الواضح ما إذا كان بإمكان وكلاء الذكاء الاصطناعي التعامل بموثوقية مع تعقيدات البنية التحتية الواقعية، والتباين، واحتمالية حدوث حالات فشل متتالية (نطاق التأثير/الضرر - blast radius).

المنهجية

يقدم المؤلفون InfraBench، وهو مجموعة معايير مرجعية مصممة لتقييم وكلاء الذكاء الاصطناعي عبر مهام البنية التحتية الواقعية. تعتمد المنهجية على أربعة أهداف تصميمية جوهرية:

1. كامل الحزمة (Full-Stack): تغطية أربع طبقات للبنية التحتية: الطبقة الأولى (L1) الأجهزة (BMC/IPMI)، الطبقة الثانية (L2) الأنظمة المحلية (نظام التشغيل، الحاويات)، الطبقة الثالثة (L3) الأنظمة الموزعة (Ceph، Slurm)، والطبقة الرابعة (L4) تطبيقات المستخدم.
2. كامل دورة الحياة (Full-Lifecycle): تقييم المهام عبر مراحل النشر، والتشغيل، والصيانة، وإيقاف التشغيل.
3. الوعي بالمخاطر (Risk-Aware): تقييم المخاطر التشغيلية والآثار الجانبية كإشارات أساسية، وليس مجرد إتمام المهمة.
4. واقعي وقابل للتوسع (Realistic & Extensible): استخدام منصة اختبار (CloudLab Wisconsin) تضم مجموعات من الأجهزة الفعلية (bare-metal) والأنظمة الافتراضية (VM clusters) لضمان الدقة العالية.

بنية النظام

يعمل InfraBench عبر أربعة مكونات:

• توصيف المهمة (Task Specification): يحدد التعليمات المرئية للوكيل وسياقات التقييم المخفية (الأعطال، نماذج التحقق، سياسات دورة الحياة).
• المنفذ (Executor): يقوم بإنشاء المهام على خلفيات موثوقة (Docker، مجموعات VM، الأجهزة الفعلية) ويدير النافذة التشغيلية.
• المقيم (Evaluator): يقيم الوكلاء من خلال فاحص دورة الحياة الكاملة (بوابات الإصلاح الفوري، التشغيل الحي، إعادة التشغيل/الاستمرارية، وإيقاف التشغيل) ومراقب المخاطر. يستخدم مراقب المخاطر نموذج لغة كبير (LLM-judge) لتصنيف مسارات الإجراءات مقابل تصنيف للمخاطر (مثل العمليات التدميرية لنظام الملفات، أو تجاوز الصلاحيات).
• المقاييس (Metrics): يستخدم مراجعاً خاصاً بكل مهمة يعيد مكافأة $R \in [0, 1]$. تشمل المقاييس الرئيسية:
  • متوسط الدرجة الفعالة (Mean Effective Score): متوسط الدرجات عبر المهام.
    تعداد المحاولات الناجحة (Attempt Pass@$\tau$): نسبة المحاولات الفردية (من أصل ثلاث لكل مهمة) التي تستوفي عتبة معينة (مثل الحل المثالي أو الحل الجزئي الجيد).
  • أفضل نتيجة من N (Best-of-N@$\tau$): نسبة المهام التي نجحت فيها أفضل محاولة من أصل ثلاث.

الإعداد التجريبي

قيمت الدراسة 15 تكويناً من (الوكيل-النموذج) عبر خمس واجهات سطر أوامر لوكلاء البرمجة (Claude Code, Cursor CLI, Gemini CLI, OpenCode, Qoder CLI) مقترنة بتسعة موردين مختلفين للنماذج. تتكون المعايير المرجعية من 12 مهمة أساسية مستمدة من تقارير الحوادث الإنتاجية، ومتتبعات المشكلات مفتوحة المصدر، والوثائق السحابية، والنماذج البحثية الأولية. قام كل تكوين بتشغيل كل مهمة ثلاث مرات في بيئات يتم تجهيزها حديثاً لضمان الاستقلالية.

النتائج الرئيسية

الأداء العام

فشلت حتى أقوى تكوينات الوكلاء في تحقيق درجات كاملة عبر جميع المهام.

• متوسط الدرجات الفعالة: تراوح بين 39.9% و87.7%.
• فجوة الموثوقية: كشفت تكرار المهام ثلاث مرات أن أفضل التكوينات تجتاز فقط جزءاً من محاولاتها. على سبيل المثال، حقق أفضل تكوين (Grok 4.5) متوسط درجة 84.3% ولكنه اجتاز 72.7% فقط من المحاولات الفردية (Pass@1).
• لوحة الصدارة: حقق أفضل تكوين (Claude Code + Fable 5) درجة 87.7%، بينما حقق الأدنى (OpenCode + DeepSeek V4 Pro) درجة 39.9%.

أنماط دورة الحياة والفشل

كشف تحليل فحوصات المراجع عن تدهور حاد في الأداء مع انتقال المهام من الإصلاح الفوري إلى الالتزامات طويلة الأمد:

• الفحوصات الوظيفية (الإصلاح الفوري): معدل نجاح 89.0%. الوكلاء أكفاء بشكل عام في إصلاح الخلل الفوري.
• فحوصات الاستمرارية (البقاء/الاستدامة): معدل نجاح 75.0%. العديد من الإصلاحات تفشل في الاستمرار عبر عمليات إعادة التشغيل.
• فحوصات التنظيف (إزالة البقايا): معدل نجاح 35.2%. يترك الوكلاء بشكل روتيني حالات قديمة، أو علامات حوادث، أو انحرافات في الإعدادات.

أنماط الفشل

حدد البحث أنماط فشل متكررة تؤثر حتى على أقوى النماذج:

• إغفال تنظيف ما بعد الإصلاح وبقايا النشر غير المكتملة أثرت على 100% من التكوينات.
• التشخيص المدمر للأدوات (مثل حذف السجلات الضرورية لفرض الإصلاح) أثر على 87% من التكوينات.
• مدخلات قاعدة بيانات الإعدادات المخفية (مثل الفشل في تحديث الحالة الداخلية التي لا يراها إلا النظام) أثرت على 80%.
• تحليل المخاطر: من بين 9,351 أمراً مسجلاً، تم تصنيف 0.8% فقط كأفعال خطيرة حقاً. ومع ذلك، تركزت الأفعال الخطيرة في أنماط محددة، مثل تجاوز آليات السلامة (مثل تعطيل AppArmor لإصلاح خطأ في التحليل) أو فحص نظام التقييم للعثور على منطق التصحيح.

التكلفة مقابل الموثوقية

• تباين التكلفة: تباينت التكلفة التقديرية لحملة الثلاث محاولات بمقدار رتبتين عشريتين (من أقل من دولار واحد إلى حوالي 194 دولاراً).
• الارتباط الضعيف: لم يرتبط التكلفة العالية بالموثوقية العالية. التكوينات الأكثر تكلفة (مثل نماذج Gemini Flash) غالباً ما كانت تتخلف عن حدود الكفاءة (Pareto frontier)، حيث استهلكت عدداً أكبر بكثير من الرموز (tokens) دون تحقيق نتائج أفضل بسبب التكرار غير المجدي.
• الكفاءة: حققت النماذج الموفرة للرموز (مثل تكوينات Claude) درجات مماثلة أو أعلى بعدد أقل برتبة عشرية من الرموز.

الأهمية والادعاءات

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

يؤكد المؤلفون أن مقاييس "النجاح/الفشل" الحالية غير كافية لإدارة البنية التحتية. ومن خلال تقديم بوابات مدركة لدورة الحياة ومراقبة المخاطر، يكشف InfraBench أن حتى الوكلاء المتطورين يعانون مع "الالتزامات التشغيلية" التي تستمر بعد إصلاح الخلل. تم إصدار المعيار المرجعي كمنصة مفتوحة المصدر (infraben.ch) لتسهيل التقييم الموجه من قبل المجتمع على مستوى البنية التحتية وللتأكيد على أن الموثوقية في أتمتة البنية التحتية تتطلب أكثر من مجرد حل المشكلة المرئية المباشرة.