Прогнозування ДТП за допомогою ML: де ламаються моделі
ДТП — рідкісна подія, і це перше, що ламає постановку задачі. На ділянці фіксують одиниці пригод на рік, а частка аварійних поїздок — частки відсотка від загального потоку.
Модель, яка завжди відповідає «спокійно», вгадує у 95% випадків: метрика виглядає відмінно, а на виході сміття — такий прогноз не відрізняє небезпечне перехрестя від безпечного.
Друга пастка — витік ознак із майбутнього. У навчальну вибірку непомітно потрапляють поля, відомі лише після пригоди: час прибуття екіпажу, оформлений протокол, тяжкість травм.
На навчанні якість майже ідеальна, у роботі — випадкове вгадування, бо на момент прогнозу цих даних ще не існує.
Третя причина — зміщена та незбалансована вибірка. Аварії фіксують там, де стоять камери й чергує патруль, тому модель вчить щільність контролю, а не ризик.
Агрегація за кварталами та адміністративними районами добиває результат: осередки аварійності розмиваються, перехрестя з концентрацією ДТП ховається всередині великого полігону.
Ділянки ріжемо за геометрією доріг — межі беремо з OpenStreetMap — і рахуємо ризик на перехрестях і перегонах окремо.
Розбираємо, як це закривається: часова крос-валідація замість випадкової, балансування рідкісного класу, аудит ознак на доступність на момент прогнозу та прив’язка прогнозу до реальних осередків, а не до сітки.
Що змінюється після впровадження прогнозу аварійності
Після впровадження прогнозу аварійності робота з осередками перестає бути реактивною. Модель перераховує ризик за ділянками регулярно і видає список місць, де концентрація інцидентів зросте найближчими тижнями: інженери отримують не звіт про минуле, а чергу задач на профілактику.
Частка підтверджених осередків у цьому списку тримається на рівні, за якого більшість виїздів припадає на реально небезпечні точки.
Час реакції на інцидент скорочується: сигнал про аномалію надходить до диспетчерської в момент фіксації, а не після розбору зміни, тому на місце встигають до повтору ситуації на тому самому перехресті або з’їзді. Накопичене зниження аварійності дає саме швидкість закриття повторів, а не разовий виїзд.
Хибні спрацьовування відсікаємо порогом впевненості та перевіркою контексту — погода, час доби, дорожні роботи, профіль трафіку. Хибних викликів стає менше, чергова зміна перестає перевіряти шум, і довіра до системи зростає швидше, ніж формальна точність.
Ручний розбір записів замінюється готовою вибіркою епізодів із розміткою: аналітик перевіряє гіпотези, а не перегортає архів за зміну.
Час, що вивільнився, іде на планування ремонтів — прогноз за осередками прив’язується до сезонності та циклу робіт, тому розмітка, освітлення й покриття ставляться туди, де знімуть ризик. Ефект від кожного ремонту стає вимірюваним за тією самою ділянкою.
Варіанти побудови моделі прогнозу: пакетний, потоковий, гібридний
Вибір режиму визначається двома речами: звідки надходять дані та на який горизонт потрібно впливати.
Пакетний розрахунок перераховує матрицю ризиків за розкладом на історичному зрізі, потоковий прогноз оновлює оцінку в міру надходження телеметрії, гібридна схема поєднує обидва контури.
Різниця між ними — у частоті оновлення прогнозу та у вимогах до інфраструктури: чим коротше вікно реакції, тим більше даних має бути доступно постійно, а не на момент запуску.
Порівнюємо варіанти за складом джерел даних і за затримкою, яку допускає сам процес ухвалення рішення.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Пакетний розрахунок | Розрізнені джерела: історія пригод, метеоархів, паспорти доріг. Прогноз на добу й далі, планування маршрутів і ремонтів | Оцінка застаріває між запусками; різкий сплеск ризику видно із затримкою |
| Потоковий прогноз | Телеметрія з бортів і міських камер, реакція потрібна в межах зміни | Залежить від стабільності каналу; якщо дані зникають, оцінка деградує, потрібне резервне джерело |
| Гібридна схема | Базова модель ризику за розкладом плюс швидкий шар корекції за свіжими подіями | Дорожче в супроводі: два контури, узгодження ознак і спільна точка відмови на стику |
На практиці починають із пакетного контуру: він перевіряється на історії та не потребує постійного потоку.
Гібридна схема стає виправданою, коли з’являється стійкий канал телеметрії та вимога реагувати швидше за добу — тоді базова модель задає фон, а потоковий шар коригує її за фактом.
Перехід робимо так, щоб обидва контури можна було запускати незалежно: якщо потік даних зник, система залишається на пакетних оцінках, а не віддає порожній прогноз.
Етапи розробки системи прогнозу аварійності
Етапи вибудувані ітеративно: прогнозування ДТП спирається на перевірений результат попереднього кроку, а не на припущення про дані.
Починаємо з аудиту джерел і закінчуємо передачею системи в експлуатацію разом із командою замовника — на виході залишається робочий прогноз і люди, які розуміють, як його читати й оновлювати.
- Аудит даних. Зводимо історію ДТП і різких гальмувань, телеметрію транспорту, погодні ряди та дані про ремонти. Перевіряємо повноту, розбіжності координат, пропуски: інакше модель навчається на дефектах обліку.
- Схема ознак. Рахуємо ознаки на рівні ділянки та часового вікна: інтенсивність потоку, розкид швидкостей, частка різких гальмувань, видимість, стан покриття, тип розв’язки. Кожна ознака має бути доступною на момент прогнозу, а не лише в історичних вивантаженнях.
- Навчання та валідація моделі. Валідуємо за часом: навчаємо на минулих періодах, перевіряємо на наступних. Дивимося повноту за заданої точності, частку хибних спрацьовувань, стабільність за сезонами.
- Пілотна ділянка. Запускаємо прогноз на обмеженому наборі ділянок із різним характером потоку, зіставляємо з фактом і налаштовуємо пороги спрацьовування.
- Перевірка на історичних зрізах. Проганяємо модель за минулими сезонами: скільки подій зловили б заздалегідь і скільки сигналів виявилися хибними.
- Передача в експлуатацію. Розгортаємо сервіс, налаштовуємо моніторинг якості та регламент перенавчання, навчаємо команду читати прогноз і оновлювати дані.
Склад постачання: артефакти моделей, схеми даних, регламенти
Ми передаємо не набір файлів, а робочу систему: у кожної позиції є власник на боці замовника та документ, за яким її можна перевірити й відтворити. Нижче — те, що залишається у вас після здачі.
- Навчені артефакти моделі. Ваги, кроки попередньої обробки та пороги спрацьовування у вигляді, який розгортається на вашому контурі без нашої інфраструктури, плюс відтворюваний сценарій навчання.
- Опис ознак. За кожною: джерело, формула розрахунку, вікно агрегації, допустимий діапазон і поведінка за пропуску — щоб логіку не відновлювали за кодом.
- Схема потоків даних. Звідки надходять телеметрія, погода та дорожня обстановка, де лежать сирі й агреговані шари, хто і на яких правах їх читає.
- Регламент перенавчання. Тригери — календар, падіння якості, зміна парку або маршрутної мережі; порядок перевірки на відкладеній вибірці та умови, за яких версія в роботу не йде.
- Інструкція оператора. Як читати оцінку ризику, які пороги ведуть до повідомлення, як фіксувати хибні спрацьовування та передавати їх на донавчання.
- Журнал перевірок. Історія версій, метрики на кожній перевірці, хто і коли підтвердив випуск — з можливістю повернутися до попередньої версії.
Комплект розрахований на те, що супроводжувати систему далі буде ваша команда: усе, що робиться по ходу проєкту, оформлюється так, щоб це можна було передати й перевірити без нас. Опишіть задачу — повернемося з оцінкою та планом, у якому склад постачання зафіксовано заздалегідь.
Кейс: прогноз осередків ДТП на міській мережі — цифри до і після
До впровадження зведення за осередками ДТП збиралося раз на квартал: інженер вручну зводив вивантаження з різних відомств, адреси зіставлялися на око, частина записів губилася на дублях і одруках.
На момент передачі дорожникам список застарівав, а рішення про ремонт ухвалювалося за торішньою картиною. Модель ми починали не з алгоритму, а з розбору цих даних.
Осередки визначалися за Методикою класифікації осередків аварійності, щоб прогноз говорив мовою замовника. Окремо лагодили прив’язку: 18% записів не лягали на дорожній граф — з’їзди, розв’язки, мости та дворові проїзди описувалися адресою, а не ділянкою.
Дублі схлопували за просторово-часовим вікном, ознаки перезібрали на ділянку: інтенсивність, схема руху, освітлення, розмітка, історія ремонтів і сезонність. Без цього будь-який прогноз ловив би шум.
Після перезбирання прогноз перераховується щодобово, а не раз на квартал. Частка підтверджених осередків у першій двадцятці ділянок зросла з 31% до 69%, повнота виявлення осередків — з 62% до 88%, хибних спрацьовувань стало одне з восьми замість одного з трьох. Розбір, де саме модель помилилася, займає години, а не тижні.
Що пішло з класів відмов: «залипання» на історичних осередках — після ремонту або зміни схеми руху ділянка більше не тримається в топі; помилки прив’язки на багаторівневих розв’язках; сезонні провали, коли зимова аварійність недооцінювалася через літню статистику.
Залишковий ризик — нові схеми руху, за якими немає жодного запису: такі ділянки позначаємо як зону невизначеності й показуємо окремо.
Що робити, якщо вже розгорнуто систему відеоаналітики
Якщо відеоаналітика вже розгорнута, у більшості випадків контур не перезбирають, а надбудовують шаром прогнозу.
Ключове питання — чи відокремлює поточна система детекцію від зберігання: якщо події з камер пишуться з міткою часу, зоною кадру та ідентифікатором треку, вони напряму стають входом для моделі передбачення ДТП. Перебудовувати доводиться лише те, чого відео не дає, — динаміку траєкторій і зовнішні фактори.
Повторно використовуються камери та їх калібрування, готові детектори об’єктів, потік подій і історична розмітка — це економить місяці збору стартової вибірки.
Заново збирається ознаковий шар: швидкість і прискорення за треками, інтервали між учасниками, затори, зчеплення з погодою. Сюди ж підключається інтеграція з датчиками — фази світлофорів, метеостанції, дорожні контролери. Обмін моделями між контурами ведемо через ONNX, щоб не перенавчати те, що вже працює.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Доработка наявного контуру | Детектори та сховище подій уже віддають дані в загальну шину | Модель прогнозу потрапляє в той самий цикл релізів, вищий ризик регресій у відеоаналітиці |
| Окремий шар прогнозу над контуром | Потрібен горизонт у хвилини та власні метрики якості | Потребує синхронізації часу та наскрізного трасування подій між системами |
| Гібрид: спільний потік подій плюс прогноз-сервіс | Кілька майданчиків і різні постачальники камер | Дорожче в супроводі: дві схеми даних, два контури спостереження |
Шари системи за будь-якого шляху одні: збір і нормалізація подій, ознаки, модель, видача та звірка з фактичними пригодами. Розділення за шарами дає головне — шар прогнозу можна вимкнути або перенавчити, не зупиняючи відеоаналітику й не втрачаючи накопичену наявну інфраструктуру.
Технічні сумніви: дані, хибні спрацьовування, приватність
Заперечення щодо передбачення аварійних ситуацій майже завжди стосуються не вибору алгоритму, а даних і режиму експлуатації.
Розмітка надходить неповною: підтверджених випадків мало, частина інцидентів закривається без протоколу, а ознаки ділянки змінюються за сезоном — узимку одна геометрія дороги дає зовсім іншу динаміку, ніж улітку.
Тому якість даних ми перевіряємо до навчання: рахуємо частку пропущених міток, дивимося зсув розподілу між періодами, фіксуємо, за якими ознаками модель ухвалює рішення.
Нижче — розбір сумнівів, які найчастіше спливають на етапі оцінки: холодний старт, хибні тривоги, контроль перенавчання та робота з персональними даними.
Що робити, якщо розмітка неповна?
Навчаємося на слабких мітках: підтверджені інциденти як позитивний клас, решта — як фон із зниженою вагою. Додатково перевіряємо частку пропущених спрацьовувань на відкладеному періоді та калібруємо поріг так, щоб модель не видавала впевненість там, де даних не вистачає.
Як модель працює на холодному старті, поки немає власної історії?
Перші тижні система йде в тіньовому режимі: передбачення рахуються, але нікого не оповіщають. Спираємося на перенесення знань із схожих ділянок і фізичні ознаки — швидкість потоку, гальмівний шлях, щільність.
У міру накопичення підтверджених випадків вага перенесення знижується, модель переходить на власну статистику ділянки.
Як знижується кількість хибних спрацьовувань?
Поріг виставляємо не єдиним, а під ціну помилки: для небезпечного перехрестя краще пропустити менше, для спокійної ділянки — не турбувати служби марно.
Оповіщення розбираються черговим, розмітка зворотного зв’язку повертається в навчання, тому частка хибних тривог знижується від ітерації до ітерації.
Як ви контролюєте перенавчання моделі?
Валідація йде за часом, а не випадковим розбиттям: навчаємо на минулих періодах, перевіряємо на наступних. Так одразу видно, чи вивчила модель закономірність, чи запам’ятала конкретні інциденти.
Додатково стежимо за дрейфом вхідних ознак — за розбіжності з навчальним розподілом сигнал перенавчається.
Що з персональними даними?
На вході дані знеособлюються: ідентифікатори транспортних засобів і людей не потрапляють в ознаки. Модель працює з агрегатами за ділянкою та часовим вікном.
Доступ до сирих записів обмежений ролями, звернення логуються, термін зберігання задається політикою та дотримується автоматично, а не вручну.
Обговорімо задачу: які дані є і який прогноз потрібен
Щоб оцінка задачі була предметною, а не «на око», потрібен мінімальний набір ввідних: чим детальніші вихідні дані замовника, тим точніший склад робіт і строки пілоту. Надсилати все одразу не обов’язково — почнемо з того, що вже є, решту уточнимо на дзвінку.
- Вивантаження історичних подій: де і коли сталися ДТП та аварійні ситуації, чим кожен запис описано у вашій системі.
- Схему ділянок і маршрутів: геометрія доріг, перехрестя, прив’язка пригод до координат.
- Дані про потік і умови: інтенсивність руху, час доби, погода, сезонність, стан покриття.
- Перелік джерел: які датчики, камери або зовнішні сервіси вже віддають дані та з якою періодичністю.
- Обмеження щодо даних: вимоги до знеособлення, розмежування доступу та зберігання.
- Цільовий прогноз: горизонт передбачення (найближчі години або доба) та одиниця — ділянка, час, тип ризику.
- Точку вбудовування: хто і в якому інтерфейсі отримуватиме попередження та що робить за ним далі.
На першому дзвінку звіримо горизонт і одиницю прогнозу, обговоримо метрику якості та перевіримо, чи вистачає історії для передбачення ДТП методами машинного навчання або частину даних доведеться збирати.
За підсумками повернемося з планом впровадження: етапи, склад робіт, що знадобиться з вашого боку, строки пілоту та критерії, за якими вважатимемо його успішним. Опишіть задачу у вільній формі та додайте те, що є, — повернемося з оцінкою та планом.
