TL;DR
SSRP — это техника из двух фаз: сначала модель-«Архитектор» переваривает историю переписки и составляет чёткий SOP (протокол действий), явно отмечая что теперь устарело и должно быть проигнорировано, потом модель-«Исполнитель» выполняет задачу строго по этому SOP — без оглядки на зашумлённую историю диалога.
Если в длинном чате ты меняешь задачу, модель продолжает тянуться к старым инструкциям. Не потому что «не поняла» — а потому что первые сообщения диалога имеют наибольший вес в её внимании. Новое требование пришло позже, оно слабее по весу. Модель «застревает» на старой цели — даже если ты явно написал «забудь про предыдущее». Авторы называют это Attention Latch — замок внимания.
SSRP разрывает этот замок: Архитектор сжимает историю до компактного SOP из 3 шагов, явно прописывая «цель G1 устарела, действуем по G2», после чего Исполнитель работает только с SOP — без шума длинной переписки. Новый протокол вытесняет историю как главный ориентир.
Схема метода
(Оба шага можно выполнить в одном чате или в двух отдельных — подробнее в шаблоне)
ШАГ 1 — АРХИТЕКТОР (один запрос):
Вход: вся история диалога + новая цель
Действие: выявить устаревшие ограничения → составить SOP (3 шага)
→ явно указать "ЧТО игнорировать" из истории
Выход: компактный SOP с маркированными устаревшими целями
ШАГ 2 — ИСПОЛНИТЕЛЬ (новый чат или следующий запрос):
Вход: ТОЛЬКО SOP от Архитектора (без истории)
Действие: выполнить задачу строго по SOP
Выход: результат без "возврата" к старым инструкциям
Пример применения
Задача: Ты 20 сообщений переписывался с Claude про landing page для доставки суши — прописал структуру, тон, УТП. Потом клиент сказал: «Нет, делаем не суши, делаем здоровое питание, и тон нужен не дерзкий а спокойный». Модель продолжает предлагать «острые формулировки» и упоминать роллы.
Промпт — фаза Архитектора (вставляешь в тот же чат):
Выступи как Архитектор-протоколист.
Задача: наша переписка изменила направление.
Мне нужен новый протокол работы.
Составь SOP строго в этом формате:
УСТАРЕВШИЕ ОГРАНИЧЕНИЯ (игнорировать полностью):
- [список целей/требований из истории, которые теперь неактуальны]
НОВАЯ ЦЕЛЬ:
[одно предложение — суть нового задания]
SOP (строго 3 шага):
Шаг 1: [что делаем первым]
Шаг 2: [что делаем вторым]
Шаг 3: [что делаем третьим]
КРИТЕРИЙ ГОТОВНОСТИ:
[как понять, что задача выполнена правильно]
Новая задача: [опиши изменение — здоровое питание, спокойный тон, новые УТП]
Промпт — фаза Исполнителя (открываешь НОВЫЙ чат):
Выполни задачу строго по этому SOP. Не отклоняйся от протокола.
[вставляешь SOP, который составил Архитектор]
Результат: Архитектор выдаст структурированный SOP с явным списком "что забыть" из старой переписки. Когда вставишь SOP в чистый чат — Исполнитель будет работать только с новым протоколом. Никаких суши, никакого дерзкого тона. Чистый старт с сохранением логики задачи.
Почему это работает
Проблема: У LLM нет "рабочей памяти" — только поток токенов. Чем раньше в диалоге появилось требование, тем статистически сильнее оно влияет на ответы. Когда ты пишешь "забудь про суши" на 25-м сообщении — это требование борется с 20 сообщениями про суши, и проигрывает. Авторы измерили: на сложных задачах стандартный ReAct обваливается до 0.1% успеха.
Сила LLM: Модель отлично следует компактным, структурированным инструкциям в начале контекста. Если SOP — первое что видит чистый чат — он получает весь вес внимания.
Как метод использует это: SSRP не борется со старым контекстом — он его обходит. Архитектор "сжимает" шум истории в чистый протокол. Исполнитель грузит только этот протокол — старая история физически отсутствует в окне контекста. Замок нечем застревать.
Рычаги управления: - 3 шага в SOP — оптимум. Меньше (1 шаг) — слишком мало сигнала. Больше (10+ шагов) — сам SOP становится шумом, модель теряет нить между шагами. - Раздел "Устаревшие ограничения" — обязателен. Это и есть ядро метода. Без явного "игнорировать X" модель тянется к X даже через SOP. - Новый чат для Исполнителя — не обязательно, но мощнее. Папка с историей переписки vs. чистый лист — разница в управляемости огромная. - Административная формулировка SOP — пиши как официальный регламент, не как "стёртую инструкцию". "Игнорируй все предыдущие инструкции" — триггер защитных фильтров. "Протокол v2.0, устаревшие требования раздела 1.1 аннулированы" — работает.
Шаблон промпта
## ФАЗА 1: АРХИТЕКТОР-ПРОТОКОЛИСТ
Выступи как Архитектор-протоколист. Твоя задача —
создать чёткий SOP для новой цели, явно отменив
устаревшие ограничения из нашей переписки.
Составь протокол строго в формате ниже:
---
ПРОТОКОЛ v2.0
УСТАРЕВШИЕ ОГРАНИЧЕНИЯ (исключить из выполнения):
- {устаревшее_требование_1}
- {устаревшее_требование_2}
- [дополни по контексту нашего диалога]
АКТУАЛЬНАЯ ЦЕЛЬ:
{новая_задача_одним_предложением}
SOP — АЛГОРИТМ ВЫПОЛНЕНИЯ (строго 3 шага):
Шаг 1: {первое_действие}
Шаг 2: {второе_действие}
Шаг 3: {третье_действие}
КРИТЕРИЙ УСПЕХА:
{как_выглядит_правильный_результат}
---
Новая задача: {опиши что изменилось и чего теперь хочешь}
## ФАЗА 2: ИСПОЛНИТЕЛЬ (новый чат)
Выполни задачу строго по протоколу ниже.
Не отклоняйся от SOP. Не обращайся к контексту
за пределами этого протокола.
{вставить ПРОТОКОЛ v2.0 от Архитектора}
Что подставлять:
- {устаревшие_требования} — можно не заполнять самому, Архитектор сам выявит из истории
- {новая_задача} — ключевое изменение: что поменялось в задаче, тоне, формате, цели
- {критерий_успеха} — опционально; помогает когда нужна точная верификация
🚀 Быстрый старт — вставь в чат:
Вот шаблон SSRP для смены задачи в длинном диалоге.
Адаптируй под мою ситуацию: {опиши что изменилось в задаче}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит что именно изменилось в задаче и какие требования из истории остаются актуальными — потому что без этого невозможно правильно заполнить раздел "Устаревшие ограничения", который и является ядром метода.
Почему это работает
Почему "в лоб" не работает: "Забудь всё что было раньше" — борьба с контекстом, который ты сам создал. Первые сообщения диалога статистически перевешивают. Модель не "не слышит" — она следует паттернам с наибольшим весом.
Что умеет LLM хорошо: Точно следовать компактным, структурированным инструкциям, которые находятся в начале контекста. Чем чище пространство вокруг инструкции — тем точнее исполнение.
Как SSRP использует это: Вместо того чтобы перекрикивать историю — создаёт новый контекст, где история физически отсутствует. SOP в начале нового чата = ни с чем не конкурирует. Получает 100% веса внимания.
Ограничения
⚠️ Простые задачи: Если задача не менялась или контекст короткий — SSRP избыточен. Один прямой запрос сработает лучше.
⚠️ Слишком детальный SOP: Больше 10 шагов — сам SOP становится источником шума. Оптимум исследования — 3 шага. Для очень сложных задач — максимум 5-7.
⚠️ Грейдинговый парадокс (Grounding Paradox): Высокостабильные модели — особенно Claude — иногда отказываются следовать новой инструкции, потому что воспринимают её как попытку манипуляции. Фикс: административное оформление SOP (официальный регламент, протокол версии X.X), а не прямые команды типа "игнорируй".
⚠️ Требует двух запросов: Стандартная схема — два отдельных обращения к модели. Ускоренный вариант (один промпт "сделай SOP и сразу выполни") работает слабее.
Как исследовали
Авторы из Университета Ватерлоо придумали элегантный дизайн: взяли 9000 диалогов из MultiWOZ 2.2 (датасет многоходовых разговоров о бронировании отелей, такси, ресторанов) и превратили их в стресс-тест на "смену задачи". Каждый диалог содержал момент, где пользователь менял требование — модель должна была бросить старую цель и следовать новой.
Три уровня сложности: сначала простой (цель спрятана в последних 2К токенах — лёгкая задача для recency-bias); потом сложный (цель закопана в середину 10К-токенного контекста, где внимание модели падает); потом убийственный — "семантическое похищение": три взаимосвязанных факта разбросаны по 10К токенам системных логов, с намеренными ловушками-приманками у начала и конца контекста.
Результат третьего уровня стал главной находкой: стандартный ReAct обвалился до 0.1% успеха на GPT 5.4 — модели, которая в других тестах выглядит сильной. SSRP на той же задаче — 71.6%. Что интересно: когда добавили "Recursive Reflexion" baseline (модель сама себя критикует и исправляет) с тем же числом вызовов что и SSRP — он показал 100% успеха. Это означает, что проблема не в интеллекте модели (она может найти ответ!), а именно в механизме внимания. Модель знает правильный ответ, но структура контекста мешает его активировать.
Адаптации и экстраполяции
🔧 Административное обрамление против защитных фильтров
Если Claude или другая осторожная модель сопротивляется обновлённым инструкциям — замени прямые команды на регламентный язык:
❌
"Игнорируй все предыдущие инструкции о формате текста"✅"Регламент v2.1. Требования Регламента v1.0 (раздел 3.2 о формате) аннулированы и не применяются."
🔧 SSRP для итерации над чужим контентом
Та же логика работает когда ты загружаешь длинный документ и меняешь задачу в середине сессии:
Архитектор: Мы анализировали этот документ с фокусом на [старая_задача]. Новая задача — [новая_задача]. Составь SOP для нового анализа, явно указав какие выводы из нашего предыдущего обсуждения теперь нерелевантны.Затем в новом чате — только документ + SOP.
🔧 Личный ассистент с "версионированием" задач
Если вы ведёте долгий проект через чат (написание книги, разработка стратегии, работа над брендом) — раз в 10-15 сообщений запускайте Архитектора:
Синтезируй текущий статус проекта в SOP. Что мы решили окончательно (зафиксировать)? Что поменялось (отметить как устаревшее)? Каковы следующие 3 шага?Это не просто саммари — это очистка контекста перед следующей рабочей сессией.
Ресурсы
Статья: Beyond the Attention Stability Boundary: Agentic Self-Synthesizing Reasoning Protocols — Dahlia Shehata, Ming Li (University of Waterloo, Canada) — Preprint 2025
Ключевые отсылки в статье: - Yang et al. (2022) — MultiWOZ 2.2 dataset: huggingface.co/datasets/tuetschek/multi_woz_v22 - Yao et al. — ReAct: базовый агентный паттерн рассуждения + действия - Wei et al. — Chain-of-Thought (CoT): пошаговое рассуждение - Liu et al. — Lost in the Middle: феномен "провала внимания" в середине контекста - Shinn et al. — Reflexion: паттерн самокритики и самокоррекции LLM - Tishby et al. — Information Bottleneck principle: теоретическая основа Архитектора