Потолок со-отказов: почему больше AI-моделей не значит лучше

Команда разработчиков берёт модель для кода, модель для логики и универсальную модель, соединяет их роутером - и предполагает, что каждая закроет слепые зоны другой. Новое исследование 67 моделей от 21 провайдера показывает: это допущение математически ошибочно. У ошибки есть название - потолок со-отказов (co-failure ceiling).

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

«Дело в том, что мы называем common-mode atom - слой запросов, на котором проваливается весь рынок сразу. Никакая попарная статистика его не видит, - объяснил VentureBeat Джозеф Чен, автор исследования. - Добавление 20-й модели в пул не даёт покрытия «хвоста». Хвост общий».

Скрытая цена мультимодельной стратегии

Чтобы оркестрировать несколько языковых моделей, разработчики обычно используют три архитектуры. Модельные роутеры работают как регулировщики: сложные запросы отправляют дорогим моделям, простые - дешёвым. Каскады сначала пропускают каждый запрос через дешёвую модель и только при низкой уверенности эскалируют на премиум. Mixture-of-Agents (MoA) опрашивает несколько моделей по одному вопросу и синтезирует ответ из их комбинированных выходов.

У каждой архитектуры есть скрытая цена: дополнительная задержка, сложность инфраструктуры, риски управления несколькими API-провайдерами. Чтобы оправдать эти издержки, инженеры используют попарную корреляцию ошибок. Если Модель A отлично пишет Python, но проваливает SQL, а Модель B пишет отличный SQL, но спотыкается на Python - их корреляция низкая. Команда думает, что роутер создал систему, которая редко ошибается в коде.

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

Джозеф Чен: «Наивное мажоритарное голосование среди неравных моделей дало отрицательный прирост (минус 10 пунктов на сложных задачах). Практический совет разработчикам - комбинировать только модели из одного качественного диапазона. Если не можете выровнять качество - берите лучшую одиночную модель и тратьте бюджет на неё».

Почему математика не работает: потолок со-отказов

Главное открытие исследования связано с метрикой co-failure rate - формальным названием сценария «все ошиблись одновременно». Ни роутер, ни система голосования, ни каскад не могут достичь точности выше потолка, который эта метрика задаёт.

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

Исследователи также обнаружили, что формат задачи напрямую влияет на co-failure. Когда graduate-level научные вопросы из бенчмарка GPQA перевели из формата multiple-choice в свободный ответ, «хвост» одновременных отказов вырос до 12,7%. Чен: «Инженерный вывод неудобный: мультимодельные конфигурации дают меньше всего именно там, где они нужны больше всего - в открытой генерации».

Бесплатный тест за 0 долларов

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

Допустим, команда тестирует пул из пяти агентов на 50 тестовых запросах и обнаруживает, что все они ошиблись вместе только на двух вопросах. Разработчик может предположить 96% точности в продакшене. Формула Клоппера-Пирсона корректирует этот оптимизм: при таком малом размере выборки истинный co-failure rate может достигать 12%.

На практике предприятию нужно собрать датасет. Fintech-компания, например, может взять 200 сложных запросов техподдержки за прошлый квартал и написать к ним эталонные ответы. Зрелые инженерные команды автоматизируют весь расчёт: он выполняется в том же CI-пайпе, что и eval-сьют, и перезапускается при любом изменении пула моделей или нагрузки.

Важный вывод исследования: на задачах с проверяемыми ответами (SQL-запрос, точное извлечение суммы из PDF, форматирование JSON под строгую схему) комбинирование моделей редко бьёт одну лучшую модель на рынке - если только у команды нет исключительно сильного сигнала для роутинга. Для таких задач выгоднее заплатить премиум за самую умную модель, чем плести трёх дешёвых в надежде, что роутер выберет правильный ответ.

Поскольку эта математическая проверка бесплатна, enterprise-команды могут отслеживать собственный co-failure rate по мере выхода новых моделей. «Измерение ничего не стоит, так что любая команда может следить за своим потолком со-отказов поколение за поколением и наблюдать, закрывается ли хвост, - говорит Чен. - Рычаг, который держат покупатели, - гетерогенность сценариев отказа и турбулентность рынка, а не количество моделей».

Что это значит для бизнеса

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

Наш опыт показывает: автоматизация с помощью ИИ даёт результат, когда вы начинаете не с выбора моделей, а с диагностики процессов. Бесплатный AI-аудит помогает понять, какие задачи в вашем бизнесе действительно готовы к автоматизации, а какие потребуют кастомного решения. А не просто добавления ещё одной модели в роутер.