TL;DR
Каждый пятый реальный запрос к LLM содержит паттерн, который гарантированно ухудшает результат — не потому что модель слабая, а потому что сам запрос сконструирован неправильно. Исследователи проанализировали реальные диалоги и выделили 7 таких паттернов. Это не техника промптинга — это диагностическая карта: знаешь паттерны, можешь найти слабости в своём запросе до того, как они сломают диалог.
Главная находка: даже топовые модели справляются меньше чем с 40% задач, если пользователь ведёт себя как большинство реальных людей. Самый частый виновник — underspecification (недоуточнённый запрос): пользователь не даёт достаточно информации, и модель начинает угадывать — часто не то. На втором месте — информационная перегрузка: слишком много нерелевантных деталей сбивают модель с фокуса.
Таксономия из 7 паттернов — это чеклист для самопроверки: пробегаешься перед отправкой сложного запроса и убираешь слабые места. Работает в один шаг, в обычном чате.
Схема метода
Это не пошаговый алгоритм, а классификатор проблем в запросе:
1. Ideal Rational → ✅ нормально: чёткая задача, все данные, логика ясна
2. Underspecification → ❌ расплывчато, пропущены ключевые детали
3. Information Overload → ❌ слишком много нерелевантного, модель теряет суть
4. Fabricated Parameters→ ❌ пользователь путает или выдумывает факты
5. Goal Switching → ❌ цель меняется в середине диалога
6. Contradictory Constraints → ❌ взаимоисключающие требования
7. Impatience/Hostility → ❌ давление и агрессия вместо чёткости
Применяется в один шаг: берёшь черновой запрос, сверяешь по чеклисту, правишь.
Пример применения
Задача: Хочешь попросить ChatGPT помочь составить письмо поставщику с условиями контракта.
Плохой запрос (сразу три паттерна):
Напиши письмо поставщику насчёт контракта. Мы с ними давно работаем,
вроде всё норм, но хочется чтобы было правильно. Там что-то про оплату
и сроки. У нас была история с другим поставщиком — они подвели,
поэтому хочется подстраховаться. Ну ты понимаешь.
Диагностика: - ❌ Underspecification: нет конкретных условий — суммы, сроков, штрафов - ❌ Information Overload: история с другим поставщиком — это шум, не данные - ❌ Fabricated Parameters: «вроде всё норм» — размытая предпосылка
Исправленный промпт:
Помоги составить деловое письмо поставщику ООО «Альфа-Логистик»
с предложением условий контракта на поставку.
Условия:
- Объём: 500 единиц в месяц
- Оплата: 50% предоплата, 50% в течение 14 дней после поставки
- Штраф за задержку: 1% от суммы партии за каждый день просрочки
- Срок действия: 12 месяцев с автопролонгацией
Тон — деловой, конкретный, без лирики. Максимум 1 страница.
Результат: Модель получит чёткую задачу без пробелов. Письмо выйдет с первого раза — без уточнений, без «вы имели в виду...?»
Почему это работает
Модель не "понимает" — она заполняет пробелы. Когда в запросе чего-то не хватает, LLM не останавливается и не спрашивает — она генерирует наиболее вероятное продолжение. Иногда угадывает. Чаще — нет. Это и есть underspecification в действии: модель додумывает то, что вы не сказали.
Больше слов ≠ больше понимания. Информационная перегрузка работает против вас: когда в запросе много нерелевантных деталей, каждое слово теряет вес. История с предыдущим поставщиком — не данные для задачи, а шум, который тянет внимание модели в сторону.
Противоречия не разрешаются автоматически. Если в запросе взаимоисключающие требования («сделай коротко и подробно», «формально, но с юмором») — модель выберет одно или попытается усидеть на двух стульях. Результат будет размытым. Исследование показало, что это один из самых вредоносных паттернов.
Шаблон промпта — чеклист перед отправкой
Проверь мой запрос по 7 паттернам проблемного поведения пользователя
и скажи, что починить:
МОЙ ЗАПРОС:
{вставь свой черновой запрос}
ПРОВЕРЬ ПО КАЖДОМУ ПАТТЕРНУ:
1. Underspecification — есть ли пробелы в данных?
Что модель вынуждена угадывать?
2. Information Overload — есть ли детали, которые уводят от задачи?
Что можно убрать?
3. Fabricated Parameters — есть ли непроверенные факты или предположения,
которые я выдаю за данные?
4. Goal Switching — не меняется ли цель в середине запроса?
5. Contradictory Constraints — нет ли взаимоисключающих требований?
6. Impatience/Hostility — не давлю ли я на модель
в ущерб чёткости задачи?
По каждому пункту: ✅ ОК / ❌ Проблема + что именно исправить.
В конце дай исправленную версию запроса.
Плейсхолдер: {вставь свой черновой запрос} — любой запрос, который не даёт хорошего результата с первого раза.
🚀 Быстрый старт — вставь в чат:
Вот чеклист проверки промптов по 7 паттернам проблемного поведения.
Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы понять что именно проверять.
[вставить шаблон выше]
LLM спросит какой запрос ты хочешь проверить и какова конечная задача — потому что без конкретного запроса аудит невозможен. Она возьмёт структуру чеклиста и пройдётся по твоему черновику.
Ограничения
⚠️ Диагностика, не рецепт: Таксономия объясняет почему ломается диалог, но не даёт формулу как писать лучше — нужно применять самостоятельно.
⚠️ Работает на сложных задачах: Для простого вопроса чеклист избыточен. Ценность — в многошаговых, деловых, технических и аналитических запросах.
⚠️ Impatience/Hostility — особый случай: Раздражённый тон почти не влияет на точность рассуждений модели, но делает её более уступчивой и менее точной — она чаще соглашается, реже уточняет.
⚠️ Исследование на инструментальных задачах: Паттерны выведены из диалогов с вызовом внешних инструментов (бронирование, API-запросы). На чисто творческих задачах картина может отличаться.
Как исследовали
Команда из City University of Hong Kong и автопроизводителя Li Auto взяла открытую базу WildChat — миллионы реальных диалогов пользователей с GPT-4 и выше. Случайно выбрали 1000 английских диалогов и попросили GPT-5.4 разметить каждый по 7 категориям. Так получили карту реального поведения — не синтетику, а живые данные.
Оказалось: 22.6% всех реальных диалогов попадают в один из проблемных паттернов. Лидер — underspecification. Потом — information overload и fabricated parameters. Goal switching и агрессия появляются преимущественно в длинных диалогах на поздних ходах — когда пользователь уже устал или разочарован.
На основе этой карты собрали RUT-Bench: 1638 сценариев в 59 средах — бронирование, управление конфигурациями, поиск информации. Протестировали 19 моделей: GPT-5.4, Claude-4.6-Opus, Gemini-3.1-Pro, DeepSeek-V4-Pro и другие. Результат обескуражил: ни одна модель не преодолела 40%. Лучший — GPT-5.4 с 37.3%. Llama3.1-8B-Instruct — с 1.3%.
Любопытный сюрприз: маленькие плотные модели показали себя так же, как большие разреженные (Qwen-3.5-27B ≈ Qwen-3.5-397B-A17B). Вероятно, у больших разреженных моделей много «спящих» параметров — реально работающих не больше, чем у компактных.
Адаптации и экстраполяции
🔧 Техника: превентивный self-disclosure — назови проблему сам
Если знаешь, что запрос расплывчатый, — скажи это явно вместо того чтобы надеяться что модель угадает:
«Я понимаю, что задача пока сформулирована расплывчато. Вот что знаю точно: [данные]. Вот что пока неясно: [пробелы]. Помоги сначала уточнить что именно нужно, потом выполни.»
Модель не будет угадывать — она перейдёт в режим уточнения. Это использует её силу (умеет задавать вопросы) вместо слабости (заполняет пробелы наугад).
🔧 Техника: явная блокировка Goal Switching
Если боишься, что сам начнёшь менять задачу в процессе:
«Зафиксируй цель в первом абзаце одним предложением. Если я начну менять требования — напоминай мне об исходной цели перед тем как双 принять изменение.»
🔧 Техника: чеклист перед code review или редактурой
Работает не только для своих запросов, но и для проверки чужих ТЗ или брифов — прежде чем передавать задачу команде или подрядчику:
«Проверь этот бриф по 7 паттернам проблемного запроса. Где могут возникнуть недопонимания при выполнении?»
Ресурсы
Beyond Ideal Instruction: A Comprehensive Framework for Evaluating LLMs in Realistic Interactions GitHub: https://github.com/TorresYangX/RUT-Bench
Авторы: Xuan Yang, Hao Xu, Tingfeng Hui, Hongsheng Xin, Kaike Zhang, Chunxiao Liu, Ning Miao
Организации: City University of Hong Kong · Hong Kong Institute of AI for Science · Li Auto Inc. · Beijing University of Posts and Telecommunications