TL;DR
DREAM — исследование показывающее как цепочки простых шагов с общей памятью обходят защиты LLM-агентов. Система строит последовательности из трёх типов действий: Scout (разведка — собирает информацию), Seeder (подготовка — создаёт условия), Exploiter (эксплуатация — достигает цели). Ключевая механика: Cross-Environment Adversarial Knowledge Graph (CE-AKG) — граф знаний, который связывает информацию между разными контекстами. Информация, собранная в одном окружении, используется для действий в другом.
Исследование выявило две критичные слабости современных агентов. Первая — контекстная хрупкость: защитные механизмы не переносятся между окружениями. Агент, который отказывается выполнять действие напрямую, выполнит его, если запрос придёт из другого контекста. Вторая — неспособность отслеживать долгосрочные намерения: агенты не видят связи между безобидными шагами, растянутыми во времени. Каждый шаг кажется безопасным, но вместе они дают опасный результат. Многошаговые атаки успешны в 70%+ случаев против большинства моделей, при том что изолированные атаки проваливаются.
Метод работает через эффект домино: каждый шаг создаёт условия для следующего. Scout собирает данные (например, ID клиента), Seeder создаёт нужный контекст (переключает окружение), Exploiter использует накопленную информацию для финального действия. Система адаптируется — если путь не работает, возвращается назад и пробует другой вариант. Используется библиотека из 1,986 атомарных действий в 349 окружениях, алгоритм выбирает оптимальную последовательность.
Схема метода
Исследование описывает архитектуру системы, не готовый промпт. Концептуальная структура:
РОЛИ (выполняются последовательно):
│
├─ Scout (Разведчик)
│ └─ Собирает информацию, снижает неопределённость
│ Результат → новые сущности в граф знаний
│
├─ Seeder (Сеятель)
│ └─ Создаёт условия, манипулирует состоянием
│ Результат → изменённый контекст
│
└─ Exploiter (Эксплуататор)
└─ Использует накопленные данные для цели
Результат → финальное действие
СВЯЗУЮЩИЙ ЭЛЕМЕНТ:
CE-AKG (граф знаний) — память между шагами и контекстами
├─ Сохраняет сущности из каждого ответа
├─ Предоставляет контекст для следующих действий
└─ Работает между разными окружениями (чатами/задачами)
АДАПТАЦИЯ:
При неудаче → откат назад → выбор альтернативного пути
Ключевые инсайты для практики
1. Эффект домино в многошаговых задачах
Находка: Одиночные запросы часто проваливаются, но последовательность из 3-5 связанных шагов резко повышает успех. Это нелинейная зависимость — не просто "больше шагов = лучше результат", а именно причинно-следственная цепочка, где каждый шаг создаёт условия для следующего.
Для практики: При сложной задаче не пытайся решить в один запрос. Разбей на этапы так, чтобы результат каждого становился входом для следующего. Модель лучше справляется с цепочкой простых шагов, чем с одним сложным.
2. Контекстная хрупкость
Находка: Модели показывают разное поведение в зависимости от того, откуда пришёл запрос. Одна и та же задача получает отказ в одном контексте и выполняется в другом. Защитные механизмы не переносятся между окружениями.
Для практики: Если модель отказывается выполнить задачу или выдаёт слабый результат — переформулируй через смену контекста. Вместо прямого запроса создай другое окружение (роль, сценарий, формат), откуда тот же запрос будет выглядеть уместно.
3. Граф знаний как память между запросами
Находка: CE-AKG связывает информацию из разных контекстов в единую структуру. Система помнит сущности (ID, имена, параметры) и использует их в следующих шагах, даже при смене окружения.
Для практики: При работе над проектом с множеством запросов явно формируй базу знаний. После каждого ответа модели извлекай ключевые данные (имена, числа, решения) и сохраняй в структурированном виде. При следующем запросе подавай эту базу как контекст. Модель связывает информацию между шагами, если ты ей это показываешь.
4. Роли как структура мышления
Находка: Разделение на три роли (Scout-Seeder-Exploiter) даёт системе чёткую структуру действий. Каждая роль имеет свою цель и тип вывода.
Для практики: При сложной задаче явно разбей процесс на роли с разными целями:
- Исследователь — собрать данные, найти информацию
- Аналитик — обработать, выявить паттерны, создать условия
- Исполнитель — использовать результаты для финального вывода
Не смешивай роли в одном запросе. Модель лучше выполняет узкую роль, чем универсальную задачу.
Пример применения (переосмысление для продуктивной работы)
Задача: Готовишь питч про новый EdTech-продукт для инвестора (например, Игоря Рыбакова или фонда ФРИИ). Нужно учесть: портрет аудитории курса, конкурентный ландшафт, финансовую модель. Прямой запрос "сделай питч" даёт общее, без глубины.
Промпт (трёхшаговая цепочка с ролями):
ШАГ 1 — РОЛЬ: Исследователь рынка
Изучи EdTech-сегмент "курсы для профессионалов" в России 2024.
Собери: топ-5 конкурентов, их цены, целевая аудитория, что критикуют пользователи.
Выдай структурированный список: название, ЦА, цена, слабость.
[Получаешь ответ → сохраняешь данные]
ШАГ 2 — РОЛЬ: Аналитик-стратег
Вот данные о конкурентах: [данные из шага 1].
Наш продукт: [описание].
Найди "белое пятно" — что не закрывают конкуренты, какую боль они игнорируют.
Предложи 3 варианта позиционирования с обоснованием.
[Получаешь ответ → выбираешь лучший вариант]
ШАГ 3 — РОЛЬ: Питч-мастер
Вот наше позиционирование: [из шага 2].
Вот конкурентный ландшафт: [из шага 1].
Составь питч на 2 минуты для Игоря Рыбакова (любит конкретику, цифры, социальный импакт).
Структура: проблема → решение → почему мы → unit-экономика → ask.
Результат: Модель выдаст три отдельных блока: список конкурентов с конкретными слабостями, анализ с вариантами позиционирования (с обоснованием через данные первого шага), финальный питч который использует оба предыдущих результата. Каждый шаг будет конкретнее и глубже, потому что опирается на результат предыдущего. Питч учтёт реальный ландшафт (а не абстракции) и будет заточен под стиль инвестора.
Почему это работает
Слабость LLM: Модели плохо удерживают многоступенчатую логику в одном запросе. При попытке "сделай всё сразу" они генерируют общий ответ, не углубляясь в детали. Ещё одна проблема — модели обрабатывают каждый запрос изолированно, не связывая информацию между контекстами автоматически.
Сильная сторона LLM: Модели отлично выполняют конкретные роли с чёткой целью. Когда задача узкая ("ты исследователь, собери данные"), модель фокусируется и выдаёт детальный результат. Также модели хорошо используют предоставленный контекст — если в промпте есть данные из предыдущего шага, модель включает их в рассуждения.
Как метод использует это: Роли разбивают сложность на простые блоки, каждый со своей целью. Модель справляется с узкой задачей лучше, чем с универсальной. Явное связывание — ты подаёшь результат предыдущего шага в следующий запрос, создавая "граф знаний" вручную. Модель не догадывается сама, но если ты показываешь связь — она использует. Смена контекста между шагами обходит "контекстную хрупкость": если прямой запрос не работает, другая роль с другим углом зрения может дать результат.
Рычаги управления:
Количество шагов: Для простых задач достаточно двух (Research → Execute), для сложных — три-пять. Больше шагов = больше токенов, но глубже результат.
Роли: Можешь называть роли конкретно под домен: не "Scout", а "Маркетинговый аналитик" или "Эксперт по UX". Конкретная роль = более специфичное выполнение.
Формат передачи данных: Между шагами передавай структурированно (списки, таблицы, JSON), не текстом. Модель лучше работает с явной структурой.
Условие перехода: Можно добавить явную проверку перед следующим шагом: "Если данных недостаточно, запроси уточнение" вместо автоматического перехода.
Шаблон промпта
=== МНОГОШАГОВАЯ ЦЕПОЧКА С РОЛЯМИ ===
ШАГ 1 — РОЛЬ: {роль_исследователя}
ЗАДАЧА: {что_собрать_или_найти}
ВЫВОД: {формат — список, таблица, структура}
[После получения ответа → сохрани ключевые данные]
---
ШАГ 2 — РОЛЬ: {роль_аналитика}
КОНТЕКСТ из шага 1: {данные_из_предыдущего_ответа}
ЗАДАЧА: {что_проанализировать_или_подготовить}
ВЫВОД: {формат — варианты, схема, выводы}
[После получения ответа → выбери лучший вариант]
---
ШАГ 3 — РОЛЬ: {роль_исполнителя}
КОНТЕКСТ из шага 1: {данные_исследования}
КОНТЕКСТ из шага 2: {результаты_анализа}
ЗАДАЧА: {финальное_действие — создать, написать, решить}
ВЫВОД: {конечный_результат}
Подставь:
- {роль_*} — конкретная роль под твою задачу (Маркетолог, Юрист, Копирайтер, Финансист)
- {что_*} — действие для каждой роли
- {данные_из_предыдущего_ответа} — копируй-вставляй релевантную часть ответа модели
- {формат} — как должен выглядеть вывод (список, JSON, таблица, текст)
Важно: Каждый шаг — отдельный запрос. Ты получаешь ответ, копируешь нужные данные, вставляешь в следующий промпт. Это не автоматизация, это workflow.
Ограничения
⚠️ Overhead на токены: Многошаговый подход расходует больше токенов, чем один запрос. Для простых задач это избыточно.
⚠️ Ручное связывание: Ты вручную копируешь данные между запросами. В ChatGPT нет автоматической памяти между сессиями, нужно явно передавать контекст.
⚠️ Не для всех задач: Метод работает для сложных, многоступенчатых задач (исследование → анализ → создание). Для простых вопросов ("Столица Франции?") это overkill.
⚠️ Требует планирования: Нужно заранее продумать, какие роли и в каком порядке. Метод не работает "на автопилоте".
⚠️ Зависимость от качества промежуточных шагов: Если Scout собрал плохие данные, Exploiter выдаст плохой результат. Цепочка усиливает как качество, так и ошибки.
Как исследовали
Команда создала автоматизированную систему атак и протестировала на 12 топовых LLM-агентах. Построили библиотеку из 1,986 атомарных атак в 349 разных окружениях (банкинг, e-commerce, корпоративные системы и т.д.). Каждая атака — структурированный объект с описанием, целевым окружением и требованиями к данным.
Система использовала алгоритм C-GPS (Contextualized Guided Policy Search), который динамически строил цепочки атак. На каждом шаге алгоритм: ① сужал пространство действий через семантический поиск, ② кластеризовал кандидатов, ③ выбирал оптимальное действие через value function (балансирует потенциал атаки + использование накопленной информации + стратегический прогресс), ④ выполнял и обновлял граф знаний. Если путь не работал — откатывался назад и пробовал другой вариант.
Результаты показали 70%+ success rate для многошаговых атак против большинства моделей, при том что одиночные атаки проваливались. Что удивило: длина цепочки работает нелинейно — от 1 до 3 шагов успех растёт медленно, но после 3-5 шагов резко взлетает. Это подтвердило гипотезу "эффекта домино": каждый шаг усиливает следующий не аддитивно, а мультипликативно.
Второе открытие — смена окружения критична. Атаки, которые начинались в одном окружении (например, корпоративный чат) и продолжались в другом (финансовая система), были на 40% успешнее mono-environment атак. Это выявило "контекстную хрупкость": защитные механизмы обучались на изолированных сценариях и не переносились между доменами.
Третий инсайт — статические защиты бесполезны против растянутых атак. Модели с defense prompts ("Always refuse harmful requests") легко обходились через разбиение на безобидные шаги. Каждый шаг проходил проверку безопасности, но вместе они давали опасный результат. Модели не отслеживают long-term intent.
Связь с другими методами
Исследование показывает механику, похожую на Chain-of-Thought, но с ключевыми отличиями: CoT разворачивает рассуждения внутри одного запроса, а здесь каждый шаг — отдельный запрос с сохранением состояния между ними. Это ближе к ReAct (Reason + Act), где модель чередует рассуждения и действия, но DREAM добавляет явную память (граф знаний) и роли с разными целями.
Принцип графа знаний пересекается с техниками RAG (Retrieval-Augmented Generation), где модель использует внешнюю базу знаний. Разница: в RAG база статична и внешняя, здесь граф динамически строится из ответов модели и используется в следующих запросах.
Разделение на роли (Scout-Seeder-Exploiter) можно переосмыслить как Multi-Agent Debate, где разные агенты с разными целями последовательно обрабатывают задачу. Но вместо дебатов — pipeline: вывод одного становится входом другого.
Ресурсы
DREAM: Dynamic Red-teaming across Environments for AI Models
Liming Lu, Xiang Gu, Junyu Huang, Jiawei Du, Yunhuai Liu, Yongbin Zhou, Shuchao Pang
_Nanjing University of Science and Technology, Agency for Science, Technology and Research, Peking University_