Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Лучший в среднем сценарий работы ИИ может уступить набору сценариев, которые независимо решают один запрос. Хотя препринт не прошёл рецензирование и все числа получили сами авторы, полный подход повысил точность на HotpotQA на 25 процентных пунктов. Для продукта это меняет объект оптимизации: сравнивать нужно не отдельные сценарии, а весь контур из параллельных запусков, селектора и затрат.
Разные ошибки ценнее высокой средней точности
Сценарий работы ИИ здесь — это цепочка вызовов модели, поиска, инструментов, проверок и правил объединения результатов. Несколько таких сценариев запускаются параллельно, после чего селектор изучает ответы и выбирает итоговый.
Mojtaba Abdolmaleki, Stefanus Jasin и Boyu Wang предлагают собирать сценарии в портфель. В него может войти процесс, который редко побеждает по средней точности, но справляется с запросами, где основной процесс ошибается. Ценность создаёт не качество участника само по себе, а его дополнительный вклад в набор кандидатов.
У разнообразия есть обратная сторона. Каждый запуск расходует токены, добавляет задержку и может вызвать инструменты, а неверный, но убедительный ответ усложняет работу селектора. Поэтому увеличение числа кандидатов способно как улучшить, так и ухудшить итог.
Чтобы описать эту зависимость, работа связывает число правильных кандидатов с вероятностью выбрать один из них. Качество селектора выражает индекс прироста шансов: он показывает, насколько селектор чаще находит правильный ответ по сравнению со случайным выбором. Из этого индекса выводится верхняя граница пользы портфеля — даже идеально подобранные взаимодополняющие сценарии не помогут, если селектор плохо различает их ответы.
Как подбирали состав портфеля и число запусков
Оптимизация одновременно решает, какие сценарии сохранить, сколько раз запускать каждый из них и сколько кандидатов передавать селектору. Целевая функция учитывает итоговую точность и вычитает повторяющиеся вычислительные затраты. Так модель может предпочесть короткий портфель или оставить единственный сценарий.
Для заранее известного набора процессов авторы дают точную целочисленную постановку, её линейное приближение и процедуру округления решения. Для пространства, которое нельзя перебрать, используется генератор сценариев. Он получает оценки задач, на которых текущий портфель теряет больше всего, и ищет процесс с высокой дополнительной точностью за вычетом стоимости запуска.
Подход проверяли на трёх наборах: ABCD для диалогов службы поддержки, Schema-Guided Dialogue для разговорных сервисов и HotpotQA для ответов с поиском по нескольким фактам. Итог выбирал отдельный Qwen-селектор, который не знал правильного ответа; портфели сравнивали с лучшим одиночным сценарием на отложенных заданиях.
Полная процедура прибавила 6,625 процентного пункта на ABCD, 7,5 пункта на Schema-Guided Dialogue и 25 пунктов на HotpotQA. На ABCD сгенерированные сценарии позволили сократить портфель с 6 до 4 запусков и одновременно повысить точность. На Schema-Guided Dialogue генерация не добавила полезных процессов: достаточно оказалось перераспределить запуски внутри исходного набора.
Результаты показывают разные источники выигрыша. Иногда помогает сочетание уже известных процессов, иногда — поиск нового сценария для оставшихся ошибок, а иногда — повторный запуск одного процесса. Проверка охватывает диалоговые задачи и ответы на вопросы с одним конкретным селектором, поэтому для производственного контура его способность выбирать ответы придётся измерить заново.
Планы стоит менять вокруг селектора, а не генератора
Работа меняет планы команд, у которых уже есть несколько способов решить одну задачу: разные подсказки, модели, цепочки поиска или проверки. Выбирать победителя только по средней точности недостаточно. Нужна таблица результатов по отдельным запросам, чтобы видеть, какие процессы закрывают разные ошибки.
- Считать качество всего контура. Метрика после селектора важнее доли запросов, где среди кандидатов вообще встретился правильный ответ. Наличие верного варианта бесполезно, если селектор предпочитает более убедительную ошибку.
- Оценивать селектор отдельно. Ему нужно давать те же ответы, следы выполнения, найденные источники и результаты проверок, которые будут доступны в продукте. Его качество определяет, окупится ли разнообразие.
- Настраивать число запусков вместе с составом. Фиксированное правило «сгенерировать побольше вариантов» игнорирует стоимость и отвлекающие ответы. Кандидат должен добавлять правильные решения именно там, где портфель пока слаб.
- Направлять генерацию на остаточные ошибки. Искать ещё один сильный в среднем процесс менее полезно, чем процесс для конкретных классов запросов, которые не закрывают текущие участники.
Для раннего прототипа достаточно воспроизвести основную схему без сложного математического решателя: собрать несколько процессов, прогнать их на общей отложенной выборке, проверить селектор на смешанных наборах ответов и сравнить итог с одиночным базовым вариантом с учётом затрат. Если селектор почти не превосходит случайный выбор, сначала стоит улучшать проверку кандидатов, а не расширять портфель.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
