System One-modeller: Når AI skal træffe beslutninger - ikke skrive tekst

Den 15. september lancerede TypeSafe AI modellen Jev og introducerede samtidig betegnelsen System One Models. Hvor et traditionelt LLM som GPT eller Claude producerer en sekvens af tokens, er Jev designet til at modtage en state og en række afgrænsede spørgsmål og returnere typed decisions med sandsynligheder og confidence scores.

TypeSafe beskriver selv Jev som en model bygget til »decisions inside software« snarere end kommunikation med mennesker. Modellen genererer ikke tekst, men kan eksempelvis vælge mellem definerede kategorier, score noget på en skala eller estimere sandsynligheden for et binært udfald.

Så er System One-modeller i virkeligheden bare classifiers?

Det korte svar er: Ja, funktionelt set er sammenligningen ganske rimelig. Men den overser noget af det interessante.

Classification er ikke nyt

Machine learning-modeller har klassificeret tekst, billeder og andre data længe før den nuværende generation af generative AI.

Hvis en organisation eksempelvis vil afgøre, om en indgående mail handler om fakturering, support eller salg, er det klassisk classification. Det samme gælder vurderinger som:

• ·Hvilket team skal håndtere denne sag?
• ·Indeholder dokumentet en bestemt type risiko?
• ·Er denne transaktion mistænkelig?
• ·Skal denne AI-agent fortsætte, prøve igen eller eskalere?
• ·Hvilken af fem handlinger bør systemet vælge?

Traditionelt ville man ofte træne eller fine-tune en classifier specifikt til opgaven. Det kan give ekstremt hurtige og billige modeller, men kræver typisk labelled data og en relativt fast definition af opgaven.

LLMs ændrede dette trade-off. Pludselig kunne vi beskrive en ny klassifikationsopgave i natural language og få et rimeligt resultat uden at træne en ny model.

Til gengæld begyndte vi også at bruge meget store generative modeller til opgaver, hvor vi reelt ikke havde brug for generation.

Vi sender måske et support-ticket gennem et frontier LLM med milliarder af parametre for at få modellen til at returnere:

billing

Det virker. Men arkitektonisk er det lidt absurd.

System One forsøger at udfylde hullet mellem classifiers og LLMs

Det er her, modeller som Jev bliver interessante.

Jev kombinerer nogle af fordelene fra traditionelle classifiers med noget af den fleksibilitet, vi har vænnet os til fra LLMs.

I stedet for at generere et JSON-dokument token for token definerer udvikleren på forhånd, hvilke typer svar modellen må returnere. Jev understøtter blandt andet valg mellem kategorier, ordinal scoring og yes/no-sandsynligheder. Flere spørgsmål kan desuden evalueres mod den samme state parallelt. [1]

Resultatet er en model, som i praksis fungerer mere som en probabilistisk funktion:

state + questions → decisions + probabilities

Det er et væsentligt anderledes interface end:

prompt → genereret tekst

TypeSafe oplyser en pris på $0,042 pr. million input tokens og end-to-end latency på cirka 70-500 ms. Virksomheden publicerer også egne benchmarks, hvor Jev på udvalgte System One-workflows er op til 193,6 gange hurtigere og 444,6 gange billigere end de sammenlignede LLM-løsninger. TypeSafe understreger selv, at disse resultater sandsynligvis ligger i den høje ende af, hvad man bør forvente i praksis. [1]

Det sidste er en vigtig detalje. Kategorien er få dage gammel, og meget af den nuværende dokumentation kommer fra producenten selv. Der er endnu ikke grundlag for at behandle de mest markante benchmark-tal som universelle egenskaber ved System One-modeller.

»Zero hallucinations« kræver også en præcis definition

TypeSafe bruger blandt andet formuleringen »zero hallucinations« om Jev.

Det giver mening i en meget specifik teknisk betydning: Når modellen kun kan returnere en værdi fra et prædefineret output space, kan den ikke pludselig opfinde en ny JSON-property, returnere et ugyldigt enum eller begynde at skrive en forklaring midt i et API-response.

Schemaet kan garanteres.

Korrektheden kan ikke.

En classifier kan stadig vælge den forkerte kategori. En probability estimate kan være dårligt calibrated. Og en model kan være meget sikker på et forkert svar.

Den relevante egenskab er derfor ikke, at modellen ikke kan tage fejl. Det er, at fejltypen bliver mere kontrollerbar, og at sandsynligheder kan bruges aktivt i applikationslogikken.

Et system kan eksempelvis automatisere beslutninger over en bestemt confidence threshold og sende resten videre til et større LLM eller et menneske.

Det er ofte langt mere interessant i enterprise software end et løfte om »ingen hallucinationer«.

Laya viser, hvor lidt mystik der egentlig behøver at være

Kort efter Jev er der allerede kommet open source-alternativer. En af de mest interessante er Laya fra ConvAI Innovations.

Laya er Apache 2.0-licenseret og gør arkitekturen betydeligt mere transparent. Den engelske model består af en ModernBERT-large encoder på cirka 395 millioner parametre kombineret med et decision head, så modellen samlet har omkring 421 millioner parametre. [2]

Hver mulig beslutning scores direkte, hvorefter modellen returnerer en probability distribution. Der genereres ikke tekst autoregressivt.

Det understreger pointen: Der er ikke nødvendigvis behov for et frontier LLM for at løse denne type problem.

Laya kan samtidig køres lokalt. Projektets egne benchmarks viser omkring 33-40 ms for en enkelt decision på en Tesla T4 og endnu højere throughput ved batching. Det er lokale modelmålinger og derfor ikke direkte sammenlignelige med Jevs hosted API-latency, men de illustrerer potentialet i relativt små non-autoregressive modeller. [3]

For virksomheder kan noget andet ved Laya dog vise sig at være mere interessant end de rå millisekunder: modellen kan fine-tunes.

Domain-specific System One kan være mere interessant end general-purpose System One

Layas egne resultater er faktisk en god illustration af både potentialet og begrænsningerne.

Projektet dokumenterer selv, at de generelle base checkpoints klarer sig relativt dårligt zero-shot på deres typed-decisions benchmark. Først efter fine-tuning på den relevante træningsdistribution stiger performance markant.

Udviklerne beskriver derfor selv Laya som en base, der bør specialiseres, snarere end en stærk generel zero-shot decision engine. [3]

Det er efter min vurdering en vigtigere pointe end spørgsmålet om, hvorvidt Laya eller Jev vinder et bestemt benchmark.

For mange virksomheder er problemet nemlig ikke:

»Hvilken generisk AI-model ved mest om verden?«

Problemet er snarere:

»Kan modellen konsekvent træffe denne bestemte type beslutning i vores forretningsproces?«

Forestil dig en model specialiseret på en pensionskasses investeringsprocesser, et forsikringsselskabs claims, en banks compliance-workflow eller en offentlig myndigheds dokumenttyper.

Her kan en relativt lille lokal model med organisationens egne evals, calibration og domain-specific fine-tuning være mere værdifuld end en langt større general-purpose model.

Det giver samtidig mulighed for on-premise deployment, kontrol over modelversioner og en anden tilgang til data sovereignty end en ekstern API alene kan tilbyde.

Layas aktuelle benchmarks skal dog læses med samme forbehold som Jevs. Sammenligningerne med Jev er ikke udført i et fælles kontrolleret benchmark-setup, og Laya-projektet gør selv opmærksom på forskelle i prompts, sample sizes og målemetoder. Der er derfor ikke fagligt grundlag for generelt at konkludere, at Laya er »bedre end Jev«. [3]

Den større ændring er arkitekturen omkring modellerne

Det mest interessante ved System One-bølgen er derfor måske slet ikke Jev.

Det er et opgør med idéen om, at ét stort LLM bør være intelligence layer for hele applikationen.

En mere moden AI-arkitektur kan i stedet bestå af flere forskellige komponenter:

1. 1.Deterministisk software håndterer de regler, som faktisk kan beskrives præcist.
2. 2.Decision models håndterer hurtige, probabilistiske valg som routing, classification, scoring og guardrails.
3. 3.Generative og reasoning-modeller bruges, når opgaven kræver analyse, syntese, planlægning eller produktion af nyt indhold.
4. 4.Mennesker håndterer den del af distributionen, hvor konsekvensen ved fejl er høj, eller modellernes confidence er utilstrækkelig.

Det lyder mindre spektakulært end idéen om en autonom super-agent.

Til gengæld ligner det langt mere den måde, robust enterprise software faktisk bliver bygget på.

AI-agenter har særligt brug for et billigt decision layer

Udviklingen bliver særligt relevant i takt med, at AI-agenter får flere tools og mere autonomi.

En agent skal konstant træffe små beslutninger:

Skal jeg kalde dette tool? Er resultatet godt nok? Hvilken model skal håndtere næste opgave? Er dette output sikkert? Matcher resultatet brugerens intention? Skal jeg prøve igen? Skal et menneske involveres?

I mange agentiske systemer bruger vi i dag endnu et LLM-call til hver af disse beslutninger.

Hvis hver beslutning kræver sekunder og relativt dyr inference, bliver cost og latency hurtigt multipliceret gennem workflowet.

En lille decision model kan potentielt fungere som et control layer omkring de større modeller.

Det ændrer økonomien væsentligt.

Ikke fordi den lille model kan erstatte frontier-modellen, men fordi frontier-modellen kun bliver brugt til de problemer, hvor dens capabilities faktisk er nødvendige.

Det relevante spørgsmål er derfor ikke, om Jev »bare« er en classifier

Teknisk er betegnelsen ikke urimelig.

»System One Model« er på nuværende tidspunkt TypeSafes navn for kategorien, ikke en etableret videnskabelig standard. Og classification, probability estimation, model calibration og non-autoregressive encoders eksisterede længe før Jev.

Men teknologi bliver ikke kun vigtig, når nogen opfinder et fundamentalt nyt matematisk princip.

Nogle gange sker skiftet, når eksisterende teknikker kombineres på en måde, der ændrer, hvad der praktisk kan bygges.

Det var i høj grad også historien om moderne chatmodeller.

Det, der er værd at følge ved Jev, Laya og de næste modeller i kategorien, er derfor ikke navnet System One.

Det er, om vi får et nyt praktisk intelligence primitive mellem deterministisk kode og generative LLMs: modeller, der er billige nok til at kalde konstant, hurtige nok til at ligge direkte i application flowet og præcise nok til, at deres probabilities kan bruges som en reel del af softwarearkitekturen.

Hvis det lykkes, kan konsekvensen blive større end endnu en forbedring af den næste frontier LLM.

For virksomheder betyder det i sidste ende en mere interessant udvikling: AI-systemer behøver ikke blive større for at blive bedre.

De skal blive bedre designet.

Om forfatteren

Mikkel Hempel er co-founder i Capacit og arbejder med krydsfeltet mellem nye AI-capabilities, teknologiarkitektur og deres praktiske anvendelse i virksomheder og større organisationer.