TL;DR
Исследователи тестировали, как разные способы организации работы LLM влияют на качество долгих интерактивных историй — там, где каждый шаг меняет мир, и это важно помнить дальше. Механика в основе: перед тем как писать очередную сцену, отдельным шагом просят модель составить короткий план (до 12 пунктов), а после сцены — отдельным шагом фиксируют, что изменилось в мире (факты, отношения, состояния персонажей), и эту "картотеку" передают в следующий шаг.
Главная находка неприятная: точность в фактах и насыщенность сюжета конфликтуют друг с другом, и это не плавный компромисс. Модель может писать живо и с поворотами, но через десятки шагов начинает путать, кто кому что обещал или кто где находится. Или наоборот — держит все факты идеально, но сюжет стоит на месте. При этом более крупная и мощная модель решает только одну проблему — она дольше не "затыкается" и продолжает генерировать текст, но не становится точнее в фактах и не пишет интереснее.
Суть метода — не просить одну модель тащить всю историю разом, а разбить работу на три отдельных шага: (1) план сцены на несколько ходов вперёд, (2) сама сцена-текст, (3) явная фиксация изменений канона после сцены. Дополнительно можно решить, как модель обрабатывает действия персонажей: один рассказчик решает всё сам, один агент придумывает действия сразу для всех NPC, или у каждого NPC свой отдельный "голос" — это даёт рычаг между насыщенностью и предсказуемостью.
Схема метода
ШАГ 1 (опционально, план):
Взять попытку игрока + текущее состояние мира
→ Составить план сцены из ≤12 связанных пунктов (что должно произойти)
ШАГ 2 (основной, всегда):
Написать сцену-продолжение по плану
→ Текст сцены + варианты действий для игрока
ШАГ 3 (опционально, память):
Сравнить новую сцену с прежним состоянием мира
→ Список изменений: новые факты, изменившиеся отношения, состояния персонажей
→ Обновить "картотеку" мира для следующего шага
Отдельно — кто решает, что делают NPC (не связано с шагами 1-3, это про "актёров"): - Вариант A: один рассказчик сам придумывает действия всех NPC - Вариант B: один агент придумывает действия сразу для всех NPC - Вариант C: у каждого NPC свой отдельный проход через модель — свой "голос"
Каждый шаг можно выполнять либо в одном длинном промпте, либо как отдельные запросы — в исследовании это были отдельные вызовы модели.
Пример применения
Задача: Вы ведёте интерактивный сериал в Telegram — подписчики голосуют, что делает герой в каждой главе. История растягивается на 30-40 глав. Проблема: к 20-й главе вы (и модель) забываете, кто кому что обещал, кто с кем враждует, у кого какая травма.
Промпт (шаг 1 — план):
Ты — сценарист интерактивной истории. Вот текущая картотека мира:
{картотека: персонажи, отношения, факты, где кто находится}
Подписчики выбрали действие героя: {выбранное действие}
Составь план следующей главы: до 8 пунктов, что должно произойти.
Учитывай текущие отношения и факты. Не придумывай новых персонажей.
Промпт (шаг 2 — сцена):
Напиши главу истории по этому плану:
{план из шага 1}
Стиль: {твой стиль — например, мрачный нео-нуар, как "Пиковая дама"}
Заверши двумя вариантами действия для голосования подписчиков.
Промпт (шаг 3 — память):
Сравни новую главу с прежней картотекой мира:
{прежняя картотека}
{новая глава}
Выпиши только ИЗМЕНЕНИЯ: новые факты, изменившиеся отношения,
новые обещания, смену локаций. Не пересказывай главу.
Верни обновлённую картотеку целиком.
Результат: после трёх шагов у вас на руках — сцена для публикации и обновлённая картотека мира (короткий список фактов), которую вы вставляете в следующий цикл вместо того, чтобы надеяться, что модель сама помнит 20 глав назад. К главе 30 у вас будет живой "документ памяти", а не каша в голове модели.
Почему это работает
Модель, которая пишет длинный текст за один проход, держит в фокусе только то, что явно есть перед глазами в контексте. Она не умеет сама лезть назад и сверяться с фактом, установленным 40 сообщений назад — она попросту не "помнит" в человеческом смысле, она предсказывает следующий текст, опираясь на то, что видит сейчас.
Зато модель отлично справляется с узкой конкретной задачей за один вызов: составить план из нескольких пунктов, написать сцену по готовому плану, или сравнить два текста и найти разницу. Каждая из этих задач — простая и локальная.
Метод берёт одну сложную задачу ("веди историю 30 глав без противоречий") и режет её на три простые, для каждой из которых у модели есть шанс справиться. А "картотеку" фактов передают явно, текстом, а не надеются, что модель сама её удержит в голове.
Рычаги управления: - Число пунктов в плане (до 12 в оригинале) — уменьши для коротких динамичных сцен, увеличь для развёрнутых глав - Отдельный агент на каждого персонажа (вариант C) — сюжет живее и непредсказуемее, но выше риск противоречий. Используй, когда насыщенность важнее точности - Один рассказчик решает всё (вариант A) — надёжнее для канона, но скучнее. Используй для сюжетов, где важна точность (детектив, где улики должны сходиться) - Частота обновления картотеки — обновляй после каждой сцены с сюжетным поворотом, реже — после проходных сцен, чтобы не раздувать текст
Шаблон промпта
Ты ведёшь долгую интерактивную историю. У тебя есть картотека мира —
короткий список фактов, который нужно поддерживать в точности.
КАРТОТЕКА МИРА:
{персонажи, их отношения, локации, ключевые обещания и факты}
ПОСЛЕДНЕЕ ДЕЙСТВИЕ ИГРОКА: {действие}
Шаг 1 — План: составь план следующей сцены из {число} пунктов.
Опирайся только на факты из картотеки, не придумывай новых персонажей.
Шаг 2 — Сцена: напиши сцену по плану. Стиль: {стиль}.
Заверши {число} вариантами действия для игрока.
Шаг 3 — Обновление: сравни написанную сцену с картотекой выше.
Выпиши только изменения (новые факты, отношения, локации).
Верни обновлённую картотеку целиком для следующего шага.
Подставь: {персонажи...} — твоя картотека мира (обновляется каждый раз), {действие} — что выбрал игрок/подписчики, {число} — количество пунктов плана и вариантов действия, {стиль} — тон истории.
🚀 Быстрый старт — вставь в чат:
Вот шаблон для ведения долгой интерактивной истории через LLM.
Адаптируй под мою задачу: {твоя задача — например, "текстовая RPG-кампания
для друзей" или "интерактивный сериал в Telegram"}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про стиль истории, начальных персонажей и их отношения, формат голосования — потому что без этого не получится собрать первую "картотеку мира", с которой начнётся цикл план→сцена→обновление.
Ограничения
⚠️ Размер модели не спасает: даже самые мощные модели не становятся точнее в фактах и не пишут интереснее — они просто дольше не "спотыкаются" и продолжают генерировать текст.
⚠️ Структура не гарантирует согласованность: добавление плана и памяти может обогатить сюжет, но не всегда улучшает точность в фактах — а иногда даже укорачивает историю, потому что модель раньше решает, что сюжет "закончен".
⚠️ Насыщенность и точность конфликтуют: нельзя получить максимум того и другого одновременно — придётся выбирать баланс под свою задачу (детектив требует точности, приключение — насыщенности).
⚠️ Метод требует ручной дисциплины: тебе придётся самому вести и передавать картотеку фактов между сообщениями (в отдельном файле или заметке) — модель сама этого делать не будет, если ты не встроишь это в цикл.
Ресурсы
WSE-bench (When Stories Evolve Benchmark). Авторы: Yuqi Chen, Sixuan Li, Yunfeng Cai, Xueai Li, Ka Man Yan, Ying Li. University of Hong Kong, Peking University, Tsinghua University, Beijing Institute of Mathematical Sciences and Applications (BIMSA).