9 key tasks for a successful, Machine-Learning based, Anomaly Detection system. Anomaly Detection con Machine Learning: 9 steps per avere successo
Matteo Longoni, Business Development Manager, Moviri Analytics
RIASSUNTO
Quando un sistema di anomaly detection deve essere integrato in ambiente di produzione, indipendentemente dai modelli di machine learning utilizzati per svilupparlo - e la letteratura ne offre svariati - per le aziende iniziano i guai. Perché? Perché temi come assegnazione delle risorse, data drift, utenti finali, requisiti di latenza, prestazioni e scalabilità, sono spesso sottovalutati: e generano problemi e com-plessità che sviluppatori e ingegneri faticano a risolvere nel momento in cui il sistema deve scalare a livello aziendale.
La soluzione? Un approccio end-to-end, che accoppia una solida base di data engineering, tecnologie big data, machine learning e MLOps all’avanguardia, con un focus incentrato sull’azienda by design. Ovvero pensato fin dall’inizio per l’ambiente di produzione, integrato, automatizzato e in grado di evolvere per supportare i processi aziendali: una soluzione scalabile end-to-end.
Questo è quello che facciamo in Moviri quando sviluppiamo le nostre solution di business Analytics, e, in questo documento, presentiamo un modello pratico per executives per assicurarsi che i sistemi di anomaly detection mantengano la loro promessa di innovazione e creazione di valore per l’azienda.
Contattaci a info@moviri.com per saperne di più su Moviri Analytics.
ABSTRACT
Regardless of which machine learning methods one uses to perform anomaly detection - and the literature offers plenty of them - companies usually run into trouble when it comes to deploying such methods in an enterprise business environment. Resource allocation and usage demands, as well as latency, performance and scalability requirements, are often underestimated. This can create major issues and complexities that data scientists and data engineers must deal with, when designing an anomaly detection pipeline. In Moviri Analytics we strongly believe in a complete approach, combining a solid foundation in data engineering, big data technologies and the leading edge technologies in machine learning and MLOps, with an enterprise focussed approach. We have the ability to understand the requirements and develop analytics solutions in production that are integrated, automated, actionable, and capable of evolving to support business processes, delivering an end to end solution at scale. In this paper, we offer a practical, high-level blueprint that executives can follow to make sure anomaly detection systems fulfill their innovation and value-creation promise.
Ti presento l’Anomaly Detection
Il termine anomalia è spesso usato come sinonimo di outlier. C’è, tuttavia, una sottile ma fondamentale differenza tra i due: un outlier è un evento che, data una certa distribuzione di dati, è improbabile che accada, ovvero un evento a bassa probabilità. Un’anomalia, invece, è un evento che, data una stessa distribuzione dei dati è impossibile da spiegare a priori. Mentre gli outlier sono accidentali e possono essere causati dal caso, le anomalie hanno radici più profonde, che possono essere ricondotte a condizioni o eventi casuali. Ma nella misura in cui hanno alla base meccanismi specifici che le generano, il primo scopo dell’anomaly detection è scoprirli.
Quando parliamo di Anomaly Detection, ci riferiamo a un gruppo di tecniche di machine learning il cui scopo è individuare anomalie in una serie di osservazioni, in genere per individuare e prevenire comportamenti indesiderati. In questo senso, la prima considerazione è che il rilevamento “tradizionale” delle anomalie presenta limitazioni significative.
E per quanto riguarda invece temi come falsi positivi, data drift, user unfriendliness, e le dipendenze dai team IT, tipiche barriere per far scalare modelli di ML in produzione?
Il fatto è che l’anomaly detection ha un grande potenziale: se eseguita correttamente! Le organizzazioni devono ripensare ai loro approcci, costruendo sistemi in grado di superare questi ostacoli e di funzionare in modo efficiente, pur mantenendoli “leggeri” e flessibili.
Ma come fare? Sei sicuro che la strategia e i processi siano impostati verso il raggiungimento del ROI che ti aspetti investendo -perchè in fondo di investire si tratta, all’inizio- nell’anomaly detection?
Sapere quale libro prendere dallo scaffale non è facile. Ogni algoritmo deve essere adattato per affrontare sfide ad alto impatto aziendale e gestito su larga scala nel rispetto dei vincoli e dell’ambito specifico del contesto operativo aziendale. Abbiamo sviluppato una breve guida per aiutarti a impostare un progetto di anomaly detection basata su machine learning in grado di abilitare il cui valore -ex ante- è potenzialmente disruptive. Questo progetto coinvolge 9 fasi critiche distinte, organizzate in 3 fasi principali:
- Preparation - Crea le basi per il successo
- Build - Sviluppa il sistema per raggiungerlo
- Operationalize - Abilita la generazione di valore continuo per l’azienda.
- Preparation - Crea le basi per il successo
1. Contesto: analisi di processo, tipo di anomalie, parametri
In ogni problema di tipo analitico, comprendere e codificare il contesto è il primo passo essenziale. Ciò è tanto più vero nei sistemi di anomaly detection. Il contesto ci permette di capire quali parti del processo e su quali parametri dovremmo concentrarci.
Il sistema deve essere disegnato in modo che possa raggiungere gli obiettivi descritti dai requisiti aziendali rilevanti: come funziona il processo sottostante? Quali tipi di anomalie stiamo cercando? Quali sono gli input e gli output principali che vogliamo codificare?
Ad esempio, questione fondamentale dell’analisi è identificare quali variabili sono buone candidate target per individuare le anomalie. Ad esempio, in un tipico caso d’uso, come il monitoraggio delle transazioni, dovremmo concentrarci sul numero di valori anomali? Sulla tempistica con cui si verificano? Sugli eventi statistici empirici? Abbiamo tutti i dati necessari? Questo passaggio è fondamentale in quanto consente agli analisti di codificare e soprattutto entrare nel merito del dominio, vero obiettivo finale di questo step.
2. Valutazione dei dati: dati, frequenza, volume
Con una solida mappatura del contesto, possiamo passare ai dati. In primo luogo, dobbiamo identificare chiaramente i set e gli stream di dati di origine, e in secondo luogo assicurarci che siano completi e corretti. Task non banali, poiché in genere richiedono il coinvolgimento di una varietà di stakeholder: i proprietari dei processi, i proprietari dei dati, chi gestisce la governance. Dal punto di vista tecnico, invece, ingegneri di sistemi IT, data scientist, data engineer, che devono fare la valutazione tecnica: profondità dello storico, frequenza di aggiornamento, volume, pipelines e infrastrutture necessarie per alimentare il sistema.
Ad esempio, l’individuazione di anomalie dipende molto dalla frequenza con cui i dati sottostanti vengono aggiornati, per cui anche i processi a monte che regolano l’afflusso e l’aggiornamento dei dati devono essere mappati in un quadro completo del processo, vero obiettivo finale di questo step.
3. Vincoli: perimetro, granularità, requisiti operativi, real time
Step successivo nel progettare un sistema di anomaly detection è l’analisi dei vincoli operativi. La premessa è che non esiste un algoritmo che funzioni bene in tutte le condizioni: ogni algoritmo funziona al meglio sotto determinati presupposti, che possono essere difficili da soddisfare in produzione e che quindi devono essere ben compresi prima di iniziare.
A volte i vincoli derivano dalla definizione stessa degli obiettivi di anomaly detection o dei requisiti degli utenti. Ad esempio, se nel sistema di monitoraggio delle transazioni l’obiettivo è di catturare il 99% o del 50% delle anomalie, fa una differenza strutturale nella progettazione del sistema. Altrettanto importanti sono i vincoli non correlati ai dati e agli algoritmi stessi, come i vincoli di usabilità. In che modo gli utenti devono essere informati delle anomalie? Quante volte? Tramite e-mail, web, app o una combinazione? Tornando all’esempio del monitoraggio delle transazioni, se le anomalie sono correlate al mancato pagamento di un canale, potrebbe essere inutile avvisare il responsabile del processo una volta al giorno: se l’obiettivo è garantire la continuità del servizio. Piuttosto, è meglio avvisarlo real time. Una volta al giorno o ogni secondo, impatta drasticamente sul sistema: da qui l’importanza di definire parametri e un perimetro chiaro entro il quale devono funzionare gli algoritmi di anomaly detection.
4. Machine learning: algoritmo, modello, approccio
Una volta che la base per l’anomaly detection è solida, siamo pronti per iniziare a lavorare sulla selezione dei migliori algoritmi e modelli. Anche in questo caso, la letteratura può aiutare, ma sapere quale libro dovremmo scegliere dallo scaffale della biblioteca non è facile...
Prendiamo ad esempio eventi rari. Per definizione, un’anomalia è un evento che rappresenta un significativo allontanamento dal funzionamento “normale” e, pertanto, gli eventi anomali possono essere pochi e rari. Occasionalmente, potremmo anche non sapere che aspetto abbia effettivamente un’anomalia. Gli algoritmi di machine learning potrebbero dover tenere conto di problemi di squilibrio di classe o determinare le caratteristiche di un’anomalia in modo autonomo, elevando il livello di specificità richiesto. Trend e stagionalità sono un altro esempio. Molti algoritmi etichettano i punti dati come anomali se superano alcune soglie predefinite. Sfortunatamente, questi algoritmi falliscono quando i dati presentano un comportamento di tendenza e/o stagionalità (pensa ai dati di vendita che raggiungono il picco prima della fine dell’anno e diminuiscono subito dopo).
Questo è il regno del machine learning e dei data scientists.
5. Tecnologie: software, piattaforme, pipelines
Quando si parla di sistema, si intende naturalmente l’insieme di componenti che lo compongono. Che nel caso dell’anomaly detection sono molteplici: strumenti software, architetture, storage, pipelines per citarne alcuni.
Per un ambiente che li orchestri tutti e ne garantisca le prestazioni, ogni anello della catena deve funzionare perfettamente. Ma con una scelta pressochè infinita di piattaforme, software, librerie, commerciali o open source, la selezione dei componenti giusti è fondamentale. E non solo: possiamo optare per una soluzione cloud, o on-premise. O ibrida: e in questo caso, come determinare quali componenti sono incloud?
Queste considerazioni valgono ovviamente che il sistema di anomaly detection sia progettato da zero, o costruito su un’architettura esistente. In ogni caso, è importante rifarsi sempre agli obiettivi che si vogliono raggiungere e lavorare di conseguenza per trovare la soluzione architetturale migliore che li abiliti. Questo è il regno dei Data Engineers.
6. Tuning: test, convalida dell’accuratezza, gestione delle eccezioni
Abbiamo già detto che i sistemi di anomaly detection a soglie o basati sull’osservazione empirica sono di gran lunga meno accurati rispetto a quelli basati su machine learning. D’altro canto, questi ultimi introducono più complessità e customizzazioni: il bianco e il nero lasciano il posto alle sfumature del grigio.
Del resto, un’anomalia è spesso il risultato di una combinazione di fattori e delle loro interazioni. Ad esempio, quando un macchinario industriale si guasta, in genere si registrano modifiche nei dati provenienti da diversi sensori, ognuno dei quali potrebbe non essere di per sé sufficiente a rilevare un’anomalia. È la loro combinazione che segnala un’anomalia correlata al guasto. Oppure, un’anomalia può verificarsi quando si verifica un certo pattern di fattori, o ancora, un’anomalia può esserlo a seconda del contesto e dell’ambiente in cui si verifica e non esserlo in uno diverso. In alcune situazioni, è fondamentale che solo le anomalie principali siano etichettate come tali (si pensi a costosi guasti industriali), mentre in altre mancare anche una singola anomalia sarebbe molto grave (il test COVID è un esempio). Problemi diversi richiedono approcci di messa a punto e ottimizzazione diversi. La chiave è modellare la complessità del contesto per definire scale appropriate alle anomalie (ad es. di criticità), in modo da pianificare gli interventi su quelli prioritari, o con cause profonde.
Rendi operativo - Crea le procedure per produrre valore continuo.
7. MLOps (manutenzione nelle operazioni ML, miglioramento continuo, manutenzione)
Traslazione nel mondo Machine Learning dei concetti DevOps (e DataOps, tema da trattare in un articolo dedicato), MLOps è un framework progettato per orchestrare, automatizzare e far scalare le operazioni richieste da un modello di machine learning per essere mantenuto efficiente (di valore) in produzione. Di fatto, risolve la spinosa questione che avrai difficoltà a sfruttare appieno i benefici di un sistema di anomaly detection (o di ML in generale) a livello aziendale, senza il supporto di un processo MLOps ben sviluppato.
- Le attività di MLOps includono:
- automazione delle fasi di sviluppo dei modelli di machine learning (ad es. estrazione e preparazione dei dati, addestramento e valutazione del modello...);
- gestione dei servizi associati (ad es. manutenzione, monitoraggio di metriche relative alla salute, tempo di risposta, tempo di esecuzione...);
- Gestione del data drifting, re-training…
Il mondo reale cambia ogni giorno e ciò che è anomalo oggi potrebbe essere normale domani. MLOps garantisce che i tuoi modelli siano costantemente allineati alle mutevoli condizioni, e performino sempre al meglio.
8. Onboarding: stakeholder, utenti, gestione del cambiamento, formazione
La chiave in questo step è: coinvolgi i tuoi stakeholder, comprendi le loro esigenze e rendili felici. Facile, non è vero? In realtà sì, se siamo pienamente consapevoli di chi siano e di quali siano le loro esigenze e aspettative.
Pensa ad esempio a un project manager IT o all’utente di business finale. O il manager dell’utente di business finale. O il responsabile del processo su cui fare anomaly detection. Ogni figura coinvolta nel progetto è, di fatto, uno stakeholder. Dobbiamo garantire che le loro aspettative siano soddisfatte, anzitutto capendole: adottando la loro prospettiva, e adeguandosi ai rispettivi livelli di background e competenza. Ma non basta. Aggiornali, mostra loro risultati concreti, tienili “sul pezzo” per tutta la durata del progetto. Se interagisci solo nei SAL principali, rischi di scoprire troppo tardi che piccole incomprensioni hanno creato distanze enormi fra risultato e aspettative. Guida le parti interessate verso il risultato finale, avendo ben presente la prospettiva di ogni individuo. Perché è importante renderli felici tutti (come lo è, dopotutto, per tutti i nostri clienti), perché vuol dire che il valore atteso è stato raggiunto.
9. Comunicazione: visualizzazione, report, allerta, evidenza delle priorità
Più un metodo è avanzato, più difficile può essere interpretare i risultati per i non esperti. Il primo punto quindi è assicurarsi di far capire il comportamento e l’output del sistema di anomaly detection, senza entrare nel merito.
Ma come? Principio generale sempre valido è attenersi alla semplicità e a strumenti, sistemi, visualizzazioni e linguaggi che gli stakeholder già utilizzano. Questo aiuta ad abbassare le barriere di ingresso. C’è sempre tempo per approfondire.
Ad esempio, se stai parlando con un Data Engineer che cerca di definire gli obiettivi del progetto, devi sforzarti di rispondere alle loro domande specifiche anche se l’idea del risultato finale che hai è ancora ad alto livello. Perché questo renderà più probabile che i risultati si avvicinino alle tue aspettative e ragionarci sopra darà forma ai dettagli nella tua mente.
D’altro canto, se stai presentando a qualcuno che non ha la tua esperienza nel campo della Data Science, concentrati sui risultati concreti che ti fornisce il sistema di anomaly detection: rilevare e classificare automaticamente 10 volte più anomalie di quanto facevi prima, con un ordine di grandezza in meno di di falsi positivi, in molto meno tempo (tratto da storia vera).
Perché indipendentemente da quale algoritmo magico o quante righe di perfetto codice PySpark hai scritto, il risultato finale è quello che porta benefici, su tutti i livelli, e su cui viene misurato il successo e il valore vero di un sistema di anomaly detection.