Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Ограничения маршрута, написанные обычным текстом, научились добавлять к уже обученному нейросетевому решателю без изменения его весов. В препринте Hironori Ohigashi, который не прошёл рецензирование и содержит полученные автором числа, LangNCO находила допустимый маршрут для каждого примера в основных наборах, а средний разрыв с эталонными решениями составил 1,63–3,26%. Это даёт командам схему для временных запретов и правил, ради которых раньше пришлось бы менять входы модели или обучать её заново.
Как текст превращается в исполнимое правило
LangNCO отделяет понимание требования от поиска маршрута. LLM переводит фразу вроде запрета на проезд между двумя точками или назначения клиента конкретной машине в небольшой предметно-ориентированный язык правил (DSL), но не строит маршрут и не генерирует произвольный программный код.
Каждое правило задаёт цель, условия и действие. Целью может быть депо, конкретный узел или группа клиентов с нужным признаком. Условия обращаются к состоянию маршрута: текущей точке, посещённым клиентам, номеру машины, использованной вместимости, времени, длине пути или дополнительным данным симулятора.
После генерации система разбирает JSON, проверяет его по схеме и компилирует тем же компонентом, который затем исполнит правило. Такая цепочка отсекает неизвестные операции, неверные способы доступа к состоянию и несовместимые формы данных. Она гарантирует, что правило можно выполнить, но не доказывает, что LLM правильно поняла исходную фразу.
Исполнитель объединяет новое правило с базовыми ограничениями задачи. Он может только исключить действие, которое исходный решатель считал допустимым, но не вернуть переход, запрещённый вместимостью машины или уже посещённым клиентом. Поэтому вмешательство не меняет внутреннее представление модели, архитектуру и параметры.
Метод проверяли на замороженной политике для задачи маршрутизации с ограниченной вместимостью машин. Основная часть охватила четыре вида требований: закрытые дороги, временные окна, назначение машины и порядок посещения; каждый набор содержал 300 примеров. Дополнительно автор составил все попарные сочетания и двенадцать других типов ограничений. Формулировки оставались контролируемыми и предметными, поэтому работа проверяет адаптацию решателя, а не устойчивость к произвольным сообщениям пользователей.
Почему одной маски действий недостаточно
Жёсткая маска предотвращает немедленное нарушение, но не гарантирует, что маршрут удастся закончить. Машина может потратить вместимость до визита к закреплённому за ней клиенту, пропустить временное окно или вернуться в депо раньше обязательной точки. Каждое отдельное действие при этом выглядит разрешённым.
LangNCO извлекает из правил критические узлы: клиентов, которых правило ограничивает напрямую, и точки, от посещения которых зависит доступность других действий. Часть прогонов получает смещение в пользу таких узлов. Запрещённые действия не возвращаются, а общий бюджет поиска не растёт.
На ограничении по назначению машины добавление обычного прогона подняло долю допустимых решений с 75,33 до 77,33%, тогда как прогон со смещением довёл её до 100%. Это показывает разницу между дополнительной случайной попыткой и поиском, который использует структуру правила.
Среднее время работы декодера почти не изменилось: 173,78 мс у обычной выборки против 174,68 мс у варианта со смещением. В этот замер не входили генерация правил и их компиляция.
Для сочетаний требований правила создавали раздельно, а затем объединяли без обработчиков под конкретную пару. На дополнительных типах ограничений проявились две разные причины ошибок: извлекатель критических узлов не раскрыл группу клиентов, заданную через признак, а для срока возврата LLM иногда создавала формально корректное правило с неверным смыслом.
LangNCO меняет интеграцию, но не заменяет проверку требований
Работа меняет планы команд, у которых уже есть быстрый нейросетевой решатель, а эксплуатационные правила меняются после его обучения. Вместо расширения входов модели под каждый запрет можно вынести новые требования в отдельный слой: LLM разбирает текст, схема ограничивает доступные конструкции, детерминированный исполнитель меняет набор действий, а исходная модель продолжает оптимизировать маршрут.
Такая архитектура сохраняет LLM заменяемой. Решатель не зависит от конкретной языковой модели, если та выдаёт правила в одной схеме. Правила также можно показать оператору, сохранить для аудита и проверить отдельно от маршрутизатора.
В продуктовый план всё равно придётся включить смысловую проверку правил. Валидный JSON и успешная компиляция защищают исполнение, но не подтверждают, что запрет на поздний возврат превратился именно в ограничение возврата, а не прибытия к клиенту. Для чувствительных процессов нужен набор предметных тестов и отказ от выполнения правила, которое не прошло проверку.
Подход применим к ограничениям, которые можно проверить по текущему состоянию и следующему действию. Для требований, оцениваемых только после построения полного решения, эта схема сама по себе не подходит. Ей также нужен доступ к соответствующему состоянию симулятора: времени, истории визитов, вместимости или другим признакам, на которые ссылается правило.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
