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. Alle gjør det samme grunnleggende: de lar en søke opp en tabell, se hvilke dimensjoner den har, og hente ut tallene - uten å måtte lese seg opp på et API-grensesnitt først.

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 44 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.

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.

Fire spørsmål, i den rekkefølgen de brukes

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

   Hvilke tabeller portalen allerede henter fra, så det samme ikke hentes to ganger på to måter.

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 seks andre verktøyene er skrevet for konkrete behov i denne portalen og ligger 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 åtte spørsmål en språkmodell kan stille:

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.

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å 3 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å 2, altså under taket, fordi flaskehalsen er gjennomlesingen morgenen etter.

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.

Å 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. Flere av eksemplene som fantes å lære av, var utdaterte nok til å ikke virke, uten å si fra om hvorfor.

• Feilene var stille

  De vanskeligste feilene ga ikke feilmelding. Grensesnittet svarte, men svarte tomt. Det tar lengre tid å finne enn noe som krasjer.

• 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.

• Svarene måtte være ærlige

  Et verktøy som svarer «det finnes ikke tall for dette» er mer verdt enn ett som svarer noe omtrentlig. Å få det til konsekvent krevde flere runder enn selve oppkoblingen.

Verktøysettet er i bruk, men det er ikke ferdig. Det er ingen dårlig beskrivelse av resten av prosjektet heller.