Чому міське планування AI впирається в дані
Планувальник запитує прогноз пасажиропотоку по новому мікрорайону, а модель відповідає впевненими цифрами, яких насправді не буде.
Причина майже завжди не в архітектурі мережі, а в якості вихідних даних: шари забудови, дорожньої мережі та маршрутів громадського транспорту надходять з різних відомств і накладаються один на одного зі зміщенням у десятки метрів.
Модель навчається на цій склейці й видає результат з тією ж помилкою, тільки тепер її ніхто не бачить очима — вона схована всередині прогнозу.
Корінь проблеми — різні системи координат і різна точність знімання в кожного шару. Одне джерело віддає геометрію в місцевій системі, інше в глобальній, третє — растрову підкладку без прив'язки до поточних меж кварталів.
Додайте сюди незмінні дати оновлення: межі ділянок актуальні на один квартал, а мережа доріг — на інший. Формально міське планування AI отримує повний набір даних, фактично — набір несумісних фрагментів.
Ручна звірка добиває процес. Інженер зводить шари в редакторі, виправляє зміщення, позначає спірні ділянки — і так по кожному району. Поки він доводить дані до придатного вигляду, вихідна ситуація встигає змінитися, і прогноз застаріває раніше, ніж доходить до рішення. Чим більша територія, тим сильніше розходяться шари і тим менше часу залишається на сам аналіз.
Розбираємо, як це закривається: єдина модель просторових даних, автоматична перевірка розбіжностей між шарами та контроль якості вихідних даних до того, як вони потрапляють у навчання.
Вимірюваний ефект: терміни погоджень і якість прогнозів
Базовий цикл міського планування впирається в підготовку сценаріїв: збір шарів з різних відомств, зведення атрибутів, ручна звірка розбіжностей. Це займало тижні, і на момент готовності сценарію частина вихідних припущень встигала застаріти.
Після впровадження той самий сценарій збирається за один-два дні, а правка в припущеннях перераховується без перезапуску всього циклу.
Помилки в даних перехоплюються до розрахунку, а не на захисті сценарію: розриви геометрії, дублі об'єктів, розбіжність адресних реєстрів, пропущені шари, викиди в щільності забудови.
У кожної перевірки є правило і явний поріг, тому сценарій або проходить далі, або зупиняється із зазначенням конкретної ділянки та шару. Частка наборів, забракованих автоматикою, сягає двох третин від загальної кількості зауважень.
Стійкість прогнозу забезпечується прогоном на кількох наборах припущень: на виході отримується діапазон значень, а не одне число, яке легко оспорити.
Так зникає клас відмов, при якому модель видає правдоподібні показники за межами застосовності — по територіях і типах забудови, слабо представлених у вихідних даних.
Результати звіряємо з відкритими галузевими платформами мікромоделювання, наприклад UrbanSim.
Якщо розбіжність за щільністю та завантаженням вулично-дорожньої мережі виходить за заданий коридор, сценарій повертається на доопрацювання даних, а не йде на погодження із завищеною впевненістю.
Варіанти впровадження: хмара, локальний контур, гібрид
Схему розгортання обирають за двома обмеженнями: де дозволено зберігати вихідні дані і який пік запитів потрібно тримати. Хмара дає швидкий старт і еластичні ресурси, локальний контур знімає питання щодо вивезення чутливих шарів, гібридна схема ділить потік між ними. Різниця проявляється не в якості моделі, а в маршрутизації запитів і в тому, як оновлюються дані.
Що реально відрізняється між схемами
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Хмара | Регулярні оновлення шарів, навантаження змінюється щогодини, потрібен швидкий старт пілота | Дані виходять за периметр, є залежність від каналу зв'язку, частину відомчих вивантажень передавати не можна |
| Локальний контур | Дані не підлягають вивезенню, є власні обчислювальні потужності, потрібна робота без зовнішньої мережі | Ресурси фіксовані, пік тримається за рахунок запасу, оновлення моделей відбувається регламентно |
| Гібридна схема | Чутлива частина закрита, аналітика та важкі розрахунки — зовні | Два середовища, синхронізація даних, окремі правила доступу та логування |
Зміна схеми — це заміна шару зберігання та маршрутизації запитів, а не переписування системи. Вимоги до даних фіксуємо до старту: формати, періодичність оновлення, власник, режим доступу.
Що вивозити не можна — залишається в локальному контурі, решту розміщуємо там, де це виправдано навантаженням.
Порядок робіт: від аудиту даних до передачі системи
Порядок етапів важливіший, ніж здається: модель, зібрана до аудиту даних, показує гарні цифри на демонстраційних наборах і розвалюється на реальних кварталах, де частина шарів застаріла, а частина суперечить одна одній.
Тому робота йде від інвентаризації даних до передачі системи, і кожен крок закривається результатом, який можна перевірити.
- Аудит даних. Інвентаризуємо шари: генплан і зонування, кадастр, транспортні потоки, звернення мешканців, статистику із соціальної інфраструктури. Фіксуємо періодичність оновлення, дублі, пропуски та розбіжності між відомствами — на виході реєстр джерел з оцінкою придатності.
- Схема інтеграцій. Визначаємо, як дані потрапляють у систему: регулярні вивантаження, обмін через черги, запити до сервісів-джерел. Для кожного джерела описуємо власника, поведінку при недоступності та правила звірки.
- Цільові показники. Домовляємося, що саме система рахує — пасажиропотік, навантаження на мережі, щільність забудови — і яка точність достатня для рішення.
- Складання та навчання моделей. Збираємо розрахунковий контур, навчаємо моделі та звіряємо прогноз з фактично прийнятими рішеннями на історичних періодах.
- Перевірка моделі. Тестуємо на районах, які не брали участі в навчанні, і на неповних даних — видно, де модель екстраполює навмання. Помилки розбираємо з профільними фахівцями, а не лише за метриками.
- Пілот в обмеженому контурі. Система працює в режимі підказки: фахівець вирішує, система пропонує варіанти та показує підстави. Так перевіряється довіра до висновків.
- Передача системи. Віддаємо документацію, регламенти оновлення даних і перенавчання, навчаємо команду замовника та супроводжуємо перші спірні результати.
Що передаємо на руки: моделі, схеми, регламенти
Роботи закінчуються не демонстрацією моделі, а передачею комплекту, за яким систему можна розвивати без нас. Усе, що описує поведінку моделі, права на дані та порядок їх оновлення, залишається у вашому сховищі коду — не в листуванні і не в голові розробника.
- Опис моделей — призначення кожної моделі, вхідні шари та ознаки, допустимі діапазони значень, метрики якості на відкладеній вибірці та межі застосовності: де прогноз щодо забудови й транспортного навантаження спирається на дані, а де починається екстраполяція.
- Документація по системі — схема сервісів, шлях даних від джерел до вітрин, точки стикування з вашими геоінформаційними контурами та формати вивантажень, сумісні з OpenStreetMap.
- Регламент оновлення — періодичність підтягування шарів, умови перенавчання при зсуві даних, критерії відправлення моделі на донавчання та відповідальні за запуск.
- Права доступу — рольова модель на рівні сервісів, сховищ і панелей аналітики: читання, запис, адміністрування; журнал звернень до чутливих шарів.
- Версіонування — як зберігаються попередні ваги та набори ознак, щоб відкат до попередньої поведінки займав хвилини, а не перезбирання.
- Порядок експлуатації — контроль якості прогнозів, типові відмови та реакція на них, приймання нової версії даних.
- План розвитку — перевірені та відкинуті гіпотези, черга наступних, щоб нова команда не починала з нуля.
Комплект самодостатній: зміни можна вести своїми силами або віддати іншій команді без відновлення контексту.
Як це працює на практиці: район комплексної забудови
Замовник — оператор комплексного освоєння території: район близько 120 га, чотири черги, жорсткі вимоги щодо соціальної та транспортної інфраструктури.
До впровадження під кожен варіант забудови група збирала дані вручну: викопіювання з OpenStreetMap, кадастрові межі, чинні регламенти, шари існуючої мережі. Три варіанти компонування — три тижні роботи та 40–60 ручних звірок на кожен.
Що показували заміри до впровадження
Основний час ішов не на проектування, а на зведення даних. Помилку у відступах від червоних ліній або в щільності забудови знаходили вже після відрисовки варіанта, і частина роботи йшла на перезбирання.
Більше трьох сценаріїв команда не встигала — обговорення точилося навколо того, що встигли порахувати, а не навколо кращого рішення.
Що змінили і що вийшло
Зібрали розрахункове ядро: геодані завантажуються в єдину модель території, поверх — бібліотека правил (щільність, поверховість, відступи, інсоляція, місця в школах і садках, завантаження виїздів).
Варіант описується набором параметрів, а не кресленням, тому новий сценарій прораховується за хвилини, а до результату додається звіт: яке правило порушено і з яким запасом.
Підготовка варіанта скоротилася з трьох тижнів до одного-двох днів, кількість розглянутих сценаріїв зросла з трьох до дванадцяти, ручні звірки замінилися автоматичною перевіркою регламентів.
Розбіжності з експертною оцінкою на вже збудованих чергах уклалися в одиниці відсотків — за ними модель і калібрували.
Що робити, якщо AI-сервіси вже впроваджені, але дані не сходяться?
Розбіжність даних рідко означає, що одна із систем зламалася. Частіше дві частини діючої системи по-різному трактують один і той самий об'єкт: адресу, кадастровий номер, статус зони, дату погодження.
Тому діагностика інтеграцій починається не з переписування, а з пошуку стиків, де трактування розходяться.
Спочатку задаємо еталон: обираємо 15–25 показників, які рахуються в обох системах, і звіряємо їх за однаковим зрізом — один район, один період, один список об'єктів.
Потім ідемо по межах обміну і на кожному стику дивимося, що йде, що приймається і що змінюється при передачі: формат поля, довідник, правило перерахунку, момент оновлення. На практиці розбіжність локалізована в одному-двох місцях, а не розмазана по всій схемі.
Діюча система при цьому залишається в роботі: звірку ведемо на копії, а не на бойовому контурі. Журнали інтеграцій пишемо паралельно і вмикаємо тіньовий прийом — новий потік іде поруч зі старим, результати порівнюються, але перемикання не відбувається.
Історію перераховуємо на архівних вивантаженнях, щоб зрозуміти, коли розбіжність з'явилася і що її запустило.
На виході виходить карта розбіжностей: де втрачається точність, які правила суперечать одне одному, що лікується правкою перетворення, а що вимагає перенесення довідника або зміни власника даних.
Кожна зміна перевіряється на контрольному зрізі до включення в робочий контур — тому поточні процеси не зупиняються ні на день.
Технічні сумніви: точність, приватність, підтримка
Найбільше питань перед стартом надходить не про саму модель, а про те, чим ми доведемо її адекватність, хто отримає доступ до міських даних і що буде із системою через рік після запуску. Нижче — короткі відповіді на три сумніви, які технічні керівники піднімають найчастіше.
Як до запуску переконатися, що прогноз точний?
Перевіряємо на історичних зрізах: беремо минулі періоди, приховуємо фактичний результат і порівнюємо з ним. Рахуємо помилку не однією середньою цифрою, а за класами об'єктів і районами — середні 8% можуть приховувати 30% на промзоні або на периферії.
Обов'язковий відкладений набір територій, які модель не бачила при навчанні: якщо якість на ньому просідає, значить алгоритм запам'ятав часткові випадки замість закономірності.
Що відбувається з міськими даними?
Система розгортається в контурі замовника, назовні йдуть лише агрегати, а не сирі записи. Персональні дані знеособлюються до навчання — ідентифікатори замінюються, адресність згортається до кварталів, де це не ламає задачу.
Доступ розмежований за ролями: аналітик бачить шари та метрики, але не персональні ознаки, а кожне звернення до набору пишеться в журнал.
Хто відповідає за модель після запуску?
Супровід — частина роботи, а не окрема послуга: стежимо за розбіжністю вхідних даних з навчальними, ловимо деградацію прогнозу раніше, ніж її помітить планувальник. Перенавчання йде за розкладом і за тригером — коли нова забудова або маршрутна мережа змінюють картину міста.
Перед кожною заміною моделі проганяємо регресійні перевірки на еталонних ділянках, а попередня залишається готовою до відкату в одну дію.
Обговоримо задачу: що надіслати для точної оцінки
Щоб повернутися з точною оцінкою робіт, а не з вилкою «від і до», нам потрібен контекст щодо даних і меж системи. Частину відомостей уточнимо самі питаннями, але перелічене нижче знімає більшу частину ітерацій і відразу задає реалістичний план впровадження.
- Які рішення система повинна підтримувати: перевірка сценаріїв забудови, прогноз транспортного навантаження, оцінка доступності соціальної інфраструктури, перевірка на суперечності з регламентами.
- Що вже є щодо даних: векторні шари, реєстри, статистика, результати минулих обстежень — у якому вигляді лежать і з якою періодичністю оновлюються.
- Якість і повнота цих даних: де покриття фрагментарне, де розходяться атрибути, чи є історичні зрізи для навчання.
- Куди систему вбудовувати: яка геоінформаційна платформа використовується сьогодні, чи є сховище, до яких довідників потрібна прив'язка.
- Вимоги до пояснюваності: наскільки відповідь має бути перевірюваною, хто і як буде трасувати висновок до вихідного шару.
- Обмеження: персональні дані, режимні території, хто всередині має право на вивантаження та на перегляд проміжних розрахунків.
- Ролі користувачів: хто формулює запит, хто перевіряє результат, хто приймає рішення за сценарієм.
- Критерії приймання: яку частку розрахунків система повинна закривати без ручної правки і за який час віддавати відповідь на сценарій.
З цим набором ми повертаємося з оцінкою робіт і планом впровадження, розбитим за перевірюваними результатами: що побачите на кожному етапі і за якою ознакою приймете. Неповний список — не проблема, обговоримо задачу і підкажемо, чого не вистачає.
