TL;DR
Анализ-перед-генерацией — это двухшаговая техника: сначала модель описывает структуру и правила задачи своими словами, потом генерирует примеры по пяти категориям — базовый, сложный, граничный, крайний случай и нарушение ограничений. Вместо «придумай ещё примеры» модель получает чёткую типологию и работает по ней.
Когда просишь «дай мне примеры» без структуры — модель генерирует похожие варианты. Попроси пять раз — получишь пять вариаций одного и того же: одинаковый масштаб, одинаковые допущения, одинаковый уровень сложности. Модель воспроизводит самый типичный случай, потому что у неё нет инструкции искать разнообразие намеренно.
Метод решает это через явные категории сценариев: базовый (всё стандартно), сложный (много взаимосвязей), граничный (крайние допустимые значения), крайний случай (нестандартно, но возможно), перегруженные ограничения (ситуация, которая логически валидна, но ломает правила). Сначала модель анализирует структуру задачи texto — это «разогрев». Потом генерирует по одному сценарию каждого типа.
Схема метода
Шаги выполняются в двух отдельных чатах (CoT-стратегия) или одном чате (простая стратегия).
CoT-стратегия (рекомендуется):
ЧАТ 1:
ШАГ 1: Анализ домена → описание на естественном языке
Промпт: "Опиши структуру, компоненты, связи, правила"
ШАГ 2: Генерация сценариев → 5 текстовых описаний по категориям
(одним запросом)
ЧАТ 2 (для каждой категории отдельно):
ШАГ 3: Генерация примера → готовый пример по описанию сценария
ШАГ 4: Если ошибка → "Это некорректно: {ошибка}. Исправь."
ШАГ 5: "Сгенерируй ещё один — структурно и семантически отличный"
Простая стратегия (быстрее):
ОДИН ЧАТ:
ШАГ 1: Инструкция + пример формата → первый пример
ШАГ 2-N: "Сгенерируй ещё один, отличный от предыдущих"
(повторять нужное количество раз)
Пример применения
Задача: Ты проводишь тренинг по работе с возражениями для менеджеров Самоката по корпоративным продажам. Нужны сценарии для ролевых игр — разные типы клиентов, которые не хотят подключать подписку для сотрудников.
Промпт (ЧАТ 1, Шаг 1 — анализ):
Проанализируй следующую модель клиента корпоративных продаж.
Структурируй ответ так:
## Описание
Общая картина: кто этот клиент, какова его цель.
### Компоненты
Перечисли ключевые атрибуты клиента: должность, размер компании,
бюджетные полномочия, текущие боли.
## Отношения и зависимости
Как взаимодействуют: закупщик, финдир, конечные пользователи.
Кто влияет на решение, с какой силой.
## Ограничения
Реальные ограничения клиента: бюджет, процедуры, предыдущий опыт.
Вот модель клиента:
{описание целевого сегмента — компании 50-500 человек, Москва и МО,
сферы: IT, финансы, ретейл, HoReCa}
Промпт (ЧАТ 1, Шаг 2 — сценарии):
На основе этого описания клиента сгенерируй 5 сценариев для ролевых игр
по категориям. Каждый сценарий — на русском, ~100 слов,
с именем персонажа, должностью, компанией и главным возражением.
Категории:
- Базовый: типичный клиент, стандартные возражения, всё предсказуемо
- Сложный: несколько заинтересованных сторон с противоречивыми целями
- Граничный: крайние значения — очень маленький бюджет или очень
большой запрос
- Крайний случай: нестандартная ситуация, которая возможна,
но редко встречается
- Перегруженные ограничения: клиент, чьи внутренние правила делают
любое решение формально невозможным — но логика ситуации требует
его принять
Учти региональные и отраслевые различия.
Результат: Модель выдаст пять описаний клиентов, которые кардинально отличаются по структуре ситуации. Базовый — знакомый закупщик с типовым «дорого». Сложный — HRD хочет, финдир против, а CEO не в курсе. Граничный — стартап с 12 сотрудниками или госкорпорация с тендером на 800 человек. Крайний случай — компания с корпоративным кейтерингом, который уже «работает». Перегруженный — холдинг, где каждая «дочка» закупает отдельно и единого бюджета нет. После этого — в новом чате — по каждому сценарию можно генерировать диалоги.
Почему это работает
Модель без явной типологии тяготеет к центру распределения — к самому частому, самому ожидаемому выводу. Это не баг, это принцип работы: следующий токен предсказывается по вероятности. Типичный пример статистически «тяжелее», чем редкий.
Категории работают как явные векторы поиска. Когда ты говоришь «граничный случай» — модель не генерирует следующий по шаблону текст, а следует инструкции найти конкретный тип. Категории убирают двусмысленность там, где «ещё один пример» оставляет её.
Рычаги управления: - Шаг анализа — сделай его длиннее или короче в зависимости от сложности задачи. Для простых задач можно пропустить совсем. - Количество категорий — можно использовать 2-3 вместо 5, если задача не требует полного покрытия. - Описание категорий — главный рычаг. «Граничный» для клиентов ≠ «граничный» для юридических документов. Перепиши под свой домен. - Культурное и региональное разнообразие — явно попроси в инструкции, иначе всё будет из одного контекста. - Цикл коррекции — если результат неточный, верни ошибку: «Этот пример не соответствует категории X, потому что {причина}. Исправь.»
Шаблон промпта
Шаблон: Анализ перед генерацией
## Шаг 1 — Анализ структуры (отдельный запрос)
Проанализируй следующую задачу/модель/структуру.
Используй чёткий язык, не перегружай деталями.
## Описание
Объясни общую структуру и назначение.
### Компоненты
Опиши ключевые элементы, их характеристики и роль.
## Отношения
Опиши связи между элементами, зависимости,
минимальные и максимальные значения там, где они есть.
## Ограничения
Перечисли правила, которые должны выполняться.
Вот структура для анализа:
{описание домена, объекта или задачи}
---
## Шаг 2 — Генерация по категориям (на основе анализа)
На основе описанной структуры сгенерируй {число} примеров
для каждой из следующих категорий:
**Базовый сценарий:** стандартный, типичный случай —
всё работает как ожидается, каждый элемент присутствует.
**Сложный сценарий:** много взаимосвязанных элементов,
несколько ограничений действуют одновременно.
**Граничный сценарий:** крайние допустимые значения —
минимум или максимум по всем ключевым параметрам.
**Крайний случай:** нестандартная, редкая, но допустимая ситуация.
**Перегруженные ограничения:** реальная ситуация,
которая логически валидна, но нарушает формальные правила —
чтобы обнаружить излишне жёсткие ограничения.
Требования к разнообразию:
- Семантическое: разные контексты, регионы, культуры, масштабы
- Структурное: разное количество элементов и связей
- Избегай дублирования с предыдущими примерами
Плейсхолдеры:
- {описание домена} — твоя тема. Клиентский сегмент, продукт, юридический документ, персонаж, сценарий переговоров — что угодно со структурой.
- {число} — сколько примеров на категорию (обычно 1-3).
🚀 Быстрый старт — вставь в чат:
Вот шаблон для генерации разнообразных примеров по категориям.
Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит что именно нужно генерировать, какой формат результата и нужен ли шаг анализа — потому что без этого она не поймёт как интерпретировать категории для твоего домена.
Ограничения
⚠️ Категории нужно адаптировать под домен: Названия (базовый, граничный, крайний) — шаблонные. Для текстов «граничный» означает одно, для переговоров — другое, для технических документов — третье. Без точного описания категории модель интерпретирует их по своим критериям.
⚠️ Шаг анализа не заменяет экспертизу: Если задача требует глубокого доменного знания (медицина, юриспруденция), анализ на шаге 1 может быть поверхностным. Стоит проверить описание перед шагом 2.
⚠️ Простые задачи не требуют CoT: Для простого «придумай 5 примеров имён» — излишне. Метод даёт прирост на задачах с явной структурой и требованием покрытия разных случаев.
⚠️ Автоматическая валидация невозможна в чате: В исследовании шибки проверяются инструментом USE автоматически. В чате — проверяешь глазами или описываешь критерии вручную.
Ресурсы
Работа: LLM-based Generation of Semantically Diverse and Realistic Domain Model Instances (препринт, апрель 2025)
Авторы: Andrei Coman, Lola Burgueño — Universidad de Málaga; Dominik Bork — TU Wien; Manuel Wimmer — JKU Linz
Смежные техники из бумаги: Chain-of-Thought (Wei et al., 2022) — промптинг через промежуточные шаги; One-shot learning — предоставление одного примера формата; USE tool + SOIL — инструменты для UML-моделирования (для специалистов по моделированию)