Skriv in en AMA-kod i Copilot och fråga vad den kräver. Svaret blir en blandning av AMA 17 och AMA 20, serverad som fakta. Nej, en nationell bilaga kan den inte läsa heller. Detsamma gäller ChatGPT och Claude: felen sitter i kategorin, inte i produkten.
Domen
Den hårdaste domen över generell AI i ingenjörsarbete kommer från dem som själva rullade ut den. På en stor teknikkonsult sammanfattade personen som ansvarade för Copilot-utrullningen ett års användning i hela bolaget i en mening:
Hopplöst för allt specifikt: den vet inte hur vi jobbar. Som en otränad praktikant.
Det är inte ett Microsoft-problem. Copilot bygger på samma klass av modeller som ChatGPT och Claude, och alla generella verktyg på den grunden fallerar på samma sätt här. En anbudsgrupp på ett annat bolag sade samma sak om ChatGPT: svaren är alltid blandade; man måste alltid stämma av. Modellerna är tränade på det publika internet, och de dokument som styr ett europeiskt infrastrukturprojekt är den del av textvärlden som internet täcker sämst. Felen är specifika och återkommer. Här är de fem som avgör.
Felläge 1
Eurokoderna ser ut som det perfekta användningsfallet för AI: harmoniserade europeiska standarder, väl omskrivna, väl representerade i träningsdata. Fällan är att de är avsiktligt ofullständiga. Varje land fastställer egna värden för de nationellt valda parametrarna: partialkoefficienter, snö- och vindlaster, exponeringskrav. Valen ligger i en nationell bilaga, och bilagan ersätter tyst grundtexten.
Ställ en fråga under EN 1992, betongstandarden, till en generell modell och den svarar ur grunddokumentet: flytande, trovärdigt och kalibrerat mot de rekommenderade värdena i stället för de svenska. Inget i grundtexten talar om för modellen att det finns en bilaga som ändrar dem. För ingenjörsarbete är det den värsta felklassen som finns: ingen vägran, inget nonsens, utan en självsäkert felaktig parameter som ser exakt ut som en riktig.
Felläge 2
Ett nordiskt projektunderlag håller sig sällan till ett språk. Kontraktet på svenska, en teknisk specifikation på engelska, villkoren i miljötillståndet på svenska, en leverantörs dimensioneringsförutsättningar på engelska. Kraven är en kravmassa; orden är delade mellan två språk.
Generisk sökning behandlar språk som en relevanssignal. Fråga på engelska och de engelska dokumenten kommer tillbaka; den svenska klausul som motsäger dem ligger kvar begravd. Korsreferenser går sönder på samma sätt: ett svenskt dokument som pekar på avsnitt 4.2 i ett engelskt är en länk ingen chattbot följer. Svaret blir inte fel för att modellen inte kan svenska. Det blir fel för att modellen aldrig förstod att den svenska halvan var den som gällde.
Felläge 3
Infrastruktur har långt minne. En konstruktion byggd 1968 bedöms mot dokument från 1968: äldre normer, vattendomar, lokala föreskrifter, arkiverade tillstånd. Mycket av det styr projekt än i dag, och det finns bara som skannat papper: maskinskrivna sidor, stämplar, tabeller, anteckningar i marginalen.
Generella verktyg kör enkel teckentolkning och hoppas på det bästa. På rena kontorsdokument fungerar det; i en skannad lasttabell tappas upphöjda tecken, kolumner flyter ihop och gränsvärden blir andra siffror. Modellen resonerar sedan obekymrat vidare ovanpå den trasiga texten, utan att veta att den läser skräp. Skanningen behöver inte vara ovanlig för att fälla den. Det räcker med en dålig tabell.
Felläge 4
Svensk infrastruktur bygger på en kompakt fackterminologi med kontraktuell tyngd: bygghandling, systemhandling, förfrågningsunderlag, granskningsutlåtande, ÄTA. Det är inte ord som väntar på översättning; de bär status. En systemhandling och en bygghandling kan beskriva samma objekt, och skillnaden avgör om ett krav är bindande ännu.
Det finns mycket lite publik svensk ingenjörstext för en grundmodell att lära sig detta av. Så en generell modell översätter i stället för att förstå: bygghandling blir "construction document", statusskillnaden försvinner, och ett svar som flyter fint på engelska har i tysthet plattat till just den distinktion som gjorde frågan värd att ställa.
Felläge 5
AMA är referensverket som svenska tekniska beskrivningar skrivs mot, och det ges ut i utgåvor: AMA 17, AMA 20 och vidare. En kod som åberopas i en teknisk beskrivning betyder det som den åberopade utgåvan säger att den betyder. Mellan utgåvor revideras krav, flyttas och får nytt tillämpningsområde, medan koden förblir samma teckensträng.
En generell modell har sett fragment av AMA-diskussioner på nätet, från blandade utgåvor, utan begrepp om vilken utgåva som gäller. Fråga vad en kod kräver och du får en blandning: mest en utgåva, kryddad med en annan, serverad som ett enda svar. Det styrande dokumentet deklarerar sin utgåva i inledningen. Det enda korrekta beteendet är att verifiera varje svar mot den deklarerade utgåvan, och en chattbot saknar mekanism för det.
Mönstret
Alla fem felen delar en rot. Rätt svar beror på vilket dokument som styr: vilken bilaga, vilket språk, vilken skanning, vilket begrepp, vilken utgåva. En generell modell har inget sätt att veta det, och värre: ingen vana att kontrollera. Bättre prompter löser det inte. Praktikanten är inte lat, den är otränad, och träningen den saknar finns inte på internet.
Därför är det här en kategoriskillnad, inte ett produktgap som nästa Copilot-version stänger. Ett verktyg som fungerar i den här domänen måste veta vilka dokument som styr ett projekt och verifiera det den säger mot dem innan den svarar. Hur den skillnaden ser ut i praktiken skriver vi om i en systertext: en chattbot svarar på en fråga, Yesper gör arbetet
Yesper är AI-civilingenjören för bygg och infrastruktur. AFRY, COWI, NRC Group och andra nordiska bolag använder den för att halvera tiden i en utredning, räkna om på minuter, och fånga fel som annars slinker förbi. Hör av dig om du vill se vad den kan göra för er.
Boka demoFå nästa text i mejlen. Avregistrera när du vill.
