Ik Vroeg GPT-4 of een Balkon Veilig Was. Het Zei Ja. De Fysica Zei Dat het Zou Instorten.

Er ligt een rendering op mijn bureau — een afdruk eigenlijk, want ik wilde ernaar staren zonder een scherm tussen ons in — van een uitkragend balkon. Strakke lijnen, een parametrische balustrade, precies het soort ding dat je zou zien in een architectuurtijdschrift over "de toekomst van stedelijk wonen." Ik voerde het beeld aan GPT-4V en stelde een simpele vraag: Is deze constructie veilig?

Het antwoord was vloeiend, zelfverzekerd en gedetailleerd. Het merkte de schijnbare hoogte van de balustrade op, becommentarieerde de zichtbare steunomstandigheden en concludeerde dat het ontwerp "constructief solide lijkt met adequate ondersteuning."

Toen gaf ik dezelfde tekening aan mijn constructeur. Ze keek er misschien vijftien seconden naar. "Er is geen achtervelden-wapening," zei ze. "Het moment aan het ingeklemde uiteinde overschrijdt de capaciteit van de doorsnede. Dit valt."

De AI zag pixels. Zij zag fysica. En die kloof — tussen wat er veilig uitziet en wat veilig is — is de reden waarom ik Veriprajna ben begonnen.

De Verleiding van "Goed Genoeg"

Ik moet eerlijk zijn over iets. Toen multimodale LLM's voor het eerst technische tekeningen begonnen te verwerken, was ik enthousiast. Oprecht enthousiast. Ik herinner me dat ik op een avond laat in ons kleine kantoor zat, de ene bouwtekening na de andere door vroege GPT-4V-toegang haalde, en toekeek hoe het constructie-elementen beschreef met verrassend vocabulaire. "Stalen I-profiel," zei het dan. "Gewapend betonnen kolom." Het klonk alsof het het begreep.

Dat enthousiasme duurde ongeveer drie weken.

Het keerpunt was een test die we uitvoerden op verbindingsdetails — de knopen waar liggers kolommen ontmoeten, waar de daadwerkelijke lastoverdracht plaatsvindt. We gaven het model een reeks tekeningen waarin sommige verbindingen correct waren uitgewerkt en andere subtiele maar kritieke gebreken hadden: ontbrekende schotplaten, te kleine lassen, onderbroken krachtenpaden. Het soort dingen dat een gebouw dat overeind blijft onderscheidt van een gebouw dat dat niet doet.

De nauwkeurigheid van het model bij het identificeren van deze gebreken was in wezen willekeurig. Het kon de componenten benoemen. Het kon beschrijven wat het zag. Maar het kon niet redeneren over de vraag of de krachten daadwerkelijk van punt A naar punt B zouden stromen. Het was alsof je iemand die de namen van elk bot in het menselijk lichaam uit zijn hoofd had geleerd, vroeg om een operatie uit te voeren.

Een AI die elk constructie-element kan benoemen maar geen krachtenpad kan traceren, is geen technisch hulpmiddel. Het is een risico met een zelfverzekerde stem.

Waarom Zien LLM's Bouwtekeningen als Pixelbrij?

Dit is wat er werkelijk onder de motorkap gebeurt, en het is belangrijk, zelfs als je niet technisch bent.

Wanneer GPT-4V of Gemini "kijkt" naar een constructietekening, gebruikt het iets dat een Vision Transformer heet. Het model hakt het beeld in stukken tot een raster van kleine fragmenten — doorgaans 16×16 pixels elk — en verwerkt ze als een reeks, vergelijkbaar met hoe het woorden in een zin verwerkt. Het leert statistische associaties tussen fragmenten. Een fragment met een verticale lijn (kolom) verschijnt meestal in de buurt van een fragment met een horizontale lijn (ligger). Over miljoenen trainingsbeelden heen worden deze correlaties ingebakken.

Maar hier komt het cruciale onderscheid: correlatie is geen oorzakelijkheid. Het model leert dat kolommen en liggers meestal samen voorkomen. Het leert niet dat de ligger gedragen wordt door de kolom. Het weet niet dat als je de kolom verwijdert, de ligger valt. Het heeft geen interne fysica-engine. Het heeft patroonstatistiek.

Onderzoek van NeurIPS toonde iets aan dat iedereen die overweegt deze modellen in te zetten voor veiligheidskritisch werk zou moeten alarmeren: wanneer je de pixelfragmenten van een beeld door elkaar husselt — ze letterlijk schudt als een kaartspel — behouden Vision Transformers vaak een hoge classificatienauwkeurigheid. Ze lezen de ruimtelijke structuur niet. Ze lezen textuur en lokale patronen.

In de techniek is ruimtelijke structuur alles. Een verbindingsdetail dat "grotendeels aanwezig" is maar een cruciaal krachtenpad mist, is niet 90% veilig. Het is 100% onveilig.

Wat Gebeurt Er Als Je LLM's Daadwerkelijk Benchmarkt op Constructief Redeneren?

Ik bleef hopen dat de benchmarks me ongelijk zouden geven. Dat deden ze niet.

De DSR-Bench-studie evalueerde tien state-of-the-art LLM's over 4.140 probleeminstanties die waren ontworpen om structureel redeneren te testen — het vermogen om complexe relaties tussen entiteiten te begrijpen en te manipuleren. Dit is precies wat je nodig hebt om een gebouwconstructie te analyseren: relaties traceren door meerdere knopen, strikte randvoorwaarden voldoen, redeneren over ruimtelijke configuraties.

Het beste geavanceerde model scoorde 0,498 van de 1,0 op uitdagende instanties. In wezen een muntworp.

De faalwijzen waren specifiek en vernietigend. Multi-hop-redeneren — het traceren van een relatie door verschillende tussenliggende knopen, wat letterlijk is wat krachtenpadanalyse vereist — was een consistente zwakte. En de prestaties gingen achteruit wanneer problemen in natuurlijke taal werden beschreven in vergelijking met formele code, wat suggereert dat de modellen syntaxis matchten uit hun trainingsdata in plaats van daadwerkelijk te redeneren.

Ik herinner me de teamvergadering waarin we deze cijfers doornamen. Een van mijn ingenieurs, die voorzichtig optimistisch was geweest over het gebruik van LLM's als eerste-fase screeningsinstrument, werd lange tijd stil. Toen zei hij: "Dus wanneer een ingenieur een niet-standaard constructief probleem in gewoon Nederlands beschrijft, gokt het model in feite de helft van de tijd." Dat was het moment waarop de stemming in de kamer omsloeg. Niet geleidelijk — in één keer.

Los daarvan bleek uit de DesignQA-benchmark dat multimodale LLM's "Wat is de maximaal toegestane doorbuiging?" konden beantwoorden (een getal uit documentatie halen) maar faalden bij "Voldoet dit specifieke liggerontwerp aan de maximaal toegestane doorbuiging?" (dat getal toepassen op een visueel beeld). Extractie versus toepassing. De regel kennen versus de regel handhaven.

Ik heb over deze faalwijze veel diepgaander geschreven in de interactieve versie van ons onderzoek, inclusief de bizarre voorkeuren bij materiaalkeuze die we vonden — LLM's die titanium en koolstofvezel aanbevelen voor contexten die duidelijk om standaard constructiestaal vroegen, simpelweg omdat exotische materialen de "high-tech" hoeken van hun trainingsdata domineren.

Het Moment Waarop We Stopten met Proberen LLM's te Repareren

Er was een investeerdersvergadering — ik zal niet zeggen welk bedrijf — waar iemand naar ons vroege onderzoek keek en zei: "Waarom fine-tune je GPT niet gewoon voor constructie-engineering? Lijkt de snellere weg."

Ik begreep de logica. Neem het dominante paradigma, specialiseer het, breng het uit. Maar ik had lang genoeg naar dit probleem gestaard om te weten dat het fine-tunen van een probabilistisch model om deterministisch werk te doen, is als het fine-tunen van een dichter om rekenwerk te doen. Je kunt ze zover krijgen dat ze getallen produceren. Je kunt ze er niet toe brengen te garanderen dat de getallen kloppen.

De wetten van de fysica zijn niet probabilistisch. Als de som van krachten op een constructie-element niet gelijk is aan nul, versnelt het element. Er is geen "meestal" bij. Er is geen betrouwbaarheidsinterval. De Euler-Bernoulli-liggervergelijking geeft niets om de verdeling van jouw trainingsdata.

Dus namen we een besluit dat destijds tegendraads aanvoelde en nu voor de hand liggend voelt: we lieten het beeld volledig los.

Niet de AI — het beeld. We stopten met proberen neurale netwerken bouwtekeningen als plaatjes te laten begrijpen. In plaats daarvan begonnen we gebouwen om te zetten in wat ze werkelijk zijn: wiskundige grafieken.

Een gebouw is geen beeld. Het is een netwerk van krachten. Op het moment dat je het als pixels behandelt, ben je de fysica al kwijt.

Hoe Zet Je een Gebouw Om in een Grafiek?

Een grafiek is, in de wiskundige zin, gewoon knopen en randen. Knopen zijn dingen; randen zijn verbindingen tussen dingen.

In ons systeem wordt elk constructie-onderdeel — ligger, kolom, vloerplaat, wand — een knoop. Maar in tegenstelling tot een pixel, die alleen kleurgegevens draagt, draagt elk van onze knopen een rijke feature-vector: elasticiteitsmodulus (hoe stijf het materiaal is), traagheidsmoment (hoe de doorsnede weerstand biedt tegen buiging), vloeigrens (wanneer het materiaal bezwijkt). De daadwerkelijke fysische parameters die je nodig hebt om te berekenen of iets overeind blijft of valt.

Elke fysieke verbinding tussen componenten wordt een rand. Een rand tussen een ligger en een kolom legt de verbindingsstijfheid vast — is het een stijve momentverbinding of een eenvoudige scharnierverbinding? — en de relatieve oriëntatie. Dit zijn geen aangeleerde benaderingen. Ze worden rechtstreeks onttrokken aan BIM-gegevens (Building Information Modeling), waar de connectiviteit expliciet is gedefinieerd.

Deze representatie heeft een eigenschap die enorm belangrijk is: permutatie-invariantie. De fysica van een gebouw verandert niet als je de lijst met liggers in de database herordent. Graph Neural Networks respecteren dit. Transformer-gebaseerde LLM's, die reeksen verwerken, zijn gevoelig voor de invoervolgorde. Het klinkt als een technisch detail, maar het is het verschil tussen een architectuur die is afgestemd op het probleem en een die ertegen vecht.

We bouwden een pijplijn die IFC-bestanden — het standaardformaat voor BIM-gegevens — omzet in rekengrafieken. Waar een LLM zou proberen de bouwtekening als beeld te "lezen" en verbindingen zou gokken, legt onze parser de connectiviteit vast met 100% getrouwheid, omdat het IFC-schema deze expliciet definieert. Geen gegok. Geen "het lijkt erop dat deze elementen verbonden zijn." Ze zijn het ofwel wel, ofwel niet.

Het Deel Waarin We Neurale Netwerken Fysica Leerden

Hier wordt het interessant, en hier denk ik dat we iets werkelijk anders doen.

Standaard machine learning werkt zo: toon het model veel voorbeelden, laat het patronen leren, hoop dat het generaliseert. Het probleem in de constructie-engineering is dat "hoop dat het generaliseert" geen aanvaardbare veiligheidsnorm is.

Physics-Informed Neural Networks — PINN's — hanteren een fundamenteel andere aanpak. In plaats van de AI te vragen fysica te ontdekken uit data, bedden we de bepalende vergelijkingen rechtstreeks in in de verliesfunctie van het netwerk. De verliesfunctie is datgene wat het netwerk tijdens de training probeert te minimaliseren — het is de definitie van "fout" die het leren aandrijft.

In een standaard neuraal netwerk betekent "fout" "je voorspelling komt niet overeen met de trainingsdata." In een PINN voegen we een tweede definitie van "fout" toe: "je voorspelling schendt de wetten van de fysica."

Neem de Euler-Bernoulli-liggervergelijking, die bepaalt hoe een ligger onder belasting doorbuigt. Wanneer ons netwerk een doorbuigingsvorm voorspelt voor een constructie-element, gebruiken we automatische differentiatie om het fysische residu te berekenen — waarbij we in wezen vragen: "Voldoet deze voorspelde doorbuiging aan de differentiaalvergelijking van statisch evenwicht?" Zo niet, dan schiet de fysica-verliesterm omhoog, en wordt het netwerk gedwongen zichzelf te corrigeren.

Het netwerk kan letterlijk geen oplossing leren die de wetten van Newton schendt. Niet "waarschijnlijk niet." Kan niet.

Ik herinner me de eerste keer dat we dit aan de praat kregen op een niet-triviale constructie. We hadden wekenlang geworsteld met convergentieproblemen — het fysica-verlies en het data-verlies vochten met elkaar, en het netwerk oscilleerde. Mijn hoofd-ML-ingenieur had op kantoor geslapen (ik zei hem dat niet te doen; hij negeerde me). Toen riep hij me op een ochtend bij zijn scherm. De voorspelde doorbuigingscurves waren op één lijn geschoten met de FEM-oplossing (Finite Element Method). Niet bij benadering. De R²-waarde was 0,9999.

We hadden iets gebouwd dat de snelheid van AI en de precisie van traditionele engineeringsolvers had. Recent onderzoek naar Graph-Structured Physics-Informed DeepONets — de architectuurklasse waarop we voortbouwen — heeft 7–8x snelheidswinst ten opzichte van traditionele FEM aangetoond, met behoud van dat nauwkeurigheidsniveau. Voor de volledige technische uitwerking van onze architectuur en benchmarks, inclusief de wiskunde achter ons message-passing-framework, heb ik een gedetailleerd onderzoekspaper gepubliceerd.

Kun Je Daadwerkelijk Zien Waar een Gebouw Zal Bezwijken?

Dit is de vraag waar ingenieurs het meest om geven, en hier wordt grafiekgebaseerde analyse voelbaar krachtig.

In ons systeem controleren we niet alleen of een constructie als geheel slaagt of faalt. We traceren het primaire krachtenpad — de route die krachten afleggen vanaf het aangrijpingspunt (zeg maar mensen die op een balkon staan) omlaag door de constructie naar de fundering.

We doen dit met een maatstaf die de U*-index heet, die de interne rekenergie-overdracht en de relatieve stijfheid tussen punten in kaart brengt. Met Runge-Kutta-integratie op de U*-gradiënt tekenen we "stroomlijnen" van kracht door de constructie — als een weerkaart, maar dan voor belastingen in plaats van wind.

Wanneer een constructie veilig is, stromen de stroomlijnen continu van het belaste element omlaag naar de fundering. Wanneer dat niet zo is — wanneer er een verbinding ontbreekt, een element te klein is, een krachtenpad onderbroken is — eindigen de stroomlijnen abrupt of divergeren ze wild.

Terug naar die balkonrendering op mijn bureau. Toen we die door onze grafiekpijplijn haalden, stopte de krachtenpad-stroomlijn van de uitkragende vloerplaat gewoon... op. Er was geen achtervelden-verbinding om het moment de dragende constructie in te voeren. De U*-contour toonde een enorme concentratie van rekenergie aan het ingeklemde uiteinde met nergens heen te gaan. De visualisatie maakte de faalwijze duidelijk op een manier die geen enkele hoeveelheid pixelanalyse ooit zou kunnen.

Een krachtenpad-stroomlijn die eindigt, is een zin die de constructie schrijft over haar eigen dood. Je moet alleen weten hoe je de grafiek moet lezen.

We kunnen ook progressieve instorting simuleren — wat er gebeurt wanneer je een kolom verwijdert en vraagt "houdt de rest van de constructie stand?" — door systematisch knopen uit de grafiek te verwijderen en de connectiviteit opnieuw te evalueren. Met maten als betweenness-centraliteit identificeren we kritieke clusters van componenten waarvan het bezwijken de grafiek in losgekoppelde stukken zou splitsen. Deze "graph attack"-simulatie draait in seconden. De equivalente niet-lineaire FEM-instortingsanalyse duurt uren. We kunnen duizenden faalscenario's screenen voordat een ingenieur zijn koffie op heeft.

Waarom Niet Gewoon Allebei Gebruiken? De Verifier-laag

Mensen brengen altijd tegen dit punt in. "Ashutosh, generatieve AI is ongelooflijk voor ontwerp in een vroege fase. Dat kun je niet zomaar negeren." En ze hebben gelijk — ik wil het niet negeren. Architecten die tools als Midjourney of parametrische generatoren gebruiken om creatieve concepten te verkennen, is oprecht spannend. Het probleem is niet het genereren. Het is de verificatie.

Wat we hebben gebouwd, is een Verifier-laag. Het generatieve model stelt een ontwerp voor. Veriprajna zet het om in een grafiek, controleert de topologische connectiviteit, traceert het krachtenpad, voert de fysica-geïnformeerde voorspelling uit. Als de fysicacontrole faalt, retourneren we een harde randvoorwaarde — geen suggestie, een randvoorwaarde: "Verhoog de liggerhoogte met 200 mm" of "Voeg een achtervelden-verbinding toe." Het generatieve model genereert opnieuw binnen die grenzen.

Creativiteit begrensd door fysica. Verbeelding geverifieerd door wiskunde. Dat is de werkwijze.

En omdat onze modellen begrensd worden door fysicavergelijkingen in plaats van getraind op het hele internet, zijn ze opmerkelijk data-efficiënt. Een PINN die is getraind op stalen frames generaliseert naar nieuwe stalen frames, omdat de wet van Hooke niet verandert tussen projecten. Dit betekent ook dat de modellen klein genoeg zijn om on-premise in te zetten. Geen enkele klant hoeft bouwtekeningen van gevoelige infrastructuur naar een publieke API te sturen.

De Glazen Doos vs. De Zwarte Doos

Er is nog één ding dat me 's nachts wakker houdt over LLM-gebaseerde engineeringtools, en dat is niet nauwkeurigheid — het is verklaarbaarheid.

Wanneer een Graph Neural Network een voorspelling doet over een constructie-element, kunnen we precies visualiseren welke naburige knopen die voorspelling hebben beïnvloed via attention-gewichten. "De kolom werd gemarkeerd omdat de gecombineerde belasting die vanuit Ligger A en Ligger B werd overgedragen zijn capaciteit overschreed." Dat is een traceerbare, auditeerbare redeneerketen. Een ingenieur kan ernaar kijken en zeggen: "Ja, dat klopt" of "Nee, je hebt het toebehorende oppervlak verkeerd geteld." Ze kunnen in discussie gaan met het model.

Probeer maar eens in discussie te gaan met GPT-4's redenering over een constructiebeoordeling. Vraag het waarom het concludeerde dat het balkon veilig was. Je krijgt een vloeiende alinea die redelijk klinkt maar naar niets verwijst dat je kunt verifiëren. De redenering is verdeeld over miljarden parameters op manieren die geen mens kan inspecteren.

In software is een zwarte doos een ontwerpkeuze. In de constructie-engineering is een zwarte doos een afwijzing van verantwoordelijkheid.

De Fundamentele Vraag

Ik heb in genoeg vergaderzalen en investeerdersvergaderingen gezeten om te weten dat de huidige AI-hype in de bouw vrijwel volledig over generatieve modellen gaat. De pitchdecks zijn schitterend. De demo's zijn indrukwekkend. De onderliggende aanname — dat je je een weg naar constructieve veiligheid kunt pixel-voorspellen — is fout.

De bouwsector is uniek onder alle sectoren op één cruciale manier: onze bugs doden mensen. Een softwarebug is een patch. Een constructiebug is een instortingsonderzoek, een rechtszaak, een gedenkteken. De marge voor "waarschijnlijk goed" is nul.

We bouwden Veriprajna op grafentheorie, geometrisch deep learning en differentiaalvergelijkingen, omdat dat de enige fundamenten zijn die deterministische antwoorden bieden op veiligheidsvragen. Niet "het ziet er veilig uit." Niet "op basis van vergelijkbare constructies in onze trainingsdata is dit waarschijnlijk adequaat." Maar: het fysische residu is nul, het krachtenpad is continu, de spanning valt binnen de capaciteit.

GPT-4 vertelde me dat dat balkon veilig was omdat het duizenden foto's van balkons had gezien, en in die foto's bleven de pixels van de vloer meestal boven de pixels van de grond. Fysica vertelde me dat het zou instorten, omdat het buigmoment aan het ingeklemde uiteinde de momentcapaciteit van de doorsnede overschreed.

Ik weet op welke van de twee ik voortbouw.