TL;DR
Если попросить модель сыграть персонажа или клиента с правилом «реагирует на то, что было раньше», она выдаст правдоподобную статистику, но не само правило. Реакции будут встречаться в нужных пропорциях, а условие «если А, то Б» модель нарушает. Распознать правило и выполнять его на длинной дистанции — две разные способности. Исследование показывает это на игре «камень-ножницы» и на простых цепочках символов.
Главная находка: больше истории не значит лучше понимание. Дали 100 раундов — модель угадывает стратегию игрока, дали 1000 — угадывает хуже, хотя обычный алгоритм по тем же данным находит её в 100% случаев. Даже когда модель правильно назвала стратегию, она часто не следует ей при генерации. При этом общая картина «выглядит как надо»: у 42% неверно угаданных стратегий итоговое распределение ходов почти идеально совпало с целевым. Чем длиннее цепочка условных зависимостей (от последнего хода — к двум, трём, восьми), тем хуже модель их держит, даже если правило выписано в промпте явно.
Метод здесь не предлагается, это скорее предупреждение и способ проверки: сравнивай не «похоже ли в среднем», а «выполняется ли правило на каждом шаге». Если ты задаёшь модели один ход за раз и показываешь настоящую историю (в статье это teacher forcing, «подсказка правильной истории»), сильные модели справляются заметно лучше, чем при свободной генерации длинной цепочки.
Схема проверки
Это выводы статьи в виде рабочей проверки, а не авторский метод:
ШАГ 1: Выпиши правила явно: «если было X → сделай Y» → список правил
ШАГ 2: Сгенерируй цепочку (диалог, последовательность) → текст
ШАГ 3: Для КАЖДОГО шага проверь: следует ли ход из предыдущего по правилу → таблица «шаг / условие / ожидалось / получено»
ШАГ 4: Посчитай долю нарушений (не среднее «похоже/не похоже») → процент
ШАГ 5: Если нарушений много → генерируй по одному ходу, подавая историю заново
Шаги 2–3 можно сделать в одном чате. Шаг 5 требует нескольких запросов подряд.
Пример применения
Задача: Ты делаешь тренажёр для менеджеров по продажам в стиле «Тинькофф Бизнес»: модель играет капризного клиента. Правила: если менеджер предлагает скидку, клиент просит ещё больше. Если менеджер отказывает, клиент говорит «ухожу к конкурентам». Если менеджер молчит или задаёт вопрос, клиент раздражается. Нужно убедиться, что «клиент» не ломает правила на десятом сообщении.
Промпт:
Ты играешь роль клиента в диалоге с менеджером по продажам CRM для малого бизнеса.
ПРАВИЛА клиента (строго, без исключений):
R1. Если менеджер предложил скидку → клиент просит скидку ещё больше.
R2. Если менеджер отказал в скидке → клиент пишет «ухожу к конкурентам».
R3. Если менеджер задал вопрос → клиент отвечает раздражённо и коротко.
Сыграй 12 реплик клиента подряд на таких ходах менеджера:
1) «Здравствуйте, чем могу помочь?»
2) «Могу предложить скидку 10%.»
3) «К сожалению, больше скидки дать не можем.»
4) «А какой у вас сейчас бюджет?»
... (ещё 8 ходов менеджера)
После каждой реплики клиента в скобках укажи: [правило: R1/R2/R3, ход менеджера: ...].
В конце выведи таблицу: № хода | какое правило должно сработать | что сделал клиент | нарушение (да/нет).
Посчитай долю нарушений.
Результат: Модель выдаст диалог с пометками правил. Затем таблица по каждому ходу и итоговый процент нарушений. Вероятнее всего, часть реплик не будет соответствовать правилу: например, клиент смягчится там, где R2 требует угрозы. Видно это только в пошаговой таблице, на общее впечатление «диалог живой» полагаться нельзя.
Почему это работает
Слабость: модель обучена выдавать правдоподобный текст, а не точно исполнять условные правила. Правдоподобная цепочка выглядит нормально по общим пропорциям: столько-то отказов, столько-то просьб. Но модель не ведёт «в голове» таблицу «что было → что делать». Чем больше предыдущих шагов нужно учитывать одновременно, тем хуже это получается.
Сильная сторона: на одном локальном шаге, когда история перед глазами и нужно лишь выбрать следующий ход, сильные модели справляются хорошо. В статье при подсказке правильной истории самая сильная модель (reasoner) попадала в правило примерно в 93% случаев, а слабая — только примерно в половине. Значит, ошибки частично копятся при длинной генерации, а частично модель вообще не может применить правило.
Как использовать: проверяй по шагам, а не по среднему. Если нарушений много, дроби генерацию: один ход за запрос, правило каждый раз в промпте, история — настоящая. Рычаги: - Число правил и глубина условия (от последнего хода, от двух последних, от пары ходов обоих игроков): чем меньше, тем надёжнее. - Явная пометка «какое правило сработало» в каждой реплике: делает нарушения видимыми. - Размер истории: не сваливай в промпт 1000 примеров ради «лучшего понимания». В статье это не помогало и часто вредило. - Сила модели: слабая модель ломает правила уже на локальном шаге.
Шаблон промпта
Это шаблон аудита, выведенный из находок статьи. Авторы его не предлагали.
Роль: ты играешь {роль} в ситуации {контекст}.
ПРАВИЛА (применяй строго, на каждом шаге):
R1. Если {условие_1} → {действие_1}.
R2. Если {условие_2} → {действие_2}.
R3. Если {условие_3} → {действие_3}.
Ходы собеседника:
{список_ходов}
Для каждого хода собеседника:
1. Назови, какое правило сработало (R1/R2/R3) и почему.
2. Дай реплику, которая ему следует.
В конце выведи таблицу: № | ход собеседника | сработавшее правило | реплика | нарушение (да/нет).
Посчитай долю нарушений. Если нарушения есть — перечисли, где именно.
Подставляй:
- {роль}, {контекст}: кого играет модель и где;
- {условие_N} и {действие_N}: короткие, однозначные правила «если ... → ...»;
- {список_ходов}: заранее заданные ходы собеседника (это и есть «подсказка правильной истории»).
Ограничения
⚠️ Игрушечная среда: опыты проведены на «камень-ножницы» и на цепочках символов с чёткими формальными правилами. Реальные диалоги и поведение клиентов мягче и многограннее. Перенос выводов на них не проверен.
⚠️ Одна модель в самых сложных опытах: детальный разбор сложных структур делали на одной сильной модели. Идентификацию тестировали шире, на нескольких. Универсальность вывода о сложных условиях не доказана.
⚠️ Решений почти нет: авторы показали, где модели ломаются, и диагностировали это (подсказка правильной истории, сравнение с алгоритмом). Готового промпта, который чинит проблему, в статье нет. Явные правила в промпте для высоких порядков зависимости не спасали.
⚠️ Нужна проверка кодом или руками: надёжно посчитать долю нарушений на длинных цепочках без таблицы или скрипта сложно.
⚠️ Текст статьи обрезан: часть результатов по сложным структурам (Exp. 3, высокие порядки) в доступном материале приведена не полностью.
Как исследовали
Идея простая: взять игру, где известно, по какому правилу ходит каждый игрок, и проверить, понимает ли модель это правило, а не только «в среднем». Выбрали «камень-ножницы» с двумя типами игроков: статистические (бросают по фиксированным вероятностям) и «марковские» (ход зависит от предыдущего хода соперника или от пары ходов). Модели дали историю в 100, 200, 500 или 1000 раундов и просили назвать стратегии. Позже просили ещё и продолжить игру на 1000 раундов.
Результаты вышли неожиданными. Во-первых, длинная история не помогала: точность угадывания падала, хотя обычный алгоритм максимального правдоподобия находил стратегию в 100% случаев. Значит, дело не в нехватке информации, а в том, что модель не извлекает из неё правило. Во-вторых, верное распознавание не гарантировало верное выполнение. А среди 282 неверно угаданных стратегий у 42% распределение ходов всё равно почти совпало с целевым. Так правдоподобие маскирует неправильный механизм. В-третьих, при подсказке правильной истории сильные модели отвечали точно (reasoner 93%, GPT-5 83%), а слабые (GPT-5-mini 54%, DeepSeek Chat 53%) ошибались и локально.
В конце авторы убрали игру и взяли одиночную задачу продолжения цепочек символов с зависимостью до восьмого порядка. Деградация сохранилась даже с длинным префиксом и явно записанными правилами, а простой счётчик по префиксу остался стабильным. Вывод для практики: правдоподобно выглядящая симуляция не доказывает, что модель держит правило.
Адаптации и экстраполяции
💡 Адаптация для генерации тестовых данных: вместо клиента симулируй пользователей сайта.
Сгенерируй 30 последовательных действий пользователя интернет-магазина (Ozon-подобного).
Правила: после «добавил в корзину» следующее действие — «оформление» с вероятностью 70%, иначе «ушёл».
После «ушёл» следующее действие всегда «вернулся через 1–2 дня и просмотрел похожий товар».
После каждого действия укажи [правило: ...].
Потом посчитай: сколько раз правило нарушено.
🔧 Техника: один ход за запрос → меньше накопления ошибок
Вместо «сыграй 12 реплик» подавай каждый ход менеджера отдельным сообщением и напоминай правила:
История диалога: {история}. Правила: R1–R3 (см. выше).
Ход менеджера: «{ход}». Выдай ТОЛЬКО реплику клиента и номер правила.
Это приближает к режиму «подсказка правильной истории» из статьи: ошибки не копятся и видны сразу. Это вариация по мотивам диагностики авторов, а не проверенный ими метод.
Ресурсы
- Работа: Do LLMs Understand Sequential Structure? A Controlled Study of Inference and Generation
- Авторы: Jerry Wang (University of Illinois Urbana-Champaign); Zhengxiang Wang, Tengfei Ma (Stony Brook University); Ting Yu Liu, Hsin-Ling Hsu, Yi-Cheng Lai (National Chengchi University)
- Связанные работы: про LLM как симуляторы поведения (Park et al., 2023), игры как среда проверки стратегического мышления (Akata et al., 2024), обучение в контексте как байесовский вывод (Xie et al., 2022)