🚌 Прогнозатор Маршрутів і Часу Прибуття Транспорту
Автобуси рухаються реальною мережею маршрутів, поки алгоритм Дейкстри обчислює найкоротші шляхи, а жива модель прогнозує час прибуття порівняно з фактичним — спостерігайте, як похибка прогнозу зменшується в міру наближення автобусів.
Про Прогнозатор Маршрутів і Часу Прибуття Транспорту
Щоразу, коли транспортний застосунок повідомляє, що автобус «прибуде за 4 хвилини», за лаштунками одночасно працюють дві зовсім різні галузі інформатики. Перша — це пошук найкоротшого шляху: маючи мережу зупинок і часи в дорозі, знайти найшвидший маршрут з точки А в точку Б. Друга — це прогнозування прибуття в реальному часі: виходячи з того, як насправді поводився трафік останнім часом, оцінити, скільки часу реально займе наступний відрізок поїздки — адже надрукований розклад є лише початковим припущенням. Ця симуляція реалізує обидва підходи по-справжньому, на мережі маршрутів із 16 зупинками.
Клацніть на будь-які дві зупинки, щоб запустити справжній пошук найкоротшого шляху за алгоритмом Дейкстри між ними: спостерігайте, як фронт «завершених» зупинок розширюється назовні, а фінальний маршрут підсвічується, щойно його знайдено. Тим часом до чотирьох автобусів безперервно курсують фіксованими маршрутами. Кожне ребро мережі має випадково коливний коефіцієнт трафіку, а жива модель експоненційно зваженого ковзного середнього вивчає поточний час у дорозі для кожного ребра з кожного автобуса, що ним проїжджає — тож прогнозований час прибуття адаптується до умов, а не слідує фіксованому розкладу. Живий графік відстежує, наскільки прогнози відхиляються від реальності зі зміною волатильності трафіку.
Часті запитання
Як саме алгоритм Дейкстри обчислює найкоротший маршрут?
Алгоритм Дейкстри підтримує поточну найкращу відому відстань до кожної зупинки, починаючи з 0 для джерела та нескінченності для всіх інших. На кожному кроці він обирає невідвідану зупинку з найменшою відомою відстанню, позначає її як завершену (settled) і релаксує кожне ребро, що з неї виходить: якщо шлях через завершену зупинку дає коротший шлях до сусіда, ніж поточний найкращий результат сусіда, цей найкращий результат і його попередник оновлюються. Оскільки зупинки завжди завершуються в порядку зростання відстані, після завершення зупинки її відстань уже ніколи не може покращитися, і алгоритм зупиняється, щойно завершено зупинку призначення. Проходження вказівників попередників у зворотному напрямку від зупинки призначення відновлює фактичний найкоротший шлях.
Чому реальні транспортні системи досі використовують маршрутизацію у стилі Дейкстри у великому масштабі?
Алгоритм Дейкстри виконується за час O((V + E) log V) з бінарною або фібоначчієвою купою, що достатньо швидко для дорожніх і транспортних графів із мільйонами ребер у поєднанні з прийомами попередньої обробки, такими як ієрархії скорочень, A* з евристикою орієнтирів або hub labelling. Ці варіанти заздалегідь обчислюють «скорочення», тож запит у реальному часі має торкнутися лише незначної частини графа. Основна гарантія — що алгоритм знаходить справжній шлях мінімальної вартості за точних вагів ребер — і робить його основою для рушіїв маршрутизації, навіть попри те, що самі ваги (у цій симуляції — час у дорозі з урахуванням поточного трафіку) є тим, над чим сучасні системи витрачають найбільше інженерних зусиль для вдосконалення.
Що таке модель прогнозування часу прибуття на основі експоненційно зваженого ковзного середнього і чому вона краща за статичний розклад?
Статичний розклад передбачає, що кожна поїздка вздовж ділянки триває однакову заплановану тривалість незалежно від умов. Натомість експоненційно зважене ковзне середнє (EWMA) підтримує одну поточну оцінку для кожного ребра та оновлює її щоразу, коли автобус фактично проїжджає цим ребром: нова_оцінка = α · спостережений_час + (1 − α) · стара_оцінка. Оскільки α перебуває між 0 і 1, останні спостереження важать більше за старі, тож оцінка відстежує поточні умови — уповільнення через затори поглинається впродовж кількох проїздів автобуса — водночас згладжуючи одноразовий шум від однієї надто швидкої чи повільної поїздки. У цій симуляції використовується α = 0,3 — типовий практичний компроміс між чутливістю та стабільністю.
Чому похибка прогнозу зростає, коли підвищується волатильність трафіку?
Модель EWMA може реагувати лише після того, як спостерігає завершену поїздку, тож вона за своєю природою є запізнілим (лагуючим) показником: вона описує нещодавні умови, а не ті, які автобус відчує під час руху. Коли повзунок волатильності збільшує різкість коливань коефіцієнтів трафіку на ребрах між оновленнями, розрив між «тим, що модель дізналась востаннє» і «тим, що відбувається просто зараз» зростає, тож середня абсолютна похибка між прогнозованим і фактичним часом прибуття збільшується. Зменшіть волатильність — і оцінка моделі зійдеться до справжнього поточного часу в дорозі протягом кількох проїздів автобуса, а ряд похибок помітно вирівняється.
Чому найкоротший шлях змінюється, хоча сама карта ніколи не рухається?
Ця симуляція запускає Дейкстру, використовуючи для кожного ребра живий прогнозований EWMA час у дорозі, а не фіксовану фізичну відстань, тож запит для тих самих двох зупинок може повернути інший маршрут, щойно умови трафіку змінять вивчені ваги настільки, що раніше повільніший шлях стане швидшим. Це відображає те, як реальні навігаційні застосунки безперервно перераховують маршрути: топологія графа статична, але вартості ребер — рухома ціль, тож пошук найкоротшого шляху доводиться перезапускати (або оновлювати поступово) щоразу, коли ці вартості суттєво змінюються.
Чим реальні системи на кшталт Google Maps чи транспортних застосунків відрізняються від цієї спрощеної моделі?
Промислові системи отримують GPS-сигнали від тисяч транспортних засобів, історичні розподіли часу в дорозі за часом доби й днем тижня, живі стрічки інцидентів і перекриттів, а також часто модель машинного навчання (градієнтний бустинг або графову нейронну мережу), а не одну EWMA-оцінку на ребро. Вони також прокладають маршрути графами з мільйонами вузлів, використовуючи заздалегідь обчислені скорочення, щоб запити поверталися за мілісекунди, і безперервно переоптимізовуються, а не лише коли користувач про це просить. Основні ідеї, продемонстровані тут — пошук найкоротшого шляху зваженим графом і адаптивна оцінка, що навчається з нещодавніх спостережень, — ті самі будівельні блоки, лише в значно більшому масштабі з набагато багатшим сигналом.
Що означає анімований «фронт» під час роботи Дейкстри?
Фронт — це зростаюча множина зупинок, які алгоритм остаточно завершив, показана тут у порядку їх завершення. Оскільки Дейкстра завжди завершує наступну найближчу з решти зупинок, фронт розширюється назовні від початкової зупинки приблизно як хвиля, хоча його точна форма залежить від поточних вагів ребер, а не від суто геометричної відстані — зупинка, що близька на карті, може завершитися пізно, якщо дороги до неї зараз повільні. Спостереження за порядком розширення — це пряма візуалізація того, скільки зупинок алгоритму фактично довелося розглянути, перш ніж він зміг гарантувати, що найкоротший шлях до зупинки призначення знайдено.
Чому різні автобусні маршрути мають різну точність прогнозу?
Оцінка EWMA для кожного ребра покращується лише тоді, коли автобуси проїжджають ним, тож ребро, яким часто проїжджають кілька маршрутів, що перетинаються, накопичує спостереження — а отже, точну й актуальну оцінку — значно швидше, ніж ребро, яке торкається лише один маршрут. Автобус, що курсує завантаженими спільними коридорами, зазвичай показуватиме нижчу середню абсолютну похибку, ніж той, що їздить тихішою частиною мережі — так само як і в реальних системах, де високочастотні коридори отримують кращі прогнози прибуття в реальному часі, ніж ті, що обслуговуються рідко, просто тому що там більше свіжих даних для навчання.
Справжній пошук Дейкстри з мінімальною відстанню виконується на графі з 16 зупинками та 28 ребрами з живими вагами ребер; чотири автобуси курсують мережею, поки модель EWMA вивчає час у дорозі для кожного ребра з кожного проїзду, а графік відстежує похибку прогнозу відносно факту в часі.
3D · рушій Three.js / WebGL · ціль 60 FPS · працює повністю на стороні клієнта, без встановлення