Разработка AI-системы для строительства и архитектуры

AI в строительстве: где ломаются процессы на объекте

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

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

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

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

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

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

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

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

Прогноз сроков строится на накопленных данных, а не на экспертном «кажется, успеваем». Система сопоставляет фактические темпы по захваткам с планом и показывает отклонение заранее — у руководителя остаётся запас на перераспределение бригад вместо аврала в последнюю неделю.

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

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

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

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

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

Этапы внедрения: от аудита данных до передачи

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

Дальше каждый этап опирается на проверенный предыдущий:

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

Состав передаваемых материалов и настроек

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

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

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

Кейс: AI в строительстве — контроль качества

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

Что изменили

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

Что стало

Цикл проверки этажа сократился до одного рабочего дня: инженер не ищет расхождения, а подтверждает или отклоняет готовый список. Доля пропущенного брака упала до 3% — в остатке дефекты, которые физически не читаются на снимке, вроде непрокрашенного стыка за утеплителем. Обратная связь по бригаде уходит в тот же день, поэтому переделки переходят из категории «после приёмки» в категорию «до бетонирования».

Чем машинное зрение отличается от фотоотчёта

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

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

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

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

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

Сомнения по данным, разметке и точности моделей

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

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

Что делать, если типовые решения меняются?

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

Как защищена проектная документация?

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

Сколько занимает обучение модели?

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

Обсудим задачу: этапы и план работ

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

Дальше идём по шагам:

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

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