AI-verktøy og MCP

En språkmodell kan mye, men den vet ingenting om hvor mange som mottok uføretrygd i Troms i fjor. Skal den svare på det, må den kunne spørre noen som vet.

MCP er en åpen avtale om hvordan et program forteller en språkmodell hva det kan gjøre. Programmet beskriver verktøyene sine, språkmodellen velger hvilket som passer, og får et svar tilbake i en form den kan bruke. Poenget er at avtalen er den samme uansett hvem som har laget verktøyet - det som virker for ett verktøy, virker for alle.

For dette prosjektet var det en praktisk gevinst før det ble en interessant idé. Å hente en tabell fra offentlig statistikk krever at man vet tabellnummeret, hvilke dimensjoner den har, og hvilke koder som gjelder. Det er nøyaktig den typen oppslag som tar tid å gjøre for hånd og som er lett å gjøre feil.

Det er bygget 6 slike verktøysett mot norske offentlige datakilder, i tillegg til ett mot statistikkbanken som ligger for seg selv. De fleste gjør det samme grunnleggende: de lar en søke opp en tabell eller serie, se hvordan den er delt inn, og hente ut tallene uten å måtte lese seg opp på et API-grensesnitt først. Foretaksregisteret er et unntak: der slår man opp et foretak og rollene i det.

Verktøyene henter bare offentlige, åpne data. De gjør ikke tilgjengelig noe som ikke allerede var det - de gjør det raskere å finne. Alle kildene står oppført på kildesiden, som i dag lister 55 kilder.

Verktøyet mot Statistisk sentralbyrå er utelatt fra tabellen med vilje. Det er det klart mest brukte, og det får sitt eget avsnitt under.

Verktøyene over er våre egne, én server per kilde. Allemannsdata går andre veien: et uavhengig prosjekt som samler rundt femti servere mot åpne norske datakilder bak ett grensesnitt, uten nøkkel, med lik svarform og dokumentasjon skrevet for maskiner.

Vi har ikke funnet noe åpent API for Anleggsregisteret, så idrettsanleggene hentes derfra. Prisen er at bare de første hundre radene i en spørring kan leses, at kommuner slås opp på navn, og at pipelinen står og faller med en tjeneste én person driver. Vi teller derfor i stedet for å liste, kontrollerer summene mot fylkene, og beholder forrige tall når noe feiler.

Hele avveiningen, og spørsmålet om hvorfor det ikke finnes en offentlig variant, står i artikkelen om allemannsdata.

Statistikkbanken til Statistisk sentralbyrå er den viktigste enkeltkilden portalen har. Den er også den vanskeligste å hente fra riktig, og det er verdt å forklare hvorfor.

Banken inneholder tusenvis av tabeller. For å hente ett tall må du vite tabellnummeret, hvilke dimensjoner tabellen har - kjønn, alder, region, periode, gjerne flere til - og hvilke koder som gjelder for hver av dem. Tar du feil her, får du sjelden en feilmelding. Du får et tall. Det ser riktig ut, og det er feil.

Den klassiske fellen er dobbelttelling: mange tabeller har en «i alt»-kategori ved siden av underkategoriene. Summerer du alle kodene, summerer du totalen én gang for mye. Ingenting i svaret sier fra.

Tre spørsmål til verktøyet, og ett til portalen

1. 1. Finn en tabell

   Søk på et tema og få tabellene som handler om det. Du slipper å kjenne nummeret på forhånd.

2. 2. Vis dimensjonene

   Hvilke inndelinger tabellen har, og hvilke koder som finnes for hver. Det er her dobbelttellingen unngås.

3. 3. Hent tallene

   Uttrekk med dimensjonene satt, akkurat de skivene du trenger.

4. 4. Hva bruker vi alt

   Svaret kommer ikke fra dette verktøyet, men fra portalens eget, beskrevet under, som lister hvilke tabeller hvert tema hviler på.

Verktøyet kan også sjekke om en tabell er endret siden sist, sammenligne år og oppsummere en hel tabell.

Det er et redaksjonelt verktøy, ikke et leserverktøy

Ingen leser bruker dette direkte. Det som har endret seg, er hvordan innhold blir til. Tre mønstre har satt seg:

Hvorfor det bor for seg selv

De andre verktøyene er skrevet for konkrete behov i denne portalen og ligger foreløpig sammen med resten. Statistikkbank-verktøyet er skilt ut som et eget prosjekt, fordi det er nyttig for enhver som jobber med norsk offentlig statistikk - det gir mening uten portalen rundt seg.

Det er også den beste testen på om et verktøy er godt avgrenset: kan det stå alene, er grensesnittet sannsynligvis riktig satt.

Det neste steget var å snu det: hvis portalen kan spørre andre, kan andre spørre portalen. Den har derfor et eget verktøysett med 8 spørsmål en språkmodell kan stille.

Bakgrunnen er et valg portalen alt hadde tatt: språkmodellenes innsamlere er sperret ute fra sidene, fordi innholdet ikke skal høstes til trening. Det stenger også for en agent som vil svare riktig på et spørsmål om norsk statistikk. Verktøysettet er den døren, med en nøkkel.

Et eksempel på hva det betyr: ber en agent om to nøkkeltall i samme kall, og det ene gjelder et helt år og det andre en enkelt måned, kommer svaret med en advarsel om at de ikke kan sammenlignes direkte. Spør den om en årsakssammenheng portalen ikke har skrevet ned, svarer verktøyet at den ikke finnes, framfor å sette sammen en.

Begrunnelsen er ikke at portalen har tall ingen andre har. Den har ikke det - alt er hentet fra åpne kilder. Det den har, er konteksten rundt tallet: hvilken periode det gjelder, hvilken kilde det kommer fra, når det sist ble oppdatert, hvilket forbehold som hører til, og hvordan det henger sammen med noe annet. En språkmodell som leser av et tall fra en nettside, får tallet og mister alt det andre. Et verktøy kan levere begge deler i samme svar.

Særlig gjelder det årsakspåstandene fra kunnskapskartet. De finnes ikke i noen offentlig tabell. De er portalens egne, med begrunnelse og belegg, og de er det eneste her som ikke kan hentes andre steder.

Verktøy lar en AI-medarbeider hente noe. Ferdigheter lar den gjøre noe på riktig måte. Forskjellen er større i praksis enn den høres ut.

En ferdighet er en nedskrevet framgangsmåte for en oppgave som gjøres om igjen: hva som må gjøres, i hvilken rekkefølge, og hvilke feller som finnes. Å legge til en ny seksjon på portalen berører et titalls registre, og rekkefølgen betyr noe. Det er ikke noe man skal forklare på nytt hver gang - og det er heller ikke noe en språkmodell gjetter riktig.

Ferdighetene er ikke bare våre egne. Dataplattformen portalen bruker, leverer sine egne: hvordan et dashbord settes opp der, hvordan man lar noen spørre dataene med vanlige ord, hvordan svarene måles. De blir tilgjengelige på samme måte som de hjemmelagde. Poenget er ikke at det går fortere, men at arbeidet følger den veien leverandøren selv anbefaler, framfor den veien en språkmodell tror er riktig.

Den viktigste erfaringen herfra er enkel: det som ikke er skrevet ned, blir ikke gjort likt to ganger. Ferdighetene er ikke først og fremst en effektivisering - de er måten konsistens oppnås på når hver arbeidsøkt starter uten hukommelse fra den forrige.

Avsnittet handler om språkmodellene som brukes til å bygge portalen. I selve driften brukes andre: artikkelutkastene skrives gjennom en språkmodell-leverandørs API, chatten lar en språkmodell i datalageret avgjøre hvilket spørrerom et spørsmål hører til, og i datalageret leser plattformens egne språkmodeller dokumentene. Den daglige idébanken og den ukentlige innholdsplanen bruker også en språkmodell gjennom et API. Svarene i chatten vurderes ukentlig av en egen evaluering. Lista er ikke nødvendigvis komplett.

Det finnes flere språkmodeller å velge mellom, og de er ikke rangert langs én akse. Den som tenker dypest, er også den tregeste og den som bruker mest av den forhåndsbetalte kvoten abonnementet gir per uke. Valget er derfor en løpende avveining mellom dybde, hastighet og forbruk, ikke et engangsvalg. Fire ting avgjør det i praksis.

1. Fasene i utviklingsløpet stiller ulike krav

Utforsking og planlegging tåler og belønner dybde. Utførelse mot en ferdig plan gjør det i mindre grad.

Da 26 kopier av det samme mønsteret i grensesnittkoden skulle samles i én delt rutine, lå hele vanskeligheten i å avgjøre hva som faktisk var samme mønster og hva som bare lignet. Selve endringen etterpå var mekanisk. 26 ganger.

2. Oppgavene deler seg i to typer, og skillet går ikke mellom lett og vanskelig

Noen oppgaver krever først og fremst at et tett regelverk følges. En ny side på portalen berører et titalls registre: innholdskartet, søkeindeksen, undermenyen, hovedmenyen, kilderegisteret, grunnlaget bloggen skriver fra. Ingenting av det er vanskelig. Det er langt, og det står allerede skrevet ned. Her vinner en dypere språkmodell lite. Den følger den samme lista.

Andre oppgaver krever reell problemløsning. Tjenesten som legger ut nettstedet, svarte riktig på selve adressen og «finnes ikke» på utleggingens egen permanente lenke, i samme øyeblikk. Passordbeskyttelsen var av, utleggingen var frisk, og ingenting i koden forklarte det. Den er fortsatt ikke løst, og står som en kjent begrensning. Det vanskelige var aldri selve rettingen. Det var at ingen av de opplagte forklaringene holdt.

3. Graden av tilsyn betyr mest

Dette er den viktigste enkeltfaktoren, og den handler ikke om oppgaven i det hele tatt.

En økt noen sitter og ser på, tåler en enklere språkmodell. Går det feil vei, avbrytes den. Feilen koster tretti sekunder.

Portalen bygger også oppgaver om natta, parallelt, i hvert sitt isolerte miljø. De legger fram arbeidet og stopper der - ingenting tas inn i hovedgrenen automatisk. En feil retning der koster hele leveransen, og den oppdages først neste morgen. Det er samme oppgavetype, men to helt ulike krav til hvor godt den må gå av seg selv. Kapittel 9 beskriver den kjeden i sin helhet.

4. Parallell kjøring multipliserer forbruket

Oppgaver som bygges samtidig, er like mange økter som tapper den samme kvoten. Taket på 5 er ikke satt av hensyn til forbruket: køen settes sammen for hånd fordi kontroll over hva som kjøres veier tyngst, og oppgaver som rører samme fil settes automatisk i rekkefølge for å unngå at de kolliderer. Men begge grensene legger samtidig et tak på hva en natt kan koste. Anbefalingen ligger på 3, altså under taket, fordi flaskehalsen er gjennomlesingen morgenen etter.

Nivået på språkmodellen velges derfor per oppgave. Tidligere arvet hver nattlige økt nivået til økta som startet køen, så en kø startet fra en dyp økt kjørte alle oppgavene dypt, og forbruket ble ganget opp med antallet som kjørte samtidig.

Regelen som er landet på, er kort nok til å huskes: velg språkmodell etter hvor lenge en feil får leve før noen ser den.

Verktøysettet er ikke åpent. Det krever en avtalt nøkkel, og er slått helt av der nøkkelen ikke er satt.

Standardvalget er strengt med vilje. Var det åpent som utgangspunkt, ville et hvilket som helst nytt miljø - en testutgave, en kopi satt opp for å prøve noe - stilltiende blitt et åpent grensesnitt mot hele registeret. En sikkerhetsinnstilling som virker bare når noen husker å skru den på, virker ikke.

Det er heller ikke et prinsipielt standpunkt mot åpenhet. Alle tallene er offentlige, og sidene er åpne for alle. Men et grensesnitt bygget for maskiner tåler helt andre mengder forespørsler enn en person som leser, og kostnaden ved å ta feil er lavere når man kan åpne senere enn når man må lukke i etterkant.

Nøkkelen sammenlignes på en måte som tar like lang tid enten en nøkkel av riktig lengde er nesten riktig eller helt feil, så svartiden ikke røper noe. Et avslag kommer som en feil klienten kan lese, ikke som en feilside, fordi en klient som får en feilside, melder at den ikke fikk kontakt, og da leter man etter feil i nettverket. Tre ting er ikke på plass: en fast rutine for å bytte nøkkel, en øvre grense for hvor stort et enkelt svar kan bli, og logging av hvem som spør om hva.

Å bygge det var mer arbeid enn ventet, og på steder som ikke var åpenbare på forhånd.

• Dokumentasjonen holdt ikke tritt

  Avtalen er ung og verktøykassen endrer seg raskt. Pakken med det navnet man først finner, var feil pakke og manglet det eksemplene viste til. Et flagg som så ut til å løse et problem, gjaldt en versjon av avtalen som ikke var støttet ennå. Ingen av delene sa fra om hvorfor.

• Feilene var stille

  Det som virket lokalt, ville svart tomt i drift. Artiklene og oppdragene ligger som filer utenfor det som pakkes med til serveren, så en lesing av dem ville gitt en tom liste framfor en feil. Merket som skal si hvilken utgave av koden et tall kom fra, ville stått som «ukjent», fordi opplysningen bare finnes mens nettstedet bygges. Begge ble fanget i gjennomgang før serveren ble lagt ut. Derfor bakes oppdragene og merket inn når nettstedet bygges, og artiklene er med vilje holdt utenfor det agentene kan slå opp i.

• Klienter som ber om noe annet

  En klient som bare godtar vanlige svar, slik minst én utbredt bedriftsplattform for agenter gjør, fikk avslag, fordi den ferdige koden alltid svarer som en strøm og krever at klienten godtar begge formene. Serveren oversetter nå selv. Koblingen til den plattformen er fortsatt ikke prøvd ende til ende.

• Svar som ser riktige ut

  Seks gjennomgangsrunder fant tre feil av samme slag, og alle tre var innført i rettingen fra runden før. Søket etter kilder matchet på delstrenger, så ett enkelt siffer ga nesten halvparten av temaene. Nabolaget i kartet gjorde halvparten av koblingene til sterkere påstander enn portalen står for. Alle svarte uten feil og så riktige ut. Det som fant dem, var å kjøre hvert verktøy mot hele registeret, ikke mot ett eksempel.

• Hva som er ett verktøy

  Det var fristende å lage ett verktøy per spørsmål noen kunne tenkes å stille. Det gir mange verktøy som ligner på hverandre, og en språkmodell som velger feil. Færre og bredere verktøy fungerte bedre. To av verktøyene kom til fordi tester stilte serveren spørsmål dokumentasjonen lovet at den kunne svare på, og den ikke kunne, som hvilke temaer som hviler på en bestemt tabell.

• Serveren fant feil i innholdet

  Den første brukertesten fant ikke bare feil i serveren, men også i portalens egne tall. Andelen kvinner blant mottakerne av uføretrygd sto som rundt tolv prosent, og sju datasett hadde stått urørt i opptil tre måneder bak en datajobb som var grønn. Et grensesnitt som leverer tallet med periode og kilde, gjør det lettere å se når noe ikke stemmer.

• Det som står åpent

  Advarselen om ulike perioder sier ingenting når tre tall for samme størrelse har samme periode. I testen i august 2026 ga ett spørsmål antallet uføretrygdede som 365 000, 374 918 og 389 023 for samme år. To av dem skiller seg fordi NAV og SSB teller ulikt, men svaret sa ingenting om hvorfor. Det er ikke løst.

Verktøysettet er i bruk, men ikke ferdig. Det logger ikke hvem som bruker det, så hvor mye det brukes utenfor prosjektet, vet vi ikke. Det er ingen dårlig beskrivelse av resten av prosjektet heller.