Суть. LLM отлично отвечают на то, что их прямо попросили (S-request), но систематически проваливают истинный запрос пользователя (I-request), когда в вопросе заложена ошибка в постановке задачи. Это классический XY-проблема: пользователь спрашивает, как забить гвоздь микроскопом (X), а на самом деле хочет просто повесить картину (Y). Работа вводит бенчмарк XYBench (8115 запросов) и показывает, что даже топ-модели в 2–3 раза реже людей выявляют и корректируют такие заблуждения. Как это работает: три измерения кооперативного ответа Кооперативный ответ на запрос с заблуждением должен включать три компонента: S-solution — ответ на буквальный запрос (можно с отказом, если решения нет). S-I-misconception-identification — объяснение, почему подход пользователя ошибочен. I-solution — альтернативное решение, которое решает настоящую проблему. Метрика оценки (LLM-as-a-judge): Из ответа извлекаются все «предложения действий» (approach units). Каждое тегируется: относится к S-решению, I-решению или ни к чему. Определяется акцент ответа: literal (S), pragmatic (I) или balanced. Misconception-identification фиксируется, если ответ отговаривает от S-подхода и поощряет I-подход (или полностью переключается на I, не развлекая S). Сквозной пример из бенчмарка Запрос (WikiHow, cupcake-кейс): «The frosting on my cupcakes keeps sliding off, what can I add to make the icing thicker and more solid?» S-request: «Как сделать глазурь гуще» (добавить крахмал и т.п.) I-request: «Как заставить глазурь не сползать» → настоящая причина: кексы не остыли, глазурь тает Что делает хороший (кооперативный) ответ: Не советует сразу утолщать глазурь (или советует, но как временную меру). Объясняет: глазурь сползает, потому что кексы тёплые — она плавится. Предлагает дать кексам полностью остыть перед глазированием. Что делают современные LLM (по данным работы): в 0.57–0.91 случаев дают S-решение, но I-решение — лишь в 0.33–0.71. Акцент на прагматическом решении — всего 22–41% против 52–60% у людей. Готовый промпт-шаблон для отлова XY-проблем Цель: заставить модель не просто отвечать, а сначала диагностировать, не ошибается ли пользователь в постановке. Ты — эксперт-консультант. Твоя задача — не просто ответить на вопрос, а понять, что пользователь на самом деле хочет сделать. Запрос пользователя: {{QUERY}} Проанализируй запрос в три шага: 1. Что пользователь просит буквально? (S-request) 2. Какая может быть настоящая цель? (I-request) — если запрос содержит типичную ошибку новичка, неэффективный подход или неверное предположение. 3. Дай ответ, который: - Кратко отвечает на буквальный вопрос (если это безопасно). - Объясняет, почему буквальный подход может быть проблематичным. - Предлагает альтернативу, которая решает настоящую цель. Важно: не просто добавь альтернативу в конец — сделай её основным фокусом ответа, если буквальный запрос ведёт в тупик. Границы применимости Когда метод полезен: Техподдержка, IT-консультации, обучение, DIY-советы — везде, где пользователь может «зафиксироваться» на одном инструменте. Запросы с формулировками «как сделать X с помощью Y», где Y — явно неоптимальный инструмент. Когда метод бесполезен или вреден: Фактоидные вопросы («столица Франции?») — здесь нет скрытой цели. Творческие запросы («напиши стих») — диагностика заблуждения не имеет смысла. Если модель ошибочно «усматривает» XY-проблему там, где её нет — это приведёт к навязчивым «правильным» ответам вместо прямых. Экстренные сценарии — пользователю нужен немедленный ответ на буквальный вопрос, а не лекция. Главный неожиданный вывод: в MCQ-формате модели выбирают прагматичный ответ в 84% случаев, но в свободной генерации проваливаются. Проблема не в том, что модель «не знает», а в том, что она не умеет самостоятельно переключиться с буквального следования инструкции на кооперативное перенаправление. Даже когда модель опознаёт заблуждение, I-решение включается лишь в 36–85% ответов Исследование https://arxiv.org/html/2609.06842v1