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

AI у будівництві: де ламаються процеси на об'єкті

На об'єкті дані проєкту живуть у трьох-чотирьох незв'язаних місцях: листування в месенджерах, вкладені таблиці, скани актів і фотографії з майданчика. Та сама відмітка або вісь надходить у кількох версіях, і ніхто не може впевнено сказати, яка актуальна на ранок понеділка.

Це і є розрізнені дані об'єкта — не метафора, а конкретний набір файлів без загальної прив'язки до приміщень і конструкцій.

Далі спрацьовує не складність проєкту, а затримка в передачі зміни. Виконавець дізнається про нове рішення останнім, уже із закупленим матеріалом, а розбіжність виявляється після монтажу — під час обмірної зйомки.

Ціна — демонтаж, простій двох бригад і зсув графіка, який потім наздоганяють в авральному режимі. Зрив термінів будівництва рідко починається з помилки в розрахунку; частіше він починається з версії креслення, яку не побачив той, хто ставив опалубку.

AI-будівництво закриває саме цей розрив: система зводить креслення, акти, зауваження технагляду та звіти з майданчика в єдину модель даних об'єкта і прив'язує все до осей і приміщень.

Тоді нова версія розділу автоматично підсвічує, що вона зачіпає, — і це видно до виходу на монтаж, а не після. Впровадження AI у проєктування дає найбільший ефект не на етапі візуалізацій, а на звірці версій і пошуку невідповідностей між суміжними розділами.

Розбираємо, як це закривається на практиці: від аудиту джерел і правил зіставлення до моменту, коли система попереджає про розбіжність раніше, ніж вона перетвориться на переробку.

Що змінюється після впровадження моделей у проєктах

Поки модель живе лише в кресленнях, розбіжності між розділами — траса вентиляції проти несучих конструкцій, армування проти закладних — спливають на майданчику, коли переробка вже з'їла тижні.

У спільній моделі ці самі перетини відловлюються перевіркою до видачі у виробництво: частка розбіжностей, закритих на етапі проєктування, сягає 90%.

Модель збирається в Autodesk Revit і передається через IFC — обмін залишається відкритим, без прив'язки до одного постачальника.

Цикл погоджень скорочується за рахунок того, що зауваження прив'язуються до координат і елементів, а не переказуються в листах: відповідальний бачить конкретний вузол з історією правок, час реакції на відхилення падає з днів до годин, повторні кола по одному й тому ж стику майже зникають.

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

Прогноз термінів будується на накопичених даних, а не на експертному «здається, встигаємо». Система зіставляє фактичні темпи по захватках із планом і показує відхилення заздалегідь — у керівника залишається запас на перерозподіл бригад замість авралу в останній тиждень.

Ефект тримається лише за дисципліни в даних: модель, яку не підтримують в актуальному стані, дає такий самий недостовірний прогноз, як і ручні зведення.

Формати впровадження: хмара, закритий контур, гібрид

Схему розміщення обирають не на смак, а за тим, де лежать дані і кому вони належать. Якщо в проєкті є креслення, кошториси або режимні об'єкти, питання впирається у вимоги служби безпеки, а не в можливості моделей. Тому спочатку розбираємо обмеження, потім збираємо контур.

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

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

Етапи впровадження: від аудиту даних до передачі

Впровадження починається не з вибору моделі, а з розбору того, що вже накопичено. Кошториси лежать у таблицях, креслення — у проєктних файлах, фотозвіти — у листуванні, журнали робіт — на папері. Поки не ясно, які масиви придатні для обробки, будь-яка оцінка термінів — ворожіння.

Далі кожен етап спирається на перевірений попередній:

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

Склад матеріалів і налаштувань, що передаються

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

• Схеми інтеграції. Що з чим обмінюється даними, у якому форматі та з якою періодичністю, що відбувається при недоступності будь-якої зі сторін — з переліком точок відмови та поведінкою за замовчуванням.
• Налаштовані сценарії обробки. Логіка за кроками: перевірка комплектності, звірка з проєктною документацією, класифікація відхилень і формування зауважень по кожному типу об'єкта.
• Політики доступу та ролі. Хто вносить дані, хто погоджує відхилення, які дії фіксуються в незмінному журналі і що саме туди потрапляє.
• Інструкції для бригад на майданчику. Короткі пам'ятки: з якої точки знімати, як перевірити коректність даних до відправлення, що робити при сумніві — без посилань на внутрішню кухню рішення.
• Регламенти роботи. Порядок розбору помилок, хто відповідає на стороні замовника, в які терміни підключаємося ми, як оформлюються доопрацювання та оновлення логіки.
• Документація рішення. Опис компонентів і меж застосовності: на яких типах об'єктів точність вища, де обов'язкова ручна перевірка, які помилки вважаються допустимими.
• Метрики та звітність. Частка зауважень, підтверджених без правки, кількість ручних доопрацювань на об'єкт, час від зйомки до висновку — щоб ефект вимірювався, а не заявлявся.

Кожен пункт погоджуємо на етапі приймання: ви перевіряєте його на своїх об'єктах, а не на демонстраційних даних. Опишіть завдання — повернемося з оцінкою та планом передачі.

Кейс: AI у будівництві — контроль якості

До впровадження контроль якості на майданчику тримався на обходах і ручній звірці: інженер знімав конструкції на камеру, а ввечері зіставляв знімки з проєктною документацією і вносив зауваження в журнал.

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

Що змінили

Знімки з майданчика прив'язуються до координат і зіставляються з проєктною моделлю: вивантаження з Autodesk Revit переводимо у відкритий формат, щоб звірка йшла за геометрією, а не за кресленнями.

Комп'ютерний зір знаходить розбіжності, розмічає їх за класами критичності та складає в перелік з прив'язкою до осі та відмітки. Поріг чутливості налаштовували разом з технаглядом — система позначає те, що виходить за допуск, а не кожен відблиск на опалубці.

Що стало

Цикл перевірки поверху скоротився до одного робочого дня: інженер не шукає розбіжності, а підтверджує або відхиляє готовий список. Частка пропущеного браку впала до 3% — у залишку дефекти, які фізично не читаються на знімку, на кшталт непрофарбованого стику за утеплювачем.

Зворотний зв'язок по бригаді йде того ж дня, тому переробки переходять з категорії «після приймання» в категорію «до бетонування».

Чим машинний зір відрізняється від фотозвіту

Фотозвіт — це архів, а не вимірювання. Виконроб обходить об'єкт, знімає вузли, прив'язує кадри до дати й підпису, складає в журнал.

Дані є, але вони не зіставлені з проєктним рішенням: щоб побачити відхилення, інженер відкриває знімок, знаходить відповідний аркуш робочої документації і порівнює вручну. На об'єкті з сотнями вузлів така вибірка завжди неповна.

Машинний зір починається з того ж кадру, але закінчується не файлом, а координатами розбіжності.

Кадр прив'язується до просторової моделі об'єкта, елемент розпізнається і зіставляється з проєктним положенням — система рахує відхилення за геометрією, за положенням закладних, за наявністю армування. Інженер отримує не «подивіться фото», а конкретну ділянку з числом.

Різниця в розпізнаванні дефектів — на рівні постановки завдання. Людина шукає те, про що її попередили, і переглядає вибірково.

Алгоритм перевіряє кожен кадр за одним і тим самим набором ознак: тонка тріщина, зміщення опалубки, пропущений анкер — це класифікація і сегментація на розмічених кадрах конкретного об'єкта, а не загальна «нейромережа для будівництва».

Є і ціна помилки. Фотозвіт не дає хибних спрацювань просто тому, що нічого не вимірює. Машинний зір дає, тому в контур вводять пороги чутливості та обов'язкову перевірку спірних ділянок інженером — підсумкове рішення все одно за людиною.

Порівняння підходів сходиться до одного: фотозвіт фіксує, що було, машинний зір показує, наскільки це розходиться з проєктом. Перше потрібне для історії та приймання, друге — для рішень прямо в момент робіт, поки відхилення ще дешево виправити.

Сумніви щодо даних, розмітки та точності моделей

Перше питання на старті — чи вистачить уже накопиченої документації. Вистачає, якщо корпус однорідний: єдиний стандарт оформлення, повторювані вузли, зіставний масштаб об'єктів.

Якщо креслення надходять від різних бюро і в різних форматах, модель плутає схожі елементи — тоді спочатку описуємо правила розмітки і приводимо корпус до єдиного вигляду.

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

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

Що робити, якщо типові рішення змінюються?

Система зібрана модульно: розпізнавання вузлів, перевірка за нормами і звірка зі специфікацією живуть окремо. Змінюється один модуль, решта працює, попередня версія залишається для відкату.

Як захищена проєктна документація?

Обробка йде у вашому контурі: доступ за ролями, журнал звернень, заборона вивантаження назовні. Креслення і розмітка залишаються вашою власністю.

Скільки займає навчання моделі?

Термін задає обсяг розмітки та однорідність корпусу, а не вибрана технологія. Цикл «розмітка — навчання — перевірка на відкладеній вибірці» йде ітераціями: перший робочий результат — на першій, далі точність моделі зростає на ваших правках з реальних об'єктів.

Обговоримо завдання: етапи та план робіт

Перша розмова займає близько години і не вимагає готового технічного завдання — ми розбираємо завдання, а не презентуємо рішення.

Щоб вона пройшла предметно, принесіть те, що вже є: вивантаження з кошторисної системи, приклади проєктної документації, журнал обходів майданчика, перелік погоджувачів. Чим ближчі матеріали до реальних, тим коротший шлях до оцінки термінів.

Далі йдемо за кроками:

• Фіксуємо межі процесу: де починається завдання, який результат вважаємо готовим, хто приймає роботу.
• Розбираємо дані: в якому вигляді надходять креслення, кошториси, фото і звіти, що приводимо до єдиного формату і в якому обсязі.
• Визначаємо точки стикування з обліковою системою та сховищем документів: обмін, права доступу, журнал змін.
• Погоджуємо метрики: частка позицій, оброблених автоматично, час підготовки звіту, кількість помилок, які система зобов'язана відловлювати.
• Збираємо план впровадження за етапами з проміжним результатом, щоб користь приходила до фінального запуску.
• Плануємо пробний запуск на одному об'єкті або ділянці — з відкатом у ручний режим без зупинки робіт.
• Повертаємося з оцінкою термінів і планом: що робимо ми, що залишається на вашій стороні, які дані потрібні до старту.

Якщо готових матеріалів немає, почнемо з опису процесу — цього достатньо для першого кроку. Опишіть завдання, і ми повернемося з оцінкою термінів і планом робіт.