Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Повторная попытка той же модели после неудачного редактирования изображения срабатывает лишь в 17–53% так часто, как первая. Работа Beijing Normal University и Nanyang Technological University предлагает RetryRoute; препринт не рецензирован, а числа получили сами авторы. На GPU-стенде маршрутизатор повысил долю правок, завершённых успешно и в целевой срок, на 5,0–6,3 процентного пункта против лучшего прежнего подхода.
Почему повтор после отказа — уже другой запрос
Сервис редактирования обычно отправляет изображение и инструкцию модели, а затем проверяет результат моделью-оценщиком. Если проверка не пройдена, оркестратор повторяет вызов с другим случайным начальным состоянием или переключается на следующую модель в заранее заданной цепочке.
Обе стратегии часто предполагают, что предыдущий отказ ничего не говорит о следующей попытке. Но запросы различаются по сложности: модель может уверенно менять цвет предмета и систематически ошибаться при замене текста на вывеске. Отказ поэтому служит новым сигналом о запросе, а не просто неудачным броском монеты.
Эффект проверяли на шести открытых моделях редактирования, наборах GEdit-Bench, GEditBench v2 и ImgEdit и с двумя независимыми моделями-оценщиками. Для FLUX.2 [klein] на английской части GEdit-Bench первая попытка проходила проверку в 67% случаев, повтор после отказа — в 15%, тогда как другая модель из того же набора справлялась с 45% таких запросов.
Отказ влияет и на оценку остальных моделей. Если несколько моделей плохо справляются с одной категорией правок, неудача одной снижает ожидаемый результат других. Поэтому правило «после первой ошибки всегда переходить к модели B» тоже теряет часть информации: решение зависит от всей последовательности вызовов.
Есть ещё одна проблема. Поздний результат проходит ту же автоматическую проверку, но независимая модель-оценщик подтверждает такие результаты реже, чем правки с первой попытки. Цикл из множества повторов может не только расходовать вычисления, но и накапливать ложные одобрения.
Как RetryRoute выбирает между повтором, сменой модели и остановкой
RetryRoute хранит состояние запроса как число отказов у каждой доступной модели. Для следующего вызова он оценивает вероятность успеха с учётом этого состояния, а не подставляет средний результат первой попытки.
Оценки строятся по журналам прошлых вызовов. Сервис считает, как часто конкретная модель справлялась после определённой последовательности отказов. Для редких категорий, где наблюдений мало, RetryRoute приближает оценку к общей статистике, чтобы единичный удачный пример не определял маршрут.
Затем динамическое программирование сравнивает три действия: повторить текущую модель, перейти к другой или прекратить обработку. В ценность действия входят вероятность принятия результата и вычислительная стоимость всех следующих попыток. Остановка становится полноценным вариантом, поэтому маршрутизатор не продолжает цикл, когда ожидаемая польза уже ниже затрат.
При работе сервиса к стоимости добавляется ожидание в очередях модели и оценщика. После каждого отказа RetryRoute заново строит план по текущей загрузке: дорогая модель с пустой очередью иногда оказывается выгоднее дешёвой, перед которой накопились запросы. Так один механизм одновременно управляет качеством, расходом GPU и задержкой.
Для запуска без полной истории предусмотрено обучение на поступающих запросах. Но основная схема лучше подходит сервису, который уже записывает модель, категорию задачи, последовательность отказов, решение оценщика, время генерации и ожидание в очереди.
Когда стоит менять архитектуру сервиса
В офлайн-проверке RetryRoute обошёл сильнейший из одиннадцати прежних подходов в среднем на 2,8 процентного пункта при основном бюджете. В испытании на трёх GPU выигрыш сохранился при разных профилях нагрузки, потому что маршрутизатор не направлял все сложные запросы в одну занятую очередь.
Для продукта с несколькими моделями это аргумент перенести решение из уровня отдельного запроса в уровень каждой попытки. Оркестратору нужны история отказов, право завершить обработку и доступ к текущим очередям. Фиксированная цепочка «дешёвая модель, затем дорогая» остаётся приемлемой только там, где нагрузка стабильна и накопленный отказ почти не меняет вероятность следующего успеха.
Если сервис использует одну модель, переключаться некуда, но результат всё равно меняет политику повторов. После каждого отказа ожидаемую вероятность нужно снижать и сравнивать с ценой ещё одного вызова, а не задавать одинаковый предел попыток для всех запросов.
Проверка охватывает прежде всего открытые модели редактирования изображений и автоматических оценщиков; отдельный эксперимент также переносит подход на генерацию изображений по тексту. Для кода, поиска и других агентных инструментов это пока архитектурная гипотеза, которую следует проверять на собственных журналах. Практический первый шаг — воспроизвести кривую успеха после последовательных отказов, а уже затем внедрять планировщик и учёт очередей.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
