01 — Кейс · ML Нейросети

AI-оптимизация логистики: маршруты и цепочки поставок

Мы разработали ИИ-систему оптимизации логистики: алгоритмы строят маршруты доставки с учётом реальных ограничений и помогают управлять цепочкой поставок — от планирования потребности до контроля исполнения. Проект выполнила команда полного цикла на Python с применением методов Data Science; от постановки задачи до рабочей системы прошло 5 месяцев. Ручное планирование сменилось расчётом: диспетчеры работают с готовыми маршрутами и лишь корректируют их, а решения по поставкам опираются на прогнозы вместо интуиции.

5 месяцевNDA

Обновлено: 14 июля 2026 г.

Смотреть кейс

срок проекта: 5 месяцев
функциональных модулей: 7
этапов разработки: 6
ключевых технологий: 5

AI-оптимизация логистики: маршруты и цепочки поставок

02 — Контекст

Задача проекта

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

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

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

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

Маршруты строятся вручную

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

Затраты растут с масштабом

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

Цепочка поставок непрозрачна

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

03 — Возможности

Что делает система

Ключевые сценарии и рабочие модули, собранные в единую систему.

Ядро маршрутной оптимизации

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

Учёт ограничений доставки

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

Планирование цепочки поставок

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

Перепланирование в течение дня

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

Контур данных Data Science

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

Рабочее место диспетчера

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

Интеграционный слой

Система встроена в существующий ландшафт заказчика, а не заменяет его. Через API заказы, остатки и справочники поступают из учётных систем, а рассчитанные маршруты и планы поставок возвращаются туда, где с ними работают люди. Обмен формализован контрактами данных, поэтому подключение новых источников не требует переделки ядра оптимизации.

04 — Архитектура

Технологический стек

Технологии выбраны под нагрузку, интеграции и дальнейшее развитие продукта.

Python

Язык всей системы: от алгоритмов оптимизации до API и подготовки данных. Для проектов на стыке математики и продакшена Python даёт лучшую экосистему — научные библиотеки, инструменты Data Science и зрелые веб-фреймворки в одном стеке. Один язык на все слои означает быстрые итерации и команду без искусственного деления на «исследователей» и «разработчиков».

Optimization Algorithms

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

Route Planning

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

Supply Chain AI

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

Data Science

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

Optimization Algorithms
Route Planning
Supply Chain AI
Python
Data Science

05 — Процесс

Как шла разработка

Последовательность работ от исследования задачи до запуска и проверки результата.

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

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

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

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

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

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

06 — Итог

Результаты

Что создано в рамках проекта: рабочий контур, реализованные возможности и подтверждённые факты.

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

Заказчик получил инструмент, который растёт вместе с бизнесом: эвристики масштабируются на большее число заказов и машин без пересборки ядра, интеграционный слой позволяет подключать новые источники данных, а контур Data Science измеряет качество планов на каждом шаге. Единый стек Python — от алгоритмов оптимизации до API — упрощает сопровождение и развитие: систему поддерживает одна команда, без разделения на исследовательскую и продуктовую части.

5 месяцев

от постановки задачи до рабочей системы

2 контура

маршруты доставки и цепочка поставок

7 модулей

от ядра оптимизации до интеграций

Python

единый стек алгоритмов, данных и API

Детали проекта

Почему кейс без имени клиента

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

Всё инженерное содержание кейса открыто: постановка задачи маршрутизации, архитектура двух контуров, стек Python с алгоритмами оптимизации и Data Science, ход проекта за 5 месяцев. Такого уровня детализации хватает, чтобы понять, ляжет ли подход на вашу доставку; предметный разговор с цифрами продолжим на встрече — не нарушая обязательств перед клиентом.

FAQ

Вопросы о проекте

Четыре группы: заказы — адреса, объёмы, веса, временные окна получателей; парк — грузоподъёмность, вместимость и доступность машин; водители — графики и ограничения смен; география — матрицы расстояний и времени в пути между точками. Для калибровки эвристик полезна история фактических рейсов за несколько месяцев. В этом проекте данные поступали из учётных систем заказчика через API, а контур Data Science очищал адреса и геокоординаты перед расчётом.

Через интеграционный слой с API: заказы, остатки и справочники поступают из учётных систем, а рассчитанные маршруты и планы поставок возвращаются в TMS и другие инструменты, где с ними работают диспетчеры и логисты. Обмен формализован контрактами данных, поэтому оптимизатор не заменяет существующий ландшафт, а встраивается в него — и подключение нового источника не требует переделки ядра.

Через сравнение с базовой линией. До запуска фиксируются метрики ручного планирования: суммарный пробег, число рейсов, загрузка транспорта, доля доставок в срок. Затем те же показатели считаются на алгоритмических планах — сначала ретроспективно, на исторических заказах, потом в пилоте, когда часть маршрутов строит система. Разница между «до» и «после» и есть измеримый эффект. Конкретные цифры этого проекта закрыты NDA, но методика воспроизводима в любой логистике.

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

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

Задача маршрутизации транспорта NP-трудна, поэтому вместо точного перебора работают эвристики и метаэвристики: они находят близкие к оптимуму решения за минуты даже на сотнях заказов. Python выбран за экосистему: оптимизационные библиотеки, инструменты Data Science и веб-фреймворки в одном языке. Вычислительно тяжёлые участки опираются на оптимизированные нативные библиотеки, так что скорость расчёта не страдает.

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