Dal pilota ChatGPT all'IA in produzione: i passaggi di ingegneria che i fondatori saltano

Ogni passo esiste perché saltarlo è ciò che fa fallire il deploy.

Passo uno: definire i modi di guasto in produzione. Una demo deve solo funzionare; una funzionalità in produzione deve fallire correttamente. Cosa fa la funzionalità quando il modello è lento, quando il modello sbaglia, quando l'input è malformato, quando l'utente si comporta in modo avverso? La maggior parte dei pilot non ha alcuna risposta; le funzionalità in produzione hanno bisogno di una risposta per ciascuno. Passo due: costruire l'harness di valutazione. Un dataset congelato da 100 a 500 input rappresentativi, le metriche che contano, la soglia sotto la quale la funzionalità è disattivata. Finché la valutazione non esiste, il modello può cambiare ma non puoi dire se il cambiamento era un miglioramento.

Passo tre: budget di costo e di latenza. Qual è il tetto di costo per richiesta, il budget di latenza p95, il tetto di spesa mensile? Se questi non sono specificati, la funzionalità supererà silenziosamente tutti e tre già dal secondo mese. Passo quattro: guardrail al confine. Mascheramento dei dati personali in input, rilevamento di prompt injection, filtraggio degli output per le categorie di policy applicabili, tassonomia di rifiuto per i casi che il modello non dovrebbe trattare. Il pilot non faceva niente di tutto questo e se la cavava perché l'unico utente era il founder. Passo cinque: il fallback senza IA. Ogni flusso assistito dall'IA ha bisogno di un cammino senza IA a cui l'azienda può tornare in pochi minuti quando il modello si rompe, deriva, o diventa fuori prezzo. Il fallback non è una finestra di dialogo di esperienza utente; è un processo manuale funzionante.

Passo sei: observability. Logging per richiesta degli input, degli output, della latenza, del costo e del punteggio di valutazione quando applicabile. Senza di esso, il team fa il debug alla cieca. Passo sette: il passaggio di consegne. Documentazione, runbook, set di valutazione, dashboard, rotazione di reperibilità. La funzionalità non è in produzione finché il team che la gestirà non può farlo senza il team che l'ha costruita. La maggior parte degli sforamenti di costo che vediamo proviene dal saltare il passo sette, il team di costruzione diventa il team di gestione permanente, e l'economia unitaria ne risulta modificata.

Attraverso i progetti che abbiamo salvato, tre dei sette passi sono saltati quasi ogni volta: l'harness di valutazione, il fallback senza IA e il livello di observability. La valutazione è saltata perché sembra superflua, il modello funziona sugli input che il team ha provato, e un set di test congelato "è per dopo". Poi il team ha bisogno di cambiare il prompt, o di scambiare il modello, o di aggiungere una fonte di contesto, e non ha alcun modo di sapere se il cambiamento ha reso la funzionalità migliore o peggiore. La maggior parte dei disastri di prompt engineering in produzione sono disastri di disciplina di valutazione e non disastri di prompt.

Il fallback senza IA è saltato perché sembra pessimista, il team ha appena costruito la funzionalità di IA, l'ultima cosa a cui vuole pensare è il mondo in cui non funziona. Poi sei mesi dopo, il fornitore del modello ha un'interruzione parziale, o il costo è triplicato, o il modello è stato dismesso, o l'ambiente normativo cambia, e l'azienda non ha alcun fallback. Il costo dell'interruzione è ciò che il fallback sarebbe costato a costruire, tre volte anziché una.

L'observability è saltata perché il pilot non ne aveva bisogno. L'unico utente era il founder; il founder si ricordava di ciò che aveva digitato. In produzione, il team dovrà fare il debug di una lamentela arrivata tre giorni fa, su un flusso che ha toccato otto input, nessuno dei quali è stato registrato. Il team passerà una settimana a cercare di riprodurre il bug a memoria e fallirà. Aggiungere retroattivamente l'observability è più costoso che integrarla fin dall'inizio.

Una funzionalità di IA pronta per la produzione possiede, come minimo, quanto segue: un dataset di valutazione congelato versato nel repository; l'harness di valutazione che gira a ogni modifica di prompt o di modello; dashboard di latenza, costo e qualità riviste ogni settimana; il mascheramento dei dati personali e il rilevamento di prompt injection al confine; un fallback senza IA documentato con una procedura di passaggio testata; un logging per richiesta con una retention dimensionata sulla più lunga finestra di debug attesa; un runbook per l'ingegnere di reperibilità; e un proprietario documentato responsabile delle metriche della funzionalità al dodicesimo mese.

Ogni elemento esiste perché abbiamo visto il fallimento che avviene quando manca. Ogni elemento costa anche meno da costruire del costo del fallimento. L'economia non è sottile, il team che consegna queste sette cose passa qualche settimana in più al lancio e risparmia qualche trimestre in più di debug e ricostruzione.

Rifiutiamo di fare deploy di IA senza la checklist. Non perché vogliamo sembrare rigorosi, ma perché l'alternativa è un deploy che il cliente non può mantenere una volta che siamo andati via, il che non è un deliverable. Il passaggio di consegne comprende ogni elemento della checklist, sotto controllo di versione, con la documentazione scritta per l'ingegnere che la erediterà.

Il vero test di un deploy di IA in produzione è com'è dodici mesi dopo, e non il giorno del lancio.

I deploy che invecchiano bene condividono tre proprietà. Il set di valutazione è stato aggiornato almeno due volte man mano che il flusso è evoluto, e non abbandonato. Il fallback è stato testato per davvero almeno una volta, anche se il modello non si è mai rotto, confermando che il cammino funziona ancora. Il team che gestisce la funzionalità non è il team che l'ha costruita, il passaggio di consegne ha davvero trasferito la proprietà.

I deploy che falliscono condividono le tre proprietà inverse. Il set di valutazione è scaduto da sei mesi, perché nessuno lo possiede. Il fallback esiste solo nella documentazione, non testato. E il team di ingegneria originale è ancora il team di supporto di fatto, perché la documentazione non ha mai permesso a qualcun altro di prendere il testimone.

Quando SDEN conclude un progetto di IA, il passaggio di consegne è ciò su cui il deliverable è giudicato. La funzionalità funziona il primo giorno; è il minimo. La funzionalità funziona ancora al trecentosessantacinquesimo giorno, posseduta dal tuo team, ecco l'esito del progetto.