Osvědčené postupy pro používání vícevariátového rozhraní DETEKTOR ANOMÁLIÍ API

  • Článek

Důležité

Od 20. září 2023 nebudete moct vytvářet nové Detektor anomálií prostředky. Služba Detektor anomálií se 1. října 2026 vyřadí z provozu.

Tento článek obsahuje pokyny týkající se doporučených postupů při použití vícevariátových rozhraní API Detektor anomálií (MVAD). V tomto kurzu:

  • Použití rozhraní API: Naučte se používat MVAD bez chyb.
  • Příprava dat: Zjistěte, jak nejlépe vařit data, aby MVAD fungoval s vyšší přesností.
  • Běžné nástrahy: Zjistěte, jak se vyhnout běžným nástrahám, se kterými se zákazníci setkávají.
  • Nejčastější dotazy: Přečtěte si odpovědi na nejčastější dotazy.

Využití rozhraní API

Postupujte podle pokynů v této části, abyste se vyhnuli chybám při používání MVAD. Pokud se vám stále zobrazují chyby, projděte si úplný seznam kódů chyb, kde najdete vysvětlení a akce, které je potřeba provést.

Vstupní parametry

Povinné parametry

Tyto tři parametry jsou vyžadovány v požadavcích rozhraní API pro trénování a odvozování:

  • source – Odkaz na soubor ZIP umístěný ve službě Azure Blob Storage se sdílenými přístupovými podpisy (SAS).
  • startTime - Počáteční čas dat používaných pro trénování nebo odvozování. Pokud je dřívější než skutečné nejstarší časové razítko v datech, použije se jako výchozí bod skutečné nejstarší časové razítko.
  • endTime - Koncový čas dat použitých pro trénování nebo odvozování, který musí být pozdější nebo roven startTime. Pokud endTime je pozdější než skutečné nejnovější časové razítko v datech, použije se jako koncový bod skutečné poslední časové razítko. Pokud endTime se rovná startTime, znamená odvozování jednoho jednoho datového bodu, který se často používá ve scénářích streamování.

Volitelné parametry pro trénovací rozhraní API

Další parametry pro trénovací rozhraní API jsou volitelné:

  • slidingWindow – Kolik datových bodů se používá k určení anomálií. Celé číslo mezi 28 a 2 880. Výchozí hodnota je 300. Pokud slidingWindow se jedná k o trénování modelu, měly by být alespoň k body přístupné ze zdrojového souboru během odvozování, aby se získaly platné výsledky.

    MVAD přebírá segment datových bodů, aby se rozhodl, jestli je dalším datovým bodem anomálie. Délka segmentu je slidingWindow. Při výběru slidingWindow hodnoty mějte na paměti dvě věci:

    1. Vlastnosti vašich dat: jestli jsou pravidelné a vzorkovací frekvence. Pokud jsou data periodická, můžete nastavit délku 1 až 3 cyklů jako slidingWindow. Pokud jsou vaše data ve vysoké frekvenci (malá členitost), jako je minutová nebo druhá úroveň, můžete nastavit relativně vyšší hodnotu slidingWindow.
    2. Kompromis mezi dobou trénování/odvozováním a potenciálním dopadem na výkon slidingWindow Větší může způsobit delší dobu trénování nebo odvozování. Neexistuje žádná záruka, že větší slidingWindows povede k nárůstu přesnosti. slidingWindow Malé může způsobit, že se model obtížně konverguje k optimálnímu řešení. Například je obtížné detekovat anomálie, pokud slidingWindow má pouze dva body.

  • alignMode - Jak zarovnat více proměnných (časové řady) na časových razítkech. Pro tento parametr Inner existují dvě možnosti a Outervýchozí hodnota je Outer.

    Tento parametr je kritický, pokud dojde k nesprávnému zarovnání mezi posloupnostmi časových razítek proměnných. Před dalším zpracováním musí model zarovnat proměnné do stejné sekvence časového razítka.

    Inner znamená, že model bude hlásit výsledky detekce pouze u časových razítek, na kterých má každá proměnná hodnotu, tj. průsečík všech proměnných. Outer znamená, že model bude hlásit výsledky detekce podle časových razítek, u kterých má každá proměnná hodnotu, tj. sjednocení všech proměnných.

    Tady je příklad vysvětlení různých alignModel hodnot.

    Proměnná-1

    časové razítko hodnota
    2020-11-01 0
    2020-11-02 2
    2020-11-04 4
    2020-11-05 5

    Proměnná-2

    časové razítko hodnota
    2020-11-01 0
    2020-11-02 2
    2020-11-03 3
    2020-11-04 4

    Inner spojení dvou proměnných

    časové razítko Proměnná-1 Proměnná-2
    2020-11-01 1 1
    2020-11-02 2 2
    2020-11-04 4 4

    Outer spojení dvou proměnných

    časové razítko Proměnná-1 Proměnná-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 - Jak vyplnit nan sloučenou tabulku. Ve sloučené tabulce můžou chybět hodnoty a měly by se správně zpracovat. Nabízíme několik metod, jak je vyplnit. Možnosti jsou Linear, , PreviousSubsequentZero, a Fixed a výchozí hodnota je Linear.

    Možnost metoda
    Linear Vyplnění nan hodnot lineární interpolací
    Previous Rozšíří poslední platnou hodnotu pro vyplnění mezer. Příklad: [1, 2, nan, 3, nan, 4] ->[1, 2, 2, 3, 3, 4]
    Subsequent K vyplnění mezer použijte další platnou hodnotu. Příklad: [1, 2, nan, 3, nan, 4] ->[1, 2, 3, 3, 4, 4]
    Zero Vyplňte nan hodnoty 0.
    Fixed Vyplňte nan hodnoty zadanou platnou hodnotou, která by měla být zadána v paddingValue.

  • paddingValue - Hodnota odsazení se používá k vyplnění nan , pokud fillNAMethod je Fixed , a musí být v takovém případě k dispozici. V jiných případech je nepovinný.

  • displayName – Jedná se o volitelný parametr, který slouží k identifikaci modelů. Můžete ho například použít k označení parametrů, zdrojů dat a všech dalších meta dat o modelu a jeho vstupních datech. Výchozí hodnota je prázdný řetězec.

Schéma vstupních dat

MVAD detekuje anomálie ze skupiny metrik a každou metriku nazýváme proměnnou nebo časovou řadu.

  • Ukázkový datový soubor si můžete stáhnout z Microsoftu a zkontrolovat přijaté schéma z: https://aka.ms/AnomalyDetector/MVADSampleData

  • Každá proměnná musí mít dvě a pouze dvě pole timestamp a valueměla by být uložena v souboru hodnot oddělených čárkami (CSV).

  • Názvy sloupců souboru CSV by měly být přesné timestamp a valuerozlišovat velká a malá písmena.

  • Hodnoty timestamp by měly odpovídat normě ISO 8601. value Můžou to být celá čísla nebo desetinná místa s libovolným počtem desetinných míst. Dobrým příkladem obsahu souboru CSV:

    časové razítko hodnota
    2019-04-01T00:00:00Z 5
    2019-04-01T00:01:00Z 3,6
    2019-04-01T00:02:00Z 4
    ... ...

    Poznámka:

    Pokud vaše časová razítka mají hodiny, minuty nebo sekundy, ujistěte se, že se před voláním rozhraní API správně zaokrouhlují nahoru.

    Pokud například vaše frekvence dat má být jeden datový bod každých 30 sekund, ale dochází k časovým razítkům jako 12:00:01 a 12:00:28, je to silný signál, že byste měli časové razítka předzpracovat na nové hodnoty, například 12:00:00 a 12:00:30.

    Podrobnosti najdete v části Časové razítko zaokrouhlení v dokumentu s osvědčenými postupy.

  • Název souboru CSV se použije jako název proměnné a měl by být jedinečný. Například "temperature.csv" a "humidity.csv".

  • Proměnné pro trénování a proměnné pro odvozování by měly být konzistentní. Pokud například používáte series_1, , series_2, series_3series_4, a series_5 pro trénování, měli byste poskytnout přesně stejné proměnné pro odvozování.

  • Soubory CSV by se měly komprimovat do souboru ZIP a nahrát je do kontejneru objektů blob Azure. Soubor ZIP může mít jakýkoli název, který chcete.

Struktura složek

Běžnou chybou při přípravě dat jsou složky v souboru ZIP. Předpokládejme například, že název souboru ZIP je series.zip. Po dekompresi souborů do nové složky ./seriesje ./series/series_1.csvsprávná cesta k souborům CSV a nesprávnácesta může být ./series/foo/bar/series_1.csv.

Správný příklad stromu adresáře po dekompresi souboru ZIP ve Windows

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

Nesprávný příklad stromu adresáře po dekompresi souboru ZIP ve Windows

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

Příprava dat

Teď můžete spustit kód pomocí rozhraní API MVAD bez jakékoli chyby. Co se dá udělat, aby se zlepšila přesnost modelu?

Kvalita dat

  • S tím, jak model učí normální vzory z historických dat, by trénovací data měla představovat celkový normální stav systému. Model se obtížně učí tyto typy vzorů, pokud jsou trénovací data plná anomálií. Empirická prahová hodnota neobvyklé rychlosti je 1 % a nižší pro dobrou přesnost.
  • Obecně platí, že chybějící poměr hodnot trénovacích dat by měl být menší než 20 %. Příliš mnoho chybějících dat může skončit s automaticky vyplněnými hodnotami (obvykle lineárními nebo konstantními hodnotami), které se učí jako normální vzory. Výsledkem může být zjištění skutečných (chybějících) datových bodů jako anomálií.

Množství dat

  • Základní model MVAD má miliony parametrů. K získání optimální sady parametrů potřebuje minimální počet datových bodů. Empirické pravidlo je, že pro vytrénování modelu potřebujete zadat 5 000 nebo více datových bodů (časových razítek) na proměnnou , abyste model vytrénoval pro zajištění dobré přesnosti. Obecně platí, že čím více trénovacích dat, tím vyšší je přesnost. V případech, kdy ale nemůžete nabíhání tolik dat, stále doporučujeme experimentovat s méně daty a zjistit, jestli je ohrožená přesnost stále přijatelná.

  • Při každém volání rozhraní API pro odvozování je potřeba zajistit, aby zdrojový datový soubor obsahoval pouze dostatek datových bodů. To je obvykle slidingWindow + počet datových bodů, které skutečně potřebují odvozování výsledků. Například v případě streamování, kdy pokaždé, když chcete odvodit jedno nové časové razítko, může datový soubor obsahovat pouze úvodní slidingWindow plus JEDEN datový bod; pak můžete přejít a vytvořit další soubor ZIP se stejným počtem datových bodů (slidingWindow + 1), ale přesunout jeden krok na "pravou" stranu a odeslat pro jinou úlohu odvozování.

    Cokoli nad rámec tohoto nebo "před" úvodního posuvného okna nebude mít vůbec vliv na výsledek odvozování a může způsobit pouze downgrade výkonu. Cokoli pod tím, co může vést k NotEnoughInput chybě.

Časové razítko zaokrouhlit nahoru

Ve skupině proměnných (časové řady) se každá proměnná může shromažďovat z nezávislého zdroje. Časové razítka různých proměnných mohou být vzájemně nekonzistentní a se známými frekvencemi. Tady je jednoduchý příklad.

Proměnná-1

časové razítko hodnota
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

Proměnná-2

časové razítko hodnota
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

Máme dvě proměnné shromážděné ze dvou senzorů, které odesílají jeden datový bod každých 30 sekund. Senzory ale neodesílají datové body striktně i často, ale někdy dříve a někdy později. Vzhledem k tomu, že MVAD bere v úvahu korelace mezi různými proměnnými, musí být časové razítko správně zarovnané, aby metriky mohly správně odrážet stav systému. Ve výše uvedeném příkladu musí být časová razítka proměnné 1 a proměnné 2 před zarovnáním správně zaokrouhlená na jejich frekvenci.

Pojďme se podívat, co se stane, když nejsou předem zpracovány. Pokud nastavíme alignModeOuter hodnotu (což znamená sjednocení dvou množin), sloučená tabulka je:

časové razítko Proměnná-1 Proměnná-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 označuje chybějící hodnoty. Sloučená tabulka samozřejmě není to, co byste očekávali. Proměnná 1 a proměnná 2 prokládání a model MVAD nemůže extrahovat informace o korelacích mezi nimi. Pokud nastavíme alignModeInnerhodnotu , sloučená tabulka je prázdná, protože neexistuje žádné běžné časové razítko v proměnné 1 a proměnné 2.

Časové razítka proměnné 1 a proměnné 2 by proto měla být předzpracovaná (zaokrouhlená na nejbližší 30sekundové časové razítko) a nová časová řada:

Proměnná-1

časové razítko hodnota
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

Proměnná-2

časové razítko hodnota
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

Sloučená tabulka je teď vhodnější.

časové razítko Proměnná-1 Proměnná-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

Hodnoty různých proměnných v časových razítkech jsou dobře zarovnané a model MVAD teď dokáže extrahovat informace o korelaci.

Omezení

V rozhraních API pro trénování i odvozování platí určitá omezení, abyste se vyhnuli chybám.

Obecná omezení

  • Posuvné okno: 28-2880 časových razítek, výchozí hodnota je 300. U pravidelných dat nastavte délku 2-4 cyklů jako posuvné okno.
  • Čísla proměnných: Pro trénování a dávkové odvozování maximálně 301 proměnných.

Omezení trénování

  • Časové razítka: Maximálně 1 000000. Příliš málo časových razítek může snížit kvalitu modelu. Doporučujeme mít více než 5 000 časových razítek.
  • Členitost: Minimální členitost je per_second.

Omezení odvození služby Batch

  • Časová razítka: Maximálně 20000, alespoň 1 posuvná délka okna.

Omezení odvození streamování

  • Časová razítka: Maximálně 2880, minimálně 1 posuvná délka okna.
  • Zjišťování časových razítek: Od 1 do 10.

Kvalita modelu

Jak řešit falešně pozitivní a falešně negativní v reálných scénářích?

Poskytli jsme závažnost, která označuje význam anomálií. Falešně pozitivní výsledky mohou být vyfiltrovány nastavením prahové hodnoty závažnosti. Někdy se může objevit příliš mnoho falešně pozitivních výsledků, když se v datech odvozování mění vzor. V takových případech může být potřeba model znovu natrénovat na nová data. Pokud trénovací data obsahují příliš mnoho anomálií, ve výsledcích detekce může dojít k falešně negativním výsledkům. Důvodem je to, že model učí vzory z trénovacích dat a anomálií může do modelu přinést předsudky. Správné čištění dat tak může pomoct snížit falešně negativní hodnoty.

Jak odhadnout, který model je nejvhodnější použít v závislosti na ztrátě trénování a ztrátě ověření?

Obecně řečeno, je těžké rozhodnout, který model je nejlepší bez označené datové sady. Ztráty trénování a ověřování ale můžeme využít k hrubému odhadu a zahození těchto špatných modelů. Nejprve musíme sledovat, jestli se trénovací ztráty konvergují. Rozdílové ztráty často značí špatnou kvalitu modelu. Za druhé, hodnoty ztráty můžou pomoct určit, jestli dojde k nedoučení nebo přeurčení. Modely nedoučení nebo přeurčení nemusí mít požadovaný výkon. Za třetí, i když definice funkce ztráty přímo neodráží výkon detekce, mohou být hodnoty ztráty pomocným nástrojem pro odhad kvality modelu. Nízká hodnota ztráty je nezbytnou podmínkou pro dobrý model, takže můžeme zahodit modely s vysokými hodnotami ztráty.

Běžné nástrahy

Kromě tabulky s kódem chyby jsme se naučili od zákazníků, jako jsou některé běžné nástrahy při používání rozhraní API MVAD. Tato tabulka vám pomůže vyhnout se těmto problémům.

Úskalí Důsledkem Vysvětlení a řešení
Časová razítka v trénovacích datech nebo datech odvozování nebyla zaokrouhlená nahoru, aby odpovídala příslušné frekvenci dat každé proměnné. Časové razítka výsledků odvozování nejsou podle očekávání: buď příliš málo časových razítek, nebo příliš mnoho časových razítek. Projděte si časové razítko zaokrouhlení.
Příliš mnoho neobvyklých datových bodů v trénovacích datech Přesnost modelu je ovlivněna negativně, protože během trénování zpracovává neobvyklé datové body jako normální vzory. Empiricky, udržet neobvyklou míru s nebo nižší než 1% pomůže.
Příliš málo trénovacích dat Přesnost modelu je ohrožena. Empirické trénování modelu MVAD vyžaduje 15 000 nebo více datových bodů (časových razítek) na proměnnou, aby byla zachována dobrá přesnost.
Převzetí všech datových bodů isAnomaly=true jako anomálií Příliš mnoho falešně pozitivních výsledků K vyhození anomálií, které nejsou závažné, a (volitelně) byste měli použít isAnomalyseverityscoreseskupení, abyste zkontrolovali dobu trvání anomálií, aby se potlačit náhodné šumy. Rozdíl mezi severity a score.
Podsložky se zazipují do datového souboru pro trénování nebo odvozování. Datové soubory CSV uvnitř podsložek se během trénování a/nebo odvozování ignorují. V souboru ZIP nejsou povoleny žádné podsložky. Podrobnosti najdete ve struktuře složek.
Příliš mnoho dat v datovém souboru odvozování: například komprimace všech historických dat v souboru ZIP pro odvozování dat Nemusí se zobrazit žádné chyby, ale při pokusu o nahrání souboru ZIP do objektu blob Azure a při pokusu o spuštění odvození dojde ke snížení výkonu. Podrobnosti najdete v množství dat .
Vytváření Detektor anomálií prostředků v oblastech Azure, které zatím nepodporují MVAD a volají rozhraní API MVAD Při volání rozhraní API MVAD se zobrazí chyba "prostředek nebyl nalezen". Během fáze Preview je MVAD k dispozici pouze v omezených oblastech. Přidejte si prosím záložku Co je nového v Detektor anomálií, abyste měli přehled o zavádění oblastí MVAD. Můžete také podat problém Na GitHubu nebo nás AnomalyDetector@microsoft.com kontaktovat a požádat o konkrétní oblasti.

Často kladené dotazy

Jak funguje posuvné okno MVAD?

Pojďme se pomocí dvou příkladů naučit, jak funguje posuvné okno MVAD. Předpokládejme, že jste nastavili slidingWindow hodnotu = 1 440 a vstupní data jsou v minutové členitosti.

  • Scénář streamování: Chcete předpovědět, jestli je datový bod ONE v "2021-01-01-02T00:00:00Z" neobvyklý. Vaše startTime a endTime bude stejná hodnota ("2021-01-02T00:00:00Z"). Zdroj dat odvozování ale musí obsahovat alespoň 1 440 + 1 časové razítko. Vzhledem k tomu, že MVAD vezme úvodní data před cílovým datovým bodem ("2021-01-01-02T00:00:00Z") a rozhodne, zda je cílem anomálie. V tomto případě je slidingWindow délka potřebných úvodních dat nebo 1 440. 1,440 = 60 * 24, takže vstupní data musí začínat nejpozději "2021-01-01T00:00:00Z".

  • Scénář dávky: K predikci máte více cílových datových bodů. Vaše endTime bude větší než vaše startTime. Odvozování v takových scénářích se provádí "pohyblivým oknem". MVAD například použije data z 2021-01-01T00:00:00Z do 2021-01-01T23:59:00Z (včetně) k určení, jestli jsou data 2021-01-02T00:00:00Z neobvyklá. Pak se posune dál a pomocí dat od 2021-01-01T00:01:00Z2021-01-02T00:00:00Z (včetně) určí, jestli jsou data 2021-01-02T00:01:00Z neobvyklá. Posune se stejným způsobem (1 440 datových bodů k porovnání) až do posledního časového razítka určeného endTime (nebo skutečného posledního časového razítka). Proto musí zdroj dat odvozování obsahovat data začínající startTime - slidingWindow a ideálně obsahuje celkovou velikost slidingWindow + ().endTime - startTime

Jaký je rozdíl mezi severity a score?

Za normálních okolností doporučujeme použít severity jako filtr, abyste vypusli "anomálie", které nejsou pro vaši firmu tak důležité. V závislosti na vašem scénáři a vzoru dat mají tyto anomálie méně důležité často relativně nižší severity hodnoty nebo samostatné (nesouvislé) vysoké severity hodnoty, jako jsou náhodné špičky.

V případech, kdy jste zjistili, že potřebujete sofistikovanější pravidla než prahové severity hodnoty nebo dobu trvání souvislých vysokých severity hodnot, můžete použít score k vytváření výkonnějších filtrů. Vysvětlení, jak MVAD používá score k určení anomálií, může pomoct:

Zvažujeme, jestli je datový bod neobvyklý z globálního i místního hlediska. Pokud score je časové razítko vyšší než určitá prahová hodnota, časové razítko se označí jako anomálie. Pokud score je nižší než prahová hodnota, ale je relativně vyšší v segmentu, označí se také jako anomálie.

Další kroky