Czy można ufać AI w sprawie właściwości IFC? 4 sposoby, w jakie je zmyśla

Oczywiście możesz dodawać do IFC własne właściwości. Robił to każdy projekt, przy którym pracowałem, a Revit, ArchiCAD, Tekla i inne programy eksportują zestawy właściwości użytkownika (tutaj jak to zrobić w Revicie). Jest tylko jedna zasada. Prefiks Pset_ jest zarezerwowany dla zestawów właściwości zdefiniowanych w standardzie IFC. Swój zestaw możesz nazwać prawie dowolnie, ale nie Pset_Cokolwiek. Dokumentacja IFC mówi to wprost: każdy zestaw zaczynający się od Pset_ musi być zestawem standardowym, z odpowiednimi właściwościami przypisanymi do odpowiednich obiektów.

I właśnie tę zasadę łamie AI. Podaje ci nazwę zaczynającą się od Pset_, zbudowaną dokładnie jak standardowa, której nie znajdziesz nigdzie w standardzie. Ani to zestaw standardowy, ani poprawny zestaw własny. Podróbka z oficjalną pieczątką.

Innymi słowy: własne właściwości są w porządku. Podrobione standardowe już nie.

Dlaczego ma cię to obchodzić? Bo podróbka wędruje dalej. Trafia wszędzie tam, gdzie użyto tej odpowiedzi:

• Projektant jednej branży mapuje ją w ustawieniach eksportu IFC i model zaczyna nieść „standardowy” zestaw, który nie powinien istnieć. Inny projektant mapuje to poprawnie. Efekt? Dwie właściwości opisujące to samo: chaos w danych, pomnożony przez tysiące właściwości i miliony obiektów.
• Koordynator BIM wpisuje ją do BEP albo tabeli LOIN, a projektanci zaczynają szukać zestawu właściwości, który nie istnieje.
• Projektant pyta chatbota, w której właściwości umieścić wymaganie, dostaje pewną siebie nazwę z Pset_ i ręcznie dodaje ją do modelu.
• Reguła sprawdzająca w twoim programie do koordynacji albo w pliku IDS szuka jej i nie znajduje nic, do czego mogłaby się przyczepić. Zielony raport. Nic nie zostało sprawdzone.

We wrześniu pisałem, że AI pracujące na własnej pamięci wypełnia luki wymyślonymi właściwościami. Ten artykuł pokazuje, jak te luki wyglądają. Każdy przykład poniżej pochodzi z moich własnych testów, które robiłem, przygotowując kurs The AI Data Validation System.

Jak IFC przechowuje właściwości, w dwie minuty

Jeśli znasz serię Sekrety formatu IFC (część 1, część 2, część 3) i artykuł Właściwości w IFC, możesz pominąć tę część. Dla wszystkich pozostałych minimum, które trzeba znać:

• Klasa mówi, czym jest obiekt: IfcWall, IfcDoor, IfcPipeSegment.
• Zestaw właściwości (property set) grupuje właściwości. Pomyśl o rozdziałach w książce albo arkuszach w pliku Excel.
• Właściwość (property) to jedna informacja w zestawie: FireRating, LoadBearing, IsExternal.

Standardowe zestawy właściwości nie wiszą w powietrzu. Każdy należy do konkretnych klas. Pset_WallCommon trafia na ściany, Pset_FootingCommon na stopy fundamentowe. Przypisz właściwość okna do fundamentu, a ta kombinacja przestaje być poprawna, nawet jeśli każda pojedyncza nazwa jest prawdziwa.

Klasy tworzą drzewo genealogiczne. Ściana jest na samym dole tej linii: IfcRoot > IfcObjectDefinition > IfcObject > IfcProduct > IfcElement > IfcBuildingElement > IfcWall. Część tych klas to klasy abstrakcyjne, a pozostałe to klasy konkretne. Abstrakcyjne są na przykład IfcElement i IfcBuildingElement: grupują obiekty, ale żaden obiekt w twoim modelu nigdy nie będzie jedną z nich. Twoja ściana to IfcWall - to klasa konkretna. (W IFC 4.3 IfcBuildingElement zmieniono na IfcBuiltElement, idea ta sama.)

Teraz skala. Schemat IFC4 jest OGROMNY! Nawet jeśli zawęzimy go tylko do zestawów i właściwości, wciąż zostaje około 3000 kombinacji! Jako zwykły tekst to ponad 100 000 tokenów. Zapamiętaj tę liczbę, jeszcze do niej wrócimy.

Dlaczego AI je zmyśla?

1. To statystyka, a nie wiedza

Model językowy niczego nie sprawdza. Przewiduje najbardziej prawdopodobne kolejne słowo na podstawie wszystkiego, co przeczytał podczas treningu. Wyobraź sobie absolwenta, który przeczytał każdą normę w bibliotece, ale nigdy nie otworzył przeglądarki IFC. Zadajesz pytanie i dostajesz płynną, pewną siebie odpowiedź, zbudowaną z tego, co zwykle występuje razem.

Przez większość czasu to wystarcza. W IFC „zwykle występuje razem” nie znaczy „istnieje”.

Przykład: Pset_WallCommon, Pset_DoorCommon i Pset_BeamCommon są prawdziwe. Gemini pociągnął ten wzorzec o krok za daleko i wymyślił Pset_BuildingElementCommon, przypisany do IfcBuildingElement. Trafiło tam siedem wymagań: LoadBearing, IsExternal, Status, FireRating, ThermalTransmittance, AcousticRating i Infiltration. Dwa błędy w jednym wierszu. Ten zestaw właściwości nie istnieje w IFC4, a IfcBuildingElement jest klasą abstrakcyjną, więc żaden obiekt w twoim modelu nigdy nią nie będzie. Sprawdź model pod tym kątem, a dostaniesz zero problemów. Siedem wymagań, których nikt nie sprawdził.

2. Zna słynne właściwości i wstawia je wszędzie

FireRating, LoadBearing i IsExternal pojawiają się wszędzie: w dokumentacji, na forach, w tutorialach na YouTube i w BEP-ach dostępnych w internecie. Model widział je tyle razy, że dokleja je niemal do wszystkiego.

Przykład: IsExternal i FireRating w Pset_FootingCommon. Prawdziwy zestaw zawiera trzy właściwości: LoadBearing, Reference i Status. W tym samym teście LoadBearing trafiło do zestawów właściwości okien, drzwi, posadzki i sufitu podwieszanego. Czyli według AI sufit podwieszany utrzymuje budynek. Spoiler: nie utrzymuje 😉

3. Problem igły w stogu siana

Pamiętasz te 100 000 tokenów? Twoje wymaganie to jedno krótkie zdanie (igła), a duży model językowy musi dopasować je do jednej z około 3000 kombinacji, w których mnóstwo nazw różni się jednym słowem: Pset_PipeSegmentTypeCommon, Pset_PipeFittingTypeCommon (stóg siana). Nawet ze schematem przed oczami łatwo o pomyłkę. Tak działa AI - szukanie igły w stogu siana to powszechny i dobrze znany problem. Skrypt filtrujący znalazłby ją w mgnieniu oka, ale AI ma z tym ogromny kłopot.

Przykład: wymaganie brzmiało „ciśnienie nominalne” dla rur. Dla IfcPipeSegment Gemini odpowiedział Pset_PipeFittingTypeCommon.PressureClass. Prawdziwa właściwość w prawdziwym zestawie, ale ten zestaw należy do kształtek, a nie do odcinków rur. Dobra rodzina, zły obiekt. W tym samym teście strumień świetlny trafił do oprawy oświetleniowej przez Pset_LampTypeCommon, czyli zestaw należący do źródła światła.

4. Klasy abstrakcyjne są na początku listy

Kiedy pierwszy raz dałem modelowi schemat IFC razem z klasami abstrakcyjnymi, zaczął się ku nim skłaniać, po prostu dlatego, że były bliżej początku listy. To kolejna cecha AI - tokeny na początku i na końcu dają najsilniejszy sygnał.

Zaczął więc klasyfikować tak: ściana? No cóż, to element budowlany. Okno? Też element budowlany. Fundament? To samo. Wiesz, o co chodzi. Pset_BuildingElementCommon z punktu 1 pokazuje to samo przyciąganie: wymyślony zestaw na klasie, której nie da się zamodelować. Procesy inżynierskie, takie jak narzędzia do sprawdzania czy modelowania, potrzebują klasy konkretnej. Z klas abstrakcyjnych korzystają głównie programiści.

Co więc robić?

Te nawyki pomagają już teraz, niezależnie od tego, do czego używasz AI.

1. Pozwól na „nie wiem”. Napisz w prompcie, że „nie ma standardowej właściwości dla tego wymagania” to poprawna odpowiedź i że wolisz ją od zgadywania. Bez tej zgody model zawsze coś znajdzie. W jednym z moich testów AI odpowiedziało na wymaganie tak: PROJECT-DEFINED: requires Custom_System with system reference properties. To uczciwa odpowiedź, a do tego poprawna: własny zestaw, uzgodniony w BEP, bez prefiksu Pset_.
2. Proś o cytat ze źródła w każdym wierszu. Zdanie klienta, słowo w słowo, obok właściwości wybranej przez AI. Gdy cytat mówi „ciśnienie nominalne rur”, a właściwość siedzi na kształtce, widzisz to w sekundę. A gdy AI nie potrafi niczego zacytować, najpewniej właśnie wyłapujesz wymyślone wymaganie.
3. Sprawdzaj w schemacie, nie w AI. Pytanie tego samego modelu „jesteś pewien?” kończy się uprzejmym „tak”. Zamiast tego otwórz dokumentację buildingSMART, znajdź zestaw właściwości i sprawdź, do jakich klas się odnosi. Przy kilku wierszach to dwie minuty na wiersz. Przy całej tabeli potrzebujesz automatycznego sprawdzenia i właśnie to robi krok Verify w mojej metodzie Draft, Verify, Validate. Jeśli chcesz zobaczyć, o ile lepiej AI radzi sobie z odpowiednimi plikami kontekstowymi, pokazałem pierwszą wersję w artykule LOIN to IDS.

Nadja, uczestniczka pierwszej edycji kursu, ujęła to tak:

„Bardzo mi się podobało, że to nie jest tylko »oto twój wynik«, ale też weryfikacja - dodam tę część do innych rzeczy, które buduję z AI.”

Podsumowanie

AI nie zna IFC. Zna to, jak IFC zwykle wygląda, i każdą lukę wypełnia czymś, co brzmi standardowo. Własne właściwości są w porządku - tylko nie zaczynaj ich nazw od Pset_.

Chcesz sprawdzić AI na własnych wymaganiach, z odpowiednimi zabezpieczeniami? Zapisz się po darmowy LOIN to IDS Translator.

I napisz w komentarzu: jaką najdziwniejszą właściwość podało ci AI? 🙂