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

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

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

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

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

Другое свежее исследование специалистов из IBM предлагает задействовать LLM для верификации самих бенчмарков. Фокус авторов направлен на системы оценки task-oriented conversational agents — диалоговых ботов, функционирующих по жестким бизнес-сценариям (например, оформление возврата товара или корректировка брони в динамическом режиме).

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

Масштаб проблемы: насколько все запущено

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

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

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

Еще один показательный сбой — требование аннулировать бронирование, которое по тем же правилам отмене не подлежало. В сфере e-commerce зафиксировали попытку провести возврат средств через PayPal, хотя платежный шлюз вообще отсутствовал в тестовом контуре.

Иными словами, мы сталкиваемся с системной ошибкой на уровне канонического ответа: агент успешно решает поставленную задачу, но получает штраф вместо похвалы.

Можно было бы списать все на небрежность разработчиков-энтузиастов, если бы не масштабное исследование Measuring what Matters. Команда из 29 ученых детально проанализировала 445 бенчмарков языковых моделей, представленных на ведущих профильных конференциях.

Критичные дефекты были найдены на всех уровнях: от размытого понимания целевых навыков до несовершенства метрик и некорректности итоговых аналитических выводов.

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

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

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

Концепт IBM: бенчмарк, проверяющий бенчмарки

Сотрудники подразделения IBM Research предложили оценивать наборы тестов для диалоговых агентов с помощью LLM-судей, направляя их не на софт, а на сами экзаменационные задания.

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

Для анализа разработчики выделили четыре базовых критерия.

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

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

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

На выходе формируется инструмент автоматического предиктивного аудита: система выявляет логические дыры и противоречия задолго до запуска сравнительных тестов.

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

Валидация аудитора: проверяем проверяющего

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

На первом этапе исследователи синтезировали 975 задач силами передовых моделей (включая GPT-5.4, Claude-4.5-Sonnet и компактные версии Llama), задействовав другие нейросети в роли арбитров.

Затем данные начали искусственно портить: в одной серии тестов целевые действия хаотично перетасовывались между 20%, 40%, 60% и 80% кейсов. По мере роста доли дефектных эталонов показатели соответствия заданию закономерно деградировали.

Во втором эксперименте условия кросс-доменировали: правила из ритейла намеренно переносились в авиационные задачи. Итог предсказуем — метрики соблюдения регламентов резко падали.

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

В изолированной среде система отработала штатно: отследила деградацию данных, нарушение регламентов и невалидные эталоны.

Тем не менее, перед нами лишь proof of concept (концептуальная демонстрация). Подход жизнеспособен, но логика порождает новый закономерный вопрос…

Возможно ли полностью исключить человека из контура?

Выстраивается интригующая цепочка: 

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

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

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

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

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

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

Вектор дискуссии смещается от вопроса «какая нейросеть сильнее?» к фундаментальному сомнению: «насколько мы вообще доверяем измерительному инструменту?».

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

 

Источник