Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Многоагентный сценарий можно научить не запускать следующий этап, если тот уже не улучшит ответ. Jinfeng Xu и соавторы показали в препринте, который не прошёл рецензирование и содержит замеры самих авторов, что LW2S сократил расход токенов на 31,2% в одном из срезов задач по программированию без потери качества. Такой контроллер позволяет оставить полный сценарий для сложных случаев, а в остальных не платить за избыточную проверку или финальную обработку.
Почему полные логи не показывают лишний шаг
Обычный лог показывает только выполненную цепочку: планировщик подготовил решение, исполнители предложили ответы, проверяющий исправил результат, финальный компонент его оформил. Из такого лога нельзя узнать, что произошло бы без проверяющего. Возможно, ответ не изменился бы; возможно, правильный промежуточный результат сохранился бы; возможно, сценарий оставил бы общую ошибку исполнителей.
LW2S получает недостающий сигнал через контролируемые пропуски. Для одной задачи система запускает полный сценарий, а затем повторяет его без одного выбранного компонента, сохраняя остальные условия. Так появляются парные трассы: одна показывает результат полного исполнения, другая — итог без проверяющего или финального компонента.
Пропуск считается безопасным, если награда не ниже, чем у полного сценария. Это относительный критерий: если полная цепочка ошиблась, LW2S может сохранить ту же ошибку и всё равно получить метку безопасного действия. Метод сокращает вычисления относительно заданного сценария, а не гарантирует правильность ответа сам по себе.
Авторы проверяли подход на MATH, MMLU и MBPP: математических задачах, вопросах с выбором ответа и генерации кода. Основной сценарий включал планировщик, двух исполнителей, проверяющий и финальный компоненты; дополнительные опыты охватывали другое устройство обсуждения и две семьи моделей с инструкциями. Порог выбирали по расходу токенов, а задержку учитывали отдельно.
Как контроллер решает, что можно не выполнять
Для каждого места в сценарии LW2S обучает отдельную модель безопасности. Она получает условие задачи и уже созданные промежуточные ответы, затем оценивает, сохранит ли конкретный пропуск результат полного исполнения. Базовая LLM остаётся замороженной: решение принимает отдельная логистическая регрессия по признакам текста, совпадениям ответов и доступным проверкам.
Одной оценки модели недостаточно. Порог принятия подбирают на отложенных трассах, причём условия должны выполняться отдельно для разных источников калибровочных примеров. Если уверенности не хватает, контроллер продолжает полный сценарий.
Поверх вероятностной оценки работают предметные проверки. В математике пропуск проверяющего разрешают, когда исполнители получили одинаковый числовой ответ. В коде оба решения должны пройти доступные модульные тесты. Для вопросов с вариантами одинаковая буква ответа оказалась слабым признаком: два исполнителя могут разделять одно заблуждение.
Решение принимается последовательно. Если проверяющий нужен, сценарий запускает его, но после этого снова оценивает, можно ли отказаться от финальной обработки. Экономия не складывается из нескольких гипотетических веток: для каждой задачи учитываются токены той продолженной трассы, которую контроллер действительно выбрал.
Работа меняет оркестрацию, но не отменяет проверки
На одном срезе MBPP полный сценарий решал 63% задач, а прямой пропуск проверяющего снижал результат до 61%. Предметная проверка блокировала такие случаи, после чего LW2S мог сэкономить токены позже, не запуская финальный компонент.
На другом срезе MBPP доля решённых задач выросла с 69% до 70%, а расход токенов уменьшился на 28,5%. Улучшение возможно потому, что дополнительный компонент иногда не исправляет, а портит уже правильный промежуточный ответ. На MMLU проявилась обратная граница: исполнители выбрали один и тот же неверный вариант A, тогда как проверяющий заменил его на правильный C.
Для продуктовой команды LW2S имеет смысл не как универсальный переключатель, а как слой оркестрации поверх стабильного сценария. Понадобятся измеримая награда, повторные запуски с одиночными пропусками, отдельная калибровочная выборка и проверяемые сигналы вроде тестов кода. Простое согласие агентов для этого недостаточно.
Практический сдвиг состоит в том, что проверяющий или финальный компонент больше не обязательно выбирать навсегда на этапе проектирования. Их можно оставить в графе и запускать условно по уже полученному состоянию процесса. Такой подход подходит сценариям с заметной стоимостью повторных вызовов и формальной проверкой результата; без надёжного критерия качества контроллер будет учиться сохранять поведение полной цепочки, включая её ошибки.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
