Бенчмарки Мебиуса: зачем IBM учит ИИ проверять собственные вопросы

Для оценки эффективности ИИ уже давно и успешно используют самые разные бенчмарки. Берем модель/агента, выдаем им одинаковый набор задач, считаем долю успешных решений и получаем удобную цифру, по которой можно сравнивать системы между собой.

По результатам используем ту, которая справилась с большим процентом задач. Звучит круто и даже удобно, но, как всегда, есть нюанс: все работает при условии, что сам экзамен составлен правильно. А с этим, как выясняется, бывают проблемы.

Внутри бенчмарка могут оказаться некорректные эталонные ответы, противоречивые условия или правила оценки, которые засчитывают правильное решение как ошибку ^[1], и еще много всего, что исказит итоговый результат.

Летом 2026 года исследователи провели ^[2] независимый аудит четырех бенчмарков для агентов, работающих с внешними инструментами: BFCL v4, τ²-Bench, LiveMCPBench и MCP-Atlas. Эксперты вручную проверили 496 выполненных заданий и в 92 случаях (18,5%) не согласились с автоматической оценкой бенчмарка. Причины оказались разными: от жесткого сравнения с эталоном до нестабильной трактовки критериев самими LLM-судьями. 

Еще одно исследование ^[3] IBM предлагает использовать LLM, чтобы проверять качество самих бенчмарков. Авторы работают с бенчмарками для task-oriented conversational agents — агентов, которые общаются с пользователем и выполняют конкретную задачу рамках заданных правил. Например, оформляют возврат в интернет-магазине или изменяют бронирование. 

Сегодня будем разбираться, что там наделали IBM и как так получилось, что у нас появляются бенчмарки для бенчмарков и почему в мире уже вовсю разворачивается мебиус-системы ИИ.

Почему проблема уже вполне реальная

Прежде чем разбираться, какое именно решение предлагает IBM глянем, насколько сильно уже успели сломаться линейки, которыми мы упорно пытаемся измерить агентов.

T³-Bench, выпущенный в начале 2026 года, представляет собой набор тестов для агентов с высокой социальной ответственностью: им нужно одновременно общаться с пользователем, вызывать инструменты и соблюдать правила бизнеса. Перед выпуском τ³-Bench разработчики отдельно проаудировали задачи из доменов авиаперевозок и ритейла, доставшиеся ему от предыдущих версий τ-Bench. Проверка выявила ошибки в самих тестовых сценариях, поэтому в итоге пришлось исправить 53 задачи: 27 полетных и 26 торговых. Среди проблем оказались неправильные ожидаемые действия, двусмысленные инструкции пользователя, невыполнимые условия и отсутствующие запасные сценарии. 

В нескольких задачах про задержанные рейсы от агента ожидали выплаты компенсации обычным пассажирам экономкласса, хотя собственные правила бенчмарка разрешали ее только определенным категориям клиентов. 

В еще одной задаче эталон бенчмарка требовал отменить бронирование, которое по тем же правилам отменять было нельзя. В ретейле вообще случился возврат кеша через PayPal, притом что такой способ возврата в тестовой среде вообще не поддерживался. 

И вот, мы натолкнулись на живой пример ошибки, записанной в самом правильном ответе — агент справился с заданием, а получил минус в карму.

«Неудачно размеченный набор от вайбкодеров!» — скажете вы, и, возможно, окажетесь правы.

Но вот вам еще исследование ^[4]. Называется оно Measuring what Matters, где команда из 29 экспертов под микроскопом изучила 445 LLM-бенчмарков из крупных конференций по машинному обучению ^[5] и обработке языка.

Авторы обнаружили слабые места практически на всех уровнях: в определении того, какую способность модели вообще хотят измерить; в самих заданиях, используемых метриках и естественно в выводах, которые затем делают на основании полученных баллов.

Есть и еще проблема — соответствие теста тому свойству, которое он якобы измеряет (cоnstruct validity). Если бенчмарк является тестом на рассуждение, то мало просто собрать сложные вопросы и посмотреть на процент правильных ответов. Нужно еще показать, что успех действительно зависит от способности рассуждать, а не, например, от запоминания ^[6] похожих примеров, особенностей формулировки задания или выбранной системы подсчета баллов.

Неудивительно, что в выводах исследования авторы сошлись — мол, такие связи в современных LLM-бенчмарках нередко обоснованы недостаточно хорошо. 

Проблема постепенно становится двухэтажной. Сначала нужно понять, что именно мы хотим измерить, а затем убедиться, что конкретные задания, эталоны и правила оценки действительно это измеряют.

IBM предлагает бенчмарк для бенчмарков

Исследователи IBM Research предлагают ^[7] для бенчмарков task-oriented conversational agents прогонять через LLM-судью уже не самого агента, а задания, которыми его собираются проверять.

LLM-судья — это метод тестирования нейронок, где одна большая языковая модель (например, Fable) оценивает качество ответов других языковых моделей. Метод используется для проверки ИИ в сложных, творческих или открытых задачах, где нет единого правильного ответа.

Для этого они взяли четыре показателя.

Первый — соответствует ли эталонный результат самому заданию.
Если пользователь просит отменить бронирование, а ожидаемое поведение ^[8] внутри бенчмарка требует от агента изменить дату поездки, с тестом явно что-то не так.

Второй — не противоречит ли эталон правилам сервиса.
Даже если действие соответствует просьбе пользователя, оно может быть запрещено регламентом. Например, клиент просит удалить одного пассажира из бронирования, хотя правила разрешают менять данные пассажиров, но не их количество. 

Еще две метрики отвечают уже не столько за корректность, сколько за качество набора задач целиком. Одна оценивает сложность — сколько ограничений приходится учитывать внутри сценария. Другая смотрит на то, проверяет ли бенчмарк разные правила или сотня заданий фактически крутится вокруг нескольких одинаковых случаев. 

На выходе получается что-то вроде автоматической предварительной проверки тестового набора: можно найти противоречивые задания и пробелы в покрытии до того, как по этому бенчмарку начнут сравнивать агентов.

Но тут теперь появляется следующий вопрос, который рождает, как я ее назвал, Мебиус-ИИ-концепцию: как нам проверить, что система для проверки бенчмарков сама действительно работает?

Как проверить систему, которая сама проверяет тесты

Ответ оказался прямолинейным: если аудитор (LLM-судья) действительно понимает качество бенчмарка, то он должен замечать, когда тест специально портят.

Сначала исследователи сгенерировали 975 задач при помощи моделей разного уровня (от GPT-5.4 и Claude-4.5-Sоnnet до небольших Llama). В роли судей использовали несколько других LLM.

Затем начали намеренно ломать данные: в одной серии экспериментов они перемешивали ожидаемые действия между задачами у 20, 40, 60 и 80% примеров. Чем больше неправильных эталонов появлялось в наборе, тем сильнее падала оценка соответствия между заданием и ожидаемым поведением ^[9].

В другом тесте авторы поменяли местами ограничивающие условия разных сфер (скажем, те же пресловутые внутренние правила компании): например, подсунули правила из ретейла задачам по авиаперевозкам. Как итог — метрики, связанные с соответствием правилам, также заметно ухудшались. 

Наконец, часть оценок сравнили с человеческой разметкой. Полного совпадения, конечно, не получилось, но результаты LLM-судей статистически коррелировали с оценками человека.

То есть в контролируемых условиях система делала именно то, чего от нее ждали: замечала ухудшение данных, неправильные правила и проблемные эталоны.

Но пока это все же proof of concept (иначе говоря, проверка концепции). Авторы всего лишь показали, что подход жизнеспособен. И все логично ^[10], но у меня возник следующий вопрос… 

Можно ли полностью убрать кожаных мешков из процесса?

У нас выявляется странная цепочка: 

одна LLM генерирует тесты →
другая проверяет их качество →
третья проходит эти тесты →
четвертая оценивает результат.

Качество бенчмарка для одних LLM IBM предлагает оценивать другой LLM. А значит, вместо человеческой ошибки мы потенциально получаем ошибку модели-судьи.

Когда систему применили к вручную созданному τ³-Bench, некоторые его показатели оказались неожиданно низкими. Авторы объясняют такое разницей в разметке: в τ³-Bench ожидаемое поведение часто описывает только конечный правильный результат, тогда как LLM-судья ожидает более полный воркфлоу. Поэтому короткий и вполне корректный эталон может выглядеть для него хуже просто из-за недостатка деталей. 

В работе Nо Free Labels ^[11] исследователи собрали человеческие оценки для 1200 ответов и обнаружили неприятную зависимость: если модель-судья сама плохо умеет решать определенный тип задач, то и качество чужих ответов на такие задачи она оценивает заметно хуже. Короче говоря, слабость LLM как исполнителя частично переносится и на ее работу в роли судьи. 

Так что полностью убрать человека из рекурсии пока не выходит. Скорее подход IBM позволяет автоматизировать первый проход по тысячам заданий и вытащить наверх подозрительные случаи.

Чем больше этапов оценки уходит моделям, тем менее очевидным становится смысл одного красивого числа в лидерборде бенчмарок. Высокий балл теперь может зависеть от качества заданий, эталонов, правил и модели-судьи.

Поэтому вопрос постепенно смещается с «какая модель набрала больше баллов?» к «насколько вообще можно доверять системе измерений, которой мы эти модели сравниваем?».

Работа IBM эту рекурсию не устраняет — человек все еще нужен. Но она предлагает хотя бы проверять саму линейку перед тем, как начинать измерять ею ИИ. Так что скоро мы увидим и полноценное решение проблемы.