Попросить LLM написать код алгоритма расписания, упаковки или планирования маршрута — звучит как вполне естественный сценарий использования. Однако новая статья исследователей из Пенсильванского университета (команда Дэна Рота) предупреждает: не спешите просить модель оптимизировать код, вы можете только всё испортить.
Три подхода, какой из них лучше?
В работе представлен бенчмарк CP-SynC-XL, включающий 100 задач комбинаторной оптимизации и 4 577 тестовых случаев, после чего LLM была предложено сгенерировать решатели тремя различными способами:
- Поиск на чистом Python: LLM напрямую пишет код алгоритма поиска на Python
- Моделирование ограничений на Python + OR-Tools: LLM строит модель с использованием Python API OR-Tools и вызывает решатель
- Декларативное моделирование на MiniZinc + OR-Tools: LLM описывает модель на декларативном языке MiniZinc, а OR-Tools выполняет решение
Результаты оказались весьма интересными.
Python + OR-Tools показал наивысшую результативность — обеспечив самую высокую точность на множестве LLM. MiniZinc + OR-Tools, несмотря на использование того же бэкенда OR-Tools, продемонстрировал более низкое покрытие — абстракция декларативного языка, наоборот, заставляла LLM чаще ошибаться. Чистый Python чаще всего выдавал решения, которые «проходят валидацию по схеме, но падают на реальных тестах».
Это наблюдение напрямую разрушает интуитивное ожидание: более высокоуровневая абстракция (MiniZinc) = лучший результат. На деле LLM гораздо надёжнее справляется с моделированием ограничений на уровне API (Python + OR-Tools).
Эвристическая ловушка: желание оптимизировать вредит модели
Далее следует самое главное открытие статьи.
Исследователи предложили LLM при генерации решателя добавить оптимизацию поиска (например, стратегии отсечения, эвристические функции, задание границ). Каков результат?
- Медианное ускорение составило всего 1.03–1.12x — практически нулевой эффект
- Чёткое бимодальное распределение — во многих случаях работа, наоборот, замедлилась
- Резкое падение точности на задачах из «длинного хвоста»
Почему так происходит? Проведя детальный анализ кода, исследователи обнаружили повторяющийся паттерн, который они назвали эвристической ловушкой (heuristic trap):
- При использовании чистого Python LLM может заменить полный поиск локальными аппроксимациями
- В связке Python + OR-Tools LLM может внедрить непроверенные ограничения границ (bound)
- При использовании MiniZinc + OR-Tools LLM может добавить избыточные декларативные конструкции, что лишь перегружает решатель
Иными словами, понимание LLM концепции «оптимизации» часто ошибочно. Модель думает, что ускоряет процесс, но на деле вносит баги или искажает семантику задачи.
«Формализуй, но не оптимизируй»
Основываясь на этих выводах, авторы предлагают консервативный, но практичный принцип проектирования:
Позвольте LLM заниматься преимущественно формализацией — определением переменных, ограничений и целевой функции, а решение доверьте проверенным решателям. Любая оптимизация поиска, написанная LLM, перед использованием должна проходить отдельную проверку.
Это стратегия «шага назад». Она признаёт, что LLM полезна на этапе моделирования (определение «что есть»), но ненадёжна при алгоритмической оптимизации (решение «как искать»). Разделив эти две задачи, вы позволяете LLM делать то, что у неё получается лучше всего, а оптимизацию передаёте зрелым вычислительным движкам.
Выводы для разработки AI-агентов
Это открытие имеет прямую практическую ценность для разработчиков AI-агентов для программирования.
Многие инструменты-агенты (Cursor, Claude Code, Copilot) заставляют LLM генерировать и модифицировать код. Если LLM пишет алгоритм, связанный с поиском/оптимизацией, агент должен помнить: не стоит слепо принимать «оптимизационные предложения» LLM без независимого механизма валидации.
Статья также указывает на более широкую закономерность: LLM гораздо надёжнее «описывают структуру задачи», чем «разрабатывают стратегии решения». Это различие, вероятно, применимо и к другим областям — например, оптимизации запросов к базам данных, оптимизации компиляторов или даже стратегиям маршрутизации в сетях.
Ссылка на статью: arXiv:2605.12421