Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
У LLM-сгенерированных эвристик для маршрутизации научились находить повторяющиеся провалы на отдельных типах задач, не переписывая удачные части. В нерецензированном препринте, где числа получили сами авторы, Binghao Ji, Di Huang, Jiahui Fang и Zhiyuan Liu показали: RouteRepair снизил средний разрыв до оптимума с 1,7476% до 0,7587%. Для команд это прежде всего новый подход к проверке и доработке эвристик: оценивать нужно не только средний результат, но и поведение на каждом отдельном примере.
Средняя оценка скрывает повторяющиеся ошибки
LLM может сгенерировать эвристику — быстрое правило поиска приемлемого маршрута при ограниченном вычислительном бюджете. Обычно такие правила сравнивают по средней стоимости маршрута или среднему отклонению от лучшего решения. Но хороший итоговый показатель может скрыть класс задач, на котором одно и то же правило регулярно ошибается.
RouteRepair начинает именно с таких локальных провалов. Для управляемого локального поиска в задаче коммивояжёра TSP средний разрыв до оптимума уменьшился с 1,7476% до 0,7587%. Этот показатель отражает, насколько найденный маршрут хуже оптимального; после ремонта разрыв сократился более чем вдвое.
В задаче CVRP, где транспорт имеет ограниченную вместимость, конструктивная эвристика снизила среднюю стоимость маршрутов на 1,91% относительно эвристики сбережений. Для муравьиной оптимизации сгенерированные априорные оценки также обошли сопоставимые оценки, заданные вручную, хотя в аннотации численный разрыв не приведён.
Смысл этих результатов не только в улучшении средней оценки. RouteRepair должен восстанавливать качество на трудных примерах и одновременно сохранять поведение там, где исходная эвристика уже работала хорошо. Это отличает направленный ремонт от очередной полной генерации правила с последующим сравнением одной итоговой метрики.
Как RouteRepair ограничивает область ремонта
Система анализирует слабые места конкретной исходной эвристики по результатам на отдельных задачах. Она объединяет сведения о маршрутах, поведение решателя и контекст программы, чтобы задать ограниченную цель ремонта. После этого меняет связанные с провалом компоненты, а не эвристику целиком.
Каждое изменение проверяют парным сравнением исходной и исправленной версий. На проблемных примерах измеряют, восстановилось ли качество, а на ранее успешных — не возникло ли сопутствующее ухудшение. Такая проверка превращает сохранение удачного поведения в отдельный критерий, а не в надежду на то, что средний результат компенсирует новые ошибки.
Подход проверяли на TSP и CVRP в конструктивном поиске, управляемом локальном поиске и муравьиной оптимизации. Поскольку этот материал подготовлен по аннотации, а не по полному тексту, точные правила диагностики и выбора изменяемого компонента восстановить нельзя.
Из доступного описания также нельзя заключить, что RouteRepair требует определённой LLM или конкретной реализации решателя. Содержательная граница уже: работа показывает принцип адресного ремонта на двух классах маршрутных задач и нескольких способах поиска.
Что меняется в планах команд
Работа не даёт оснований сразу менять выбранный решатель или заменять ручные эвристики генерацией через LLM. Она меняет экспериментальный контур вокруг уже сгенерированных правил. Одной средней оценки теперь недостаточно, если продукт должен стабильно работать на разных структурах маршрутов.
Первое практическое изменение — сохранять результат по каждому примеру, а не только сводную метрику. Это позволяет увидеть повторяющийся провал, который растворяется в среднем значении. Для логистической системы таким сигналом становится не единичный плохой маршрут, а воспроизводимая слабость исходной эвристики на сходных входных условиях.
Второе изменение — задавать ремонту узкую цель. Контекст программы и поведение решателя должны указывать, какую часть правила разрешено менять и какое успешное поведение нужно сохранить. Полная перегенерация остаётся возможной, но она затрудняет понимание того, почему результат улучшился и где появились новые сбои.
Третье изменение — проверять исходную и исправленную версии на одних и тех же примерах. Отдельно нужны случаи прежнего провала и случаи, где исходное правило уже давало хороший маршрут. Если улучшение на трудной группе сопровождается ухудшением на устойчивой, средняя метрика может снова скрыть проблему.
Для команд, которые уже строят автоматическую генерацию эвристик, RouteRepair предлагает понятную архитектуру следующего этапа: диагностика по отдельным задачам, ограниченное изменение компонента и парная проверка регрессий. Пока это скорее схема исследовательского контура для маршрутизации, чем готовое универсальное средство ремонта LLM-сгенерированных программ.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
