OSCAR проверяет решения LLM и эскалирует запросы по цене

Небольшие модели с открытыми весами смогли превращать текстовые бизнес-правила в корректные решения задач оптимизации почти в каждом запуске. OSCAR достиг точности от 95 до 100%, хотя работа Jinzhi Bu, Haixin Tang и Huanan Zhang не рецензирована, а замеры выполнили сами авторы. Для повторяющихся задач это позволяет сначала исчерпать возможности локальных моделей и обращаться к более дорогим только тогда, когда проверяемого улучшения нет.

Симулятор отделяет правильное решение от правильного кода

LLM в таких системах не заменяет оптимизационный решатель. Она переводит описание задачи в формальную модель и пишет код, а COPT или Gurobi ищет численное решение. Ошибка возникает раньше: модель может неверно понять ограничение или целевую функцию, после чего решатель найдёт точный оптимум для другой задачи.

Успешный запуск программы поэтому ничего не доказывает. Нельзя напрямую сравнить и целевые значения двух сгенерированных моделей: каждая может описывать собственную область допустимых решений. План с лучшим числом окажется непригодным, если нарушает реальное правило бизнеса.

OSCAR создаёт для сравнения отдельный детерминированный симулятор. Он получает описание задачи, данные целевого случая, формат рабочего решения и размеченные примеры допустимых и недопустимых планов. Для допустимого примера можно также указать правильное значение целевой функции, а для недопустимого — нарушенное правило.

Симулятор исправляют, пока он не пройдёт проверку на этих примерах, а затем фиксируют. После этого он оценивает все решения по одной шкале: сначала проверяет допустимость, затем сравнивает целевую функцию. Если текстовое описание и размеченный пример расходятся, OSCAR следует примеру.

Поверх симулятора работают два компонента. Coder пишет и исправляет формулировку, а Reviewer изучает описание задачи, найденное решение и объяснения нарушений. Система сохраняет лучший подтверждённый план и продолжает поиск даже после первого допустимого результата: допустимый план ещё не обязательно лучший.

Escalator повышает стоимость попыток только после неудач

Авторы рассматривают поиск следующего подтверждённого улучшения как отдельное окно. Внутри него нужно решить, какую конфигурацию моделей вызвать, сколько раз повторить попытку и когда остановиться. Конфигурация включает модели для написания и проверки кода, поэтому более дорогой вариант не обязательно означает замену всей цепочки.

Escalator упорядочивает конфигурации по стоимости и постепенно переходит к следующим ступеням. Неудачные попытки служат сигналом, что текущая задача может быть сложнее ожидаемого. При известных предположениях о сложности авторы описывают условия, когда такой порядок оптимален; для общего случая дают расписание без предварительного распределения сложности и доказывают для него ограничение потерь относительно системы, которая заранее знает сложность.

Политике всё равно нужны цена вызова и оценка вероятности успеха каждой конфигурации. Их можно обновлять по журналам запусков, не меняя симулятор и цикл улучшения. Поэтому в меню можно добавлять новые LLM или менять порядок старых по мере изменения тарифов и качества.

Эксперименты охватили пять задач FrontierOR. В OSCAR использовали qwen3.5-flash и qwen3.6-flash, каждую из которых можно развернуть локально на одном GPU. Одиночная попытка обеих моделей давала правильный ответ менее чем в половине случаев, но итеративный цикл поднял точность до диапазона 95–100%.

Codex с GPT-6 Astra расходовал в среднем в 3,1 раза больше токенов на запуск, а Claude Code с Fable 5.1 — в 5,8 раза больше. Эти агенты получали только описание и данные задачи, без доступа к симулятору, эталонной проверке и обратной связи. Полную стоимость построения симулятора при этом начисляли каждому запуску OSCAR, хотя в рабочей системе его можно повторно использовать для задач с теми же правилами.

Планы меняет не маршрутизация, а источник проверяемой истины

Работа не предлагает просто поставить дешёвую LLM перед дорогой. Экономия появляется только потому, что система умеет автоматически доказать улучшение относительно текущего плана. Без независимого симулятора каскад моделей будет выдавать больше вариантов, но не получит надёжного способа выбрать между ними.

Для команд, которые регулярно пересобирают расписания, маршруты или планы размещения, архитектурный приоритет смещается с выбора одной LLM на подготовку размеченных решений. Потребуются примеры как допустимых, так и нарушающих правила планов, стабильный формат решения и процедура сертификации симулятора. После этой подготовки цикл формирования моделей работает без участия человека.

Проверка в статье касается правильности решения для конкретного экземпляра задачи. Она не доказывает, что сгенерированная формулировка останется верной для любых входных данных, совместимых с описанием. Эксперимент также ограничен задачами FrontierOR и двумя моделями Qwen, поэтому перед заменой действующей цепочки нужен пилот на собственных правилах и размеченных случаях.

Если такие примеры уже накапливаются при ручной приёмке планов, OSCAR даёт практическую схему их повторного использования. Сначала локальные модели делают дешёвые попытки, симулятор отбрасывает ошибки, а более дорогая конфигурация подключается только после исчерпания заданного бюджета. Если размеченных решений нет, основная работа начнётся не с маршрутизатора, а с создания проверяемого набора бизнес-правил.

Источники

• OR for AI That Does OR: Routing LLMs up the Escalator inside the OSCAR Framework