Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Много-модельная система стала точнее, когда другие LLM подключали не к каждому запросу, а только к сомнительным ответам. В работе KAUST и LUMS, которая не прошла рецензирование и содержит замеры самих авторов, COMED улучшил результат основной модели во всех 16 конфигурациях с открытыми весами — в среднем на 4,6 процентного пункта. Такой контроллер можно поставить после существующего маршрутизатора, не перестраивая весь контур выбора моделей.
Как COMED решает, нужен ли второй ответ
Обычный маршрутизатор выбирает модель и считает задачу законченной, как только та дала ответ. COMED добавляет следующий этап: принять результат, проверить его через соседнюю модель или запустить совместное рассуждение.
Сначала основная модель строит несколько независимых цепочек рассуждения. Если они приводят к разным выводам, система считает ответ нестабильным и сразу подключает другую модель. Это не гарантирует ошибку, но указывает, что дополнительный расход вычислений приходится на рискованный запрос.
Совпавшие цепочки ещё не означают, что ответ верен: модель может уверенно повторять одну ошибку. Поэтому COMED смотрит на разрыв между оценками маршрутизатора для лучшего и следующего кандидата. Большой разрыв позволяет принять ответ, а близкие оценки отправляют запрос на проверку.
Проверяющая модель сначала решает задачу одним проходом. Если её ответ совпадает с основным, система завершает работу. При расхождении проверяющая модель строит дополнительные варианты, и только устойчивое несогласие запускает полноценный обмен между моделями.
Проверка не выбирает итоговый ответ сама. Она служит фильтром: случайное возражение слабого соседа не должно менять верный результат, но уверенное расхождение оправдывает дальнейший расход токенов. При совместном рассуждении модели получают краткие сводки рассуждений друг друга, а не полные внутренние цепочки.
Почему постоянное сотрудничество уступило выборочному
Маршрутизация ограничена уже полученными вариантами: если ни одна модель не предложила правильный ответ, выбор лучшего кандидата не поможет. На MedQA совместное рассуждение исправило 14,2% случаев, где правильного варианта не было ни в одной исходной цепочке. Чужая сводка могла добавить пропущенное условие и направить генерацию по новому пути.
Тот же обмен иногда портил правильный ответ. Убедительная, но ложная версия соседа заставляла основную модель отказаться от верного решения. Поэтому авторы разделяют эффект на спасённые ошибки и испорченные ответы: дополнительная модель полезна, только когда первое перевешивает второе.
На MedQA выборочная эскалация дала максимальный прирост в 10,7 процентного пункта. Относительно режима, где модели сотрудничали на каждом запросе, COMED расходовал примерно на 33% меньше декодированных токенов и вызывал не более двух различных моделей для одного задания.
Открытую часть проверяли с фиксированной основной моделью и с моделью, выбранной обученным маршрутизатором. Тесты охватили медицинские, научные и общие задачи рассуждения; отдельно систему проверили на HLE с закрытыми моделями. Пороговые значения контроллера не подбирали заново под каждый набор задач, что делает результат ближе к переносимому правилу, а не к настройке под отдельный тест.
Когда эта схема меняет архитектурный план
Работа сдвигает точку управления с выбора модели на момент после первого ответа. Команде не обязательно заменять действующий маршрутизатор: он продолжает выбирать основную LLM, а новый слой решает, достаточно ли её результата.
Для такого слоя нужны два сигнала, которых может не быть в текущем API. Система должна получать несколько независимых ответов основной модели и оценки маршрутизатора по ближайшим кандидатам. Если провайдер возвращает только один готовый результат без оценок, эти сигналы придётся воспроизводить дополнительными вызовами или собственным маршрутизатором.
COMED особенно уместен там, где ошибка дороже дополнительного запроса, но постоянный совет нескольких моделей слишком затратен: медицинские помощники, технический анализ и ответы по внутренним базам знаний. Для свободного диалога без проверяемого правильного ответа труднее настроить контроллер и измерить, действительно ли сосед исправил ошибку.
При испытании такого контура стоит считать отдельно спасённые и испорченные ответы, а не только итоговую точность. Иначе два режима с одинаковым средним результатом могут различаться по риску: один исправляет сложные случаи, другой часто меняет уже верные ответы.
Ресурсный вывод пока относится прежде всего к декодированным токенам. Замеры реального времени выполнения в работе предварительные, поэтому сокращение числа вызванных моделей нельзя автоматически считать таким же сокращением задержки в рабочей инфраструктуре.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
