Documento AI
MLOps senza la parola d'ordine: cosa serve effettivamente per mantenere in funzione un sistema AI
Vincent Wahidi
MLOps è la disciplina che mira a mantenere utile un sistema di apprendimento automatico dopo il suo lancio. In termini semplici, copre quattro compiti: monitoraggio (guardare se il modello funziona ancora nel mondo reale), riqualificazione (aggiornarlo man mano che i dati cambiano), controllo delle versioni (sapere esattamente quale modello e dati hanno prodotto quale risultato) e l'impianto idraulico di distribuzione che spedisce una nuova versione in modo sicuro. Un modello non è un prodotto finito il giorno in cui viene pubblicato. È un componente deperibile che si trova all’interno di un sistema che deve essere alimentato, sorvegliato e corretto. MLOps è il nome di questo lavoro in corso. Ignoralo e il modello si allontana silenziosamente dalla realtà, la precisione scivola e una mattina le previsioni sono sbagliate in modi che nessuno sta controllando. Il lancio è l’inizio del lavoro, non la fine.
Cosa significa effettivamente MLOps nella produzione?
MLOps è ciò che DevOps rappresenta per il software ordinario, adattato al fatto che un modello dipende dai dati, non solo dal codice. Una normale applicazione si comporta allo stesso modo oggi come il giorno in cui l'hai spedita, finché qualcuno non cambia il codice. Un modello no. Il mondo da cui ha imparato continua a muoversi, quindi la sua precisione può peggiorare mentre ogni riga di codice rimane intatta.
Questa differenza è il punto centrale. Con il software che chiedi, funziona ancora. Con un modello devi anche chiederti, è ancora valido. MLOps è l'insieme di pratiche e strumenti che ti consentono di rispondere alla seconda domanda ogni giorno e non una volta al trimestre quando un cliente si lamenta.
Qual è il lavoro successivo al lancio di un modello?
Il lavoro del secondo giorno si divide in quattro lavori ricorrenti. Nessuno di questi è affascinante, e tutti sono ciò che separa un sistema che si guadagna da vivere da uno che marcisce.
- Monitoraggio. Tieni traccia degli input e degli output del modello in produzione. Fai attenzione alla deriva dei dati (i dati in tempo reale iniziano ad apparire diversi dai dati di addestramento) e al calo di precisione rispetto ai risultati reali una volta noti. L'avviso che desideri è quello che viene attivato prima che il cliente se ne accorga, non dopo.
- Riqualificazione. Quando le prestazioni diminuiscono o i dati si sono spostati chiaramente, aggiorna il modello con dati più recenti e invia l'aggiornamento. Decidi in anticipo se questo viene attivato da una metrica che attraversa una linea o viene eseguito secondo un programma e rendilo una routine, non un'esercitazione antincendio.
- Versionamento. Registra quale versione del codice, dei dati e del modello addestrato ha prodotto un determinato risultato. Quando un output viene contestato, è necessario ricostruire esattamente cosa è stato eseguito. Senza questo, ogni indagine parte da congetture.
- Convalida e implementazione. Testa un nuovo modello rispetto a quello attuale prima che raggiunga il traffico reale, rilascialo gradualmente e mantieni un percorso rapido per tornare alla versione precedente se presenta prestazioni inferiori.
Questa è la stessa disciplina ingegneristica che trasforma un pilota in un sistema che sopravvive al contatto con utenti reali. La demo dimostra che il modello può funzionare una volta. Questo lavoro dimostra che continua a funzionare.
Perché i sistemi AI marciscono senza MLOps?
Perché i dati sottostanti non smettono mai di cambiare e un modello non monitorato non ha modo di dirti che è rimasto indietro. Un modello di frode addestrato sui modelli dell'anno scorso non riesce lentamente a raggiungere quelli di quest'anno. Un estrattore di documenti ottimizzato per le fatture di un fornitore inizia a eliminare i campi quando arriva il formato di un nuovo fornitore. Il codice va bene. Il modello è semplicemente invecchiato rispetto alla realtà per cui è stato costruito.
Il pericolo è che questo fallimento taccia. Un server bloccato chiama qualcuno alle 3 del mattino. Un modello alla deriva restituisce semplicemente risposte leggermente peggiori, giorno dopo giorno, e continua a restituirle con sicurezza. Nessuno viene chiamato. Nel momento in cui qualcuno individua uno strano numero, il sistema potrebbe essere rimasto tranquillamente in errore per mesi. Questo è ciò che la gente intende quando dice che un sistema AI è marcito: non che si sia rotto, ma che nessuno lo stava guardando decadere.
Questo è il motivo per cui i sistemi durevoli, come quello necessario per il documento AI in un'azienda, trattano il monitoraggio e la riqualificazione come parte della creazione, non come qualcosa da aggiungere se rimane del budget.
Di quanto MLOps ha realmente bisogno un progetto?
Meno di quanto implica il panorama dei fornitori e più di quanto la maggior parte dei progetti pilota prevede. La giusta quantità è proporzionale alla posta in gioco, non alla dimensione del catalogo degli utensili.
| Tipo di sistema | Di cosa ha bisogno il monitoraggio | Cadenza di riqualificazione |
|---|---|---|
| Posta bassa, input stabili | Registrazione dell'output di base e un semplice controllo della precisione | Raramente, solo quando emerge un problema |
| Input mutevoli e critici per il business | Avvisi di deriva e precisione con un proprietario nominato | Su un trigger definito o con una pianificazione regolare |
| Decisioni consequenziali sulle persone | Registrazione completa, revisione umana dei casi limite, traccia di controllo | Programmato, con ogni versione registrata |
Due principi mantengono questo onesto. In primo luogo, creare il monitoraggio prima che sia necessario, mentre il sistema è piccolo, perché aggiornare la visibilità in un sistema live è molto più difficile che progettarlo. In secondo luogo, assegnare al sistema in esecuzione un proprietario con nome. Il lavoro operativo senza proprietario non avviene e un modello senza nessuno che lo guarda è un modello sulla via della putrefazione.
Il pratico asporto
Quando metti in servizio un sistema AI, chiedi chi ne sarà responsabile nel sesto mese e come farà a sapere se smette di funzionare. Se la risposta è una data di lancio seguita dal silenzio, stai acquistando una demo con una passerella più lunga. Se la risposta nomina una persona, una serie di parametri che osserva e un piano per aggiornare il modello, stai acquistando qualcosa costruito per rimanere utile. MLOps è solo l'abitudine poco affascinante di mantenere una promessa al termine della festa di lancio. Encelyte crea il documento dei sistemi AI e AI con il lavoro di due giorni progettato fin dall'inizio.

Vincent Wahidi
Autore
Vincent Wahidi is the director of Encelyte, a computer engineer who builds production AI, automation, and custom software for enterprises across Cyprus and the wider region. He writes the strategy, cost and decision-maker pieces himself; the practical how-to guides are curated under the five mission-cat bylines below.
Da leggere dopo
Dove vanno i dati della tua azienda quando usi AI: una risposta chiara per il consiglio
Hai un problema che vale la pena risolvere?
Raccontaci cosa stai costruendo o sistemando. Risponderemo entro un giorno lavorativo con un passo successivo chiaro.
