XYBench - бенчмарк из 8 115 реальных вопросов, который проверяет, замечает ли AI-ассистент подмену задачи: человек просит помочь с подходом Y, хотя его настоящая цель X требует другого решения. Тест подготовили исследователи Ai2 совместно с Carnegie Mellon, NVIDIA и Johns Hopkins; анонс и детали опубликованы в блоге Ai2 на Hugging Face.
Короткий ответ на главный вопрос: ассистенты отвечают на буквальный запрос чаще, чем на реальную задачу. Claude Sonnet 4.6, GPT-5, Gemini 3.1 Pro, Qwen3.5-9B и DeepSeek-V4 Pro в тестах часто предлагали решение проблемы пользователя, но сохраняли фокус ответа на исходном ошибочном подходе. Человеческие референтные ответы уводили от такого подхода чаще всех пяти моделей.
Второй результат меняет взгляд на практику: в режиме выбора из двух ответов те же модели в 71-84% случаев верно определяли полезный вариант. Хороший совет модель узнаёт, а вот сгенерировать его сама, поставив под сомнение предпосылку вопроса, у неё получается хуже.
Что такое XY-проблема и почему ассистент отвечает не на тот вопрос
XY-проблема - это несоответствие между подходом, о котором спрашивает человек, и целью, которую он хочет достичь. Формулировка из анонса XYBench: человек хочет получить X, предполагает, что подход Y сработает, и просит помочь с Y.
Пример из бытовой жизни, который приводит команда бенчмарка: пользователь спрашивает, как сделать глазурь гуще, чтобы она не сползала с капкейков. Настоящая проблема в другом - капкейки ещё слишком тёплые для нанесения глазури. Ответ «добавьте больше сахарной пудры» формально решает Y и портит результат по X.
В разработке та же схема встречается постоянно. Иллюстрация, не связанная с тестами XYBench: человек просит «как ускорить этот SQL-запрос», хотя его цель - чтобы страница открывалась быстрее, и правильнее поставить кэш перед базой. Модель охотно берётся за индексы и переписывание джойнов.
Причина предсказуемая. Запрос Y сформулирован явно, со всеми деталями, а X нужно выводить из контекста или из неполного описания. Модель, натренированная следовать инструкции, видит ясную задачу и выполняет её. Для человека-эксперта переспросить «а зачем тебе это?» - обычная практика. Для ассистента это отдельный навык, и именно его проверяет бенчмарк.
Чем XY-проблема отличается от просто плохо сформулированного вопроса
При плохом запросе непонятно, чего хочет пользователь: он написал «не работает», не приложил лог и не назвал версию. При XY-проблеме запрос понятен полностью, он может быть технически грамотным и подробным, с кодом, командами и конфигом. Не ведёт к цели выбранный подход, а не формулировка.
Отсюда и ловушка: чем качественнее описан Y, тем охотнее модель отвечает на него. Авторы XYBench отфильтровали случаи, где ответ на буквальный запрос в основном решал бы проблему. В датасете остались именно ситуации, где буквального ответа недостаточно.
Как устроен XYBench: 8 115 реальных вопросов из четырёх источников
Состав датасета: 1 557 вопросов из Stack Overflow, 184 из Stack Exchange, 102 вручную курированных примера и 6 272 вопроса, сгенерированных из руководств WikiHow. Сумма даёт те самые 8 115 вопросов.
Для каждого вопроса размечены два поля: заявленный запрос (Y), то есть то, что человек просит явно, и подразумеваемый запрос (X), то есть цель, которую можно вывести из контекста. Для вопросов с публичных форумов разметку X и возможные решения устанавливали по трём наиболее высоко оценённым человеческим ответам и принятому ответу, где он был доступен. Это разумный ход: люди в комментариях к таким вопросам почти всегда объясняют, почему исходный подход не сработает.
Из выборки убрали случаи, где ответ на буквальный запрос в основном решал бы проблему. Без этого фильтра бенчмарк измерял бы качество обычного ответа, а не способность увидеть подмену задачи.
На EMNLP 2026 XYBench получил награду Best Resource Paper Award, то есть рецензенты признали ценность самого набора данных и методики, а не только результатов моделей.
Как генерировали вопросы из WikiHow и что это значит для интерпретации
WikiHow дал самую большую часть датасета. Вопросы вокруг правдоподобных ошибочных представлений в процедурных руководствах генерировала Sonnet 4.5. Затем их дорабатывали так, чтобы эксперт мог вывести подразумеваемую цель, не заявленную прямо, но чтобы при этом контекста хватало для разумного вывода.
Практический вывод: 6 272 из 8 115 вопросов - сгенерированная часть. Это не делает бенчмарк плохим, но означает, что выводы по кулинарным и бытовым процедурам стоит держать отдельно от выводов по реальным форумным вопросам про код. Синтетическая часть проверяет рассуждение о бытовых процедурах, форумная - поведение на живых технических запросах с историей обсуждения.
Три метрики XYBench: что именно оценивают в ответах моделей
Оценка ответа раскладывается на три группы критериев:
- есть ли в ответе рабочее решение заявленного запроса Y;
- есть ли решение истинного запроса X;
- на чём модель расставляет акцент и идентифицирует ли она ошибочное допущение пользователя.
Все три нужны, потому что по отдельности каждая обманывает. Ответ может дать полезный совет по X, но не предупредить, что Y приведёт к тупику, и человек продолжит копать в неверном направлении. Обратный случай: модель долго и подробно разбирает Y, а про реальную цель упоминает одной строкой в конце. Формально решение X в ответе есть, фактически внимание пользователя осталось на ошибочном подходе.
Иллюстрация разбора, а не реальный результат теста. Запрос: «посоветуйте пылесос помощнее, ковёр плохо чистится». Ответ в духе «возьмите модель с большей мощностью всасывания, вот три варианта» закрывает Y и не решает X, если причина в забитом фильтре или в неподходящей насадке. Ответ, который сначала предлагает проверить фильтр и насадку, а потом уже говорит про мощность, идентифицирует ошибочное допущение и уводит от лишней покупки. Опубликованный фрагмент анонса обрывается на разделе «Evaluating how an answer helps», поэтому точные формулировки критериев стоит сверять по полной статье.
Результаты: модели отвечают на буквальный вопрос, но узнают хороший совет
На XYBench оценивали пять моделей: Claude Sonnet 4.6, GPT-5, Gemini 3.1 Pro, Qwen3.5-9B и DeepSeek-V4 Pro. Общая картина одинаковая для всех: модели часто предлагали решение проблемы пользователя, но сохраняли фокус ответа на исходном, ошибочном подходе. По сравнению с человеческими референтными ответами все пять моделей реже уводили пользователя от такого подхода к решению, подходящему для его цели.
Разрыв особенно заметен рядом со вторым результатом: в режиме выбора из двух ответов те же модели в 71-84% случаев верно определяли полезный ответ. То есть модель отличает хороший совет от плохого, когда видит оба варианта рядом, и не демонстрирует того же уровня в свободной генерации.
Рейтинг моделей по этим данным строить не на чем: в анонсе нет разбивки результатов по каждой модели с числами, а различия между пятью участниками описываются общей формулировкой. Утверждать, что одна из них «лучше видит XY-проблему», на основании этого материала нельзя.
Почему распознать хороший ответ проще, чем сгенерировать его
Гипотеза первая: при выборе из двух вариантов у модели есть точка сравнения. Один из ответов ставит под сомнение предпосылку, второй нет, и задача сводится к оценке готового текста. При генерации ставить предпосылку под сомнение нужно самостоятельно, без внешней подсказки.
Гипотеза вторая, связанная с обучением: ассистентов настраивают быть полезными и следовать инструкции. Буквальный ответ на Y выглядит как выполнение запроса, а встречный вопрос «точно ли тебе нужен Y» рискует показаться уходом от задачи. Это объяснение, а не доказанный в бенчмарке факт; авторы в анонсе не разбирают причины разрыва.
Что это значит на практике: как заставить ассистента увидеть XY-проблему
Приёмы ниже - следствие из результатов бенчмарка, а не протестированная методика с гарантированным эффектом. Поведение зависит от модели, длины контекста и формулировки задачи.
- Называйте цель X прямо в промпте. Формулировка «я хочу добиться X, планирую делать Y, проверь, подходит ли Y» даёт модели тот контекст, которого ей обычно не хватает.
- Просите сначала проверить предпосылки, потом отвечать. Отдельный пункт в промпте: «до ответа оцени, ведёт ли предложенный подход к цели, и укажи, если есть более короткий путь».
- Пропишите в системной инструкции переспрашивать о цели при неоднозначности. Для агентов и встроенных ассистентов это делается на уровне конфигурации, а не разово в чате.
- Читайте ответ с проверкой: решает ли он X или только Y. Если в ответе подробно разобран Y и одна строка про X, считайте, что XY-проблема не распознана.
- Для локальных моделей те же приёмы актуальны, но проверять поведение нужно на своих задачах: Qwen3.5-9B входит в список оценённых моделей, однако результатов по ней отдельно в анонсе не приводится.
Шаблон промпта для проверки предпосылок
Моя цель - X (что должно получиться в итоге и зачем). Я собираюсь сделать Y, потому что Z. Прежде чем помогать с Y: 1) скажи, ведёт ли Y к X, и при каких условиях; 2) если нет, предложи альтернативу и объясни, почему она лучше; 3) перечисли допущения, которые я мог не проверить. После этого дай инструкции по выбранному пути.
Шаблон копируется как есть, но это иллюстрация подхода, а не проверенное решение. Если Z в вашем случае не формулируется, значит вы ещё не нашли настоящую цель, и никакая модель за вас её не угадает.
Ограничения XYBench и как относиться к его выводам
Первое ограничение - состав. Большая часть вопросов, 6 272 штуки, сгенерирована из WikiHow через Sonnet 4.5. Это синтетика, пусть и построенная по реальным процедурным руководствам.
Второе - опора на человеческие ответы. Для форумной части X и возможные решения выводились из трёх лучших ответов и принятого ответа. Люди тоже ошибаются, а принятый ответ бывает устаревшим; такие ошибки попадают в разметку.
Третье - оценка по трём метрикам включает суждение «на чём модель делает акцент». Такая оценка требует разметчиков или модели-судьи, и здесь всегда есть пространство для интерпретации. Четвёртое - выборка отфильтрована: случаи, где буквальный ответ решал бы проблему, удалены, поэтому процент «провалов» в реальном чате будет ниже, чем в бенчмарке.
Общий контекст тоже стоит держать в голове: методики оценки AI-моделей пока незрелы, и сравнивать лидерборды между собой без оговорок нельзя. Об этом подробно говорит директор по политике Hugging Face Айрин Солаиман. Отдельная известная проблема - подгонка моделей под популярные тесты; на русскоязычном материале AI-Manual разобрано, как аудит выявляет признаки такой подгонки у китайских LLM.
Сам XYBench задуман как инструмент для исследователей: он помогает измерять, делают ли улучшения моделей ассистентов лучше в распознавании ошибочных допущений, объяснении, почему предложенный подход может не работать, и предложении более эффективных альтернатив. Вывод вида «модель X плохая» из одного бенчмарка не следует.
Кому и зачем нужен XYBench: разработчикам, поддержке и всем, кто полагается на ассистента
Разработчикам XY-проблема обходится дороже всего, потому что отладка идёт внутри неверного подхода. Ассистент, который послушно правит regex вместо перехода на парсер, экономит минуту и стоит дня. XYBench даёт язык для описания этой проблемы и подсказывает, что проверять при выборе модели для работы с кодом; те же вопросы стоит задавать и к бенчмаркам вроде Real-SWE, где заявка на «реальные задачи разработки» пока не подкреплена деталями методологии.
Техподдержке и продакт-менеджерам полезно помнить, что формулировка запроса определяет, получите вы решение или инструкцию по тупиковому пути. Требование проговаривать цель X в тикете или в промпте к внутреннему ассистенту снижает риск ответа не на тот вопрос.
Исследователям XYBench полезен как готовый ресурс с разметкой X и Y и как пример того, как отделять распознавание от генерации. Следить за обновлениями удобно через Daily Papers на Hugging Face: анонс XYBench опубликован именно там, рядом с карточками моделей и датасетов. Условия доступа и лицензию бенчмарка в этом материале не приводим: в анонсе их нет.
Практический шаг на сегодня: возьмите один свой типовой запрос к ассистенту, добавьте в него цель X и пункт «проверь, ведёт ли мой план к этой цели», и сравните ответ с обычным. Это дешевле, чем менять модель, и сразу показывает, насколько ваш инструмент склонен отвечать на буквальный вопрос.