Hvordan kan AI bruges med LCAbyg
PoC for JSON byggevare lavet af AI
Disclaimer
*Dette er et PoC, Proof of Concept, indlæg.*
Intro
Jeg selv siddet en del med LCA-beregninger over forskellige faser og noget som er blevet mere relevant og en større del af workflowet er projekt-specifikke byggevare, at oprette byggevare fra EPD’er. Af alle de forskellige objekter i LCAbyg, synes jeg personligt byggevare er det mest tidskrævende.
I min undersøgelse af LCAbyg-templates og -biblioteker, har jeg også sat mig ind i JSON-formatet, her skal det siges at ikke havde noget forud viden omkring JSON, men her efter 1,5 måned har jeg et nogenlunde overblik over logikken i det. Dette kommer dels også fra at LCAbyg har lavet en rigtig fin JSON-guide i det tilfælde af man skulle have lyst til at give sig i kast med det.
Men hvorfor snakke så meget om JSON i et indlæg som skulle handle om AI? Jo, det fordi AI er VIRKELIG god til at håndtere JSON og generere det.
Så i led med at byggevare var det mest tidskrævende at lave, min research af LCAbyg programmet og min interesse for AI, gik jeg i gang med at undersøge og eksperimentere med om jeg kunne få en AI til at lave en JSON-byggevare komponent ud fra en EPD. Det er jeg nu lykkes med.
Som vi kan se i det lille billedserie, har jeg uploadet en EPD i min chat, derefter generer AI’en en byggevare JSON fil klar til download.
Jeg importerer derefter JSON filen og programmet registrere den nye byggevare. Jeg har for en sikkerhedsskyld anonymiseret producenten af byggevareren, men vi ser der i byggevaren er de tre faser, A1-A3, C3 og C4, med alle værdierne udfyldt, derefter er der blot tilbage at udfylde mængde og levetid for byggevaren og mængden for konstruktionen og nu kan vi se aftrykket.
Det tekniske og min proces i at opsætte et system hvor det “1-shot-promt” virker.
For at forstå hvordan man kan få noget som dette til at virke, er det essentielt vi først forstår nogle forskellige ting.
- JSON (meget overordnet og overfladisk forståelse)
- Hvordan arbejder LCAbyg med JSON (Datastrukturen af LCAbyg)
- AI vidensbase
JSON-delen
Meget overordnet og overfladisk fortalt, JSON, som står for JavaScript Object Notation, er et letvægtsformat til lagring og overførsel af data. Under ses et meget simpelt eksempel:
“JSON er en måde at gemme og sende information på, så computere nemt kan læse og forstå det.
Forestil dig, at du har en masse information, du gerne vil gemme – for eksempel om din yndlingsfilm:
- Titel: Harry Potter
- År: 2001
- Skuespillere: Harry, Hermione, Ron
JSON hjælper med at skrive det sådan, at en computer kan forstå det, lidt ligesom en opskrift:
{
"titel": "Harry Potter",
"år": 2001,
"skuespillere": ["Harry", "Hermione", "Ron"]
}Det ligner lidt en blanding af dansk og kode. Der er nøgler (som “titel”) og værdier (som “Harry Potter”). Det er super smart, fordi det er nemt for både mennesker og computere at læse. ” Skrevet af AI
For at få det fulde overblik over hvordan JSON arbejder i LCAbyg, anbefaler jeg at læse LCAbyg’s egen JSON guide, som trinvis går igennem alt man behøver at vide.
AI-delen
Hvad skal der så til for at få en AI til at kunne lave denne her JSON fil for os?
Her er vi først nødt til at have en forståelse af hvad der sker når vi “spørger” en AI om noget eller rettere sagt, når vi giver en promt. Når en AI genererer tekst, sker det ikke ved at “tænke” eller “vide noget” i traditionel forstand. I stedet er det et resultat af sandsynlighedsberegning og mønstergenkendelse på baggrund af en MASSE data. Her er en trinvis forklaring på, hvordan det fungerer:
AI’en (som GPT-modellerne fra OpenAI) bliver trænet på enorme mængder tekst fra internettet, bøger, artikler, dialoger osv. Formålet er ikke at lære fakta, men at lære sproglige mønstre og sammenhænge. Under træningen lærer modellen f.eks., at hvis man starter en sætning med “København er hovedstaden i”, så er “Danmark” en sandsynlig fortsættelse. Når du stiller et spørgsmål eller giver en prompt, analyserer AI’en de ord, du skriver, og prøver at forudsige det næste mest sandsynlige ord, ét ad gangen.
Simplificeret så har en AI, kun viden fra det data den er trænet på, det vil også sige at der hvor en AI er skarpest, er indenfor den viden som der ligger i den data den er trænet på. Det vil også sige at en model ikke kan have viden om ting der sker i realtid, et begreb der bruges her er “knowledge cuttoff” Al viden og alle begivenheder efter denne dato kender den ikke, medmindre du oplyser det manuelt. Her er det også vigtigt at vide at jo mere niche specifik et output man vil have desto mere vil det være nødvendigt at manuelt vedlægge viden om det man vil snakke om.
Da LCAbyg er meget niche specifikt, har det derfor været nødvendigt for mig at jeg “fodre” AI’en med information om hvad LCAbyg er og JSON-guiden til LCAbyg, så den kan opnå bedre sandsynlighed i dens mønstergenkendelse, da jeg ønsker et MEGET specifikt output. Med download af JSON-guiden til LCAbyg, oplyser de også eksempler på hvordan JSON-objekterne skal opbygges, disse eksempler har jeg også fodret AI’en med.
Sidst men ikke mindst, så har jeg taget allerede eksisterende byggevare fra LCAbyg og eksporterede dem, hvorefter jeg har gennemgået JSON-strukturen, og ud fra dette har jeg lavet en “V3 Template product_A1-3_C3_C4” som er hele en byggevares JSON-fil uden værdierne udfyldt. Denne template er det jeg har fortalt AI’en at den skal bruge hver gang den skal lave en ny byggevare ud fra en EPD. Den vil derfor ikke selv skulle opfinde strukturen, men blot inputtet værdierne den læser fra EPD’en. Denne template har jeg lavet i VScode, hvori jeg også har skrevet noter til hver enkelt felt i forhold til om værdien kan variere eller skal være noget specifikt, hvis den varierer har jeg skrevet en note til hvor specifikt den kan findes eller hvad den værdi specifikt hedder.
Mit valg af AI
Det firma jeg har valgt at gå med er Anthropic’s modeller Claude. Jeg gennemgik helt i starten et lille eksperiment, hvor jeg researchede en masse modeller og afprøvede de forskellige af i deres gratis version. Her havde jeg en fornemmelse af at output fra Claude var en smule mere “on-point” uden nogen ekstra viden, men det burde i det store hele i gøre den store forskel, eftersom at man altid kan tilføje ekstra viden, i det omfang der er nødvendigt, for at få samme resultat.
For at få dette til at fungere, har jeg som forrigt nævnt, skulle fodre modellen med en masse viden, i Claude’s pro plan får man adgang til det der hedder “Projects”, hvor man vedhæfte en masse data, som modellen vil være præ-fodret med i hver chat startet i det project. Dette princip er også at finde hos andre firmaers modeller i betalte planer. Så det er ikke fordi man skal føle sig tvunget til at bruge Claude, hvis man som firma allerede har et abonnement hos noget andet, men man skal kunne være i stand til at lave en base med ekstra viden modellen skal være informeret om i hver ny chat.
Begrænsninger
Dette er et PoC (Proof of Concept) oplæg, hvor jeg viser og forklarer noget at processen og mine tanker bag. Det virker og jeg er super tilfreds! Det virkelig fedt at kunne gå fra manuelt at gennemgå en EPD og indtaste værdier en for en, til blot at kunne uploade EPD’en i en Chat og få et færdigt og brugbart produkt ud, vel og mærke uden errors!
Men…
Nogle udfordringer jeg stadig bokser med er Usage limit og Context Window/Token limit.
Lad mig starte med at forklare hvorfor Token limit er et problem. Token limit i en samtale handler om, hvor meget tekst (input + output) der kan være i en enkelt interaktion eller samtale med en sprogmodel, før man løber tør for “plads”, en enkelt chat kan derfor kun være så omstændig som Token grænsen tillader for den enkelt model og den tilkøbte plan. Det vil sige at når jeg uploader en PDF konverteres hele indholdet af PDF’en til tekst og bruger deraf Tokens. Dette problem kan løses med “Information Extraction (IE)” jeg vil lave et indlæg omkring dette når jeg selv har fået sat det op. Ideen med det går ud på at trække det specifikke tekst ud af en PDF som vi skal bruge og lagre det i tabel i fx. et excel ark.
Det næste problem jeg støder på er Usage limit. Usage limit refererer til de begrænsninger, der er sat på, hvor meget du må bruge af en tjeneste – typisk målt i antal anmodninger, tokens eller andre ressourcer – inden for en given tidsperiode. Hvad jeg oplever med Claude er, at jeg kan uploade en EPD og få en byggevare ud 5 gange indenfor en kort periode før jeg rammer min Usage limit og derefter må vente 5 timer før jeg kan chatte med Claude igen. Ud fra hvad jeg har researchet mig til kan man promte igennem API’er, hvor man her har en “wallet” og betaler per million tokens brugt. Det skal dog siges at når jeg får sat IE op og deraf ikke skal uploade hele EPD’er men kun den specifikke information AI’en skal bruge, nedsætter jeg betragteligt mine tokens og vil deraf kunne lave mange flere end 5 byggevare i streg.
Afrunding
Så er vi ved vejs ende, jeg håber det har været interessant at læse med, det har uden tvivl været en af mine mere tekniske indlæg sammenlignet med størstedelen af mine andre indlæg som har været mere begyndervenlige og introducerende. Jeg har prøvet at holde det kort og konkret uden at miste kontekst, men med noget så teknisk som dette kan det være svært at komme omkring alt, skulle man dog have nogle spørgsmål, opdage jeg har glemt noget, noget er for vagt forklaret eller er interesseret i en dialog er man mere end velkommen til at række ud.
I form af det er et Proof of Concept håber jeg også at have opvakt nysgerrighed til i selv vil eksperimentere lidt, det er uden tvivl reproducerbart og noget der kan bygges videre på. Jeg vil hvert fald selv bygge lidt videre på dette for at løse nogle af problematikkerne der begrænser skalerbarheden og nogle af de faktorer, som jeg føler, der lige nu forhindre det i at blive implementeret hos virksomheder.
Det er helt klart også noget som skal kunne “betale” sig, som det er lige nu afhænger det meget af at købe en “pro-plan” fra en AI virksomhed, den pris det koster for planen, skal gerne kunne hentes ind igen, ved tid sparet på ikke manuelt at skulle lave projekt specifikke byggevare i LCAbyg ud fra EPD’er, noget jeg først nu kan forestille mig bliver en virkelighed med det nye bygningsreglement (2025.07.01).