TL;DR
Исследователи прогнали 5 моделей (GPT-4o, Claude, Llama, Mistral, Qwen) через задачу генерации двух видов документов — один со строгим фиксированным форматом (паспорт батареи по еврорегуляции), другой с расплывчатыми требованиями (оценка рисков обработки персональных данных). Каждую задачу давали с четырьмя уровнями детализации промпта — от почти пустого до максимально подробного с явным перечнем разделов — и смотрели, насколько стабильно и полно модель выдаёт результат при повторных запусках.
Главная находка неожиданная: для расплывчатых задач промпт "средней подробности" оказался хуже, чем совсем скудный. Когда модели дали краткое обобщение требований (без разбивки на подпункты), она каждый раз собирала документ по-разному — то включит один блок, то другой, консистентность падала до 3 из 4 повторов совпадающих по структуре. А вот когда модели вообще не давали деталей — она вырабатывала свой стабильный шаблон "по умолчанию" и держалась его. Хуже всего работает именно половинчатая инструкция: она даёт модели повод "довыдумывать", но не даёт чёткой структуры, чтобы делать это одинаково каждый раз.
Для задач со строгим заранее заданным форматом (как техническая форма) детализация промпта почти не важна — модели стабильно попадают в структуру независимо от контекста. Но за эту стабильность приходится платить: чем строже загнать модель в формат, тем выше риск, что она придумает значение для поля, данных для которого физически нет в исходнике.
Схема метода
ШАГ 1: Определи тип задачи → жёсткий шаблон (форма, таблица) или расплывчатое требование (отчёт, риск-анализ)
ШАГ 2 (если задача расплывчатая): Разбей требования на явный пронумерованный список разделов и подпунктов
→ не давай "краткое резюме требований", это провоцирует нестабильность
ШАГ 3: Добавь запрет на выдумывание ("не изобретай значения, оставь поле пустым, если данных нет")
ШАГ 4: Проверь консистентность — прогони промпт 2-3 раза и сравни структуру ответов
Все шаги выполняются в одном промпте — единственное "многошаговое" действие, требующее отдельного запроса, это проверка стабильности (шаг 4).
Пример применения
Задача: Служба безопасности маркетплейса (условно, как у Ozon или Wildberries) внедряет систему видеонаблюдения и трекинга эффективности сотрудников на складе. По 152-ФЗ (аналог GDPR в России) нужно составить оценку рисков обработки персональных данных перед запуском системы. Юрист не хочет каждый раз получать документ разной структуры от нейросети.
Промпт:
Ты — специалист по защите персональных данных. Составь оценку рисков
обработки персональных данных для следующей ситуации:
Компания внедряет систему видеонаблюдения и трекинга эффективности
для 3000 сотрудников складов в 12 городах. Система собирает:
видеозаписи, данные геолокации погрузчиков, биометрию на входе,
показатели производительности. Данные используются для автоматического
формирования рейтингов и передаются в HR для кадровых решений.
Документ должен включать РОВНО следующие разделы, каждый — отдельным блоком:
1. Описание обработки: какие данные собираются, у кого, с какой целью,
как они перемещаются внутри компании, сколько хранятся
2. Оценка необходимости и соразмерности: можно ли достичь цели с меньшим
объёмом данных, какое правовое основание для обработки, как соблюдаются
права субъектов данных
3. Оценка рисков для прав и свобод сотрудников: что может пойти не так,
насколько вероятно, насколько серьёзен вред, есть ли уязвимые группы
4. Меры по снижению рисков: технические меры защиты, организационные
политики, остаточный риск после мер
Требования:
- Не смешивай данные из разных объектов/городов
- Если для какого-то пункта нет данных в описании — оставь поле пустым,
не придумывай значения
- Ответ дай в структурированном виде с явными заголовками разделов
Результат: Модель выдаст документ из четырёх чётко озаглавленных блоков, соответствующих структуре промпта. При повторных запросах с этим же промптом структура и состав разделов будут воспроизводиться стабильно — в отличие от того, если бы вы просто попросили "составь оценку рисков по 152-ФЗ" без разбивки.
Почему это работает
У LLM нет встроенного чек-листа для расплывчатых задач. Когда вы даёте общее описание требований без разбивки на пункты, модель каждый раз сама решает, что включить и в каком порядке — получается лотерея структуры.
Зато модель отлично умеет повторять заданный паттерн, если ей дать явный, исчерпывающий список пунктов. Это её сильная сторона — не творческая интерпретация с нуля, а точное следование структуре, которую вы уже расписали.
Метод использует это: убирает у модели необходимость "додумывать" структуру, заменяя её готовым скелетом. Модель просто заполняет уже размеченные блоки — и делает это одинаково от запуска к запуску.
Рычаги управления: - Уровень детализации структуры (от общего резюме до пронумерованного списка подпунктов) → чем расплывчатее исходная задача, тем детальнее нужен список разделов - Запрет на выдумывание ("не изобретай значения, оставь пустым") → снижает количество придуманных данных, но может увеличить число пустых полей - Явное указание "сохраняй именно эту структуру" → полезно, если задаёте готовый шаблон (таблицу, форму)
Ограничения
⚠️ Модели ведут себя по-разному: в исследовании только Claude показал резкую нестабильность на промпте средней детализации (до 3 из 4 совпадающих запусков), тогда как GPT-4o и Qwen держали идеальную консистентность на всех уровнях. Значит, перед тем как довериться подходу, стоит проверить конкретную модель — вывод не универсален для всех LLM одинаково.
⚠️ Строгая детализация повышает риск выдумывания данных: чем жёстче заданный шаблон обязательных полей, тем выше шанс, что модель заполнит поле придуманным значением, если реальных данных для него нет. Явный запрет частично, но не полностью решает эту проблему.
⚠️ Проверено только на двух типах документов: выводы построены на одном строгом (паспорт батареи) и одном расплывчатом (оценка рисков данных) кейсе. Для других типов задач (творческие тексты, код, аналитика) закономерность может проявляться иначе.
Как исследовали
Команда прогнала пять моделей — GPT-4o, Claude, открытые Llama-3.1, Mistral-7B и Qwen2.5 — через две задачи: составление паспорта батареи по строгому европейскому стандарту (AAS) и оценки рисков персональных данных по расплывчатым требованиям GDPR. Каждую задачу давали с четырьмя уровнями детализации промпта: базовый (полный текст регуляции), высокий, средний, низкий контекст — и каждую комбинацию гоняли по три раза, всего 120 запусков.
Результаты сравнивали с вручную составленным эталонным документом, проверяя два параметра: консистентность (одинаковая ли структура при повторных запусках) и полноту (сколько обязательных полей заполнено). Именно контролируемая матрица "модель × уровень детализации × тип задачи" делает находку убедительной — это не случайное наблюдение на одном прогоне, а системная закономерность.
Удивило то, что для расплывчатой задачи средний уровень детализации оказался хуже низкого — промпт, который просто пересказывает требования словами (без разбивки на пункты), сбивает модель сильнее, чем полное отсутствие инструкций. Практический вывод: если задача сама по себе нечёткая, не пытайтесь "объяснить своими словами" — сразу дайте явный пронумерованный список.
Ресурсы
From Regulation to Implementation: A Critical Evaluation of LLM-Assisted Regulatory Compliance in Industry — Adriana Watson, Marco Bücheler, Grant Richards, Purdue University (School of Engineering Technology). В работе используются стандарт Asset Administration Shell (AAS), шаблон IDTA-02003-6 для паспорта батареи и требования GDPR Article 35(7) для DPIA.