Прогнозування пасажиропотоку: де ламається розклад
Прогноз пасажиропотоку майже завжди розходиться з фактичною посадкою, і річ не в якості моделі, а в тому, на яких даних вона навчається.
Середній попит на маршруті, порахований за місяць, згладжує пікове навантаження настільки, що в ранкову годину пік розрахунок виявляється нижчим за реальну посадку на чверть.
Далі це перетворюється на дві крайнощі: або транспорт вирушає напівпорожнім у міжпік, або на зупинці залишаються люди.
Нерівномірність попиту за днями ламає усереднення найсильніше. Понеділок і п’ятниця поводяться як різні маршрути: роз’їзд за навчальними змінами, зсунутий робочий графік, сезонний спад у відпустках, разові події на кшталт стадіону або ярмарку.
Одна й та сама година в різні дні дає розбіжність у рази, а модель, навчена на тижневому середньому, цієї різниці просто не бачить.
Друга причина — неповні дані про поїздки. Валідатори втрачають частину записів у години перевантаження, частина карток залишається неідентифікованою, входи й виходи не завжди зіставляються в пару, а на маршрутах з оплатою у водія дані просто не доїжджають до сховища.
Якщо рахувати посадку за такими записами, реальний потік систематично занижується — і прогноз упевнено відтворює цю помилку.
Третя — ручні правки в розкладі. Диспетчер підлаштовує графік під учорашній збій: знімає рейс, розтягує інтервал, переносить вихід.
Правки живуть в окремому файлі, назад у розрахунок не повертаються, і в наступний цикл система знову рахує за вихідним планом, а не за тим, що дійсно виконувалося. Виникає петля: модель навчається на спотворених даних, прогноз відходить від факту ще далі, правок стає більше.
Розбираємо, як це закривається.
Ефект від моделі: менше порожніх рейсів і зривів графіка
Модель прогнозує посадку на кожну годину доби окремо за маршрутом, напрямком і зупинкою — сітка виходить нерівною, як і реальний попит.
Розклад і випуск рухомого складу планують від прогнозу, а не від середніх значень за минулий період, які згладжують і ранковий пік, і провал між рейсами.
Точність розрахунку за годинами
Прогноз на годинних інтервалах звіряють із фактичними даними валідаторів і датчиків, тому розбіжність видно за кожним рейсом, а не лише за добою. На сталих будніх днях відхилення тримається в межах 8–12%, а за піковими годинами — нижче, ніж у моделі, навченої на денних агрегатах. Це дозволяє довіряти прогнозу під час перестановки виходів.
Випуск транспорту під попит
Кількість виходів на маршрут прив’язують до очікуваного завантаження: де прогноз показує зростання, додають рейси й переходять на менший інтервал, де спад — знімають зайві. Завантаження маршрутної мережі вирівнюється, а переповнення на окремих напрямках перестає бути постійним.
Скорочення порожніх рейсів
Окремо контролюють рейси, де посадка не виправдовує випуск. Їхня частка в загальному обсязі помітно падає: частину рейсів переносять у часі, частину скорочують, частину переводять на меншу місткість. Це найшвидший ефект від моделі.
Планування ремонтів і резервів
Прогноз на кілька тижнів уперед дає вікна спаду, куди ставлять планове обслуговування без шкоди для пасажирів. Під пікові дні заздалегідь резервують машини й водіїв, а дані про розклади зводять із GTFS-вивантаженнями перевізника, щоб прогноз рахувався за актуальною мережею.
Формати прогнозування пасажиропотоку: пакетний, потоковий, гібрид
Режим розрахунку обирають не за «потужністю моделі», а за горизонтом розрахунку й частотою оновлення моделі.
Пакетний перерахунок проганяє модель повністю за розкладом, потокова модель у реальному часі оновлює оцінку за кожною подією, гібридна схема розрахунку поєднує обидва контури: базова крива рахується пакетно, онлайн-корекція ловить відхилення в межах зміни.
До впровадження фіксуємо два параметри: наскільки далеко вперед потрібен прогноз і як швидко він має оновлюватися.
Для планування випуску рухомого складу на добу достатньо нічного перерахунку за накопиченими даними; для управління посадкою на платформі потрібна реакція в межах хвилин, інакше прогноз втрачає сенс на момент рішення.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Пакетний перерахунок | Сталий потік даних із валідаторів і турнікетів, прогноз на зміну, добу, тиждень | Затримка між подією та перерахунком; різкі збої — закриття ділянки, скасування рейсів — потрапляють у прогноз із запізненням |
| Потокова модель у реальному часі | Потрібна реакція в межах зміни: скупчення, запізнення, разові піки | Чутлива до пропусків у потоці даних: збій датчика або втрата пакетів спотворюють оцінку, потрібен контроль якості на вході |
| Гібридна схема розрахунку | Змішані задачі — розклад уперед і оперативне коригування на тих самих даних | Складніша в налаштуванні: узгодження горизонту розрахунку за контурами, дисципліна версіонування моделі й логування правок |
Гібридна схема закриває більшість маршрутних мереж, але потребує звірки обох контурів за єдиними метриками помилки: якщо базова крива й онлайн-корекція розходяться, прогноз стає суперечливим.
Обмеження знімаються не зміною варіанта, а контролем вхідних даних і зрозумілим регламентом перезбирання моделі — обговоримо, яка схема ляже на ваш парк.
Впровадження: від аудиту даних до передачі моделі в експлуатацію
Прогнозування пасажиропотоку ламається не на моделі, а на даних. Квиткові транзакції, валідатори в салоні, треки рухомого складу й файли розкладу живуть у різних системах, розходяться за часом і за ключами маршруту, а частина поїздок не фіксується взагалі.
Поки це не зведено в одну картину, будь-яка цифра на виході виглядає правдоподібно, але не перевіряється.
- Аудит даних про поїздки. Розбираємо джерела за минулі періоди: повнота за днями, дублі, провали під час обривів зв’язку, зсуви часових поясів, аномалії свят і ремонтів. На виході — перелік придатних ознак і список прогалин, які закриваються до навчання.
- Схема потоків даних. Фіксуємо, звідки і з якою частотою надходять транзакції та телеметрія, де вони очищуються й агрегуються, як зберігається історія. Схема позначає точки відмови й власника кожного джерела.
- Налаштування моделі під маршрут. Враховуємо інтервал руху, тип дня, сезонність, канікули, погоду й міські події. Налаштування йде за напрямками, а не однією усередненою кривою на всю мережу.
- Перевірка на історичних періодах. Навчання й контроль розділяємо за часом, інакше майбутнє підказує відповідь. Дивимося помилку на горизонті доби й тижня — окремо на пікових годинах і на збоях розкладу.
- Передача моделі в експлуатацію. Розрахунок розгортаємо в контурі замовника, прив’язуємо до регламенту оновлень, вмикаємо оповіщення про падіння точності й дрейф вхідних даних.
- Регламент супроводу. Передаємо команді замовника порядок перенавчання після зміни маршрутної мережі та розбір розбіжностей прогнозу з фактом.
Так прогноз перестає бути експериментом і стає сервісом, який команда замовника веде сама.
Що залишається у замовника: конфігурації, схеми, регламенти
Модель прогнозування пасажиропотоку залишається у вашому контурі, і разом із нею — комплект матеріалів, за якими її можна супроводжувати, розвивати й передавати новим інженерам без нашої участі.
Комплект розрахований на дві аудиторії: ІТ-службу й аналітиків, які працюють із даними та інфраструктурою, і диспетчерів, які бачать результат в інтерфейсі.
- Документація з моделі — які ознаки беруть участь у розрахунку, як задається горизонт прогнозу, що означає кожен вихідний показник і за якими даними модель вважається придатною до роботи.
- Регламент оновлення — періодичність перенавчання, перевірка точності на відкладеному періоді, умови відкату на попередню версію, якщо якість прогнозу просіла.
- Схеми інтеграції з обліковими системами — звідки надходять дані про рейси й валідації, у якому вигляді прогноз повертається в диспетчерську систему й у канали інформування пасажирів.
- Правила доступу до даних — ролі та розмежування прав, порядок вивантажень, окремий знеособлений контур для тестових прогонів і розборів.
- Інструкції для диспетчерів — як читати прогноз та його інтервал, що робити при розбіжності факту з розрахунком, як зафіксувати інцидент і куди передати.
- Журнал версій і прогонів — що змінювали, на якому періоді перевіряли, який результат отримали і чим обґрунтовано вибір робочої версії.
- Чек-лист приймання і планових робіт — точки контролю якості, пороги спрацювання і порядок оновлення без зупинки сервісу.
Кейс: як зросла точність і скоротилися порожні рейси
Проєкт — для міського оператора автобусних перевезень: кілька десятків маршрутів, розклад на день диспетчери збирали вручну за середніми значеннями за минулий місяць. На розворотах, у канікули й у дні міських подій розрахунок розходився з фактичною посадкою особливо сильно.
Що показав замір до впровадження
На пікових маршрутах розбіжність із фактом сягала 20-25%: уранці випускали зайві машини в спальних районах, на пересадочних вузлах не вистачало місткості.
Частка скасованих рейсів трималася близько 6%, а підготовка графіка займала п’ять робочих днів — правки за погодою й подіями в нього вже не потрапляли.
Зібрали єдиний конвеєр даних: валідатори, треки, календар, погода, міські події. Прогноз рахує ансамбль моделей на годинних і добових інтервалах, окремо для буднів, вихідних і канікул, а якість кожної версії перевіряємо на відкладеному періоді та еталонних тижнях минулих сезонів.
Розбіжність на контрольних маршрутах знизилася до 7-9%, скасування — до 2%, порожні рейси в міжпіковий час скоротилися майже втричі. Графік збирається за 3-4 години й перераховується при зміні погоди або закритті ділянок.
Разом із замовником передали в експлуатацію моделі, конвеєр і правила перерахунку: налаштували моніторинг точності за кожним маршрутом і оповіщення про дрейф даних, регламент перенавчання й навчання диспетчерів. Далі — щомісячний розбір метрик і щоквартальна перевірка повноти даних.
Що робити, якщо облік за валідаторами вже ведеться своїми силами
Якщо облік поїздок за валідаторами вже працює, переробляти його не потрібно. Прогноз будується поверх ваших даних: система читає ті самі події, що й квиткова система, і не втручається в транзакції.
Достатньо домовитися про формат вивантаження й періодичність — раз на добу або частіше, залежно від потрібного горизонту прогнозу.
Перший крок — імпорт історичних даних. Потрібен ряд не коротший за пів року, щоб алгоритм побачив сезонність: будні й вихідні, канікули, ремонти й перекриття.
Записи беремо як є, разом із пропусками й збоями обладнання — аномалії позначаємо й залишаємо, вони корисні як сигнал про стан парку.
Далі — звірка довідників маршрутів. Коди маршрутів, зупинок і рейсів у кожного перевізника свої, і без зведення до спільного довідника прогноз не зійдеться з реальністю.
Зіставляємо за сталими ідентифікаторами, а розбіжності — дублі, перейменування, сезонні схеми — виносимо у звіт і розбираємо з вашим адміністратором системи.
Розширюємо охоплення поступово: спочатку один парк або маршрутна мережа з найчистішими даними, звірка прогнозу з фактом на закритому періоді, потім наступна ділянка.
Ваш облік продовжує працювати як працював: інтеграція з наявними валідаторами йде лише на читання, а шар прогнозування пасажиропотоку надбудовується зверху.
Від вас потрібні доступ на читання до вивантажень, контакт адміністратора системи й опис довідників — решту закриваємо самі.
Сумніви щодо даних, точності та супроводу моделі
Неповні дані про посадку — робоча норма, а не збій: частина валідаторів не віддає записи, лічильники на дверях втрачають інтервали.
На вході стоять перевірки повноти й зв’язності, прогалини закриваємо оцінкою за сусідніми зупинками й рейсами того самого профілю, а не нулем; при ненадійному відновленні прогноз іде інтервалом із позначкою про низьку впевненість.
Свята, масові події та збої виносимо в окремий календар ознак: тип дня, погода, перекриття, історичні аномалії. У святковий день модель поводиться інакше, ніж у звичайну суботу, а сезонна зміна розкладу оновлює довідник маршрутів.
Маршрути змінюються за сезонами — модель доведеться перенавчати заново?
Ні. Профіль маршруту зберігається окремо від ваг моделі: зміна траси або сезонного розкладу оновлює довідник, і прогноз будується за новими зупинками без повного перенавчання. Перенавчання запускається за регламентом — за календарем сезонності або при помітному зсуві точності.
Хто супроводжує модель після запуску?
Моніторинг порівнює прогноз із фактом за кожним маршрутом, повідомлення надходить при систематичній розбіжності. Передаємо регламент оновлення й документацію з даних — ваша команда може вести модель сама, або супровід беремо на себе.
Наскільки пояснюваними є рекомендації?
До прогнозу додається внесок факторів: скільки дали день тижня, скільки — погода, скільки — історія зупинки. Логіку перевіряють до випуску на лінію, а не довіряють чорній скриньці.
Обговоримо задачу: підберемо режим розрахунку під ваш парк
Починаємо з розбору поточних даних: які архіви пасажиропотоку вже накопичені, з якою частотою вони знімаються, чи є прив’язка до маршрутів, зупинок і календаря подій.
Від цього залежить підбір режиму розрахунку — короткостроковий прогноз на зміну й середньостроковий на тиждень будуються на різних наборах ознак і по-різному перенавчаються при зміні маршрутної мережі.
Що уточнюємо на старті й у якому вигляді повернемося:
- джерела даних та їхня придатність — турнікети, валідатори, дані про випуск на лінію, зовнішні календарі;
- горизонт і крок прогнозу — на скільки годин або діб уперед потрібен результат;
- перелік маршрутів і вузлів, де помилка прогнозу критична для розкладу;
- вимоги до оновлення моделі при сезонних зсувах і введенні нових зупинок;
- сценарії використання — планування випуску, коригування інтервалів, оповіщення пасажирів;
- обмеження щодо інфраструктури й режиму доступу до ваших систем;
- критерії приймання — на якій частці контрольних періодів прогноз має вкладатися в допустиме відхилення.
По підсумках розбору надсилаємо план впровадження за етапами з оцінкою обсягу робіт: що робимо на історичних даних, як перевіряємо якість на відкладених періодах, як виводимо прогноз у ваш контур і хто відповідає за супровід після запуску.
Опишіть задачу розрахунку — маршрутну мережу, доступні дані й горизонт прогнозу. Повернемося з оцінкою та планом впровадження.
