Розробка AI-системи для аналізу BIM-моделей під ключ

AI-аналіз BIM: де рветься ручна перевірка моделей

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

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

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

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

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

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

Що змінюється після автоматизації перевірок моделей

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

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

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

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

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

Без нормалізації будь-яка перевірка дає шум і хибні спрацювання, тому обмін за відкритими схемами buildingSMART і чищення атрибутів — частина роботи, а не підготовка «на стороні замовника».

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

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

Способи перевірки моделей: порівняння підходів

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

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

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

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

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

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

Впровадження за кроками: від аудиту моделі до регламенту

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

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

Комплект передачі: конфігурації, схеми, політики, регламенти

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

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

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

Кейс: перевірка координації розділів без ручного обходу

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

Координацію розділів перевіряли обходом — інженер відкривав Navisworks, вручну проходив поверхи й позначав перетини в таблиці. На один цикл ішло 7–8 проходів і близько трьох тижнів, а частина невідповідностей спливала вже на будівництві: переробками та зсувом поставок обладнання.

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

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

Метрики до й після: проходів перевірки — 2 замість 7–8 (перший автоматичний, другий на закриття спірних місць); частка невідповідностей, знайдених до випуску, зросла з 60% до 93%; комплект документації виходить на три тижні раніше, а строки погодження скоротилися вдвічі — спірні вузли приходять з історією та посиланням на правило, що спрацювало, а не із запитанням «хто правий».

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

Що робити, якщо BIM-модель уже в роботі

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

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

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

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

На практиці починають із пілота й розширюють охоплення, поки перевірки не покриють весь випуск.

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

Технічні сумніви: точність, розмітка, підтримка

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

Ризик реальний — частина елементів надходить з неповною розміткою: атрибути не заповнені, той самий тип названий по-різному в різних розділах. Якщо правило зав'язане на точне значення атрибута, перевірка ловить шум замість реальної колізії.

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

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

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

Обговоримо задачу: що потрібно для старту робіт

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

• 2-3 моделі у вихідних форматах (IFC, RVT або експорт з авторського ПЗ) — за ними видно реальну геометрію та структуру даних, а не лише опис.
• Перелік типових помилок, які має ловити система: колізії, недотримання зазорів, розходження атрибутів, порожні параметри елементів.
• Внутрішні стандарти та контрольні списки: вимоги до іменування, правила оформлення, шаблони перевірок за розділами.
• Приклади вже погоджених зауважень — вони задають формат звіту, який вам зручно отримувати на виході.
• Склад ролей і доступи: хто відповідає за моделі на вашій стороні, хто приймає результат, кому передається звіт.
• Цільовий процес: на якому кроці погодження з'являється результат — ручна перевірка, нарада, видача зауважень підряднику.
• Обмеження за даними: де зберігаються моделі, чи є закриті розділи, чи потрібна робота на вашій інфраструктурі.

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

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