Почему ИИ до сих пор не может решить вашу реальную задачу математической оптимизации

И чем отличается ORPilot?

Делиться

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

Этот разрыв не случаен. Он возник намеренно, и именно поэтому я создал ORPilot.

Перспективы оптимизации на основе искусственного интеллекта

Исследование операций (ОР) на протяжении десятилетий незаметно, но эффективно, помогает принимать важнейшие решения в бизнесе — планировать маршруты грузовиков, составлять графики производства на заводах, проектировать цепочки поставок, распределять грузы между перевозчиками. Математические основы хорошо развиты, а решатели превосходны. Узким местом всегда оставалась необходимость в высококвалифицированных специалистах для преобразования бизнес-задачи в математическую модель.

Большие языковые модели (LLM) казались идеальным решением. Растущее число исследований, включая серию OptiMUS, OR-LLM и другие, показало, что современные LLM могут генерировать корректный код решателя для хорошо определенных задач линейного программирования (LP) и смешанного целочисленного программирования (MIP). Результаты выглядели впечатляюще. Демонстрации были убедительными.

Затем вы пытаетесь использовать один из этих инструментов для решения реальной проблемы, и трещины появляются немедленно.

Где существующие инструменты дают сбой

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

В реальных задачах исследования операций все работает совсем не так. Даже близко нет.

Рассмотрим, что на самом деле происходит, когда команда, занимающаяся управлением цепочкой поставок, хочет построить оптимизационную модель:

1. Описание проблемы неполное и неоднозначное. Бизнес-аналитик может сказать: «Мы хотим минимизировать транспортные расходы», и забыть упомянуть, что у каждого распределительного центра есть ограничение по пропускной способности, что некоторые маршруты не существуют или что открытие объекта влечет за собой единовременные фиксированные затраты. Эти упущения недопустимы.
   Невнимательность. Это предположения, которые аналитик считает очевидными, и именно поэтому они опасны. Система ИИ, которая начинает моделирование до того, как эти детали будут точно определены, создает модель, которая технически верна, но практически неверна.
2. Объём данных слишком велик, чтобы уместить их в подсказке. Реальная проблема в цепочке поставок может включать сотни производственных площадок, распределительных центров, клиентов и тысячи товаров за несколько периодов. Одна только таблица спроса может содержать миллионы записей. Вы не можете встроить это в подсказку. Даже если бы это было возможно, переполнение контекстного окна необработанными данными значительно увеличивает риск возникновения галлюцинаций.
3. Имеющиеся у вас данные не соответствуют потребностям модели . Моделированию может потребоваться матрица расстояний между всеми парами местоположений. У вас же есть таблица GPS-координат. Моделированию может потребоваться совокупный спрос по продуктам и периодам. У вас же есть реестр транзакций с одной строкой на каждый заказ. Преодоление этого разрыва, а именно вычисление производных параметров из исходных данных, является важным инженерным этапом, который ни один из существующих инструментов LLM-for-OR не выполняет автоматически.
4. После создания рабочей модели важны ее переносимость и воспроизводимость. Если вы захотите повторно запустить модель на обновленных данных, перейти с Gurobi на решатель с открытым исходным кодом или передать модель коллеге на другой машине, вы вернетесь к исходной точке, если инструмент не создаст надежный, независимый от решателя артефакт. Большинство инструментов создают код, специфичный для конкретного решателя, и ничего больше.

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

Представляем ORPilot

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

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

Это проектное решение, отдающее приоритет пониманию над скоростью, отражает один главный принцип: агент ИИ должен работать так же, как и опытный специалист-консультант в области операционных исследований.

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

Конвейер обработки данных ORPilot отражает эту дисциплину посредством пяти последовательно связанных этапов.

Этап 1: Собеседование с агентом

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

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

На практике это означает такие разговоры:

ORPilot: «После открытия объекта, остается ли он открытым на протяжении всех последующих периодов, или его можно закрыть позже?»

ORPilot: «Эта модель предназначена для одного типа продукции или для нескольких?»

ORPilot: «Вы упомянули стоимость транспортировки. Это стоимость за единицу отгруженной продукции, за всю партию независимо от количества, или что-то другое?»

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

Этап 2: Агент сбора данных

В большинстве существующих инструментов LLM-for-OR этот этап не имеет аналогов. Это одно из важнейших структурных нововведений в ORPilot.

Большинство существующих инструментов LLM-for-OR предполагают, что данные встроены в текст задачи и достаточно малы, чтобы поместиться в подсказке. Для задач из учебников это работает. Для реальных задач это дает сбой по двум причинам. Во-первых, реальные наборы данных слишком велики. Например, задача о цепочке поставок, включающая 500 клиентов, 500 товаров и 12 периодов, будет содержать 3 000 000 записей о спросе. Во-вторых, встраивание данных в подсказку увеличивает риск возникновения иллюзий и неоправданно расходует контекстное окно.

Решение ORPilot заключается в том, чтобы рассматривать данные как нечто совершенно отдельное от запроса. Данные хранятся в CSV-файлах. Искусственный интеллект получает к ним доступ только путем написания и выполнения кода. Задача агента сбора данных — точно определить, как должны выглядеть эти CSV-файлы.

На основе описания проблемы, предоставленного агентом, проводившим интервью, агент по сбору данных определяет:

• Какие сущности (множества) существуют в модели?
• Какие атрибуты (параметры) необходимы каждой сущности?
• Точная схема для каждой необходимой таблицы: имена столбцов, типы, семантика.

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

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

Этап 3: Агент вычисления параметров

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

• Для модели маршрутизации транспортных средств необходима матрица попарных расстояний. Пользователь располагает GPS-координатами. Вычисление евклидовых или географических расстояний — это преобразование, полностью выходящее за рамки задач линейного программирования/целочисленного линейного программирования.
• Многопериодная производственная модель требует агрегированного спроса за период. Пользователь имеет реестр транзакций, содержащий одну строку на каждый заказ. Параметром модели является суммарное агрегирование, которое должно быть вычислено на основе исходных данных.

Агент по вычислению параметров автоматически устраняет этот разрыв. Он получает спецификацию задачи и необработанные CSV-файлы, а затем:

1. Определяет, какие параметры модели нельзя считать напрямую из исходных таблиц.
2. Генерирует скрипт на Python для вычисления этих производных параметров.
3. Выполняет скрипт в изолированной среде.
4. Записывает результаты в виде дополнительных CSV-файлов, передаваемых на этап моделирования.

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

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

Этап 4: Агент генерации кода

Имея на руках полное описание задачи, исходные данные и производные параметры, агент генерации кода создает полноценный скрипт решателя на Python для выбранного вами бэкэнда. В настоящее время ORPilot поддерживает пять бэкэндов: Gurobi, CPLEX, PuLP, Pyomo и OR-Tools.

Сгенерированный код немедленно выполняется в изолированной среде. Если что-то пойдет не так: синтаксическая ошибка, исключение во время выполнения или недопустимый/неограниченный результат решателя, полное сообщение об ошибке и трассировка стека передаются обратно в LLM вместе с ранее сгенерированным кодом. Агент повторяет попытки, до заданного пользователем максимального количества попыток.

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

Этап 5: Репортер-агент

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

Почему этот приказ важен

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

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

Как это выглядит в масштабе

Я протестировал ORPilot на нескольких задачах исследования операций, одна из которых — задача проектирования сети поставок с 50 производственными площадками, 50 распределительными центрами, 500 клиентами, 500 продуктами и 12 периодами. Полученная модель содержала более 9,7 миллионов переменных решений и 963 000 ограничений. ORPilot успешно обработал весь конвейер от начала до конца, от первоначального обсуждения и сбора данных до вычисления параметров, генерации кода и составления отчета о решении, получив оптимальное решение с помощью Gurobi. Результаты решения других тестовых задач можно посмотреть в моей статье здесь: https://arxiv.org/abs/2605.02728.

Начиная

ORPilot — это программное обеспечение с открытым исходным кодом, доступное уже сейчас:

GitHub: https://github.com/GuangruiXieVT/ORPilot
Статья: https://arxiv.org/abs/2605.02728

Установка занимает несколько минут. ORPilot поддерживает OpenAI, Anthropic, Google и DeepSeek в качестве поставщиков LLM-решений, а также Gurobi, CPLEX, PuLP, Pyomo и OR-Tools в качестве бэкэндов для решателей.

В следующей статье этой серии мы подробно рассмотрим промежуточное представление (IR) — независимый от решателя JSON-артефакт, который делает результаты ORPilot воспроизводимыми и переносимыми между различными бэкэндами без необходимости повторного вызова LLM. Следите за обновлениями!

Гуангруй Се: посмотреть все Гуангруй Се

Источник: towardsdatascience.com