Прогнозирование спроса и перебалансировка флота каршеринга с AI

AI каршеринг: где ломается баланс спроса и машин

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

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

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

Разбираем, как прогноз спроса по зонам на коротком горизонте и планирование перебалансировки с AI закрывают этот разрыв — от подготовки данных до работы в ежедневном режиме.

AI каршеринг: загрузка флота и перепробег после внедрения

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

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

После внедрения сдвигаются метрики, по которым флот и оценивают. Загрузка автомобиля — доля времени, когда машина выполняет заказ или едет к клиенту, — поднимается с 40–50% до 60–65%. Время простоя в дефицитных зонах сокращается примерно вдвое, доля отмен по причине «нет машины рядом» падает на 30–40%, а коэффициент использования флота растёт без закупки новых машин.

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

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

Варианты прогнозирования спроса: сравнение подходов

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

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

Перед внедрением прогоняем каждый вариант на отложенном отрезке истории и смотрим, в какой доле зон прогноз не попал в фактический спрос — это и определяет выбор.

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

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

1. Аудит данных телематики — проверяем полноту треков, корректность статусов, часовые пояса и связность поездок с тарифами; на выходе перечень зон и периодов, где данные пригодны для обучения.
2. Подготовка признаков — агрегируем спрос в окна по 15–30 минут и по зонам, добавляем календарь, погоду, события и историю загрузки, чтобы модель видела причину роста, а не только сам факт.
3. Настройка модели — обучаем прогноз спроса на горизонте от часа до суток, отдельно для будней, выходных и аномальных дней, с проверкой устойчивости к пропускам в данных.
4. Калибровка перебалансировки — прогноз превращаем в решения: сколько машин и куда переставить, с ограничениями по пробегу, зонам и времени подачи, чтобы подсказки были выполнимы.
5. Проверка модели на истории — прогоняем решения на прошлых периодах и сравниваем с тем, как флот работал фактически: ошибка прогноза, доля необслуженного спроса, холостой пробег.
6. Передача в эксплуатацию — фиксируем регламент переобучения, мониторинг качества прогноза и понятные диспетчеру экраны; дальше команда заказчика меняет пороги и зоны сама.

Конфигурации, правила перебалансировки и регламенты

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

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

Артефакты лежат рядом с конфигурацией и обновляются тем же изменением — расхождению между документацией и работающим сервисом взяться неоткуда.

Кейс: перепробег и простои флота до и после

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

Внедрили почасовой прогноз спроса по зонам на 2–4 часа вперёд: модель на LightGBM учитывает историю по дням недели, погоду, городские события и перекрытия. На его основе распределение машин между зонами считалось как задача минимизации суммарного перепробега при покрытии прогнозного спроса — с жёстким лимитом на длину перегона.

Метрики до и после

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

Что делать, если телематика уже есть, а данных для модели мало?

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

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

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

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

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

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

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

Как прогноз стыкуется с системой бронирования?

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

Кто сопровождает модель после запуска?

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

Как часто нужно переобучение?

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

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

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

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

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

Опишите задачу — вернёмся с оценкой и планом.