Condividi tramite

Procedure consigliate per l'uso dell'API Rilevamento anomalie multivariato

  • Articolo

Importante

A partire dal 20 settembre 2023 non sarà possibile creare nuove risorse di Rilevamento anomalie. Il servizio Rilevamento anomalie verrà ritirato il 1° ottobre 2026.

Questo articolo fornisce indicazioni sulle procedure consigliate da seguire quando si usano le API Rilevamento anomalie multivariato (MVAD). In questa esercitazione si apprenderà come:

  • Utilizzo API: Scopri come usare il rilevamento anomalie multivariato senza errori.
  • Ingegneria dei dati: Scopri come cucinare al meglio i dati in modo che il rilevamento anomalie multivariato funzioni con una maggiore accuratezza.
  • Problemi comuni: Scopri come evitare i problemi comuni riscontrati dai clienti.
  • Domande frequenti: Consulta le risposte alle domande frequenti.

Utilizzo delle API

Segui le istruzioni riportate in questa sezione per evitare errori durante l'uso del rilevamento anomalie multivariato. Se si verificano ancora errori, fare riferimento all'elenco completo dei codici di errore per consultare le spiegazioni e le azioni da eseguire.

Parametri di input

Parametri obbligatori

Questi tre parametri sono necessari nel caso di richieste API di training e inferenza:

  • source - Il collegamento al file ZIP che si trova nell'archiviazione BLOB di Azure con firme di accesso condiviso (SAS).
  • startTime - L’ora di inizio dei dati usati per il training o l'inferenza. Se è precedente al timestamp effettivo dei dati, il timestamp effettivo verrà usato come punto iniziale.
  • endTime - L’ora di fine dei dati usati per il training o l'inferenza, che deve essere successiva o coincidente con startTime. Se endTime è successivo al timestamp effettivo più recente nei dati, il timestamp effettivo più recente verrà usato come punto finale. Se endTime è uguale a startTime, ciò significa inferenza di un singolo punto dati che viene spesso usato negli scenari di streaming.

Parametri facoltativi per l'API di training

Gli altri parametri per l'API di training sono facoltativi:

  • slidingWindow - Numero di punti dati usati per determinare le anomalie. Un numero intero compreso tra 28 e 2.880. Il valore predefinito è 300. Se slidingWindow è k per il training del modello, almeno k punti devono essere accessibili dal file di origine durante l'inferenza per ottenere risultati validi.

    MVAD accetta un segmento di punti dati per decidere se il punto dati successivo rappresenta un'anomalia. La lunghezza del segmento è slidingWindow. Tenere presenti due aspetti quando si sceglie un valore slidingWindow:

    1. Le proprietà dei dati, indipendentemente dal fatto che siano periodiche, e la frequenza di campionamento. Quando i dati sono periodici, è possibile impostare la lunghezza di 1 - 3 cicli come slidingWindow. Quando i dati hanno una frequenza elevata (granularità ridotta) ad esempio a livello di minuti o secondi, è possibile impostare un valore relativamente più elevato di slidingWindow.
    2. Compromesso tra tempo di training/inferenza e potenziale impatto sulle prestazioni. Un valore slidingWindow maggiore può causare tempi di training/inferenza più lunghi. Non c'è garanzia che slidingWindow più elevati condurranno a guadagni in termini di accuratezza. Un slidingWindow piccolo può causare la difficile convergenza del modello verso una soluzione ottimale. Ad esempio, è difficile rilevare anomalie quando slidingWindow ha solo due punti.

  • alignMode - Come allineare più variabili (serie temporali) ai timestamp. Sono disponibili due opzioni per questo parametro, Inner e Outer, e il valore predefinito è Outer.

    Tale parametro è fondamentale quando si verifica un errore di allineamento tra le sequenze di timestamp delle variabili. Il modello deve allineare le variabili alla stessa sequenza di timestamp prima di continuare l'elaborazione.

    Inner indica che il modello invierà i risultati del rilevamento solo sui timestamp in cui ogni variabile ha un valore, ovvero all'intersezione di tutte le variabili. Outer indica che il modello segnala i risultati del rilevamento sui timestamp in cui una variabile qualsiasi ha un valore, ovvero all'unione di tutte le variabili.

    Di seguito è riportato un esempio utile per spiegare valori alignModel diversi.

    Variabile-1

    timestamp value
    2020-11-01 1
    2020-11-02 2
    2020-11-04 4
    2020-11-05 5

    Variabile-2

    timestamp value
    2020-11-01 1
    2020-11-02 2
    2020-11-03 3
    2020-11-04 4

    Inner unione di due variabili

    timestamp Variabile-1 Variabile-2
    2020-11-01 1 1
    2020-11-02 2 2
    2020-11-04 4 4

    Outer unione di due variabili

    timestamp Variabile-1 Variabile-2
    2020-11-01 1 1
    2020-11-02 2 2
    2020-11-03 nan 3
    2020-11-04 4 4
    2020-11-05 5 nan

  • fillNAMethod - Come compilare nan la tabella unita. Nella tabella unita potrebbero essere presenti valori mancanti, che devono essere gestite in maniera appropriata. Forniamo diversi metodi per effettuarne la compilazione. Le opzioni sono Linear, Previous, Subsequent, Zero e Fixed, mentre il valore predefinito è Linear.

    Opzione metodo
    Linear Inserire i valori nan in base all'interpolazione lineare
    Previous Propagare l'ultimo valore valido per riempire i vuoti. Esempio: [1, 2, nan, 3, nan, 4] ->[1, 2, 2, 3, 3, 4]
    Subsequent Usare il valore valido successivo per riempire i vuoti. Esempio: [1, 2, nan, 3, nan, 4] ->[1, 2, 3, 3, 4, 4]
    Zero Compilare i valori nan con 0.
    Fixed Compilare i valori nan con un valore valido specificato che deve essere indicato in paddingValue.

  • paddingValue - Il valore di riempimento viene usato per compilare nan quando fillNAMethod è Fixed e, in quel caso, deve essere specificato. In altri casi è facoltativo.

  • displayName - Si tratta di un parametro facoltativo usato per identificare i modelli. Ad esempio, è possibile usarlo per contrassegnare parametri, origini dati e altri metadati relativi al modello e ai relativi dati di input. Il valore predefinito è una stringa vuota.

Schema dei dati di input

MVAD rileva anomalie da un gruppo di metriche e ogni metrica viene detta variabile o serie temporale.

  • È possibile scaricare il file di dati di esempio da Microsoft per verificare lo schema accettato da: https://aka.ms/AnomalyDetector/MVADSampleData

  • Ciascuna variabile deve avere due soli due campi, timestamp e value, e deve essere archiviata in un file con valori delimitati da virgole (CSV).

  • I nomi delle colonne del file CSV devono essere esattamente timestamp e value, con distinzione tra maiuscole e minuscole.

  • I valori timestamp devono essere conformi a ISO 8601. I valori value possono essere numeri interi o decimali con un numero qualsiasi di cifre decimali. Un buon esempio del contenuto di un file CSV：

    timestamp value
    2019-04-01T00:00:00Z 5
    2019-04-01T00:01:00Z 3.6
    2019-04-01T00:02:00Z 4
    ... ...

    Nota

    Se i timestamp hanno ore, minuti e/o secondi, assicurarsi che vengano arrotondati correttamente prima di chiamare le API.

    Ad esempio, se la frequenza dei dati deve essere un punto dati ogni 30 secondi, ma vengono visualizzati timestamp come "12:00:01" e "12:00:28", è un segnale forte che è consigliabile pre-elaborare i timestamp in nuovi valori come "12:00:00" e "12:00:30".

    Per informazioni dettagliate, vedere la sezione "Timestamp round-up" nel documento sulle procedure consigliate.

  • Il nome del file CSV verrà usato come nome della variabile e deve essere univoco. Ad esempio, "temperature.csv" e "humidity.csv".

  • Le variabili per il training e le variabili per l'inferenza devono essere coerenti. Ad esempio, se si usano series_1, series_2, series_3, series_4 e series_5 per il training, è necessario fornire esattamente le stesse variabili per l'inferenza.

  • I file CSV devono essere compressi in un file ZIP e caricati in un contenitore BLOB di Azure. Il file ZIP può avere qualsiasi nome.

Struttura delle cartelle

Un errore comune nella preparazione dei dati è costituito dalle cartelle aggiuntive nel file ZIP. Si supponga, ad esempio, che il nome del file ZIP sia series.zip. Dopo aver decompresso i file in una nuova cartella ./series, il percorso corretto dei file CSV è ./series/series_1.csv, mentre un percorso errato potrebbe essere ./series/foo/bar/series_1.csv.

Esempio corretto dell'albero della directory dopo la decompressione del file ZIP in Windows

.
└── series
    ├── series_1.csv
    ├── series_2.csv
    ├── series_3.csv
    ├── series_4.csv
    └── series_5.csv

Esempio errato dell'albero delle directory dopo la decompressione del file ZIP in Windows

.
└── series
    └── series
        ├── series_1.csv
        ├── series_2.csv
        ├── series_3.csv
        ├── series_4.csv
        └── series_5.csv

Ingegneria dei dati

A questo punto è possibile eseguire il codice con le API Rilevamento anomalie multivariato senza errori. Cosa si può fare per migliorare l'accuratezza del modello?

Qualità dei dati

  • Man mano che il modello apprende modelli normali dai dati cronologici, i dati di training devono rappresentare lo stato normale complessivo del sistema. È difficile per il modello apprendere questi tipi di modelli se i dati di training sono pieni di anomalie. Una soglia empirica di frequenza anomala per una buona accuratezza è uguale o inferiore all’1%.
  • In generale, la percentuale di valori mancanti dei dati di training deve essere inferiore al 20%. Troppi dati mancanti possono far sì che i valori compilati automaticamente (in genere valori lineari o valori costanti) vengano appresi come modelli normali. Questo può far sì che punti di dati reali (non mancanti) vengano rilevati come anomalie.

Quantità di dati

  • Il modello sottostante di Rilevamento anomalie multivariato ha milioni di parametri. È necessario un numero minimo di punti dati per apprendere un set ottimale di parametri. La regola empirica è che per una buona accuratezza è necessario fornire 5.000 punti dati (timestamp) o più per variabile per eseguire il training del modello. In generale, più dati di training ci sono e maggiore è l’accuratezza. Tuttavia, nei casi in cui non si è in grado di raccogliere tale quantità di dati, è comunque consigliabile sperimentare con meno dati e verificare se l'accuratezza compromessa è ancora accettabile.

  • Ogni volta che si chiama l'API di inferenza, è necessario assicurarsi che il file di dati di origine contenga solo punti dati sufficienti. Questo è in genere slidingWindow + numero di punti dati che necessitano realmente di risultati di inferenza. Ad esempio, in un caso streaming in cui ogni volta che si vuole fare un’inferenza su UN nuovo timestamp, il file di dati può contenere solo il slidingWindow iniziale più UN punto dati, quindi è possibile procedere e creare un altro file ZIP con lo stesso numero di punti dati (slidingWindow + 1) ma spostandosi di una posizione sul lato "destro" ed effettuare l’invio per un altro processo di inferenza.

    Qualsiasi elemento oltre ciò o "prima" della finestra temporale scorrevole iniziale non avrà alcuna conseguenza sul risultato dell'inferenza e può causare solo una riduzione delle prestazioni. Qualsiasi elemento di seguito a ciò può causare un errore NotEnoughInput.

Arrotondamento timestamp

In un gruppo di variabili (serie temporali), ogni variabile può essere raccolta da un'origine indipendente. I timestamp di variabili diverse possono non essere coerenti tra loro né con le frequenze note. Un semplice esempio viene riportato di seguito.

Variabile-1

timestamp value
12:00:01 1.0
12:00:35 1,5
12:01:02 0.9
12:01:31 2.2
12:02:08 1.3

Variabile-2

timestamp value
12:00:03 2.2
12:00:37 2.6
12:01:09 1.4
12:01:34 1,7
12:02:04 2.0

Ci sono due variabili raccolte da due sensori che inviano un punto dati ogni 30 secondi. Tuttavia, i sensori non inviano punti dati a una frequenza rigorosamente uniforme, a volte li inviano prima e a volte dopo. Poiché il rilevamento anomalie multivariato prende in considerazione le correlazioni tra variabili diverse, i timestamp devono essere allineati adeguatamente, in modo che le metriche riflettano correttamente la condizione del sistema. Nell'esempio precedente, i timestamp della variabile 1 e della variabile 2 devono essere correttamente arrotondati alla frequenza prima dell'allineamento.

Vediamo cosa accade se non vengono pre-elaborati. Se si imposta alignMode su Outer (che significa l'unione di due set), la tabella unita è:

timestamp Variabile-1 Variabile-2
12:00:01 1.0 nan
12:00:03 nan 2.2
12:00:35 1,5 nan
12:00:37 nan 2.6
12:01:02 0.9 nan
12:01:09 nan 1.4
12:01:31 2.2 nan
12:01:34 nan 1,7
12:02:04 nan 2.0
12:02:08 1.3 nan

nan indica valori mancanti. Ovviamente, la tabella unita non è quella prevista. La variabile 1 e la variabile 2 si intersecano e il modello rilevamento anomalie multivariato non può estrarre informazioni sulle correlazioni tra di esse. Se si imposta alignMode su Inner, la tabella unita è vuota perché non esiste un timestamp comune alla variabile 1 e alla variabile 2.

Di conseguenza, i timestamp della variabile 1 e della variabile 2 devono essere pre-elaborati (arrotondati ai timestamp di 30 secondi più vicini), e le nuove serie temporali sono:

Variabile-1

timestamp value
12:00:00 1.0
12:00:30 1,5
12:01:00 0.9
12:01:30 2.2
12:02:00 1.3

Variabile-2

timestamp value
12:00:00 2.2
12:00:30 2.6
12:01:00 1.4
12:01:30 1,7
12:02:00 2.0

Ora la tabella unita è più ragionevole.

timestamp Variabile-1 Variabile-2
12:00:00 1.0 2.2
12:00:30 1,5 2.6
12:01:00 0.9 1.4
12:01:30 2.2 1,7
12:02:00 1.3 2.0

I valori di variabili diverse in timestamp vicini sono ben allineati e il modello rilevamento anomalie multivariato ora può estrarre informazioni sulla correlazione.

Limiti

Esistono alcune limitazioni nelle API di training e inferenza, per evitare errori è necessario tenere presente queste limitazioni.

Limitazioni generali

  • Finestra temporale scorrevole: 28-2880 timestamp, con un valore predefinito di 300. Per i dati periodici, impostare la lunghezza di 2-4 cicli come finestra temporale scorrevole.
  • Numeri variabili: per il training e l'inferenza batch, al massimo 301 variabili.

Limitazioni del training

  • Timestamp: al massimo 1000000. Un numero eccessivo di timestamp può ridurre la qualità del modello. È consigliabile avere più di 5.000 timestamp.
  • Granularità: la granularità minima è per_second.

Limitazioni dell'inferenza batch

  • Timestamp: al massimo 20000, almeno 1 lunghezza della finestra temporale scorrevole.

Limitazioni dell'inferenza di streaming

  • Timestamp: al massimo 2880, almeno 1 lunghezza della finestra scorrevole.
  • Rilevamento dei timestamp: da 1 a 10.

Qualità del modello

Come gestire i falsi positivi e i falsi negativi in scenari reali?

È stata fornita una gravità che indica la rilevanza delle anomalie. I falsi positivi possono essere filtrati impostando una soglia in base alla gravità. In alcuni casi è possibile che vengano visualizzati troppi falsi positivi quando si verificano spostamenti di criteri nei dati di inferenza. In questi casi potrebbe essere necessario ripetere il training di un modello sui nuovi dati. Se i dati di training contengono troppe anomalie, potrebbero esserci falsi negativi nei risultati del rilevamento. Ciò è dovuto al fatto che il modello apprende degli schemi dai dati di training, e le anomalie possono causare distorsioni al modello. La pulizia corretta dei dati può quindi contribuire a ridurre i falsi negativi.

Come stimare quale modello è preferibile usare in base alla perdita di training e alla perdita di convalida?

In generale, è difficile decidere qual è il modello migliore senza un set di dati etichettato. Tuttavia, è possibile sfruttare le perdite di training e di convalida per ottenere una stima approssimativa e rimuovere tali modelli non validi. Prima di tutto, dobbiamo osservare se le perdite di training convergono. Perdite divergenti spesso indicano una scarsa qualità del modello. In secondo luogo, i valori di perdita possono aiutare a determinare se si verifica l'underfitting o l'overfitting. I modelli in underfitting o overfitting potrebbero non avere le prestazioni desiderate. Terzo, anche se la definizione della funzione di perdita non riflette direttamente le prestazioni di rilevamento, i valori di perdita possono essere uno strumento ausiliario per stimare la qualità del modello. Un basso valore di perdita è una condizione necessaria per un modello valido, pertanto è possibile eliminare i modelli con valori di perdita elevati.

Inconvenienti comuni

Oltre alla tabella dei codici di errore, abbiamo appreso dai clienti come te alcuni problemi comuni emersi durante l'uso delle API rilevamento anomalie multivariato. Questa tabella consente di evitare questi problemi.

Problema Conseguenza Spiegazione e soluzione
I timestamp nei dati di training e/o nei dati di inferenza non sono stati arrotondati affinché possano essere allineati alla rispettiva frequenza dati di ogni variabile. I timestamp dei risultati di inferenza non sono quelli previsti: troppi timestamp o troppo pochi timestamp. Vedi Arrotondamento timestamp.
Troppi punti dati anomali nei dati di training L'accuratezza del modello è influenzata negativamente perché considera i punti dati anomali come modelli normali durante il training. Empiricamente, può essere utile mantenere il tasso anormale a un livello pari o inferiore all’1%.
Dati di training troppo esigui L'accuratezza del modello è compromessa. Empiricamente, per mantenere una buona accuratezza il training di un modello rilevamento anomalie multivariato richiede 15.000 o più punti dati (timestamp) per variabile.
Acquisizione di tutti i punti dati con isAnomaly=true come anomalie Troppi falsi positivi È consigliabile usare sia isAnomaly che severity (o score) per analizzare le anomalie che non sono gravi e (facoltativamente) usare il raggruppamento per controllare la durata delle anomalie ed eliminare i rumori casuali. Per conoscere la differenza tra severity e score, vedere la sezione domande frequenti di seguito.
Le sottocartelle vengono compresse nel file di dati per il training o l'inferenza. I file di dati CSV all'interno di sottocartelle vengono ignorati durante il training e/o l'inferenza. Nel file ZIP non sono consentite sottocartelle. Per informazioni dettagliate, vedi Struttura delle cartelle.
Troppi dati nel file di dati di inferenza: ad esempio, tutti i dati cronologici vengono compressi nel file ZIP dei dati di inferenza È possibile che non vengano visualizzati errori, ma si riscontrano prestazioni ridotte quando si tenta di caricare il file ZIP nel BLOB di Azure o quando si tenta di eseguire l'inferenza. Per informazioni dettagliate, vedi Quantità dei dati.
Creazione di risorse rilevamento anomalie nelle aree di Azure che non supportano ancora il rilevamento anomalie multivariato e chiamano le API MVAD Si riceverà un errore "risorsa non trovata" durante la chiamata alle API MVAD. Durante la fase di anteprima, il rilevamento anomalie multivariato è disponibile solo in alcune aree. Aggiungere un segnalibro Novità di Rilevamento anomalie per mantenere aggiornate le implementazioni MVAD nella regione. Inoltre, è possibile segnalare un problema di GitHub o contattarci all'indirizzo AnomalyDetector@microsoft.com per richiedere informazioni relativamente a regioni specifiche.

Domande frequenti

Come funziona la finestra temporale scorrevole di MVAD?

Utilizziamo due esempi per capire come funziona la finestra temporale scorrevole di MVAD. Si supponga di aver impostato slidingWindow = 1.440 e che i dati di input abbiano una granularità di un minuto.

  • Scenario streaming: si vuole stimare se il punto dati UNO in "2021-01-02T00:00:00Z" è anomalo. Il valore di startTime e endTime sarà lo stesso ("2021-01-02T00:00:00Z"). L'origine dati di inferenza, tuttavia, deve contenere almeno 1.440 + 1 timestamp. Poiché MVAD accetta i dati iniziali prima del punto dati di destinazione ("2021-01-02T00:00:00Z"), per decidere se la destinazione è un'anomalia. La lunghezza dei dati iniziali necessari è slidingWindow o 1.440 in questo caso. 1.440 = 60 * 24, quindi i dati di input devono iniziare dall'ultimo "2021-01-01T00:00:00Z".

  • Scenario batch: sono disponibili più punti dati di destinazione da stimare. Il valore endTime sarà maggiore di startTime. L'inferenza in tali scenari viene eseguita in modo "finestra mobile". Ad esempio, rilevamento anomalie multivariato userà i dati da 2021-01-01T00:00:00Z a 2021-01-01T23:59:00Z (inclusi) per determinare se i dati in 2021-01-02T00:00:00Z sono anomali. Quindi procede e usa i dati da 2021-01-01T00:01:00Z a 2021-01-02T00:00:00Z (inclusi) per determinare se i dati in 2021-01-02T00:01:00Z sono anomali. Procede nello stesso modo (prendendo 1.440 punti dati da confrontare) fino all'ultimo timestamp specificato da endTime (o al timestamp effettivo). Pertanto, l'origine dati di inferenza deve contenere dati a partire da startTime - slidingWindow e idealmente contenere un totale di dimensioni slidingWindow + (endTime - startTime).

Qual è la differenza tra severity e score?

In genere è consigliabile usare severity come filtro per analizzare le "anomalie" che non sono così importanti per la propria attività. A seconda dello scenario e dello schema di dati, le anomalie che sono meno importanti spesso hanno valori severity relativamente inferiori o valori severity elevati autonomi (discontinui) come picchi casuali.

Nei casi in cui è stata rilevata una necessità di regole più sofisticate rispetto alle soglie severity rispetto o alla durata dei valori elevati severity continui, è possibile usare score per creare filtri più potenti. Può essere utile capire il modo in cui il rilevamento anomalie multivariato usa score per determinare le anomalie:

Valutiamo se un punto dati è anomalo sia da una prospettiva globale che locale. Se score in un timestamp è superiore a una determinata soglia, allora il timestamp viene contrassegnato come anomalia. Se score è inferiore alla soglia ma è relativamente superiore in un segmento, viene contrassegnato sempre come anomalia.

Passaggi successivi