جعل الألعاب مفهومة لوكلاء LLM

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

لماذا تجد نماذج LLM صعوبة مع الألعاب

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

الحتمية والحالات القابلة للتكرار

لكي تصبح اللعبة مفهومة للوكيل، الحتمية هي الأساس. يجب أن تكون اللعبة قادرة على إعادة إنتاج حالة محددة بسهولة ودقة. يتطلب ذلك وجود مصدر موحد للعشوائية (seed) من البداية، مما يضمن أن جميع استدعاءات الدوال غير الحتمية تستخدم هذا المصدر. إذا استدعت الشفرة دالة عشوائية من نوع float 30 مرة، يجب أن تكون الاستدعاء الثلاثين متطابقًا في كل مرة. تمكن الحالات القابلة للتكرار الوكلاء من الوصول إلى نفس النقطة مرارًا وتكرارًا من الصفر لاختبار التغييرات. يوصى أيضًا بتضمين واجهات برمجة تطبيقات لقطات الشاشة (screenshot APIs). تشغيل وإيقاف طبقات واجهة المستخدم (UI) وطريقة اللعب (gameplay) يقلل الضوضاء المرئية ويتيح لنموذج LLM التركيز على طبقة محددة يعمل عليها.

جعل الألعاب قابلة للفهم للذكاء الاصطناعي

التقييم المرئي عبر لقطات الشاشة قد يتسبب في فقدان السياق. حتى النماذج متعددة الوسائط تجد صعوبة في فهم التغييرات من لقطة شاشة كاملة، مما يشبه تلوث السياق. بدلاً من عرض الصور بشكل أعمى، يجب على المطورين استخدام تحديد الصور (diffing). أدوات مثل odiff يمكنها مقارنة صورتين واستخراج أهمية الاختلاف الرقمي، على سبيل المثال، بنسبة 85% تشابه. هذا يمنح نموذج LLM خط أساس مستقر لتقييم التقدم في كل دورة أثناء محاولته تقليل الفرق بين الحالة الحالية والصورة المستهدفة.

بنية للوكلاء: تطوير الأشياء (Thing Driven Development)

للقرار المعماري أيضًا أهميته. الاحتفاظ بتسلسلات هرمية عميقة من البرمجة الموجهة بالكائنات يسبب ارتباكًا لدى وكلاء الذكاء الاصطناعي عندما يحاولون تحديد مكان إجراء التغييرات. بدلاً من ذلك، يجب على المطورين دمج "تطوير الأشياء" (Thing Driven Development). هذا يعني أن كل شيء كائن من نوع واحد، أي Thing، بقيم stat ونوع type enum. يعجب الذكاء الاصطناعي بذلك لأنه يوجد مصدر حقيقة واحد. لا غموض في توسيع فئة أو إنشاء فئة جديدة. يصبح الحفظ والتحميل أمرًا بديهيًا. تتحول اللعبة ببساطة إلى قائمة عملاقة من الأشياء (Things) يتم تسلسلها بطريقة واحدة. يمكن تثبيت التغييرات في هذه الكائنات باستخدام نمط الأمر (Command Pattern)، من خلال تخزين التعديلات ككائنات أمر (command objects) قابلة للتسلسل.

المصادر: kylekukshtel.com