Made With ML: una guida pratica per portare il machine learning in produzione
Cosa insegna davvero Made With ML, quali parti sono riusabili in un team e come trasformare il materiale in un controllo di qualità prima del rilascio.
Scritto da Redazione Daniel Vedovato · Revisionato il 21 luglio 2026
Articolo preparato con assistenza AI, verificato e revisionato da Daniel Vedovato.
Made With ML non è una libreria da aggiungere a un progetto. È un corso open source che usa un’applicazione di classificazione come filo conduttore per mostrare il passaggio dall’esperimento alla manutenzione. Questa distinzione è importante: un notebook può dimostrare che un modello produce un risultato, ma non dimostra che il risultato resterà corretto, osservabile e ripetibile dopo il rilascio.
Il repository espone proprio le componenti che di solito restano fuori da una demo: dati, configurazione, addestramento, valutazione, predizione e servizio. Include anche test, gestione degli esperimenti con MLflow e un percorso di deployment. Il valore del materiale non è copiare quella specifica architettura, ma usare le sue domande per scoprire cosa manca al proprio prodotto.
Dalla metrica al sistema
Un modello può avere una buona metrica offline e fallire comunque in produzione. Il motivo è semplice: la metrica descrive un dataset e una procedura di valutazione, mentre il prodotto riceve richieste nuove, dati incompleti, versioni diverse di dipendenze e vincoli di costo.
Made With ML insiste su un ciclo iterativo: progettare, sviluppare, distribuire e migliorare. Per un team questo si traduce in quattro artefatti minimi. Primo, una definizione documentata del problema: chi riceve la previsione, quale errore è accettabile e quando serve il giudizio umano. Secondo, una versione identificabile di dati, codice e parametri. Terzo, un confronto automatico fra modello candidato e baseline. Quarto, un modo per osservare il servizio una volta esposto.
Non servono tutti gli strumenti del corso per iniziare. Una piccola azienda può conservare un file di configurazione nel repository, salvare le metriche di ogni esecuzione e bloccare il deploy se il test su un set di controllo peggiora. Il punto è rendere una decisione tecnica ricostruibile, non accumulare dashboard.
Cosa prendere dal repository
La struttura dei file è utile perché separa responsabilità. data.py non dovrebbe decidere la logica del modello; evaluate.py non dovrebbe modificare silenziosamente il dataset; serve.py non dovrebbe contenere parametri di training. Questa separazione permette test più piccoli e rende più semplice capire da dove nasce una regressione.
Il corso mostra anche una differenza spesso trascurata tra esperimento e API. Durante un notebook si può correggere un input a mano. Un endpoint, invece, deve definire formato, validazione, timeout, autenticazione e comportamento in caso di modello non disponibile. Se questi aspetti non sono espliciti, il rischio operativo viene soltanto spostato da chi addestra a chi gestisce il servizio.
Un buon primo esercizio consiste nel riprodurre una sola catena completa su un dataset non sensibile: caricamento, controllo dello schema, addestramento, valutazione, salvataggio dell’artefatto e chiamata HTTP. Solo dopo conviene introdurre orchestrazione, cloud o GPU. Il repository stesso propone esecuzioni locali e indica che i carichi più grandi richiedono infrastruttura gestita o un ambiente controllato.
Checklist per una release ML
Prima di pubblicare una funzione basata su modello, una checklist concreta vale più di una promessa di accuratezza.
- Dati: origine, licenza, periodo di raccolta e trattamento dei valori mancanti sono annotati?
- Baseline: esiste una soluzione più semplice con cui confrontare il nuovo modello?
- Valutazione: il set di test è separato dall’addestramento e rappresenta casi realmente attesi?
- Soglia di azione: è chiaro quando mostrare una previsione, chiedere conferma o rifiutare l’operazione?
- Osservabilità: log, latenza, tasso di errore e distribuzione degli input permettono di accorgersi di un cambiamento?
- Ritorno indietro: il team può ripristinare la versione precedente senza ricostruire l’ambiente?
Questa lista non rende un sistema infallibile. Riduce però il costo dell’errore: si scopre prima se una modifica ai dati, a una dipendenza o alla logica applicativa ha cambiato il comportamento atteso.
Limiti da non nascondere
Made With ML usa strumenti e scelte tecnologiche precise, fra cui Ray e MLflow. Non sono requisiti universali. Per un servizio piccolo, introdurre un cluster o un tracking server prima di avere una pipeline stabile può aumentare complessità e spesa. Inoltre gli esempi didattici hanno dataset e obiettivi più ordinati di quelli disponibili in un’impresa.
Va evitata anche un’altra scorciatoia: trattare test automatici e monitoraggio come una certificazione di correttezza. I test verificano ciò che è stato previsto; non rilevano automaticamente una definizione sbagliata del problema, un dataset non rappresentativo o un effetto ingiusto sugli utenti. In questi casi servono revisione del dominio, campioni manuali e una decisione esplicita su chi risponde del risultato.
Come valutarlo in una settimana
La prova più utile non è rifare tutto il corso. Scegli un caso interno già misurabile, conserva l’attuale metodo come baseline e costruisci una pipeline minima. Al termine, confronta tempo di rilascio, errori rilevati prima della produzione, costo dell’esecuzione e facilità di spiegare come è stata ottenuta una previsione.
Se il team riesce a rispondere rapidamente a “quale codice e quali dati hanno prodotto questo risultato?”, il percorso sta creando valore. Se invece il progetto aggiunge molti servizi senza rendere più affidabile una decisione concreta, conviene fermarsi e ridurre il perimetro.