OR-License проверяет LLM-агентов от клиентских файлов до допустимого решения

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

Бенчмарк начинается с материалов клиента, а не с готовой задачи

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

OR-License сохраняет эту часть работы. В него вошла 31 обезличенная задача из 10 промышленных сценариев, созданная на основе оплаченных проектов общей стоимостью 3,68 миллиона долларов. Вместе с исходными требованиями авторы сохранили форматы файлов, неоднозначности и границу между сведениями, доступными сразу, и фактами, которые обычно приходится запрашивать у клиента.

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

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

Границы проверки заданы достаточно чётко: авторы сравнили 11 моделей в среде Claude Code, выполняя по пять запусков для каждой пары модели и задачи. Такой дизайн проверяет длинную цепочку работы с инструментами на конкретном классе задач, а не способность LLM отвечать на отдельные вопросы по оптимизации.

Хорошая целевая функция не спасает недопустимое решение

Ключевая метрика — качество с поправкой на развёртывание (Deployment-Adjusted Quality, DAQ). Сначала проверяется строгая допустимость: решение должно пройти все официальные случаи конкретной задачи. Если хотя бы один случай нарушает обязательное условие, задача получает ноль независимо от того, насколько выгодно выглядит результат.

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

Лучший результат в основной конфигурации показал Grok 4.6: строгая допустимость составила 88,39%, а DAQ — 86,55% при экспертном эталоне 100%. Разрыв возник не из-за систематически слабой оптимизации, а потому, что часть решений нарушала требования и полностью теряла зачёт.

Разбор журналов показал ещё один разрыв. Агенты в основном задавали вопросы до написания решателя, хотя уточнения на поздних этапах помогали исправлять уже обнаруженные проблемы. Полную цепочку «гипотеза — объяснение — эксперимент — интерпретация — исправление» модели завершали лишь в 24–45% подходящих случаев.

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

Планы меняет не рейтинг моделей, а схема приёмки агента

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

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

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

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

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

Источники

• OR-License: Evaluating LLM Agents as Real-World Operations Research Practitioners