Разработка AI-системы городского планирования Urban Planning AI

Почему городское планирование AI упирается в данные

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

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

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

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

Измеримый эффект: сроки согласований и качество прогнозов

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

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

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

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

Варианты внедрения: облако, локальный контур, гибрид

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

Что реально различается между схемами

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

Порядок работ: от аудита данных до передачи системы

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

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

Что передаём на руки: модели, схемы, регламенты

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

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

Комплект самодостаточен: изменения можно вести своими силами или отдать другой команде без восстановления контекста.

Как это работает на практике: район комплексной застройки

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

Что показывали замеры до внедрения

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

Что изменили и что получилось

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

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

Что делать, если AI-сервисы уже внедрены, но данные не сходятся?

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

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

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

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

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

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

Что происходит с городскими данными?

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

Кто отвечает за модель после запуска?

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

Обсудим задачу: что прислать для точной оценки

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

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

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