AI-система анализа потоков людей и транспорта по геоданным

Почему AI анализ потоков людей даёт сбои на городских данных

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

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

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

Именно на таких данных принимают решения по объекту: ставят точку притяжения там, где поток был одну неделю, и не видят устойчивого спроса в двух кварталах рядом. Разбираем, как это закрывается — от чистки выборки до проверки модели на независимом замере.

Измеримый эффект: точность, скорость и устойчивость системы

Результат AI-системы анализа потоков раскладывается на величины, которые заказчик может проверить сам, а не принять на слово. Долю верно распознанных объектов, объём ручной сверки и время подготовки отчёта мы фиксируем до старта — на размеченной выборке участков и временных окон, и эти же значения идут в приёмку.

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

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

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

Источники данных и режимы обработки: что подходит под задачу

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

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

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

Как мы внедряем систему: этапы инженерной работы

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

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

Что остаётся после запуска

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

Документация, схемы и регламенты: состав передаваемого комплекта

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

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

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

Кейс: как изменилась точность подсчёта на реальном объекте

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

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

Что калибровали

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

Что получилось

Точность подсчёта поднялась с 74% до 94% в светлое время и с 61% до 88% ночью, доля обрывов траекторий упала с трети до 6%. Расхождение с ручным замером в часы пик держится в пределах 3–4%, а отчёты по часам и направлениям строятся автоматически — отдельные выгрузки для сверки больше не нужны.

Чем подсчёт людей по геоданным отличается от видеоаналитики?

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

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

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

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

Технические сомнения: приватность, точность и интеграция

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

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

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

Что если часть точек не отдаёт данные?

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

Обсудим задачу: с чего начнём и что нужно с вашей стороны

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

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

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