Разработка AI-системы предсказания ДТП и аварийных ситуаций

Предсказание ДТП с помощью ML: где ломаются модели

ДТП — редкое событие, и это первое, что ломает постановку задачи. На участке фиксируют единицы происшествий в год, а доля аварийных поездок — доли процента от общего потока. Модель, которая всегда отвечает «спокойно», угадывает в 95% случаев: метрика выглядит отличной, а на выходе мусор — такой прогноз не отличает опасный перекрёсток от безопасного.

Вторая ловушка — утечка признаков из будущего. В обучающую выборку незаметно попадают поля, известные только после происшествия: время прибытия экипажа, оформленный протокол, тяжесть травм. На обучении качество почти идеальное, в работе — случайное угадывание, потому что в момент прогноза этих данных ещё не существует.

Третья причина — смещённая и несбалансированная выборка. Аварии фиксируют там, где стоят камеры и дежурит патруль, поэтому модель учит плотность контроля, а не риск. Агрегация по кварталам и административным районам добивает результат: очаги аварийности размываются, перекрёсток с концентрацией ДТП прячется внутри большого полигона. Участки режем по геометрии дорог — границы берём из OpenStreetMap — и считаем риск на перекрёстках и перегонах отдельно.

Разбираем, как это закрывается: временная кросс-валидация вместо случайной, балансировка редкого класса, аудит признаков на доступность в момент прогноза и привязка прогноза к реальным очагам, а не к сетке.

Что меняется после внедрения прогноза аварийности

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

Время реакции на инцидент сокращается: сигнал об аномалии приходит в диспетчерскую в момент фиксации, а не после разбора смены, поэтому на место успевают до повтора ситуации на том же перекрёстке или съезде. Накопленное снижение аварийности даёт именно скорость закрытия повторов, а не разовый выезд.

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

Ручной разбор записей заменяется готовой выборкой эпизодов с разметкой: аналитик проверяет гипотезы, а не перелистывает архив за смену. Освободившееся время уходит на планирование ремонтов — прогноз по очагам привязывается к сезонности и циклу работ, поэтому разметка, освещение и покрытие ставятся туда, где снимут риск. Эффект от каждого ремонта становится измеримым по тому же участку.

Варианты построения модели прогноза: пакетный, потоковый, гибридный

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

Сравниваем варианты по составу источников данных и по задержке, которую допускает сам процесс принятия решения.

На практике начинают с пакетного контура: он проверяем на истории и не требует постоянного потока. Гибридная схема становится оправданной, когда появляется устойчивый канал телеметрии и требование реагировать быстрее суток — тогда базовая модель задаёт фон, а потоковый слой корректирует её по факту. Переход делаем так, чтобы оба контура можно было запускать независимо: если поток данных пропал, система остаётся на пакетных оценках, а не отдаёт пустой прогноз.

Этапы разработки системы прогноза аварийности

Этапы выстроены итеративно: предсказание ДТП опирается на проверенный результат предыдущего шага, а не на предположения о данных. Начинаем с аудита источников и заканчиваем передачей системы в эксплуатацию вместе с командой заказчика — на выходе остаётся работающий прогноз и люди, которые понимают, как его читать и обновлять.

1. Аудит данных. Сводим историю ДТП и резких торможений, телеметрию транспорта, погодные ряды и данные о ремонтах. Проверяем полноту, расхождения координат, пропуски: иначе модель учится на дефектах учёта.
2. Схема признаков. Считаем признаки на уровне участка и временного окна: интенсивность потока, разброс скоростей, доля резких торможений, видимость, состояние покрытия, тип развязки. Каждый признак должен быть доступен в момент прогноза, а не только в исторических выгрузках.
3. Обучение и валидация модели. Валидируем по времени: учим на прошлых периодах, проверяем на последующих. Смотрим полноту при заданной точности, долю ложных срабатываний, стабильность по сезонам.
4. Пилотный участок. Запускаем прогноз на ограниченном наборе участков с разным характером потока, сопоставляем с фактом и настраиваем пороги срабатывания.
5. Проверка на исторических срезах. Прогоняем модель по прошлым сезонам: сколько событий поймали бы заранее и сколько сигналов оказалось ложными.
6. Передача в эксплуатацию. Разворачиваем сервис, настраиваем мониторинг качества и регламент переобучения, обучаем команду читать прогноз и обновлять данные.

Состав поставки: артефакты моделей, схемы данных, регламенты

Мы передаём не набор файлов, а рабочую систему: у каждой позиции есть владелец на стороне заказчика и документ, по которому её можно проверить и воспроизвести. Ниже — то, что остаётся у вас после сдачи.

• Обученные артефакты модели. Веса, шаги предобработки и пороги срабатывания в виде, который разворачивается на вашем контуре без нашей инфраструктуры, плюс воспроизводимый сценарий обучения.
• Описание признаков. По каждому: источник, формула расчёта, окно агрегации, допустимый диапазон и поведение при пропуске — чтобы логику не восстанавливали по коду.
• Схема потоков данных. Откуда приходят телеметрия, погода и дорожная обстановка, где лежат сырые и агрегированные слои, кто и на каких правах их читает.
• Регламент переобучения. Триггеры — календарь, падение качества, смена парка или маршрутной сети; порядок проверки на отложенной выборке и условия, при которых версия в работу не идёт.
• Инструкция оператора. Как читать оценку риска, какие пороги ведут к уведомлению, как фиксировать ложные срабатывания и передавать их в дообучение.
• Журнал проверок. История версий, метрики на каждой проверке, кто и когда подтвердил выпуск — с возможностью вернуться к предыдущей версии.

Комплект рассчитан на то, что сопровождать систему дальше будет ваша команда: всё, что делается по ходу проекта, оформляется так, чтобы это можно было передать и проверить без нас. Опишите задачу — вернёмся с оценкой и планом, в котором состав поставки зафиксирован заранее.

Кейс: прогноз очагов ДТП на городской сети — цифры до и после

До внедрения сводка по очагам ДТП собиралась раз в квартал: инженер вручную сводил выгрузки из разных ведомств, адреса сопоставлялись глазами, часть записей терялась на дублях и опечатках. К моменту передачи дорожникам список устаревал, а решение о ремонте принималось по прошлогодней картине. Модель мы начинали не с алгоритма, а с разбора этих данных.

Очаги определялись по Методике классификации очагов аварийности, чтобы прогноз говорил на языке заказчика. Отдельно чинили привязку: 18% записей не ложились на дорожный граф — съезды, развязки, мосты и дворовые проезды описывались адресом, а не участком. Дубли схлопывали по пространственно-временному окну, признаки пересобрали на участок: интенсивность, схема движения, освещение, разметка, история ремонтов и сезонность. Без этого любой прогноз ловил бы шум.

После пересборки прогноз пересчитывается ежесуточно, а не раз в квартал. Доля подтверждённых очагов в первой двадцатке участков выросла с 31% до 69%, полнота обнаружения очагов — с 62% до 88%, ложных срабатываний стало одно из восьми вместо одного из трёх. Разбор, где именно модель ошиблась, занимает часы, а не недели.

Что ушло из классов отказов: «залипание» на исторических очагах — после ремонта или смены схемы движения участок больше не держится в топе; ошибки привязки на многоуровневых развязках; сезонные провалы, когда зимняя аварийность недооценивалась из-за летней статистики. Остаточный риск — новые схемы движения, по которым нет ни одной записи: такие участки помечаем как зону неопределённости и показываем отдельно.

Что делать, если уже развёрнута система видеоаналитики

Если видеоаналитика уже развёрнута, в большинстве случаев контур не пересобирают, а надстраивают слоем прогноза. Ключевой вопрос — отделяет ли текущая система детекцию от хранения: если события с камер пишутся с меткой времени, зоной кадра и идентификатором трека, они напрямую становятся входом для модели предсказания ДТП. Перестраивать приходится только то, чего видео не даёт, — динамику траекторий и внешние факторы.

Переиспользуются камеры и их калибровка, готовые детекторы объектов, поток событий и историческая разметка — это экономит месяцы сбора стартовой выборки. Заново собирается признаковый слой: скорость и ускорение по трекам, интервалы между участниками, заторы, сцепление с погодой. Сюда же подключается интеграция с датчиками — фазы светофоров, метеостанции, дорожные контроллеры. Обмен моделями между контурами ведём через ONNX, чтобы не переобучать то, что уже работает.

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

Технические сомнения: данные, ложные срабатывания, приватность

Возражения по предсказанию аварийных ситуаций почти всегда касаются не выбора алгоритма, а данных и режима эксплуатации. Разметка приходит неполной: подтверждённых случаев мало, часть инцидентов закрывается без протокола, а признаки участка меняются по сезону — зимой одна геометрия дороги даёт совсем другую динамику, чем летом. Поэтому качество данных мы проверяем до обучения: считаем долю пропущенных меток, смотрим сдвиг распределения между периодами, фиксируем, по каким признакам модель принимает решение.

Ниже — разбор сомнений, которые чаще всего всплывают на этапе оценки: холодный старт, ложные тревоги, контроль переобучения и работа с персональными данными.

Как модель работает на холодном старте, пока нет своей истории?

Первые недели система идёт в теневом режиме: предсказания считаются, но никого не оповещают. Опираемся на перенос знаний с похожих участков и физические признаки — скорость потока, тормозной путь, плотность. По мере накопления подтверждённых случаев вес переноса снижается, модель переходит на собственную статистику участка.

Как снижается число ложных срабатываний?

Порог выставляем не единым, а под цену ошибки: для опасного перекрёстка лучше пропустить меньше, для спокойного участка — не тревожить службы зря. Оповещения разбираются дежурным, разметка обратной связи возвращается в обучение, поэтому доля ложных тревог снижается от итерации к итерации.

Как вы контролируете переобучение модели?

Валидация идёт по времени, а не случайным разбиением: обучаем на прошлых периодах, проверяем на последующих. Так сразу видно, выучила модель закономерность или запомнила конкретные инциденты. Дополнительно следим за дрейфом входных признаков — при расхождении с обучающим распределением сигнал переобучается.

Что с персональными данными?

На входе данные обезличиваются: идентификаторы транспортных средств и людей не попадают в признаки. Модель работает с агрегатами по участку и временному окну. Доступ к сырым записям ограничен ролями, обращения логируются, срок хранения задаётся политикой и соблюдается автоматически, а не вручную.

Обсудим задачу: какие данные есть и какой прогноз нужен

Чтобы оценка задачи была предметной, а не «на глаз», нужен минимальный набор вводных: чем подробнее исходные данные заказчика, тем точнее состав работ и сроки пилота. Присылать всё сразу не обязательно — начнём с того, что уже есть, остальное уточним на созвоне.

• Выгрузку исторических событий: где и когда происходили ДТП и аварийные ситуации, чем каждая запись описана в вашей системе.
• Схему участков и маршрутов: геометрия дорог, перекрёстки, привязка происшествий к координатам.
• Данные о потоке и условиях: интенсивность движения, время суток, погода, сезонность, состояние покрытия.
• Перечень источников: какие датчики, камеры или внешние сервисы уже отдают данные и с какой периодичностью.
• Ограничения по данным: требования к обезличиванию, разграничению доступа и хранению.
• Целевой прогноз: горизонт предсказания (ближайшие часы или сутки) и единица — участок, время, тип риска.
• Точку встраивания: кто и в каком интерфейсе будет получать предупреждение и что делает по нему дальше.

На первом созвоне сверим горизонт и единицу прогноза, обсудим метрику качества и проверим, хватает ли истории для предсказания ДТП методами машинного обучения или часть данных придётся собирать. По итогам вернёмся с планом внедрения: этапы, состав работ, что понадобится с вашей стороны, сроки пилота и критерии, по которым будем считать его успешным. Опишите задачу в свободной форме и приложите то, что есть, — вернёмся с оценкой и планом.