Snorkel تشغّل ملايين المحاكاة الوكيلية شهريًا وتوفّر 20% في تكلفة البيئات المعزولة

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

لماذا يحتاج الوكيل إلى بيئة واقعية

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

تتنوع مهام Snorkel: البرمجة، والبنية التحتية، وهندسة تعلّم الآلة. فوكيل تعلّم الآلة يحتاج إلى GPU لتدريب نموذج، ووكيل البنية التحتية قد يحتاج إلى نواة Linux كاملة وعدة حاويات. لذلك يشغّل الفريق المحاكاة في بيئات Modal المعزولة، بما فيها بيئات VM المعزولة ذات الأنظمة متعددة الخدمات وأحمال GPU. ومزوّد واحد لوحدات GPU والمعالجات المركزية يبسّط البنية التحتية ومحاسبة التكاليف معًا. وبحسب Snorkel، لم تحصل على بيئات GPU معزولة بالحجم المطلوب إلا لدى Modal.

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

لماذا يصعب تقدير موارد الوكيل

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

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

الحل هو التوسّع المؤقت (bursting) في Modal. فالبيئة المعزولة توسّع الذاكرة أو المعالج فورًا عند الحاجة. وتدفع مقابل الاستهلاك الفعلي أو الحد الأدنى المعلن، أيهما أكبر. وهذا أتاح طلب موارد أقل دون التعرض للانهيارات. وتتحدث Snorkel عن توفير نحو 20% من الفاتورة الإجمالية للبيئات المعزولة، كما انخفض عدد التشغيلات التي سقطت بسبب الحدود.

تنبيه: حتى الآن لا يستخدم التوسّع المؤقت سوى 10–15% من بيئات Snorkel المعزولة. ورقم 20% هو تقدير الشركة نفسها، وفي دراسة حالة ينشرها المورّد. لذا اعتبروه مؤشرًا إرشاديًا لا ضمانًا لحملكم.

الاستدلال بحسب المعيار

النصف الثاني من المهمة هو النماذج نفسها. فللفحوص الأولية لنماذج open-weight الجديدة تستخدم Snorkel نقطة وصول عامة جاهزة. وإن لزم نموذج أعاد العميل تدريبه، يرفعه الفريق بأوزان مخصصة على نقطة وصول مخصصة. وثمة تفصيل مهم: كل ذلك يتم دون مشاركة فريق البنية التحتية. يُرفع النموذج، ويُشغَّل المعيار، ثم يُنهى.

وتخطط الشركة لتقييم Modal للتدريب أيضًا، لإغلاق حلقة «البيانات ← التدريب ← التقييم» على منصة واحدة.

ما الذي يمكن الاستفادة منه

• إذا كنتم تبنون اختبارات تقييم للوكلاء، فافصلوا بين «الوكيل لم يستطع» و«البيئة لم تسمح». سجّلوا أسباب الإخفاق واحسبوا حالات الفشل بسبب الموارد على حدة.
• لا تحدّدوا الموارد بالتخمين، لا بالمتوسط ولا بالحد الأقصى. قيسوا ذروة المعالج والذاكرة على عيّنة من التشغيلات (رسمت Snorkel مخططًا كهذا لـ 5 000 بيئة معزولة) وانظروا في الحدود المرنة.
• إذا كان الوكلاء يحتاجون إلى GPU داخل البيئة المعزولة، فتأكدوا من أن المزوّد يوفّره بالحجم المطلوب قبل تصميم المعيار.
• إذا كان العميل ينتظر الإجابة خلال يوم، فالمهم ليس متوسط السرعة بل ذروة التوازي.

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