TL;DR
Когда вы спрашиваете ИИ "как сделать X", а на самом деле X — это неправильный метод для решения задачи Y, модель почти всегда просто помогает с X. Она не останавливает вас и не говорит "стоп, это не тот путь" — даже если внутри неё есть понимание, что путь неверный.
Представьте: вы спрашиваете "как распарсить XML через регулярные выражения". Модель с вероятностью 75-92% просто даст вам регулярку. Хотя правильный ответ — "используй XML-парсер, регулярки для этого не годятся" — модель озвучивает такой ответ только в 33-71% случаев. Самое неожиданное: если дать модели те же два варианта ответа и спросить "какой лучше?", она в 84% случаев выберет правильный, прагматичный вариант. Но сама, без подсказки, она его не сгенерирует.
Разница видна на цифрах: люди-эксперты замечают ошибку в подходе пользователя в 79-90% случаев, у моделей — максимум 60-63%. Причина не в незнании — модель "знает" лучший ответ (это доказывает тест с выбором), но не активирует это знание, если её не попросить явно сравнить подходы. Значит, если вы явно попросите модель сопоставить ваш метод с альтернативами — вероятность получить полезный совет резко растёт.
Схема метода
Это не техника из статьи, а вывод, который можно превратить в приём для чата:
ШАГ 1 (в одном промпте): Опиши реальную цель, а не только выбранный метод → явная формулировка "чего я хочу добиться"
ШАГ 2 (в том же промпте): Попроси модель явно сравнить твой метод с альтернативами → выбор между вариантами вместо свободного ответа
Механика по данным исследования: когда модели дают выбор между "ответить в лоб" и "ответить по существу проблемы" — она выбирает по существу в 84% случаев. Значит, задача пользователя — самому создать этот "выбор" внутри промпта.
Пример применения
Ограничение метода: работает лучше для процедурных ошибок (человек выбрал неправильный инструмент/способ), хуже для чисто фактических вопросов.
Задача: Владелец интернет-магазина на Wildberries хочет протестировать 5 разных заголовков на карточке товара и вручную создаёт 5 копий карточки, чтобы вручную менять и сравнивать конверсию.
Промпт:
Мне нужно протестировать 5 разных заголовков карточки товара на Wildberries.
Сейчас я планирую создать 5 отдельных копий карточки и вручную менять заголовки,
а потом сравнивать продажи за неделю на каждой.
Прежде чем помогать мне с этим планом, ответь на два вопроса:
1. Какая моя настоящая цель — не как я планирую это делать, а что я хочу получить в итоге?
2. Есть ли более эффективный способ достичь этой цели, чем создание 5 копий карточки вручную?
Если да — прямо скажи, в чём слабость моего текущего плана, и предложи лучшую альтернативу.
После этого дай мне пошаговый план — либо по моему исходному способу, либо по альтернативе.
Результат: Модель сначала сформулирует настоящую цель ("найти заголовок с максимальной конверсией без потери позиции карточки в поиске"), затем укажет слабость ручного A/B-теста (искажение из-за сезонности, потеря позиций из-за дублей, долгий срок теста) и предложит альтернативу — встроенные инструменты аналитики WB Advertising или сервисы сплит-тестирования карточек. В конце — конкретный план действий по лучшему варианту.
Почему это работает
Модели обучены буквально выполнять инструкции — это тренированное поведение, а не баг. Когда вы просите "как сделать X", модель по умолчанию отвечает про X, а не проверяет, была ли выбрана правильная цель.
Но у модели есть скрытая сила: она хорошо сравнивает готовые варианты, если их явно предъявить. Исследование показало — стоит дать модели выбор "ответ А или ответ Б", и она в 84% случаев выбирает более полезный. Проблема не в знаниях модели, а в том, что при свободной генерации это знание не включается автоматически.
Приём выше искусственно создаёт этот "выбор" внутри одного запроса — вы просите модель сначала явно сформулировать цель и сравнить подходы, а потом уже отвечать. Это переносит задачу из режима "свободная генерация" (где модель слабая) в режим "сравнение вариантов" (где модель сильная).
Рычаги управления: - Уберите вопрос "какая моя настоящая цель" → модель вернётся к буквальному ответу на ваш вопрос, минуя проверку. - Добавьте "оцени риски моего текущего подхода в цифрах/времени" → модель конкретнее объяснит цену ошибки. - Для технических задач добавьте "представь, что ты сеньор-разработчик, которого попросили сделать код-ревью моего плана" → роль экспертов усиливает готовность указывать на ошибки (люди-эксперты в исследовании справлялись значительно лучше моделей).
Шаблон промпта
Мне нужно {конкретная задача}. Сейчас я планирую делать это через {ваш метод/инструмент}.
Прежде чем помогать с этим планом, ответь на два вопроса:
1. Какая моя настоящая цель — не способ, а результат, который я хочу получить?
2. Есть ли более эффективный способ достичь этой цели, чем {ваш метод}?
Если да — прямо укажи слабость текущего плана и предложи лучшую альтернативу.
После этого дай план действий — по исходному способу или по альтернативе, в зависимости от твоего ответа.
Подставляйте: {конкретная задача} — то, чего вы хотите добиться в итоге; {ваш метод/инструмент} — конкретный способ, который вы уже выбрали и который может быть не оптимальным.
🚀 Быстрый старт — вставь в чат:
Вот приём для проверки, не выбрал ли я неправильный способ решения задачи.
Адаптируй его под мою ситуацию: {опишите вашу задачу и метод, который собираетесь использовать}.
[вставить шаблон выше]
LLM спросит детали вашей задачи и метода — потому что без конкретики она не сможет сформулировать вашу реальную цель и сравнить альтернативы.
Ограничения
⚠️ Не панацея даже с явной подсказкой: в экспериментах исследователей даже когда модели явно давали и стated-запрос, и intended-запрос (то есть почти всю подсказку решения), разрыв с человеческим уровнем не закрывался полностью. Приём снижает проблему, но не убирает её.
⚠️ Модель может неверно угадать "реальную цель": если в вашем запросе мало контекста, шаг 1 промпта может сформулировать неправильную цель, и весь дальнейший совет будет мимо.
⚠️ Слабее работает на фактических вопросах: приём заточен под ситуации "неправильный метод/инструмент", а не под вопросы типа "правда ли, что...". Для проверки фактов это не тот инструмент.
Как исследовали
Команда собрала 8 115 запросов с "скрытой ошибкой в подходе" (тот самый XY problem — когда человек зацикливается на неправильном методе) из трёх источников: реальные вопросы со Stack Overflow и Stack Exchange, размеченные сообществом как "XY problem" (1741 штука), синтетические бытовые запросы, сгенерированные из статей WikiHow (6272 штуки), и вручную собранные случаи из Reddit и рабочих переписок (102 штуки).
Для каждого запроса выделили три параметра ответа: решает ли ответ буквальный запрос, называет ли модель саму ошибку в подходе, и предлагает ли решение настоящей проблемы. Дальше протестировали 5 топовых моделей (3 закрытых, 2 открытых) и сравнили их с ответами живых людей-экспертов на тех же вопросах.
Самое интересное — тест с множественным выбором. Когда моделям дали и буквальный, и "правильный" вариант ответа и попросили выбрать лучший, они выбирали правильный в 84% случаев. Но когда тех же моделей просто просили ответить на вопрос свободно — правильный, прагматичный ответ появлялся значительно реже. Это разошлось с ожиданием исследователей: получилось, что дело не в отсутствии знаний у модели, а в том, что свободная генерация "не достаёт" это знание без явной подсказки сравнить варианты.
Ресурсы
XYBench (Akhila Yerukola, Jena D. Hwang, Mingqian Zheng и др., Carnegie Mellon University, Allen Institute for AI, NVIDIA, Johns Hopkins University). Код и датасет: github.com/Akhila-Yerukola/XYBench