Комплектовщик на складе 8000 м² с фронтальными стеллажами проходит за смену 15–22 километра. Шаги — это 50–60% рабочего времени и 70% усталости. Сократить шаги на 25% можно ML-моделью, которая анализирует историю заказов, физическую раскладку склада и совместное появление SKU в заказах — и генерирует маршрут лучше, чем базовый алгоритм S-shape или ручная маршрутизация бригадира.
Ниже — как устроена AI-маршрутизация, какие данные нужны для обучения модели, как интегрировать её с WMS, сколько стоит внедрение и какой ROI получается на типовых кейсах. С разбором двух реальных проектов — у крупного российского e-commerce-ритейлера и регионального FMCG-дистрибьютора.algorithms
Что не так с базовыми алгоритмами маршрутизации
Все WMS из коробки используют один из трёх базовых алгоритмов маршрутизации. Каждый имеет ограничения, которые на больших складах с десятками тысяч SKU превращаются в реальные потери времени.
S-shape (змейка). Оператор проходит проход целиком, разворачивается, идёт следующий. Простой и предсказуемый алгоритм. Минусы: если в проходе одна позиция в начале и одна в конце — оператор проходит весь проход в обе стороны. На длинных проходах (60–80 м) это даёт 20–30% лишних шагов.
Largest-gap (наибольший разрыв). Оператор входит в проход, идёт до самой дальней нужной позиции, разворачивается, забирает остальные на обратном пути. Лучше S-shape на проходах с малым числом позиций, но проигрывает на проходах с равномерным распределением.
Combined (комбинированный). WMS выбирает между S-shape и largest-gap для каждого прохода в зависимости от числа позиций. Лучший из базовых, но всё равно работает в логике «проход за проходом» — не видит картину всего заказа.
Проблема всех базовых алгоритмов — они оптимизируют локально (внутри прохода), а не глобально (по всему складу). Реальная оптимальная задача — это вариация задачи коммивояжёра (TSP), которая для 30–50 точек на пик не решается за реальное время простыми переборами.
Здесь и появляется ML: модель учится на тысячах прошлых маршрутов и предсказывает оптимальный порядок обхода для нового заказа за 1–5 секунд. Точность приближается к 95–99% от математического оптимума при разумных вычислительных затратах.
Шаг 1: данные для обучения модели
Модели нужны три категории данных. Без них любой алгоритм работает в режиме «угадай».
Категория 1: топология склада. Координаты каждого адреса хранения (X, Y, Z), ширина проходов, расположение тупиков, точек входа/выхода, зон погрузки. На складе 8000 м² с 12 000 адресами это таблица в 12 000 строк с 5–8 параметрами. Источник: WMS + чертёж склада, обновляется при перестановках стеллажей.
Категория 2: история заказов и маршрутов. За 6–12 месяцев. Для каждого заказа: список SKU, фактический маршрут оператора (по логам сканера или GPS терминала), время цикла, число шагов (по шагомерам или расчёту), ошибки сборки. Минимум 10 000 заказов для базовой модели, оптимально 50 000+ для точной.
Категория 3: характеристики SKU. Габариты, вес, частота заказа (за 30/90/365 дней), частота совместного появления с другими SKU (matrix), категория, оборачиваемость. Эти данные используются для решения о слоттинге (где лучше хранить SKU) и для весовых коэффициентов маршрута.
Подготовка данных занимает 4–8 недель работы аналитика. Главные сложности: чистка дублей в адресной системе (типично 3–8% адресов имеют ошибки), сопоставление логов сканера с реальным маршрутом (требует валидации на 100–200 случайных заказах), сбор данных о фактических шагах (если нет шагомеров — расчёт по координатам и эвристикам).
Шаг 2: выбор модели и архитектуры
Три семейства ML-моделей применимы для маршрутизации пикинга. Каждое имеет нишу.
Семейство 1: gradient boosting (XGBoost, LightGBM, CatBoost). Учится на признаках: позиции SKU в заказе, время суток, вес товара, размер заказа, опыт оператора. Предсказывает оптимальный порядок обхода как ранжирование точек. Простота настройки — главный плюс. Подходит для складов с 1000–10 000 SKU, заказов до 30 позиций. Точность 88–93% от математического оптимума.
Семейство 2: reinforcement learning (DQN, PPO). Модель «играет» в маршрутизатор: пробует разные порядки обхода, получает награду за короткий маршрут. Учится на тысячах симуляций. Подходит для сложных складов с большими заказами (30+ позиций) и нестандартной топологией (несколько уровней, лифты, мезонин). Точность 92–96%. Сложнее в обучении и поддержке.
Семейство 3: graph neural networks (GNN). Представляет склад как граф (узлы — адреса, рёбра — расстояния), модель учится на структуре графа. Идеально подходит для очень больших складов с десятками тысяч адресов и сложной топологией (несколько корпусов, переходы). Точность 95–98%. Самое сложное в имплементации, требует команды ML-инженеров.ml-models
Выбор. Для большинства проектов в РФ (склады 3000–15 000 SKU, заказы 5–25 позиций) оптимально gradient boosting — баланс точности, сложности и стоимости разработки. Reinforcement learning — для крупных e-com операторов (Ozon, Wildberries, СберМегаМаркет). GNN — пока редкий выбор, в основном в зарубежных проектах с очень большим масштабом.
Сравнение с другими подходами к организации маршрутов — в материале о маршрутизации пикинга.
Шаг 3: обучение модели
Процесс обучения занимает 2–6 недель, в зависимости от объёма данных и выбранной модели.
Этап 1: предобработка (1–2 недели). Из таблицы заказов и маршрутов формируют обучающую выборку. Каждый случай — это «вход (заказ + текущее состояние склада) → выход (оптимальный порядок обхода)». Если ручной маршрут не был оптимальным, корректируют целевую переменную математическим решением TSP для этого конкретного заказа.
Этап 2: разделение на выборки (1 день). Случайная разбивка 70/20/10: 70% на обучение, 20% на валидацию (подстройка гиперпараметров), 10% на тест (финальная оценка качества).
Этап 3: обучение базовой модели (3–7 дней). Подбор гиперпараметров (maxdepth, learningrate, n_estimators для boosting). На современной GPU-машине (RTX 4090 или Tesla T4) обучение одной модели занимает 4–12 часов, всего 50–200 экспериментов до оптимума.
Этап 4: тестирование на симуляторе (1 неделя). Перед запуском в продакшен модель тестируется на симуляторе склада с реальной топологией и историческими данными. Проверяют: что модель не «зацикливается», не предлагает физически невозможные маршруты, работает на разных типах заказов (мелкие, крупные, разнородные).
Этап 5: A/B тест на 10–20% операторов (2–4 недели). Половина операторов получает маршруты от старого алгоритма, половина — от ML-модели. Сравнивают по 8 метрикам: число шагов, время цикла, ошибки, утомляемость, простои в проходах, пересечения, число возвратов, удовлетворённость операторов.
Этап 6: полное развёртывание (1–2 недели). После успешного A/B-теста модель внедряется на 100% операторов. Включается мониторинг качества: модель переобучается каждые 30–60 дней на новых данных, чтобы адаптироваться к изменениям ассортимента и слоттинга.
Шаг 4: интеграция с WMS
ML-модель сама по себе не выдаёт команды операторам. Это делает WMS через терминалы сбора данных, голосовые headset или AR-очки.
Архитектура интеграции:
Заказ от клиента → WMS → ML-сервис (REST API)
↓
Маршрут (упорядоченный список адресов)
↓
WMS → Терминал оператора
Время отклика ML-сервиса должно быть менее 500 мс на запрос, чтобы оператор не ждал команды дольше 1 секунды от появления нового заказа. На современных серверах (16–32 ядра CPU, 32–64 GB RAM) одна машина обрабатывает 50–150 запросов в секунду — достаточно для склада с 50–200 одновременно работающих операторов.
Резервирование. ML-сервис — единая точка отказа. Решение: два сервера в балансе нагрузки, при сбое одного второй берёт 100% потока. Также fallback на базовый алгоритм S-shape, если оба ML-сервера недоступны — система не остановится, просто потеряет в эффективности на время сбоя.
Подводный камень: «бывает» в WMS. Если оператор отклонился от рекомендованного маршрута (взял позицию из соседнего прохода, вспомнил про пропущенную позицию), модель должна корректировать маршрут на лету. Иначе оператор раздражается и игнорирует подсказки. Современные ML-системы пересчитывают маршрут каждые 3–5 шагов, адаптируясь к фактическому положению оператора.
Шаг 5: запуск и мониторинг
После полного развёртывания ML-модель требует постоянного мониторинга и поддержки.
Метрики качества. Среднее число шагов на заказ (цель: −20…−30% от базового). Среднее время цикла (цель: −30…−45%). Доля заказов с ошибками (цель: −10…−20%). Среднее использование подсказки (доля случаев, когда оператор следует рекомендации; цель: 85–95%).
Переобучение. Раз в 30–60 дней модель переобучается на свежих данных (последние 90 дней). Это нужно, потому что ассортимент склада меняется: появляются новые SKU, исчезают старые, меняется слоттинг (часто меняемые товары перемещаются ближе ко входу). Без переобучения качество модели падает на 5–10% за квартал.
Аномалии. Мониторинг отклонений: если в одной зоне склада время цикла резко выросло — возможно, перестановка стеллажей не отражена в WMS, или в зоне сбой освещения. ML-система должна сигналить о таких аномалиях в дашборд диспетчера.
A/B тестирование улучшений. Каждый раз, когда команда выпускает новую версию модели, она запускается на 5–10% операторов параллельно с текущей. Если новая версия лучше на 2–3% — переключаем всех. Если хуже — откатываем.
Бюджет проекта
Полный CAPEX внедрения AI-маршрутизации для склада 5000–10 000 м².
| Статья | Сумма, млн ₽ | Доля |
|---|---|---|
| Аудит данных WMS и слоттинга | 0,8 | 8% |
| Разработка ML-модели (команда 3 чел × 3 мес) | 4,5 | 45% |
| Серверная инфраструктура (2 сервера + СУБД) | 1,2 | 12% |
| Интеграция с WMS (API, шина данных) | 1,8 | 18% |
| Адаптация терминалов сбора данных | 0,5 | 5% |
| Обучение операторов и бригадиров | 0,3 | 3% |
| A/B тестирование и пуско-наладка | 0,5 | 5% |
| Резерв на доработки (12%) | 0,4 | 4% |
| **Итого CAPEX** | **10,0** | 100% |
OPEX в год: поддержка модели (1 ML-инженер на 30% занятости) — 1,2 млн ₽, серверная инфраструктура (хостинг, обновления) — 0,4 млн, переобучение и улучшения — 0,5 млн. Итого 2,1 млн ₽/год.
ROI. На складе с 30 комплектовщиками средняя экономия от −25% шагов = +25% производительности = +7,5 эквивалента ставок. По стоимости ставки 600 тыс ₽/год — 4,5 млн ₽ экономии в год. Окупаемость CAPEX: 10 / 4,5 = 2,2 года.
Кейс 1: e-commerce ритейлер 18 000 м², 35 000 SKU
Крупный российский интернет-магазин (бытовая электроника, мелкая бытовая техника) запустил AI-маршрутизацию на распределительном центре в Подмосковье. До проекта работала комбинированная алгоритмика, 65 комплектовщиков в две смены, среднее время цикла 7,5 минут на заказ из 8 позиций.
Внедрение. Модель reinforcement learning (PPO) на топологии 18 000 адресов с уровнями + мезонин. Команда из 4 ML-инженеров работала 4 месяца. Тренировка на 280 тыс заказов за 9 месяцев истории.
Результаты через 6 месяцев после полного развёртывания. Среднее время цикла: 4,5 минут на заказ (−40%). Среднее число шагов на маршрут: −28%. Доля ошибок сборки: с 0,85% до 0,52% (−39%). Штат комплектовщиков: с 65 до 48 (−26%). Использование подсказки: 91% (среди операторов с опытом 3+ месяца).
CAPEX 14 млн ₽, OPEX 3 млн/год, экономия 18 млн/год. Окупаемость 9 месяцев.
Подводные камни. Через 4 месяца обнаружили, что модель «разучилась» работать с новыми SKU (категория умных колонок, которой не было в исторических данных) — пришлось внеплановое переобучение на сборном датасете. С этого момента ввели правило: внеплановое переобучение при появлении новой категории объёмом более 500 SKU.
Кейс 2: FMCG-дистрибьютор 6500 м², 9000 SKU
Региональный дистрибьютор бакалеи и снеков в Поволжье. До проекта — простой S-shape, 22 комплектовщика, среднее время цикла 5 минут на заказ из 12 позиций. Ошибки сборки 1,3%.
Внедрение. Модель gradient boosting (XGBoost) на 9 тыс адресов одного уровня. Команда из 2 человек работала 2,5 месяца. Тренировка на 65 тыс заказов за 12 месяцев истории.
Результаты через 4 месяца. Среднее время цикла: 3,5 минут (−30%). Шаги −23%. Ошибки: с 1,3% до 0,9% (−31%). Штат: с 22 до 17 (−23%).
CAPEX 5,5 млн ₽, OPEX 1,4 млн/год, экономия 5,5 млн/год. Окупаемость 12 месяцев.
Особенность кейса: при выборе модели специально остановились на простом gradient boosting, а не на reinforcement learning. Причина — наличие в команде только одного ML-инженера, поддержка более сложной модели была бы рискованной. Это правильный подход: лучше получить 90% эффекта от простой модели, чем 100% от сложной с риском «зависнуть» при сбое.
Связь с другими процессами склада
AI-маршрутизация — это часть более широкой автоматизации процесса комплектации. Сама по себе она не работает без правильного слоттинга (когда часто заказываемые SKU стоят ближе ко входу), без чистых данных в WMS, без современных терминалов сбора данных у операторов.
Связь со слоттингом. Модель маршрутизации работает на «фиксированной» топологии — она оптимизирует обход данных позиций. Но сами позиции тоже можно оптимизировать: переставить часто заказываемые SKU ближе ко входу, сгруппировать товары, которые часто покупают вместе. Это слоттинг SKU, и в связке с AI-маршрутизацией он даёт дополнительные 10–15% сокращения шагов.
Связь с прогнозированием спроса. Если модель знает прогноз заказов на ближайшие 4–8 часов, она может «предсказывать» оптимальный слоттинг и предлагать пополнения с правильным размещением. Это уже следующий уровень — predictive picking, который внедряют единичные компании в РФ.
FAQ — AI-маршрутизация
Можно ли использовать AI-маршрутизацию без WMS?
Нет. Без WMS нет данных о заказах, позициях, перемещениях. AI-модель — это «надстройка» над WMS, она получает входные данные оттуда и возвращает рекомендации. Минимальные требования к WMS: API для интеграции (REST или SOAP), регулярное обновление адресной системы, чистые данные по слоттингу.
Сколько данных нужно для запуска модели?
Минимум 10 000 заказов с фактическими маршрутами за период не менее 3 месяцев. На таком объёме модель работает на уровне 88–92% от математического оптимума. Для 95%+ нужно 50 000+ заказов. Если данных меньше — лучше начать с базового combined-алгоритма и собирать данные параллельно, а ML внедрять через 6–12 месяцев.
Как операторы воспринимают подсказки модели?
После первых 2–3 недель адаптации — позитивно. Усталость падает на 20–30% (меньше шагов), доход на сделке растёт (если оплата сдельная — больше заказов в смену). Главный риск отторжения — если модель предлагает «странные» маршруты в начале (зигзагом по складу). Решение — постепенный запуск (10% → 30% → 100% операторов) с возможностью отключить подсказки для тех, кто не справляется.
Что делать при перестройке склада?
При значительной перестройке (новые зоны, изменение проходов) модель временно теряет точность (3–7 дней работает на 70–80% возможностей). Решение: за неделю до перестройки добавить новую топологию в модель и сделать ускоренное переобучение на исторических данных с симуляцией новой топологии. Это требует 1–2 дней работы ML-инженера.
Какова разница между cloud-моделью и on-premise?
Cloud-модель (как сервис от внешнего провайдера) — быстрее запустить (2–4 месяца vs 4–6 месяцев), меньше CAPEX (3–6 млн вместо 10–14), но требует устойчивого интернета и не подходит для складов с ограниченным доступом к внешним сервисам (объекты гособоронзаказа). On-premise (свои серверы) — дороже на старте, но полный контроль над данными и независимость от внешних провайдеров.
AI-маршрутизация — это уже не эксперимент, а проверенная технология с понятной окупаемостью. На складах с 20+ комплектовщиков и сложной топологией — это стандарт-2026. Главное правило: не пытаться внедрить ML до того, как наведён порядок в данных и базовой автоматизации. Иначе вместо +25% производительности получите −5% и потерянные инвестиции.
algorithms: Базовые алгоритмы маршрутизации: S-shape (змейка по проходам), largest-gap (выбор большего разрыва), combined (комбинированный), optimal (точное решение TSP для малых заказов). ml-models: Типовые ML-модели для пикинга: gradient boosting (XGBoost, LightGBM), reinforcement learning (DQN, PPO), graph neural networks для маршрутов с учётом топологии склада.