Что ИИ-мастер DnD пока не умеет: честный список ограничений

07.09.2026 · Владислав Новиков

ИИ-мастер в днд-боте пока не умеет надёжно видеть инвентарь и кондиции персонажа при генерации прозы, различать сцены при разборе действий игрока и удерживать редких NPC на сцене без лишних затрат - часть багов уже почищена, часть осталась принятым ограничением.

Что ИИ-мастер DnD пока не умеет: честный список ограничений

ИИ-мастер в днд-боте уже водит бои, генерирует подземелья и держит лор кампании - но это всё ещё активная стройка, а не готовый продукт без швов. Ниже - не рекламный список фич, а честная инвентаризация того, где нейросеть пока спотыкается: от инвентаря персонажа до летописи кампании. Часть проблем уже почищена, часть - принятое ограничение, о котором честнее сказать заранее, чем упаковать в маркетинг “магия работает всегда”.

Список собран по живым багам и решениям разработки, а не по теории: аудит промптов, QA-прогоны и A/B-сравнение моделей нарратора за последние месяцы. Дальше - по одному пункту на баг или ограничение, без воды.

Почему ИИ-мастер не видит кондиции и инвентарь персонажа?

Нарратор - та часть нейросети, что пишет прозу для игрока - иногда работает вслепую относительно состояния героя: не видит активных кондиций, инвентаря, золота и потраченных ячеек заклинаний. На аудите промптов “отравленного” персонажа нарратор описывал бодрым и весёлым, а один раз предложил купить верёвку - которая уже лежала в сумке героя. Ситуация из разряда “ребят, она у меня уже есть” - забавно на бумаге, но за столом ломает доверие к рассказчику.

Похожая дыра нашлась со списком заклинаний: игрок писал “творю Counterspell”, которого у его класса физически нет, - и получал полноценный отыгрыш вместо честного отказа. Отдельно ловили баг с колчаном: движок честно фиксировал ноль стрел, но флаг не долетал до нарратора, и тот с чистой совестью описывал меткий выстрел из пустого лука. Три разных бага - а корень один: часть данных о персонаже не доезжает до того слоя, который сочиняет текст.

Часть таких дыр уже закрыта: например, ИИ-мастер научился держать паралич и другие состояния, не забывая их через ход-другой, как раньше.

Почему разбор действий игрока путает таверну со склепом?

Парсер, который превращает фразу игрока в игровое действие, до недавнего времени разбирал намерение без контекста сцены - не зная имён NPC и типа локации, где всё происходит. Из-за этого “обыскиваю стол” в шумной таверне и в мрачном склепе читались буквально одинаково, хотя по смыслу это два разных действия с разным результатом: один стол - это поднос с кружками, другой - алтарь с костями.

Тот же корень - у путаницы с целями в бою: движок иногда цеплялся не за того NPC, если игрок называл его через контекст сцены (“атакую контрабандиста за столом”), а не по имени напрямую. Решение звучит просто - научить парсер видеть сцену целиком, а не только фразу игрока, - но на практике это отдельный слой контекста, который приходится прокидывать через весь пайплайн хода.

Почему NPC могут исчезать на следующих ходах?

Если нарратор впервые упомянул персонажа только в прозе, а игрок с ним не подрался и не поторговался, этот NPC рискует пропасть со сцены на следующих ходах или незаметно смениться - как будто его никогда и не было. Починка “на каждый ход” стоила бы лишнего вызова нейросети на КАЖДЫЙ ход ради довольно редкого косметического случая: решение принято сознательно - не чинить, а экономить ресурсы там, где цена фикса выше цены бага.

Это не уникальная болезнь одного конкретного бота. Разбор чужих ИИ-мастеров тоже фиксирует, что кампании “начинаются блестяще и теряют нить где-то после пятидесятого хода” - модель забывает имя персонажа и пускает за стол злодея, которого игрок уже прикончил (arcanumrpgs.com, 2026). Получается, что забывчивые NPC - это не баг одной реализации, а системная плата за то, как вообще устроены языковые модели: у них нет постоянной памяти, только окно контекста, которое рано или поздно кончается.

У нашего бота, кстати, была и обратная версия той же беды: баг заставлял фантомного NPC таскаться за героем по всем сценам сразу, вместо того чтобы вовремя пропасть. Тающий NPC и вездесущий NPC - две стороны одной и той же проблемы с персистентностью.

В какую сторону чаще ошибается генерация боёв и квестов?

Ошибки нейросети редко бывают нейтральными - у них есть направление. Сравнение двух моделей нарратора на одном и том же наборе ходов показало разницу в качестве (8,70 балла против 7,93) и втрое меньше грубых ошибок (3 против 9) у одной из них - но именно у неё профиль ошибок оказался опаснее, “в пользу игрока”: то убийство NPC засчитывалось по одной лишь заявке игрока без проверки, то квест закрывался авансом раньше срока, то движок повторно начислял уже выданную награду.

Звучит как подарок игроку, но на деле рушит саму механику риска - если решение движка можно переписать словами задним числом, зачем вообще было его принимать. Быстрая и дешёвая модель, которая охотно подыгрывает, кажется удобной ровно до первого разбора полётов: щедрость за счёт правил игры - это не щедрость, а дыра в балансе, которую рано или поздно найдут и начнут эксплуатировать.

Почему квесты иногда закрываются раньше времени?

Составной квест вроде “убить и найти” - там, где нужно выполнить два условия по очереди, - иногда засчитывался выполненным уже после первой половины, хотя вторая часть работы игроком ещё не сделана. Нарратор описывал развязку раньше, чем игрок фактически довёл дело до конца, а движок верил прозе больше, чем собственному чек-листу условий: раз в тексте прозвучало “дело сделано”, значит дело сделано - даже если по факту нет.

Подробный разбор этого конкретного бага, с деталями, что именно пошло не так в проверке условий, - в отдельной статье про квест, который закрывался раньше времени.

Почему летопись кампании иногда переписывает историю?

Летопись - короткую хронику похождений партии - пишет сам нарратор по итогам каждого хода. Один раз он закрепил в ней выплату золота, которой на самом деле не было, - и эта строка осталась в истории кампании навсегда, потому что летопись по задумке не перезаписывается задним числом: это всё-таки хроника, а не черновик.

Что было: нарратор мог зафиксировать в летописи любую денежную строку без проверки, и она становилась частью канона кампании насовсем. Что стало: пайплайн научили вычищать “денежные” предложения из летописи перед записью и вместо них ставить каноничную фразу-заглушку “Сделка сорвалась” - если сделки по факту не случилось, история не должна врать о деньгах, даже задним числом.

Самая честная слабость: что происходит после первой сессии?

Продукт неплохо цепляет игрока с самого начала: медианный игрок делает 16 ходов за первую сессию, не бросая на середине - значит, первое впечатление в целом работает. Затягивает? Затягивает. Но медианная жизнь игрока - это ровно одна сессия. Повода вернуться через неделю и продолжить ту же кампанию генерация пока даёт не всем: это не баг конкретной механики вроде колчана или летописи, а вопрос удержания, над которым ещё предстоит работать отдельно - и это честнее признать, чем делать вид, будто проблема только в багах из списка выше.

Все пункты выше - не жалобы на продукт, а список того, что чинится или сознательно не чинится прямо сейчас: DnD-бот в Telegram - активная стройка, а не готовая коробка с гарантией без единого шва. Если за столом наткнётесь на ещё один похожий баг - репорт тестерам всегда ценнее молчаливого раздражения, он реально попадает в такие же разборы, как этот. А разбор где ИИ-мастер честно проигрывает живому мастеру за столом поможет понять, какие из ограничений принципиальные, а какие - просто вопрос времени.

Как готовился материал: черновик собирает мой ИИ-конвейер по темам из практики таверны, факты сверяются с первоисточниками и правилами, финальную версию я читаю и правлю руками перед публикацией. Обложку тоже рисует нейросеть. Про кухню — на странице о проекте.