MaRGen: четырёхагентная система для автоматической генерации маркетинговых отчётов

RETRIEVER (опционально):
Извлекает hypothesis trees из PowerPoint консультантов
↓ (добавляет few-shot примеры)

RESEARCHER:
Цикл на MAX_QUERIES запросов (4-8):
1. Формулирует гипотезу → SQL запрос
2. Получает данные → анализирует
3. Корректирует гипотезу если нужно
→ Финальный research summary

WRITER:
1. Markdown с Python блоками для графиков
2. Выполняет код → генерирует PNG
3. LaTeX код с ссылками на картинки
→ Компиляция в PDF

REVIEWER:
Оценивает PDF по критериям (1-10):
- Clarity (ясность)
- Layout (оформление)
→ Feedback + scores

ИТЕРАЦИИ (до 4 раундов):
Writer улучшает → Reviewer оценивает
→ Пока не достигнут perfect score (10/10)

ФИНАЛ:
Генерация N отчётов параллельно
→ Pairwise-сравнение
→ Выбор лучшего

Как работает в системе: Researcher начинает с формулировки гипотезы, затем собирает данные для проверки, корректирует гипотезу если данные противоречат.

Как применить в чате:

Вместо "проанализируй данные" → структурируй запрос:

1. Сформулируй гипотезу о том, что может быть
2. Определи какие данные нужны для проверки
3. Проанализируй данные
4. Подтверди/опровергни/скорректируй гипотезу
5. Повтори если нужно

Пример промпта:

Задача: Понять почему продажи в нашем интернет-магазине 
упали на 30% в ноябре.

Действуй по hypothesis-driven подходу:

ШАГ 1: Сформулируй 3 возможные гипотезы объясняющие падение
ШАГ 2: Для каждой гипотезы - какие данные нужны для проверки
ШАГ 3: Я дам данные, ты проанализируй и проверь гипотезы
ШАГ 4: Скорректируй/уточни гипотезы на основе данных
ШАГ 5: Финальный вывод с рекомендациями

Данные которые есть:
[вставь свои данные - traffic, конверсия, средний чек, и т.д.]

Как работает в системе: Разные агенты специализируются на разных задачах - исследование, написание, критика, извлечение знаний.

Как применить в чате:

Один чат = один агент. Для сложной задачи используй несколько чатов последовательно:

• Чат 1 (Analyst): "Ты аналитик. Изучи данные и найди паттерны"
• Чат 2 (Critic): "Ты критик. Вот выводы аналитика - где слабые места?"
• Чат 3 (Strategist): "Ты стратег. На основе анализа и критики - план действий"

Альтернатива - симуляция агентов в одном промпте:

Действуй как система из трёх агентов:

ANALYST (Аналитик):
- Изучает данные
- Ищет паттерны и аномалии
- Формулирует первичные выводы

CRITIC (Критик): 
- Проверяет выводы аналитика
- Ищет слабые места в аргументации
- Задаёт неудобные вопросы

STRATEGIST (Стратег):
- Учитывает анализ и критику
- Предлагает действия
- Оценивает риски

Задача: [твоя задача]

Покажи рассуждения каждого агента по очереди.
В конце - консолидированный вывод.

Как работает в системе: Writer создаёт отчёт → Reviewer критикует → Writer улучшает → цикл повторяется до достижения высокого качества.

Как применить в чате:

Вариант А - в одном чате (быстро):

Создай черновик [текст/отчёт/презентацию] на тему: [тема]

После создания:
1. Переключись в роль строгого редактора
2. Покритикуй свой черновик - что слабо, что непонятно, что упущено
3. Создай улучшенную версию устраняя найденные проблемы

Повтори цикл критики → улучшения ещё 1 раз.

Вариант Б - через разные чаты (глубже):

Чат 1 - Writer:

Создай черновик маркетингового отчёта по [теме]
на основе этих данных: [данные]

Чат 2 - Reviewer:

Ты опытный редактор. Вот черновик отчёта: [вставить]

Оцени по критериям:
- Clarity (ясность): 1-10
- Data support (обоснованность данными): 1-10 
- Actionability (конкретность рекомендаций): 1-10
- Layout (структура): 1-10

Для каждого критерия ниже 8 - конкретные предложения по улучшению.

Чат 1 - Writer (продолжение):

Вот feedback редактора: [вставить]

Улучши черновик адресуя все замечания.
После улучшения - кратко опиши что именно изменил.

Повторить цикл 2-3 раза до высоких оценок.

Как работает в системе: Retriever извлекает hypothesis trees из материалов консультантов: главная гипотеза → аргументы → данные (depth=2).

Структура Pyramid Principle:

ВЕРШИНА (главный вывод/рекомендация)
 ↓
СРЕДНИЙ УРОВЕНЬ (2-4 аргумента поддерживающих вывод)
 ↓
ОСНОВАНИЕ (конкретные данные/факты для каждого аргумента)

Как применить в чате:

Проанализируй [ситуацию/данные] используя Pyramid Principle:

СТРУКТУРА:
Root (главный вывод): Что нужно сделать и почему
 ├─ Sub-hypothesis 1: Первый аргумент в поддержку
 │ ├─ Data point 1.1
 │ └─ Data point 1.2
 ├─ Sub-hypothesis 2: Второй аргумент в поддержку 
 │ ├─ Data point 2.1
 │ └─ Data point 2.2
 └─ Sub-hypothesis 3: Третий аргумент в поддержку
 ├─ Data point 3.1
 └─ Data point 3.2

Каждый уровень должен логически вытекать из данных нижнего уровня.
Начни снизу (данные) → средний уровень (аргументы) → вершина (вывод).

Пример применения:

Задача: Стоит ли запускать новую линейку продуктов?

Используй Pyramid Principle. Вот данные:
- Текущая маржинальность: 35%
- Прогноз маржи новой линейки: 28% 
- NPS текущих клиентов: 72
- % клиентов просящих расширение ассортимента: 43%
- Конкуренты уже запустили аналоги
- Наша доля рынка: 18% (год назад была 24%)

Построй pyramid: данные → аргументы → финальный вывод (да/нет + почему).

Как работает в системе: Вместо абсолютной оценки каждого отчёта (individual scoring показал сжатие к средним значениям 6.5-8.25), система сравнивает отчёты попарно: "какой из двух лучше?". Это даёт более чёткое разделение по качеству.

Как применить в чате:

Если генерируешь несколько вариантов (например, 3 концепции продукта) - не проси оценить каждый, а попроси сравнить попарно:

Вот 3 концепции нового продукта:

КОНЦЕПЦИЯ А: [текст]
КОНЦЕПЦИЯ Б: [текст] 
КОНЦЕПЦИЯ В: [текст]

Сделай pairwise-сравнения:
1. А vs Б: какая лучше и почему (2-3 предложения)
2. Б vs В: какая лучше и почему (2-3 предложения)
3. А vs В: какая лучше и почему (2-3 предложения)

На основе трёх сравнений - ранжирование: 1 место, 2 место, 3 место.

Почему работает: LLM лучше справляется с относительными суждениями ("это лучше того") чем с абсолютными оценками ("это 7 из 10"). При pairwise модель не может "уйти в середину шкалы" — она вынуждена делать выбор.

Многошаговые задачи и специализация ролей: LLM хорошо справляется с узкими специализированными задачами, но теряет фокус в комплексных проектах. Разбиение на роли (исследователь → писатель → критик) даёт каждому запросу чёткую задачу. В одном промпте "проанализируй и напиши отчёт" модель размазывает внимание. В последовательности запросов с разными ролями — каждая роль максимально сфокусирована.

Критика улучшает результат через second-order thinking: Когда LLM генерирует контент, она идёт по пути наименьшего сопротивления — первое "достаточно хорошее" решение. Роль критика заставляет вернуться и подумать: "А что если?", "А не упущено ли?", "А не слишком ли поверхностно?". Это second-order thinking — мышление о мышлении. Исследование показало: initial scores ~7-8, после review ~9-10. Более того, pairwise-сравнения показали что поздние версии объективно лучше ранних, даже когда LLM "не знает" какая версия старше.

Pairwise-сравнение избегает compression to the middle: Individual scoring показал сжатие оценок к середине шкалы (6.5-8.25) — модель избегает крайностей. Pairwise заставляет делать выбор: "это лучше того". Нельзя дать обеим 7. Результат: более чёткое разделение по качеству и корреляция с экспертами r=0.6 против r=0.43 для individual scoring.

Few-shot from expert materials работает как knowledge distillation: Retriever извлекает hypothesis trees из PowerPoint консультантов и добавляет как примеры. LLM видит "как думают профессионалы" и мимикрирует под этот паттерн. Это не просто "вот пример текста" — это структура мышления: главная гипотеза → аргументы → данные. Pyramid Principle превращается из абстрактной методологии в конкретный few-shot шаблон.

Hypothesis-driven подход структурирует исследование: Вместо "проанализируй всё" → формулируй гипотезу → собирай данные → проверяй → корректируй. Это снижает когнитивную нагрузку и даёт чёткие критерии "достаточности" данных. В исследовании: Researcher делает 4-8 SQL-запросов, не больше и не меньше. Гипотеза определяет что искать, данные говорят когда хватит.

⚠️ Требует инфраструктуры: Исследование описывает систему требующую SQL базы данных, API к AWS Athena, LaTeX компилятор, Python окружение. Это не работает "из коробки" в обычном чате. Ценность для читателя — в принципах (hypothesis-driven, multi-agent, iterative review), которые можно адаптировать вручную.

⚠️ Нет валидации данных: Авторы упоминают что создали Verifier агента (Appendix B.4) для проверки корректности SQL-запросов и расчётов, но не провели полноценную оценку. Фактическая точность данных не проверялась против экспертов — только "читабельность" отчёта.

⚠️ Оценка только по форме, не по содержанию: Корреляция с экспертами r=0.6 касается критериев вроде clarity, layout, feasibility. Но не проверялось насколько бизнес-выводы корректны. Отчёт может выглядеть профессионально, но содержать ошибочные инсайты.

⚠️ Узкая специфика: Система заточена под структурированные данные в SQL и конкретный workflow Amazon консультантов. Pyramid Principle хорош для consulting reports, но может не подходить для креативных или нестандартных задач.

⚠️ Cost & Time: 7 минут и $1 за отчёт звучит дёшево, но это без учёта времени на подготовку базы данных, создание схем, дебаггинг SQL-запросов, настройку LaTeX окружения. Для разового применения накладные расходы могут быть значительными.

Команда из Amazon и японских университетов тестировала систему на реальных данных заказов Amazon с января по ноябрь 2024. База на AWS S3, доступ через Athena API. Claude 3.5 Sonnet через AWS Bedrock для всех агентов.

Проверяли два сценария: (1) оптимизация продаж для компании желающей стать лидером в категории, (2) разработка стратегии bundling для electronics компании. Для каждого сценария генерировали по 20 финальных отчётов.

Критически: как проверяли качество отчётов? Два человека-эксперта независимо оценивали каждый из 20 отчётов по шести критериям (non-triviality, justification, clarity, feasibility, balance, overall). Pairwise LLM-оценки показали корреляцию r=0.6 (p<0.01) с усреднёнными оценками экспертов. Individual scoring дал r=0.43 (p=0.058) — хуже и на грани значимости.

Почему такая разница? Individual scoring сжимал оценки к середине шкалы 6.5-8.25 — не улавливал вариативность. Pairwise заставлял модель делать чёткий выбор: "какой из двух отчётов лучше?". Результат: шире разброс оценок, лучше correlation.

Тест iterative improvement: Отслеживали scores по clarity и layout через 4 раунда review. Initial scores ~7-8, после 2-3 раундов достигали 9-10. Cross-check без знания версий: LLM сравнивала одинаковые отчёты из разных раундов не зная какой раунд какой — консистентно выбирала поздние версии как лучшие. Это валидирует что улучшение реальное, не артефакт "ожидания что новое лучше".

Тест Retriever: Для 5 компаний создали отдельные Retriever из их PowerPoint материалов. По 20 отчётов: 10 с few-shot примерами от Retriever, 10 без. Pairwise matrix показала чёткую границу: отчёты 10-19 (с экспертными примерами) статистически значимо лучше отчётов 0-9 (без примеров). Visual heatmap (рис. 8) показывает два чётких кластера — не overlap.

Что удивило: Initial scores по clarity были уже довольно высокие (~7-8), но все 20 отчётов после review достигали 9-10. Это говорит что даже "хороший на первый взгляд" output имеет значительный потенциал для улучшения через структурированную критику. Второй surprise: few-shot from PowerPoint реально работает — не просто marginal improvement, а статистически значимый эффект видимый невооружённым глазом на heatmap.

Лимитация исследования: Авторы честно признают что не проводили A/B тест "MaRGen vs человек-консультант". Проверяли только alignment между LLM и экспертами в оценке, не качество итогового бизнес-анализа. Также не проверяли фактическую корректность данных и выводов — только presentation quality.

MaRGen: Multi-Agent LLM Approach for Self-Directed Market Research and Analysis

Roman Koshkin (Okinawa Institute of Science and Technology), Pengyu Dai (Institute of Science Tokyo), Nozomi Fujikawa, Masahito Togami, Marco Visentini-Scarzanella (Amazon)

LLM4ECommerce Workshop at KDD '25, August 2025

Ключевая отсылка:

Barbara Minto (2008). The Pyramid Principle: Logic in Writing and Thinking (3rd ed.) — методология консультантов для структурирования аргументации от вывода к данным.