„To kontynuacja. Większość wymagań zostaje bez zmian. Powinno pójść szybko.”
Tak sobie powiedzieliśmy na starcie drugiej fazy projektu New Stavanger University Hospital. Wymagania były w większości już napisane, trzeba było je tylko dostosować o wnioski z poprzedniej fazy. Łatwizna.
Nie było łatwo. Dostosowanie ich zamieniło się w pełny audyt properties, zmiany w pliku shared parameters we wszystkich branżach, polowanie na duplikaty, poprawianie konwencji nazewnictwa, rozplątywanie sprzecznej logiki i długie pętle uzgodnień z każdym interesariuszem. Dwa pełne tygodnie sprzątania – i to przy solidnym punkcie wyjścia. Bez porządnych szablonów dołóż kolejne dwa. Pewnie więcej.
Jeśli brzmi to boleśnie znajomo, to dobrze. Znaczy, że też przez to przeszedłeś. To normalne życie w BIM na dużym projekcie.
Tyle że tego dokumentu, tego, który zjadł dwa tygodnie, Twój program do sprawdzania modeli i tak nie przeczyta. Ani Excela. Ani PDF-a. Nic. Więc zanim zwalidujesz choćby jeden model, ktoś musi przetłumaczyć te wymagania jeszcze raz, na jedyny język, który checker rozumie. Nazywa się IDS. A robienie tego ręcznie to najbardziej ogłupiające zajęcie w całym łańcuchu.
Ten wpis jest o oddaniu tej roboty sztucznej inteligencji.
Czym jest IDS - i dlaczego Excel czy PDF nie wystarczą
Dwie krótkie definicje, bo cały wpis się na nich opiera.
LOIN (Level of Information Need) to lista tego, jakie dane ma nieść każdy obiekt i kiedy. Odporność ogniowa na drzwiach, nośność na ścianach, kod klasyfikacyjny na każdym obiekcie. Jest pisany dla ludzi, zwykle jako tabela w Excelu albo proza zakopana w EIR. Czytelny. Sensowny. Bezużyteczny dla komputera.
IDS (Information Delivery Specification) to otwarty standard buildingSMART, który zapisuje te same wymagania w formacie, który checker potrafi uruchomić. Mówi „ta klasa IFC musi nieść tę właściwość, z tą wartością", więc dowolne narzędzie obsługujące IDS, jak Solibri czy usBIM, może to wyegzekwować automatycznie. Jeśli chcesz dłuższą wersję, więcej o tym, czym jest IDS i jak działa.
Więc zadanie jest proste do opisania. Wziąć wymagania napisane przez człowieka i zamienić je w IDS, który czyta komputer.
Proste do opisania. Bolesne do zrobienia.
Dlaczego zamiana tabeli LOIN na IDS tak boli
Wymagania mówią jednym językiem: zwykłym opisem. Raz bardziej szczegółowym, raz mniej, i każdy projekt ma swój ton i układ.
IDS mówi innym: sztywną strukturą zdefiniowaną przez schemę XML. Zagnieżdżone tagi, ostre nawiasy.
Zwykle na projekcie mamy tabele LOIN z kilkuset wierszami wymagań.
Już czujesz ból? Nie?
To Ci powiem, że edytory IDS nie mają (jeszcze) żadnego importu hurtowego. Żadnego kopiuj-wklej. Żadnego łatwego translatora.
A teraz to sobie wyobraź.
Klikanie przez opcje dla KAŻDEGO POJEDYNCZEGO WYMAGANIA. A żeby określić jedno wymaganie, potrzeba minimum 7 kliknięć myszą i 5 pól do wpisania wartości (policzone).
Umieram w środku samym pisaniem o tym.
Więc myślisz: dobra, napiszę ten XML ręcznie. Skopiuję szablon i wpiszę, co trzeba.
Też próbowałem. Zagnieżdżone tagi w zagnieżdżonych tagach w zagnieżdżonych tagach. Jeden nawias w złym miejscu i cały plik jest nieważny. Zrób to dla kilkuset parametrów, a zeżre Ci cały dzień, znudzi na śmierć, i i tak skończysz z trzema literówkami schowanymi gdzieś w środku.
The data side of BIM
Practical AI and BIM workflows. The LOIN to IDS pack comes with the first email.
Rozwiązanie: niech AI napisze XML
Nie powinieneś w 2026 pisać XML-a ręcznie. Maszyna to zrobi.
Więc zbudowałem LOIN to IDS Translator napędzany AI. Bierzesz wymagania, które inwestor przysłał Ci w Excelu, wklejasz je do zwykłego czatu z AI razem z promptem, który już napisałem, i dostajesz z powrotem plik IDS. Taki, który wczytuje się do edytora IDS bez błędu. Około pięciu minut do pierwszego wyniku.
Tak wygląda to tłumaczenie dla jednego wymagania.
Piszesz jeden prosty wiersz w tabeli:
| IFC Class | Property Set | Property Name | Restriction |
|---|---|---|---|
| IfcWall | Pset_WallCommon | FireRating | 30 MIN, 60 MIN, 90 MIN |
AI zamienia to w to:
<ids:specification ifcVersion="IFC4" name="Wall fire rating">
<ids:applicability minOccurs="1" maxOccurs="unbounded">
<ids:entity>
<ids:name><ids:simpleValue>IFCWALL</ids:simpleValue></ids:name>
</ids:entity>
</ids:applicability>
<ids:requirements>
<ids:property dataType="IFCLABEL" cardinality="required">
<ids:propertySet><ids:simpleValue>Pset_WallCommon</ids:simpleValue></ids:propertySet>
<ids:baseName><ids:simpleValue>FireRating</ids:simpleValue></ids:baseName>
<ids:value>
<xs:restriction base="xs:string">
<xs:enumeration value="30 MIN" />
<xs:enumeration value="60 MIN" />
<xs:enumeration value="90 MIN" />
</xs:restriction>
</ids:value>
</ids:property>
</ids:requirements>
</ids:specification>Jeden czytelny wiersz zamienia się w dwadzieścia linii zagnieżdżonych tagów. Teraz pomnóż to przez kilkaset wierszy, i rozumiesz, dlaczego nikt nie robi tego ręcznie.
Dwa bloki robią tu robotę. Blok applicability mówi, których obiektów dotyczy reguła (każdej ściany IfcWall). Blok requirements mówi, co muszą nieść (odporność ogniową z dozwolonej listy).
Dlaczego to działa (i dlaczego sam prompt nie wystarczy)
Wokół AI jest sporo szumu, w naszej branży i wszędzie indziej. Więc bądźmy szczerzy, w czym jest dobre.
AI nie stworzy Ci modelu w Revicie. Nie zaprojektuje za Ciebie, nie sprawdzi budynku i oczywiście go nie zbuduje. Ale jest bardzo dobre w dwóch rzeczach: czytaniu tekstu i strukturyzowaniu danych.
Czym jest EIR? Tekstem.
Czym jest IDS? Ustrukturyzowaną schemą danych.
Bingo.
No i uczciwe pytanie. Skoro to tylko „poproś ChatGPT, żeby napisał Ci IDS", to po co Ci w ogóle pakiet ode mnie?
Bo próbowałem dokładnie tego, i AI dało mi pewne siebie bzdury. Wymyśliło property sety, które nie istnieją. Zmyśliło restriction bases. Wyprodukowało XML, który wyglądał idealnie i wywalał się w momencie wczytania.
Sztuką nie jest sam prompt. Sztuką jest kontekst, który dajesz AI obok promptu. Kilka prawdziwych, poprawnych plików IDS, które pokazują mu, jak wygląda dobrze, plus pusty szablon z dokładną strukturą do wypełnienia. Z takim kontekstem w czacie model przestaje zgadywać. Przetestowałem ten sam układ na Claude, ChatGPT i Gemini, i cała trójka zwraca poprawny IDS, kiedy nakarmisz je plikami kontekstowymi.
To właśnie sprawia, że to więcej niż sprytny prompt. To prompt plus bariery, które nie pozwalają AI odpłynąć.
Jak przekonwertować LOIN na IDS w trzech krokach
Całość jest naprawdę taka krótka.
Krok 1 - Wypełnij tabelę LOIN
Wszystko zaczyna się w tabeli LOIN. Jedno wymaganie na wiersz. Klasa IFC, property set, nazwa właściwości i wartość albo restriction. Jeśli umiesz wypełnić arkusz, umiesz to zrobić. W pakiecie jest gotowy przykład, dziesięć wymagań już rozwiązanych, żebyś zobaczył, jak wygląda dobrze, zanim ruszysz swoje.
Krok 2 - Uruchom prompt
Otwierasz Claude albo ChatGPT. Wklejasz prompt z pakietu, wgrywasz swoją tabelę i dołączasz pliki kontekstowe. Klikasz start i patrzysz, jak pisze XML, którego nie chciałeś pisać. Każdy wiersz z tabeli staje się jedną specyfikacją w pliku. Prompt mówi AI dokładnie, jak zbudowany jest IDS, więc wypełnia strukturę, zamiast ją zmyślać.
Krok 3 - Sprawdź wynik (nigdy tego nie pomijaj)
Zapisujesz wynik z końcówką .ids i wczytujesz prosto do wybranego edytora IDS (polecam usBIM, bo najlepiej radzi sobie z błędami). Jeśli otwiera się bez błędu parsera, struktura jest zdrowa. Potem rzuć okiem na kilka nazw właściwości względem dokumentacji IFC, bo AI od czasu do czasu wymyśli właściwość, która brzmi idealnie i nie istnieje.
Tabela, prompt, sprawdzenie. XML, którego nigdy nie musiałeś dotknąć.
Szczera część: jeden prompt to nie proces
Nie chcę tego przesadnie sprzedawać, bo parzyłem się na narzędziach, które tak robią.
Dwie rzeczy, które musisz usłyszeć.
Po pierwsze, AI dalej halucynuje. Dlatego krok 3 nie jest opcjonalny: zmyślona właściwość, która wygląda dobrze, przejdzie po cichu, aż Solibri się na niej zakrztusi. Dwie minuty sprawdzania biją popołudnie debugowania cichego błędu później.
Po drugie, jeden prompt nie rozwiąże Twojego projektu. Translator radzi sobie z czystymi wymaganiami, schludną tabelą z natywnymi properties. Prawdziwe EIR-y nie przychodzą schludne. Przychodzą jako pięćdziesiąt stron prozy, warunkowe reguły w stylu „akustyka 40 dB w salach spotkań, 30 w biurach", parametry, których nikt nie zdefiniował. Zamiana tego bałaganu w czystą tabelę, mapowanie mglistych słów na natywne klasy IFC, a potem zautomatyzowanie sprawdzeń, żeby chodziły w nocy zamiast Ciebie klikającego Solibri w piątkowe popołudnie, to znacznie większa robota. Jeden prompt Cię tam nie doprowadzi. Proces tak.
Co dalej: te pokręcone EIR-y (i darmowy webinar we wrześniu)
Ten proces właśnie teraz buduję. Krok po kroku, jak pracować z AI nad tym bez oddawania swojego osądu czarnej skrzynce. Cel to dobry wynik przy jak najmniejszej ilości ręcznej, nudnej roboty. Nie AI piszące za Ciebie wymagania, tylko AI robiące nudne tłumaczenie, podczas gdy Ty trzymasz kontrolę i sprawdzasz to, co ważne.
Spędziłem pięć lat po stronie inwestora, budując bazy wymagań na New Stavanger University Hospital, więc wiem, gdzie chowa się bałagan i gdzie AI naprawdę zarabia na swoje miejsce. Prowadzę darmowy webinar o całej ścieżce we wrześniu. Jeśli pokręcony EIR to ściana, o którą ciągle się rozbijasz, to jest ta sesja dla Ciebie.
Pobierz darmowy LOIN to IDS Translator
Na razie LOIN to IDS Translator jest darmowy na datainbim.com. Już teraz oszczędza Ci godziny na czystych przypadkach. Wypróbuj go na własnych wymaganiach i napisz mi, co się wywala. Czytam każdą odpowiedź.
👉👉 Pobierz go za darmo tutaj: datainbim.com
FAQ: LOIN, IDS i AI
Czym różni się LOIN od IDS?
LOIN (Level of Information Need) to czytelna dla człowieka lista tego, jakie dane ma nieść każdy obiekt, zwykle tabela w Excelu albo tekst w EIR. IDS (Information Delivery Specification) to wersja tych samych wymagań czytelna dla maszyny, otwarty standard buildingSMART, który checker taki jak Solibri czy usBIM potrafi uruchomić automatycznie. LOIN to to, co piszą ludzie. IDS to to, co czyta oprogramowanie.
Czy ChatGPT potrafi napisać pliki IDS?
Tak, ale nie niezawodnie sam z siebie. Poproś czat o IDS bez żadnego naprowadzenia, a wymyśli property sety i restriction bases, które wyglądają dobrze i wywalają się przy wczytaniu. Robi się niezawodny, kiedy dasz mu kontekst: prawdziwe, poprawne pliki IDS i pusty szablon do wypełnienia. Z tym Claude, ChatGPT i Gemini zwracają poprawny IDS.
Czy muszę umieć programować, żeby stworzyć plik IDS?
Nie. Jeśli umiesz wypełnić arkusz, stworzysz plik IDS z LOIN to IDS Translatorem. Wpisujesz swoje wymagania jako wiersze w tabeli, AI pisze XML, a Ty sprawdzasz wynik w edytorze IDS. Nigdy nie dotykasz linijki XML.
Jak sprawdzić, czy wygenerowany przez AI plik IDS jest poprawny?
Wczytaj go do darmowego usBIM IDS Editor. Jeśli otwiera się bez błędu na dole, struktura jest zdrowa. Potem sprawdź kilka nazw właściwości względem dokumentacji IFC, bo AI potrafi wymyślić właściwość, która nie istnieje.
Ile trwa konwersja tabeli LOIN na IDS?
Około pięciu minut do pierwszego poprawnego pliku dla czystej tabeli. Ręczna alternatywa, klikanie przez edytor IDS albo pisanie XML-a ręcznie, zajmuje większą część dnia dla kilkuset wymagań.
The data side of BIM
Practical AI and BIM workflows. The LOIN to IDS pack comes with the first email.
