Чому AI-аналіз потоків людей дає збої на міських даних
Автоматичний підрахунок потоку ламається не на моделі, а на вхідних даних. Пристрій, що їде в салоні авто, і телефон пішохода потрапляють в одну вибірку, тому AI-аналіз потоків людей змішує пішохідний трафік із транспортним.
На виході — завищена щільність на магістралях і занижена в переходах між кварталами, хоча фізично картина зворотна.
Друге джерело — пропуски в геоданих. Подія приходить не щохвилини, частина пристроїв взагалі не потрапляє в лог, а на межах зон запис обривається.
Модель добудовує розрив лінійно й отримує гладкий, але неправильний профіль: пік в одній точці й уявне затишшя в сусідній, куди люди просто не доїхали на момент вимірювання.
Поверх цього працюють аномалії трафіку: ярмарок, ремонт дороги, закриття станції на вихідні. Разовий сплеск потрапляє в навчання як норма й зсуває сезонну компоненту.
Помилки розпізнавання накопичуються тихо — точність підрахунку потоку просідає вдвічі, а на зведеному графіку це виглядає як рівне зростання.
Саме на таких даних ухвалюють рішення щодо об’єкта: ставлять точку тяжіння там, де потік був один тиждень, і не бачать сталого попиту в двох кварталах поруч. Розбираємо, як це закривається — від чищення вибірки до перевірки моделі на незалежному вимірюванні.
Вимірюваний ефект: точність, швидкість і стійкість системи
Результат AI-системи аналізу потоків розкладається на величини, які замовник може перевірити сам, а не прийняти на слово.
Частку правильно розпізнаних об’єктів, обсяг ручної звірки й час підготовки звіту ми фіксуємо до старту — на розміченій вибірці ділянок і часових вікон, і ці самі значення йдуть у приймання.
Точність розпізнавання рахуємо окремо за типами учасників руху: пішохід, легковий транспорт, транзитний потік. На змішаному потоці помилки розподіляються нерівномірно, тому загальна цифра по системі нічого не доводить.
Класифікація уточнюється за шаром зон і об’єктів інфраструктури, геометрія яких береться з OpenStreetMap і потім вивіряється за фактичними треками.
Час підготовки звіту перестає залежати від ручної праці: агрегати за сіткою рахуються регламентно, вивантаження збирається з готових шарів.
Ручна звірка скорочується до контрольної вибірки — оператор перевіряє не весь масив, а ті записи, де модель дала низьку впевненість і позначила їх для розбору.
Окремо закриваємо клас відмов, який раніше ламав розрахунки: розриви треку в місцях втрати сигналу, дублі під час перемикання між вежами, подвійний облік на межах зон.
Зіставлення сесій і дедуплікація прибирають їх до агрегації, тому повторний прогін на тих самих даних дає той самий результат. Розрахунки відтворювані, а розбіжності між двома звітами завжди пояснювані — аж до конкретної ділянки й години.
Джерела даних і режими обробки: що підходить під задачу
Вибір джерела визначається питанням: потрібне охоплення території, точність у конкретній точці чи ретроспектива. Знеособлені геодані операторів зв’язку показують потоки між районами, маятникову міграцію й добові профілі, але згладжують деталі всередині кварталу.
Власні датчики точні на входах і у вузьких проходах, зате залежать від монтажу, живлення й погоди — це ціна за деталізацію. Режим обробки — друга вісь вибору: онлайн-підрахунок віддає поточне завантаження, архівний розбір відновлює історію й слугує еталоном для калібрування.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Знеособлені геодані операторів зв’язку | Потрібна картина по місту або регіону: потоки між районами, сезонність | Агрегація за сотами, точність падає там, де одна сота накриває кілька об’єктів; вивантаження приходить із затримкою |
| Власні датчики на об’єкті | Важлива точність на входах, у переходах і на парковці, потрібен облік унікальних відвідувачів | Монтаж, живлення й обслуговування; сліпі зони та перекриття; якість сигналу залежить від освітлення |
| Обробка архіву | Ретроспектива: оцінити ефект змін, порівняти сезони, перевірити модель на минулих даних | Запізнення в часі, потрібне зберігання сирих записів і розмітка; не годиться для оперативних рішень |
| Режим онлайн-підрахунку | Потрібне поточне завантаження: регулювання потоків, оповіщення про перевантаження | Чутливий до збоїв зв’язку й живлення, потребує запасу обчислювальних ресурсів і контролю якості даних на ходу |
| Гібридний збір даних | Задача змінюється: зараз контроль, далі аналітика й прогноз | Складніший у налаштуванні — потрібно звести різні сітки агрегації та відкалібрувати джерела одне за одним |
На практиці схема майже завжди гібридна: геодані задають охоплення, датчики уточнюють ключові точки, архів перевіряє, що розрахунок не розійшовся з реальністю. Під задачу ми обираємо комбінацію з цієї таблиці й фіксуємо, які обмеження для вас прийнятні.
Як ми впроваджуємо систему: етапи інженерної роботи
Система аналізу потоків починається не з моделі, а з аудиту даних. Ми дивимося, які джерела доступні — знеособлені вивантаження операторів зв’язку, треки транспорту, шари забудови й подій — і чи достатньо їхньої щільності для потрібних ділянок. Якщо цей крок пропустити, модель буде впевнено рахувати шум.
- Аудит вихідних даних. Перевіряємо повноту, частоту й якість зрізів, знаходимо розриви та дублі, позначаємо слабко покриті райони й години. На виході — карта придатності даних.
- Зведення джерел. Приводимо вивантаження до єдиної схеми, знеособлюємо й пов’язуємо між собою, щоб один потік описувався однаково незалежно від джерела.
- Калібрування моделей. Налаштовуємо параметри під конкретне місто: щільність забудови, режим роботи транспорту, сезонність. Модель навчається на історичних зрізах, а не на усереднених шаблонах.
- Контрольна вибірка. Частина даних не бере участі в налаштуванні — на ній звіряємо розрахунок із фактом. Так видно, де модель помиляється системно, а де разово.
- Перевірка на об’єкті. Звіряємо розрахунок із натурним підрахунком на контрольних ділянках — перехресті, вузлі, зупинці. Розходження вище порогу повертає нас до калібрування, а не у звіт.
- Передача в експлуатацію. Розгортаємо систему на вашому боці, налаштовуємо оновлення даних і оповіщення, навчаємо команду, передаємо документацію.
Що залишається після запуску
Регламент: як часто переглядати модель, які відхилення вважати підставою для повторного калібрування і хто відповідає за оновлення даних.
Документація, схеми й регламенти: склад передаваного комплекту
Комплект документації збирається паралельно розробці, а не перед здаванням: описана постфактум система розходиться з фактичним станом, і за місяць такими документами ніхто не користується.
Нижче — те, що фізично залишається у замовника й дає змогу розвивати аналіз потоків людей і транспорту силами своєї команди.
- Схема потоків даних — від джерела геоданих до вітрин аналітики: які поля надходять, де збагачуються й агрегуються, де зберігається сирий шар, з якою періодичністю оновлюється кожна ділянка.
- Опис логіки розрахунку — як рахуються інтенсивність і щільність потоку, як визначаються аномалії та сталі маршрути, які правила відсікають викиди й пропуски в даних.
- Політики доступу — ролі й матриця прав за об’єктами та територіями, розмежування чутливих зрізів, порядок надання й відкликання доступів, журналювання звернень до даних.
- Регламент оновлення даних — вікно перерахунку, поведінка системи при затримці або обриві джерела, порядок публікації нової версії моделі та відкат до попередньої.
- Інструкції для команди — запуск і зупинка контурів, діагностика типових збоїв, порядок дій при деградації джерела, точки, де потрібен інженер, а де система дає раду сама.
- Словник показників — єдині визначення метрик, щоб «потік» у звіті та в моделі означав те саме, без розбіжностей між підрозділами.
- Журнал рішень — які зміни вносилися в логіку розрахунку і чому: під час розбору інциденту видно причину, а не лише наслідок.
Кожен документ живе в репозиторії замовника й оновлюється разом із кодом — розходження видно на рев’ю, а не з’ясовується в момент інциденту.
Передача — не «надіслали архів»: розбираємо схеми з командою, відповідаємо на запитання й фіксуємо, хто відповідає за який контур після запуску.
Кейс: як змінилася точність підрахунку на реальному об’єкті
Об’єкт — транспортно-пішохідний вузол із чотирма підходами: дві камери дивилися вздовж проїзної частини, дві — на пішохідні переходи.
Замовник прийшов із ручними вимірюваннями в години пік, і саме їх узяли за еталонну вибірку: сирі траєкторії, геозони й мітки об’єктів складали в PostGIS, щоб звіряти автоматичний підрахунок із ручним щохвилини.
На вході збіг із ручним вимірюванням тримався на рівні трьох випадків із чотирьох удень і двох із трьох уночі. Група пішоходів сходила за один об’єкт, відображення на мокрому асфальті давали хибні спрацювання, а траєкторія обривалася, коли потік транспорту перекривав людину. Окрема проблема — розсинхрон часу між камерами: той самий автомобіль потрапляв у звіт двічі.
Що калібрували
Пороги впевненості виявлення розвели за сценаріями — світлий час, ніч, опади — замість одного загального.
Повний кадр замінили зонами інтересу, що відсікають вітрини й відображення, а зшивання траєкторій через перекриття налаштували за напрямком руху й часом зникнення, а не за близькістю об’єктів.
Час на камерах прив’язали до спільного джерела, щоб потоки на перехресті складалися, а не дублювалися.
Що вийшло
Точність підрахунку піднялася з 74% до 94% у світлий час і з 61% до 88% уночі, частка обривів траєкторій упала з третини до 6%.
Розходження з ручним вимірюванням у години пік тримається в межах 3–4%, а звіти за годинами й напрямками будуються автоматично — окремі вивантаження для звірки більше не потрібні.
Чим підрахунок людей за геоданими відрізняється від відеоаналітики?
Камера й геодані вимірюють різні фізичні величини. Відеоаналітика розпізнає об’єкти в кадрі й рахує перетини із заданою лінією, а геодані — це агреговані знеособлені реєстрації абонентських пристроїв у зоні обслуговування.
Звідси розходяться охоплення, деталізація й коло задач, які кожному джерелу взагалі має сенс задавати.
Геодані виграють в охопленні: вони покривають місто або регіон без монтажу обладнання, працюють цілодобово й не залежать від освітлення, погоди та ракурсу. Плата за це — роздільна здатність.
Потік видно на рівні зони, а не окремої людини, а на малих числах вмикається поріг знеособлення, і частина значень надходить згладженою. Розрізнити пішохода, автомобіль і транзит через район у загальному обсязі складно без додаткових ознак.
Відеоаналітика сильна в точці: розрізняє клас об’єкта, напрямок і час проходу, віддає метрику за конкретним входом.
Але її похибка зростає саме там, де потік найцікавіший, — у щільному натовпі, при перекриттях, у сутінках і опадах, на стику зон огляду, де та сама людина потрапляє в два лічильники.
До цього додається лінійне зростання витрат на охоплення: щоб закрити район, потрібно пропорційно більше камер, монтажу й обслуговування.
Тому вибір джерела даних диктує задача, а не зручність інструмента. Потрібен точний підрахунок на вході та розбивка за типами — беремо відео. Потрібна структура потоків між районами, добові й тижневі ритми, охоплення території без обладнання — працюємо з геоданими.
Комбінована схема дає найкраще з двох: відеопідрахунок на опорних точках слугує еталоном калібрування, а геодані масштабують картину на все місто й пов’язують точки між собою. Нижче розбираємо, як обираємо джерело під конкретну задачу.
Технічні сумніви: приватність, точність та інтеграція
Сирі ідентифікатори пристроїв не покидають наш контур: на вході вони замінюються на псевдоніми із сіллю, яка ротується за розкладом, а в аналітику потрапляють лише агрегати за гео-комірками.
Комірки, де число пристроїв нижче заданого порогу, не публікуються взагалі — за ними не можна відновити маршрут конкретної людини.
Такий контур закриває вимоги захисту персональних даних і при цьому залишає дані придатними для моделі: на агрегатах видно і розподіл потоків, і добову сезонність.
На малих потоках цифри поводяться інакше — поодинокі пристрої дають стрибки, які легко прийняти за тренд. Ми рахуємо точність на малих потоках явно: будуємо довірчі інтервали, згладжуємо за часом і не показуємо висновок там, де вибірка нижче порогу. У звіті видно не одну точку, а діапазон, тому рішення не ухвалюються на шумі.
Інтеграція з обліковими системами замовника йде через регламентний обмін.
Зіставляємо довідники об’єктів і зон, приводимо агрегати до вашого формату й віддаємо їх у вже працююче сховище або звітність — система стає поруч і наповнює те, чим ви користуєтеся, без перебудови процесів.
Метод дає абсолютну чисельність людей?
Ні, і це усвідомлене обмеження методу. Геодані показують відносні потоки та структуру: звідки й куди рухається трафік, як змінюється профіль за годинами та днями тижня.
Абсолютну чисельність надійніше брати з ваших облікових систем, а геодані використовувати як пояснювальний шар до них.
Що як частина точок не віддає дані?
Ми тримаємо карту покриття за зонами й регулярно її звіряємо. Якщо зона випадає, потік за нею позначається як неповний, а не дораховується моделлю — інакше у звіті з’явилися б числа, яких немає в даних. Пропуск закривається додаванням джерела або коригуванням меж зони.
Обговоримо задачу: з чого почнемо і що потрібно з вашого боку
Початок проєкту впирається не в модель, а в дані й доступи: без історичних зрізів і розуміння, як влаштовані джерела, ні архітектуру, ні строки чесно не оцінити.
Нижче — мінімальний перелік вхідних даних від замовника, після якого ми повертаємося з планом робіт і оцінкою, а не з уточнювальними питаннями.
- Цілі та межі: які рішення ви ухвалюєте за результатом — пріоритет маршрутів, завантаження зупинок, прогноз пікових інтервалів.
- Знеособлені історичні зрізи геоданих за кілька періодів, включно з аномальними днями: свята, ремонти, збої.
- Довідники та шари: зупинки, маршрути, розклади, межі районів і точки тяжіння.
- Доступи до систем: сховище даних, черга подій, панель моніторингу транспорту — з роллю на читання.
- Відповідальний за дані з вашого боку та порядок погодження змін у джерелах.
- Вимоги до вивантаження результату: формат, куди пишемо, хто і як часто дивиться зведення.
- Обмеження щодо персональних даних і правила зберігання знеособлених наборів.
Як тільки перелік закрито, ми описуємо схему обробки, перевіряємо її на вашому історичному зрізі й показуємо, на яких ділянках модель помиляється. Після цього фіксуємо етапи, склад робіт і строки. Опишіть задачу — повернемося з оцінкою та планом.
