La ricerca è finita quando gira

C’è un momento in ogni progetto di machine learning in cui le metriche sono buone e tutti si rilassano. Il modello separa le classi. La curva di validazione si comporta bene. Qualcuno mette un numero in una slide.

Quel momento è più o meno a un terzo del lavoro, e viene scambiato molto spesso per la fine.

Passo il tempo su entrambi i lati di questa linea — ricerca su imaging medicale, e consulenza per portare modelli dentro sistemi che le persone usano di martedì. La distanza tra i due non è un passo di deployment. È un insieme di cose che nel notebook non c’erano mai state e che vanno progettate dentro, di solito prima di quanto faccia piacere.

Il notebook mente su quattro cose

Mente sui dati. In un notebook hai un dataset. In produzione hai un flusso di record che arrivano in un formato definito da qualcun altro, con campi mancanti, problemi di codifica, e una banca che il mese scorso ha cambiato il formato delle causali senza dirlo a nessuno. Il codice di pulizia nel notebook è stato scritto una volta, su dati che erano già stati puliti una volta. Quel codice non è la pipeline. È lo schizzo di quello che la pipeline dovrà fare, per sempre, senza nessuno che guardi.

Mente sulla latenza. Nessuno misura il tempo di inferenza in un notebook, perché non c’è niente in attesa. In produzione c’è sempre qualcosa in attesa, e di solito è una persona davanti a uno schermo.

Mente sulla decisione. Un notebook produce una previsione. Un sistema deve produrre un’azione — accetta, proponi, escala, rifiuta. Tra la previsione e l’azione sta una soglia, e quella soglia è una decisione di business travestita da iperparametro. Alta, il sistema fa risparmiare poco. Bassa, il primo errore visibile distrugge per sempre la fiducia dell’operatore. Quel numero non si trova in validazione. Si trova nell’uso.

Mente sul tempo. Un notebook è una fotografia. Il mondo lì dentro non si muove. L’azienda cambia, i dati derivano, e il modello che a marzo era giusto a novembre è silenziosamente sbagliato — e niente nel notebook ti dirà in che settimana è successo.

Cosa colma davvero la distanza

Decidi dove vivrà il modello prima di addestrarlo. È la decisione che difenderei con più forza e quella che più spesso viene presa per ultima. Un modello che gira dentro la schermata che un operatore già usa viene usato. Lo stesso modello, più accurato, in uno strumento separato, no — perché nessuno lo apre. Una risposta giusta nel posto sbagliato non è una risposta. Se quel vincolo comporta scegliere una libreria che sta dentro il runtime esistente invece di quella che sceglieresti sul merito, scegli quella che ci sta. Il vincolo è il requisito.

Consegna la confidenza, non solo la previsione. Una previsione da sola costringe il sistema a fingere di avere sempre ragione. Una previsione con una confidenza permette di costruire l’unico flusso che qualcuno accetterà: confidenza alta proposta e accettata con un’occhiata, confidenza bassa portata a una persona. È anche ciò che rende il sistema misurabile in termini che l’azienda riconosce — non l’accuratezza, ma quanta revisione ha tolto.

Registra le correzioni. Quando qualcuno sovrascrive il modello, quella correzione è il dato più prezioso che otterrai mai: un esempio etichettato di un caso che hai sbagliato, prodotto da un esperto, gratis. Un sistema che lo butta è un sistema che può solo peggiorare rispetto a un mondo che continua a muoversi.

Costruisci l’explainability dentro, non sopra. Nel medicale non è negoziabile: un clinico non agisce su una previsione che non può interrogare. Ma il vincolo è salutare ovunque. Dà forma all’architettura: rami che puoi ablare, feature che puoi indicare, una catena di preprocessing che puoi ripercorrere all’indietro. Se la aggiungi dopo, di solito finisci per cambiare comunque l’architettura, più tardi e in condizioni peggiori.

Rendi la pipeline riproducibile prima di rendere il modello migliore. Un modello che non sai ricostruire è un modello che non sai correggere. La riproducibilità non è igiene di processo: è la differenza tra un artefatto e un aneddoto.

Perché è un problema di ricerca e non di ingegneria

L’istinto è di archiviare tutto questo sotto ingegneria — la parte sporca dopo la scienza. È proprio quella inquadratura a causare il problema.

Il preprocessing decide cosa il modello può imparare. La soglia decide cosa il sistema fa davvero. L’explainability vincola quali architetture siano addirittura ammissibili. Non sono a valle della ricerca: sono dentro. Trattarle come il problema di qualcun altro produce un modello le cui ottime metriche descrivono un compito che non ha nessuno.

Un modello in un notebook non è stato finito. È stato descritto. Il lavoro è finito quando gira — e quando qualcuno che non sei tu riesce a dire che sei mesi dopo sta ancora girando bene.