Представьте: вы собрали команду AI-агентов — один кодит как бог, другой щёлкает логические задачи, третий — универсал. Логика подсказывает: их слабые места не пересекутся, значит, вместе они непобедимы. Спойлер: математика с этим не согласна. Новое исследование, протестировавшее 67 ведущих моделей от 21 провайдера, доказывает: такое предположение — чистой воды самообман, и у этого самообмана есть имя — co-failure ceiling, или провальный потолок.
Идея простая: если две модели редко ошибаются на одних и тех же запросах, их комбинация создаёт страховочную сеть. Но реальное ограничение оркестрации — не частота разногласий, а процент запросов, на которых все модели в пуле выдают неверный ответ одновременно. Игнорируя провальный потолок, компании строят сложную и дорогую инфраструктуру маршрутизации ради прироста производительности, которого просто не существует. Хорошая новость: та же математика позволяет разработчикам бесплатно проверить, когда мультимодельная оркестрация действительно окупится.
Скрытые издержки мультимодельной стратегии
Чтобы оркестрировать несколько языковых моделей, разработчики обычно используют три архитектуры. Роутеры моделей работают как регулировщики: сложные запросы отправляют дорогой модели, простые — дешёвой. Каскады сначала гонят каждый запрос через дешёвую модель, и только если её уверенность низкая, эскалируют до премиум-модели. Наконец, подходы вроде Mixture-of-Agents (MoA) объединяют несколько моделей, задавая им один и тот же вопрос и синтезируя ответ из их комбинированных выводов.
Все эти архитектуры вводят «теневую цену» в стоимость инференса. Каждый раз, когда команда внедряет роутер или каскад, она платит повышенной задержкой, сложным обслуживанием инфраструктуры и возросшими рисками управления — а ведь провайдеров API много. Чтобы оправдать эти операционные издержки, инженеры используют «попарную корреляцию ошибок» для подбора пула моделей. Пример: у вас есть Модель A, которая пишет отличный Python, но проваливает SQL, и Модель B, которая блестяще справляется с SQL, но не тянет Python. Поскольку они ошибаются на разных типах запросов, попарная корреляция ошибок низкая. Разработчик предполагает, что, поставив перед ними слой маршрутизации, он получил композитную систему, которая редко ошибается в кодинге.
Но исследование показало: просто бросать разнородные модели в кучу на основе низкой корреляции может навредить, если модели не равны по способностям. Когда вы голосуете по разнородным, но неравным моделям, более слабые часто сговариваются и переголосовывают самую умную.
Джозеф Чен, автор статьи, объяснил VentureBeat: в их экспериментах «наивное мажоритарное голосование среди неравных моделей дало отрицательный средний прирост (минус 10 пунктов на нашем сложном миксе): разнородные, но более слабые участники переголосовывают сильного». Практический совет разработчикам: «объединяйте только модели из одного качественного диапазона». Если вы не можете выровнять качество, берите за базу одну лучшую модель и тратьте бюджет на неё.
Впрочем, для архитектур MoA исследование даёт один проблеск. При сборке ансамблей команды часто используют «Self-MoA» — много раз опрашивают одну и ту же премиум-модель и синтезируют ответ. Учёные выяснили: при равном качестве построение разнородного ансамбля с низкой попарной корреляцией побеждает Self-MoA с высокой корреляцией.
Однако когда команды пытаются использовать ту же метрику попарной корреляции для предсказания абсолютной точности всей системы, математика ломается.
«Команды платят накладные расходы на оркестрацию авансом — задержка, сложность, мультипровайдерные операции — в надежде, что дивиденды от разнообразия придут позже, — говорит Чен. — Обычно этого не происходит, потому что сегодняшние лучшие модели согласны друг с другом, и, что хуже, они ошибаются на одних и тех же запросах... Запрос просто несёт слишком мало сигнала о том, какая модель окажется права, когда фронтирные модели расходятся во мнениях».
Почему математика подводит: провальный потолок
Ключевое открытие исследования — метрика под названием «co-failure rate» (частота совместных отказов), формальное имя для описанного выше сценария «все неправы». Ни роутер, ни система голосования, ни каскад не могут достичь точности выше того потолка, который он накладывает.
Пул из кодинг-специалиста, логика и универсала показывает низкую попарную корреляцию на рутинных запросах — они редко ошибаются вместе. Но провальный потолок проявляется на редких, очень сложных краевых случаях, которые выходят за пределы возможностей текущих AI-архитектур. Если запрос настолько труден, что все три модели галлюцинируют или ошибаются, неважно, насколько умно роутер распределяет задачу — весь пул падает разом.
Исследователи протестировали свой пул из 67 моделей, включая GPT-5.5, Claude Opus 4.8 и Gemini 3.1 Pro, на открытом математическом бенчмарке MATH-500. Основываясь на стандартной попарной корреляции, статистические модели предсказывали, что весь пул выйдет из строя одновременно только на 2,3% вопросов. В реальности частота совместных отказов составила 5,2%. Стандартные метрики корреляции недооценили частоту отказов примерно в 2,25 раза. Виновник — не просто независимая сложность, а общая точка отказа.
«Драйвер — то, что мы называем общим атомом: срез запросов, на которых весь рынок ошибается вместе, и никакая попарная статистика этого не видит, — объясняет Чен. — Добавление 20-й модели в ваш пул не покрывает хвосты. Хвост — общий».
Также выяснилось, что формат задачи напрямую запускает совместный отказ. Когда учёные взяли вопросы уровня выпускника из бенчмарка GPQA и изменили формат с множественного выбора на свободный ответ, «всё-неправильный» хвост расширился до 12,7%.
Разработчики могут обойти потолок, хотя и с оговоркой. «Инженерный вывод неудобен: мультимодельные конфигурации дают меньше всего именно там, где команды хотят их больше всего — на генерации открытых ответов, — говорит Чен. — Везде, где вы можете превратить генерацию в верификацию или ограниченный выбор (структурированные выходы, проверяемые ответы, тесты на исполнение), потолок открывается снова».
В итоге исследователи выяснили, что этот потолок ограничивает AI-приложения двумя разными способами в зависимости от области:
Потолок-ограниченная среда (например, открытая математика): частота совместных отказов высока. Задача слишком сложна, все модели ошибаются одновременно. Никакая маршрутизация не обойдёт недостаток базовых способностей.
Среда с ограничением реализуемости (например, наука уровня выпускника): частота совместных отказов близка к нулю — хотя бы одна модель в пуле обычно знает ответ. Однако модели расходятся во мнениях настолько тонко, что слой маршрутизации не может надёжно выбрать правильный ответ без всеведущего оракула.
Бесплатная проверка здравомыслия перед развёртыванием
Прежде чем тратить инженерные часы на построение роутера, команды могут бесплатно рассчитать свой абсолютный потолок производительности с помощью математической формулы — границы Клоппера-Пирсона (Clopper-Pearson bound).
Граница Клоппера-Пирсона работает как калькулятор наихудшего сценария. Если вы подбросили монету десять раз и получили восемь орлов, вы не можете гарантировать, что монета будет выпадать орлом в 80% случаев вечно. Граница берёт небольшую выборку тестовых вопросов и выдаёт математически гарантированный потолок.
Применительно к языковым моделям: предположим, команда тестирует пул из пяти агентов на 50 запросах и обнаруживает, что все они ошибаются вместе всего на двух вопросах. Разработчик может предположить, что в продакшене их мультиагентная система достигнет 96% точности. Формула Клоппера-Пирсона корректирует этот оптимизм: она анализирует маленький размер выборки и даёт математическую гарантию, что истинная частота совместных отказов может достигать 12%.
Чтобы использовать это на практике, предприятие должно собрать отложенный набор данных. Например, финтех-компания может взять 200 сложных обращений в поддержку за прошлый квартал и попросить людей-операторов написать идеальные ответы в качестве бенчмарка. Звучит как ручная работа, но зрелые инженерные команды могут автоматизировать весь расчёт потолка.
«Интеграция тривиальна: это подсчёт логов eval-запусков, которые команды уже производят, — отмечает Чен. — Он выполняется на той же стадии CI, что и eval-набор, и перезапускается при изменении пула моделей или нагрузки».
Инженерная команда прогоняет свои модели-кандидаты на этих 200 тикетах один раз и записывает результаты. Когда нужно оценить мультимодельные конфигурации, они могут использовать метрику частоты совместных отказов, чтобы предсказать максимальную точность, которую можно получить от системы, не запуская лишних запросов.
Один из важных выводов исследования: на задачах, ответы на которые можно однозначно проверить, комбинирование моделей редко превосходит использование одной лучшей модели на рынке, если только у команды нет исключительно сильного сигнала маршрутизации на уровне запроса.
В корпоративной среде задача с однозначной проверкой имеет объективный, нетерпимый к ошибкам ответ. Это может быть генерация SQL-запроса, который должен выполниться без ошибок, извлечение конкретной суммы из 50-страничного PDF или форматирование JSON-нагрузки, которая идеально соответствует строгой схеме. Для таких задач компаниям обычно выгоднее заплатить премию за самую умную фронтирную модель, чем сплетать вместе три дешёвые в надежде, что роутер выберет правильный вывод. Исследование не тестировало субъективные, неоцениваемые задачи вроде написания маркетинговых текстов — авторы отмечают, что вопрос, применимы ли эти выводы за пределами их верифицируемых бенчмарков, остаётся открытым.
Поскольку эта математическая проверка бесплатна, корпоративные команды могут отслеживать свою частоту совместных отказов по мере выхода новых моделей.
«Измерение ничего не стоит, так что любая команда может следить за своим co-failure rate от поколения к поколению моделей и наблюдать, сужается ли хвост, — говорит Чен. — В конечном счёте рычаг, который держат покупатели, — это гетерогенность режимов отказа и турбулентность рынка, а не количество моделей».