Wat zijn AI-beslissingsmodellen? Hoe ze werken en belangrijke voorbeelden

Stel je voor: je zit in een restaurant en de ober vraagt: “Plat of bruisend?” Je antwoordt niet met een alinea over je hydratatievoorkeuren; je kiest een van de twee opties die je kreeg.

Denk nu aan hoe we grote taalmodellen (LLM’s) tegenwoordig in de meeste apps gebruiken. We stellen vragen als “Gaat dit supportticket over facturatie, verzending of retouren?” en het model schrijft ons een volledige zin terug, die we vervolgens met wat code moeten parsen. In feite waren er maar drie mogelijke antwoorden, maar we betaalden toch voor een heel denkproces.

Dit is het gat dat dit nieuwe type model wil vullen. In september 2026 bracht een startup genaamd TypeSafe AI Jev uit, een model dat helemaal geen tekst schrijft.

In plaats daarvan scoret het een vaste set antwoorden en vertelt het hoe waarschijnlijk elk ervan is. Binnen een paar weken lanceerden OpenAI, Cloudflare, Perplexity en Microsoft allemaal hun eigen versies, wat laat zien hoe snel dit veld beweegt.

In dit artikel wil ik onderzoeken wat deze AI-beslissingsmodellen zijn, hoe ze werken en waar het idee eigenlijk vandaan komt (het is veel ouder dan de hype doet vermoeden). Ik kijk ook naar wat onafhankelijke benchmarks vonden.

Beslissingsmodellen in een notendop

• Een AI-beslissingsmodel neemt een input en een lijst met toegestane antwoorden, en geeft vervolgens een waarschijnlijkheid voor elk antwoord terug in plaats van tekst te genereren.
• Omdat het model antwoorden in één keer scoort, rapporteert TypeSafe dat Jev binnen 70 tot 500 milliseconden reageert, en het resultaat kan direct een if-statement in.
• Het idee is niet nieuw. Zero-shot-classifiers, rerankers en verifiers scoren al jaren kandidaten, en de releases in 2026 van TypeSafe, OpenAI, Cloudflare, Perplexity en Microsoft verpakken het vooral beter.
• In Red Hats onafhankelijke guardrail-tests gaven beslissingsmodellen geen snellere, goedkopere of betere antwoorden dan LLM-as-a-judge, en een kleine getrainde classifier kwam dicht in de buurt bij promptinjection.
• Ze werken het best als snelle, goedkope poorten rond een LLM. Test hun waarschijnlijkheden op je eigen data voordat je drempels instelt.

Wat zijn AI-beslissingsmodellen?

Een AI-beslissingsmodel is een model dat een input en een set toegestane antwoorden neemt en de waarschijnlijkheid van elk antwoord teruggeeft, zonder vrije tekst te genereren.

Het belangrijkste idee van deze modellen is dat de output al gestructureerd is.

Je hoeft nooit een zin te parsen, omdat het model alleen een van de antwoorden kan teruggeven die je het hebt gegeven. Dit betekent dat het resultaat direct een if-statement in je code kan in.

Ik denk graag aan het verschil als twee soorten tentamens.

Een groot taalmodel doet een essaytoets, waarbij het zijn antwoord woord voor woord uitschrijft, terwijl een beslissingsmodel een meerkeuzetoets doet en je ook vertelt hoe zeker het is van elk vakje (een confidentiescore).

De drie vraagtypes

Jev en de meeste Jev-alternatieven ondersteunen drie soorten vragen:

• Choice: kies één optie uit een lijst (Jev staat tot 255 opties toe), met een waarschijnlijkheid voor elk.
• Noul: de waarschijnlijkheid dat een stelling waar is; dit is TypeSafes naam voor een ja/nee-vraag.
• Score: een positie op een geordende schaal, zoals een rubric van 1 tot 5.

TypeSafe heeft ook een experimenteel Box-type voor het lokaliseren van objecten in afbeeldingen, dat ik hier oversla.

Laat me een voorbeeld geven uit TypeSafes eigen documentatie.

Je kunt een state sturen (dat is gewoon de tekst waar het model naar moet kijken) en een map met questions. Voor een choice-vraag komt elke optie met een korte beschrijving in een veld genaamd criteria.

{
  "model": "jev-latest",
  "state": "My running shoes arrived in the wrong size. Can I swap them for a size 10?",
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "Which team should handle this?",
      "criteria": {
        "returns": "Exchanges, wrong or damaged items",
        "shipping": "Delivery status, delays, lost packages",
        "billing": "Charges, invoices, payment problems"
      }
    }
  }
}

En dit was het bijbehorende antwoord:

{
  "model": "jev-1.13.0",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "returns",
      "confidence": 1.0,
      "probabilities": {
        "shipping": 0.0,
        "returns": 1.0,
        "billing": 0.0
      }
    }
  }
}

Er is geen tekst om te parsen.

Je krijgt de gekozen optie, een waarschijnlijkheid voor elke optie en een confidentiewaarde afgeleid van de hoogste waarschijnlijkheid; een plattere verdeling betekent dus lagere confidence. In de documentatie splitst een rommeliger ticket dat zowel een verkeerde maat als een dubbele afschrijving noemt de waarschijnlijkheid tussen retouren (0,61) en facturatie (0,35), en de confidence zakt naar 0,42.

Waarom TypeSafe het een “System One”-model noemt

TypeSafe beschrijft Jev als een “System One Model,” geleend uit Daniel Kahnemans boek Thinking, Fast and Slow. Waarom is dat zo?

In heel eenvoudige taal: Systeem 1 is je snelle, onderbuikgevoel-oordeel, en Systeem 2 is je langzame, stap-voor-stap redenering.

Een beslissingsmodel is bedoeld als de snelle variant.

Eén kanttekening: Systeem 1 is ook het deel van onze hersenen dat snelle fouten maakt, en tot eer van TypeSafe staat in hun eigen docs openlijk waar Jev de mist in gaat. Daar komen we later op terug.

De naam verduidelijken

Wat me in het begin in de war bracht, is dat “beslissingsmodel” al verschillende andere dingen kan betekenen. Het kan verwijzen naar:

• Beslissingstabellen in business rules-software.
• De Decision Transformer in reinforcement learning, die juist acties genereert, dus bijna het tegenovergestelde van wat we hier bespreken.
• Keuzemodellen in de economie.

Dus voor alle duidelijkheid: in dit artikel betekent een “beslissingsmodel” alleen de nieuwe categorie modellen die eind 2026 is uitgebracht en getypte antwoorden scoort in plaats van tekst te schrijven.

Hoe generatie token-voor-token werkt

Voordat we ingaan op hoe beslissingsmodellen werken, helpt het om te zien hoe een normaal LLM zijn antwoord produceert. Dat maakt het verschil, denk ik, makkelijker zichtbaar.

Een groot taalmodel werkt in een lus.

Het zet onze tekst om in tokens, voorspelt een waarschijnlijkheid voor elk token in zijn vocabulaire, kiest er één, voegt die toe aan de tekst en herhaalt dit dan.

Elke extra token in het antwoord betekent nog een forward pass door het model.

Figuur 1: Een LLM heeft één forward pass nodig voor elke token die het schrijft. Originele afbeelding door auteur.

Deze lus werkt goed voor het schrijven van e-mails, code of uitleg, maar bij simpele beslissingen kan dit voor een paar problemen zorgen:

• Je betaalt om woorden te genereren die je toch weggooit.
• Het model kan antwoorden met “Ja, want…” terwijl je alleen “ja” of “nee” vroeg, wat je parser breekt.
• Kleine fouten kunnen zich opstapelen over een lange output.
• Als je een LLM vraagt hoe zeker het is, heeft het getal dat het terugschrijft vaak weinig met de werkelijkheid te maken, zoals John Berryman van Arcturus Labs opmerkt in zijn write-up van Jev.

Beslissingsmodellen proberen precies deze problemen op te lossen.

Hoe beslissingsmodellen werken: outputs scoren

Laten we nu naar de daadwerkelijke mechaniek gaan.

Er zijn hier drie ideeën die de moeite waard zijn om te begrijpen:

1. Eén pass in plaats van een lus
2. Waar de waarschijnlijkheden vandaan komen
3. Wat “gekalibreerd” eigenlijk betekent

Laten we ze elk iets uitgebreider bekijken.

Eén pass in plaats van een lus

Een beslissingsmodel leest je input en de vragen en produceert een score voor elk toegestaan antwoord.

Die scores worden doorgaans omgezet in waarschijnlijkheden met een softmaxfunctie. Zoals je kunt raden is er geen lange lus, omdat er niets geschreven hoeft te worden.

TypeSafes documentatie zegt ook dat vragen in dezelfde request parallel worden geëvalueerd, dus extra vragen toevoegen verandert de responstijd nauwelijks.

Hier komt het grootste deel van de snelheid vandaan, en TypeSafe zegt dat Jev doorgaans in zo’n 70 tot 500 milliseconden reageert.

Figuur 2: Hetzelfde ticket, beantwoord door een LLM en door een beslissingsmodel. Originele afbeelding door auteur.

Waar de waarschijnlijkheden vandaan komen

Er is geen enkele “architectuur voor beslissingsmodellen”.

TypeSafe heeft niet gepubliceerd hoe Jev werkt, maar er zijn grofweg drie manieren om deze scores te krijgen:

• De tokenwaarschijnlijkheden van een LLM uitlezen. Je somt de antwoorden op als A, B en C, draait het model en kijkt alleen naar hoe waarschijnlijk het “A”, “B” of “C” acht als de volgende token. John Berryman bij Arcturus Labs gokte eerst dat Jev een encodermodel met een aangepaste output-head was, en wees daarna op een X-post van Harsha Gundala die iets vergelijkbaars repliceerde met tokenwaarschijnlijkheden. Geen van beide gissingen is bevestigd.
• Een scoring head toevoegen. Een kleiner encodermodel krijgt een outputlaag die elke optie direct scoort. Het open-source Laya-model gebruikt ModernBERT op deze manier.
• Een aparte scorer gebruiken. Een tweede model, zoals een reranker of rewardmodel, beoordeelt elke kandidaat.

Maak je niet druk over welke waar wordt gebruikt: alle drie eindigen op hetzelfde punt, een getal voor elk toegestaan antwoord.

Wat “gekalibreerd” betekent

Dit is het deel dat volgens mij het meest telt, dus laat me een voorbeeld geven.

Stel je voor dat een model “70% waarschijnlijk” zegt bij 100 verschillende vragen. Als het model goed gekalibreerd is, zouden ongeveer 70 van die antwoorden ook daadwerkelijk correct moeten blijken.

Kalibratie is belangrijk omdat goed gekalibreerde waarschijnlijkheden ons veilige drempels in onze code laten instellen, zoals “automatisch goedkeuren boven 90%, anders naar een mens sturen.”

Als de waarschijnlijkheden niet met de werkelijkheid overeenkomen, zijn die drempels betekenisloos.

Leveranciers trainen hierop met verliesfuncties die overmoed afstraffen.

TypeSafe noemt zijn methode Reinforcement Learning for Calibrated Decisions (RLCD), terwijl Cloudflare zegt dat het cross-entropy koppelt aan een Brier loss voor zijn Clef-modellen.

Beslissingsmodellen zijn geen nieuw idee

Dit verrast je misschien, maar het idee om kandidaten te scoren in plaats van ze te genereren bestaat al jaren.

In mijn ogen zijn beslissingsmodellen de nieuwste en meest handige versie hiervan, niet een volledig nieuwe uitvinding. Dit zijn de belangrijkste modellijnen waarop het voortbouwt.

Figuur 3: Scoren in plaats van genereren gaat terug tot 2019, en beslissingsmodellen zijn de versie van 2026. Originele afbeelding door auteur.

Zero-shot-classifiers

Al in 2019 konden modellen zoals BART-large-mnli tekst indelen in labels waarop ze nooit waren getraind.

Ze deden dit door uitspraken als “deze tekst gaat over facturatie” te scoren voor elk mogelijk label.

Het AI-safetyteam van Red Hat suggereert dat beslissingsmodellen in feite gewoon deze zero-shot-classifiers zijn onder een nieuwe naam.

Rerankers en cross-encoders

Als je een RAG-systeem hebt gebouwd, heb je er mogelijk een gebruikt. Je haalt eerst snel een shortlist op (bijvoorbeeld 50 documenten), daarna leest een cross-encoder je vraag en elk document samen en kent elk paar een relevantiescore toe.

Er wordt niets gegenereerd; in plaats daarvan worden de documenten gewoon herordend op basis van hun score.

Rewardmodellen en verifiers

Dit zijn scorers die antwoorden beoordelen die een LLM al heeft gegenereerd.

In 2021 lieten OpenAI-onderzoekers zien dat het toevoegen van een verifier aan een model een boost gaf op rekenkundige schoolwiskunde die grofweg gelijk stond aan het 30 keer groter maken van het model, wat ik opvallend vind.

Twee jaar later liet het “Let’s Verify Step by Step”-paper zien dat het scoren van elke redeneringsstap nog beter werkt dan alleen het eindantwoord scoren.

Best-of-N en generate-then-filter

De simpele versie is: genereer veel antwoorden, scoor elk en houd de beste over. AlphaCode van DeepMind (2022) dreef dit tot het extreme door tot een miljoen programma’s per probleem te genereren, ongeveer 99% weg te gooien met voorbeeldtests en er dan slechts 10 in te dienen.

In gesimuleerde evaluaties op eerdere Codeforces-wedstrijden scoorde het gemiddeld in de top 54,3% van menselijke deelnemers.

Eén waarschuwing: als je te hard pusht op een onvolmaakte scorer, gaat de kwaliteit uiteindelijk omlaag omdat de generator de fouten van de scorer gaat uitbuiten.

De technische term hiervoor is reward overoptimization.

LLM-as-a-judge

Dit is wanneer een grote LLM de output van een ander model beoordeelt.

Een studie uit 2023 vond dat GPT-4 meer dan 80% van de tijd met menselijke beoordelaars overeenkwam, maar ook biases had, zoals een voorkeur voor langere antwoorden of voor het antwoord dat als eerste werd getoond.

Beslissingsmodellen worden deels verkocht als een goedkoper, gestructureerd alternatief voor deze judges.

Energy-based models en JEPA

Een energy-based model geeft een lage “energie”-score aan een input en antwoord die goed bij elkaar passen en een hoge score aan paren die dat niet doen.

Een antwoord kiezen betekent dan simpelweg de laagste energie vinden, wat opnieuw neerkomt op kandidaten scoren.

Yann LeCun betoogt al jaren dat token-voor-token-generatie niet het pad is naar echte intelligentie, en dat energy-based benaderingen en JEPA een betere richting zijn.

Belangrijke beslissingsmodellen in 2026

Nu wil ik het hebben over de modellen die daadwerkelijk zijn uitgebracht. Het gaat hier erg snel, dus ik houd elk voorbeeld kort.

TypeSafes Jev

TypeSafe AI is een startup uit San Francisco, opgericht door Diogo Almeida, een voormalig onderzoeker bij OpenAI, en kwam op 15 september 2026 uit stealth met Jev en een seedronde van $40 miljoen onder leiding van DCVC.

Jev is een gehoste API. In productie accepteert het alleen tekst; beeldinput is experimenteel en vereist een opt-in-header. De prijs wordt berekend op invoertokens, en de outputs zijn gratis, wat logisch is als de output slechts enkele getallen zijn.

Jev 1.14 volgde op 14 oktober, hoewel de alias jev-latest nog steeds naar 1.13.0 wijst, de versie die Red Hat later in dit artikel testte.

Er was veel buzz rond de lancering. Vercel zei dat ongeveer 13% van zijn betalende teams Jev via de AI Gateway uitprobeerde binnen de eerste 24 uur, hoewel het op dat moment gratis was op de gateway.

OpenAI’s Decisions API

OpenAI kondigde zijn Decisions API aan op DevDay op 29 september 2026.

Het werkt met door gebruikers gedefinieerde vragen met een vaste set antwoorden en is gebouwd op GPT-6 Luna. Het ging op 6 oktober naar publieke bèta en kan ook afbeeldingen verwerken, wat Jev alleen experimenteel ondersteunt.

Cloudflares Clef

Cloudflare bracht Clef en een kleinere Clef-flash uit op 1 oktober 2026, met open gewichten en hosting op Workers AI. Beide zijn gebouwd op Qwen-modellen en accepteren Jev-achtige requests, dus code geschreven voor Jev kan met heel weinig wijzigingen naar Clef worden gericht.

Andere modellen

Wat me echt opviel bij het samenstellen van deze sectie is dat de meeste open en big tech-modellen hier fijngestemde versies van normale LLM’s zijn. Laya is de uitzondering: het is een encoder met een decision head. De internals van Jev zijn niet openbaar.

Mijns inziens ondersteunt dit het idee dat de echte innovatie de verpakking is (dus de interface en de training voor kalibratie) in plaats van een gloednieuwe architectuur.

Beslissingsmodellen vs LLM’s vs classifiers

De duidelijkste manier om te beslissen wanneer je welke gebruikt, is een vergelijking:

Wanneer welke gebruiken

Mijn vuistregel is deze:

• Afgebakende antwoorden en geen trainingsdata: een beslissingsmodel is een goede match.
• Één taak, veel gelabelde data en strakke snelheidslimieten: een fijngestemde classifier is moeilijk te verslaan.
• Open einde-output: gebruik een LLM.
• Een lastig probleem met een goedkope manier om antwoorden te checken: gebruik een LLM plus een verifier.

Ik geloof dat de beste systemen al deze opties combineren.

Ik zie beslissingsmodellen fungeren als snelle poorten rond een LLM. Een poort beslist:

• Welke tool aangeroepen moet worden.
• Of een input veilig is.
• Of een resultaat een mens nodig heeft.

Zo draait de dure LLM alleen wanneer er echt iets geschreven moet worden.

Wat onafhankelijke tests laten zien

Deze sectie is het belangrijkst, omdat de meeste grote cijfers die je online ziet van de leveranciers zelf komen. Zelfs TypeSafe geeft toe dat de headline-winst in snelheid en kosten aan de hoge kant is van wat je in de praktijk zou zien.

De Red Hat guardrail-benchmark

In oktober 2026 vergeleek het AI-safetyteam van Red Hat negen guardrail-opstellingen op twee taken: promptinjection detecteren en onveilige content detecteren.

DiffusionGemma is een Gemma tekst-diffusion-model geserveerd via vLLM.

Dit zijn de interessantste resultaten:

Jev eindigde eerste op content safety, 0,67 procentpunt voor DiffusionGemma (de Qwen-judge was derde), en de Qwen-judge werd eerste op promptinjection.

Die splitsing is waarom Red Hat nog steeds kan zeggen dat beslissingsmodellen overall geen kwaliteitswinst lieten zien ten opzichte van LLM-judges.

Maar wat ik het interessantst vind, is dat een classifier met 200 miljoen parameters slechts 0,3 procentpunt achterbleef op promptinjection, met een mediane latency onder de 100 milliseconden vergeleken met ongeveer 348 voor Jev.

Jev’s latency omvatte wel een trip over de Atlantische Oceaan, aangezien de tests vanuit het VK draaiden en de servers van TypeSafe in de VS staan.

Die hop verklaart alleen het gat ten opzichte van de lokale CPU-modellen. Qwen, Nemotron en DiffusionGemma draaiden ook op een cluster in de VS, en Qwen was nog steeds sneller dan Jev.

Toch concludeerde Red Hat dat beslissingsmodellen in hun tests geen snellere, goedkopere of betere antwoorden gaven dan LLM-as-a-judge, behalve Laya, wiens kleine formaat een echt voordeel is als je om zijn beperkingen heen kunt prompten.

De “Just Ask Jev”-paper

Een onderzoekspaper van universiteitsonderzoekers, geplaatst op arXiv in september 2026, testte Jev op 44 alignment-benchmarks.

De resultaten waren op een interessante manier gemengd:

• Jev was goed in het hoger ranken van alignment-failures boven niet-failures, met een mediane AUROC van 0,886 op de 31 benchmarks die een generieke ja/nee-vraag ondersteunen. AUROC meet hoe goed een score positieve voorbeelden boven negatieve rangschikt, waarbij 0,5 toeval is en 1 perfecte ranking.
• Het kostte ongeveer $0,30 voor werk dat ongeveer $18,96 kostte met LLM-judges, over de 19 benchmarks die een API-judge gebruiken.
• Het was goed gekalibreerd wanneer alle benchmarks samen werden genomen, maar niet binnen individuele benchmarks.
• Alleen de helft van de antwoorden behouden die het verst van 50% af lagen verhoogde de mediane nauwkeurigheid van 0,793 naar 0,933.
• De auteurs noemen beperkingen: één Jev-versie, alleen Engels, kleine doelsystemen van 2B tot 7B, en labels die grotendeels zijn gegenereerd door bestaande scorers.

Ik denk dat het punt over selectieve voorspellingen in de praktijk erg nuttig is.

Het laat zien dat een simpele opzet waarbij het beslissingsmodel de makkelijke gevallen afhandelt en de onzekere naar een LLM of een persoon doorspeelt, een goede strategie is.

Hands-on: bouw een beslissingsmodel uit een kleine LLM

Laten we nu zelf een beslissingsmodel bouwen.

We gaan een kleine open LLM omzetten in een beslissingsmodel met de tokenwaarschijnlijkheden-truc van eerder en vervolgens checken of we de waarschijnlijkheden daadwerkelijk kunnen vertrouwen.

Eerst installeren we de packages met dit commando (dit kun je allemaal in een gratis Colab-notebook draaien):

pip install transformers torch datasets sentence-transformers numpy

Stap 1: Maak van een LLM een scorer

We gebruiken Qwen2.5-0.5B-Instruct, die klein genoeg is om op een CPU te draaien.

Het idee is simpel: we labelen de opties met letters, draaien het model één keer en kijken alleen naar de waarschijnlijkheden van die letters als volgende token.

import torch
from transformers import AutoTokenizer, AutoModelForCausalLM

model_name = "Qwen/Qwen2.5-0.5B-Instruct"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(model_name)
model.eval()

def option_logits(state, question, options):
    letters = [chr(ord("A") + i) for i in range(len(options))]
    option_text = "\n".join(f"{l}. {o}" for l, o in zip(letters, options))
    messages = [
        {"role": "system", "content": "Answer with a single letter only."},
        {"role": "user", "content": f"{state}\n\nQuestion: {question}\n{option_text}"},
    ]
    prompt = tokenizer.apply_chat_template(
        messages, tokenize=False, add_generation_prompt=True
    )
    inputs = tokenizer(prompt, return_tensors="pt")

    with torch.no_grad():
        next_token_logits = model(**inputs).logits[0, -1].float()

    letter_ids = [tokenizer.encode(l, add_special_tokens=False)[0] for l in letters]
    return next_token_logits[letter_ids]

def decide(state, question, options, temperature=1.0):
    logits = option_logits(state, question, options)
    probs = torch.softmax(logits / temperature, dim=-1)
    return {o: round(p.item(), 3) for o, p in zip(options, probs)}

Let op dat we nooit generate() aanroepen. We doen één forward pass, bewaren de scores voor “A”, “B”, “C”, enzovoort, en gooien al het andere weg.

print(decide(
    state="My running shoes arrived in the wrong size. Can I swap them for a size 10?",
    question="Which team should handle this?",
    options=["returns", "shipping", "billing"],
))

print(decide(
    state="The app crashes every time I open the settings page.",
    question="Does this message describe a software bug?",
    options=["yes", "no"],
))

En dat is het echt. We hebben zojuist in ongeveer 30 regels een werkend beslissingsmodel gemaakt.

Een ja/nee-vraag is simpelweg een choice-vraag met twee opties.

Stap 2: Herken de eigenaardigheden

Laten we nu zien waar deze eenvoudige versie begint te worstelen.

Probeer de volgorde van de opties te wisselen en draai dezelfde vraag opnieuw:

options = ["returns", "shipping", "billing"]
state = "My shoes arrived late and in the wrong size, and I was charged twice."
question = "Which team should handle this?"

print(decide(state, question, options))
print(decide(state, question, list(reversed(options))))

Bij rommelige inputs als deze zullen we vaak zien dat de waarschijnlijkheden verschuiven alleen omdat de opties verhuisden.

Dit heet ordebias, en TypeSafe noemt een neiging naar de eerste optie zelfs als een van Jev’s bekende zwaktes.

Je kunt ook zien dat het model vrij vaak bijna-100%-antwoorden geeft. Berryman draaide een mooie test op Jev zelf, waarbij hij vertelde dat een munt 60% van de tijd op kop landt, en de ja/nee-vraag gaf 0,58 terug, wat dichtbij is.

Maar de choice-vraag (“heads or tails?”) gaf 0,99 voor heads, omdat de waarschijnlijkheid instortte op het meer waarschijnlijke antwoord.

Stap 3: Meet en fix kalibratie

Dit is de stap die ik vind dat iedereen zou moeten draaien. We nemen 400 nieuwsitems uit de AG News-dataset (elk is een kop plus een korte beschrijving), die vier onderwerpen heeft, en checken of onze waarschijnlijkheden met de werkelijkheid overeenkomen.

import numpy as np
from datasets import load_dataset

data = load_dataset("fancyzhx/ag_news", split="test").shuffle(seed=42).select(range(400))
labels = ["World", "Sports", "Business", "Science and technology"]
question = "What is the topic of this news headline?"

all_logits, targets = [], []
for row in data:
    all_logits.append(option_logits(row["text"], question, labels))
    targets.append(row["label"])

all_logits = torch.stack(all_logits)
targets = torch.tensor(targets)

Vervolgens hebben we een manier nodig om kalibratie te meten. Expected calibration error (ECE) groepeert de voorspellingen in confidence-bins en controleert hoe ver het gemiddelde vertrouwen in elke bin afligt van de werkelijke nauwkeurigheid.

Voor de duidelijkheid: lager is beter:

def expected_calibration_error(probs, targets, n_bins=10):
    confidences, predictions = probs.max(dim=-1)
    correct = (predictions == targets).float()
    bins = np.linspace(0, 1, n_bins + 1)
    ece = 0.0
    for lo, hi in zip(bins[:-1], bins[1:]):
        mask = (confidences > lo) & (confidences <= hi)
        if mask.any():
            gap = abs(correct[mask].mean() - confidences[mask].mean())
            ece += mask.float().mean() * gap
    return float(ece), float(correct.mean())

Hier komt nu de truc.

We splitsen onze data in tweeën, gebruiken de eerste helft om een temperatuur te vinden die de waarschijnlijkheden eerlijker maakt en testen dan op de tweede helft.

Een temperatuur boven 1 verzacht overzekere voorspellingen, terwijl een temperatuur onder 1 onderzekere voorspellingen aanscherpt.

calib_logits, test_logits = all_logits[:200], all_logits[200:]
calib_targets, test_targets = targets[:200], targets[200:]

def nll(temperature):
    probs = torch.softmax(calib_logits / temperature, dim=-1)
    picked = probs[torch.arange(len(calib_targets)), calib_targets]
    return -torch.log(picked + 1e-12).mean().item()

temperatures = [float(t) for t in np.linspace(0.5, 5.0, 46)]
best_t = min(temperatures, key=nll)

before = expected_calibration_error(torch.softmax(test_logits, dim=-1), test_targets)
after = expected_calibration_error(torch.softmax(test_logits / best_t, dim=-1), test_targets)

print(f"Best temperature: {best_t:.2f}")
print(f"Before: ECE={before[0]:.3f}, accuracy={before[1]:.3f}")
print(f"After:  ECE={after[0]:.3f}, accuracy={after[1]:.3f}")

De nauwkeurigheid verandert niet, omdat delen door een temperatuur nooit verandert welke optie als eerste eindigt.

Alleen het vertrouwen verandert.

Je exacte cijfers hangen af van je run, maar de ECE op de testhelft zou meestal moeten dalen. Met slechts 200 testitems is de schatting ruiserig, dus lees niet te veel in kleine verschillen.

De les is simpel: dat een model gekalibreerd is op andermans data betekent niet dat het gekalibreerd is op jouw data.

Stap 4: Score kandidaten met een cross-encoder

Om te laten zien hoe gebruikelijk dit “scoren, niet genereren”-idee eigenlijk is, hier hetzelfde in een RAG-setting.

Een cross-encoder scoort elke passage tegen een vraag en we sorteren ze gewoon:

from sentence_transformers import CrossEncoder

reranker = CrossEncoder("cross-encoder/ms-marco-MiniLM-L6-v2")

query = "How do I get a refund for a double charge?"
passages = [
    "Our app supports dark mode on all devices.",
    "If you were charged twice, contact billing and we will refund the duplicate payment.",
    "Refunds are processed within five business days.",
    "You can change your password from the settings page.",
]

for result in reranker.rank(query, passages):
    print(round(float(result["score"]), 3), passages[result["corpus_id"]])

Opnieuw wordt er niets gegenereerd: het model geeft elk kandidaat gewoon een getal.

Gebruiksscenario’s voor beslissingsmodellen

Dit zijn de use-cases die het vaakst terugkomen:

Het robotica-punt vind ik persoonlijk het interessantst.

Berryman suggereert dat een model als Jev kan zitten tussen een trage LLM die high-level plannen maakt en de kinematische modellen die de gewrichten van een robot bewegen.

Het is wel goed om te weten dat TypeSafes bekende Doom-demo Jev teksttelemetrie voerde in plaats van ruwe beelden.

Beperkingen van beslissingsmodellen

Beslissingsmodellen zijn nuttig, maar ik wil ze niet oversellen.

Dit zijn de belangrijkste beperkingen die ik vond om in gedachten te houden:

• Het kan alleen kiezen uit jouw lijst. Als het juiste antwoord ontbreekt in je opties, kan het model het niet verzinnen. Daarom raadt TypeSafe aan om een “overig”-optie toe te voegen of een begeleidende ja/nee-vraag die checkt of er überhaupt iets past.
• Zelfverzekerd verkeerd is nog steeds verkeerd. Geen off-format antwoorden betekent niet geen fouten.
• Kalibratie draagt niet automatisch over. Test je drempels op een kleine gelabelde steekproef van je eigen data.
• Prompts dragen niet altijd over. Red Hat vond dat een prompt die was getuned voor Laya de nauwkeurigheid met bijna 18 procentpunten verhoogde maar Jev ongeveer 3,7 procentpunt slechter maakte.
• Er is geen uitleg. Dit maakt beslissingen lastiger te auditen, dus log je inputs en houd een LLM achter de hand voor gevallen die een reden vereisen.
• Er zijn bekende zwakke plekken. In TypeSafes eigen docs staan wiskunde, data, lange irrelevante context, adversariële tekst en een bias richting de eerste optie.

Tot slot

AI-beslissingsmodellen nemen een heel oud idee van kandidaten scoren in plaats van antwoorden genereren en maken het veel makkelijker te gebruiken.

Je hebt geen trainingsdata nodig; je krijgt getypeerde antwoorden terug, en je kunt veel vragen tegelijk stellen.

Naar mijn mening is deze verpakking de echte innovatie.

Ik verwacht dat beslissingsmodellen rondom LLM’s komen te zitten als snelle, goedkope poorten die de simpele beslissingen afhandelen, zodat het dure model alleen draait wanneer er echt iets geschreven moet worden.