Jak zbudowałem harness, który czyta model budynku

Modele 3D się marnują.

Projektanci i tak je tworzą. W pliku jest mnóstwo odpowiedzi: ile metrów kwadratowych szkła ma elewacja albo ile betonu siedzi w ścianach piwnicy. Potem model trafia do zamawiającego i zwykle na tym koniec.

Większość ludzi, którzy mogliby z modelu korzystać, nie jest jego autorem. Inwestor, generalny wykonawca, kosztorysant, inspektor nadzoru. Ich firmy często nie mają programu, w którym mogłyby ten plik otworzyć. A nawet gdy plik da się otworzyć w darmowej przeglądarce, odpowiedź na proste pytanie o ilość wymaga kogoś, kto wie, w którym zestawie parametrów jej szukać. Decyzje zapadają więc znowu na podstawie PDF-ów i ręcznie przepisywanych zestawień, a kiedy czegoś w nich brakuje, ktoś pisze maila do projektanta i czeka.

Ten problem nie jest nowy i najwięcej kosztuje właścicieli budynków. W Stanach Zjednoczonych straty z powodu złej wymiany danych między firmami i programami wyceniono w 2004 roku na 15,8 mld dolarów rocznie. Dwie trzecie tej kwoty płacą właściciele i zarządcy, głównie w czasie eksploatacji. Dziesięć lat później 68% amerykańskich właścicieli, którzy realizowali projekty w BIM, oceniało swoją zdolność do wykorzystania modelu po zakończeniu budowy jako żadną albo niską. Model powykonawczy trafia do zamawiającego przy odbiorze, ale rzadko ktoś po jego stronie umie z niego sprawnie korzystać, więc BIM żyje głównie w projekcie i na budowie. W Polsce BIM wciąż stosuje mniejszość branży. W badaniu Kantar dla Autodesk z 2023 roku projekty w BIM realizowało 41% firm projektowych, 37% inwestorów i tylko 21% firm budowlanych. Inwestorzy jako barierę najczęściej wskazywali małą liczbę specjalistów od BIM (86%).

„70% [branży zajmuje się] produkcją modeli, ale tylko około 15% korzysta z BIM.”

Lars Christiansen, były współprezes buildingSMART International, o rynku skandynawskim (McGraw Hill Construction, 2014, tłum. własne)

Dziś przyjmuje się, że do czytania modelu potrzeba skomplikowanego narzędzia i specjalisty. Uważam, że nie musi tak być. Model można po prostu zapytać. Agent AI znajduje właściwe dane, liczy je i pokazuje, skąd ma wynik.

Chciałem to sprawdzić w praktyce: wrzucić plik IFC do przeglądarki, zobaczyć model w 3D i zapytać go po polsku. Tak powstał prototyp, który opisuję w tym wpisie.

Co zbudowałem

Najpierw krótkie demo na modelu biurowca.

Upuszczasz plik IFC. Po kilku sekundach widzisz model w 3D, a obok okno rozmowy z agentem. Pytasz zwykłym językiem, na przykład o powierzchnię przeszkleń na każdej kondygnacji. Agent odpowiada tabelą z liczbami. Pod odpowiedzią widać zapytania, z których te liczby pochodzą, a w modelu podświetlają się dokładnie te elementy, które policzył.

Pytanie o beton do kosztorysu. Po prawej odpowiedź i jej źródła, po lewej policzone elementy w modelu.

Słowo „harness” pożyczam z inżynierii agentów. Oznacza wszystko, co otacza model językowy: co widzi na starcie, jakie dostaje narzędzia, czego mu nie wolno i jak sprawdza się jego odpowiedzi.

Sam model językowy jest tu wymienny. Wybieram go z listy w interfejsie: przy szkole pracował Claude Sonnet 5, a przy biurowcu tani DeepSeek V4.1 Flash. W filmie odpowiada właśnie DeepSeek: każda odpowiedź przychodzi po 2 do 7 sekundach i kosztuje najwyżej około centa. Do takiej pracy nie trzeba sięgać po najdroższe modele językowe w rodzaju Claude Opus. To, czy odpowiedź nadaje się do kosztorysu, zależy od harnessu, a nie od inteligencji modelu.

Celowo piszę, że agent czyta model. Słowo „rozumie” byłoby na wyrost. Agent nie widzi bryły, nie wie, co z czym sąsiaduje, nie szuka kolizji. Czyta dane, które w modelu są, tak jak czyta je projektant, który otwiera zestawienie. Czego w danych nie ma, nazywa luką. To skromniejsza obietnica, ale każdą liczbę da się sprawdzić.

Pięć założeń

Agent dostaje mapę modelu

Model biurowca, na którym testowałem prototyp, miał ponad 240 MB i prawie 228 tysięcy właściwości. Tego nie da się wkleić do rozmowy z modelem językowym. A nawet gdyby się dało, pytania o ilości wymagają arytmetyki, a nie czytania.

Dlatego serwer zaraz po wgraniu pliku zamienia go w bazę danych. Agent dostaje do rozmowy tylko kartę modelu: jakie są klasy elementów i kondygnacje, jakie parametry występują, jakie wartości w nich realnie stoją i czego brakuje. Szczegóły pobiera sam, zapytaniami do bazy. Trochę jak nowa osoba w biurze, która nie uczy się projektu na pamięć, tylko dostaje spis treści i dostęp do zestawień.

Każda liczba ma źródło

Agent ma jedną twardą regułę: każda liczba w odpowiedzi musi pochodzić z zapytania wykonanego w tej rozmowie. Bez szacowania i bez „około”. Każde takie zapytanie widać pod odpowiedzią jako „Źródło odpowiedzi” albo „Narzędzie”. Można je rozwinąć i przeczytać.

Źródło odpowiedzi o przeszklenia: jedno zapytanie, cztery wiersze, po jednym na kondygnację.

Po odpowiedzi aplikacja jeszcze raz przechodzi po liczbach (pomija małe liczby całkowite i procenty) i sprawdza, czy każda ma pokrycie w wynikach zapytań, z tolerancją na zaokrąglenie. Jeśli tak, pod odpowiedzią pojawia się znacznik „Liczby zgodne z zapytaniami”. Jeśli nie, aplikacja wypisuje liczby bez pokrycia. To sprawdzenie działa po fakcie i niczego nie blokuje. Traktuję je jak czujnik, nie jak bramkę, i wolę to powiedzieć wprost.

Odpowiedź widać w modelu

Baza danych i przeglądarka 3D używają tego samego identyfikatora elementu. Dzięki temu wynik zapytania od razu zapala się w modelu, a reszta budynku przygasa. Tabela mówi, ile. Model pokazuje, które. Zaufanie do liczby rośnie, kiedy można ją zobaczyć.

Działa to też w drugą stronę. Kliknięcie w element otwiera jego kartę z parametrami, kondygnacją i pomieszczeniem, w którym stoi. Z karty można od razu zapytać agenta o ten element.

Biurowiec przycięty do pierwszego piętra. Jedno kliknięcie w krzesło i karta z jego danymi.

Ciężka praca raz, geometria u użytkownika

Od początku zależało mi, żeby to nie było zasobożerne. Geometrię liczy przeglądarka użytkownika, biblioteką skompilowaną do WebAssembly, więc serwer nie wydaje na nią ani sekundy procesora. Serwer analizuje plik raz, w osobnym procesie, który po pracy oddaje pamięć. Potem zapytania do bazy trwają zwykle poniżej milisekundy.

W liczbach: model szkoły z tego wpisu (44 MB, 4,5 mln trójkątów) rysuje się w przeglądarce w około 3 sekundy. Analiza biurowca (242 MB) zajęła serwerowi 15 sekund. Pytania o szkołę obsłużył Claude Sonnet 5: odpowiedź o przeszklenia trwała 63 sekundy i kosztowała 0,09 USD, a o beton 39 sekund i 0,06 USD. Pytania o parter i pierwsze piętro biurowca zadałem modelowi DeepSeek V4.1 Flash. Przy pierwszych testach trafiały do najtańszych dostawców tego modelu: każda odpowiedź zajmowała około minuty i kosztowała od 0,001 do 0,002 USD. Po zmianie ustawień (najszybszy dostawca zamiast najtańszego) ten sam model odpowiada w filmie po 2 do 7 sekundach, a odpowiedź kosztuje od 0,004 do 0,011 USD.

Agent tylko czyta

Agent może pytać bazę, ale nie może zmieniać danych modelu. Pilnuje tego kod, a nie prośba w instrukcji: do bazy przechodzą wyłącznie zapytania odczytujące dane. Jedyne, co agent może zapisać, to wpis do słownika projektu, i to dopiero po zgodzie użytkownika. Brakujących informacji nie dopowiada. Jeśli czegoś w modelu nie ma, mówi to wprost i wskazuje, których danych brakuje.

Dwa pytania do modelu szkoły

Zrzuty w tym wpisie pochodzą z modelu koncepcji szkoły w Kibeho, którą pokazuję w portfolio, i z modelu biurowca. Model szkoły to eksport z Revita do IFC2X3: 5525 elementów na czterech kondygnacjach. Jest koncepcyjny, co za chwilę będzie miało znaczenie.

Ile jest szkła

Pierwsze pytanie brzmiało: „Jaka jest powierzchnia przeszkleń na każdej kondygnacji?”.

W tym modelu nie ma ani jednego okna (elementu klasy IfcWindow). Przeszklenia to panele ścian kurtynowych. Agent sam do tego doszedł: znalazł 454 panele szklane, zsumował ich powierzchnię (1 516,79 m²) i rozbił ją na kondygnacje. Osobno wskazał trzy świetliki dachowe. Nie dodał ich do sumy i napisał dlaczego: model podaje dla nich powierzchnię w rzucie, a nie rzeczywistą powierzchnię skośnego przeszklenia. Dopisał też, skąd wziął powierzchnię paneli. Pochodzi z parametru Revita, bo standardowych ilości IFC z powierzchnią dla tej klasy w pliku nie ma.

Odpowiedź o przeszklenia. Świetliki dachowe agent pokazał osobno i nie dodał ich do sumy.

Ta odpowiedź podoba mi się bardziej niż sama liczba. Agent zrobił to, co zrobiłby uważny człowiek: zanim zaczął liczyć, sprawdził, jak w tym konkretnym pliku zapisano szkło, a na koniec powiedział, czego nie wliczył.

Ile betonu do kosztorysu

Drugie pytanie zadałem tak, jak mógłby je zadać kosztorysant: „Potrzebuję betonu do kosztorysu. Ile m³ mają ściany i stropy konstrukcyjne na każdej kondygnacji?”.

Agent zaczął od ustalenia, co w tym modelu jest konstrukcją. Wziął ściany i stropy, których typ ma w nazwie „Structural_Concrete” albo „Slab_Structural”. Pominął tynki, lekkie ścianki działowe i podest schodów. Wynik: 3 505,39 m³ betonu w 384 elementach, z podziałem na kondygnacje.

Pod tabelą dopisał uwagi. Dwie z nich kosztorysant powinien przeczytać przed liczbą. Objętość brutto ma tylko 217 z 384 elementów, więc użył objętości netto. Materiał we wszystkich warstwach to generyczny „Koncepcyjny Czarny”, więc model nie zna klasy betonu.

Odpowiedź o beton. Najważniejsze są uwagi pod tabelą.

Kosztorys jest tak dobry jak model

Tu chcę się zatrzymać, bo tu leży granica całego pomysłu.

Agent policzył beton, bo projektant nazwał typy ścian tak, że da się z nich odczytać konstrukcję i materiał. Gdyby te same ściany nazywały się „Ściana 1” i „Ściana 2”, agent nie miałby się czego złapać. Materiał nic mu nie podpowie, bo w modelu koncepcyjnym jest tylko roboczym oznaczeniem. Klasy betonu nie ma nigdzie, więc do wyceny i tak potrzebny jest człowiek.

Druga rzecz wychodzi dopiero w 3D. Długi, wygięty pas przed budynkiem jest w modelu stropem konstrukcyjnym 300 mm. Agent policzył go jak każdy inny strop, więc ten beton jest wliczony w wynik. Czy słusznie, wie tylko projektant. Agent liczy to, co jest w modelu, a nie to, co ktoś miał na myśli. Dlatego podświetlenie traktuję jako część odpowiedzi: po jednym spojrzeniu widać, co trafiło do sumy.

Trzecią rzecz aplikacja pokazuje, zanim padnie pierwsze pytanie. Karta modelu mówi wprost, że w tym pliku nie ma pomieszczeń, więc pytania o ich powierzchnie nie zadziałają. Cztery klasy elementów, w tym schody, nie mają wyeksportowanych ilości.

Karta modelu. Uwagi o brakach w danych są widoczne przed pierwszym pytaniem.

W modelu biurowca agent sam zgłosił 112 ścian gipsowo-kartonowych oznaczonych jako zewnętrzne i 107 krzeseł bez przypisanej kondygnacji. Narzędzie nie naprawi modelu. Może za to szybko pokazać, czego w nim brakuje, zanim ktoś oprze na nim kosztorys.

Jeśli model ma służyć do przedmiaru, z pracy nad tym prototypem wynika dla mnie kilka prostych wymagań:

• typy elementów nazwane tak, żeby było z nich widać funkcję i materiał,
• prawdziwe materiały zamiast roboczych oznaczeń,
• ilości (BaseQuantities) wyeksportowane dla wszystkich klas, które mają trafić do kosztorysu,
• elementy przypisane do kondygnacji,
• pomieszczenia w modelu, jeśli pytania mają dotyczyć powierzchni.

Nic z tego nie jest nowe dla kogoś, kto pracuje w BIM. Nowe jest to, że agent w minutę pokazuje, który z tych punktów w danym pliku kuleje.

Drugi model: biurowiec

Szkoła to model koncepcyjny, więc sprawdziłem też biurowiec: 7049 elementów i 26 pomieszczeń. Plik nie ma ani jednej kondygnacji IFC, więc aplikacja odtwarza je z parametrów Revita. Budynek przycinałem przekrojem do jednej kondygnacji, a pytania o parter i pierwsze piętro zadawałem tańszemu modelowi, DeepSeek V4.1 Flash.

Parter w przekroju

Przekrój zostawia w modelu tylko wybraną kondygnację i odsłania jej wnętrze. Na parterze widać ścianki, schody i meble.

Biurowiec przycięty przekrojem do parteru.

Na pytanie „Jakie pomieszczenia są na parterze i jaką mają powierzchnię?” agent sam ustalił, który poziom w tym pliku jest parterem, i odpowiedział tabelą 14 pomieszczeń z numerami, nazwami i powierzchniami, razem 508,08 m². Odpowiedź zajęła niecałą minutę i kosztowała 0,002 USD. Pomieszczenia zapaliły się w modelu jako półprzezroczyste bryły na tle wnętrza.

Pomieszczenia parteru, które zsumował agent, na tle wnętrza kondygnacji.

Odpowiedź DeepSeek V4.1 Flash. Na dole nazwa modelu językowego, czas i koszt odpowiedzi.

Pierwsze piętro

Kolejne pytanie: „Ile krzeseł jest na pierwszym piętrze?”. Tu też najpierw ustalił, która kondygnacja jest pierwszym piętrem, i znalazł 24 krzesła w trzech pomieszczeniach. Liczy przy tym to, co model zapisał jako krzesło. Taborety zamodelowane razem ze stolikami są w tym pliku częścią stolika, więc do tej liczby nie wchodzą.

Pierwsze piętro w przekroju. 24 krzesła, które policzył agent, na tle wnętrza.

Beton w ścianach klatki schodowej

Trudniejsze pytanie dostał już Claude Sonnet 5: „Ile m³ betonu mają ściany klatki schodowej?”. W modelu jest pomieszczenie „Staircase”, ale przy żadnej ścianie nie zapisano, że do niego należy. To pytanie o położenie, a agent nie widzi geometrii.

Agent nie podał od razu liczby. Napisał, że model nie łączy ścian z klatką schodową, i wypisał, czego mu brakuje. Pomylił się przy tym w jednym zdaniu: napisał, że żadne pomieszczenie nie nazywa się klatką schodową, choć „Staircase” w modelu jest. Znacznik zgodności tego nie wyłapie, bo sprawdza liczby, nie zdania.

Kiedy poprosiłem, żeby sprawdził ściany trzonu, znalazł 12 ścian oznaczonych jako „structural core”, zaczynających się na trzech poziomach, i zapytał, czy ma je policzyć. Po „tak” podał 229,47 m³ żelbetu, a razem z izolacją i tynkiem 279,19 m³. Sprawdziłem to w bazie i wynik zgadza się co do setnej.

Agent nie był pewien, czy te ściany tworzą jeden trzon, i zaproponował, żebym sprawdził to w 3D. Wystarczyło jedno spojrzenie: to ciągły trzon od fundamentu po dach. Czy cały trzon to klatka, czy klatka razem z szybem windy, rozstrzygnąłby projektant. Taki podział pracy mi odpowiada. Agent liczy i mówi, czego nie wie. Człowiek patrzy i potwierdza.

12 ścian trzonu policzonych po dopytaniach. W 3D od razu widać, że tworzą jeden ciągły trzon.

Czego to nie robi

• Nie widzi geometrii. Wie, w którym pomieszczeniu stoi element, tylko jeśli model to zapisał. Nie wywnioskuje tego z położenia i nie powie, co z czym sąsiaduje ani gdzie są kolizje. Pytania o położenie, jak to o klatkę schodową, wymagają człowieka i widoku 3D.
• Nie porównuje wersji modelu.
• Duże modele obciążają pamięć komputera użytkownika. Biurowiec (242 MB) to 11,6 mln trójkątów w przeglądarce, więc potrzebny jest mocny komputer.
• Działa tylko na moim komputerze. To wciąż prototyp.

Nie każde pytanie musi też iść przez agenta. W aplikacji jest zwykły panel z drzewem klas: klikam w stropy i od razu dostaję ich liczbę na kondygnacjach, sumy ilości i materiały, bez modelu językowego. W poprzednim wpisie pisałem, że czasem nudny kawałek zwykłego software'u jest lepszym wyborem niż agent. Tutaj jest tak samo. Agent jest od pytań, do których nie znam drogi.

Czy to ma sens poza moim biurkiem?

Modele i tak powstają, a ich odczytanie nie musi wymagać specjalistycznego programu. Prototyp w minutę odpowiada na pytania, przy których sam przekopywałbym się przez zestawienia znacznie dłużej. Nie wiem jeszcze, czy to narzędzie, czy ciekawostka. Tego nie rozstrzygnę sam przy biurku.

Dlatego pytam. Czy widzicie w tym wartość w swojej pracy? Jakie pytanie zadalibyście swojemu modelowi jako pierwsze? A jeśli macie model IFC i chcielibyście sprawdzić to na nim, napiszcie do mnie. Chętnie przejdę przez taki test razem z wami.