Розробка ШІ-системи генеративного проєктування будівель

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

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

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

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

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

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

Що змінюється в роботі бюро: швидкість варіантів і перевірок

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

За ніч рахується 20–40 варіантів з метриками по кожному, і на захист іде 3–4 опрацьованих рішення замість одного.

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

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

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

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

Режими пошуку рішень: порівняння підходів і обмежень

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

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

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

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

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

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

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

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

Тому порядок робіт вибудуваний так, щоб спочатку зняти правила з практики і лише потім закріплювати їх у коді.

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

   Розбираємо 15–20 минулих проєктів: які рішення ухвалювалися відразу, що перероблялося і на якому етапі.

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

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

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

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

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

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

Конфігурації, правила та регламенти: що залишається в бюро

Система генеративного проєктування цінна не сама по собі, а тим, що бюро може змінювати її поведінку без розробника.

Тому на закритті етапу ми передаємо не «доступ до сервісу», а повний набір артефактів, за якими команда відтворює будь-який результат і править правила своїми руками.

• Конфігурація системи — файли налаштувань генерації: параметри варіантів, ваги обмежень, прив’язка наборів правил до типів об’єктів, профілі під різні стадії проєктування.
• Опис правил і обмежень — що система вважає допустимим, що відкидає і чому; кожне обмеження з посиланням на пункт норм або внутрішнього стандарту бюро.
• Шаблони рішень — типові сценарії (секції, паркінг, громадські блоки) з готовими наборами налаштувань, щоб новий проєкт стартував із перевіреної конфігурації, а не з чистого аркуша.
• Регламент роботи команди — хто на якому кроці затверджує варіант, як фіксується відхилення від типового рішення, у який момент підключається головний інженер проєкту.
• Документація та інструкції — розгортання, ролі й доступи, порядок оновлення моделей, розбір типових збоїв із готовими діями.
• Журнал змін конфігурації та процедура відкату — видно, хто і коли поміняв правило, і є куди повернутися, якщо новий набір дає просідання за якістю варіантів.
• Набір приймальних задач — еталонні вхідні дані з очікуваним результатом: після будь-якої правки правил прогін показує, чи не зламали суміжні сценарії.

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

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

Кейс: варіантність планувань зросла в рази за один цикл

Вихідна точка

Житловий корпус на 12 поверхів: планування народжувалися вручну — команда встигала прорахувати 2-3 варіанти компонування, на кожен ішло 8-10 робочих днів.

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

Що змінили і що отримали

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

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

Метрики до і після: 2-3 варіанти за 8-10 днів проти 40-60 варіантів за цикл у 4-6 годин; первинна оцінка одного варіанта скоротилася з 3-4 годин до 5-7 хвилин; частка компонувань, що проходять нормативні перевірки з першого прогону, зросла приблизно з третини до 85%. Інженер дивиться не все, а 5-8 фіналістів, відсортованих за цільовою функцією.

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

Що робити, якщо в бюро вже є база типових рішень?

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

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

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

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

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

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

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

Як враховуються нормативні обмеження?

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

Як це вбудовується в поточний процес?

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

Хто відповідає за результат?

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

Обговоримо задачу на ваших вхідних даних

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

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

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

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