Metodtips för att använda Avvikelseidentifiering multivariat-API

Den här artikeln ger vägledning om rekommenderade metoder att följa när du använder MVAD-API:er (multivariate Avvikelseidentifiering). I den här självstudien kommer du att:

  • API-användning: Lär dig hur du använder MVAD utan fel.
  • Datateknik: Lär dig hur du bäst lagar dina data så att MVAD presterar med bättre noggrannhet.
  • Vanliga fallgropar: Lär dig hur du undviker vanliga fallgropar som kunder möter.
  • Vanliga frågor och svar: Läs mer om vanliga frågor och svar.

API-användning

Följ anvisningarna i det här avsnittet för att undvika fel när du använder MVAD. Om du fortfarande får fel kan du se den fullständiga listan med felkoder för förklaringar och åtgärder som du kan vidta.

Indataparametrar

Obligatoriska parametrar

Dessa tre parametrar krävs i API-begäranden för träning och slutsatsledning:

  • source– Länken till zip-filen som finns i Azure Blob Storage signatur för delad åtkomst (SAS).
  • startTime – Starttiden för data som används för träning eller slutsatsledning. Om den är tidigare än den faktiska tidigaste tidsstämpeln i data används den faktiska tidigaste tidsstämpeln som startpunkt.
  • endTime - Sluttiden för data som används för träning eller slutsatsledning som måste vara senare än eller lika med startTime . Om är senare än den faktiska senaste tidsstämpeln i data används den faktiska senaste tidsstämpeln endTime som slutpunkt. Om endTime är lika med innebär det startTime härledning av en enskild datapunkt som ofta används i strömningsscenarier.

Valfria parametrar för tränings-API

Andra parametrar för tränings-API är valfria:

  • slidingWindow – Hur många datapunkter som används för att fastställa avvikelser. Ett heltal mellan 28 och 2 880. Standardvärdet är 300. Om är för modellträning bör minst punkter vara tillgängliga från källfilen slidingWindow k under k inferensen för att få giltiga resultat.

    MVAD tar ett segment med datapunkter för att avgöra om nästa datapunkt är en avvikelse. Längden på segmentet är slidingWindow . Tänk på två saker när du väljer ett slidingWindow värde:

    1. Egenskaperna för dina data: om de är periodiska och samplingsfrekvensen. När dina data är periodiska kan du ange längden på 1–3 cykler som slidingWindow . När dina data har hög frekvens (liten kornighet) som på minutnivå eller sekundnivå kan du ange ett relativt högre värde för slidingWindow .
    2. Avvägningen mellan träning/slutsatsledningstid och potentiell prestandapåverkan. En större slidingWindow kan orsaka längre tränings-/inferenstid. Det finns ingen garanti för att större S leder till slidingWindow noggrannhetsförbättringar. En liten slidingWindow kan göra att modellen är svår att konvergera till en optimal lösning. Det är till exempel svårt att identifiera avvikelser när bara slidingWindow har två punkter.
  • alignMode – Justera flera variabler (tidsserier) efter tidsstämplar. Det finns två alternativ för den här Inner Outer parametern, och , och standardvärdet är Outer .

    Den här parametern är kritisk när det finns feljustering mellan variablernas tidsstämpelsekvenser. Modellen måste justera variablerna till samma tidsstämpelsekvens innan ytterligare bearbetning.

    Innerinnebär att modellen endast rapporterar identifieringsresultat för tidsstämplar där varje variabel har ett värde, dvs. skärningspunkten för alla variabler. Outerinnebär att modellen rapporterar identifieringsresultat för tidsstämplar där alla variabler har ett värde, dvs. union av alla variabler.

    Här är ett exempel som förklarar olika alignModel värden.

    Variabel-1

    timestamp värde
    2020-11-01 1
    2020-11-02 2
    2020-11-04 4
    2020-11-05 5

    Variabel-2

    timestamp värde
    2020-11-01 1
    2020-11-02 2
    2020-11-03 3
    2020-11-04 4

    Inner koppla ihop två variabler

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

    Outer koppla ihop två variabler

    timestamp Variabel-1 Variabel-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 – Så här fyller du nan i den sammanslagna tabellen. Det kan saknas värden i den sammanslagna tabellen och de bör hanteras korrekt. Vi tillhandahåller flera metoder för att fylla dem. Alternativen är Linear , , , och och Previous Subsequent Zero Fixed standardvärdet är Linear .

    Alternativ Metod
    Linear Fyll nan i värden efter linjär interpolering
    Previous Sprid det sista giltiga värdet för att fylla i luckor. Exempel: [1, 2, nan, 3, nan, 4] -> [1, 2, 2, 3, 3, 4]
    Subsequent Använd nästa giltiga värde för att fylla i luckor. Exempel: [1, 2, nan, 3, nan, 4] -> [1, 2, 3, 3, 4, 4]
    Zero Fyll nan i värden med 0.
    Fixed Fyll nan i värden med ett angivet giltigt värde som ska anges i paddingValue .
  • paddingValue – Utfyllnadsvärdet används för att fylla nan i när är och måste anges i det fillNAMethod Fixed fallet. I andra fall är det valfritt.

  • displayName – Det här är en valfri parameter som används för att identifiera modeller. Du kan till exempel använda den för att markera parametrar, datakällor och andra metadata om modellen och dess indata. Standardvärdet är en tom sträng.

Schema för indata

MVAD identifierar avvikelser från en grupp mått och vi kallar varje mått för en variabel eller en tidsserie.

  • Du kan ladda ned exempeldatafilen från Microsoft för att kontrollera det godkända schemat från: https://aka.ms/AnomalyDetector/MVADSampleData

  • Varje variabel måste ha två och endast två fält, och , och ska lagras i en fil med timestamp value kommaavgränsade värden (CSV).

  • Kolumnnamnen för CSV-filen ska vara exakt och timestamp value , fallkänsliga.

  • Värdena timestamp ska överensstämma med ISO 8601. Kan vara heltal eller value decimaler med val annat antal decimaler. Ett bra exempel på innehållet i en CSV-fil:

    timestamp värde
    2019-04-01T00:00:00Z 5
    2019-04-01T00:01:00Z 3,6
    2019-04-01T00:02:00Z 4
    ... ...

    Anteckning

    Om dina tidsstämplar har timmar, minuter och/eller sekunder ser du till att de avrundas korrekt uppåt innan du anropar API:erna.

    Om din datafrekvens till exempel ska vara en datapunkt var 30:e sekund, men du ser tidsstämplar som "12:00:01" och "12:00:28", är det en stark signal att du ska bearbeta tidsstämplar till nya värden som "12:00:00" och "12:00:30".

    Mer information finns i avsnittet "Avrundning av tidsstämpel" i dokumentet om bästa praxis.

  • Namnet på csv-filen används som variabelnamn och ska vara unikt. Till exempel "temperature.csv" och "humidity.csv".

  • Variabler för träning och variabler för slutsatsledning ska vara konsekventa. Om du till exempel använder , , , och för träning bör du series_1 ange exakt samma variabler för series_2 series_3 series_4 series_5 slutsatsledning.

  • CSV-filer ska komprimeras till en zip-fil och laddas upp till en Azure-blobcontainer. Zip-filen kan ha vilket namn du vill.

Mappstrukturen

Ett vanligt misstag vid förberedelse av data är extra mappar i ZIP-filen. Anta till exempel att namnet på zip-filen är series.zip . Efter dekomprimering av filerna till en ny mapp är sedan rätt sökväg till CSV-filer och ./series fel sökväg kan vara ./series/series_1.csv ./series/foo/bar/series_1.csv .

Rätt exempel på katalogträdet efter dekomprimering av zip-filen i Windows

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

Ett felaktigt exempel på katalogträdet efter dekomprimering av zip-filen i Windows

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

Datateknik

Nu kan du köra koden med MVAD-API:er utan fel. Vad kan du göra för att förbättra modellens noggrannhet?

Datakvalitet

  • När modellen lär sig normala mönster från historiska data bör träningsdata representera systemets övergripande normala tillstånd. Det är svårt för modellen att lära sig dessa typer av mönster om träningsdata är fulla av avvikelser. Ett empiriskt tröskelvärde för onormal frekvens är 1 % och lägre för god noggrannhet.
  • I allmänhet bör förhållandet mellan saknade värden för träningsdata vara under 20 %. För mycket data som saknas kan leda till att automatiskt ifyllda värden (vanligtvis linjära värden eller konstanta värden) lärs in som normala mönster. Det kan leda till att verkliga (inte saknade) datapunkter identifieras som avvikelser. Det finns dock fall där ett högt saknat förhållande är acceptabelt. Om du till exempel har två variabler (tidsserier) i en grupp med hjälp Outer av läget för att justera deras tidsstämplar. En av dem har en minuts kornighet, den andra har timgranularitet. Därefter har timvariabeln per natur minst 59/60 = 98,33 % datapunkter som saknas. I sådana fall går det bra att fylla i variabeln varje timme med det enda tillgängliga värdet (saknas inte) om det normalt inte varierar för mycket.

Datakvantitet

  • Den underliggande MVAD-modellen har miljontals parametrar. Den behöver ett minsta antal datapunkter för att lära sig en optimal uppsättning parametrar. Den empiriska regeln är att du måste ange 15 000 eller fler datapunkter (tidsstämplar) per variabel för att träna modellen för bra noggrannhet. I allmänhet, ju mer träningsdata, desto bättre noggrannhet. Men om du inte kan ackumulera så mycket data rekommenderar vi ändå att du experimenterar med mindre data och ser om den komprometterade noggrannheten fortfarande är acceptabel.

  • Varje gång du anropar härlednings-API:et måste du se till att källdatafilen innehåller precis tillräckligt med datapunkter. Det är slidingWindow normalt + antal datapunkter som verkligen behöver slutsats slutsatsledningsresultat. I ett strömningsfall när du till exempel vill dra slutsatser om EN ny tidsstämpel kan datafilen bara innehålla inledande plus en datapunkt. Sedan kan du gå vidare och skapa en annan zip-fil med samma antal slidingWindow datapunkter ( + slidingWindow 1) men flytta ETT steg till höger och skicka för ett annat härledningsjobb.

    Allt utöver det eller "före" inledande skjutfönstret påverkar inte inferensresultatet alls och kan bara orsaka nedgradering av prestanda. Allt nedan som kan leda till ett NotEnoughInput fel.

Avrundning av tidsstämpel

I en grupp variabler (tidsserier) kan varje variabel samlas in från en oberoende källa. Tidsstämplarna för olika variabler kan vara inkonsekventa med varandra och med kända frekvenser. Här är ett enkelt exempel.

Variabel-1

timestamp värde
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

Variabel-2

timestamp värde
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

Vi har två variabler som samlas in från två sensorer som skickar en datapunkt var 30:e sekund. Sensorerna skickar dock inte datapunkter med en strikt jämn frekvens, men ibland tidigare och ibland senare. Eftersom MVAD tar hänsyn till korrelationer mellan olika variabler måste tidsstämplar justeras korrekt så att måtten korrekt kan återspegla systemets villkor. I exemplet ovan måste tidsstämplar för variabel 1 och variabel 2 vara korrekt avrundade till frekvensen före justeringen.

Nu ska vi se vad som händer om de inte bearbetas i förväg. Om vi anger alignMode till Outer (vilket innebär union av två uppsättningar) blir den sammanslagna tabellen

timestamp Variabel-1 Variabel-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 anger saknade värden. Den sammanslagna tabellen är naturligtvis inte det du förväntade dig. Variabel 1 och variabel 2 över flera, och MVAD-modellen kan inte extrahera information om korrelationer mellan dem. Om vi anger till är den sammanslagna tabellen tom eftersom det inte alignMode Inner finns någon gemensam tidsstämpel i variabel 1 och variabel 2.

Därför bör tidsstämplarna för variabel 1 och variabel 2 förbearbetas (avrundas till närmaste 30 sekunders tidsstämplar) och de nya tidsserierna är

Variabel-1

timestamp värde
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

Variabel-2

timestamp värde
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

Nu är den sammanslagna tabellen mer rimlig.

timestamp Variabel-1 Variabel-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

Värdena för olika variabler vid nära tidsstämplar är väl justerade och MVAD-modellen kan nu extrahera korrelationsinformation.

Vanliga fallgropar

Förutom felkodtabellen harvi lärt oss från kunder som du några vanliga fallgropar när du använder MVAD-API:er. Den här tabellen hjälper dig att undvika dessa problem.

Fallgrop Följd Förklaring och lösning
Tidsstämplar i träningsdata och/eller härledningsdata avrundades inte uppåt för att justera med respektive datafrekvens för varje variabel. Inferensresultatets tidsstämplar är inte som förväntat: antingen för få tidsstämplar eller för många tidsstämplar. Se Tidsstämpel avrundning.
För många avvikande datapunkter i träningsdata Modellens noggrannhet påverkas negativt eftersom den behandlar avvikande datapunkter som normala mönster under träningen. Empiriskt hjälper det att hålla den onormala frekvensen på eller under 1 %.
För lite träningsdata Modellens noggrannhet komprometteras. Empiriskt kräver träning av en MVAD-modell 15 000 eller fler datapunkter (tidsstämplar) per variabel för att hålla en bra noggrannhet.
Ta alla datapunkter isAnomaly = true med som avvikelser För många falska positiva resultat Du bör använda både och (eller ) för att gå igenom avvikelser som inte är allvarliga och (valfritt) använda gruppering för att kontrollera varaktigheten för avvikelserna för att förhindra isAnomaly severity score slumpmässiga brus. Se avsnittet med vanliga frågor och svar nedan för att se skillnaden mellan severity och score .
Undermappar zippade i datafilen för träning eller slutsatsledning. CSV-datafilerna i undermapparna ignoreras under träningen och/eller härledning. Inga undermappar tillåts i zip-filen. Mer information finns i Mappstruktur.
För mycket data i inferensdatafilen: till exempel komprimera alla historiska data i zip-filen med inferensdata Du kanske inte ser några fel, men du får försämrade prestanda när du försöker ladda upp zip-filen till Azure Blob samt när du försöker köra slutsatsledning. Mer information finns i Datakvantitet.
Skapa Avvikelseidentifiering i Azure-regioner som ännu inte stöder MVAD och anropa MVAD-API:er Du får felet "resursen hittades inte" när du anropar MVAD-API:erna. Under förhandsversionsfasen är MVAD endast tillgängligt i begränsade regioner. Bokmärket What's new in (Vad är nytt i Avvikelseidentifiering att hålla dig uppdaterad med MVAD-region-utrullningar. Du kan också skicka ett GitHub eller kontakta oss på för AnomalyDetector@microsoft.com att begära specifika regioner.

Vanliga frågor

Hur fungerar MVAD-skjutfönster?

Vi använder två exempel för att lära oss hur MVAD:s skjutfönster fungerar. Anta att du har slidingWindow angett = 1 440 och att dina indata har en kornighet på en minut.

  • Strömningsscenario: Du vill förutsäga om ONE-datapunkten vid "2021-01-02T00:00:00Z" är avvikande. Och startTime kommer att ha samma värde endTime ("2021-01-02T00:00:00Z"). Inferensdatakällan måste dock innehålla minst 1 440 + 1 tidsstämplar. Eftersom MVAD tar ledande data före måldatapunkten ("2021-01-02T00:00:00Z") för att avgöra om målet är en avvikelse. Längden på nödvändiga inledande data är slidingWindow eller 1 440 i det här fallet. 1 440 = 60 * 24, så dina indata måste starta från senast "2021-01-01T00:00:00Z".

  • Batch-scenario: Du har flera måldatapunkter att förutsäga. Kommer endTime att vara större än din startTime . Slutsatsledning i sådana scenarier utförs på ett "flyttande fönster". MVAD använder till exempel data från 2021-01-01T00:00:00Z till 2021-01-01T23:59:00Z (inklusive) för att avgöra om data 2021-01-02T00:00:00Z på är avvikande. Sedan går den framåt och använder data från 2021-01-01T00:01:00Z till 2021-01-02T00:00:00Z (inklusive) för att avgöra om data 2021-01-02T00:01:00Z vid är avvikande. Den går vidare på samma sätt (tar 1 440 datapunkter att jämföra) tills den senaste tidsstämpeln som anges av (eller den faktiska senaste endTime tidsstämpeln). Därför måste din härledningsdatakälla innehålla data som börjar från startTime - slidingWindow och helst innehåller totalt storlek slidingWindow + ( endTime - startTime ).

Varför bara acceptera ZIP-filer för träning och slutsatsledning?

Vi använder zip-filer eftersom vi i batchscenarier förväntar oss att storleken på både tränings- och inferensdata skulle vara mycket stor och inte kan läggas i HTTP-begärandetexten. Detta gör att användare kan utföra batch-slutsatssatsning på historiska data för modellvalidering eller dataanalys.

Detta kan dock vara något olämpligt för strömnings inferens och för data med hög frekvens. Vi har en plan för att lägga till ett nytt API som utformats särskilt för strömnings inferens som användare kan skicka data i begärandetexten.

Vad är skillnaden mellan severity och score ?

Normalt rekommenderar vi att du severity använder som filter för att gå igenom "avvikelser" som inte är så viktiga för din verksamhet. Beroende på ditt scenario och datamönster har de avvikelser som är mindre viktiga ofta relativt lägre värden eller fristående (oavvisliga) höga värden som severity severity slumpmässiga toppar.

I fall där du har hittat ett behov av mer avancerade regler än tröskelvärden mot eller varaktighet för kontinuerliga höga värden, kan du använda för att severity severity skapa mer kraftfulla score filter. Att förstå hur MVAD använder för score att fastställa avvikelser kan vara till hjälp:

Vi överväger om en datapunkt är avvikande ur både globalt och lokalt perspektiv. Om score en tidsstämpel är högre än ett visst tröskelvärde markeras tidsstämpeln som en avvikelse. Om score är lägre än tröskelvärdet men är relativt högre i ett segment markeras det också som en avvikelse.

Nästa steg