Как спрогнозировать спрос на самокаты и не захламить город, версия Whoosh

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

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

Меня зовут Никита Зеленский, я руковожу отделом по работе с данными в Whoosh, разработчике технологических решений и операторе микромобильности. Эту статью мы написали вместе с Иваном Маричевым, дата‑сайнтистом Whoosh. Он же и автор алгоритма, о котором пойдет речь.

Здесь мы расскажем, как мы реализовывали модель прогнозирования спроса на самокаты, с чем сталкивались при прототипировании, какие модели были протестированы, чем наш случай отличается от прогнозирования спроса в каршеринге, спроса для пополнения запасов в дарксторе и т. п. (Самокат, самокаты Whoosh передают привет!)

История получилась про наши подходы и грабли, которые мы в итоге собрали. Чуть‑чуть про технику, чуть‑чуть про бизнес — нескучно и с ветерком (как на самокате).

Whoosh!

Проблематика

Зачем менять устоявшуюся схему, разрабатывать ML‑модель, если можно все сделать в Экселе?

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

Вопрос — почему бы просто не выставлять сильно завышенное количество техники? Представим следующую картину: в среднестатистическом городе Х имеется 350–400 парковок (если не брать в расчет города‑миллионники). По каждой парковке мы собираем статистику: какое количество поездок пользователи на ней начали и закончили. Зная эти цифры, можно было бы оставлять на них количество самокатов, равное скользящему среднему от количества поездок за 7 дней + 20%? Но не все так просто:

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

2. Логистика. После появления такого количества флота на парковке, неизбежно вырастут расходы на ребалансировку, которые напрямую зависят от количества регулярно перевозимых самокатов.

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

4. Урбанистика. Отдельное «спасибо» можно ожидать от горожан и властей, которые явно не одобрят загромождение городских пешеходных зон большим количеством неиспользуемой техники.

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

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

EDA

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

Что мы имеем на входе?

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

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

3. Пропуски в данных. Наш бизнес имеет определенную сезонную динамику. В большинстве городов мы работаем 9 месяцев: с марта по ноябрь. А анализируя временные ряды, такие пробелы между датами (с декабря по февраль) просто так не выкинешь — их необходимо правильно обрабатывать: подсказывать модели периоды завершения сезона и его начала, что было между этими датами, а также периоды, когда локация встает на кратковременную паузу. В противном случае, мы будем иметь «кривую» линию тренда с завышенным или заниженным показателями.

Также в ходе EDA было определено, что прогнозирование на все 100% парковок для города не имеет бизнес‑смысла, так как 40% «топовых» парковок генерировали 80% всех поездок города.

В качестве тестового города выступает город Сочи в связи с тем, что сезон аренды самокатов в городах южного округа продолжается круглогодично. Тем самым мы, конечно, немного проигнорируем п.3 из списка нюансов выше, но у нас другие цели для MVP:

• Проверить работоспособность алгоритма (а это проще сделать без разрыва во временных рядах)

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

Выбор модели

С вводными разобрались, теперь приступим к выбору обучающей модели. Как упоминалось ранее, парковок, и, соответственно, рядов для прогнозирования, много — десятки тысяч. Для нас скорость обучения важна не менее (если не более), чем точность самой модели, поэтому при принятии решения какую модель (или модели) выбирать, мы основывались на показателях RMSE и среднему времени, которое мы получаем при прогнозировании данных для n‑парковок. Мы протестировали модели SARIMAX, LightGBM, Prophet и NeuralProphet.

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

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

SARIMAX же является расширением ARIMA с добавленными алгоритмами обработки сезонности и экзогенных переменных — регрессоров (используемые гиперпараметры — SARIMAX(3, 0, 2)x(2, 1, 1)).

Плюсы:

• Высокая точность уже «из коробки», учитывая доверительный интервал прогноза;

• Развёрнутая документация

• Из всех моделей прогнозирования временных рядов она является наиболее интерпретируемой, т.к. имеет четкое математическое обоснование.

Минусы:

• долгий подбор гиперпараметров (около 10 минут на парковку).

2. LightGBM — реализация градиентного бустинга за авторством Microsoft. По опыту примения бустинговых моделей (чаще всего в регрессионных задачах, хотя и в двоичной\множественной классификации алгоритм также хорош), LightGBM — явный фаворит в связи с более высокой (x1.5 — x2) скоростью обучения при практически идентичной точности (разница на уровне погрешности ± 1%) в сравнении с XGBoost, CatBoost, etc.
   
   Плюсы:

• Высокая скорость обучения.

• Большой набор гиперпараметров.

• Менее ресурсоемко по сравнению с аналогами.

• Возможность параллельного и GPU-обучения.

Минусы:

• К сожалению, мы получили переобучение. Даже при автоматизированном подборе гиперпараметров, на тесте так же отсутствует предсказательная способность. Решили не закапываться и поискать возможные альтернативы.

3. Prophet — относительно молодая библиотека прогнозирования от “ЛицоКниги”. Prophet является расширением авторегрессионных моделей, которое  позволяет использовать не только лаговые значения целевой переменной, но и дополнительные признаки (реализовано через ​​применение ряда Фурье к таргету), т.е. позволяет использовать дополнительные переменные — регрессоры. Для нас это было особенно актуально, так как сами лаговые значения таргета не обеспечивают точного прогноза, и требуются дополнительные независимые переменные.

Prophet имеет ряд других полезных функций, например:

• Высокая точность и скорость обучения “из коробки”.

• Удобно реализованы базовые функции (в частности, добавления регрессоров).

• Отслеживание изменений тенденции.

• Функционал создания пула дат со значениями-аутлаерами (праздниками, спортивными событиями), которые исключались из построения общего тренда + сезонности. 

• Поддерживается и регулярно обновляется разработчиками.

И пара минусов:

• По умолчанию нет настроек нормализации временного ряда и сопутствующих регрессоров.

• Пропуски\аутлаеры в данных лучше обработать вручную.

4. NeuralProphet ‑ модификация базовой библиотеки Prophet с добавлением нейронного слоя. По сравнению с Prophet бэкэнд переехал со Stan на PyTorch. Идея использовать Prophet, обладающий высокими результатами (особенно после тюнинга) по функциям потери\времени, и при этом добавить однослойную нейронную сеть для теоретического улучшения точности показалась нам крайне интересной, после чего мы построили модель уже на NeuralProphet. API у библиотек практически идентичны, как и почти все ключевые функции, поэтому технически реализовать было несложно.

   

Из плюсов можно выделить:

• Хороший уровень точности «из коробки»

• В библиотеку интегрирован слой pyTorch, благодаря которому реализован подбор параметров через градиентный спуск

• Автоматическая предобработка данных (заполнение пропусков, нормализация и т. д.)

Минусы:

• Низкая скорость обучения, связанная с профилированием DL‑настроек (количество эпох, learning rate, etc) для каждой парковки в индивидуальности

Что получили на выходе?

Табл.1 сравнения метрики RMSE и времени выполнения алгоритмов на n‑парковок.

Не трудно догадаться, что из всего зоопарка моделей нами в качестве рабочей был выбран Prophet. Связано это в первую очередь с простотой настройки модели и ее гипер‑параметров, удобным добавлением регрессоров и достаточной гибкостью при работе с различными структурами временных рядов.

Разумеется, как бы хороша библиотека не была, чуда «по умолчанию» не произошло, и прежде чем Prophet начал демонстрировать приемлемые результаты предстояло решить ряд проблем. Например, данные по температуре меньше -1°C модель принимала как NaN и пришлось видоизменять датасет с погодой под этот баг. На старте прототипирования у нас были сложности с прогнозированием пиков, так как к дневной сезонности прибавлялись естественные шумы. Решить эту проблему получилось путем добавлением регрессоров с высокой корреляцией к таргету, в первую очередь, связанные с погодными метриками и пользовательской активностью.

Большие надежды также возлагались на NeuralProphet, так как библиотека позиционируется как «быстрее‑выше‑сильнее Prophet во всем», однако в нашем случае это оказалось не совсем верно. Небольшую прибавку в точности (+3–5%) получалась только путем значительного увеличения количества эпох, как следствие — всего времени обучения в 2 — 2,5 раза.

В случае с топовыми и дефицитными парковками Prophet позволил умеренно‑эффективно прогнозировать данные не только там, где присутствует явная структура (тренд + сезонность), но и там, где спрос не обладает устойчивой структурой.

Общая модель ребаланса

Необходимо учитывать, что парковки обладают различной структурой не только в плане спроса («топовые» и «слабо востребованные»), но и в плане ориентированности.

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

Искушенный аналитик спросит — для чего вообще рассчитывать финиши, если они, в отличие от стартов, не аккумулируют прибыль и их нет необходимости как‑либо обеспечивать со стороны ребаланса?

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

1. Берем последнее историческое наблюдение количества самокатов (scooters_last).

2. Прогнозируем количество стартов на ближайшие X‑часов (starts_forecast).

3. Прогнозируем количество финишей на тоже количество X‑часов (finishes_forecast).

Необходимый флот на парковку = scooters_last - starts_forecast + finishes_forecast

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

На выходе мы получаем таблицу такого вида:

где:

ds — время, к которому подвезти самокаты,

parking_id — номер парковки,

rebalance — фактическое значение ребаланса (положительное — профицит, отрицательное — дефицит),

class_ — тип парковки, требуется для приоритизации парковок для сервисных центров.

Вывод

В статье кратко рассказали, как мы реализовывали алгоритм расчета ребаланса, основная цель которого — оптимизировать человеко‑часы и облегчить жизнь нашим сервисным командам, которые обеспечивают пользователей самокатами.

Разумеется, это далеко не весь список задач, в который у нас внедрен ML: здесь и классификации (в том числе и гео‑классификации по индексу Морана), и регрессионные модели расчета целевых бизнес метрик, и многое другое.

Если статья показалась вам интересной, и вы хотите продолжения — пишите в комментариях, мы с удовольствием ответим на вопросы по теме.

Уважайте пешеходов, водите осторожно и до встречи на улицах.

Whoosh!