Прогнозування попиту та перебалансування флоту каршерінгу зі ШІ

ШІ-каршеринг: де ламається баланс попиту й машин

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

Це не сезонна аномалія, а наслідок того, що розподіл парку задається статично, тоді як попит змінюється постійно.

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

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

У ручного перебалансування своя ціна. Перепробіг під час перебалансування — це кілометри, пальне та оплачені години зміни, а сама машина в момент перегону недоступна для замовлення: вона обліковується в системі, але клієнт не може її взяти. Частка простою автомобілів зростає, утилізація парку падає, і частина заявок зникає безповоротно.

Розбираємо, як прогноз попиту за зонами на короткому горизонті та планування перебалансування зі ШІ закривають цей розрив — від підготовки даних до роботи в щоденному режимі.

ШІ-каршеринг: завантаження флоту та перепробіг після впровадження

Прогноз попиту будується за зонами та півгодинними інтервалами: модель навчається на історії замовлень, міському календарі, погоді та подіях і перенавчається за ковзним вікном.

Точність вважаємо для кожної зони окремо, а не середнім по флоту — помилка в дефіцитному районі перетворюється на скасування, а не на зайві хвилини очікування.

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

Перегін запускається лише тоді, коли очікуваний приріст виконаних замовлень перекриває перепробіг, інакше машина залишається на місці.

Після впровадження зміщуються метрики, за якими флот і оцінюють. Завантаження автомобіля — частка часу, коли машина виконує замовлення або їде до клієнта, — піднімається з 40–50% до 60–65%.

Час простою в дефіцитних зонах скорочується приблизно вдвічі, частка скасувань через «немає машини поруч» падає на 30–40%, а коефіцієнт використання флоту зростає без закупівлі нових машин.

Перепробіг під час перегону знижується на чверть-третину за тієї ж кількості перестановок: оптимізатор обмінює далекі перегони на ближчі й відмовляється від переміщень, які не окупаються попитом.

Побічний ефект — рівномірніший знос і рідше позапланове обслуговування, бо порожнього пробігу стає менше.

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

Варіанти прогнозування попиту: порівняння підходів

Вибір підходу визначають горизонт прогнозу, обсяг накопиченої історії та ціна помилки. Прості правила перебалансування — це пороги за кількістю вільних машин у зоні на годинний слот: не вистачає — підвозимо із сусідньої.

Працюють з першого дня і без даних, але не знають про дощ, концерт і разовий сплеск попиту біля бізнес-центру.

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

Навчання на даних телематики додає зовнішні ознаки — погоду, міські події, завантаженість доріг — і рахує прогноз для кожної зони окремо, зате потребує моніторингу розходження прогнозу з фактом.

Перед впровадженням проганяємо кожен варіант на відкладеному відрізку історії й дивимося, у якій частці зон прогноз не влучив у фактичний попит — це й визначає вибір.

Етапи впровадження: від аудиту даних до передачі в експлуатацію

Аудит даних телематики майже завжди змінює план робіт: у логах знаходяться розриви треків, різні часові пояси в машин парку, «залиплі» статуси зайнятості та поїздки, закриті за тарифом, а не за фактом.

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

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

Конфігурації, правила перебалансування та регламенти

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

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

Артефакти лежать поруч із конфігурацією й оновлюються тією ж зміною — розходженню між документацією та працюючим сервісом узятися нізвідки.

Кейс: перепробіг і простої флоту до та після

Парк у кілька сотень машин перебалансовували за фіксованими маршрутами, спираючись на звіт за минулу добу. До вечірнього піку машини закінчувалися в спальних районах і простоювали біля ділового центру, а дефіцит у зоні закривався через годину-півтори, коли попит уже спадав. Зайвий перегін додавав пробіг і часто закінчувався без замовлення.

Впровадили погодинний прогноз попиту за зонами на 2–4 години вперед: модель на LightGBM враховує історію за днями тижня, погоду, міські події та перекриття.

На його основі розподіл машин між зонами рахувався як задача мінімізації сумарного перепробігу за покриття прогнозного попиту — з жорстким лімітом на довжину перегону.

Метрики до та після

Результат перебалансування утримуємо на щоденному контролі: відхилення факту від прогнозу для кожної зони, частка перегонів без наступного замовлення, час реакції на сплеск попиту.

Якщо помилка прогнозу виходить за поріг, розклад повертається як страхувальний режим, а модель перенавчається на свіжому вікні даних.

Що робити, якщо телематика вже є, а даних для моделі мало?

Так, старт можливий: модель попиту не потребує багаторічної історії. Достатньо позицій із часовими мітками, статусом зайнятості, позначками початку й кінця поїздок та рівнем заряду — цього вистачає, щоб відновити добовий профіль попиту за зонами.

Складність неповної телематики не в обсязі, а в неоднорідності: різні інтервали опитування, пропуски в треках, загублені події зміни статусу. Тому перший крок — розбір якості даних: частка пропусків за кожним полем, частка викидів, скільки машин мовчить довше звичайного. Що не проходить поріг — лагодиться на джерелі або в розрахунок не береться.

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

Без власної історії модель навчають на сусідньому парку або місті зі схожим профілем, а на місці дообучують на своєму потоці — перенесення надійне на стійких закономірностях ранку, вечора та вихідних і слабше на локальних аномаліях, які закриваються правилами.

Розширення йде етапами: прогноз за зонами та годинами, потім перебалансування з урахуванням маршрутів і часу подачі, потім персоналізація пропозицій.

Так перебалансування запускають, не чекаючи повного охоплення телематикою: охоплення зростає разом із точністю моделі, а не блокує старт.

Технічні сумніви: точність, інтеграції, супровід

Перед стартом замовники ставлять ті самі запитання: якої точності чекати, як рішення стикується із системою бронювання і хто відповідає за модель через пів року після запуску. Відповідаємо по суті, без загальних слів.

Як прогноз стикується із системою бронювання?

Модель не замінює систему бронювання й не пише в неї напряму: вона читає знеособлені події оренди — старти, повернення, скасування — і віддає рекомендації щодо перебалансування через програмний інтерфейс.

Диспетчер бачить їх на своєму робочому місці, звичні сценарії бронювання не змінюються. Якщо прогноз недоступний, система продовжує працювати як раніше.

Хто супроводжує модель після запуску?

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

Як часто потрібне перенавчання?

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

Обговоримо задачу: вимоги до прогнозу та план робіт

Щоб оцінка обсягу робіт спиралася на факти, а не на припущення, нам потрібен зріз вашої поточної ситуації щодо флоту. Нічого екзотичного не знадобиться — як правило, усе це вже є в команди, яка веде каршеринг, достатньо вивантажити й передати.

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

У відповідь повернемо постановку задачі прогнозу з горизонтом і цільовим показником, оцінку обсягу робіт за етапами, план впровадження з контрольними точками та перелік того, що знадобиться з вашого боку.

Якщо даних мало або вони неповні, скажемо одразу й запропонуємо, як зібрати мінімальний набір для першої версії.

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