Trenger alle beslutninger en språkmodell?

En kunde skriver til banken. Før meldingen kan besvares, må en rekke små beslutninger tas. Inneholder den personopplysninger? Hvilke API velges for å hente data eller utføre en handling? Må et menneske involveres? Og hvor mye haster det?
Slike oppgaver kan løses med en stor språkmodell.  Men trenger vi virkelig en LLM for hver oppgave i en kundeservice, en arbeidsflyt, eller et større agentisk system?

Språkmodeller er kraftige, men de bruker tid, koster penger per kall og inneholder ofte at data sendes ut av bankens egne systemer. For enkle beslutninger finnes det et alternativ: små, spesialiserte beslutningsmodeller som kan kjøres lokalt.

Jeg bestemte meg for å teste en.

Hva er en «System One»-modell?

System One-modeller, også kalt beslutningsmodeller, er ikke vanlige språkmodeller. De genererer ikke tekst. Du gir dem en tilstand (for eksempel en kundemelding) og noen spørsmål, og de svarer med ferdig strukturerte svar og sannsynligheter. Her er tre typer spørsmål:

• Valg: velg ett alternativ (for eksempel hvilket team).
• Skår: gi en gradering (for eksempel lav, middels, høy).
• Ja/nei: sannsynlighet for at en påstand er sann.

Du kan stille mange spørsmål i ett og samme kall, og de åpne variantene kan kjøres lokalt på egen maskinvare, for eksempel via Ollama eller på egne servere.

Typen ble gjort kjent av modellen Jev fra TypeSafe AI, og kalles derfor ofte «Jev-style». Modellen jeg testet heter nimble. Det er en åpen System One-modell fra Bespoke Labs, altså ikke TypeSafe AI sin egen Jev-modell, men samme type og samme API.

Eksperimentet

Jeg stilte de samme fem spørsmålene til to modeller, om de samme norske kundemeldingene:

De fem spørsmålene, slik de ble sendt til begge modellene:

1. Personopplysninger til stede (ja/nei): «Meldingen inneholder personopplysninger (navn, fødselsnummer, konto- eller kortnummer, adresse e.l.).»
2. Type personopplysning (valg): «Hvilken type personopplysning er mest sensitiv i meldingen?» Alternativer: fødselsnummer (fødselsnummer eller D-nummer), konto/kort (konto- eller kortnummer), kontakt (navn, adresse, telefon eller e-post), ingen.
3. Sensitivitet (skår): «Hvor sensitiv er informasjonen i meldingen?» Alternativer: Lav, Middels, Høy.
4. Hvilket team (valg): «Hvilket team bør håndtere meldingen?» Alternativer: lån (lån og boliglån), kort (kort og betaling), svindel (svindel og sikkerhet), generelt (generell henvendelse).
5. Hvor mye det haster (skår): «Hvor haster denne henvendelsen?» Alternativer: Rutine, Snart, Haster.

Begge modellene fikk nøyaktig likt spørsmål. Språkmodellen ble bedt om å svare i samme faste JSON-format, slik at svarene kan sammenlignes direkte.

De tre meldingene jeg testet:

1. «Hei, kortet mitt (4571 0392 1123 8890) ble belastet to ganger i går. Kan dere refundere?»
2. «Jeg lurer på hva renten er på boliglån for tiden?»
3. «Noen har logget seg inn på kontoen min og overført 15 000 kr jeg ikke kjenner til!! Haster!»

Viktig å være ærlig om: dette er en liten første test med tre meldinger, ikke en benchmark. Resultatene peker på tendenser, ikke fasit. Jeg brukte bare syntetiske data, aldri ekte kundemeldinger.

Resultater

Begge modellene var enige i 13 av 15 svar, og begge svarte riktig på alle de klare tilfellene. Treffsikkerheten var altså omtrent lik. Det interessante lå et annet sted.

Funn 1: Den store forskjellen er kalibrering, ikke treffsikkerhet

Modellene skilte seg der det betyr mest. På de usikre sakene fordelte nimble sannsynligheten sin bredere, mens språkmodellen landet på trygge, runde tall uansett.

Meldingen om kontoinnbrudd over inneholder strengt tatt ingen personidentifikatorer (verken navn, fødselsnummer eller kontonummer). Det er et ekte grensetilfelle:

• nimble svarte «ja, personopplysninger» med 0,54 i sannsynlighet, altså et tydelig signal om «dette er jeg usikker på».
• Språkmodellen svarte «ja» med 0,95, trygt, men på tynt grunnlag. På type personopplysning svarte den til og med konto-/kortnummer med 0,90, selv om det ikke finnes noe slikt nummer i teksten.

Samme mønster på et tvilsomt «haster»-spørsmål (meldingen om dobbel kortbelastning): begge valgte «Snart», men nimble la bare 0,61 av sannsynligheten der og fordelte resten på «Rutine» (0,21) og «Haster» (0,18), altså reell tvil. Språkmodellen ga 0,85 på «Snart» og lite annet.

For en bank er dette hele poenget. Hvis jeg setter en terskel og sender usikre saker til et menneske, vil nimble sine spredte fordelinger fange opp de vanskelige sakene, mens språkmodellens jevnt høye tall ville sende dem rett videre, noen ganger feil. Språkmodellens runde tall (0,90 / 0,95 / 0,99) ser dessuten ut som en tommelfingerregel, ikke en målt sannsynlighet.

Funn 2: Farten avhenger av maskinvaren

På en vanlig kontor-laptop med RTX A2000 brukte nimble i snitt ca. 4 sekunder per kall, altså tregere enn skymodellen inkludert nettverk. Men dette er en begrensning i laptopen, ikke i tilnærmingen. nimble er en liten modell (9 milliarder parametere) som bare skal svare med noen få tegn. På kraftigere maskinvare går det vesentlig raskere: offentlige målinger viser svartider rundt 100 millisekunder per avgjørelse.

Forventningen er derfor at kraftigere maskinvare vil bringe nimble godt under ett sekund, sannsynligvis raskere enn sky-LLM-en, og fortsatt uten kostnad per kall. Så lenge maskinen er bankens egen (egne servere eller egen sky), beholder man personvernet. Dette har jeg ikke målt ennå, og det er neste steg.

Funn 3:  Usikkerheten er lettere å etterprøve

nimble gir en full sannsynlighetsfordeling for hvert svar. Det er lett å logge, sette terskler på og forklare i ettertid, noe som er nyttig for etterlevelse og revisjon. Språkmodellen gir bare ett tall den selv har funnet på. Én ting å passe på: nimble svarer på hvert spørsmål uavhengig, så svarene kan av og til motsi hverandre. Da trenger man en enkel regel som rydder opp.

Konklusjon

En lokal beslutningsmodell er ikke en erstatning for språkmodeller. Den er et billigere, mer privat og mer etterprøvbart lag for de mange små avgjørelsene. Og spesifikt for min lille test:

• Personvern: den lokale modellen sendte ingenting ut av maskinen. Sterkeste argument.
• Kalibrering: den lokale modellen var ærlig usikker på vanskelige saker. Dette er det mest lovende resultatet for en regulert bransje.
• Fart: avhenger av maskinvaren. Treg på laptop, men ventet å være rask på et skikkelig GPU.

Den naturlige arkitekturen blir da: la beslutningsmodellen gjøre de raske avgjørelsene og sile ut det den er sikker på, og la en språkmodell (eller et menneske) ta det den er usikker på.

Forbehold:  Tre testmeldinger er selvfølgelig alt for lite til å konkludere. Neste steg er et større syntetisk datasett (50 til 100 meldinger) med fasit, slik at jeg kan måle reell treffsikkerhet og kalibrering skikkelig, og med testing på kraftigere maskinvare/en kjøring på et bedre GPU for å teste farten. (kostnadstallet bygger på listepris for Haiku. Bedrock kan avvike).

Men denne første testen ga iallfall grunn til å stille spørsmålet en gang til.

Trenger alle beslutninger egentlig en språkmodell?