Зроблення ігор сприйнятними для LLM-агентів

Розробники, які використовують LLM-моделі в реальній розробці ігор, часто наштовхуються на стіну. Хоча LLM чудово працюють у стеку на основі вебу, їхнє застосування до традиційної розробки ігор дає погані результати. Ігри містять елементи, які невидимі для LLM, що означає: моделі за замовчуванням не можуть ефективно їх читати та змінювати. Щоб це виправити, розробники мають впровадити такі харнес-системи, які зроблять ігри сприйнятними для AI-агентів.

Чому LLM важко працювати з іграми

LLM погано читають ігри в їхньому стані за замовчуванням. На відміну у веб-застосунків, які мають величезну кількість відкритого коду, іграм бракує стандартизованих інструментів, і вони мають багато елементів, які важко витягнути з коду. Коли розробники покладаються на LLM для обробки цих невидимих елементів, моделі зазнають невдач. Основна проблема — це проблема контексту. Оскільки ігри — це не лише код, наявні харнес-системи, які працюють із кодом, недостатні. Розробникам потрібно відкрити чорну коробку гри та зробити її більшу частину безпосередньою доступною для LLM.

Детермінізм та відтворювані стани

Щоб гра стала сприйнятною для агента, важливий детермінізм. Гра має дозволити легко й точно відтворювати конкретний стан. Це вимагає наявності з самого початку єдиного seed-джерела випадковості, яке гарантує, що кожен виклик недетермінованих функцій використовує це джерело. Якщо код викликає випадкову float-функцію 30 разів, 30-й виклик має бути ідентичним щоразу. Відтворювані стани дають агентам змогу повторно досягати тієї ж точки з нуля для перевірки змін. Також рекомендовані вбудовані screenshot API. Увімкнення-вимкнення шарів UI та gameplay зменшує візуальний шум і дозволяє LLM зосередитися на конкретному шарі, над яким відбувається робота.

Зроблення ігор сприйнятними для AI

Візуальне оцінювання через скріншоти може спричинити втрату контексту. Навіть мультимодальним моделем важко розуміти зміни з повного скріншота, що нагадує забруднення контексту. Замість того, щоб просто показувати зображення, розробники мають використовувати дифінг зображень. Такі інструменти, як odiff, можуть порівнювати два зображення та виводити кількісну значимість відмінностей, наприклад, на 85 відсотків схожі. Це дає LLM стабільну базову лінію для оцінки прогресу кожного циклу, поки він намагається зменшити різницю між поточним станом та цільовим зображенням.

Архітектура для агентів: Thing Driven Development

Архітектурний вибір теж має значення. Збереження глибоко об'єктно-орієнтованих ієрархій програмування в AI-агентах спричиняє плутанину, коли вони намагаються з'ясувати, куди вносити зміни. Замість цього розробники мають впровадити Thing Driven Development. Це означає, що все є об'єктом одного типу, тобто Thing, зі значеннями stat та type enum. AI це подобається, бо існує один джерело правди. Немає невизначеності, чи розширити клас, чи створити новий. Збереження та завантаження також стає тривіальним. Гра просто перетворюється на гігантський список Thing-ів, який серіалізується одним способом. Фіксація змін в цих об'єктах можлива за допомогою Command Pattern, із збереженням модифікацій у вигляді серіалізуваних command-об'єктів.

Джерела: kylekukshtel.com