I March Nines di Karpathy mostrano perché l’affidabilità dell’IA al 90% non è sufficiente

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

“Il Gabbiano dei Nove” inquadra una verità di produzione comune: è possibile raggiungere il primo 90% di affidabilità con una demo efficace e ogni nove ulteriori spesso richiedono sforzi ingegneristici simili. Per i team aziendali, la distanza tra “normalmente funziona” e “funziona come un software affidabile” determina l’adozione.

La matematica composta dietro la Marcia dei Nove

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

I flussi di lavoro intermedi aumentano gli errori. Un tipico flusso aziendale potrebbe includere: analisi degli intenti, recupero del contesto, pianificazione, una o più chiamate a strumenti, convalida, formattazione e registrazione di controllo. Se ci sono n passaggi in un flusso di lavoro e ogni passaggio ha esito positivo con una certa probabilità P.successo completo ca. p^n.

In un flusso di lavoro in 10 passaggi, il successo end-to-end deriva dai fallimenti in ogni passaggio. A meno che non si rafforzino le dipendenze condivise, gli interrupt associati (autenticazione, limiti di velocità, connettori) prevarranno.

Definire l’affidabilità come SLO misurabili

“Ha molto più senso dedicare un po’ più di tempo ad esprimere i propri desideri in modo più concreto.” — Andrej Karpathy

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

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

• Tasso di successo delle chiamate del veicolo entro i timeout con rigorosa convalida dello schema in entrata e in uscita.

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

• Tasso di conformità alle policy (PII, segreti e restrizioni di sicurezza).

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

• Tasso di ritiro (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 il budget di errore per tenere sotto controllo gli esperimenti.

Nove bracci che aggiungono in modo affidabile nove

1) Limitare l’autonomia con un chiaro diagramma del flusso di lavoro

L’affidabilità aumenta quando il sistema dispone di casi limitati e di elaborazione deterministica per nuovi tentativi, timeout e risultati terminali.

• Le chiamate al modello esistono all’interno di una macchina a stati, o DAG, in cui ciascun nodo definisce i mezzi consentiti, il numero massimo di tentativi e una previsione di successo.

• Stato persistente con chiavi idempotenti in modo che i tentativi siano sicuri e debuggabili.

2) Applicare i contratti ad ogni frontiera

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

• Utilizza JSON Schema/protobuf per ogni output configurato e convalida il lato server prima di eseguire 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 business

La convalida dello schema acquisisce il markup. I controlli semantici e delle regole aziendali impediscono risposte sensate che interrompono i sistemi.

• Controlli semantici: integrità referenziale, limiti numerici, controlli delle autorizzazioni e join deterministici per identità, quando disponibili.

• Regole aziendali: approvazioni per azioni di scrittura, restrizioni sul posizionamento dei dati e restrizioni sul livello client.

4) Creare un percorso in base al rischio utilizzando segnali di incertezza

Le azioni ad alto impatto meritano maggiori garanzie. Una guida basata sul rischio trasforma l’incertezza in una caratteristica del prodotto.

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

• Intraprendi i passi rischiosi dietro modelli più forti, convalida aggiuntiva o convalida umana.

5) Chiamate di strumenti di ingegneria come sistemi distribuiti

I raccoglitori e le dipendenze spesso dominano i tassi di fallimento nei sistemi con agenti.

• Implementa timeout, backoff del jitter, interruttori automatici e limiti di concorrenza in base al veicolo.

• Versione degli schemi degli strumenti e verifica delle risposte degli strumenti per evitare interruzioni silenziose quando le API cambiano.

6) Rendere l’accesso 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.

• Monitora il tasso di inattività, l’aggiornamento dei documenti e il tasso di successo per le query contrassegnate.

• L’indice della nave cambia con i canarini in modo da sapere se qualcosa fallirà prima che fallisca.

• Implementa l’accesso e l’orchestrazione con privilegi minimi a livello di ricezione per ridurre il rischio di perdite.

7) Creare una linea di valutazione della produzione

I prossimi nove dipendono dalla rapida individuazione degli errori rari e dalla prevenzione delle regressioni.

• Mantieni un set gold basato su eventi dal traffico di produzione ed eseguilo a ogni modifica.

• Esegui la modalità shadow e i canary A/B con rollback automatico sulle regressioni SLI.

8) Investire in osservabilità e risposta operativa

Quando i fallimenti diventano rari, la velocità della diagnosi e del recupero diventa il fattore limitante.

• Pubblica tracce/emissioni per passaggio, memorizza i suggerimenti corretti e gli I/O del veicolo con controlli di accesso efficaci e classifica ogni guasto in una tassonomia.

• Utilizza runbook e transizioni in “modalità provvisoria” per una mitigazione rapida (disabilitare strumenti rischiosi, modificare modelli, chiedere l’approvazione umana).

9) Presentare uno slider sull’autonomia con rendimenti decisivi

I sistemi difettosi necessitano di controllo e il software di produzione necessita di un modo sicuro per aumentare l’autonomia nel tempo. Tratta l’autonomia come un pulsante, non come un interruttore, e rendi la modalità sicura l’impostazione predefinita.

• Per impostazione predefinita, azioni di sola lettura o reversibili; Richiede l’approvazione esplicita (o flussi di lavoro di approvazione) per scritture e operazioni irreversibili.

• Crea fallback deterministici: risposte di solo accesso, risposte memorizzate nella cache, gestori basati su regole o inoltro 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 eventi.

• Progetta trasferimenti ripristinabili: mantieni lo stato, mostra il piano/la differenza e lascia che il revisore confermi con un cambio di idempotenza e continui dal passaggio esatto.

Schizzo di implementazione: un wrapper a passaggi limitati

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

def run_step(name, try_fn, validate_fn, *, max_attempts=3, timeout_s=15):

# tiene traccia di tutti i tentativi in ​​un singolo intervallo

intervallo = intervallo_inizio(nome)

per provare nell’intervallo (1, max_attempts + 1):

da provare:

# latenza limitata, quindi un passaggio non può interrompere il flusso di lavoro

con data di scadenza (timeout_s):

fuori = prova_fn()

# gate: schema + semantica + letterali business

validate_fn(esci)

# percorso verso il successo

metrica("passo_successo"sostantivo, processo = processo)

ritorno

tranne (TimeoutError, UpstreamError):

# temporaneo: riprova con jitter per evitare tempeste di tentativi

span.log({"tentativo": tentativo, "errore": via(e)})

sonno(jittered_backoff(test))

tranne ValidationError come e:

# output di errore: riprovare in modalità “più sicura” (temperatura più bassa/prompt più rigoroso)

span.log({"tentativo": tentativo, "errore": via(e)})

out = prova_fn(modalità="più sicuro")

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

metrica("step_fallback"nome)

restituire EscalateToHuman(motivo=f)"{nome} non è riuscito")

Perché le aziende insistono sui prossimi nove?

Le lacune di affidabilità diventano rischi aziendali. La ricerca globale di McKinsey per il 2025 Riporta che il 51% delle organizzazioni che utilizzano l’intelligenza artificiale hanno subito almeno una conseguenza negativa, con quasi un terzo che ha segnalato conseguenze dovute all’imprecisione dell’intelligenza artificiale. Questi risultati stanno stimolando la domanda di metriche, guardrail e controlli operativi più robusti.

Chiusura della lista di controllo

• Scegli il flusso di lavoro migliore, definisci lo SLO di completamento e i codici di stato del terminale del dispositivo.

• Aggiungi contratti + validatori attorno a ciascun output del modello e input/output dello strumento.

• Trattare i connettori e le operazioni di accesso come un esercizio di affidabilità di prim’ordine (timeout, interruttori automatici, canarini).

• Reindirizzare le azioni ad alto impatto verso percorsi di garanzia più elevata (verifica o approvazione).

• Trasforma ogni evento in un test di regressione nel tuo set oro.

I nove derivano da un’ingegneria disciplinata: flussi di lavoro limitati, interfacce rigide, dipendenze flessibili e cicli di apprendimento operativo rapidi.

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

Collegamento alla fonte