Piątek po południu, na CDE ląduje nowa rewizja modelu. Clash detection zrobisz od razu. A walidacja danych BIM? Ta poczeka do poniedziałku. Albo do nigdy.
Mniej więcej wiesz, czego chciał klient. Odporność ogniowa na drzwiach, kody klasyfikacyjne na wszystkim, dane materiałowe, z których ktoś dalej w procesie zrobi zamówienie. Wiesz też, że nikt nie otworzył dokumentu z wymaganiami od spotkania kick-off.
Więc co robisz? Puszczasz clash detection, przeklikujesz kilkaset issues, grupujesz je, eksportujesz raport. A dane? Trochę poscrollujesz. Sprawdzisz na wyrywki kilkoro drzwi. I liczysz, że jest dobrze.
Tak wygląda praca wielu BIM koordynatorów, z którymi rozmawiałem. Pokażę Ci, dokąd to prowadzi i co ja robię zamiast tego.
Staliśmy się cyfrowymi woźnymi
Zatrudnili Cię jako inżyniera. Ktoś płaci Ci inżynierską stawkę. A teraz pomyśl szczerze o zeszłym tygodniu: ile z tych godzin poszło na robotę, którą powinna zrobić maszyna?
Chodzi mi o tę mechaniczną część. Przeklikiwanie modelu, żeby go sprawdzić. Przepisywanie błędów do raportu, którego nikt nie poprawi. Wrzucanie i ściąganie modeli z CDE. Poprawianie tagów i literówek, a dwa tygodnie później to samo od nowa.
Rola BIM koordynatora powstała po to, żeby sprzątać bałagan po kimś innym. W większości ręcznie.
Dlaczego walidacja danych BIM zawsze wypada z planu?
Zapytaj na typowym projekcie, co to znaczy sprawdzić model, a usłyszysz jedną odpowiedź: clash detection.
Ale koordynacja BIM to nie tylko clash detection. Obok niego siedzi walidacja danych BIM, czyli sprawdzenie, czy wymagane właściwości w ogóle istnieją i czy mają poprawne wartości. Większość projektów to zaniedbuje.
Dlaczego? Bo clash detection jest łatwy. Nie łatwy do naprawienia. Łatwy do znalezienia. Dwie rzeczy przecinają się w tym samym miejscu, a nie powinny. Nikt nie musi definiować, czym jest kolizja.
Dane są niewidoczne.
Weź dwoje drzwi ze swojego modelu. Jedne mają w środku fire rating, drugie nie. Na ekranie jedne i drugie wyglądają idealnie, a spora część oprogramowania dalej nie pokaże Ci różnicy.
Kolizję widać, więc każdy ją sprawdza. Brakująca właściwość nie wygląda na nic.
Dane nie mają naturalnej definicji błędu. Ktoś musi spisać, jak wygląda "poprawnie", a tym spisanym czymś jest EIR, którego nikt nie przeczytał.
Więc branża sprawdza to, co potrafi złapać, i nazywa to kontrolą jakości.
Ile naprawdę kosztuje brak walidacji danych BIM
Walidacja danych BIM kosztuje czas. Jej brak kosztuje pieniądze, tylko rachunek przychodzi później i do kogoś innego.
Jeśli dane są puste albo błędne, inwestor nie wgra ich do systemu utrzymania przy przekazaniu obiektu. Więc płaci komuś, żeby przeszedł skończony budynek i ręcznie spisał każdy kod i każdą tabliczkę znamionową. Płaci drugi raz za tę samą informację.
Wykonawcy też tracą pieniądze na złych danych. Wyobraź sobie drzwi z obrazka powyżej. Wykonawca policzył drzwi z odpornością ogniową i je zamówił. Ale część drzwi, które powinny mieć tę właściwość, jej nie miała, więc przyjechał zły typ. Kto zapłaci za pomyłkę?
Trzy powody, dla których to się ciągle powtarza
Walidacja danych BIM nie jest trudna technicznie. Rozbija się o trzy inne rzeczy.
Wymagania są nie do przeczytania
Na Nye SUS, nowym szpitalu uniwersyteckim w Stavanger, komplet wymagań BIM to było sześć dokumentów. 146 stron. Ponad dwieście właściwości wymaganych we wszystkich branżach.
Wiesz, co się dzieje z takim dokumentem. Powiedz szczerze o swoim obecnym projekcie: kto przeczytał go dalej niż do dziesiątej strony?
Walidacja danych BIM robi się ręcznie
To jest pułapka klikacza i sam w niej siedziałem latami. Ściągnij modele, zaktualizuj je, poczekaj, popraw rulesety, odpal silnik, znowu poczekaj, oddziel prawdziwe błędy od szumu, pogrupuj je per projektant, wyeksportuj BCF, załóż zadania. A teraz pomnóż to przez kilka tysięcy issues.
Znalezienie tego jednego błędu, który ma znaczenie, wśród trzech tysięcy to szukanie igły w stogu siana. Więc sporo osób odpuszcza i sprawdza model wzrokowo.
Na szpitalu ręczna walidacja danych BIM zajmowała mi 20 godzin co drugi tydzień. Pół tygodnia pracy, w większości bezmyślne klikanie.
Walidacja danych BIM się nie kumuluje
I to właśnie wypala ludzi. Błędy się nie kończą, a nic, co zrobiłeś w zeszłym miesiącu, nie przyspiesza tego miesiąca.
Zapytaj dowolnego BIM koordynatora, w czym chce być lepszy za rok, a dostaniesz dwie odpowiedzi: lepsze procesy i mniej powtarzalnej roboty.
Nikt nie mówi "chcę szybciej klikać".
Więc co się zmieniło w walidacji danych BIM?
Przez lata budowałem te sprawdzenia ręcznie, reguła po regule. Działało, ale było tak wolne i tak kruche, że nikt inny w projekcie nie chciał tego tknąć.
Zmieniły to dwie rzeczy, a wielu BIM koordynatorów i managerów nie korzysta porządnie z żadnej z nich.
Standard, który maszyna potrafi przeczytać
W czerwcu 2024 buildingSMART wypuścił Information Delivery Specification, czyli IDS. Opisuje wymagania w formie, którą oprogramowanie potrafi wykonać, i czyta go większość checkerów modeli IFC. Więcej o tym pisałem tutaj.
Zostaje jeden problem: wyprodukowanie pliku. IDS to XML, a pisanie go ręcznie to męka. Klikanie go w edytorze jest jeszcze gorsze: siedem kliknięć i piętnaście sekund na jedno wymaganie, a w projekcie jest ich co najmniej sto.
Modele językowe, które czytają bałagan i oddają strukturę
Druga nowość przyszła z ChatGPT na początku 2023. AI jest bardzo dobre w dwóch nudnych rzeczach: rozumieniu prozy i strukturyzowaniu danych. Czyli dokładnie w tym, czym jest problem z wymaganiami.
Dlaczego nie można po prostu poprosić ChatGPT o ten plik?
Bo próbowałem, pewnie Ty też, i nie jest to tak proste, jak wygląda na początku. Popsuta składnia i halucynacje podane z pełnym przekonaniem.
Problem polega na tym, że AI jest czarną skrzynką. Wrzucasz dokument i prompt, model coś sobie myśli, wychodzi odpowiedź. Czasem poprawna, czasem bzdura.
W naszej branży nie możemy zadowolić się "całkiem niezłym", bo "drobne" błędy potrafią kosztować miliony (albo i lata więzienia, jeśli coś się zawali...). Musimy być tak blisko pełnej poprawności, jak się da, cokolwiek AI nam wygeneruje.
Odpowiedź jest taka, że AI potrzebuje prowadzenia. Odpowiednie dokumenty i pliki kontekstowe na wejściu, zdefiniowana struktura odpowiedzi i człowiek sprawdzający każdy efekt na wyjściu.
Walidacja danych BIM w trzech krokach: Draft, Verify, Validate
Zbudowałem więc workflow wokół tego, w czym AI jest dobre, i tego, co umożliwia IDS. Zobacz krok po kroku, jak to działa.
AI pisze draft wymagań. Ty je weryfikujesz. Oprogramowanie waliduje model względem nich. Draft i weryfikacja chodzą w pętli, tyle razy, ile trzeba, aż tabela mówi dokładnie to, o co prosił klient. Nic więcej, nic wymyślonego.
Pierwszy krok próbuje już każdy. Drugiego prawie nikt.
Cały workflow na jednym obrazku. Biały to człowiek, szary to plik kontekstowy, czerwony to model językowy, czarny to niezależne narzędzie.
Draft
Do tego kroku wchodzą dwie rzeczy.
Pierwsza to dokument klienta, dokładnie w takiej formie, w jakiej przyszedł. U mnie to był Excel z pomieszanymi wszystkimi etapami i pięcioma czy sześcioma wymaganiami wciśniętymi w jedną komórkę. Bierz jeden etap na raz, bo dane rozwijają się razem z projektem. Ja wziąłem LOIN 200 i resztę zostawiłem w spokoju.
Jeden wiersz, jedna komórka, a w środku cała lista wymagań. Tak zwykle przychodzi dokument od klienta.
Druga rzecz to pliki kontekstowe i to jest ta część, którą ludzie pomijają. Schemat IFC4 i dokumentacja IDS, przerobione na czysty markdown, który model językowy potrafi przeczytać. Bez nich model pracuje z pamięci treningowej, a ta obejmuje tylko słynne właściwości w stylu FireRating czy LoadBearing. Poproś o cokolwiek poza tym, a dziury wypełni własnymi wymyślonymi właściwościami.
Dokumentacja IDS przepisana pod maszynowego czytelnika. Nudna do przygotowania i jednocześnie największy powód, dla którego wynik przestaje być fikcją.
Potem dwa prompty. Pierwszy rozbija dokument: jedno wymaganie na wiersz, nic sklejonego. Moja pojedyncza komórka z wymaganiami dla drzwi zamieniła się w siedemnaście osobnych wymagań.
Te same drzwi po atomizacji. Siedemnaście wierszy, każdy sprawdzalny osobno.
Drugi prompt rozwiązuje każdy wiersz względem słownika IFC4 i zwraca klasę IFC, property set, właściwość i typ danych, plus cytat ze źródła.
Verify
Weryfikacja nie dzieje się w modelu. Dzieje się w pliku, zanim model w ogóle wejdzie do gry.
Wyjaśniam, dlaczego. Błędna właściwość przejdzie każde automatyczne sprawdzenie, jakie masz. Istnieje w schemacie IFC, siedzi na legalnym property secie, plik się parsuje, checker świeci na zielono. Strukturalnie nie ma czego znaleźć. Jedyne, co wie, że wymaganie jest złe, to zdanie, które napisał Twój klient. A tego zdania nie przeczytał żaden program.
Więc to zdanie musi podróżować razem z danymi. Każdy wiersz niesie cytat z dokumentu klienta razem ze stroną, z której pochodzi. Nie streszczenie, tylko własne słowa klienta. Streszczenie możesz przelecieć wzrokiem i pokiwać głową. Ale nie przelecisz wzrokiem cytatu, który stoi obok nazwy właściwości i do niej nie pasuje. A kiedy AI w ogóle nie potrafi takiego cytatu podać, właśnie złapałeś wymyślone wymaganie.
Potem trzy przebiegi.
Pierwszy to skrypt (albo nawet wyszukiwanie w Excelu, jeśli w ogóle nie kodujesz) i jest celowo głupi: sprawdza klasy IFC, property sety i właściwości względem schematu, i nie ma zdania na żaden inny temat. Reguły napisane przez człowieka, raz spisane, działają zawsze.
Drugi przebieg to znowu AI i wiem, jak to brzmi. AI sprawdzające AI to przepis na piętrzenie błędów. Ale to AI dostaje zdanie klienta z jednej strony, wybraną właściwość z drugiej i jedno zadanie: udowodnić, że te dwie rzeczy nie znaczą tego samego. Niczego nie zmienia, podaje tylko swoje uzasadnienie.
To, co do Ciebie dociera, jest krótkie: wiersze wyłapane przez oba przebiegi, a nie 146 stron. I to jest trzeci przebieg, ten ludzki. Musisz przejrzeć to, co dostałeś, albo dokładnie, albo wyrywkowo. To jest ręczne i zajmuje czas, wiem. Weryfikacja nigdy nie będzie jednym kliknięciem. Ale to jest najtańsze miejsce, żeby ubrudzić sobie ręce.
Validate
Z pierwszych dwóch kroków wychodzi plik IDS. Ostre nawiasy, namespace'y, zagnieżdżone schematy. Brzydki kod, jeśli mnie pytasz.
Sprawdzasz, czy plik się otwiera, zanim w ogóle podejdziesz do modelu. Potem wrzucasz go do checkera IFC. Jeśli Twoje narzędzie w ogóle nie czyta IDS, lepiej dowiedz się tego w tym tygodniu, a nie w dniu, w którym klient Ci taki plik przyśle.
Tu zaczyna się właściwa walidacja danych BIM, ta w modelu. Upload, sprawdzenie, założenie issues, eksport BCF. Zwykła procedura koordynacyjna.
A teraz część, która oddaje godziny. Żadne z tych kliknięć nie musi być moje. Solibri automatyzuje się przez Autorun: XML, który mówi programowi, co ma zrobić, i mały plik batch, który to odpala. Ten XML należy do tej samej rodziny schematów co IDS, więc jego też pisze AI, z dokumentacją Solibri Developer Platform jako plikiem kontekstowym.
Potem to chodzi w nocy, a raport leży na moim biurku rano. I tak dwadzieścia godzin co drugi tydzień zamieniło się w jakieś dwie. Narzędzia są specyficzne dla Solibri, ale sam kształt tego procesu już nie.
Jeśli chcesz zobaczyć, jak przechodzę przez to od początku do końca, z wyjaśnieniami, gotowymi promptami i plikami kontekstowymi, na prawdziwym dokumencie, to właśnie tego uczę na kursie. Zajrzyj na dół 👇
Podsumowanie
AI nie naprawi Twojego klienta i błędy nie przestaną przychodzić tylko dlatego, że mamy teraz modele językowe. Zmienia się Twoja pozycja w tej pracy.
IDS i LLM-y zmieniają to, co jest tu możliwe, ale żadne z nich Cię nie usuwa. Draft bywa jednocześnie pewny siebie i błędny, więc weryfikacja zostaje po Twojej stronie. Jeśli na raporcie ma być Twoje nazwisko, sam czytasz cytaty, zanim plik dotknie modelu.
Zrób to raz, a praca zacznie się kumulować. Reguły napisane w tym miesiącu dalej działają w następnym, a w poniedziałek czytasz raport zamiast go produkować. Tak właśnie walidacja danych BIM przestaje być piątkową harówką i staje się procesem, który chodzi sam.
Któregoś piątkowego popołudnia na CDE wyląduje kolejna rewizja. Albo otworzysz ją ręcznie i będziesz liczyć, że jest dobrze, albo sprawdzenie już się wykonało i raport na Ciebie czeka.
Przestajesz być osobą, która sprawdza modele, i stajesz się osobą, która ustawiła sprawdzanie.
The AI Data Validation System
Kurs na żywo o workflow opisanym powyżej: bierzemy dokument z wymaganiami Twojego klienta, zamieniamy go w plik IDS, którego umiesz obronić, i ustawiamy sprawdzenie, które samo chodzi na Twoim modelu. Zostaje Ci prompt book, szablony, pliki kontekstowe i referencyjne, mapa procesu weryfikacji oraz gotowe pliki Solibri Autorun.
Zbudowane na trzech miesiącach pracy na pełen etat nad samym procesem, na bazie pięciu lat walidacji danych BIM na szpitalu o powierzchni 125 000 m², zrealizowanym bez rysunków.
