A Building as a Repository: KIR, a Typed Intermediate Representation for Agent-Authored Building Information Models
Dit artikel introduceert KIR, een getypeerde intermediaire representatie die bouwinformatiemodellen behandelt als versiebeheerbare programma's om systematisch zeven specifieke foutmodi in door autonome agenten gegenereerde constructie te detecteren en te representeren, waarbij significante verbeteringen in foutdiagnose en codecompactheid worden aangetoond vergeleken met directe manipulatie van de host-API.
Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer
Stel je een wereld voor waarin de blauwdrukken van onze steden niet slechts statische tekeningen zijn, maar levende instructies geschreven door intelligente softwareagenten. Deze agenten zijn ontworpen om digitale modellen van gebouwen te construeren, laag voor laag, kamer voor kamer, met behulp van complexe software waar architecten en ingenieurs dagelijks op vertrouwen. De uitdaging is dat deze softwareprogramma's zijn gebouwd voor menselijke handen, niet voor autonome machines. Ze reageren op commando's op manieren die vaak onvoorspelbaar zijn: een hulpmiddel kan stilzwijgend falen, een keuze kan worden gemaakt zonder dat er een reden voor wordt vastgelegd, of een cruciaal stuk informatie kan spoorloos verdwijnen. Wanneer een menselijke architect een fout maakt, kan hij de fout zien, de context begrijpen en het herstellen. Wanneer een softwareagent een fout maakt in deze omgeving, kan hij vaak niet vertellen wat er misging, wat hij probeerde te doen, of of het gebouw dat hij heeft gecreëerd daadwerkelijk overeenkomt met het ontwerp dat hem is gegeven. Het resultaat is een systeem waarbij de computer kan beweren dat een taak voltooid is, zelfs als het geproduceerde gebouw gebrekkig of incompleet is.
Dit is het probleem dat een onderzoeker genaamd Dmitry Kuklev probeerde op te lossen. Hij stelde een eenvoudige maar diepzinnige vraag: wat als we deze agenten niet langer vragen om de ruwe code te schrijven die direct met de bouwsoftware communiceert, maar hen vragen om een helder, getypeerd plan te schrijven dat een compiler kan controleren voordat er ook maar iets gebouwd wordt? Het resultaat is een nieuw systeem genaamd KIR. Het behandelt een gebouw niet als een verzameling bestanden, maar als een programma dat in een versiebeheerde repository wordt vastgehouden, vergelijkbaar met een bibliotheek van instructies die gelezen, gecontroleerd en herzien kunnen worden. De kern van het idee is dat voordat een agent probeert een muur te bouwen of een deur te plaatsen, hij eerst exact moet opschrijven wat hij van plan is te doen, en dat een apart systeem moet verifiëren dat het plan deugdelijk is, dat de referenties duidelijk zijn en dat de gevolgen bekend zijn. Als het plan ambigu is, weigert het systeem verder te gaan en legt het precies uit waarom, waarbij het een lijst met mogelijke correcties aanbiedt. Deze aanpak verschuift de last van gissen en hopen naar weten en verifiëren.
De onderzoekers bouwden dit systeem om zeven specifieke manieren aan te pakken waarop een bouwproject fout kan gaan zonder dat iemand het merkt. Op de oude manier zou een agent bijvoorbeeld een specifieke verdieping kunnen proberen te selecteren, maar als twee verdiepingen vergelijkbare namen hebben, zou de software simpelweg de eerste kunnen kiezen die het vindt en doorgaan, waardoor de agent er niet van op de hoogte is dat hij de verkeerde heeft gekozen. In het nieuwe systeem wordt deze ambiguïteit onmiddellijk opgemerkt. Het systeem stopt het proces en presenteert een weigeringsrecord dat het exacte probleem en de beschikbare kandidaten vermeldt, waardoor de agent gedwongen wordt een bewuste keuze te maken. Op dezelfde manier, als een agent een waarde leeg laat, in de verwachting dat de software dit met een standaardwaarde zal invullen, legt het nieuwe systeem exact vast waar deze standaardwaarde vandaan kwam. Het houdt een permanent logboek bij van of een waarde door de agent is geschreven, door een macro is berekend, of door de software zelf is geleverd. Dit creëert een spoor van herkomst (provenance), een geschiedenis van elke beslissing die is genomen bij de constructie van het model.
Om dit idee te testen, creëerden de onderzoekers een gecontroleerde omgeving waarin ze experimenten konden uitvoeren zonder dat de eigenlijke bouwsoftware draaide. Ze bouwden een compiler die het getypeerde plan van de agent neemt en dit controleert tegen een snapshot van een gebouwmodel. In één experiment voerden ze het systeem tweeënveertig verschillende programma's, waarvan sommige opzettelijke fouten bevatten die ontworpen waren om het systeem te breken. Het systeem weigerde tweeentwintig van deze gebrekkige programma's succesvol te verwerken en leverde gedetailleerde diagnostische codes die precies uitlegden wat er mis was. Cruciaal was dat het dit deed zonder vast te lopen of een ongevangen fout te genereren; het stopte simpelweg en legde het probleem uit. Voor de programma's die werden geaccepteerd, genereerde het systeem een enorme hoeveelheid code om in de eigenlijke bouwsoftware uit te voeren. Een enkel gebouwontwerp dat honderd regels instructies nodig had om in het nieuwe systeem te beschrijven, breidde uit tot bijna vier miljoen tekens aan code wanneer het werd vertaald voor de hostsoftware. Dit enorme verschil benadrukt de complexiteit van de onderliggende software en de waarde van een compact, menselijk leesbaar plan dat tussen de agent en de machine staat.
Het systeem introduceerde ook een nieuwe manier van denken over de staat van een bouwproject. In traditionele systemen is een transactie ofwel succesvol, ofwel het faalt. In dit nieuwe systeem is er een derde staat: onbevestigd. Als de software een commando stuurt om een muur te bouwen maar het antwoord gaat verloren of is onduidelijk, raadt het systeem niet of het gelukt is. In plaats daarvan markeert het de actie als onbevestigd en vereist het een specifieke verificatiestap voordat de actie opnieuw kan worden geprobeerd. Dit voorkomt dat het systeem ervan uitgaat dat een bouwelement bestaat wanneer dat wellicht niet zo is. De onderzoekers bouwden ook een "omgekeerd pad" (reverse path), een manier om een voltooid gebouwmodel terug te lezen in de taal van het systeem. Dit proces controleert of elk element in het model kan worden verantwoord. Als het systeem een deel van het gebouw tegenkomt dat het niet kan begrijpen of uitdrukken, laat het dit niet simpelweg vallen; het registreert het als een "atoom" met een specifieke reden voor de fout, zodat geen enkel deel van het gebouw verloren gaat in de vertaling.
De evaluatie van dit systeem was rigoureus. De onderzoekers testten het op een gesimuleerde zestig verdiepingen tellende toren, een complex bouwwerk met honderden verdiepingen en duizenden kolommen. Ze ontdekten dat het systeem het volledige bouwplan in een compact formaat van net iets meer dan elfduizend tekens kon genereren, wat vervolgens uitbreidde naar de benodigde code voor de hostsoftware. Ze testten ook het vermogen van het systeem om conflicten af te handelen wanneer meerdere agenten hetzelfde gebouw proberen te bewerken. Het systeem gebruikt een methode genaamd compare-and-swap, die ervoor zorgt dat als twee agenten tegelijkertijd hetzelfde deel van het gebouw proberen te wijzigen, het systeem het conflict detecteert en weigert de wijzigingen samen te voegen totdat de agenten de onenigheid hebben opgelost. Dit voorkomt het soort datacorruptie dat vaak gebeurt wanneer meerdere mensen aan hetzelfde digitale bestand werken.
De onderzoekers zijn echter voorzichtig in hun verklaring over wat zij nog niet bewezen hebben. Hoewel het systeem perfect werkt in hun offline tests en code genereert die succesvol compileert, hebben ze nog geen gecontroleerde vergelijking uitgevoerd om te zien of agenten die dit nieuwe systeem gebruiken beter zijn in het bouwen van dingen dan agenten die direct code schrijven. Dat experiment staat gepland maar is nog niet uitgevoerd. De huidige resultaten laten zien dat het systeem robuust is, dat het fouten opvangt die anders onopgemerkt zouden blijven, en dat het een duidelijk, inspecteerbaar record biedt van elke genomen beslissing. Het scheidt de geldigheid van het plan van het succes van de uitvoering en de juistheid van het uiteindelijke ontwerp, en behandelt deze als drie afzonderlijke zaken die apart geverifieerd moeten worden.
De betekenis van dit werk ligt in de verschuiving van een model van blinde uitvoering naar een model van bewijsgebaseerde constructie. Door het gebouw te behandelen als een programma dat gelezen, gecontroleerd en herzien kan worden, geeft het systeem autonome agenten de mogelijkheid om over hun eigen acties te redeneren. Het biedt een vocabulaire voor falen, waardoor het systeem kan zeggen: "Ik kan dit niet doen vanwege X", in plaats van simpelweg stilzwijgend te falen. Deze aanpak maakt het proces van bouwen met agenten niet alleen betrouwbaarder, maar ook transparanter en verantwoorder. De onderzoekers hebben aangetoond dat het mogelijk is om een systeem te bouwen waarin de computer weet wat hij doet, waarom hij het doet en wat hij heeft bereikt, waarmee een fundament wordt gelegd voor een toekomst waarin intelligente agenten kunnen samenwerken met mensen om de complexe structuren van onze wereld te ontwerpen en te bouwen. Het werk dient als een demonstratie dat het, met de juiste instrumenten, mogelijk is om de kloof tussen de intentie van een agent en het uiteindelijke resultaat te overbruggen met helderheid en precisie.
Verdrinkt u in papers in uw vakgebied?
Ontvang dagelijkse digests van de nieuwste papers die bij uw onderzoekswoorden passen — met technische samenvattingen, in uw taal.