Sdílet prostřednictvím


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

Důležité

Od 20. září 2023 nebudete moct vytvářet nové zdroje detektoru anomálií. 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 slouží k pro trénování modelu, měly by být během odvozování alespoň k body dostupné ze zdrojového souboru, aby se získaly platné výsledky.

    MVAD používá segment datových bodů, aby určil, 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 Větší slidingWindow může způsobit delší dobu trénování nebo inferenční doby. Neexistuje žádná záruka, že větší slidingWindows povede k nárůstu přesnosti. Malá slidingWindow může způsobit, že 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 existují dvě možnosti, Inner a Outer, a vý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
    1. 11. 2020 1
    2020-11-02 2
    2020-11-04 4
    2020-11-05 5

    Proměnná-2

    časové razítko hodnota
    1. 11. 2020 1
    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
    1. 11. 2020 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
    1. 11. 2020 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 Vyplňte nan hodnoty lineární interpolací
    Previous Doplní poslední platnou hodnotu k 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 nulami.
    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 v případě, že fillNAMethod je Fixed. V takovém případě musí být 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 value, přičemž se rozlišují 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 Souhrn časových razítek 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 přebytečné 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 ./series, je správná cesta k souborům CSV ./series/series_1.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 nashromáždit tolik dat, stále doporučujeme experimentovat s méně daty a zjistit, jestli je kompromitovaná 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 provést inferenci na nové časové razítko, může datový soubor obsahovat pouze úvodní slidingWindow plus JEDEN datový bod; následně můžete vytvořit další soubor ZIP se stejným počtem datových bodů (slidingWindow + 1), ale přesunout se o jeden krok dále doprava a odeslat pro další úlohu inferenčního zpracování.

    Cokoli nad rámec tohoto nebo "před" hlavního posuvného okna nebude mít vůbec vliv na výsledek inferencí a může způsobit pouze snížení výkonu. Jakákoli hodnota pod touto úrovní může vést k NotEnoughInput chybě.

Rejstřík časových razítek

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 neslučitelná s ostatními 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 neodesílají datové body ve striktně pravidelných intervalech, 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 se prolínají a model MVAD nedokáže získat informace o vztazích mezi nimi. Pokud nastavíme alignMode na Inner, sloučená tabulka je prázdná, protože neexistuje žádné společ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 blízkých časových razítkách 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, pokud je to možné, mít více než 5 000 časových značek.
  • Členitost: Minimální členitost je per_second.

Omezení dávkového odvozování

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

Omezení odvození streamování

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

Kvalita modelu

Jak řešit falešné pozitivy a falešné negativity 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 se učí vzory z výcvikových dat a anomálie může model zkreslit. 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 ztráty při tréninku sbíhají. Rozpory ve ztrátách často označují špatnou kvalitu modelu. Za druhé, hodnoty ztráty můžou pomoct určit, jestli dojde k nedostatečnému přizpůsobení nebo přepřizpůsobení. Modely, které trpí podfitováním nebo overfitováním, 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ódy chyb jsme se od zákazníků, jako jste vy, naučili 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.

Skryté nebezpečí Důsledek 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ů inferencí nejsou podle očekávání: buď jich je příliš málo, nebo naopak příliš mnoho. Podívejte se na souhrn časových razítek.
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 míru abnormality na nebo pod 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.
Označení všech datových bodů isAnomaly=true jako anomálií Příliš mnoho falešně pozitivních výsledků K vyfiltrování anomálií, které nejsou závažné, byste měli použít jak isAnomaly, tak severity (nebo score), a (volitelně) využít seskupení ke kontrole doby trvání anomálií, aby se potlačily náhodné šumy. Podívejte se do sekce Často kladené dotazy níže na 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 části Množství dat.
Vytváření prostředků detektoru anomálií v oblastech Azure, které zatím nepodporují MVAD, a volání 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 hodnotu slidingWindow = 1 440, a že vaše vstupní data jsou v minutové členitosti.

  • Scénář streamování: Chcete předpovědět, jestli je hodnota JEDEN v "2021-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. Protože MVAD vezme předchozí data před cílovým datovým bodem ("2021-01-02T00:00:00Z") k rozhodnutí, zda je cílový bod anomálií. Potřebná délka úvodních dat je v tomto případě slidingWindow 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. Inferenční proces v takových scénářích se provádí metodou "pohyblivého okna". 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ě by měl obsahovat 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í méně důležité anomálie často relativně nižší severity hodnoty nebo samostatné (nesouvislé) vysoké severity hodnoty, podobně jako 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