Udostępnij za pośrednictwem

Monitorowanie wydajności modeli wdrożonych w środowisku produkcyjnym

  • Artykuł

DOTYCZY: Rozszerzenie interfejsu wiersza polecenia platformy Azure w wersji 2 (current)Zestaw PYTHON SDK azure-ai-ml v2 (bieżąca)

Dowiedz się, jak używać monitorowania modeli usługi Azure Machine Learning do ciągłego śledzenia wydajności modeli uczenia maszynowego w środowisku produkcyjnym. Monitorowanie modelu zapewnia szeroki wgląd w sygnały monitorowania i alerty dotyczące potencjalnych problemów. Podczas monitorowania sygnałów i metryk wydajności modeli w środowisku produkcyjnym można krytycznie ocenić związane z nimi zagrożenia i zidentyfikować martwe miejsca, które mogą negatywnie wpłynąć na twoją firmę.

Z tego artykułu dowiesz się, jak wykonywać następujące zadania:

  • Konfigurowanie gotowego i zaawansowanego monitorowania modeli wdrożonych w punktach końcowych online usługi Azure Machine Learning
  • Monitorowanie metryk wydajności modeli w środowisku produkcyjnym
  • Monitorowanie modeli wdrożonych poza usługą Azure Machine Learning lub wdrożonych w punktach końcowych usługi Azure Machine Learning wsadowych
  • Konfigurowanie monitorowania modelu przy użyciu niestandardowych sygnałów i metryk
  • Interpretowanie wyników monitorowania
  • Integrowanie monitorowania modelu usługi Azure Machine Learning z usługą Azure Event Grid

Wymagania wstępne

Przed wykonaniem kroków opisanych w tym artykule upewnij się, że masz następujące wymagania wstępne:

  • Kontrola dostępu na podstawie ról platformy Azure (Azure RBAC): jest używana do udzielania dostępu do operacji w usłudze Azure Machine Learning. Aby wykonać kroki opisane w tym artykule, konto użytkownika musi mieć przypisaną rolę właściciela lub współautora dla obszaru roboczego usługi Azure Machine Learning lub rolę niestandardową zezwalającą na Microsoft.MachineLearningServices/workspaces/onlineEndpoints/*korzystanie z usługi . Aby uzyskać więcej informacji, zobacz Zarządzanie dostępem do obszaru roboczego usługi Azure Machine Learning.

  • Aby monitorować model wdrożony w punkcie końcowym online usługi Azure Machine Learning (zarządzany punkt końcowy online lub punkt końcowy online platformy Kubernetes), upewnij się, że:

  • Aby monitorować model wdrożony w punkcie końcowym wsadowym usługi Azure Machine Learning lub wdrożony poza usługą Azure Machine Learning, upewnij się, że:

    • Należy zebrać dane produkcyjne i zarejestrować je jako zasób danych usługi Azure Machine Learning.
    • Stale aktualizuj zarejestrowany zasób danych na potrzeby monitorowania modelu.
    • (Zalecane) Zarejestruj model w obszarze roboczym usługi Azure Machine Learning w celu śledzenia pochodzenia.

Ważne

Zaplanowano uruchamianie zadań monitorowania modelu w bezserwerowych pulach obliczeniowych platformy Spark z obsługą następujących typów wystąpień maszyn wirtualnych: Standard_E4s_v3, , Standard_E8s_v3Standard_E16s_v3, Standard_E32s_v3i Standard_E64s_v3. Możesz wybrać typ wystąpienia maszyny wirtualnej z właściwością create_monitor.compute.instance_type w konfiguracji YAML lub z listy rozwijanej w usłudze Azure Machine Learning Studio.

Konfigurowanie gotowego do użycia monitorowania modelu

Załóżmy, że model jest wdrażany w środowisku produkcyjnym w punkcie końcowym online usługi Azure Machine Learning i włączasz zbieranie danych w czasie wdrażania. W tym scenariuszu usługa Azure Machine Learning zbiera dane wnioskowania produkcyjnego i automatycznie przechowuje je w usłudze Microsoft Azure Blob Storage. Następnie możesz użyć monitorowania modelu usługi Azure Machine Learning, aby stale monitorować te dane wnioskowania produkcyjnego.

Możesz użyć interfejsu wiersza polecenia platformy Azure, zestawu SDK języka Python lub programu Studio na potrzeby gotowej konfiguracji monitorowania modelu. Konfiguracja monitorowania modelu gotowego do użycia zapewnia następujące możliwości monitorowania:

  • Usługa Azure Machine Learning automatycznie wykrywa zestaw danych wnioskowania produkcyjnego skojarzony z wdrożeniem online usługi Azure Machine Learning i używa zestawu danych do monitorowania modelu.
  • Zestaw danych referencyjnych porównania jest ustawiany jako ostatni, poprzedni zestaw danych wnioskowania produkcyjnego.
  • Konfiguracja monitorowania automatycznie obejmuje i śledzi wbudowane sygnały monitorowania: dryf danych, dryf przewidywania i jakość danych. Dla każdego sygnału monitorowania usługa Azure Machine Learning używa:
    • niedawny, poprzedni zestaw danych wnioskowania produkcyjnego jako zestaw danych referencyjnych porównania.
    • inteligentne wartości domyślne metryk i progów.
  • Zadanie monitorowania ma być uruchamiane codziennie o godzinie 3:15 (na przykład), aby uzyskać sygnały monitorowania i ocenić każdy wynik metryki względem odpowiadającego mu progu. Domyślnie po przekroczeniu dowolnego progu usługa Azure Machine Learning wysyła wiadomość e-mail z alertem do użytkownika, który skonfigurował monitor.

Monitorowanie modelu usługi Azure Machine Learning używa az ml schedule do planowania zadania monitorowania. Monitor modelu gotowego do użycia można utworzyć przy użyciu następującego polecenia interfejsu wiersza polecenia i definicji YAML:

az ml schedule create -f ./out-of-box-monitoring.yaml

Poniższy kod YAML zawiera definicję monitorowania modelu gotowego do użycia.

# out-of-box-monitoring.yaml
$schema:  http://azureml/sdk-2-0/Schedule.json
name: credit_default_model_monitoring
display_name: Credit default model monitoring
description: Credit default model monitoring setup with minimal configurations

trigger:
  # perform model monitoring activity daily at 3:15am
  type: recurrence
  frequency: day #can be minute, hour, day, week, month
  interval: 1 # #every day
  schedule: 
    hours: 3 # at 3am
    minutes: 15 # at 15 mins after 3am

create_monitor:

  compute: # specify a spark compute for monitoring job
    instance_type: standard_e4s_v3
    runtime_version: "3.3"

  monitoring_target: 
    ml_task: classification # model task type: [classification, regression, question_answering]
    endpoint_deployment_id: azureml:credit-default:main # azureml endpoint deployment id

  alert_notification: # emails to get alerts
    emails:
      - abc@example.com
      - def@example.com

Konfigurowanie zaawansowanego monitorowania modelu

Usługa Azure Machine Learning oferuje wiele możliwości ciągłego monitorowania modeli. Zobacz Możliwości monitorowania modeli, aby uzyskać pełną listę tych możliwości. W wielu przypadkach należy skonfigurować monitorowanie modelu przy użyciu zaawansowanych funkcji monitorowania. W poniższych sekcjach skonfigurujesz monitorowanie modelu przy użyciu tych funkcji:

  • Korzystanie z wielu sygnałów monitorowania dla szerokiego widoku.
  • Użycie historycznych danych trenowania modelu lub danych walidacji jako zestawu danych referencyjnych porównania.
  • Monitorowanie najważniejszych n najważniejszych funkcji i poszczególnych funkcji.

Konfigurowanie ważności funkcji

Ważność funkcji reprezentuje względne znaczenie każdej funkcji wejściowej do danych wyjściowych modelu. Na przykład temperature może być ważniejsze od przewidywania modelu w porównaniu z elevationwartością . Włączenie ważności funkcji może zapewnić wgląd w funkcje, których nie chcesz dryfować ani mieć problemów z jakością danych w środowisku produkcyjnym.

Aby włączyć ważność funkcji z dowolnymi sygnałami (takimi jak dryf danych lub jakość danych), należy podać następujące elementy:

  • Zestaw danych trenowania reference_data jako zestaw danych.
  • Właściwość reference_data.data_column_names.target_column , która jest nazwą kolumny danych wyjściowych/przewidywania modelu.

Po włączeniu znaczenia funkcji zobaczysz znaczenie funkcji dla każdej funkcji, którą monitorujesz w interfejsie użytkownika programu Azure Machine Learning Model Monitoring Studio.

Do zaawansowanej konfiguracji monitorowania modelu można użyć interfejsu wiersza polecenia platformy Azure, zestawu SDK języka Python lub programu Studio.

Utwórz konfigurację zaawansowanego monitorowania modelu za pomocą następującego polecenia interfejsu wiersza polecenia i definicji YAML:

az ml schedule create -f ./advanced-model-monitoring.yaml

Poniższy kod YAML zawiera definicję zaawansowanego monitorowania modelu.

# advanced-model-monitoring.yaml
$schema:  http://azureml/sdk-2-0/Schedule.json
name: fraud_detection_model_monitoring
display_name: Fraud detection model monitoring
description: Fraud detection model monitoring with advanced configurations

trigger:
  # perform model monitoring activity daily at 3:15am
  type: recurrence
  frequency: day #can be minute, hour, day, week, month
  interval: 1 # #every day
  schedule: 
    hours: 3 # at 3am
    minutes: 15 # at 15 mins after 3am

create_monitor:

  compute: 
    instance_type: standard_e4s_v3
    runtime_version: "3.3"

  monitoring_target:
    ml_task: classification
    endpoint_deployment_id: azureml:credit-default:main
  
  monitoring_signals:
    advanced_data_drift: # monitoring signal name, any user defined name works
      type: data_drift
      # reference_dataset is optional. By default referece_dataset is the production inference data associated with Azure Machine Learning online endpoint
      reference_data:
        input_data:
          path: azureml:credit-reference:1 # use training data as comparison reference dataset
          type: mltable
        data_context: training
        data_column_names:
          target_column: DEFAULT_NEXT_MONTH
      features: 
        top_n_feature_importance: 10 # monitor drift for top 10 features
      metric_thresholds:
        numerical:
          jensen_shannon_distance: 0.01
        categorical:
          pearsons_chi_squared_test: 0.02
    advanced_data_quality:
      type: data_quality
      # reference_dataset is optional. By default reference_dataset is the production inference data associated with Azure Machine Learning online endpoint
      reference_data:
        input_data:
          path: azureml:credit-reference:1
          type: mltable
        data_context: training
      features: # monitor data quality for 3 individual features only
        - SEX
        - EDUCATION
      metric_thresholds:
        numerical:
          null_value_rate: 0.05
        categorical:
          out_of_bounds_rate: 0.03

    feature_attribution_drift_signal:
      type: feature_attribution_drift
      # production_data: is not required input here
      # Please ensure Azure Machine Learning online endpoint is enabled to collected both model_inputs and model_outputs data
      # Azure Machine Learning model monitoring will automatically join both model_inputs and model_outputs data and used it for computation
      reference_data:
        input_data:
          path: azureml:credit-reference:1
          type: mltable
        data_context: training
        data_column_names:
          target_column: DEFAULT_NEXT_MONTH
      metric_thresholds:
        normalized_discounted_cumulative_gain: 0.9
  
  alert_notification:
    emails:
      - abc@example.com
      - def@example.com

Konfigurowanie monitorowania wydajności modelu

Monitorowanie modelu usługi Azure Machine Learning umożliwia śledzenie wydajności modeli w środowisku produkcyjnym przez obliczanie ich metryk wydajności. Obecnie obsługiwane są następujące metryki wydajności modelu:

W przypadku modeli klasyfikacji:

  • Dokładność
  • Dokładność
  • Odwołaj

W przypadku modeli regresji:

  • Średni błąd bezwzględny (MAE)
  • Błąd średniokwadratowy (MSE)
  • Błąd średniokwadratowy (RMSE)

Więcej wymagań wstępnych dotyczących monitorowania wydajności modelu

Aby skonfigurować sygnał wydajności modelu, musisz spełnić następujące wymagania:

  • Zawierają dane wyjściowe dla modelu produkcyjnego (przewidywania modelu) z unikatowym identyfikatorem dla każdego wiersza. Jeśli zbierasz dane produkcyjne za pomocą modułu zbierającego dane usługi Azure Machine Learning, correlation_id zostanie on dostarczony dla każdego żądania wnioskowania. W przypadku modułu zbierającego dane masz również możliwość rejestrowania własnego unikatowego identyfikatora z aplikacji.

    Uwaga

    W przypadku monitorowania wydajności modelu usługi Azure Machine Learning zalecamy zarejestrowanie unikatowego identyfikatora we własnej kolumnie przy użyciu modułu zbierającego dane usługi Azure Machine Learning.

  • Mają podstawowe dane prawdy (wartości rzeczywiste) z unikatowym identyfikatorem dla każdego wiersza. Unikatowy identyfikator dla danego wiersza powinien być zgodny z unikatowym identyfikatorem danych wyjściowych modelu dla tego konkretnego żądania wnioskowania. Ten unikatowy identyfikator służy do łączenia zestawu danych podstawowej prawdy z danymi wyjściowymi modelu.

    Bez posiadania podstawowych danych prawdy nie można wykonywać monitorowania wydajności modelu. Ze względu na to, że na poziomie aplikacji napotykane są podstawowe dane prawdy, odpowiedzialność za ich zbieranie w miarę ich udostępniania. Należy również zachować zasób danych w usłudze Azure Machine Learning, który zawiera te podstawowe dane prawdy.

  • (Opcjonalnie) Zestaw danych tabelarycznych ze wstępnie sprzężonym zestawem danych z danymi wyjściowymi modelu i danymi podstawy prawdy już połączonymi.

Monitorowanie wymagań dotyczących wydajności modelu podczas korzystania z modułu zbierającego dane

Jeśli używasz modułu zbierającego dane usługi Azure Machine Learning do zbierania danych wnioskowania produkcyjnego bez podawania własnego unikatowego identyfikatora dla każdego wiersza jako oddzielnej kolumny, correlationid element zostanie automatycznie wygenerowany i uwzględniony w rejestrowanym obiekcie JSON. Jednak moduł zbierający dane będzie wsadowy wiersze , które są wysyłane w krótkim odstępie czasu. Wiersze wsadowe będą należeć do tego samego obiektu JSON i w ten sposób będą miały taki sam correlationidkod .

Aby rozróżnić wiersze w tym samym obiekcie JSON, monitorowanie wydajności modelu usługi Azure Machine Learning używa indeksowania w celu określenia kolejności wierszy w obiekcie JSON. Jeśli na przykład trzy wiersze są wsadowe, a correlationid testwiersz , jeden z nich będzie miał identyfikator , wiersz drugi będzie miał identyfikator test_0test_1, a wiersz trzeci będzie miał identyfikator test_2. Aby upewnić się, że zestaw danych podstawowej prawdy zawiera unikatowe identyfikatory pasujące do zebranych danych wyjściowych modelu wnioskowania produkcyjnego, upewnij się, że indeksujesz je correlationid odpowiednio. Jeśli zarejestrowany obiekt JSON ma tylko jeden wiersz, będzie to correlationid correlationid_0.

Aby uniknąć używania tego indeksowania, zalecamy zarejestrowanie unikatowego identyfikatora we własnej kolumnie w ramce danych biblioteki pandas rejestrowanej za pomocą modułu zbierającego dane usługi Azure Machine Learning. Następnie w konfiguracji monitorowania modelu należy określić nazwę tej kolumny, aby połączyć dane wyjściowe modelu z danymi wyjściowymi podstawy. Tak długo, jak identyfikatory dla każdego wiersza w obu zestawach danych są takie same, monitorowanie modelu usługi Azure Machine Learning może wykonywać monitorowanie wydajności modelu.

Przykładowy przepływ pracy monitorowania wydajności modelu

Aby zrozumieć pojęcia związane z monitorowaniem wydajności modelu, rozważmy ten przykładowy przepływ pracy. Załóżmy, że wdrażasz model, aby przewidzieć, czy transakcje kart kredytowych są fałszywe, czy nie, możesz wykonać następujące kroki, aby monitorować wydajność modelu:

  1. Skonfiguruj wdrożenie tak, aby używało modułu zbierającego dane w celu zbierania danych wnioskowania produkcyjnego modelu (danych wejściowych i wyjściowych). Załóżmy, że dane wyjściowe są przechowywane w kolumnie is_fraud.
  2. Dla każdego wiersza zebranych danych wnioskowania zarejestruj unikatowy identyfikator. Unikatowy identyfikator może pochodzić z aplikacji lub użyć unikatowego identyfikatora generowanego correlationid przez usługę Azure Machine Learning dla każdego zarejestrowanego obiektu JSON.
  3. Później, gdy dane podstawowej prawdy (lub rzeczywistej) is_fraud staną się dostępne, są również rejestrowane i mapowane na ten sam unikatowy identyfikator, który został zarejestrowany przy użyciu danych wyjściowych modelu.
  4. Te podstawowe dane prawdy is_fraud są również zbierane, utrzymywane i zarejestrowane w usłudze Azure Machine Learning jako zasób danych.
  5. Utwórz sygnał monitorowania wydajności modelu, który łączy w wyniku wnioskowania produkcyjnego modelu i podstawowe zasoby danych prawdy przy użyciu unikatowych kolumn identyfikatorów.
  6. Na koniec oblicz metryki wydajności modelu.

Po spełnieniu wymagań wstępnych dotyczących monitorowania wydajności modelu można skonfigurować monitorowanie modelu przy użyciu następującego polecenia interfejsu wiersza polecenia i definicji YAML:

az ml schedule create -f ./model-performance-monitoring.yaml

Poniższy kod YAML zawiera definicję monitorowania modelu przy użyciu zebranych danych wnioskowania produkcyjnego.

$schema:  http://azureml/sdk-2-0/Schedule.json
name: model_performance_monitoring
display_name: Credit card fraud model performance
description: Credit card fraud model performance

trigger:
  type: recurrence
  frequency: day
  interval: 7 
  schedule: 
    hours: 10
    minutes: 15
  
create_monitor:
  compute: 
    instance_type: standard_e8s_v3
    runtime_version: "3.3"
  monitoring_target:
    ml_task: classification
    endpoint_deployment_id: azureml:loan-approval-endpoint:loan-approval-deployment

  monitoring_signals:
    fraud_detection_model_performance: 
      type: model_performance 
      production_data:
        data_column_names:
          prediction: is_fraud
          correlation_id: correlation_id
      reference_data:
        input_data:
          path: azureml:my_model_ground_truth_data:1
          type: mltable
        data_column_names:
          actual: is_fraud
          correlation_id: correlation_id
        data_context: actuals
      alert_enabled: true
      metric_thresholds: 
        tabular_classification:
          accuracy: 0.95
          precision: 0.8
  alert_notification: 
      emails: 
        - abc@example.com

Konfigurowanie monitorowania modelu przez wprowadzenie danych produkcyjnych do usługi Azure Machine Learning

Możesz również skonfigurować monitorowanie modelu dla modeli wdrożonych w punktach końcowych wsadowych usługi Azure Machine Learning lub wdrożonych poza usługą Azure Machine Learning. Jeśli nie masz wdrożenia, ale masz dane produkcyjne, możesz użyć tych danych do ciągłego monitorowania modelu. Aby monitorować te modele, musisz mieć możliwość:

  • Zbieranie danych wnioskowania produkcyjnego z modeli wdrożonych w środowisku produkcyjnym.
  • Zarejestruj dane wnioskowania produkcyjnego jako zasób danych usługi Azure Machine Learning i zapewnij ciągłe aktualizacje danych.
  • Podaj niestandardowy składnik przetwarzania wstępnego danych i zarejestruj go jako składnik usługi Azure Machine Learning.

Jeśli dane nie są zbierane z modułem zbierającym dane, musisz podać niestandardowy składnik przetwarzania wstępnego danych. Bez tego niestandardowego składnika przetwarzania wstępnego danych system monitorowania modelu usługi Azure Machine Learning nie będzie wiedział, jak przetwarzać dane w formie tabelarycznej z obsługą okien czasowych.

Niestandardowy składnik przetwarzania wstępnego musi mieć następujące podpisy wejściowe i wyjściowe:

Dane wejściowe/wyjściowe Nazwa podpisu Type Opis Przykładowa wartość
input data_window_start Literału godzina rozpoczęcia okna danych w formacie ISO8601. 2023-05-01T04:31:57.012Z
input data_window_end Literału godzina zakończenia okna danych w formacie ISO8601. 2023-05-01T04:31:57.012Z
input input_data uri_folder Zebrane dane wnioskowania produkcyjnego zarejestrowane jako zasób danych usługi Azure Machine Learning. azureml:myproduction_inference_data:1
output preprocessed_data mltable Tabelaryczny zestaw danych zgodny z podzbiorem schematu danych referencyjnych.

Aby zapoznać się z przykładem niestandardowego składnika przetwarzania wstępnego danych, zobacz custom_preprocessing w repozytorium GitHub azuremml-examples.

Po spełnieniu poprzednich wymagań możesz skonfigurować monitorowanie modelu przy użyciu następującego polecenia interfejsu wiersza polecenia i definicji YAML:

az ml schedule create -f ./model-monitoring-with-collected-data.yaml

Poniższy kod YAML zawiera definicję monitorowania modelu przy użyciu zebranych danych wnioskowania produkcyjnego.

# model-monitoring-with-collected-data.yaml
$schema:  http://azureml/sdk-2-0/Schedule.json
name: fraud_detection_model_monitoring
display_name: Fraud detection model monitoring
description: Fraud detection model monitoring with your own production data

trigger:
  # perform model monitoring activity daily at 3:15am
  type: recurrence
  frequency: day #can be minute, hour, day, week, month
  interval: 1 # #every day
  schedule: 
    hours: 3 # at 3am
    minutes: 15 # at 15 mins after 3am

create_monitor:
  compute: 
    instance_type: standard_e4s_v3
    runtime_version: "3.3"
  monitoring_target:
    ml_task: classification
    endpoint_deployment_id: azureml:fraud-detection-endpoint:fraud-detection-deployment
  
  monitoring_signals:

    advanced_data_drift: # monitoring signal name, any user defined name works
      type: data_drift
      # define production dataset with your collected data
      production_data:
        input_data:
          path: azureml:my_production_inference_data_model_inputs:1  # your collected data is registered as Azure Machine Learning asset
          type: uri_folder
        data_context: model_inputs
        pre_processing_component: azureml:production_data_preprocessing:1
      reference_data:
        input_data:
          path: azureml:my_model_training_data:1 # use training data as comparison baseline
          type: mltable
        data_context: training
        data_column_names:
          target_column: is_fraud
      features: 
        top_n_feature_importance: 20 # monitor drift for top 20 features
      metric_thresholds:
        numberical:
          jensen_shannon_distance: 0.01
        categorical:
          pearsons_chi_squared_test: 0.02

    advanced_prediction_drift: # monitoring signal name, any user defined name works
      type: prediction_drift
      # define production dataset with your collected data
      production_data:
        input_data:
          path: azureml:my_production_inference_data_model_outputs:1  # your collected data is registered as Azure Machine Learning asset
          type: uri_folder
        data_context: model_outputs
        pre_processing_component: azureml:production_data_preprocessing:1
      reference_data:
        input_data:
          path: azureml:my_model_validation_data:1 # use training data as comparison reference dataset
          type: mltable
        data_context: validation
      metric_thresholds:
        categorical:
          pearsons_chi_squared_test: 0.02
  
  alert_notification:
    emails:
      - abc@example.com
      - def@example.com

Konfigurowanie monitorowania modelu przy użyciu niestandardowych sygnałów i metryk

Dzięki monitorowaniu modelu usługi Azure Machine Learning można zdefiniować sygnał niestandardowy i zaimplementować dowolną wybraną metrykę do monitorowania modelu. Ten sygnał niestandardowy można zarejestrować jako składnik usługi Azure Machine Learning. Gdy zadanie monitorowania modelu usługi Azure Machine Learning jest uruchamiane zgodnie z określonym harmonogramem, oblicza metryki zdefiniowane w ramach sygnału niestandardowego, podobnie jak w przypadku wstępnie utworzonych sygnałów (dryfu danych, dryfu przewidywania i jakości danych).

Aby skonfigurować niestandardowy sygnał do użycia na potrzeby monitorowania modelu, należy najpierw zdefiniować sygnał niestandardowy i zarejestrować go jako składnik usługi Azure Machine Learning. Składnik usługi Azure Machine Learning musi mieć następujące podpisy wejściowe i wyjściowe:

Podpis wejściowy składnika

Element wejściowy składnika DataFrame powinien zawierać następujące elementy:

  • Element mltable z przetworzonymi danymi ze składnika przetwarzania wstępnego
  • Dowolna liczba literałów, z których każda reprezentuje zaimplementowaną metryki w ramach niestandardowego składnika sygnału. Jeśli na przykład zaimplementowano metryki , std_deviationmusisz wprowadzić dane wejściowe dla elementu std_deviation_threshold. Ogólnie rzecz biorąc, powinna istnieć jedna wartość wejściowa na metryę o nazwie <metric_name>_threshold.
Nazwa podpisu Type Opis Przykładowa wartość
production_data mltable Tabelaryczny zestaw danych zgodny z podzbiorem schematu danych referencyjnych.
std_deviation_threshold Literału Odpowiedni próg dla zaimplementowanego metryki. 2

Podpis wyjściowy składnika

Port wyjściowy składnika powinien mieć następujący podpis.

Nazwa podpisu Type Opis
signal_metrics mltable Tabela mltable zawierająca obliczone metryki. Schemat jest zdefiniowany w następnej sekcji signal_metrics schematu.

schemat signal_metrics

Ramka danych wyjściowych składnika powinna zawierać cztery kolumny: group, , metric_namemetric_valuei threshold_value.

Nazwa podpisu Type Opis Przykładowa wartość
grupa Literału Grupowanie logiczne najwyższego poziomu do zastosowania do tej metryki niestandardowej. TRANSACTIONAMOUNT
metric_name Literału Nazwa metryki niestandardowej. std_deviation
metric_value numeryczny Wartość metryki niestandardowej. 44,896.082
threshold_value numeryczny Próg dla metryki niestandardowej. 2

W poniższej tabeli przedstawiono przykładowe dane wyjściowe z niestandardowego składnika sygnału, który oblicza metrykę std_deviation :

grupa metric_value metric_name threshold_value
TRANSACTIONAMOUNT 44,896.082 std_deviation 2
LOCALHOUR 3.983 std_deviation 2
TRANSACTIONAMOUNTUSD 54,004.902 std_deviation 2
DIGITALITEMCOUNT 7.238 std_deviation 2
PHYSICALITEMCOUNT 5.509 std_deviation 2

Aby wyświetlić przykładową niestandardową definicję składnika sygnału i kod obliczeń metryk, zobacz custom_signal w repozytorium azureml-examples.

Po spełnieniu wymagań dotyczących używania niestandardowych sygnałów i metryk możesz skonfigurować monitorowanie modelu przy użyciu następującego polecenia interfejsu wiersza polecenia i definicji YAML:

az ml schedule create -f ./custom-monitoring.yaml

Poniższy kod YAML zawiera definicję monitorowania modelu za pomocą sygnału niestandardowego. Niektóre kwestie, które należy zauważyć w kodzie:

  • Przyjęto założenie, że składnik został już utworzony i zarejestrowany przy użyciu niestandardowej definicji sygnału w usłudze Azure Machine Learning.
  • Element component_id zarejestrowanego niestandardowego składnika sygnału to azureml:my_custom_signal:1.0.0.
  • Jeśli dane zostały zebrane za pomocą modułu zbierającego dane, możesz pominąć pre_processing_component właściwość . Jeśli chcesz użyć składnika przetwarzania wstępnego do wstępnego przetwarzania danych produkcyjnych, które nie są zbierane przez moduł zbierający dane, możesz go określić.
# custom-monitoring.yaml
$schema:  http://azureml/sdk-2-0/Schedule.json
name: my-custom-signal
trigger:
  type: recurrence
  frequency: day # can be minute, hour, day, week, month
  interval: 7 # #every day
create_monitor:
  compute:
    instance_type: "standard_e4s_v3"
    runtime_version: "3.3"
  monitoring_signals:
    customSignal:
      type: custom
      component_id: azureml:my_custom_signal:1.0.0
      input_data:
        production_data:
          input_data:
            type: uri_folder
            path: azureml:my_production_data:1
          data_context: test
          data_window:
            lookback_window_size: P30D
            lookback_window_offset: P7D
          pre_processing_component: azureml:custom_preprocessor:1.0.0
      metric_thresholds:
        - metric_name: std_deviation
          threshold: 2
  alert_notification:
    emails:
      - abc@example.com

Interpretowanie wyników monitorowania

Po skonfigurowaniu monitora modelu i zakończeniu pierwszego uruchomienia możesz wrócić do karty Monitorowanie w usłudze Azure Machine Learning Studio, aby wyświetlić wyniki.

  • W widoku głównym Monitorowanie wybierz nazwę monitora modelu, aby wyświetlić stronę Przegląd monitorowania. Na tej stronie przedstawiono odpowiedni model, punkt końcowy i wdrożenie wraz ze szczegółami dotyczącymi skonfigurowanych sygnałów. Następny obraz przedstawia pulpit nawigacyjny monitorowania, który zawiera sygnały dryfu danych i jakości danych. W zależności od skonfigurowanych sygnałów monitorowania pulpit nawigacyjny może wyglądać inaczej.

    Zrzut ekranu przedstawiający pulpit nawigacyjny monitorowania.

  • Zapoznaj się z sekcją Powiadomienia pulpitu nawigacyjnego, aby zobaczyć, dla każdego sygnału, który funkcje naruszyły skonfigurowany próg dla odpowiednich metryk:

  • Wybierz data_drift, aby przejść do strony szczegółów dryfu danych. Na stronie szczegółów można zobaczyć wartość metryki dryfu danych dla każdej funkcji liczbowej i podzielonej na kategorie uwzględnionej w konfiguracji monitorowania. Gdy monitor ma więcej niż jeden przebieg, zobaczysz linię trendu dla każdej funkcji.

    Zrzut ekranu przedstawiający stronę szczegółów sygnału dryfu danych.

  • Aby wyświetlić szczegółowo poszczególne funkcje, wybierz nazwę funkcji, aby wyświetlić dystrybucję produkcyjną w porównaniu z dystrybucją referencyjną. Ten widok umożliwia również śledzenie dryfu w czasie dla tej konkretnej funkcji.

    Zrzut ekranu przedstawiający szczegóły dryfu danych dla poszczególnych funkcji.

  • Wróć do pulpitu nawigacyjnego monitorowania i wybierz pozycję data_quality , aby wyświetlić stronę sygnału jakości danych. Na tej stronie można zobaczyć współczynniki wartości null, wartości poza granicami i współczynniki błędów typu danych dla każdej monitorowanej funkcji.

    Zrzut ekranu przedstawiający stronę szczegółów sygnału jakości danych.

Monitorowanie modelu jest procesem ciągłym. Dzięki monitorowaniu modelu usługi Azure Machine Learning można skonfigurować wiele sygnałów monitorowania w celu uzyskania szerokiego wglądu w wydajność modeli w środowisku produkcyjnym.

Integrowanie monitorowania modelu usługi Azure Machine Learning z usługą Azure Event Grid

Zdarzenia generowane przez monitorowanie modelu usługi Azure Machine Learning umożliwiają konfigurowanie aplikacji, procesów lub przepływów pracy ciągłej integracji/ciągłego wdrażania za pomocą usługi Azure Event Grid. Zdarzenia można używać za pośrednictwem różnych programów obsługi zdarzeń, takich jak Azure Event Hubs, Azure Functions i Logic Apps. Na podstawie dryfu wykrytego przez monitory można podjąć działania programowo, takie jak skonfigurowanie potoku uczenia maszynowego w celu ponownego wytrenowania modelu i jego ponownego wdrożenia.

Aby rozpocząć integrowanie monitorowania modelu usługi Azure Machine Learning z usługą Event Grid:

  1. Wykonaj kroki opisane w temacie Konfigurowanie w witrynie Azure Portal. Nadaj subskrypcji zdarzeń nazwę, taką jak MonitoringEvent, i wybierz tylko pole Stan uruchomienia zmienione w obszarze Typy zdarzeń.

    Ostrzeżenie

    Pamiętaj, aby wybrać pozycję Stan uruchomienia zmieniony dla typu zdarzenia. Nie wybieraj pozycji Wykryto dryf zestawu danych, ponieważ dotyczy to dryfu danych w wersji 1, a nie monitorowania modelu usługi Azure Machine Learning.

  2. Wykonaj kroki opisane w temacie Filtrowanie i subskrybowanie zdarzeń , aby skonfigurować filtrowanie zdarzeń dla danego scenariusza. Przejdź do karty Filtry i dodaj następujący klucz, operator i wartość w obszarze Filtry zaawansowane:

    • Klucz: data.RunTags.azureml_modelmonitor_threshold_breached
    • Wartość: nie powiodło się z powodu co najmniej jednej funkcji naruszającej progi metryk
    • Operator: Ciąg zawiera

    Dzięki temu filtrowi zdarzenia są generowane, gdy stan uruchomienia zmieni się (z Ukończono na Niepowodzenie lub Zakończone) dla dowolnego monitora w obszarze roboczym usługi Azure Machine Learning.

  3. Aby filtrować na poziomie monitorowania, użyj następującego klucza, operatora i wartości w obszarze Filtry zaawansowane:

    • Klucz: data.RunTags.azureml_modelmonitor_threshold_breached
    • Wartość: your_monitor_name_signal_name
    • Operator: Ciąg zawiera

    Upewnij się, że your_monitor_name_signal_name jest to nazwa sygnału w określonym monitorze, dla którego chcesz filtrować zdarzenia. Na przykład credit_card_fraud_monitor_data_drift. Aby ten filtr działał, ten ciąg musi być zgodny z nazwą sygnału monitorowania. Należy nazwać sygnał zarówno nazwą monitora, jak i nazwą sygnału dla tego przypadku.

  4. Po zakończeniu konfiguracji subskrypcji zdarzeń wybierz żądany punkt końcowy, który będzie służyć jako program obsługi zdarzeń, taki jak Azure Event Hubs.

  5. Po przechwyceniu zdarzeń można je wyświetlić na stronie punktu końcowego:

    Zrzut ekranu przedstawiający zdarzenia wyświetlane ze strony punktu końcowego.

Zdarzenia można również wyświetlić na karcie Metryki usługi Azure Monitor:

Zrzut ekranu przedstawiający zdarzenia wyświetlane na karcie metryki usługi Azure Monitor.

Powiązana zawartość