Udostępnij za pośrednictwem

Najlepsze rozwiązania dotyczące używania interfejsu API wielowariancji Narzędzie do wykrywania anomalii

  • Artykuł

Ważne

Od 20 września 2023 r. nie będzie można tworzyć nowych zasobów Narzędzie do wykrywania anomalii. Usługa Narzędzie do wykrywania anomalii jest wycofywana 1 października 2026 r.

Ten artykuł zawiera wskazówki dotyczące zalecanych rozwiązań, które należy stosować w przypadku korzystania z wielowariancji interfejsów API Narzędzie do wykrywania anomalii (MVAD). W tym samouczku wykonasz następujące elementy:

  • Użycie interfejsu API: dowiedz się, jak używać wzorca MVAD bez błędów.
  • Inżynieria danych: dowiedz się, jak najlepiej gotować dane, aby usługa MVAD działa z lepszą dokładnością.
  • Typowe pułapki: Dowiedz się, jak uniknąć typowych pułapek spotykanych przez klientów.
  • Często zadawane pytania: Poznaj odpowiedzi na często zadawane pytania.

Użycie interfejsu API

Postępuj zgodnie z instrukcjami w tej sekcji, aby uniknąć błędów podczas korzystania z usługi MVAD. Jeśli nadal występują błędy, zapoznaj się z pełną listą kodów błędów, aby uzyskać wyjaśnienia i akcje do wykonania.

Parametry wejściowe

Parametry wymagane

Te trzy parametry są wymagane w żądaniach interfejsu API trenowania i wnioskowania:

  • source — Link do pliku zip znajdującego się w usłudze Azure Blob Storage z sygnaturami dostępu współdzielonego (SAS).
  • startTime — Godzina rozpoczęcia danych używanych do trenowania lub wnioskowania. Jeśli jest wcześniejsza niż rzeczywisty najwcześniejszy znacznik czasu w danych, rzeczywisty najwcześniejszy znacznik czasu będzie używany jako punkt początkowy.
  • endTime — Czas zakończenia danych używanych do trenowania lub wnioskowania, które muszą być późniejsze niż lub równe startTime. Jeśli endTime jest późniejszy niż rzeczywisty najnowszy znacznik czasu w danych, rzeczywisty najnowszy znacznik czasu będzie używany jako punkt końcowy. Jeśli endTime jest równa startTime, oznacza to wnioskowanie jednego pojedynczego punktu danych, który jest często używany w scenariuszach przesyłania strumieniowego.

Parametry opcjonalne dla interfejsu API trenowania

Inne parametry interfejsu API trenowania są opcjonalne:

  • slidingWindow — Ile punktów danych jest używanych do określania anomalii. Liczba całkowita z zakresu od 28 do 2880. Wartość domyślna to 300. Jeśli slidingWindow jest przeznaczony k do trenowania modelu, co najmniej k punkty powinny być dostępne z pliku źródłowego podczas wnioskowania, aby uzyskać prawidłowe wyniki.

    MvAD przyjmuje segment punktów danych, aby zdecydować, czy następny punkt danych jest anomalią. Długość segmentu to slidingWindow. Podczas wybierania slidingWindow wartości należy pamiętać o dwóch kwestiach:

    1. Właściwości danych: niezależnie od tego, czy są to dane okresowe, jak i częstotliwość próbkowania. Gdy dane są okresowe, można ustawić długość od 1 do 3 cykli jako slidingWindow. Gdy dane mają wysoką częstotliwość (mały stopień szczegółowości), na przykład poziom minuty lub drugi poziom, można ustawić stosunkowo wyższą wartość slidingWindow.
    2. Kompromis między czasem trenowania/wnioskowania a potencjalnym wpływem na wydajność. Większy slidingWindow może spowodować dłuższy czas trenowania/wnioskowania. Nie ma gwarancji , że większe slidingWindows doprowadzi do zysków dokładności. Mała slidingWindow może spowodować trudności z połączeniem modelu z optymalnym rozwiązaniem. Na przykład trudno jest wykryć anomalie, gdy slidingWindow ma tylko dwa punkty.

  • alignMode - Jak wyrównywać wiele zmiennych (szeregów czasowych) na znacznikach czasu. Istnieją dwie opcje dla tego parametru i Inner Outer, a wartość domyślna to Outer.

    Ten parametr ma krytyczne znaczenie w przypadku niezgodności między sekwencjami sygnatur czasowych zmiennych. Model musi wyrównywać zmienne do tej samej sekwencji znacznika czasu przed dalszym przetwarzaniem.

    Inner oznacza, że model będzie zgłaszać wyniki wykrywania tylko na znacznikach czasu, na których każda zmienna ma wartość, tj. przecięcie wszystkich zmiennych. Outer oznacza, że model będzie zgłaszać wyniki wykrywania na znacznikach czasu, na których każda zmienna ma wartość, tj. związek wszystkich zmiennych.

    Oto przykład objaśnienia różnych alignModel wartości.

    Zmienna-1

    timestamp wartość
    2020-11-01 1
    2020-11-02 2
    2020-11-04 100
    2020-11-05 5

    Zmienna-2

    timestamp wartość
    2020-11-01 1
    2020-11-02 2
    2020-11-03 3
    2020-11-04 100

    Inner sprzężenia dwóch zmiennych

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

    Outer sprzężenia dwóch zmiennych

    timestamp Zmienna-1 Zmienna-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 wypełnić nan scaloną tabelę. W scalonej tabeli mogą brakować wartości i powinny być prawidłowo obsługiwane. Udostępniamy kilka metod, aby je wypełnić. Opcje to Linear, , PreviousSubsequent, Zeroi , a Fixed wartością domyślną jest Linear.

    Opcja Method
    Linear Wypełnianie nan wartości według interpolacji liniowej
    Previous Propaguj ostatnią prawidłową wartość, aby wypełnić luki. Przykład: [1, 2, nan, 3, nan, 4] ->[1, 2, 2, 3, 3, 4]
    Subsequent Użyj następnej prawidłowej wartości, aby wypełnić luki. Przykład: [1, 2, nan, 3, nan, 4] ->[1, 2, 3, 3, 4, 4]
    Zero Wypełnij nan wartości wartością 0.
    Fixed Wypełnij nan wartości z określoną prawidłową wartością, która powinna być podana w pliku paddingValue.

  • paddingValue - Wartość dopełniania jest używana do wypełnienia nan , gdy fillNAMethod jest Fixed i musi być podana w tym przypadku. W innych przypadkach jest to opcjonalne.

  • displayName — Jest to opcjonalny parametr, który służy do identyfikowania modeli. Można na przykład użyć go do oznaczania parametrów, źródeł danych i innych metadanych dotyczących modelu i jego danych wejściowych. Wartością domyślną jest ciąg pusty.

Schemat danych wejściowych

MvAD wykrywa anomalie z grupy metryk i wywołujemy każdą metrykę zmienną lub szeregiem czasowym.

  • Możesz pobrać przykładowy plik danych od firmy Microsoft, aby sprawdzić zaakceptowany schemat z: https://aka.ms/AnomalyDetector/MVADSampleData

  • Każda zmienna musi mieć dwa i tylko dwa pola oraz timestamp value, i powinna być przechowywana w pliku wartości rozdzielanych przecinkami (CSV).

  • Nazwy kolumn pliku CSV powinny być dokładnie timestamp i value, z uwzględnieniem wielkości liter.

  • Wartości timestamp powinny być zgodne z normą ISO 8601. value Mogą to być liczby całkowite lub dziesiętne z dowolną liczbą miejsc dziesiętnych. Dobry przykład zawartości pliku CSV:

    timestamp wartość
    2019-04-01T00:00:00Z 5
    2019-04-01T00:01:00Z 3,6
    2019-04-01T00:02:00Z 100
    ... ...

    Uwaga

    Jeśli znaczniki czasu mają godziny, minuty i/lub sekundy, upewnij się, że są one prawidłowo zaokrąglane przed wywołaniem interfejsów API.

    Na przykład jeśli częstotliwość danych ma być jednym punktem danych co 30 sekund, ale widzisz znaczniki czasu, takie jak "12:00:01" i "12:00:28", jest to silny sygnał, że należy wstępnie przetworzyć znaczniki czasu dla nowych wartości, takich jak "12:00:00" i "12:00:30".

    Aby uzyskać szczegółowe informacje, zapoznaj się z sekcją "Zaokrąglenie znacznika czasu" w dokumencie najlepszych rozwiązań.

  • Nazwa pliku CSV będzie używana jako nazwa zmiennej i powinna być unikatowa. Na przykład "temperature.csv" i "humidity.csv".

  • Zmienne trenowania i zmiennych wnioskowania powinny być spójne. Jeśli na przykład używasz series_1metod , , series_2series_3, , series_4i series_5 do trenowania, należy podać dokładnie te same zmienne dla wnioskowania.

  • Pliki CSV powinny być kompresowane do pliku zip i przekazywane do kontenera obiektów blob platformy Azure. Plik zip może mieć dowolną nazwę.

Struktura folderów

Typowym błędem w przygotowaniu danych są dodatkowe foldery w pliku zip. Załóżmy na przykład, że nazwa pliku zip to series.zip. Następnie po dekompresowaniu plików do nowego folderu ./seriesprawidłową ścieżką do plików CSV jest./series/series_1.csv, a nieprawidłową ścieżką może być ./series/foo/bar/series_1.csv.

Prawidłowy przykład drzewa katalogów po dekompresowaniu pliku zip w systemie Windows

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

Nieprawidłowy przykład drzewa katalogów po dekompresowaniu pliku zip w systemie Windows

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

Inżynieria danych

Teraz możesz uruchomić kod za pomocą interfejsów API MVAD bez żadnego błędu. Co można zrobić, aby zwiększyć dokładność modelu?

Jakość danych

  • Ponieważ model uczy się normalnych wzorców z danych historycznych, dane treningowe powinny reprezentować ogólny normalny stan systemu. Trudno jest modelowi nauczyć się tego typu wzorców, jeśli dane szkoleniowe są pełne anomalii. Próg empiryczny nieprawidłowej szybkości wynosi 1% i poniżej w celu uzyskania dobrej dokładności.
  • Ogólnie rzecz biorąc, brak współczynnika wartości danych treningowych powinien wynosić poniżej 20%. Zbyt wiele brakujących danych może skończyć się automatycznie wypełnionymi wartościami (zwykle wartościami liniowymi lub wartościami stałymi) wyuczone jako normalne wzorce. Może to spowodować wykrycie rzeczywistych (nie brakuje) punktów danych jako anomalii.

Ilość danych

  • Podstawowy model MVAD ma miliony parametrów. Potrzebuje minimalnej liczby punktów danych, aby poznać optymalny zestaw parametrów. Reguła empiryczna polega na tym, że należy podać 5000 lub więcej punktów danych (sygnatur czasowych) na zmienną , aby wytrenować model pod kątem dobrej dokładności. Ogólnie rzecz biorąc, tym więcej danych treningowych, tym większa dokładność. Jednak w przypadkach, gdy nie możesz wygenerować takiej ilości danych, nadal zachęcamy do eksperymentowania z mniejszą ilością danych i sprawdzenia, czy naruszona dokładność jest nadal akceptowalna.

  • Za każdym razem, gdy wywołujesz interfejs API wnioskowania, musisz upewnić się, że plik danych źródłowych zawiera tylko wystarczającą liczbę punktów danych. Zwykle jest to slidingWindow + liczba punktów danych, które naprawdę potrzebują wyników wnioskowania. Na przykład w przypadku przesyłania strumieniowego, gdy za każdym razem, gdy chcesz wywnioskować jeden nowy znacznik czasu, plik danych może zawierać tylko główny slidingWindow punkt danych plus JEDEN. Następnie można przejść do innego pliku zip z taką samą liczbą punktów danych (slidingWindow + 1), ale przenieść jeden krok po prawej stronie i przesłać do innego zadania wnioskowania.

    Cokolwiek poza tym lub "przed" wiodące okno przesuwane nie wpłynie na wynik wnioskowania w ogóle i może spowodować tylko obniżenie wydajności. Wszystkie poniższe elementy mogą prowadzić do błędu NotEnoughInput .

Zaokrąglone znaczniki czasu

W grupie zmiennych (szeregów czasowych) każda zmienna może być zbierana z niezależnego źródła. Sygnatury czasowe różnych zmiennych mogą być niespójne ze sobą i ze znanymi częstotliwościami. Oto prosty przykład.

Zmienna-1

timestamp wartość
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

Zmienna-2

timestamp wartość
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

Mamy dwie zmienne zebrane z dwóch czujników, które wysyłają jeden punkt danych co 30 sekund. Jednak czujniki nie wysyłają punktów danych z ścisłą parzystą częstotliwością, ale czasami i czasami później. Ponieważ mvAD bierze pod uwagę korelacje między różnymi zmiennymi, znaczniki czasu muszą być prawidłowo wyrównane, aby metryki mogły poprawnie odzwierciedlać stan systemu. W powyższym przykładzie znaczniki czasu zmiennej 1 i zmiennej 2 muszą być prawidłowo zaokrąglone do ich częstotliwości przed wyrównaniem.

Zobaczmy, co się stanie, jeśli nie zostaną wstępnie przetworzone. Jeśli ustawimy wartość alignMode Outer (co oznacza związek dwóch zestawów), scalona tabela to:

timestamp Zmienna-1 Zmienna-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 wskazuje brakujące wartości. Oczywiście scalona tabela nie jest oczekiwana. Zmienna 1 i zmienna 2 przeplatać, a model MVAD nie może wyodrębnić informacji o korelacjach między nimi. Jeśli ustawimy wartość alignMode Inner, scalona tabela jest pusta, ponieważ nie ma wspólnego znacznika czasu w zmiennej 1 i zmiennej 2.

W związku z tym znaczniki czasu zmiennej 1 i zmiennej 2 powinny być wstępnie przetwarzane (zaokrąglone do najbliższych 30-sekundowych sygnatur czasowych), a nowe szeregi czasowe to:

Zmienna-1

timestamp wartość
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

Zmienna-2

timestamp wartość
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

Teraz scalona tabela jest bardziej rozsądna.

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

Wartości różnych zmiennych w znacznikach czasu zamknięcia są dobrze wyrównane, a model MVAD może teraz wyodrębnić informacje korelacji.

Ograniczenia

Istnieją pewne ograniczenia dotyczące interfejsów API trenowania i wnioskowania. Należy pamiętać o tych ograniczeniach, aby uniknąć błędów.

Ogólne ograniczenia

  • Okno przesuwne: 28-2880 znaczniki czasu, wartość domyślna to 300. W przypadku okresowych danych ustaw długość 2–4 cykli jako okno przesuwne.
  • Liczby zmiennych: w przypadku trenowania i wnioskowania wsadowego co najwyżej 301 zmiennych.

Ograniczenia trenowania

  • Znaczniki czasu: Co najwyżej 1000000. Zbyt mało sygnatur czasowych może zmniejszyć jakość modelu. Zaleca się posiadanie więcej niż 5000 sygnatur czasowych.
  • Stopień szczegółowości: minimalny stopień szczegółowości to per_second.

Ograniczenia wnioskowania wsadowego

  • Znaczniki czasowe: Co najmniej 1 długość okna przesuwnego wynosi co najmniej 20000.

Ograniczenia wnioskowania przesyłania strumieniowego

  • Znaczniki czasowe: Co najmniej 2880, co najmniej 1 długość okna przesuwnego.
  • Wykrywanie sygnatur czasowych: od 1 do 10.

Jakość modelu

Jak radzić sobie z fałszywie dodatnimi i fałszywie ujemnymi w rzeczywistych scenariuszach?

Podaliśmy ważność, która wskazuje znaczenie anomalii. Wyniki fałszywie dodatnie mogą być filtrowane przez skonfigurowanie progu dla ważności. Czasami zbyt wiele wyników fałszywie dodatnich może pojawić się, gdy istnieją zmiany wzorca w danych wnioskowania. W takich przypadkach może być konieczne ponowne trenowanie modelu na nowych danych. Jeśli dane szkoleniowe zawierają zbyt wiele anomalii, w wynikach wykrywania mogą występować fałszywe wyniki ujemne. Dzieje się tak, ponieważ model uczy się wzorców z danych treningowych i anomalii może spowodować odchylenie modelu. W związku z tym prawidłowe czyszczenie danych może pomóc zmniejszyć liczbę wyników fałszywie ujemnych.

Jak oszacować, który model najlepiej używać zgodnie z utratą trenowania i utratą walidacji?

Ogólnie rzecz biorąc, trudno jest zdecydować, który model jest najlepszy bez oznaczonego zestawu danych. Możemy jednak wykorzystać straty trenowania i walidacji, aby uzyskać przybliżone oszacowanie i odrzucić te złe modele. Najpierw musimy sprawdzić, czy straty treningowe są zbieżne. Rozbieżne straty często wskazują niską jakość modelu. Po drugie, wartości strat mogą pomóc określić, czy występuje niedopasowanie, czy nadmierne dopasowanie. Modele niedopasowane lub nadmierne dopasowanie mogą nie mieć żądanej wydajności. Po trzecie, chociaż definicja funkcji utraty nie odzwierciedla bezpośrednio wydajności wykrywania, wartości strat mogą być narzędziem pomocniczym do szacowania jakości modelu. Wartość niskiej utraty jest niezbędnym warunkiem dla dobrego modelu, dlatego możemy odrzucić modele o wysokich wartościach strat.

Typowe pułapki

Oprócz tabeli kodów błędów dowiedzieliśmy się od klientów, takich jak niektóre typowe pułapki podczas korzystania z interfejsów API MVAD. Ta tabela pomoże Ci uniknąć tych problemów.

Pułapki Konsekwencja Wyjaśnienie i rozwiązanie
Znaczniki czasu w danych treningowych i/lub danych wnioskowania nie zostały zaokrąglone w celu dopasowania do odpowiedniej częstotliwości danych każdej zmiennej. Znaczniki czasu wyników wnioskowania nie są zgodnie z oczekiwaniami: zbyt mało sygnatur czasowych lub zbyt wiele sygnatur czasowych. Zapoznaj się z tematem Zaokrąglenie znacznika czasu.
Zbyt wiele nietypowych punktów danych w danych treningowych Na dokładność modelu ma negatywny wpływ, ponieważ traktuje nietypowe punkty danych jako normalne wzorce podczas trenowania. Empirycznie zachowaj nietypową szybkość na poziomie lub poniżej 1% pomoże.
Zbyt mało danych treningowych Bezpieczeństwo dokładności modelu jest naruszone. Empirycznie trenowanie modelu MVAD wymaga 15 000 lub większej liczby punktów danych (sygnatur czasowych) na zmienną, aby zachować dobrą dokładność.
Pobieranie wszystkich punktów danych z isAnomaly=true anomaliami Zbyt wiele wyników fałszywie dodatnich Należy użyć zarówno isAnomaly i severity (lub score), aby przesiewać anomalie, które nie są poważne i (opcjonalnie) używać grupowania, aby sprawdzić czas trwania anomalii w celu pomijania losowych szumów. Zapoznaj się z poniższą sekcją często zadawanych pytań , aby uzyskać różnicę między elementami severity i score.
Podfoldery są spakowane do pliku danych na potrzeby trenowania lub wnioskowania. Pliki danych csv wewnątrz podfolderów są ignorowane podczas trenowania i/lub wnioskowania. W pliku zip nie są dozwolone żadne podfoldery. Szczegółowe informacje można znaleźć w temacie Struktura folderów.
Za dużo danych w pliku danych wnioskowania: na przykład kompresowanie wszystkich danych historycznych w pliku zip danych wnioskowania Podczas próby przekazania pliku zip do obiektu blob platformy Azure oraz podczas próby uruchomienia wnioskowania mogą wystąpić błędy. Aby uzyskać szczegółowe informacje, zobacz Ilość danych.
Tworzenie zasobów Narzędzie do wykrywania anomalii w regionach platformy Azure, które nie obsługują jeszcze wzorca MVAD i wywoływanie interfejsów API MVAD Podczas wywoływania interfejsów API MVAD zostanie wyświetlony błąd "Nie znaleziono zasobu". Na etapie wersji zapoznawczej usługa MVAD jest dostępna tylko w ograniczonych regionach. Dodaj zakładkę Co nowego w Narzędzie do wykrywania anomalii, aby być na bieżąco z wdrożeniami regionów MVAD. Możesz również zgłosić problem z usługą GitHub lub skontaktować się z nami pod adresem AnomalyDetector@microsoft.com , aby poprosić o określone regiony.

Często zadawane pytania

Jak działa okno przesuwane MVAD?

Użyjmy dwóch przykładów, aby dowiedzieć się, jak działa okno przesuwne MVAD. Załóżmy, że ustawiono slidingWindow wartość = 1440, a dane wejściowe są na poziomie jednego minuty szczegółowości.

  • Scenariusz przesyłania strumieniowego: chcesz przewidzieć, czy punkt danych ONE o wartości "2021-01-02T00:00:00Z" jest nietypowy. Twoja startTime i endTime będzie taka sama wartość ("2021-01-02T00:00:00Z"). Źródło danych wnioskowania musi jednak zawierać co najmniej 1440 + 1 znaczniki czasu. Ponieważ mvAD pobierze wiodące dane przed docelowym punktem danych ("2021-01-02T00:00:00Z"), aby zdecydować, czy element docelowy jest anomalią. Długość potrzebnych danych wiodących wynosi slidingWindow lub 1440 w tym przypadku. 1,440 = 60 * 24, więc dane wejściowe muszą zaczynać się od najnowszej "2021-01-01T00:00:00Z".

  • Scenariusz wsadowy: masz wiele docelowych punktów danych do przewidywania. Twój endTime będzie większy niż twój startTime. Wnioskowanie w takich scenariuszach jest wykonywane w sposób "przesuwający się okno". Na przykład mvAD będzie używać danych z 2021-01-01T00:00:00Z do (włącznie) w 2021-01-01T23:59:00Z celu określenia, czy dane w 2021-01-02T00:00:00Z lokalizacji są nietypowe. Następnie przechodzi do przodu i używa danych z 2021-01-01T00:01:00Z do 2021-01-02T00:00:00Z (włącznie), aby określić, czy dane w 2021-01-02T00:01:00Z lokalizacji są nietypowe. Przechodzi on w ten sam sposób (biorąc 1440 punktów danych do porównania) do ostatniego znacznika czasu określonego przez endTime (lub rzeczywisty najnowszy znacznik czasu). W związku z tym źródło danych wnioskowania musi zawierać dane zaczynające się od startTime - slidingWindow i idealnie zawiera łącznie rozmiar slidingWindow + (endTime - startTime).

Jaka jest różnica między elementami severity i score?

Zwykle zalecamy użycie severity jako filtru do przesiewania "anomalii", które nie są tak ważne dla Twojej firmy. W zależności od scenariusza i wzorca danych te anomalie, które są rzadziej ważne, mają stosunkowo niższe severity wartości lub autonomiczne (nieciągłe) wysokie severity wartości, takie jak losowe skoki.

W przypadkach, gdy znaleziono potrzebę bardziej zaawansowanych reguł niż progi względem severity lub czasu trwania ciągłych wysokich severity wartości, warto użyć score do tworzenia bardziej zaawansowanych filtrów. Zrozumienie sposobu używania score wzorca MVAD do określania anomalii może pomóc:

Uważamy, czy punkt danych jest nietypowy zarówno z perspektywy globalnej, jak i lokalnej. Jeśli score znacznik czasu jest wyższy niż określony próg, znacznik czasu jest oznaczony jako anomalia. Jeśli score wartość jest niższa niż próg, ale jest stosunkowo wyższa w segmencie, jest również oznaczona jako anomalia.

Następne kroki