Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Новый подход помогает LLM создавать системные эвристики, которые не обменивают хороший средний результат на провалы при редких нагрузках. TAILOR подтвердил улучшение среднего результата и худшей части распределения на шести из семи тестов с уверенностью 99%, хотя работа не рецензирована и числа в ней получили сами авторы. Для команд, которые уже ищут программы с помощью LLM, это повод сначала пересмотреть целевую функцию, а не усложнять поисковую архитектуру.
Почему среднего результата недостаточно
LLM может написать эвристику для упаковки виртуальных машин, размещения серверов или допуска заданий к GPU. Поисковая система запускает каждый вариант на наборе нагрузок, выставляет оценку и передаёт результат модели, чтобы та предложила следующую версию.
Если оценивать только среднюю стоимость, поиск выбирает рискованные стратегии. Они выигрывают на большинстве входов, но заметно проигрывают базовой эвристике на отдельных случаях. Добавление сложных или специально подобранных нагрузок само по себе не решает проблему: средняя оценка всё равно позволяет компенсировать один крупный провал множеством небольших улучшений.
Процентиль тоже даёт неполную картину. Он показывает границу, после которой начинаются плохие результаты, но не учитывает их глубину. Два кандидата могут пройти один порог, хотя первый немного уступает базовой системе, а второй на части нагрузок ломает её экономику.
TAILOR сравнивает кандидата не с абстрактным уровнем качества, а с действующей эвристикой на одной и той же нагрузке. Из стоимости кандидата вычитают стоимость базового решения. Отрицательная разница означает улучшение, положительная — регрессию.
Как парный CVaR связывает худшие случаи со средним
Целевой функцией служит условная стоимость под риском (CVaR): средняя разница между кандидатом и базовой эвристикой в худших 5% нагрузок. Такой показатель одновременно учитывает, как часто возникают регрессии и насколько далеко они заходят.
Если парный CVaR отрицателен, кандидат в среднем выигрывает даже в выбранном хвосте. Из свойств этой меры следует, что общий средний результат тоже улучшается: среднее по худшей части не может быть лучше среднего по всему распределению.
Работа доказывает и более полезное для системной разработки свойство. Отрицательный парный CVaR ограничивает изменение разрыва между эвристикой и недоступным точным оптимумом. Сам оптимум вычислять не нужно — достаточно запускать старое и новое решения на одинаковых входах. Это делает показатель пригодным для итеративного поиска, где приходится проверять множество программ.
Для итоговой проверки TAILOR берёт независимые нагрузки и строит верхнюю статистическую границу для CVaR. Сертификат выдаётся, только если эта граница остаётся ниже нуля. Он относится к тому распределению нагрузок, на котором прошла проверка: после изменения трафика или состава задач эвристику нужно сертифицировать заново.
Метод проверяли на допуске пакетных заданий к Azure GPU, упаковке Azure VM, размещении серверов и дополнительных задачах оптимизации. В основном сравнении исследователи фиксировали LLM, поисковую систему Engram, наборы нагрузок и бюджет поиска, меняя только целевую функцию. Поэтому результаты показывают эффект оценки кандидатов, а не смены модели или более долгого перебора.
Что меняется в планах команд
На потоках запросов к Azure GPU эвристика, оптимизированная по среднему, уступала базовому правилу на 7,5% входов. В выбранном хвосте средняя регрессия достигала 9,2%. TAILOR сократил долю проигрышей до менее 0,01%, сохранив улучшение среднего результата.
По сравнению с поиском по фиксированному процентилю TAILOR дал на 46–62% больший выигрыш в худшей части входов. Разница возникла не из-за нового генератора программ: обратная связь заставила LLM изменить саму стратегию. Вместо постоянного ожидания более выгодных будущих запросов сгенерированная эвристика ограничивала число ранних отказов и учитывала оставшуюся ёмкость.
Практический вывод относится прежде всего к системам, где уже есть рабочая базовая эвристика и повторяемый набор нагрузок. В таком контуре можно запускать старое и новое решения попарно, оптимизировать хвост разницы и проверять финального кандидата на независимой выборке. Менять весь поисковый конвейер для этого не требуется.
Сертификат не заменяет остальные требования эксплуатации. В опытах ограничение времени исполнения проверяли фильтром во время поиска, однако некоторые сгенерированные решения нарушали его на новых входах. Задержку, память и другие обязательные показатели придётся включать в целевую функцию отдельно либо сертифицировать собственными проверками.
Работа также снижает ценность сложной поисковой обвязки как первого шага. Если текущий конвейер ранжирует программы по среднему результату, добавление агентов или генератора сложных входов не устраняет ошибку в критерии отбора. Сначала стоит определить приемлемую худшую долю, границы возможной регрессии и независимый набор для сертификации, а уже затем выбирать архитектуру поиска.
Источники
Иллюстрация: рисунок из статьи «Robustness Starts with the Objective: Designing and Certifying Robust LLM-Generated Heuristics», Pantea Karimi, Roozbeh Bostandoost, Dany Rouhana и др., CC BY 4.0
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
