كيف بنى زيرو نويتشي لعبة مستذئبين بالذكاء الاصطناعي تضم عشرة وكلاء

يوضح 野市 零 / Zero Noichi ما يحدث عندما يتشارك عشرة وكلاء للذكاء الاصطناعي لعبة مستذئبين واحدة: فلم يعد التحدي يتمثل في توليد رد ذكي، بل في تنسيق الأصوات، والأدوار، والذاكرة، والتوقيت، والتعارض، من دون أن يبدو الحوار آليًا.

يشكر هذا المقال 野市 零 / Zero Noichi على توثيق التجربة في فيديو المستذئبين بالذكاء الاصطناعي الأصلي. يُقدَّم الفيديو كتجربة ترفيهية، لكنه يكشف أيضًا عن المشكلات الهندسية الكامنة وراء تطبيق متعدد الوكلاء يبدو مقنعًا: كيفية جعل الوكلاء ينتظرون، ويقاطعون، ويتذكرون، ويخدعون، ويتفاعلون بصفتهم أعضاء في عالم مشترك واحد.

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

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

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

المشكلة الأصعب هي الواقع المشترك، وليس عدد الوكلاء

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

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

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

تحتاج موجّهات الشخصيات إلى أكثر من صفة شخصية

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

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

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

اختيار النموذج يغيّر إيقاع اللعبة

يسلط الفيديو الضوء على اختيار نماذج اللغات الكبيرة باعتباره جزءًا من التجربة، بدل التعامل مع «الذكاء الاصطناعي» كمكوّن واحد قابل للاستبدال. وقد سُمّي Moonshot Kimi K3 في المشروع مكوّنًا لنموذج اللغة، ويؤثر هذا الاختيار ليس في جودة الإجابات فحسب، بل أيضًا في طول الاستجابات، وزمن الاستجابة، وسلوك الرفض، والأسلوب اللغوي، وكمية السياق التي يمكن نقلها بين الأدوار.

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

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

تتطلب المحادثة الطبيعية محركًا لتناوب الأدوار

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

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

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

يضيف الصوت إشارات اجتماعية—وأنماطًا جديدة من الأعطال

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

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

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

تحتاج حلقة اللعبة إلى مصدر وحيد للحقيقة من جانب الخادم

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

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

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

موضع ZimaBoard 2 في البنية

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

يعتمد تشغيل اللوحة لنموذج معين محليًا على حجم النموذج، والتكميم، والذاكرة، والتسريع، ووقت الاستجابة الذي تتطلبه التجربة. ولهذا السبب، فإن مقارنة إعداد Zero Noichi باستخدام ZimaBoard 2 وAMD MI50 المنفصل مفيدة: إذ تغيّر القدرة الحاسوبية الإضافية لوحدة معالجة الرسومات مسار الاستدلال، بينما تظل اللوحة قادرة على توفير طبقة المضيف والخدمات المستقرة. وتتمثل قاعدة التخطيط الآمنة في فصل التنسيق عن الاستدلال: صمّم التطبيق بحيث يظل محرك الحالة مفيدًا حتى إذا انتقلت نقطة نهاية النموذج بين خدمة محلية، أو جهاز آخر، أو واجهة برمجة تطبيقات مستضافة.

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

ما تكشفه النتيجة المباشرة عن الذكاء الاصطناعي متعدد الوكلاء

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

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

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

كيفية إعادة إنشاء الفكرة من دون نسخ الإنتاج بأكمله

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

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

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

لمنصة خادم منزلي مدمجة يمكنها استضافة خدمات التنسيق والخدمات الداعمة، استكشف ZimaBoard 2 - خادم منزلي مصغر لفكرتك الكبيرة. ولمقارنة الأفكار مع صانعين آخرين، انضم إلى مجتمع ZimaSpace على Discord.