TL;DR
Большинство современных LLM теряются на предложениях типа «Алиса готовит, а Боб ест еду». Не потому что задача сложная — а потому что такое предложение требует одновременно двух привязок (кто → что делает) на одном токене. Это выше возможностей архитектуры большинства моделей. Провалились GPT-4o, Claude Sonnet-3.5, Gemini-2.5 Flash, Qwen3-235B, DeepSeek-V3.2. Справились только самые новые: Claude Opus-4.5 и Gemini-3-Pro.
Главная находка: LLM внутри хранят информацию о персонажах в двух независимых «слотах» — текущий (кто описывается прямо сейчас) и предыдущий (кто был перед ним). Эти слоты работают в разных направлениях внутри модели и не мешают друг другу. Предыдущий слот используется для сравнений соседних персонажей: кто шёл после Алисы, есть ли противоречие между соседними. Но для прямых фактических вопросов («Кто высокий?», «Как зовут весёлого?») модель использует только текущий слот — даже когда нужная информация в предыдущем тоже есть.
Это практическая карта ошибок: если промпт требует от модели отследить двух персонажей через одно предложение — ждите сбоев. Решение простое: одно предложение = один персонаж = одна привязка. Описывайте каждого отдельно, используйте явные простые конструкции. Это не стилистика — это работа в рамках архитектурного ограничения модели.
Схема: что работает и что ломается
❌ ЛОМАЕТСЯ (двойная привязка на одном токене):
"Алиса готовит, а Боб ест еду."
→ Одно предложение, два субъекта, один объект
→ Модель не может одновременно хранить оба binding'а
✅ РАБОТАЕТ (одна привязка на предложение):
"Алиса готовит еду."
"Боб ест еду."
→ Каждый персонаж в своём предложении → надёжная привязка
✅ РАБОТАЕТ (сравнение соседних):
"Кто шёл в списке после Алисы?"
"Есть ли противоречие между соседними персонажами?"
→ Задействует prior-entity slot → работает хорошо
❌ НЕНАДЁЖНО (явное извлечение из прошлого):
Длинный список → затем "Кто из первых трёх был смелым?"
→ Первый персонаж держится дольше других, остальные угасают
Все шаги — в одном чате, структурируются на этапе написания промпта.
Пример применения
Задача: Пишешь промпт для разбора питч-дека — просишь Claude сыграть роль сразу нескольких «персонажей»: Артёма Сенаторова (контент-стратег), Фёдора Овчинникова (предприниматель-практик), Ги Кавасаки (венчурный взгляд). Нужно, чтобы каждый оценил идею по-своему, и модель не путала их позиции.
Промпт:
Ты разыгрываешь мозговой штурм с тремя экспертами. Они дают оценку по очереди.
Эксперт 1 — Артём Сенаторов.
Его фокус: насколько идея производит контент сама по себе, есть ли вирусный потенциал.
Его слабость: может недооценивать операционные сложности.
Эксперт 2 — Фёдор Овчинников.
Его фокус: реальность исполнения, юнит-экономика, первые 100 клиентов.
Его слабость: скептик, занижает рыночный потенциал.
Эксперт 3 — Ги Кавасаки.
Его фокус: масштаб рынка, простота питча, «10x улучшение».
Его слабость: игнорирует локальную специфику.
Идея: [Опиши свою идею в 2–3 предложениях.]
Пусть каждый эксперт по очереди скажет ровно 3 предложения — своим голосом, со своей позицией.
После — одно итоговое расхождение: в чём главное противоречие между их оценками?
Результат: Модель выдаст три чётких блока — по одному от каждого эксперта — в стиле каждого персонажа. Финал: явное указание на ключевое противоречие во мнениях. Каждый персонаж описан отдельным блоком → модель не смешивает их позиции и атрибуты.
Почему это работает
LLM не хранит «базу данных» персонажей с произвольным доступом. Это скорее скользящее окно: хорошо видно текущего персонажа и предыдущего. Дальше — размыто, кроме самого первого (он обычно держится дольше остальных).
Когда предложение вынуждает модель одновременно обработать двух персонажей — она физически не может: у токена есть место только для одной «текущей» привязки плюс одной «предыдущей». Авторы проверили: нужная информация технически закодирована в активациях, но модель её не использует для явного ответа на вопрос. Грубо: данные есть, но доступа к ним нет.
Простое решение — раздать каждому персонажу собственные предложения. Тогда каждая привязка попадает в свой «текущий слот», и модель обращается к нужной информации напрямую. Плюс: информация из пользовательских сообщений сохраняется глубже в разговоре, чем из ответов ассистента. Если хочешь, чтобы описание персонажей помнилось дольше — давай его сам, а не проси модель сгенерировать.
Шаблон промпта
Вот {число} участников / персонажей / ролей.
{Имя 1}: {Одно-два предложения — кто это, что его отличает. Только об этом персонаже.}
{Имя 2}: {Одно-два предложения — кто это, что его отличает. Только об этом персонаже.}
{Имя 3}: {Одно-два предложения — кто это, что его отличает. Только об этом персонаже.}
Задача: {Что нужно сделать — оценить / сравнить / обсудить}.
Правило: каждый говорит от своего имени, своим голосом. Не смешивай позиции.
Плейсхолдеры:
- {число} — сколько персонажей/ролей
- {Имя N} — имя или роль
- Описание каждого — отдельным блоком, без соединительных «а также», «и»
- {Задача} — что ты хочешь получить от взаимодействия персонажей
Ключевой принцип: никаких конструкций «X делает одно, а Y — другое с тем же объектом» в одном предложении. Всегда разбивай.
🚀 Быстрый старт — вставь в чат:
Вот шаблон для работы с несколькими персонажами/ролями в промпте.
Адаптируй под мою задачу: [опиши свою задачу].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит: сколько персонажей, кто они, какая задача — потому что шаблон структурирован под чёткое описание каждого отдельно. Она возьмёт паттерн из шаблона и адаптирует под твой контекст.
Почему это работает — механика
LLM не «думает» о персонажах как людях. Она генерирует текст, опираясь на паттерны в активациях токенов. Каждый токен несёт в себе «сжатую память» о пройденном контексте — но не равномерно.
Ключевое открытие: в активациях выделяются два специализированных направления — одно для текущего, другое для предыдущего персонажа. Они почти не пересекаются (корреляция ~0.11), то есть это действительно разные каналы хранения. Предыдущий канал работает хорошо для относительных задач (кто шёл после кого, есть ли противоречие между соседними). Но для прямых вопросов о конкретных атрибутах модель игнорирует предыдущий канал — даже когда там есть ответ.
Рычаги управления: - 🔧 Количество персонажей: чем меньше, тем надёжнее. 4–5 хорошо, 8+ — начинают размываться средние - 🔧 Порядок: самый важный персонаж — первый (держится дольше) или последний (текущий слот, самый сильный) - 🔧 Разбивка предложений: дроби сложные предложения о двух персонажах на простые — это не стилистика, это надёжность - 🔧 Кто описывает: описывай персонажей сам в своих сообщениях, не проси модель — твои сообщения дольше сохраняются в её представлении
Ограничения
⚠️ Только граничные модели: Принцип о двойных привязках актуален для большинства моделей. Claude Opus-4.5 и Gemini-3-Pro уже справляются с такими предложениями — возможно, у них другие механизмы. Проверяй на своей версии.
⚠️ Не панацея от потери персонажей: Раздельные описания снижают ошибки, но не устраняют их полностью при очень длинных разговорах с множеством персонажей.
⚠️ Соседние vs. далёкие: Сравнивать двух соседних персонажей — надёжно. Сравнивать первого и пятого в длинном списке — уже сложнее.
⚠️ Явное извлечение атрибутов: «Кто из всех был смелым?» — ненадёжно при большом списке. Лучше задавать вопрос сразу после описания персонажа, пока он ещё «текущий».
Как исследовали
Команда из программы Anthropic Fellows взяла 10 000 промптов с описанием восьми персонажей — каждый с одной из 15 черт характера (смелый, аналитичный, творческий и т. д.). Описания генерировал Claude Sonnet-4.5, по четыре предложения на персонажа. Затем авторы вытащили внутренние активации токенов (состояние нейросети в момент обработки) и обучили специальный зонд — детектор, который принимает на вход одно состояние токена и пытается угадать черты сразу нескольких персонажей одновременно.
Хитрость в архитектуре зонда: вместо одного классификатора — несколько параллельных с маршрутизатором. Маршрутизатор сам решает, какой классификатор использовать для какого персонажа на каком токене. Это позволило обнаружить, что модель кодирует «красный квадрат» на токене «красный» иначе, чем «красный квадрат» на следующем токене «синий круг» — разными направлениями в пространстве активаций.
Самый неожиданный результат: информация о предыдущем персонаже физически присутствует в активациях — зонд её легко читает. Но когда задаёшь прямой вопрос («Как зовут высокого?»), модель к этой информации не обращается. Информация есть — доступа нет. Это как если бы книга лежала на полке, но библиотекарь о ней не знает и не выдаёт. Авторы также провели патчинг-эксперименты — подменяли активации одного промпта активациями другого, чтобы проследить причинно-следственные связи, а не просто корреляции.
Адаптации и экстраполяции
🔧 Техника: Явное «закрепление» атрибутов → надёжнее при явном извлечении
Если нужно, чтобы модель точно вспомнила атрибут конкретного персонажа позже — повтори привязку перед вопросом:
[После длинного описания всех персонажей]
Напоминание: Игорь — смелый. Лена — аналитичная. Саша — творческий.
Вопрос: Кто из них лучше подойдёт для роли лидера в кризисной ситуации?
Это не дублирование ради дублирования — ты переводишь нужного персонажа в «текущий слот» прямо перед вопросом, где модель точно его использует.
🔧 Техника: Первый персонаж = «якорь» длинного контекста
Поскольку первый персонаж сохраняется наиболее устойчиво, используй это при структурировании:
Главный критерий/принцип (назовём его "Принцип Федора"):
[Опиши главный стандарт оценки или ключевой контекст]
Далее список для анализа через этот принцип:
1. ...
2. ...
«Принцип Федора» в начале будет устойчиво удерживаться в представлениях модели на протяжении всей беседы.
Ресурсы
Slot Machines: How LLMs Keep Track of Multiple Entities Paul C. Bogdan, Jack Lindsey Anthropic Fellows Program, Anthropic Контакт: paulcbogdan@gmail.com
Связанные концепции упомянутые в работе: linear probes (линейные зонды для интерпретации активаций), induction heads (механизм предсказания по паттерну [A][B]→[B]), activation steering (управление поведением модели через модификацию активаций), residual stream (поток активаций через слои трансформера).