Mettere l'AI in produzione: MLOps / LLMOps

In una frase

Costruire un prototipo AI è facile e veloce; tenerlo in produzione — accurato, sicuro e sostenibile nel tempo — è il vero mestiere. Un modello in produzione non è "finito": va monitorato, valutato e aggiornato. Le discipline che lo governano sono MLOps (per il machine learning in generale) e la sua variante per i modelli linguistici, LLMOps.

Il salto che frega tutti: dalla demo alla produzione

PROTOTIPO  (mezza giornata)          PRODUZIONE  (per anni)
  funziona nella demo                 accurato, sicuro, sostenibile
  "guarda, risponde!"                 monitorato, valutato, aggiornato
                                      ↑ qui vive gran parte del lavoro

La trappola è credere che, una volta che la demo funziona, il più sia fatto. In realtà il codice del modello è una piccola parte del sistema: il grosso — dati, infrastruttura, monitoraggio — è dove si annida il "debito tecnico nascosto" (lo descrisse Google già nel 2015). E c'è un nemico silenzioso: il drift. Il mondo cambia, i dati cambiano, e un modello fermo invecchia — le sue risposte peggiorano senza che nessuno tocchi niente.

MLOps: portare la disciplina del software nel machine learning

MLOps (Machine Learning Operations) applica al ML le buone pratiche del DevOps: automatizzare e monitorare l'intero ciclo di vita del modello. Quattro anelli continui:

• CI — integrazione continua: test del codice e dei dati/modelli.
• CD — rilascio continuo: messa in produzione automatica delle pipeline.
• CT — addestramento continuo (la novità del ML): ri-addestrare il modello quando i dati cambiano.
• CM — monitoraggio continuo: sorvegliare dati e performance in produzione (cali di accuratezza, drift).

dati ─► addestra ─► testa ─► rilascia ─► MONITORA (in produzione)
  ▲                                            │
  └───── ri-addestra quando i dati cambiano ─────┘
          (il mondo cambia: il modello "invecchia")

Strumenti tipici: pipeline come Kubeflow o TFX, tracciamento esperimenti con MLflow, sopra Docker/Kubernetes o piattaforme cloud gestite.

LLMOps: quando il modello è un LLM

Con gli LLM nasce LLMOps, e il baricentro si sposta. Tre differenze che cambiano tutto:

	MLOps (ML classico)	LLMOps (LLM)
Dove sta il costo	nell'addestramento	nell'inferenza (i token, a ogni risposta)
Cosa fai di solito	addestri un modello tuo	orchestri un modello esistente (prompt + RAG + strumenti)
La sfida n° 1	il drift dei dati	valutare output non deterministici

Di conseguenza, le aree su cui si lavora sono diverse:

• Valutazione (eval): misurare la qualità di risposte che non hanno una sola "soluzione giusta" (la parte più difficile — sotto).
• Osservabilità / tracing: registrare prompt, risposte e catene di chiamate, per capire e correggere.
• Gestione dei prompt: versionarli e testarli come si fa col codice.
• Controllo dei costi: monitorare i token — senza controllo, la spesa può raddoppiare i costi operativi mensili.
• Sicurezza / guardrail: filtrare input e output, prevenire abusi.

La chiave di volta: valutare (eval)

Se non misuri la qualità, non sai se il tuo sistema migliora o peggiora a ogni modifica. Ma valutare un LLM è intrinsecamente sfumato: l'output è aperto. Gli strumenti:

• Benchmark standard: test condivisi per confrontare i modelli — es. MMLU (57 materie, dalla matematica al diritto) per conoscenza e ragionamento, e HELM per una valutazione "olistica" su più metriche (accuratezza, robustezza, bias…).
• Eval su misura: un dataset di test del tuo dominio — il pezzo che conta davvero.
• LLM-as-a-judge: usare un modello forte per giudicare le risposte (scalabile, ma con limiti propri).
• Metriche utili: accuratezza, pertinenza, fedeltà alle fonti (per il RAG), sicurezza, costo, latenza.

Trappola dei benchmark: un buon punteggio su un test pubblico non garantisce buone prestazioni sul tuo caso reale (i benchmark possono essere "contaminati" o non rappresentare il tuo dominio). Misura sul tuo caso, non sulla classifica.

Per una PMI: il minimo sindacale

Per un progetto piccolo non serve la macchina MLOps completa — sarebbe over-engineering. Ma per qualunque app AI seria in produzione, questi quattro presidi sono il minimo:

1. Eval — un set di esempi di test, per accorgerti subito se una modifica peggiora le risposte.
2. Osservabilità — tracciare prompt e risposte, per capire cosa succede quando qualcosa va storto.
3. Costi — monitorare i token (la bolletta dell'AI scala col volume).
4. Guardrail — filtri su input e output, soprattutto se l'AI compie azioni reali.

Regola pratica: versiona i prompt come versioni il codice, e tieni un piccolo set di test che giri a ogni modifica di prompt o di modello. È il modo più economico per non "rompere" ciò che già funzionava.

In sintesi

• Il difficile non è il prototipo, è la produzione: un modello non è mai "finito", e col tempo invecchia (drift).
• MLOps = DevOps per il ML: integrazione, rilascio, ri-addestramento e monitoraggio continui, contro drift e debito tecnico.
• LLMOps sposta il baricentro: il costo è nell'inferenza (token), si orchestra invece di addestrare, e la sfida è valutare output non deterministici.
• La valutazione è la chiave: benchmark (MMLU, HELM) + eval sul tuo caso + LLM-as-a-judge; ma un buon benchmark ≠ buono sul tuo caso reale.
• Per una PMI: parti dal minimo (eval, osservabilità, costi, guardrail), senza over-engineering.

Fonti

• Il "debito tecnico" nei sistemi ML (fondamento dell'MLOps): Sculley et al. (Google), Hidden Technical Debt in Machine Learning Systems, NeurIPS 2015
• Benchmark di conoscenza (MMLU): Hendrycks et al., Measuring Massive Multitask Language Understanding, 2020 — arXiv:2009.03300
• Valutazione olistica (HELM): Liang et al., Holistic Evaluation of Language Models, 2022 — arXiv:2211.09110

Materiale informativo a cura di Rayer Group. Non costituisce consulenza tecnica o legale personalizzata: per il caso concreto valutiamo insieme la situazione specifica.