Vad modellen är, och vad siffrorna faktiskt mäter.
Elliott kör en egen fintrimad språkmodell för ArchiMate-klassificering. Den här sidan beskriver hur den är byggd, vad utvärderingssiffrorna betyder, och var den fortfarande är svag. Vi hellre säger det rakt ut än låter dig upptäcka det i en pilot.
En fintrimad Qwen3, inte en chattmodell med systemprompt.
Grundmodellen är Qwen3-14B, en öppen språkmodell med 14 miljarder parametrar. Ovanpå den ligger en finjustering vi tränat själva: först ett QLoRA-steg på arkitekturuppgifter, sedan ett DPO-steg som lär modellen välja rätt när två svar ligger nära varandra. Resultatet körs lokalt via Ollama på hårdvara i Sverige.
Skillnaden mot att koppla in GPT-4 och skriva en lång systemprompt är att modellvikterna faktiskt har flyttat sig. Modellen har sett tusentals exempel på skillnaden mellan en Business Function och en Business Process i svensk kommunal kontext, inte bara en instruktion om att skillnaden finns.
Vad 95 procent betyder, och vad det inte betyder.
Siffran kommer från vår interna golden-utvärdering. Det är en handskriven testmängd med 100 uppgifter som modellen aldrig sett under träningen, uppdelad på tre saker verktyget faktiskt gör: klassificera enskilda element, mappa mellan ramverk, och hitta relationer mellan element.
Klassificeringsdelen är 40 uppgifter. Modellen ska avgöra vilken ArchiMate-typ en rad eller kolumn i ett dokument motsvarar, till exempel om Ärendehantering är en capability, en business_process eller en business_function. Där svarar den rätt på 37 av 40, och macro F1 är 0,939.
| Uppgift | Antal fall | Rätt | Macro F1 | Otränad Qwen3-14B |
|---|---|---|---|---|
| Klassificering av element | 40 | 95 % | 0,939 | 70 % |
| Mappning mellan ramverk | 25 | 80 % | 0,688 | 0 % |
| Detektering av relationer | 35 | 60 % | 0,314 | 15 % |
Golden-utvärdering av produktionsmodellen, körd 2026-06-08. Kolumnen längst till höger är samma testmängd på grundmodellen utan vår finjustering. Klassificeringssiffran avser de 39 svar som gick att tolka maskinellt. Räknar man det oläsbara svaret som fel blir siffran 92,5 procent.
Det här är vår egen testmängd, inte ett oberoende riktmärke. Vi har skrivit uppgifterna själva, de är färre än hundra per kategori, och en handfull rätt eller fel flyttar procenttalet flera steg. Behandla siffrorna som en intern regressionsmätning som visar att finjusteringen gjorde skillnad, inte som ett bevis på hur modellen presterar på just era dokument. Det enda sättet att veta det är att köra era egna filer genom den.
Relationer är den svaga delen.
Att klassificera ett element för sig är en betydligt lättare uppgift än att avgöra hur två element hänger ihop. Det syns i siffrorna. Modellen hittar rätt relation i ungefär 60 procent av fallen, och macro F1 på 0,314 säger något viktigare än accuracy-talet: träffsäkerheten är ojämn mellan relationstyper. Vanliga relationer som realisering och tilldelning fungerar bra. Ovanligare relationstyper med få träningsexempel fungerar sämre.
Vi säger det här öppet därför att det påverkar hur ni bör arbeta i verktyget. Klassificeringsförslagen kan ni ofta acceptera i klump efter en snabb genomläsning. Relationsförslagen bör ni gå igenom ett i taget. Elliott är byggt för det: varje förslag har en konfidenspoäng, en motivering på svenska, och alternativa förslag att välja mellan.
Relationsdelen är också det vi arbetar mest med just nu. Vägen framåt är fler träningsexempel för de relationstyper som är underrepresenterade, samt bättre kandidatgenerering så att modellen får färre och mer rimliga elementpar att ta ställning till.
Annat som är värt att veta
- Modellen är inte en orakelmaskin. Den föreslår, ni beslutar. Inget importeras till er arkitektur utan att någon har godkänt det.
- Svarstiden är sekunder, inte millisekunder. En lokal 14B-modell på egen GPU är långsammare än ett moln-API. Vi tycker att det är ett rimligt pris för att dokumenten stannar i Sverige.
- Kvaliteten beror på källan. Ett välstrukturerat förvaltningsdokument ger bättre resultat än en skannad PDF med tabeller i bildform.
Träningsdata: genererad, inte insamlad.
Modellen är tränad på 7 430 genererade exempel. De är konstruerade utifrån ArchiMate 3.2- och TOGAF-specifikationerna och speglar fem domäner: kommun, sjukvård, bank, tillverkning och ITIL. Ingen kunds verksamhetsdata ingår i den träningen.
Om ni vill bidra till att modellen blir bättre på just er sorts dokument är det ett aktivt val ni gör, inte något som sker som standard. Delning av interaktionsdata är opt-in. Den är avstängd tills någon hos er slår på den, och den regleras skriftligt i tillägg till personuppgiftsbiträdesavtalet. Vi tränar inte på era dokument bara för att de har passerat servern.
Varför den körs lokalt.
Alla stora EA-verktyg har lagt till AI det senaste året, och i praktiken betyder det nästan alltid en generell modell anropad över ett moln-API. Det fungerar tekniskt. Men för en kommun innebär det att förvaltningsdokument, systemlandskap och organisationsstrukturer lämnar byggnaden och behandlas hos en leverantör i ett annat land.
Elliott gör inte det. Modellen ligger på en server i Sverige, dokumenten stannar där, och inget i flödet anropar Azure eller OpenAI. Det är också anledningen till att vi kan teckna personuppgiftsbiträdesavtal utan att bygga en kedja av underbiträden och tredjelandsöverföringar.
Det finns en avvägning här och vi ska vara ärliga om den. En 14B-modell på egen hårdvara är mindre än de största molnmodellerna, och på generella uppgifter är den sämre. Vår tes är att det inte spelar någon roll, eftersom uppgiften här är smal: klassificera arkitekturelement enligt en känd notation. På just den uppgiften slår den finjusterade modellen en betydligt större generell modell, och den gör det på hårdvara ni vet var den står.
Testa den på era egna dokument.
Siffrorna på den här sidan är våra. De enda som säger något om er verklighet är de ni får när ni kör en riktig fil genom verktyget.