سرب من وكلاء الذكاء الاصطناعي يطوّر لعبة Spawn: التوكنات تكلّف 3 ملايين دولار شهريًا

Spawn لعبة متعددة اللاعبين برسومات ثلاثية الأبعاد من نوع الفوكسل، يتغير عالمها بالطلبات النصية. يكتب اللاعب إلى مساعد الذكاء الاصطناعي المدمج «سافي» ما يريد إضافته، فتكمل بناء العالم. جرّب المطوّر سايمون ويليسون اللعبة من هاتفه، وحصل خلال دقائق على قلعة ثم تنين، ثم حلّق حول القلعة على ظهره. لكن الأهم أمر آخر: فبحسب المؤسس جيكوب سانسبري، يطوّر اللعبةَ نفسها سربٌ من الوكلاء على نموذج Fable. ولا يشارك البشر في العملية إلا قليلًا، بينما تذهب أكثر من 3 ملايين دولار شهريًا إلى التوكنات. والتوكنات هنا وحدة الدفع مقابل عمل النموذج اللغوي. ويقول سانسبري إن الإنفاق عليها يفوق الإنفاق على الرواتب بـ30 مرة. وبحساب تقريبي، يبلغ إجمالي رواتب الفريق نحو $100 ألف شهريًا.

نشر كل ساعة وأخطاء تفتحها اللعبة بنفسها

يعدّل الوكلاء الشيفرة الحية مباشرة، ويرسلون التعديلات إلى بيئة الإنتاج (أي إلى اللاعبين) مرة في الساعة. ويقرؤون بأنفسهم الأخطاء وتقارير العيوب والمقاييس. وتبدأ نحو 60% من المهام من أحد أربعة مصادر:

• خطأ في بيئة الإنتاج؛ • تقرير عن خطأ من سافي؛ • سطر غريب في السجلات؛ • طلب ميزة جديدة.

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

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

تراجع خلال 30 ثانية وأعطال مخططة

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

أي نموذج نجح وأيّ نموذج لم ينجح

بحسب سانسبري، أتاح Fable 5 هذا المستوى من الاستقلالية، ثم Fable 5.1. أما Opus 5.5 فلا يرقى إلى مستوى مهامهم. وتُروى قصة منفصلة عن GPT-6 Astra. فقد طُلب منه تطبيق إصلاحات بناءً على نتائج فحص أمني. والنتيجة أن جميع الوظائف عُطّلت ووُسمت بأنها ستُفعَّل بعد انتهاء التعديلات، وكما يكتب سانسبري، فإن النموذج «جعل غير الآمن آمنًا بمجرد إيقافه». رسميًا لا توجد ثغرات، لكن لا يوجد منتج أيضًا.

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

ما الذي يمكن للمهندسين أخذه من هذه التجربة

أما رقم 3 ملايين دولار وتفوّق الإنفاق على الرواتب بـ30 مرة، فهما حتى الآن رواية المؤسس نفسه، ولا توجد تأكيدات مستقلة. لكن مجموعة الممارسات محددة وقابلة للنقل:

• عمليات نشر قصيرة وسيلةً لإبقاء الوكيل داخل السياق. التغييرات الصغيرة تتسع لتلك الساعات القليلة التي يستطيع الوكيل الاحتفاظ بها. • تراجع سريع وموضعي. التراجع خلال 30 ثانية يجعل النشر كل ساعة مقبولًا. • تدريبات على الاستعادة. الأعطال المتعمدة تتحقق من أن الوكلاء المسؤولين عن الحوادث يعيدون الخدمة فعلًا. • فرز الأخطاء بواسطة الوكيل. تترك النتائج الثلاث (إصلاح، عدم إصلاح، حاجة إلى قرار بشري) للبشر المسائل المتعلقة بالمقصد فقط. • اختبار النموذج على مهامك أنت. المهمة الأمنية نفسها أوصلت Fable إلى منتج يعمل، وأوصلت Astra إلى منتج معطّل.

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