Karpathy’s March of Nines laat zien waarom 90% AI-betrouwbaarheid niet eens in de buurt komt van genoeg

“Als je een demo krijgt en iets werkt 90% van de tijd, dan zijn dat alleen de eerste negen.” — Andrej Karpathy

De “Maart van Negens“kadert een gemeenschappelijke productierealiteit: je kunt de eerste 90% betrouwbaarheid bereiken met een sterke demo, en elke extra negen vereist vaak vergelijkbare technische inspanningen. Voor bedrijfsteams is de afstand tussen “werkt meestal” en “werkt als betrouwbare software” bepalend voor de acceptatie.

De samengestelde wiskunde achter de March of Nines

“Elke negen is dezelfde hoeveelheid werk.” – Andrej Karpathy

Agentische workflows verergeren fouten. Een typische bedrijfsstroom kan het volgende omvatten: intentieparsering, ophalen van context, planning, een of meer tooloproepen, geldigmakingopmaak en auditregistratie. Als een workflow n stappen heeft en elke stap met waarschijnlijkheid slaagt Phet end-to-end succes is ongeveer p^n.

In een workflow van 10 stappen wordt het end-to-end succes vergroot door de mislukkingen van elke stap. Gecorreleerde storingen (authenticatie, snelheidslimieten, connectoren) zullen domineren, tenzij u gedeelde afhankelijkheden verhardt.

Definieer betrouwbaarheid als meetbare SLO’s

“Het is veel logischer om wat meer tijd te besteden aan het concreter maken van uw aanwijzingen.” — Andrej Karpathy

Teams behalen hogere negens door betrouwbaarheid om te zetten in meetbare doelstellingen en vervolgens te investeren in controles die de variantie verminderen. Begin met een kleine set SLI’s die zowel het gedrag van het model als het omringende systeem beschrijven:

• Voltooiingspercentage van de workflow (succes of expliciete escalatie).

• Succespercentage van tool-calls binnen time-outs, met strikte schemavalidatie op invoer en uitvoer.

• Schema-geldige uitvoersnelheid voor elk gestructureerd antwoord (JSON/argumenten).

• Beleidsnalevingspercentage (PII, geheimen en beveiligingsbeperkingen).

• p95 end-to-end latentie en kosten per workflow.

• Terugvalpercentage (veiliger model, gegevens in de cache of menselijke beoordeling).

Stel SLO-doelen in per workflowlaag (laag/gemiddeld/hoog impact) en beheer een foutenbudget, zodat experimenten onder controle blijven.

Negen hefbomen die op betrouwbare wijze negens toevoegen

1) Beperk de autonomie met een expliciete workflowgrafiek

De betrouwbaarheid neemt toe wanneer het systeem begrensde statussen en deterministische afhandeling heeft voor nieuwe pogingen, time-outs en terminale uitkomsten.

• Modelaanroepen bevinden zich in een statusmachine of een DAG, waar elk knooppunt toegestane tools, maximale pogingen en een succespredicaat definieert.

• Behoud de status met idempotente sleutels, zodat nieuwe pogingen veilig zijn en fouten kunnen worden opgespoord.

2) Handhaaf contracten bij elke grens

De meeste productiefouten beginnen als interfaceafwijking: verkeerd opgemaakte JSON, ontbrekende velden, verkeerde eenheden of verzonnen identificatiegegevens.

• Gebruik JSON Schema/protobuf voor elke gestructureerde uitvoer en valideer de serverzijde voordat een tool wordt uitgevoerd.

• Gebruik opsommingen, canonieke ID’s en normaliseer tijd (ISO-8601 + tijdzone) en eenheden (SI).

3) Laagvalidators: syntaxis, semantiek, bedrijfsregels

Schemavalidatie vangt opmaak op. Semantische en bedrijfsregelcontroles voorkomen plausibele antwoorden die systemen kapot maken.

• Semantische controles: referentiële integriteit, numerieke grenzen, toestemmingscontroles en deterministische joins op basis van ID, indien beschikbaar.

• Bedrijfsregels: goedkeuringen voor schrijfacties, beperkingen op het gebied van gegevenslocatie en beperkingen op klantniveau.

4) Route op basis van risico met behulp van onzekerheidssignalen

Acties met een grote impact verdienen meer zekerheid. Op risico gebaseerde routing maakt van onzekerheid een producteigenschap.

• Gebruik vertrouwenssignalen (classificatoren, consistentiecontroles of een tweede-modelverificateur) om de routering te bepalen.

• Zet risicovolle stappen achter sterkere modellen, aanvullende verificatie of menselijke goedkeuring.

5) Gereedschapsoproepen van engineers zoals gedistribueerde systemen

Connectors en afhankelijkheden domineren vaak de faalpercentages in agentische systemen.

• Pas time-outs per tool toe, ga terug met jitter, stroomonderbrekers en gelijktijdigheidslimieten.

• Versietoolschema’s en valideer toolreacties om stille breuk te voorkomen wanneer API’s veranderen.

6) Maak het ophalen voorspelbaar en waarneembaar

De ophaalkwaliteit bepaalt hoe gegrond uw aanvraag zal zijn. Behandel het als een dataproduct met versiebeheer en dekkingsstatistieken.

• Houd het aantal lege ophaalacties, de recentheid van documenten en het aantal treffers bij gelabelde zoekopdrachten bij.

• Wijzigingen in de scheepsindex met kanaries, zodat u weet of iets zal mislukken voordat het mislukt.

• Pas toegang en redactie met de minste bevoegdheden toe op de ophaallaag om het risico op lekkage te verminderen.

7) Bouw een pijplijn voor productie-evaluatie

De latere negens zijn afhankelijk van het snel vinden van zeldzame mislukkingen en het voorkomen van regressies.

8) Investeer in waarneembaarheid en operationele respons

Zodra storingen zeldzaam worden, wordt de snelheid van diagnose en herstel de beperkende factor.

• Verzend sporen/reeksen per stap, sla geredigeerde aanwijzingen op en tool-I/O met krachtige toegangscontroles, en classificeer elke fout in een taxonomie.

• Gebruik runbooks en ‘veilige modus’-schakelaars (risicovolle tools uitschakelen, van model wisselen, menselijke goedkeuring vereisen) voor snelle mitigatie.

9) Verzend een autonomieschuifregelaar met deterministische fallbacks

Feilbare systemen hebben toezicht nodig, en productiesoftware heeft een veilige manier nodig om de autonomie in de loop van de tijd te verhogen. Traktatie autonomie als een knop, niet als een schakelaar, en maak het veilige pad de standaard.

• Standaard ingesteld op alleen-lezen of omkeerbare acties, waarbij expliciete bevestiging (of goedkeuringsworkflows) vereist is voor schrijfbewerkingen en onomkeerbare bewerkingen.

• Bouw deterministische fallbacks: antwoorden die alleen kunnen worden opgehaald, antwoorden in het cachegeheugen, op regels gebaseerde afhandelingen of escalatie naar menselijke beoordeling wanneer het vertrouwen laag is.

• Maak veilige modi per tenant zichtbaar: schakel risicovolle tools/connectoren uit, forceer een sterker model, verlaag de temperatuur en verscherp de time-outs tijdens incidenten.

• Ontwerp hervatbare overdrachten: houd de status vol, toon het plan/verschil en laat een beoordelaar het goedkeuren en hervatten vanaf de exacte stap met een idempotentiesleutel.

Implementatieschets: een begrensde stappenwrapper

Een kleine verpakking rond elke model-/toolstap zet onvoorspelbaarheid om in beleidsgestuurde controle: strikte validatie, begrensde nieuwe pogingen, time-outs, telemetrie en expliciete fallbacks.

def run_step(naam, poging_fn, validate_fn, *, max_attempts=3, time-out_s=15):

# traceer alle nieuwe pogingen binnen één bereik

span = start_span(naam)

voor poging binnen bereik(1, max_attempts + 1):

poging:

# gebonden latentie, zodat één stap de workflow niet kan vertragen

met deadline(timeout_s):

uit = poging_fn()

# poort: schema + semantische + zakelijke invarianten

validate_fn(uit)

# succespad

metric(“stap_success”, naam, poging=poging)

terug uit

behalve (TimeoutError, UpstreamError) als e:

# voorbijgaand: opnieuw proberen met jitter om stormen met nieuwe pogingen te voorkomen

span.log({“poging”: poging, “err”: str(e)})

sleep(jittered_backoff(poging))

behalve ValidationError als e:

# slechte uitvoer: probeer het één keer opnieuw in de “veiligere” modus (lagere temperatuur / striktere prompt)

span.log({“poging”: poging, “err”: str(e)})

out = poging_fn(mode=‘veiliger’)

# fallback: houd het systeem veilig als er geen nieuwe pogingen meer zijn

metric(“step_fallback”, naam)

return EscalateToHuman(reason=f”{naam} mislukt”)

Waarom bedrijven vasthouden aan de latere negens

Betrouwbaarheidstekorten vertalen zich in bedrijfsrisico’s. McKinsey’s wereldwijde onderzoek uit 2025 rapporteert dat 51% van de organisaties die AI gebruiken minstens één negatief gevolg heeft ondervonden, en dat bijna een derde gevolgen rapporteerde die verband hielden met de onnauwkeurigheid van AI. Deze uitkomsten stimuleren de vraag naar sterkere metingen, vangrails en operationele controles.

Afsluitende checklist

• Kies een topworkflow, definieer de voltooiings-SLO en de statuscodes van de instrumentterminal.

• Voeg contracten en validators toe rond elke modeluitvoer en tool-invoer/-uitvoer.

• Behandel connectoren en het terughalen ervan als eersteklas betrouwbaarheidswerk (time-outs, stroomonderbrekers, kanaries).

• Leid acties met een grote impact via hogere zekerheidspaden (verificatie of goedkeuring).

• Maak van elk incident een regressietest in jouw gouden set.

De negens komen tot stand via gedisciplineerde engineering: begrensde workflows, strikte interfaces, veerkrachtige afhankelijkheden en snelle operationele leerlussen.

Nikhil Mungel bouwt al meer dan 15 jaar gedistribueerde systemen en AI-teams bij SaaS-bedrijven.