Przykład zastosowania AI do zamiany języka naturalnego na formuły stosowane w budownictwie do opisu wymagań projektowych

Wstęp

Sprawdzanie zgodności projektu z obowiązującymi wytycznymi jest procesem iteracyjnym, z reguły manualnym, opartym obecnie w dużej mierze na rysunkach 2D. W konsekwencji proces ten jest uciążliwy, czasochłonny i podatny na błędy.
W projekcie budowlanym opartym na BIM, dane kompleksowo opisują budynek, który ma zostać wzniesiony. Stanowią je informacje geometryczne i semantyczne, które obejmują znaczenie wyrażeń, relacji między elementami oraz znaczenie kontekstualne. Model IFC prezentuje różnego typu dane, które powinny spełniać wymagania formalne zarówno te stawiane rzeczywistemu obiektowi, jak i te które dotyczą jego cyfrowej reprezentacji. Aby zoptymalizować czas weryfikacji modeli oraz zminimalizować “błąd ludzki” dąży się do komputerowego wsparcia tego procesu poprzez automatyzację. Jednak automatyczne sprawdzanie zgodności modelu i wymagań prawnych/inwestora wymaga między innymi przetłumaczenia przepisów budowlanych i wytycznych dotyczących danego projektu na kod wykonywalny, zrozumiały dla maszyn i algorytmów.
Informacje zapisane w formie sformalizowanego kodu, stanowią doskonałą podstawę do automatyzacji procesu sprawdzania zgodności cyfrowego modelu obiektu budowlanego względem zapisanych warunków.
Architekci i pozostali uczestnicy procesu inwestycyjnego coraz częściej pracują z cyfrowymi modelami informacji o budynku. Modele te obok znanych zastosowań mogą również służyć przy niewielkich dodatkowych nakładach pracy, do automatycznego sprawdzania, czy projektowane budynki spełniają określone wymagania. Takie podejście może również zapewnić znaczne skrócenie czasu i wysiłku potrzebnego władzom i projektantom podczas sprawdzania projektów pod kątem zgodności z przepisami budowlanymi podczas wydawania lub ubiegania się o pozwolenie na budowę. W niektórych krajach częściowa automatyczna weryfikacja zgodności jest już nieodłączną częścią procesu składania wniosków o pozwolenie na budowę, ale w wielu innych plany proponowanych budynków są nadal sprawdzane ręcznie. Raporty Doing Business publikują dane o tej sytuacji w 190 krajach. Polska wg Doing Business 2020 zajmuje 39 pozycję z 12 procedurami i 153 dniami. To się jednak zmienia, ponieważ wiele krajów pracuje nad usprawnieniem tych procesów. Ogólnie rzecz biorąc, stwarza to nowe możliwości dla sektora budowlanego w zakresie skrócenia czasu przetwarzania wniosków dzięki wykorzystaniu już istniejącego materiału danych.
Formalizacja wymagań wymaga specjalistycznej wiedzy w zakresie formułowania specyfikacji, które mają usystematyzowaną, rygorystyczną składnię i semantykę. W związku z tym wymagania są często formułowane w języku naturalnym. Kluczowym więc aspektem weryfikacji i walidacji jest przełożenie tych wymagań na język specyfikacji [1,2].
Niniejsza publikacja dotyczy nieco węższego zadania związanego z zastosowaniem formalizacji języka naturalnego do formuł stosowanych w standardzie IDS (InformationDelivery Specification). Zanim zostanie przedstawiony model2 AI wspierający proces tworzenia specyfikacji zgodnych z IDS zastosowany w rozwiązaniu IDS Maker (Sekcja „Opis Rozwiązania” oraz „Znaczenie pomysłu”), zaprezentowana zostanie sama logika oraz zasady obowiązujące w strukturze pliku IDS (plik wymagań informacyjnych dla modeli IFC, standard IDS utworzony i rozwijany przez buildingSMART).

Struktura pliku IDS i definiowanie wymagań

Każda ze specyfikacji w pliku IDS może składać się z dwóch członów określających zasoby informacyjne modeli IFC lub ich elementów, są to: Zastosowanie oraz Wymagania. Proste specyfikacje mogą mieć jedynie Zastosowanie. Wówczas takie specyfikacje wskazują jedynie, że jakieś określone w tej części obiekty powinny w modelu wystąpić.
Specyfikacja może być jednak bardziej złożona i składać się nie tylko z Zastosowania, ale również z sekcji Wymagań. Wymagania zawsze dotyczą elementów które są wskazane w sekcji Zastosowanie. Takie Specyfikacje więc nie tylko sprawdzają występowanie pewnych elementów (sekcja Zastosowanie), ale również czy te wskazane elementy spełniają warunki określone w Wymaganiach.
W skrócie, posiadając model IFC, szukamy wszystkich obiektów, które spełniają warunki w sekcji Zastosowanie i sprawdzamy je pod względem każdego wymagania z sekcji Wymagania.
Zastosowanie jak i Wymagania można określić przy pomocy 6-ciu różnych kategorii zasobów informacyjnych. Rodzaje faset są takie same zarówno dla Zastosowania jak i Wymagań, dzielą się na Encje, Atrybuty, Właściwości, Materiały, Klasyfikacje, Relacje (Część).

Przykłady wymagań (Requirements) względem elementów ścian o różnych fasetach to np.:

1. Wskazane elementy (określone w Zastosowaniu) mają mieć Encję (typ elementu IFC) równą IfcWallStandardCase.
2. Dla wskazanych elementów (określonych w Zastosowaniu) Atrybut Name (nazwa) ma być równa “External Load-Bearing Wall”
3. Wskazane elementy (określone w Zastosowaniu) mają mieć Właściwość ThermalTransmittance w Zestawie Właściwości Pset_WallCommon o wartości 0.18 W/m2K
4. Wskazane elementy (określone w Zastosowaniu) mają być z Materiału Porotherm 25 P+W
5. Wskazane elementy (określone w Zastosowaniu) mają mieć Klasyfikację EF_25_10 z systemu Uniclass 2015
6. Wskazane elementy (określone w Zastosowaniu) mają mieć Relację IfcRelContainedInSpatialStructure z kondygnacją IfcBuildingStorey

Każda z faset zarówno określająca Zastosowanie jak i Wymagania może mieć różną “szczegółowość”, to znaczy wymaganie może być na poziomie ogólnym np. określać, że po prostu jakaś konkretna właściwość ma występować lub też może być bardziej szczegółowa wskazując, że określona właściwość nie tylko ma występować, ale również ma przybierać wartość z określonego zakresu (np. zakres wielkości dla parametru liczbowego lub też zakres określony listą możliwych parametrów opisowych).
Każda ze specyfikacji zarówno w części “Zastosowanie” jak i w części “Wymagania” może zawierać zbiór faset odnoszących się do różnych parametrów. W tych dwóch częściach istnieją pewne zasady interpretacji poszczególnych definiowanych reguł. To znaczy zbiór reguł wymienionych w Zastosowaniu w każdej pojedynczej specyfikacji rządzi się warunkiem “koniunkcji” (i) (i dlatego ta część też określona jest jednym wspólnym typem z 3ech możliwych: Wymagane, Opcjonalne, Zabronione), natomiast w Wymaganiach jednej specyfikacji każda reguła jest określona odrębnym typem warunku (są więc one analizowane osobno, a nie jako grupa powiązanych warunków). Każdy pojedynczy warunek w wymaganiach przybiera jeden z 3-ech możliwych typów: wymagany, opcjonalny, zabroniony.

Opis rozwiązania AI – generowanie specyfikacji na podstawie tekstu użytkownika

Przedmiotem badań są wybrane problemy przetwarzania języka naturalnego (ang. Natural Language Processing – NLP) w komputerowych systemach wyszukiwania informacji [3,4]. Dotyczą one tworzenia charakterystyk wyszukiwawczych dla tych systemów. To interesujący badawczo, a zarazem złożony i do tej pory niezbadany dogłębnie, problem nauki o informacji. Badania wyniknęły z potrzeby zautomatyzowania procesu analizy wymagań projektowych. Wymagania projektowe opisujące szereg danych dotyczących budowli takich jak przepisy normowe, technologiczne i eksploatacyjne są zapisywane w języku naturalnym i nie nadają się do automatycznego przetwarzania. W technologii BIM opracowano standard IDS, który służy do takiej analizy, ale narzuca, aby wymagania projektowe były zapisane w postaci formuł matematycznych według określonego schematu (jak opisano wyżej). Przełożenie wymagań użytkownika w postaci zdań na sformalizowany zapis zgodny z wymaganiami pliku IDS oraz utworzenie takiego pliku wynikowego to fundamentalne zadanie, które zdecyduje o możliwości automatyzacji kontroli wymagań projektowych dla modelu i praktycznej użyteczności tego rozwiązania. Celem badań było zdobycie wiedzy co do możliwości wykorzystania w tym celu sztucznej inteligencji dla zamiany wymagań opisanych w języku naturalnym na reguły matematyczne.
Za pośrednictwem portalu IDS Maker użytkownik definiuje wymagania w języku naturalnym, które po zatwierdzeniu są przetwarzane przez model AI.
Na etapie wstępnym kontroler w IDS Maker (jednostka, która zarządza akcjami użytkownika po stronie serwera aplikacji) analizuje wymagania i tworzy wewnętrzną, łatwo przekazywalną strukturę danych, a następnie wysyła ją do osobnej aplikacji zarządzającej pracą modeli językowych. Dane zostają przekazane do modelu delegującego, który rozpoznaje rodzaje faset i kieruje je do odpowiednich modeli ze względu na indywidualny typ fasety.
Gdy aplikacja obsługująca modele AI dostaje zapytanie (Request) z IDS Makera, to w łatwy sposób odczytuje strukturę danych w postaci obiektów JSON i mapuje je na własną strukturę. Następnie główny model delegujący (mediator) określa typ fasety i przekazuje każde wymaganie użytkownika do jednego z 6 modeli BIRM (Basic IDS Recognition Model), który specjalizuje się tylko w wyznaczonym typie fasety:

• BIRM_Attribute – do pracy z atrybutami
• BIRM_Classification – do pracy z klasyfikacjami
• BIRM_Entity – do pracy z obiektami IFC
• BIRM_Material – do pracy z materiałami
• BIRM_PartOf – do pracy z relacjami między obiektami IFC
• BIRM_Property – do pracy z właściwościami obiektów

Każdy model obsługuje tylko jeden typ fasety, dzięki czemu udało się uniknąć tak zwanego zjawiska przesycenia (kiedy pewnego typu danych model ma zbyt dużo i skłania się używać ich częściej do generowania odpowiedzi). Podział na 6 modeli pozwala na przetrenowanie jakieś konkretnej jego części, co pozwala uniknąć konieczności przeprowadzenia takiego procesu na wszystkich zasobach od nowa. W ten sposób ponowne wytrenowanie może zostać zrealizowane w krótszym czasie, a w przypadku przerwy w dostawie prądu czy innej awarii, jest szansa, że zanim do tego dojdzie, przynajmniej część z prac zostanie ukończona (a nie zostanie przerwany jeden długi proces).
Do wytrenowania modeli zostało napisane osobne narzędzie AITestDataMaker, które w oparciu o standardy IFC oraz bSDD generuje około 1.2 mln rekordów danych testowych.

Wszystkie modele oprócz mediatora mają identyczną zasadę działania. Wygląda ona następująco:

1. Tekst użytkownika jest dostarczany do odpowiedniego modelu
2. Model analizuje tekst i wyznacza slowa-klucze, następnie przetwarza cały tekst na zestaw wektorów liczbowych i wyznacza ich wagę
3. Model wyciąga kluczowe dane (o ile wystąpiły w tekście użytkownika) i przekształca je na obiekt, który można jednoznacznie przenieść na strukturę IDS
4. Gdy wszystkie obiekty są utworzone, model delegujący strukturyzuje je i wysyła wynik konwersji do IDS Makera.

Po odczycie odpowiedzi modelu używamy mechanizmów do normalizacji oraz uzupełnienia brakujących danych (takich jak np. semantyka nazw klas oraz właściwości czy przypisanie właściwego typu danych dla wartości atrybutów/właściwości).
Gdy użytkownik uzna, że wygenerowany wynik nie spełnia jego oczekiwań i go zmodyfikuje, to w momencie pobrania pliku wszystkie utworzone przez AI specyfikacje zostaną porównane ze stanem początkowym (tuż po wygenerowaniu). Jeśli wystąpią różnice (czyli zmiany wprowadzone przez użytkownika), to zostanie wygenerowany plik z danymi do dalszej ewaluacji modelu.

Znaczenie praktyczne pomysłu

Opisane badania i prace rozwojowe mają znaczenie praktyczne związane z automatyzacją
kontroli wymagań modeli BIM tworzonych w standardzie IFC. Wymagania te mogą być
rozmaite i dotyczą:

• Określenia tolerancji wymiarowych dla elementów konstrukcyjnych, takich jak ściany,
  drzwi i okna.
• Poziomu szczegółowości modelu na różnych etapach projektu.
• Określenia właściwości, które muszą być przypisane do poszczególnych elementów
  modelu, takich jak np. „Fire Rating” dla ścian czy „Acoustic Rating” dla drzwi.
• Definiowania, jak elementy powinny się zachowywać w określonych warunkach,
  np. odporność na ogień, izolacja akustyczna.
• Wymagań dotyczących metadanych, takich jak nazwa producenta, numer katalogowy,
  data instalacji.

Przebieg procesu przetwarzania języka naturalnego modelem BIRM wygląda
następująco:

a. Użytkownik wpisuje swoje wymagania zgodnie z instrukcją – analogicznie do podanych przykładów (lub w przybliżeniu do nich)
b. Informacje wprowadzone przez użytkownika są układane w tablice obiektów w formacie JSON i w takiej formie przesyłane do modelu:

{
"applicabilities":[
"an ifc class \"ifcwindow\"”
],
"requirements":[
"a classification \"MDS-12\" from \"MyClass\" system"
]
}

c. Model delegujący wyznacza typ obiektu (fasety), którego dotyczy warunek i przekazuje konkretne wymaganie do odpowiedniego modelu BIRM

d. Model BIRM wyciąga dane z tekstu i tworzy predefiniowane obiekty, które można użyć do dalszego przetwarzania wymagań użytkownika

{
"Applicabilities": [
{
"T": "entity",
"F1": "simpleValue(ifcwindow)",
"F2": null,
"F3": null
}
],
"Requirements": [
{
"T": "classification",
"F1": "simpleValue(MyClass)",
"F2": "simpleValue(MDS-12)",
"F3": null
}
]
}

e. następnie po stronie aplikacji IDS Maker tworzona jest specyfikacja oraz przypisywane są do niej odpowiednio: Zastosowanie (Applicabilities) i Wymagania (Requirements). W miarę możliwości podejmowane są próby dodawania dodatkowych informacji (datatype, wersja IFC, normalizacja nazw encji oraz formatowanie wartości dla faset Attribute oraz Property).

f. Jako końcowy etap przetwarzania, przedstawiane są użytkownikowi wyniki modelu i jego tekst początkowy. Na tym etapie użytkownik może przyjąć wygenerowaną specyfikację lub wrócić do wprowadzania/edycji danych
g. Wygenerowana specyfikacja jest w pełni edytowalna i pozwala użytkownikowi na modyfikację / dodawanie / usuwanie faset
h. Końcowy efekt przetwarzania wprowadzonego tekstu przez użytkownika na strukturę XML IDS

Model generatora AI, pozwala użytkownikowi na wpisanie reguł w postaci zdań, których treści są przetwarzane i kolejno mapowane na strukturę danych formatu IDS. Model AI wymaga jednak precyzyjnych instrukcji, po to, aby zostały one w dalszej kolejności dobrze zinterpretowane. Właśnie dlatego dla każdej fasety i różnych kombinacji utworzono przykładowe zdania (w jęz. angielskim), które stanowią instrukcję-wzorzec w jaki sposób użytkownik powinien komunikować mechanizmowi swoją wolę.

Każda z rodzaju faset może przekazywać pewien zasób wiedzy. W przypadku fasety Encji może ona odnosić się jedynie do typu IFC elementu w modelu, ale również może zawierać wymaganie dotyczące typu predefiniowanego. Podobnie jest w innych fasetach, tak jak w fasecie Właściwości, Użytkownik może określić samą właściwość z zestawu właściwości, ale może też określić wartość jaką ma ona przyjmować w modelu. W zależności od rodzaju danych jakie ta właściwość określa, spektrum wartości może być różne.
Zobaczmy kilka przykładów z właściwościami o różnych typach danych.
Specyfikacja będzie określać, że zewnętrzne ściany nośne, mają mieć przenikalność cieplną w zakresie 0.10 – 0.20 W/m²K.
Aby użyć sztucznej inteligencji należy więc zapisać, że w zakresie Zastosowania (typ specyfikacji WYMAGANA):
A property “LoadBearing” from “Pset_WallCommon” property set with a value “true”
Jak również: A property “IsExternal” from “Pset_WallCommon” property set with a value “true”
A w zakresie wymagań (rodzaj wymagań MUST HAVE):
A property “ThermalTransmittance” from “Pset_WallCommon” property set with a value greater than or equal to “0.10” and less than or equal to “0.20”

Zakończenie

Opisane rozwiązanie wykorzystujące sztuczną inteligencję do zamiany języka naturalnego na formuły wymagań projektowych w standardzie IDS stanowi znaczący krok w kierunku automatyzacji procesów budowlanych. Dzięki zastosowaniu zaawansowanych technik przetwarzania języka naturalnego (NLP) oraz specjalistycznych modeli AI dedykowanych poszczególnym fasetom, system umożliwia efektywne przekształcanie nieprecyzyjnych wymagań opisanych słownie na ścisłe, matematyczne formuły.
Główne korzyści płynące z tego rozwiązania to:

• Oszczędność czasu i redukcja błędów – automatyzacja procesu weryfikacji wymagań projektowych eliminuje konieczność żmudnej, manualnej analizy, co przekłada się na szybsze i bardziej rzetelne wyniki.
• Zwiększenie zgodności z przepisami – precyzyjne mapowanie wymagań na standard IDS pozwala na dokładniejsze sprawdzanie zgodności projektów z obowiązującymi normami.
• Elastyczność i skalowalność – podział na wyspecjalizowane modele oraz możliwość ich indywidualnego trenowania sprawia, że system można łatwo dostosować do nowych wytycznych lub rozszerzyć o dodatkowe funkcjonalności.

Praktyczne zastosowanie tego narzędzia w procesach BIM, takich jak automatyczna weryfikacja wymagań dotyczących właściwości materiałów, tolerancji wymiarowych czy metadanych, otwiera nowe możliwości dla sektora budowlanego. W przyszłości rozwój podobnych rozwiązań może przyczynić się do dalszej optymalizacji procesów projektowych, skracając czas realizacji inwestycji i podnosząc jakość finalnych projektów.
Wdrożenie technologii AI w budownictwie to nie tylko odpowiedź na obecne wyzwania, ale również inwestycja w przyszłość, gdzie automatyzacja i cyfryzacja staną się standardem w codziennej pracy architektów, inżynierów i innych uczestników procesu inwestycyjnego.

Literatura

1. Blank-Landeshammer, B. (2020). Formalisierung von Bauvorschriften für die automatisierte Überprüfung von BIM Modellen [Diploma Thesis, Technische Universität Wien]. reposiTUm. https://doi.org/10.34726/hss.2021.86597
2. Rohit J. Kate, Yuk Wah Wong, Raymond J. Mooney, Learning to Transform Natural to Formal Languages, Proceedings of the AAAI Conference on Artificial Intelligence, 20, 2005
3. .Iat Tou Leong, Raul Barbosay, Translating Natural Language Requirements to Formal Specifications: A Study on GPT and Symbolic NLP, Conference: 2023 53rd Annual IEEE/IFIP International Conference on Dependable Systems and Networks Workshops (DSN-W)
4. Jaeyeol Song, Jinsung Kim, Jin-Kook Lee, NLP and Deep Learning-based Analysis of Building Regulations to Support Automated Rule Checking System, Pages 586-592 (2018 Proceedings of the 35th ISARC, Berlin, Germany, ISBN 978-3-00-060855-1, ISSN 2413-5844)