TL;DR
В исследовании есть две экстрактируемые техники. Первая — Chain-of-Thought генерация структурированного документа: модель получает задачу разбить её на явные шаги (извлечь сущности → определить атрибуты → установить связи → проверить синтаксис) и только потом выдать итог. Вторая — LLM-as-a-Judge: один LLM оценивает выходы другого (или несколько версий одного ответа) по структурированной рубрике с конкретными критериями и шкалой 1–5.
Главная находка: открытый промпт ("сгенерируй мне схему") даёт плохой результат. Без явных шагов, ограничений и примера структуры модель генерирует неполные, синтаксически поломанные ответы. Ровно та же боль, что при любой сложной задаче в чате — попросил "напиши ТЗ", получил кашу. Причина: модель не знает какой именно артефакт ты ожидаешь, и заполняет пустоту самостоятельно.
Решение в двух шагах. Шаг 1 — промпт генерации с явными этапами рассуждения, жёсткими ограничениями и примером нужного формата. Шаг 2 — отдельный оценочный промпт: другой (или тот же) LLM сравнивает два варианта ответа по пяти критериям и называет победителя с обоснованием.
Схема метода
ШАГ 1 — Генерация (один промпт)
Роль: эксперт в предметной области
CoT: явные шаги (a→b→c→d→проверка)
Ограничения: что включить, что исключить
Пример структуры: шаблон нужного формата
→ Выход: структурированный документ/схема
ШАГ 2 — Оценка через LLM-as-a-Judge (отдельный промпт)
Вход: требования + Вариант A + Вариант B
Критерии: 5 штук, каждый со шкалой 1–5
Приоритет: критерии упорядочены по важности
→ Выход: Победитель A|B + обоснование + оценки по критериям
Шаги выполняются в двух отдельных запросах. Можно в одном чате — сначала попросить несколько вариантов, потом попросить оценить.
Пример применения
Задача: Алексей — владелец небольшого SaaS для HR-специалистов. Написал два варианта описания продукта для питч-деки перед инвесторами. Хочет понять какой сильнее — но сам уже "замылен".
Промпт (Шаг 1 — генерация, если вариантов ещё нет):
Ты — опытный продуктовый маркетолог.
Давай разберём задачу по шагам:
(a) выдели ключевые боли целевой аудитории из описания;
(b) определи главные преимущества продукта;
(c) найди доказательства ценности (цифры, факты, сравнения);
(d) выстрой логику сообщения от боли к решению к результату;
(e) проверь: нет ли маркетинговой воды без конкретики.
Затем выдай только финальный текст описания. Не более 80 слов.
Ограничения:
— Конкретные цифры вместо абстракций
— Без слов "инновационный", "уникальный", "передовой"
— Целевая аудитория: HR-директора компаний 50–500 человек
— Язык: деловой, без жаргона
Описание продукта для работы: {вставь описание}
Промпт (Шаг 2 — LLM-as-a-Judge):
Ты — строгий оценщик питч-материалов.
Сравни два варианта описания продукта (A и B) относительно требований инвестора.
Контекст (кто читает): {описание инвестора/аудитории}
Вариант A: {текст A}
Вариант B: {текст B}
Правила оценки:
— Оценивай только соответствие контенту требований, не стиль
— Не выдумывай преимущества, которых нет в тексте
— Контекст инвестора — главный судья
Критерии оценки (по приоритету):
1. Чёткость ценностного предложения — 1-5
2. Соответствие болям целевой аудитории — 1-5
3. Наличие конкретных доказательств — 1-5
4. Ясность и понятность — 1-5
5. Согласованность терминологии с контекстом — 1-5
Выдай только:
Победитель: A | B
Обоснование: 2–4 предложения с конкретными примерами из A и B
Оценки: по каждому критерию для обоих вариантов
Результат:
Модель выдаст структурированное сравнение: счёт по каждому из пяти критериев для обоих вариантов, назовёт победителя и объяснит почему — со ссылками на конкретные фразы из текстов. Если в варианте A "снижение времени найма на 40%" — а в B только "ускоряет найм" — модель это зафиксирует как конкретное преимущество A по критерию доказательств.
Почему это работает
Слабость LLM при открытом промпте: модель заполняет неопределённость самостоятельно. Попросил "сделай хорошо" — получил "сделал что-то". Без явных шагов она пропускает этапы, которые кажутся очевидными, но для задачи критичны.
Сильная сторона LLM: модель отлично следует явной последовательности шагов и строгим ограничениям. Если ей сказать "сначала сделай A, потом B, потом C, а потом проверь по D" — она именно так и пройдёт. CoT в промпте — это не подсказка, это принудительный маршрут через нужные этапы рассуждения.
Почему LLM-as-a-Judge работает: сравнивать два варианта проще, чем оценивать один в вакууме. У модели нет калибровки "что такое хорошо" в абсолюте — зато есть возможность сказать "из этих двух вот этот сильнее по критерию X". Плюс структурированные критерии с описанием каждого балла убирают двусмысленность: модель не угадывает что ты имеешь в виду под "хорошим".
Рычаги управления: - Количество критериев → убери 1–2 для быстрой оценки, добавь отраслевые под свою задачу - Порядок критериев → первый критерий — самый важный, модель взвешивает по приоритету - Роль судьи → замени "строгий оценщик" на "скептичный инвестор" или "придирчивый клиент" — тональность критики изменится - Формат выхода → убери "Победитель" и попроси только оценки по критериям, если нужна не победа, а диагностика
Шаблон промпта
Шаблон 1 — CoT-генерация структурированного документа:
Ты — {роль эксперта}.
Разбери задачу по шагам:
(a) {шаг извлечения ключевых элементов};
(b) {шаг определения свойств/параметров};
(c) {шаг установки связей/логики};
(d) {шаг финальной проверки}.
Затем выдай только итоговый {тип документа}.
Ограничения:
— {что обязательно включить}
— {что исключить}
— {формат или стиль}
Пример структуры результата:
{вставь короткий шаблон ожидаемого формата}
Исходные данные: {вставь требования/описание/текст}
Шаблон 2 — LLM-as-a-Judge:
Ты — строгий оценщик {тип материала}.
Сравни два варианта (A и B) относительно {контекст/требования}.
Контекст: {описание аудитории или требований}
Вариант A: {текст A}
Вариант B: {текст B}
Правила:
— Оценивай только по критериям ниже
— Контекст — главный судья, не личные предпочтения
— Не выдумывай то, чего нет в текстах
Критерии (по приоритету):
1. {критерий 1} — 1-5
2. {критерий 2} — 1-5
3. {критерий 3} — 1-5
4. {критерий 4} — 1-5
5. {критерий 5} — 1-5
Выдай:
Победитель: A | B
Обоснование: 2–4 предложения с конкретными примерами
Оценки: таблица по критериям для A и B
Плейсхолдеры:
- {роль эксперта} → "опытный юрист", "продуктовый менеджер", "UX-дизайнер"
- {тип материала} → "коммерческих предложений", "технических заданий", "текстов лендингов"
- {контекст/требования} → описание кому это читать и что они ожидают
- {критерий 1–5} → адаптируй под домен, первый = самый важный
🚀 Быстрый старт — вставь в чат:
Вот шаблон LLM-as-a-Judge оценки. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про домен, аудиторию и что считать качеством — потому что без этого критерии оценки будут размытыми и оценка потеряет смысл. Она возьмёт паттерн сравнения из шаблона и адаптирует под конкретный тип материала и аудиторию.
Ограничения
⚠️ CoT-шаги не гарантируют правильности извлечения: Модель следует шагам, но может пропустить важные сущности из исходного текста — особенно неявные. Всегда проверяй итог против источника.
⚠️ LLM-as-a-Judge предвзята к длинным ответам: Более объёмный вариант воспринимается как более полный даже если просто многословен. Если сравниваешь тексты разной длины — явно предупреди модель в промпте не учитывать длину как критерий.
⚠️ Парное сравнение работает хуже трёх и более вариантов: При трёх вариантах результаты могут стать непоследовательными (A > B, B > C, но C > A). Для трёх+ вариантов разбивай на серии попарных сравнений.
⚠️ Судья-LLM склонна к компромиссным оценкам: Почти во всех моделях судья избегает крайних баллов (1 и 5), тяготея к середине. Если нужна острая дифференциация — добавь в промпт: "Используй весь диапазон от 1 до 5. Не бойся ставить 1 и 5".
⚠️ Без наглядного примера формата — мусорный выход: Если в генерирующем промпте нет примера структуры результата, модель придумывает формат сама. Всегда давай хотя бы короткий шаблон ожидаемого выхода.
Как исследовали
Команда из Monash University и University College Dublin взяла восемь реальных наборов требований — от системы управления запасами до медицинских устройств (кардиостимуляторы) и систем автопилота. Это был сознательный выбор: разные домены, разные стили записи требований (user stories vs "shall"-формат), разный размер — от 12 до 187 требований в документе.
Для каждого набора четыре модели (GPT-5, Claude Sonnet 4, Gemini 2.5 Flash Thinking, Llama-3.1-8B) генерировали UML-диаграммы. Потом два независимых судьи-LLM (Grok и Mistral) сравнивали результаты попарно по пяти критериям. Интересное решение: исследователи намеренно взяли судей из других "семейств" моделей, чем генераторы — чтобы не было предвзятости "своих".
Главный сюрприз: LLM-судьи согласились между собой примерно так же хорошо, как два независимых эксперта-человека. Коэффициент Коэна (мера согласия) оказался в диапазоне "умеренное–хорошее" согласие. Это важно: значит LLM можно использовать как замену дорогой экспертной оценки — когда нет времени ждать человека или задач слишком много. Для RQ2 добавили двух живых экспертов (кандидаты наук с опытом UML-моделирования) и сравнили их оценки с LLM-судьями — расхождение оказалось небольшим, особенно на лучшей модели (GPT-5).
Адаптации и экстраполяции
Адаптация 1: Последовательная итерация вместо одного запроса
🔧 Разбить CoT-шаги на отдельные сообщения → глубже на каждом этапе
Вместо одного длинного промпта: сначала "извлеки только сущности", потом "для каждой сущности определи атрибуты", потом "установи связи". Модель не торопится к финальному ответу и прорабатывает каждый шаг полнее.
Адаптация 2: "Красная команда" через LLM-as-a-Judge
🔧 Попроси судью найти слабости одного варианта — не сравнивать два
Модифицируй промпт оценки: убери вариант B, замени "Победитель: A|B" на "Список проблем по критериям". Получишь детальный разбор слабых мест одного текста/документа — как критика от строгого эксперта.
...
Вариант для анализа: {текст}
Задача: найди конкретные слабые места по каждому критерию.
Не нужно называть победителя — нужен список: что именно и почему слабо,
с цитатами из текста.
Выдай:
Критерий 1 — оценка + что конкретно слабое
Критерий 2 — ...
...
Итоговая рекомендация: 1–2 самых важных улучшения
Адаптация 3: Применение за пределами UML — оценка любого структурированного документа
Принцип LLM-as-a-Judge с 5-критериальной рубрикой переносится на любой домен, где есть "требования" и "результат":
| Контекст | Критерии оценки |
|---|---|
| ТЗ для фрилансера | Полнота, Однозначность, Измеримость, Структура, Соответствие бюджету |
| Коммерческое предложение | Ценностное предложение, Доказательства, Ясность, Соответствие боли клиента, Призыв к действию |
| Контент-план | Охват тем, Разнообразие форматов, Регулярность, Соответствие аудитории, Практическая ценность |
Ресурсы
Class Model Generation from Requirements using Large Language Models Jackson Nguyen, Rui En Koe, Fanyu Wang, Chetan Arora, Alessio Ferrari Monash University (Melbourne, Australia) + University College Dublin (Ирландия) MSSiS '26, April 2026, Rio de Janeiro, Brazil DOI: https://doi.org/10.1145/3786146.3788643 Артефакты: https://github.com/jackson0076/FIT4701-GenAI/ PlantUML онлайн-редактор: https://www.planttext.com/