فريق ARC-AGI-3 يرفع سرعة الوكيل من 500 إلى 3400 رمز في الثانية

في مسابقة ARC-AGI-3 احتل أحد المشاركين المركز السادس، وخرج بدرس مفيد يتجاوز بكثير وكلاء الألعاب. عندما تكون ميزانية الحوسبة محددة بتسع ساعات، فلا يفوز بالضرورة صاحب أذكى موجّه. أحيانًا يكون الحاسم هو عدد المحاولات الكاملة التي ينجح الوكيل في إنجازها، ومقدار الجودة الذي تخسره مقابل هذه السرعة.

بدأ المؤلف بنحو عشرة خطوط لعب متوازية وسرعة تقارب 500 رمز في الثانية. وبعد شهر من العمل كان الخادم يقدّم نحو 3400 رمز في الثانية ويخدم 110 خطوط في آن واحد على وحدة GPU بذاكرة 96 غيغابايت. غير أن التسريع البسيط لم يضمن تحسن النتيجة: فبعض التحسينات أفسدت إجابات النموذج دون أن يلاحظ أحد، وبعد عدة ساعات من اللعب ظهرت حالة ثبات في النتائج.

لماذا لم تفد الموجّهات إلا قليلًا

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

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

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

كيف تُحشر 110 خطوط على بطاقة واحدة

شغلت أوزان النموذج وخبراؤه الـ512 معظم ذاكرة GPU. لذلك نُقلت حالة خطوط اللعب إلى الذاكرة العشوائية، وضُغطت ذاكرة KV المؤقتة إلى صيغة رباعية البت، وقُلّص عدد الخبراء المتاحين أولًا إلى 400. وسمح ذلك بزيادة التوازي زيادة كبيرة.

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

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

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

السرعة مطلوبة حتى نقطة التشبع

أكثر الاكتشافات عملية هو التبديل الفوري للوضع. ففي الساعات الست الأولى كان الوكيل يعمل بسرعة مع 400 خبير ويشغّل أقصى عدد من الخطوط. وعندما تنتهي الألعاب البسيطة ويبقى نحو 70 لعبة صعبة، كان النظام يفعّل جميع الخبراء الـ512 وينتقل إلى توليد أعلى جودة. ورفع هذا الوضع النتيجة من نحو 50 إلى 54 نقطة.

بعد لحظة معينة لم تعد الرموز الإضافية تفيد تقريبًا. كان الوكيل يحسم المستويات السهلة بسرعة، ثم يتعثر في الصعبة: وصار الفارق بين 600 ألف و900 ألف رمز للعبة الواحدة ضئيلًا. هذا هو الحد العملي لتوسيع المحاولات دون تحسين المُحلّل نفسه.

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