TL;DR
Исследователи из RWTH Aachen разработали систематический подход к генерации профессиональных документов через ChatGPT — без доступа к реальным образцам. В его основе: комбинация роли эксперта, жёсткого шаблона структуры и цепочки рассуждений (Chain-of-Thought). Плюс итеративная оценка качества через явный рубрик со снятием баллов за нарушения.
Главная находка, которая меняет как работать с LLM: не доверяй модели оценивать собственный вывод. Когда GPT-4o оценивал свои же документы, он давал в среднем 0.90 из 1. Когда те же документы оценивал Claude Sonnet — в среднем 0.64. Тот же Claude выдавал разброс 0.48–0.73 при десяти оценках одного и того же документа. Это не баг конкретной модели — это системное свойство LLM: модель льстит себе и нестабильна как судья.
Чтобы обойти это, авторы использовали кросс-модельную проверку: документ генерировала одна модель, оценивала — другая, более критичная. Плюс явный рубрик: инструкция снимать конкретное количество баллов за каждое нарушение с объяснением причины. Это даёт стабильнее и честнее результат, чем просто "оцени от 1 до 10".
Схема метода
ШАГ 1 (ГЕНЕРАЦИЯ): Один промпт с тремя слоями
→ Роль эксперта + жёсткий шаблон структуры + Chain-of-Thought
→ Инструкция использовать нейтральный термин ("сценарий", а не "ТЗ")
→ Инструкция отличаться от предыдущих версий
→ Выход: готовый документ по шаблону
ШАГ 2 (ОЦЕНКА ПОЛНОТЫ): Отдельный промпт той же или другой модели
→ Проверить наличие каждого раздела из шаблона
→ Выход: да/нет по каждому пункту
ШАГ 3 (ОЦЕНКА РЕАЛИСТИЧНОСТИ): Отдельный промпт с рубриком
→ Роль эксперта + инструкция снимать баллы по шкале тяжести
→ Объяснение каждого нарушения
→ Выход: числовая оценка [0–1] + комментарии
ШАГ 4 (КРОСС-ПРОВЕРКА): Ту же оценку — другой моделью
→ Сравниваешь два вывода
→ Расхождение > 0.2 = сигнал, что документ требует правки
⚠️ Все шаги — отдельные запросы в чате.
Пример применения
Задача: Фаундер хочет подготовить ТЗ для разработчика мобильного приложения для записи к барберу. Нет готовых образцов, нет опыта в написании ТЗ — нужен документ, который примет любой нормальный разработчик.
Промпт (ШАГ 1 — Генерация):
Ты — опытный системный аналитик и менеджер продукта с 10-летним
опытом написания технических заданий для мобильных приложений.
Создай сценарий: техническое задание для мобильного приложения в сфере
[барберские услуги]. Следуй точно этой структуре:
1. ОБЗОР ПРОДУКТА
1.1 Назначение и цели
1.2 Целевая аудитория
1.3 Ключевые ограничения
2. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
2.1 Основные функции (список с описанием каждой)
2.2 Пользовательские роли и права доступа
2.3 Интеграции с внешними сервисами
3. НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ
3.1 Производительность
3.2 Безопасность
3.3 Масштабируемость
4. ОГРАНИЧЕНИЯ И ДОПУЩЕНИЯ
4.1 Технологический стек
4.2 Временны́е ограничения
4.3 Бюджетные рамки
Рассуждай пошагово: сначала определи пользовательский сценарий,
потом выпиши требования по каждому разделу. Делай требования
конкретными, измеримыми, без общих фраз. Объём — 600–800 слов.
Промпт (ШАГ 3 — Оценка реалистичности):
Ты — опытный технический директор и системный аналитик. Тебе нужно
оценить реалистичность технического задания.
Начни с оценки 1.0. Затем найди все нереалистичные элементы документа:
КРИТИЧЕСКИЕ нарушения (снять -0.2 за каждое):
- Внутренние противоречия между разделами
- Технически невозможные требования
СЕРЬЁЗНЫЕ нарушения (снять -0.1 за каждое):
- Расплывчатые требования без метрик
- Отсутствие требований, обязательных для этого типа приложений
НЕЗНАЧИТЕЛЬНЫЕ нарушения (снять -0.05 за каждое):
- Нетипичная формулировка для данной отрасли
- Пропуск второстепенных деталей
Итоговая оценка = 1.0 минус сумма снятых баллов.
Для каждого нарушения укажи: цитату из документа → почему нереалистично
→ уровень серьёзности → сколько баллов снято.
[Вставить сгенерированный документ]
Результат: В ШАГ 1 модель выдаст структурированное ТЗ на 600–800 слов с конкретными требованиями по каждому разделу. В ШАГ 3 — список конкретных проблем с объяснениями и финальную оценку. Если она выше 0.8 — документ готов к передаче разработчику. Если ниже — правишь по списку нарушений и просишь перегенерировать слабые разделы.
Почему это работает
Слабость LLM: попроси написать профессиональный документ "просто так" — получишь либо шаблонную воду, либо документ с внутренними противоречиями, которые не видны на первый взгляд. Модель не "знает" как должна выглядеть хорошая спецификация — она генерирует по паттернам из обучающих данных, где профессиональных ТЗ значительно меньше, чем общего текста.
Сильная сторона LLM: модель отлично заполняет явные структуры. Когда ты даёшь жёсткий шаблон — она не изобретает форму, а концентрируется на содержании. Persona "опытный аналитик" сдвигает распределение токенов в сторону профессионального регистра. Chain-of-Thought разбивает одну сложную задачу на несколько простых — по разделу за раз.
Почему нейтральный термин снижает галлюцинации: если использовать точный термин ("SRS по ISO 29148"), модель может генерировать по смутным паттернам из интернета, где этот термин встречается неточно. Нейтральный термин + явная структура = она следует твоему шаблону, а не своим предположениям о формате.
Рычаги управления: - Строгость рубрика — увеличь штрафы за критические нарушения, если нужна высокая точность - Объём — укажи диапазон слов явно; без него модель выдаёт непредсказуемый объём - Степень детализации структуры — чем детальнее шаблон (до под-подпунктов), тем предсказуемее вывод - Критичность оценщика — Claude более строг как судья, GPT-4o — мягче; выбирай под задачу
Шаблон промпта
Генерация документа
Ты — опытный {роль_эксперта} с {N} летним опытом создания
{тип_документа} в сфере {отрасль}.
Создай сценарий: {тип_документа} для {описание_продукта_или_услуги}.
Следуй точно этой структуре:
{РАЗДЕЛ_1}
{подраздел_1.1}
{подраздел_1.2}
{РАЗДЕЛ_2}
{подраздел_2.1}
{подраздел_2.2}
{РАЗДЕЛ_3}
{подраздел_3.1}
{подраздел_3.2}
Рассуждай пошагово: сначала определи ключевой контекст, затем
заполни каждый раздел конкретными, измеримыми данными.
Объём — {мин_слов}–{макс_слов} слов.
Оценка через рубрик
Ты — опытный {роль_эксперта}. Оцени реалистичность документа
для использования в {цель_использования}.
Начни с оценки 1.0. Найди нарушения:
КРИТИЧЕСКИЕ (−{штраф_1} за каждое): {описание_критических}
СЕРЬЁЗНЫЕ (−{штраф_2} за каждое): {описание_серьёзных}
НЕЗНАЧИТЕЛЬНЫЕ (−{штраф_3} за каждое): {описание_незначительных}
Для каждого нарушения: цитата → почему проблема → уровень → балл.
Итоговая оценка = 1.0 − сумма штрафов.
Документ:
{вставить_документ}
Что подставлять:
- {роль_эксперта} → "системный аналитик", "копирайтер", "бизнес-аналитик", "маркетолог"
- {тип_документа} → "техническое задание", "бриф для агентства", "контент-план", "описание вакансии"
- {штраф_1/2/3} → попробуй 0.2 / 0.1 / 0.05 как базу
🚀 Быстрый старт — вставь в чат:
Вот шаблоны для генерации документа и его оценки.
Адаптируй под мою задачу: [твоя задача].
Задавай уточняющие вопросы, чтобы заполнить все поля.
[вставить шаблон выше]
LLM спросит про тип документа, отрасль и структуру разделов — потому что без этого шаблон не заполнить. Она возьмёт паттерн и адаптирует под твою задачу.
Оригинал из исследования
Авторы использовали точно такую комбинацию для генерации ТЗ: - Persona pattern: "experienced requirements engineer and business analyst" - Template pattern: разделы по ISO/IEC/IEEE 29148 (цели, ограничения, функциональные и нефункциональные требования) - Chain-of-Thought: сложные инструкции разбиты на последовательные подзадачи - Нейтральный термин: использовали "scenario" вместо "SyRS" — чтобы снизить риск галлюцинаций из-за неточных паттернов в обучающих данных
Для оценки качества — два отдельных промпта: PComp (полнота по шаблону, boolean) и PDoR (реалистичность, рубрик с баллами и качественными объяснениями, та же роль эксперта, CoT).
Ограничения
⚠️ LLM-оценщик ненадёжен: Одна и та же модель оценивает один документ с разбросом до 25% от шкалы при повторных запросах. Не используй числовую оценку LLM как финальный вердикт — только как один из сигналов.
⚠️ Модель хвалит себя: Когда генерирующая и оценивающая модель — одна и та же, оценки завышены. Для честной проверки — оценивай другой моделью (GPT → Claude или наоборот).
⚠️ Соответствие ≠ качество: 62% экспертов согласились, что документ выглядит "как настоящий". Но углублённый анализ выявил внутренние противоречия и пропуски. Документ может выглядеть профессионально и при этом содержать ошибки, незаметные при беглом чтении.
⚠️ Метод для структурированных документов: Работает для чётко структурированных профессиональных текстов (ТЗ, брифы, спецификации). Для свободного творческого текста или субъективных оценок — менее применимо.
Ресурсы
Работа: "Can ChatGPT Generate Realistic Synthetic System Requirement Specifications? Results of a Case Study" — принята в ENASE 2026
Датасет: 300 синтетических ТЗ опубликован на GitLab RWTH Aachen
Авторы: Alex R. Mattukat, Florian M. Braun, Horst Lichter — Research Group Software Construction, RWTH Aachen University, Германия
Техники промптинга из: Schulhoff et al., White et al. (классификаторы паттернов промптинга)