La Marcia dei Nove di Karpathy mostra perché l’affidabilità dell’IA al 90% non è nemmeno lontanamente sufficiente

“Quando ottieni una demo e qualcosa funziona il 90% delle volte, sono solo le prime nove.” — Andrej Karpathy

IL “Marcia dei Nove” inquadra una realtà produttiva comune: è possibile raggiungere il primo 90% di affidabilità con una demo efficace e ogni nove ulteriori spesso richiede uno sforzo ingegneristico comparabile. Per i workforce aziendali, la distanza tra “di solito funziona” e “funziona come un software program affidabile” determina l’adozione.

La matematica dietro la Marcia dei Nove

“Ogni nove è la stessa quantità di lavoro.” — Andrej Karpathy

I flussi di lavoro agentici aggravano il fallimento. Un tipico flusso aziendale potrebbe includere: analisi delle intenzioni, recupero del contesto, pianificazione, una o più chiamate a strumenti, convalida, formattazione e registrazione di controllo. Se un flusso di lavoro ha n passaggi e ogni passaggio ha esito positivo con probabilità Pil successo end-to-end è di circa p^n.

In un flusso di lavoro in 10 passaggi, il successo end-to-end si aggrava a causa dei fallimenti di ogni passaggio. Le interruzioni correlate (autenticazione, limiti di velocità, connettori) prevarranno a meno che non si rafforzino le dipendenze condivise.

Definire l’affidabilità come SLO misurabili

“Ha molto più senso dedicare un po’ più di tempo per essere più concreti nei tuoi suggerimenti.” — Andrej Karpathy

I workforce ottengono risultati migliori trasformando l’affidabilità in obiettivi misurabili, quindi investendo in controlli che riducano la varianza. Inizia con un piccolo insieme di SLI che descrivono sia il comportamento del modello che il sistema circostante:

• Tasso di completamento del flusso di lavoro (successo o escalation esplicita).

• Tasso di successo delle chiamate agli strumenti entro i timeout, con rigorosa convalida dello schema su enter e output.

• Tasso di output valido nello schema per ogni risposta strutturata (JSON/argomenti).

• Tasso di conformità alle coverage (PII, segreti e vincoli di sicurezza).

• p95 latenza end-to-end e costo per flusso di lavoro.

• Tasso di fallback (modello più sicuro, dati memorizzati nella cache o revisione umana).

Imposta obiettivi SLO per livello di flusso di lavoro (impatto basso/medio/alto) e gestisci un funds di errore in modo che gli esperimenti rimangano controllati.

Nove leve che aggiungono nove in modo affidabile

1) Vincolare l’autonomia con un grafico del flusso di lavoro esplicito

L’affidabilità aumenta quando il sistema dispone di stati delimitati e di una gestione deterministica per nuovi tentativi, timeout e risultati terminali.

• Le chiamate al modello si trovano all’interno di una macchina a stati o di un DAG, in cui ciascun nodo definisce gli strumenti consentiti, il numero massimo di tentativi e un predicato di successo.

• Stato persistente con chiavi idempotenti, quindi i tentativi sono sicuri ed è possibile eseguire il debug.

2) Applicare i contratti advert ogni confine

La maggior parte degli errori di produzione iniziano con la deriva dell’interfaccia: JSON malformato, campi mancanti, unità errate o identificatori inventati.

• Utilizza JSON Schema/protobuf per ogni output strutturato e convalida lato server prima dell’esecuzione di qualsiasi strumento.

• Utilizza enumerazioni, ID canonici e normalizza l’ora (ISO-8601 + fuso orario) e le unità (SI).

3) Validatori di livello: sintassi, semantica, regole di enterprise

La convalida dello schema rileva la formattazione. I controlli semantici e delle regole aziendali impediscono risposte plausibili che rompono i sistemi.

• Controlli semantici: integrità referenziale, limiti numerici, controlli delle autorizzazioni e be a part of deterministici per ID, quando disponibili.

• Regole aziendali: approvazioni per azioni di scrittura, vincoli di residenza dei dati e vincoli a livello di cliente.

4) Percorso per rischio utilizzando segnali di incertezza

Le azioni advert alto impatto meritano maggiori garanzie. Il routing basato sul rischio trasforma l’incertezza in una caratteristica del prodotto.

• Utilizza segnali di confidenza (classificatori, controlli di coerenza o un verificatore del secondo modello) per decidere il routing.

• Porta i passi rischiosi dietro modelli più forti, verifiche aggiuntive o approvazione umana.

5) Chiamate degli strumenti di ingegneria come sistemi distribuiti

I connettori e le dipendenze spesso dominano i tassi di fallimento nei sistemi advert agenti.

• Applica timeout per strumento, backoff con jitter, interruttori automatici e limiti di concorrenza.

• Versiona gli schemi degli strumenti e convalida le risposte degli strumenti per evitare interruzioni silenziose quando le API cambiano.

6) Rendere il recupero prevedibile e osservabile

La qualità del recupero determina quanto sarà fondata la tua domanda. Trattalo come un prodotto dati con versione con metriche di copertura.

• Tieni traccia della percentuale di recupero dei dati vuoti, dell’aggiornamento dei documenti e della percentuale di successo nelle question etichettate.

• L’indice della spedizione cambia con i canarini, quindi sai se qualcosa fallirà prima che fallisca.

• Applicare l’accesso con privilegi minimi e la redazione al livello di recupero per ridurre il rischio di perdite.

7) Costruire una pipeline di valutazione della produzione

Gli ultimi nove dipendono dalla rapida individuazione dei guasti rari e dalla prevenzione delle regressioni.

8) Investire in osservabilità e risposta operativa

Una volta che i guasti diventano rari, la velocità di diagnosi e risoluzione diventa il fattore limitante.

• Emetti tracce/span per passaggio, archivia immediate redatti e I/O degli strumenti con controlli di accesso efficaci e classifica ogni errore in una tassonomia.

• Utilizza runbook e attiva/disattiva la “modalità provvisoria” (disabilita strumenti rischiosi, cambia modello, richiede l’approvazione umana) per una mitigazione rapida.

9) Spedire uno slider di autonomia con fallback deterministici

I sistemi fallibili necessitano di supervisione e il software program di produzione necessita di un modo sicuro per aumentare l’autonomia nel tempo. Tratta l’autonomia come una manopola, non come un interruttore, e rendi il percorso sicuro il valore predefinito.

• Per impostazione predefinita, le azioni sono di sola lettura o reversibili, richiedono una conferma esplicita (o flussi di lavoro di approvazione) per le scritture e le operazioni irreversibili.

• Crea fallback deterministici: risposte di solo recupero, risposte memorizzate nella cache, gestori basati su regole o escalation alla revisione umana quando la fiducia è bassa.

• Esporre modalità sicure per tenant: disabilitare strumenti/connettori rischiosi, forzare un modello più potente, abbassare la temperatura e ridurre i timeout durante gli incidenti.

• Progetta passaggi ripristinabili: persisti lo stato, mostra il piano/differenza e consenti a un revisore di approvare e riprendere dal passaggio esatto con una chiave di idempotenza.

Schizzo di implementazione: un wrapper a gradini delimitato

Un piccolo wrapper attorno a ogni passaggio del modello/strumento converte l’imprevedibilità in controllo basato su coverage: convalida rigorosa, tentativi limitati, timeout, telemetria e fallback espliciti.

def passo_esecuzione(nome, tentativo_fn, validazione_fn, *, max_tentativi=3, timeout_s=15):

# traccia tutti i tentativi sotto un unico intervallo

intervallo = intervallo_inizio(nome)

per tentativo in vary(1, max_attempts + 1):

Tentativo:

# latenza limitata in modo che un passaggio non possa bloccare il flusso di lavoro

con scadenza(timeout_s):

out = tentativo_fn()

# gate: schema + semantica + invarianti aziendali

validate_fn(uscita)

# percorso di successo

metric(“step_success”, nome, tentativo=tentativo)

ritornare fuori

tranne (TimeoutError, UpstreamError) come e:

# transitorio: riprova con jitter per evitare tempeste di tentativi

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

sonno(jittered_backoff(tentativo))

tranne ValidationError come e:

# output errato: riprovare una volta in modalità “più sicura” (temperatura più bassa/immediate più severo)

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

out = tentativo_fn(modalità=”più sicuro”)

# fallback: mantiene il sistema sicuro quando i tentativi sono esauriti

metrica(“passaggio_fallback”, nome)

return EscalateToHuman(motivo=f”{nome} non riuscito”)

Perché le imprese insistono sugli ultimi nove

Le lacune di affidabilità si traducono in rischi aziendali. Sondaggio globale 2025 di McKinsey riferisce che il 51% delle organizzazioni che utilizzano l’intelligenza artificiale hanno subito almeno una conseguenza negativa e quasi un terzo ha segnalato conseguenze legate all’imprecisione dell’intelligenza artificiale. Questi risultati stimolano la domanda di misurazioni, guardrail e controlli operativi più efficaci.

Lista di controllo di chiusura

• Scegli un flusso di lavoro ottimale, definisci il relativo SLO di completamento e i codici di stato del terminale dello strumento.

• Aggiungi contratti + validatori attorno a ogni output del modello e enter/output dello strumento.

• Trattare i connettori e il recupero come un lavoro di affidabilità di prima classe (timeout, interruttori automatici, canarini).

• Indirizzare le azioni advert alto impatto attraverso percorsi di maggiore garanzia (verifica o approvazione).

• Trasforma ogni incidente in un check di regressione nel tuo set d’oro.

Il nove arriva attraverso un’ingegneria disciplinata: flussi di lavoro limitati, interfacce rigorose, dipendenze resilienti e cicli di apprendimento operativo rapidi.

Nikhil Mungel costruisce sistemi distribuiti e workforce di intelligenza artificiale presso aziende SaaS da oltre 15 anni.