Прогнозирование пассажиропотока: где ломается расписание
Прогноз пассажиропотока почти всегда расходится с фактической посадкой, и дело не в качестве модели, а в том, на каких данных она учится. Средний спрос по маршруту, посчитанный за месяц, сглаживает пиковую нагрузку настолько, что в утренний час пик расчёт оказывается ниже реальной посадки на четверть. Дальше это превращается в две крайности: либо транспорт уходит полупустым в межпик, либо на остановке остаются люди.
Неравномерность спроса по дням ломает усреднение сильнее всего. Понедельник и пятница ведут себя как разные маршруты: разъезд по учебным сменам, сдвинутый рабочий график, сезонный спад в отпусках, разовые события вроде стадиона или ярмарки. Один и тот же час в разные дни даёт расхождение в разы, а модель, обученная на недельном среднем, эту разницу просто не видит.
Вторая причина — неполные данные о поездках. Валидаторы теряют часть записей в часы перегрузки, часть карт остаётся неопознанной, входы и выходы не всегда сопоставляются в пару, а на маршрутах с оплатой у водителя данные просто не доезжают до хранилища. Если считать посадку по таким записям, реальный поток систематически занижается — и прогноз уверенно воспроизводит эту ошибку.
Третья — ручные правки в расписании. Диспетчер подстраивает график под вчерашний сбой: снимает рейс, растягивает интервал, переносит выход. Правки живут в отдельном файле, обратно в расчёт не возвращаются, и в следующий цикл система снова считает по исходному плану, а не по тому, что действительно выполнялось. Возникает петля: модель учится на искажённых данных, прогноз уходит от факта ещё дальше, правок становится больше.
Разбираем, как это закрывается.
Эффект от модели: меньше пустых рейсов и срывов графика
Модель прогнозирует посадку на каждый час суток отдельно по маршруту, направлению и остановке — сетка получается неровной, как и реальный спрос. Расписание и выпуск подвижного состава планируют от прогноза, а не от средних значений за прошлый период, которые сглаживают и утренний пик, и провал между рейсами.
Точность расчёта по часам
Прогноз на часовых интервалах сверяют с фактическими данными валидаторов и датчиков, поэтому расхождение видно по каждому рейсу, а не только по суткам. На устойчивых будних днях отклонение держится в пределах 8–12%, а по пиковым часам — ниже, чем у модели, обученной на дневных агрегатах. Это позволяет доверять прогнозу при перестановке выходов.
Выпуск транспорта под спрос
Число выходов на маршрут привязывают к ожидаемой загрузке: где прогноз показывает рост, добавляют рейсы и переходят на меньший интервал, где спад — снимают лишние. Загрузка маршрутной сети выравнивается, а переполнение на отдельных направлениях перестаёт быть постоянным.
Сокращение пустых рейсов
Отдельно контролируют рейсы, где посадка не оправдывает выпуск. Их доля в общем объёме заметно падает: часть рейсов переносят по времени, часть сокращают, часть переводят на меньшую вместимость. Это самый быстрый эффект от модели.
Планирование ремонтов и резервов
Прогноз на несколько недель вперёд даёт окна спада, куда ставят плановое обслуживание без ущерба для пассажиров. Под пиковые дни заранее резервируют машины и водителей, а данные о расписаниях сводят с GTFS-выгрузками перевозчика, чтобы прогноз считался по актуальной сети.
Форматы прогнозирования пассажиропотока: пакетный, потоковый, гибрид
Режим расчёта выбирают не по «мощности модели», а по горизонту расчёта и частоте обновления модели. Пакетный пересчёт прогоняет модель целиком по расписанию, потоковая модель в реальном времени обновляет оценку по каждому событию, гибридная схема расчёта совмещает оба контура: базовая кривая считается пакетно, онлайн-коррекция ловит отклонения в пределах смены.
До внедрения фиксируем два параметра: насколько далеко вперёд нужен прогноз и как быстро он должен обновляться. Для планирования выпуска подвижного состава на сутки хватает ночного пересчёта по накопленным данным; для управления посадкой на платформе нужна реакция в пределах минут, иначе прогноз теряет смысл к моменту решения.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Пакетный пересчёт | Устойчивый поток данных из валидаторов и турникетов, прогноз на смену, сутки, неделю | Задержка между событием и пересчётом; резкие сбои — закрытие участка, отмена рейсов — попадают в прогноз с опозданием |
| Потоковая модель в реальном времени | Нужна реакция внутри смены: скопления, опоздания, разовые пики | Чувствительна к пропускам в потоке данных: сбой датчика или потеря пакетов искажают оценку, требуется контроль качества на входе |
| Гибридная схема расчёта | Смешанные задачи — расписание вперёд и оперативная корректировка на тех же данных | Сложнее в настройке: согласование горизонта расчёта по контурам, дисциплина версионирования модели и логирование правок |
Гибридная схема закрывает большинство маршрутных сетей, но требует сверки обоих контуров по единым метрикам ошибки: если базовая кривая и онлайн-коррекция расходятся, прогноз становится противоречивым. Ограничения снимаются не сменой варианта, а контролем входных данных и понятным регламентом пересборки модели — обсудим, какая схема ляжет на ваш парк.
Внедрение: от аудита данных до передачи модели в эксплуатацию
Прогнозирование пассажиропотока ломается не на модели, а на данных. Билетные транзакции, валидаторы в салоне, треки подвижного состава и файлы расписания живут в разных системах, расходятся по времени и по ключам маршрута, а часть поездок не фиксируется вовсе. Пока это не сведено в одну картину, любая цифра на выходе выглядит правдоподобно, но не проверяется.
- Аудит данных о поездках. Разбираем источники за прошлые периоды: полнота по дням, дубли, провалы при обрывах связи, сдвиги часовых поясов, аномалии праздников и ремонтов. На выходе — перечень пригодных признаков и список пробелов, которые закрываются до обучения.
- Схема потоков данных. Фиксируем, откуда и с какой частотой приходят транзакции и телеметрия, где они очищаются и агрегируются, как хранится история. Схема отмечает точки отказа и владельца каждого источника.
- Настройка модели под маршрут. Учитываем интервал движения, тип дня, сезонность, каникулы, погоду и городские события. Настройка идёт по направлениям, а не одной усреднённой кривой на всю сеть.
- Проверка на исторических периодах. Обучение и контроль разделяем по времени, иначе будущее подсказывает ответ. Смотрим ошибку на горизонте суток и недели — отдельно на пиковых часах и на сбоях расписания.
- Передача модели в эксплуатацию. Расчёт разворачиваем в контуре заказчика, привязываем к регламенту обновлений, включаем оповещения о падении точности и дрейфе входных данных.
- Регламент сопровождения. Передаём команде заказчика порядок переобучения после изменения маршрутной сети и разбор расхождений прогноза с фактом.
Так прогноз перестаёт быть экспериментом и становится сервисом, который команда заказчика ведёт сама.
Что остаётся у заказчика: конфигурации, схемы, регламенты
Модель прогнозирования пассажиропотока остаётся в вашем контуре, и вместе с ней — комплект материалов, по которым её можно сопровождать, развивать и передавать новым инженерам без нашего участия. Комплект рассчитан на две аудитории: ИТ-службу и аналитиков, которые работают с данными и инфраструктурой, и диспетчеров, которые видят результат в интерфейсе.
- Документация по модели — какие признаки участвуют в расчёте, как задаётся горизонт прогноза, что означает каждый выходной показатель и по каким данным модель считается пригодной к работе.
- Регламент обновления — периодичность переобучения, проверка точности на отложенном периоде, условия отката на предыдущую версию, если качество прогноза просело.
- Схемы интеграции с учётными системами — откуда приходят данные о рейсах и валидациях, в каком виде прогноз возвращается в диспетчерскую систему и в каналы информирования пассажиров.
- Правила доступа к данным — роли и разграничение прав, порядок выгрузок, отдельный обезличенный контур для тестовых прогонов и разборов.
- Инструкции для диспетчеров — как читать прогноз и его интервал, что делать при расхождении факта с расчётом, как зафиксировать инцидент и куда передать.
- Журнал версий и прогонов — что меняли, на каком периоде проверяли, какой результат получили и чем обоснован выбор рабочей версии.
- Чек-лист приёмки и плановых работ — точки контроля качества, пороги срабатывания и порядок обновления без остановки сервиса.
Кейс: как выросла точность и сократились пустые рейсы
Проект — для городского оператора автобусных перевозок: несколько десятков маршрутов, расписание на день диспетчеры собирали вручную по средним значениям за прошлый месяц. На разворотах, в каникулы и в дни городских событий расчёт расходился с фактической посадкой особенно сильно.
Что показал замер до внедрения
На пиковых маршрутах расхождение с фактом доходило до 20-25%: утром выпускали лишние машины в спальных районах, на пересадочных узлах не хватало вместимости. Доля отменённых рейсов держалась около 6%, а подготовка графика занимала пять рабочих дней — правки по погоде и событиям в него уже не попадали.
Собрали единый конвейер данных: валидаторы, треки, календарь, погода, городские события. Прогноз считает ансамбль моделей на часовых и суточных интервалах, отдельно для будней, выходных и каникул, а качество каждой версии проверяем на отложенном периоде и эталонных неделях прошлых сезонов.
Расхождение на контрольных маршрутах снизилось до 7-9%, отмены — до 2%, пустые рейсы в межпиковое время сократились почти втрое. График собирается за 3-4 часа и пересчитывается при смене погоды или закрытии участков.
Вместе с заказчиком передали в эксплуатацию модели, конвейер и правила пересчёта: настроили мониторинг точности по каждому маршруту и оповещение о дрейфе данных, регламент переобучения и обучение диспетчеров. Дальше — ежемесячный разбор метрик и ежеквартальная проверка полноты данных.
Что делать, если учёт по валидаторам уже ведётся своими силами
Если учёт поездок по валидаторам уже работает, переделывать его не нужно. Прогноз строится поверх ваших данных: система читает те же события, что и билетная система, и не вмешивается в транзакции. Достаточно договориться о формате выгрузки и периодичности — раз в сутки или чаще, в зависимости от нужного горизонта прогноза.
Первый шаг — импорт исторических данных. Нужен ряд не короче полугода, чтобы алгоритм увидел сезонность: будни и выходные, каникулы, ремонты и перекрытия. Записи берём как есть, вместе с пропусками и сбоями оборудования — аномалии помечаем и оставляем, они полезны как сигнал о состоянии парка.
Дальше — сверка справочников маршрутов. Коды маршрутов, остановок и рейсов у каждого перевозчика свои, и без сведения к общему справочнику прогноз не сойдётся с реальностью. Сопоставляем по устойчивым идентификаторам, а расхождения — дубли, переименования, сезонные схемы — выносим в отчёт и разбираем с вашим администратором системы.
Расширяем охват постепенно: сначала один парк или маршрутная сеть с наиболее чистыми данными, сверка прогноза с фактом на закрытом периоде, затем следующий участок. Ваш учёт продолжает работать как работал: интеграция с существующими валидаторами идёт только на чтение, а слой прогнозирования пассажиропотока надстраивается сверху.
От вас нужны доступ на чтение к выгрузкам, контакт администратора системы и описание справочников — остальное закрываем сами.
Сомнения по данным, точности и сопровождению модели
Неполные данные о посадке — рабочая норма, а не сбой: часть валидаторов не отдаёт записи, счётчики на дверях теряют интервалы. На входе стоят проверки полноты и связности, пробелы закрываем оценкой по соседним остановкам и рейсам того же профиля, а не нулём; при ненадёжном восстановлении прогноз идёт интервалом с пометкой о низкой уверенности.
Праздники, массовые события и сбои выносим в отдельный календарь признаков: тип дня, погода, перекрытия, исторические аномалии. В праздничный день модель ведёт себя иначе, чем в обычную субботу, а сезонная смена расписания обновляет справочник маршрутов.
Маршруты меняются по сезонам — модель придётся переобучать заново?
Нет. Профиль маршрута хранится отдельно от весов модели: смена трассы или сезонного расписания обновляет справочник, и прогноз строится по новым остановкам без полного переобучения. Переобучение запускается по регламенту — по календарю сезонности или при заметном сдвиге точности.
Кто сопровождает модель после запуска?
Мониторинг сравнивает прогноз с фактом по каждому маршруту, уведомление приходит при систематическом расхождении. Передаём регламент обновления и документацию по данным — ваша команда может вести модель сама, либо сопровождение берём на себя.
Насколько объяснимы рекомендации?
К прогнозу прикладывается вклад факторов: сколько дал день недели, сколько — погода, сколько — история остановки. Логику проверяют до выпуска на линию, а не доверяют чёрному ящику.
Обсудим задачу: подберём режим расчёта под ваш парк
Начинаем с разбора текущих данных: какие архивы пассажиропотока уже накоплены, с какой частотой они снимаются, есть ли привязка к маршрутам, остановкам и календарю событий. От этого зависит подбор режима расчёта — краткосрочный прогноз на смену и среднесрочный на неделю строятся на разных наборах признаков и по-разному переобучаются при изменении маршрутной сети.
Что уточняем на старте и в каком виде вернёмся:
- источники данных и их пригодность — турникеты, валидаторы, данные о выпуске на линию, внешние календари;
- горизонт и шаг прогноза — на сколько часов или суток вперёд нужен результат;
- перечень маршрутов и узлов, где ошибка прогноза критична для расписания;
- требования к обновлению модели при сезонных сдвигах и вводе новых остановок;
- сценарии использования — планирование выпуска, корректировка интервалов, оповещение пассажиров;
- ограничения по инфраструктуре и режиму доступа к вашим системам;
- критерии приёмки — на какой доле контрольных периодов прогноз должен укладываться в допустимое отклонение.
По итогам разбора присылаем план внедрения по этапам с оценкой объёма работ: что делаем на исторических данных, как проверяем качество на отложенных периодах, как выводим прогноз в ваш контур и кто отвечает за сопровождение после запуска.
Опишите задачу расчёта — маршрутную сеть, доступные данные и горизонт прогноза. Вернёмся с оценкой и планом внедрения.
