Guadagni:
- Capacità di riconoscere le sfide speciali del machine learning legate al trio codice-dati-modello e al pacchetto e di presentare il modello online o in batch in base alle esigenze aziendali.
- Capacità di implementare modelli di distribuzione graduali e di rollback (shadow, canary, A/B, rollback) e di aggiungere un piano di rollback testato a ciascuna distribuzione
- Capacità di mantenere tracciabile il collegamento dati-codice-metrico del modello messo in produzione con CI/CD controllato da soglie di valutazione e anagrafica del modello
Ottenere un modello che raggiunga una precisione del 95% nel notebook è solo metà della storia. L'altra metà, spesso la parte difficile, è portare quel modello agli utenti reali in modo affidabile, scalabile e gestibile. MLOps (Machine Learning Operations: la disciplina di messa, utilizzo e manutenzione di modelli ML in produzione) combina le pratiche DevOps dell'ingegneria del software con le sfide uniche del ML. In questa unità, tratteremo le fasi di passaggio del modello alla produzione e il modo in cui l'intelligenza artificiale aiuta in questo processo.
Perché il machine learning è diverso dal software normale?
Nel software ordinario, il comportamento è nel codice; Se il codice non cambia, il comportamento non cambia. In ML, il comportamento dipende sia dal codice, dai dati che dal modello. Queste tre dimensioni creano le sfide aggiuntive di MLOps:
- Deriva dei dati: i dati in produzione si allontanano dai dati in addestramento nel tempo; il modello diventa obsoleto.
- È necessario eseguire la versione di tre cose: codice, dati e modello, tutti e tre.
- Fallimento silenzioso: un modello può fallire senza bloccarsi, senza dare errori, semplicemente producendo previsioni errate. Catturare questo richiede monitoraggio.
Ecco perché esiste una grande differenza tra un "modello funzionante" e un "modello pronto per la produzione".
Confezione e presentazione del modello
Il primo passo per mettere in produzione il modello è impacchettarlo: il file del modello, le librerie necessarie, il codice di preelaborazione e le informazioni sulla versione insieme come un insieme riproducibile. La containerizzazione (ad esempio Docker: mettere l'applicazione in una scatola isolata con tutte le sue dipendenze) è standard qui; Elimina il problema "funzionava sulla mia macchina".
Due modelli fondamentali di servizio al modello:
- Online/in tempo reale (online): il modello si trova dietro un'API, restituendo una previsione istantanea per ogni richiesta in arrivo. La bassa latenza è fondamentale.
- Batch: il modello elabora periodicamente grandi set di dati (ad esempio genera punteggi per tutti i clienti durante la notte). La latenza è irrilevante, l’efficienza è importante.
Quale sia quello giusto dipende dalle esigenze aziendali: raccomandazione istantanea online, punteggio di rischio mensile in batch.
Suggerimento: "In tempo reale" è un costo, non l'impostazione predefinita. Il batch è molto più economico e semplice se il risultato verrà utilizzato entro poche ore. Hai davvero bisogno di una risposta immediata? Chiedilo prima.
Strategie di distribuzione sicure
Aprire un nuovo modello direttamente a tutto il traffico è rischioso; If it's wrong, everyone is affected. Modelli di distribuzione sicuri:
- Distribuzione shadow: il nuovo modello riceve traffico di produzione, ma le sue previsioni non vengono mostrate all'utente, ma solo registrate. Viene confrontato con il vecchio modello per vedere se è sicuro nei dati reali.
- Distribuzione Canary: il nuovo modello viene inizialmente distribuito a una piccola percentuale di traffico (ad esempio 5%); Se non ci sono problemi, viene aumentato gradualmente.
- Test A/B: due modelli vengono presentati all'utente reale in parallelo e vengono confrontate le metriche aziendali (conversione, clic).
- Rollback: possibilità di ripristinare rapidamente la vecchia versione se il nuovo modello risulta non valido. Every deployment should have a rollback plan.
Attenzione: una distribuzione senza un piano di rollback non è completa. La possibilità di ripristinare la vecchia versione in pochi minuti protegge l'utente quando il nuovo modello si comporta in modo imprevisto in produzione. Testarlo prima della distribuzione.
Approccio debole/Approccio forte
Debole: "Il modello è stato buono nei test, siamo andati in diretta, l'abbiamo aperto a tutti."
Güçlü: "We containerized the model, labeled it as a version. First, we ran it in shadow mode with production traffic for 3 days, comparing the predictions with the old model — deviation was acceptable. Then we opened it with 5% canary, monitored the throughput metrics and latency. When there were no problems, we gradually increased it to 100%. We had tested the rollback command beforehand."
La differenza: l’approccio forte è graduale, misurato e reversibile. Risk is limited at every step.
CI/CD e automazione
CI/CD (Continuous Integration / Continuous Deployment: pipeline of automatically testing and releasing code changes) in ML covers not only the code but also the data and model steps. A good ML CI/CD pipeline: runs tests when the code changes, performs data validation, retrains the model (if necessary), checks evaluation thresholds, and only advances deployment if the thresholds hold. Il principio “la formazione è automatica, la distribuzione è basata su soglie” impedisce al modello difettoso di penetrare silenziosamente nella produzione.
L'intelligenza artificiale è molto utile durante la configurazione di queste pipeline: scrittura di bozze di file di configurazione (YAML), casi di test, script di distribuzione. Ma sei tu a determinare le soglie di distribuzione (qualunque sia la metrica che supera il valore pubblicato) e la politica di rollback; queste sono decisioni relative al rischio aziendale.
Infrastruttura di riproducibilità
Per riprodurre il comportamento di un modello in produzione, registro del modello: un record che conserva quale modello è stato addestrato con quali dati e codice e quali metriche ha ricevuto. Per ogni modello di produzione, dovrebbe essere tracciabile quanto segue: versione dei dati di training, versione del codice (git commit), iperparametri, punteggi di valutazione e data di distribuzione. Quando sorge un problema, dovresti essere in grado di rispondere alla domanda "quale modello ha prodotto questa previsione, con quali dati?" in pochi minuti. Approfondiremo questo aspetto nell'unità 11.
tre mini custodie
Caso 1 - Problema rilevato dalla distribuzione dell'ombra. Un modello di raccomandazione ha battuto quello vecchio nei test. Running it with production traffic in shadow mode was found to produce very poor recommendations for a particular segment of users (new users) — the test data was underrepresentative of this segment. Il modello è stato corretto senza mai essere visualizzato all'utente. Se venisse aperto direttamente, la nuova esperienza dell'utente verrebbe interrotta.
Caso 2 – Distribuzione irrevocabile. Un team ha implementato un nuovo modello di prezzo per tutto il traffico, senza piani di rollback. Il modello inaspettatamente ha valutato alcuni prodotti molto a buon mercato. Il ripristino della versione precedente ha richiesto ore perché il processo non era pronto. C'è stata una grave perdita di reddito. Successivamente, a ogni distribuzione sono stati aggiunti test obbligatori di rollback.
Caso 3 – Deriva silenziosa dei dati. Per mesi è apparso uno schema di frode senza errori. Ma la tattica dei truffatori è cambiata (data drift) e il richiamo del modello è silenziosamente diminuito. Nessuno se ne è accorto perché non c'era alcun monitoraggio. Una volta istituito un pannello di monitoraggio della distribuzione delle previsioni, la deriva è diventata presto visibile. Tratteremo il monitoraggio nell'unità 8.
Modelli copiabili
Scrivere una bozza del piano di distribuzione per questo modello. Model: [what it does], usage: [online or batch?] Should include:1) Packaging (container, versioning)2) Incremental deployment strategy (shadow/canary/A-B) and why3) Metrics to track (business + technical + latency)4) Rollback plan and how to test5) Deployment thresholds (which metric should exceed what value)
Check this ML CI/CD pipeline:1) Is data validation in the line?2) Can the deployment proceed without holding the evaluation threshold (should it not)?3) Is rollback automatic?4) Are data+code+metrics tracked in the model registry?Pline configuration: [config]
Aiutami a decidere se la presentazione online o batch è adatta per questo modello. How long will the result be used: [instant / minute / hour / day]Expected request volume: [number]Is there a delay constraint: [ms]Which one would you recommend in terms of cost and complexity and why?
Write a rollback procedure for this model.- What metric/threshold triggers poor performance?- What are the rollback steps?- How long should the rollback take (target)?- How do I test this procedure before production?
Tabella dei modelli di presentazione
criterio
On-line (in tempo reale)
Lotto
ritardo
Critico (ms)
insignificante
Utilizzo
È richiesta una risposta immediata
Punteggio periodico
Costo
alto
basso
complessità
alto
basso
esempio
Raccomandazione dal vivo, truffa
Punteggio di rischio mensile
Errori comuni
- Distribuire senza un piano di recupero. Il modello sbagliato colpisce l'intero utente.
- Apertura diretta al 100% del traffico. Limitare il rischio con una distribuzione scaglionata.
- Non istituire un monitoraggio. Il modello produce errori silenziosamente, senza errori.
- Presentazione ridondante in tempo reale. Sebbene il batching sia sufficiente, i costi e la complessità aumentano.
- Non collegare le versioni del codice modello-dati. Non è possibile riprodurre il problema.
- Rilascio automatico senza soglia di distribuzione. Il cattivo modello si insinua silenziosamente.
In sintesi
Lo spostamento del modello in produzione è un compito ingegneristico diverso e spesso più difficile rispetto all'addestramento. Il machine learning richiede una disciplina aggiuntiva perché dipende dal trio codice-dati-modello: confezionamento e controllo delle versioni, modello di distribuzione (online/batch) adatto alle esigenze aziendali, implementazione graduale e reversibile, CI/CD controllato da soglia e registrazione del modello. L’intelligenza artificiale è un potente aiuto nella generazione del codice e della configurazione di questa infrastruttura; ma le soglie di distribuzione, la politica di recupero e le decisioni sul rischio sono tue. Una distribuzione senza un piano di rollback non è completa.
Compito dell'applicazione
Containerizza (Docker) un modello ed etichettalo come versione. Decidi se offrirai online o in batch in base alle tue esigenze aziendali e scrivi la tua giustificazione. Documentare un piano di distribuzione graduale (shadow o canary) e una procedura di rollback testata. Assicurati di registrare la versione dei dati, il commit del codice e i punteggi di valutazione nel registro del modello.
lista di controllo
- [ ] Il modello è confezionato e versionato (contenitore + etichetta).
- [] Il modello di presentazione (online/batch) è stato scelto in base alle esigenze aziendali.
- [ ] Strategia di distribuzione graduale (shadow/canary) implementata.
- [ ] Procedura di rollback scritta e testata.
- [ ] CI/CD non fa avanzare la distribuzione prima che venga raggiunta la soglia di valutazione.
- [ ] Il registro del modello contiene il collegamento dati+codice+metrica.