Karpathy’s March of Nines laat zien waarom 90% AI-betrouwbaarheid niet genoeg is

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

“Negen maart” schetst een gemeenschappelijke productierealiteit: je kunt de eerste keer een betrouwbaarheid van 90% bereiken met een sterke demo, en elke extra negen demo’s vereisen vaak vergelijkbare technische inspanningen. Voor bedrijfsteams bepaalt de kloof tussen “werkt meestal” en “werkt als betrouwbare software” de implementatie.

De wiskunde achter de March of Nines

“Elke negen is evenveel werk.” – Andrej Karpati

Het samenvoegen van de agentwerkstroom is mislukt. Een typische bedrijfsstroom kan het volgende omvatten: intentieparsering, ophalen van context, planning, een of meer tooloproepen, geldigmakingopmaak, en auditopname. Als een workflow n stappen heeft en elke stap met waarschijnlijkheid slaagt PHet end-to-end succes is ca p^n.

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

Definieer betrouwbaarheid als meetbare SLO’s

“Het is veel logischer om meer tijd te nemen om concreter te zijn in uw verzoeken.” — Andrej Karpati

Teams behalen hogere negens door van betrouwbaarheid een meetbaar doel te maken en vervolgens te investeren in controles die de variantie verminderen. Begin met een kleine set SLI’s die het gedrag van het model en het omringende systeem beschrijven:

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

• Succespercentage van tooloproepen binnen tijdslimieten, met strikte schemavalidatie op input en output.

• Schema geldig uitvoerniveau voor elk gestructureerd antwoord (JSON/argumenten).

• Nalevingsniveau van beleid (PII, geheimen en beveiligingsbeperkingen).

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

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

Stel SLO-doelen in per workflowniveau (laag/gemiddeld/hoog impact) en beheer foutbudgetten zodat experimenten onder controle blijven.

Negen hendels die op betrouwbare wijze het getal negen toevoegen

1) Beperk de autonomie met expliciete workflowgrafieken

De betrouwbaarheid neemt toe wanneer het systeem beperkte statussen heeft en een deterministische afhandeling van nieuwe pogingen, time-outs en eindresultaten.

• Modelaanroepen bevinden zich binnen een statusmachine of DAG, waar elk knooppunt de toegestane tools, maximale inspanning en succespredikaat bepaalt.

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

2) Handhaaf contracten bij elke grens

De meeste productiefouten ontstaan ​​door afwijkingen in de interface: onjuiste JSON-opmaak, ontbrekende velden, onjuiste eenheden of ontdekte ID’s.

• Gebruik JSON Schema/protobuf voor gestructureerde uitvoer en validatie aan de serverzijde voordat tools worden uitgevoerd.

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

3) Laagvalidators: syntaxis, semantiek, bedrijfsregels

Schemavalidatie legt de opmaak vast. Semantische controles en bedrijfsregels voorkomen dat redelijke antwoorden het systeem doorbreken.

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

• Bedrijfsregels: goedkeuring voor schrijfacties, beperkingen op de locatie van gegevens en beperkingen op klantniveau.

4) Op risico gebaseerde routering maakt gebruik van onzekerheidssignalen

Acties met een grote impact verdienen hogere garanties. Op risico gebaseerde routing zet onzekerheid om in producteigenschappen.

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

• Sluit riskante stappen achter robuustere modellen, aanvullende verificatie of menselijke goedkeuring.

5) Bel ingenieurstools zoals gedistribueerde systemen

Connectors en afhankelijkheden domineren vaak de foutpercentages in agentsystemen.

• Implementeer time-outs per apparaat, back-off met jitter, stroomonderbrekers en gelijktijdigheidslimieten.

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

6) Maak het ophalen voorspelbaar en waarneembaar

De kwaliteit van de opname bepaalt hoe robuust uw applicatie 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.

• De scheepvaartindex verandert met kanaries, zodat u weet of er iets misgaat voordat het mislukt.

• Dwing toegang en redactie met de minste bevoegdheden af ​​op de ophaallaag om het risico op lekken te verminderen.

7) Zet ​​een productie-evaluatielijn op

De volgende negen mislukkingen waren afhankelijk van het snel vinden van zeldzame mislukkingen en het voorkomen van regressie.

8) Investeer in operationele observatie- en responsmogelijkheden

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

• Voer traceringen/bereiken per stap uit, sla geredigeerde opdrachten en tool-I/O op met krachtige toegangscontroles, en classificeer elke fout in een taxonomie.

• Gebruik runbooks en ‘veilige modus’-knoppen (risicovolle tools uitschakelen, modellen vervangen, menselijke goedkeuring vereisen) voor snelle mitigatie.

9) Schuifregelaar voor scheepsautonomie met deterministische terugval

Defecte systemen vereisen toezicht, en productiesoftware vereist veilige manieren om de autonomie in de loop van de tijd te vergroten. Verpleegkundige autonomie als een knop, niet als een schakelaar, en maak beveiligd pad de standaard.

• De standaardwaarde is alleen-lezen of omkeerbaar, waardoor expliciete bevestiging (of goedkeuringsworkflow) 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 vertrouwensniveau laag is.

• Stel veilige modi per tenant bloot: schakel risicovolle apparaten/connectoren uit, forceer krachtigere modellen, verlaag de temperaturen en verkort de wachttijden tijdens incidenten.

• Ontwerp een hervatbare overdracht: behoud de status, toon plannen/verschillen, en laat reviewers het goedkeuren en verder gaan met de belangrijkste idempotentie.

Implementatieschets: begrensde stappenwrapper

Kleine wrappers in elke stap van het model/tool ​​zetten onzekerheid om in op beleid gebaseerde controle: strikte validatie, beperkte nieuwe pogingen, time-outs, telemetrie en expliciete fallbacks.

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

# volg alle nieuwe pogingen binnen een bereik

span = start_span(naam)

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

poging:

# latentie is gebonden zodat een enkele stap de workflow niet kan stoppen

met time-out (timeout_s):

uit = try_fn()

# gateway: schema + semantiek + bedrijfsinvarianten

validate_fn(afsluiten)

# succespad

metric(“succes_step”, naam, try=try)

kom terug naar buiten

behalve (TimeoutError, UpstreamError) als e:

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

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

slaap(jittered_backoff(proberen))

behalve ValidationError als e:

# slechte uitvoer: probeer het opnieuw in de “veiligere” modus (lagere temperatuur / strenger commando)

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

exit = try_fn(mode=‘veiliger’)

# fallback: houdt het systeem veilig als er een time-out voor nieuwe pogingen optreedt

metric(“fallback_step”, naam)

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

Waarom blijven bedrijven vasthouden aan de laatste negen?

Betrouwbaarheidstekorten vertalen zich in bedrijfsrisico’s. Wereldwijd McKinsey-onderzoek 2025 rapporteerde dat 51% van de organisaties die AI gebruiken, ten minste één negatief gevolg ondervond, en bijna een derde rapporteerde gevolgen die verband hielden met AI-onnauwkeurigheden. Deze resultaten stimuleren de vraag naar sterkere metingen, vangrails en operationele controles.

Afsluitende checklist

• Selecteer de bovenste workflow, specificeer de voltooiings-SLO en de statuscode van de instrumentterminal.

• Voeg contracten en validators toe rond elke modeluitvoer en toolinvoer/uitvoer.

• Beschouw connectoren en pickups als een eersteklas betrouwbaarheidsjob (time-outs, stroomonderbrekers, kanaries).

• Stimuleer acties met een grote impact via hogere zekerheidstrajecten (verificatie of goedkeuring).

• Verander elke gebeurtenis in een regressietest in jouw gouden serie.

Deze negen dingen worden bereikt door gedisciplineerde engineering: beperkte workflows, strakke interfaces, robuuste afhankelijkheden en snelle operationele leerlussen.

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