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

  • Articolo

Importante

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

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

  • Utilizzo api: informazioni su come usare MVAD senza errori.
  • Ingegneria dei dati: informazioni su come cucinare al meglio i dati in modo che MVAD funzioni con una maggiore precisione.
  • Problemi comuni: informazioni su come evitare insidie comuni che i clienti incontrano.
  • Domande frequenti: informazioni sulle risposte alle domande frequenti.

Utilizzo delle API

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

Parametri di input

Parametri obbligatori

Questi tre parametri sono necessari nelle richieste api di training e inferenza:

  • source- Il collegamento al file ZIP che si trova nel Archiviazione BLOB di Azure con firme di accesso condiviso (SAS).
  • startTime - 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 - Ora di fine dei dati usati per il training o l'inferenza che deve essere successiva o uguale a startTime. Se endTime è successivo al timestamp più recente effettivo nei dati, il timestamp più recente effettivo verrà usato come punto finale. Se endTime è uguale a startTime, significa inferenza di un singolo punto dati che viene spesso usato negli scenari di streaming.

Parametri facoltativi per l'API di training

Altri parametri per l'API di training sono facoltativi:

  • slidingWindow - Numero di punti dati usati per determinare le anomalie. Intero compreso tra 28 e 2.880. Il valore predefinito è 300. Se slidingWindow è k per il training del modello, almeno i 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 è un'anomalia. La lunghezza del segmento è slidingWindow. Tenere presenti due aspetti quando si sceglie un slidingWindow valore:

    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) come il livello di minuto o il secondo livello, è possibile impostare un valore relativamente più elevato di slidingWindow.
    2. Compromesso tra tempo di training/inferenza e potenziale impatto sulle prestazioni. Un valore maggiore slidingWindow può causare tempi di training/inferenza più lunghi. Non c'è garanzia che più grandi slidingWindowcondurranno a guadagni di accuratezza. Una piccola slidingWindow può causare la difficile convergenza del modello in 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 Outere il valore predefinito è Outer.

    Questo 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, ad esempio l'intersezione di tutte le variabili. Outer indica che il modello segnala i risultati del rilevamento sui timestamp in cui qualsiasi variabile ha un valore, ad esempio l'unione di tutte le variabili.

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

    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 join di due variabili

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

    Outer join 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. Potrebbero essere presenti valori mancanti nella tabella unita e devono essere gestiti correttamente. Forniamo diversi metodi per riempirli. Le opzioni sono Linear, PreviousSubsequent, Zero, e Fixed il valore predefinito è Linear.

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

  • paddingValue - Il valore di riempimento viene usato per riempire nan quando fillNAMethod è Fixed e deve essere specificato in questo caso. 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 viene chiamata ogni metrica una variabile o una serie temporale.

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

  • Ogni 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 , con distinzione tra maiuscole e valueminuscole.

  • I timestamp valori devono essere conformi a ISO 8601. value I valori 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 dovrebbe 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 usa series_1, series_2, series_3, series_4e 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 desiderato.

Struttura delle cartelle

Un errore comune nella preparazione dei dati è costituito da 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 e 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 della 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 MVAD senza errori. Cosa è possibile 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 è 1% e inferiore per una buona accuratezza.
  • In generale, il rapporto di valore mancante dei dati di training deve essere inferiore al 20%. Troppi dati mancanti possono finire con valori compilati automaticamente (in genere valori lineari o valori costanti) appresi come modelli normali. Ciò può comportare il rilevamento di punti dati reali (non mancanti) come anomalie.

Quantità di dati

  • Il modello sottostante di MVAD ha milioni di parametri. È necessario un numero minimo di punti dati per apprendere un set ottimale di parametri. La regola empirica è che è necessario fornire 5.000 o più punti dati (timestamp) per variabile per eseguire il training del modello per una buona accuratezza. In generale, maggiore è la precisione dei dati di training. Tuttavia, nei casi in cui non si è in grado di accumulare 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 di risultati di inferenza. Ad esempio, in un caso di streaming in cui ogni volta che si vuole dedurre un nuovo timestamp, il file di dati può contenere solo il punto dati iniziale slidingWindow più UN punto dati, quindi è possibile passare e creare un altro file ZIP con lo stesso numero di punti dati (slidingWindow + 1) ma spostando un passaggio sul lato "destro" e inviare per un altro processo di inferenza.

    Qualsiasi elemento al di là di questo o "prima" della finestra temporale scorrevole iniziale non influisce affatto sul risultato dell'inferenza e può causare solo il downgrade delle prestazioni. Qualsiasi elemento di seguito che può causare un NotEnoughInput errore.

Timestamp arrotondamento

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 e con le frequenze note. Ecco un semplice esempio.

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

Sono disponibili due variabili raccolte da due sensori che inviano un punto dati ogni 30 secondi. Tuttavia, i sensori non inviano punti dati a una frequenza uniforme rigorosa, ma a volte in precedenza e talvolta in un secondo momento. Poiché MVAD prende in considerazione le correlazioni tra variabili diverse, i timestamp devono essere allineati correttamente 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 essere Outer (ovvero 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 interleave e il modello MVAD non può estrarre informazioni sulle correlazioni tra di esse. Se si imposta su alignModeInner, la tabella unita è vuota perché non esiste un timestamp comune nella variabile 1 e nella 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 la nuova serie temporale 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 a chiusura dei timestamp sono ben allineati e il modello MVAD può ora estrarre informazioni di correlazione.

Limiti

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

Limitazioni generali

  • Finestra scorrevole: 28-2880 timestamp, valore predefinito: 300. Per i dati periodici, impostare la lunghezza di 2-4 cicli come finestra 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 il significato 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 modelli dai dati di training e dalle anomalie può 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 quale modello è il migliore senza un set di dati etichettato. Tuttavia, è possibile sfruttare le perdite di training e convalida per ottenere una stima approssimativa e rimuovere tali modelli non valido. Prima di tutto, dobbiamo osservare se le perdite di training convergeranno. Le perdite divergenti indicano spesso una scarsa qualità del modello. In secondo luogo, i valori di perdita possono aiutare a identificare se si verifica l'underfitting o l'overfitting. I modelli sottofitting o overfitting potrebbero non avere 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. Il valore di bassa 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, sono stati appresi dai clienti come alcuni problemi comuni durante l'uso delle API MVAD. Questa tabella consente di evitare questi problemi.

Insidia Conseguenza Spiegazione e soluzione
I timestamp nei dati di training e/o nei dati di inferenza non sono stati arrotondati per allinearli alla rispettiva frequenza di dati di ogni variabile. I timestamp dei risultati dell'inferenza non sono come previsto: troppi timestamp o troppi timestamp. Fare riferimento a Timestamp arrotondamento.
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, mantenere il tasso anormale al di sotto o al di sotto dell'1% aiuterà.
Dati di training troppo piccoli L'accuratezza del modello è compromessa. In modo empirico, il training di un modello MVAD richiede 15.000 o più punti dati (timestamp) per variabile per mantenere una buona accuratezza.
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 per eliminare i rumori casuali. Per 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, vedere Struttura delle cartelle.
Troppi dati nel file di dati di inferenza: ad esempio, comprimendo tutti i dati cronologici nel file ZIP dei dati di inferenza È possibile che non vengano visualizzati errori, ma si verificano prestazioni ridotte quando si tenta di caricare il file ZIP nel BLOB di Azure e quando si tenta di eseguire l'inferenza. Per informazioni dettagliate, vedere Quantità di dati .
Creazione di Rilevamento anomalie risorse nelle aree di Azure che non supportano ancora MVAD e che chiamano le API MVAD Si riceverà un errore di "risorsa non trovata" durante la chiamata alle API MVAD. Durante la fase di anteprima, MVAD è disponibile solo in aree limitate. Aggiungere un segnalibro Novità in Rilevamento anomalie per mantenere aggiornato le implementazioni dell'area MVAD. È anche possibile segnalare un problema di GitHub o contattare Microsoft all'indirizzo AnomalyDetector@microsoft.com per richiedere aree specifiche.

Domande frequenti

Come funziona la finestra scorrevole di MVAD?

Verranno ora usati due esempi per informazioni sul funzionamento della finestra scorrevole di MVAD. Si supponga di aver impostato slidingWindow = 1.440 e che i dati di input abbiano una granularità di un minuto.

  • Scenario di streaming: si vuole stimare se il punto dati ONE in "2021-01-02T00:00:00Z" è anomalo. Il valore 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, MVAD userà i dati da 2021-01-01T00:00:00Z a 2021-01-01T23:59:00Z (inclusi) per determinare se i dati in sono 2021-01-02T00:00:00Z anomali. Quindi sposta in avanti e usa i dati da 2021-01-01T00:01:00Z a 2021-01-02T00:00:00Z (inclusi) per determinare se i dati in sono 2021-01-02T00:01:00Z anomali. Si sposta nello stesso modo (prendendo 1.440 punti dati da confrontare) fino all'ultimo timestamp specificato da endTime (o il timestamp effettivo). Pertanto, l'origine dati di inferenza deve contenere dati a partire da startTime - slidingWindow e idealmente contiene in 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 l'azienda. A seconda dello scenario e del modello di dati, le anomalie che sono meno importanti spesso hanno valori relativamente inferiori o valori elevati severity autonomi (discontinui) severity come picchi casuali.

Nei casi in cui si è trovata una necessità di regole più sofisticate rispetto alle soglie severity rispetto o alla durata dei valori elevati severity continui, è consigliabile usare score per creare filtri più potenti. Informazioni sull'uso score di MVAD per determinare le anomalie possono risultare utili:

Si valuta se un punto dati è anomalo sia dal punto di vista globale che locale. Se score in un timestamp è superiore a una determinata soglia, il timestamp viene contrassegnato come anomalia. Se score è inferiore alla soglia ma è relativamente superiore in un segmento, viene anche contrassegnato come anomalia.

Passaggi successivi