От говорящей головы к живому персонажу: как Unreal Engine и RAG оживили интерактивного NPC
Интерактивный искусственный интеллект в играх долго оставался набором звуковых реакций: NPC «слышал» игрока, но отвечал статично, не влияя на реальность мира. В новой разработке команда из Habr AI создала полноценного торгового бота на Unreal Engine, где локальная модель большой языковой модели (LLM) комбинируется с технологиями RAG, анализом эмоций и функциями вызова действий (function calling). Теперь виртуальный персонаж может проверять инвентарь, реагировать на тон речи игрока и совершать реальные транзакции без необходимости подключения внешних API.
# От говорящей головы к живому персонажу: как Unreal Engine и RAG оживили интерактивного NPC
Движок Unreal Engine давно зарекомендовал себя как платформа для создания не только графики, но и интеллектуальных систем. Однако до недавнего времени создание живых персонажей в играх имело ограничения. Прототипы на базе MetaHuman могли имитировать человеческую речь через распознавание (STT) и синтез (TTS), но их знания о мире были зашифрованы в статичных инструкциях (system prompt). Такой подход приводил к тому, что NPC одинаково вежливо отвечал на любой вопрос, игнорируя контекст игры и эмоциональное состояние собеседника.
В представленной архитектуре инженеры решили эту проблему, внедрив три ключевых компонента: Agent Knowledge Base на базе RAG (Retrieval-Augmented Generation), Expressive Agent для анализа эмоций и Agent Function-Calling для взаимодействия с игровой логикой. Результатом стала система, которая работает локально на видеокарте, не требуя подписки на облачные модели, но обеспечивая глубокий уровень погружения.
База знаний в реальном времени: как работает RAG в играх
Классическая система RAG обычно хранит в векторном хранилище фрагменты текста документов, подыскивая похожие куски для ответа. В игровом контексте такой подход неэффективен, так как состояние мира игры меняется каждую секунду (игрок купил предмет, получил урон, перешел в другую локацию). Дублирование этой динамической информации в базе знаний привело бы к рассинхронизации.
Вместо этого разработчики внедрили архитектуру, основанную на намерениях. База знаний содержит не факты, а шаблоны запросов игрока (интенции). Каждый шаблон связывает намерение пользователя (например, «продать предмет») с конкретным инструментом извлечения данных (DataGetter). Когда игрок говорит что-то вроде «Дай мне дробовик», модель с помощью embedding-алгоритма определяет смысловое намерение. Затем система не ищет факты в базе, а вызывает DataGetter, который напрямую опрашивает логику игры: сколько денег у игрока, есть ли товар у торговца. Таким образом, контекст, поступающий к языковой модели, всегда является актуальным срезом состояния игрового мира.
Для разработчиков это означает простоту интеграции: чтобы изменить источник данных, достаточно заменить логику в DataGetter, не переписывая системные инструкции для LLM. Модель получает на вход объединенный JSON-объект с запросом игрока и актуальными данными, что радикально снижает вероятность «галлюцинаций» и выдумки несуществующих предметов.
Эмоциональный интеллект и синхронизация речи
Статичный голос и выражение лица часто разрушают immersion (погружение) в игру. Чтобы персонаж ощущался живым, система引入了 механизм Expressive Agent. Этот компонент анализирует не только слова игрока, но и его контекст: здоровье, финансы, агрессию в тоне голоса. Одни и те же слова могут вызвать у NPC жалость, гнев или равнодушие в зависимости от ситуации.
На выходе модель генерирует тег эмоции (Happy, Sad, Angry, Surprise, Neutral). Этот тег запускает два параллельных процесса: 1. Лицевая анимация: В движке Unreal Engine активируется соответствующий набор анимаций MetaHuman (Face_Joy, Face_Anger и т.д.), оживляя выражение лица персонажа. 2. Голос и синхронизация губ: В память загружаются референсные сэмплы голоса для каждой эмоции. На их основе в реальном времени синтезируется аудиопоток ответа. Затем плагин ULSS (Unreal Lip-Sync) создает последовательность движения ключевых точек губ, идеально подгоняя их под ритм и интонацию сгенерированной речи.
Всё это происходит на стороне клиента, используя локальные модели от компании Qwen (для STT, TTS и инференса LLM). Это гарантирует отсутствие задержек при передаче данных в облако и соблюдение приватности данных игрока.
Действия в игре: от слов к коду через Function Calling
Главным вызовом для чат-ботов всегда было выполнение действий, а не просто генерация текста. Если NPC просто говорит «продай мне дробовик», но не списывает деньги и не меняет инвентарь, он остается декорацией. Для решения этой задачи использован механизм Function Calling (вызов функций).
Система работает по принципу строгого контракта. Модель вынуждена выводить ответ в формате JSON, который включает не только текст ответа и эмоцию, но и объект с действием. Этот объект содержит имя функции (например, SellItem) и её параметры. Игровой движок интерпретирует этот сигнал как прямую команду: ищет соответствующий обработчик (Blueprint), выполняет логику сделки и обновляет интерфейс.
Однако доверять модели выполнение кода опасно. Она может выдать действие, которого не существует, или использовать неверные параметры (например, название предмета на русском вместо английского ключа). Чтобы решить эту проблему, авторы используют GBNF-грамматику (Grammatical Constraint). Это не просто запрос на валидный JSON, а ограничение на уровне генерации токенов. Языковая модель физически не может сгенерировать символы, выходящие за рамки заданной структуры. Это служит надежным предохранителем, превращая LLM из капризного творца в предсказуемого агента, строгого исполнителя команд.
Требования к железу и масштабирование
Стоит отметить, что работа четырех нейросетевых моделей одновременно (для диалога, поиска контекста, распознавания речи и синтеза голоса) требует серьезных ресурсов. На видеокарте загружаются модели Qwen3.5, Qwen-STT, Qwen-TTS и embedding-модели, что в сумме занимает около 13 ГБ видеопамяти. Рекомендуемым решением уровня видеокарт является RTX 5070 Ti с 16 ГБ VRAM. При использовании менее мощных карт часть вычислений перекладывается на процессор, что увеличивает задержку ответа.
Важно, что память расходуется не на каждого персонажа отдельно. Модель загружается один раз, и поверх неё могут работать десятки NPC с разными именами, голосами и наборами действий. Это открывает перспективы для создания полностью живых городов с множеством взаимодействующих агентов.
Таким образом, представленный кейс демонстрирует переход от имитации общения к реальному интеллектуальному взаимодействию. Технология позволяет создавать персонажей, которые не только знают о мире, но и действуют в нем, сохраняя при этом эмоциональную связь с игроком, а всё это работает в автономном режиме на игровом устройстве.
*Интересно, что строгие ограничения формата вывода (grammar) превращают творческую свободу LLM в дисциплинированный инструмент, где модель больше не может «заблудиться» в логике приложения.*