Разработка AI-системы оптимизации маршрутов доставки

Почему AI оптимизация маршрутов доставки ломается на реальных данных

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

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

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

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

Что меняется после внедрения: эффект в измеримых метриках

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

• Сокращение пробега — суммарный километраж на сопоставимом числе точек падает на 8–15%: маршрутизатор собирает цепочки по времени и геометрии, а не в порядке поступления заявок.
• Порожние рейсы — доля перегонов без груза уходит вниз, потому что обратная загрузка планируется в том же проходе, а не отдельным звонком диспетчера.
• Доля опозданий по окнам доставки — считается по факту въезда на точку; жёсткие окна и приоритеты клиентов заданы ограничениями, поэтому план не рассыпается на первой же пробке.
• Нагрузка диспетчера — время на ручные правки сокращается с часов до минут: система перестраивает день при срыве окна, а человек подтверждает изменения.
• Равномерность загрузки — разброс числа точек и веса по машинам уменьшается, крайние перегрузы рейсов уходят.

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

Режимы работы: онлайн-пересчёт, пакетный расчёт, гибрид

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

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

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

Этапы внедрения: от аудита данных до передачи в эксплуатацию

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

1. Аудит данных о доставке. Выгружаем историю рейсов, адреса точек, временные окна получателей, вес и габариты груза, режим труда водителей. Считаем долю адресов без точной геопривязки, заказов без окна и дублирующихся точек — именно эти пробелы дают нереалистичные сроки в расчёте.
2. Схема решения. Определяем, что считает система, а что остаётся за человеком: жёсткие ограничения (грузоподъёмность, время смены, запреты проезда) и мягкие предпочтения (постоянные клиенты, равномерная загрузка машин). Фиксируем, что именно оптимизируем — пробег, число машин или соблюдение окон.
3. Настройка правил планирования. Правила, которые диспетчер держит в голове, переводим в формальные ограничения и веса. Каждое проверяем на конфликт с остальными, спорные пары разводим по приоритетам, чтобы расчёт не «зависал» на взаимоисключающих условиях.
4. Проверка на исторических рейсах. Прогоняем план на закрытых периодах и сравниваем с фактом: пробег, опоздания, число задействованных машин, доля ручных правок. Расхождения разбираем вместе с диспетчерами, уточняем правила и повторяем цикл, пока отклонения не станут объяснимыми.
5. Пробный запуск на одном участке. Один филиал или смена работает в системе параллельно с привычным планированием: сверяем результат в реальном времени, снимаем возражения диспетчеров до того, как менять процесс целиком.
6. Передача в эксплуатацию. Передаём конфигурацию, регламенты и порядок ручных правок, обучаем диспетчеров на их же маршрутах, фиксируем роли и права доступа. Дальше — сопровождение и донастройка правил по фактическим данным.

Что передаём на руки: конфигурации, схемы и регламенты

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

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

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

Кейс: парк доставки после перехода на AI-планирование рейсов

Кейс: дистрибьютор с собственным парком и двумя складами

Точка отсчёта

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

Что изменили и что получили

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

• Пробег на маршрут сократился на 18% при том же объёме заказов.
• Число рейсов уменьшилось на 12%: часть точек объединили в один выезд.
• Доставка в срок выросла с 87% до 98%, опоздания по вине планирования почти исчезли.
• Время диспетчера на ручную корректировку — с трёх часов до получаса за смену.
• Отказы из-за сдвинутых окон доставки сократились вдвое.

Такой разрыв между «до» и «после» даёт не отдельная формула, а связка модели с ограничениями реального парка и понятным процессом пересчёта плана.

Чем потоковая оптимизация отличается от пакетного пересчёта

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

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

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

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

Технические сомнения: данные, интеграции и контроль диспетчера

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

У нас уже развёрнута система планирования — её придётся менять?

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

Диспетчер сможет править маршрут вручную?

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

Обсудим задачу: что нужно для первого этапа

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

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

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