Komponent InfraValidator TFX Pipeline

InfraValidator to składnik TFX, który jest używany jako warstwa wczesnego ostrzegania przed wprowadzeniem modelu do produkcji. Nazwa walidator „infra” wzięła się stąd, że waliduje on model w rzeczywistym modelu obsługującym „infrastrukturę”. Jeśli ewaluator ma zagwarantować wydajność modelu, InfraValidator ma zagwarantować, że model jest mechanicznie w porządku i zapobiega wypychaniu złych modeli.

Jak to działa?

InfraValidator pobiera model, uruchamia serwer modelu w piaskownicy z modelem i sprawdza, czy można go pomyślnie załadować i opcjonalnie odpytać. Wynik walidacji infra zostanie wygenerowany w wyniku blessing w taki sam sposób, jak robi to Evaluator .

InfraValidator koncentruje się na kompatybilności między binarnym modelem serwera (np. TensorFlow Serving ) a modelem do wdrożenia. Pomimo nazwy „infra” walidator, użytkownik jest odpowiedzialny za prawidłowe skonfigurowanie środowiska, a walidator infra współpracuje tylko z serwerem modelowym w środowisku skonfigurowanym przez użytkownika, aby sprawdzić, czy działa poprawnie. Prawidłowe skonfigurowanie tego środowiska zapewni, że pomyślna lub niepomyślna walidacja infra będzie wskazywać, czy model będzie obsługiwany w produkcyjnym środowisku obsługującym. Oznacza to, między innymi, następujące kwestie:

InfraValidator używa tego samego pliku binarnego serwera modelu, który będzie używany w produkcji. Jest to minimalny poziom, do którego musi zbiegać się środowisko walidacji w podczerwieni.
InfraValidator wykorzystuje te same zasoby (np. Ilość alokacji i typ procesora, pamięć i akceleratory), które będą używane w produkcji.
InfraValidator używa tej samej konfiguracji serwera modelu, która będzie używana w produkcji.

W zależności od sytuacji użytkownicy mogą wybrać, w jakim stopniu InfraValidator ma być identyczny ze środowiskiem produkcyjnym. Technicznie model może zostać poddany walidacji infra w lokalnym środowisku Dockera, a następnie bez problemu obsługiwany w zupełnie innym środowisku (np. Klastrze Kubernetes). Jednak InfraValidator nie będzie sprawdzać tej rozbieżności.

Tryb pracy

W zależności od konfiguracji walidacja infra odbywa się w jednym z następujących trybów:

Tryb LOAD_ONLY : sprawdzanie, czy model został pomyślnie załadowany do infrastruktury obsługującej, czy nie. LUB
Tryb LOAD_AND_QUERY : tryb LOAD_ONLY plus wysyłanie przykładowych żądań, aby sprawdzić, czy model jest w stanie obsługiwać wnioski. InfraValidator nie dba o to, czy prognoza była poprawna, czy nie. Liczy się tylko to, czy żądanie się powiodło, czy nie.

Jak tego używam?

Zwykle InfraValidator jest definiowany obok komponentu Evaluator, a jego dane wyjściowe są przekazywane do Pusher. Jeśli InfraValidator zawiedzie, model nie zostanie przekazany.

evaluator = Evaluator(
    model=trainer.outputs['model'],
    examples=example_gen.outputs['examples'],
    baseline_model=model_resolver.outputs['model'],
    eval_config=EvalConfig(...)
)

infra_validator = InfraValidator(
    model=trainer.outputs['model'],
    serving_spec=ServingSpec(...)
)

pusher = Pusher(
    model=trainer.outputs['model'],
    model_blessing=evaluator.outputs['blessing'],
    infra_blessing=infra_validator.outputs['blessing'],
    push_destination=PushDestination(...)
)

Konfigurowanie składnika InfraValidator.

Istnieją trzy rodzaje protokołów do konfigurowania narzędzia InfraValidator.

`ServingSpec`

ServingSpec jest najważniejszą konfiguracją dla InfraValidator. Określa:

jaki typ serwera modelowego do uruchomienia
gdzie to uruchomić

Obsługujemy modele serwerów (zwane serwującymi binarnymi)

Obsługa TensorFlow

Obecnie obsługiwane są następujące platformy obsługujące:

Lokalny Docker (Docker powinien być zainstalowany wcześniej)
Kubernetes (ograniczona obsługa tylko KubeflowDagRunner)

Wyboru platformy obsługującej oneof binarne i platformy obsługującej dokonuje się, określając jeden z bloków specyfikacji ServingSpec . Na przykład, aby użyć pliku binarnego obsługi TensorFlow działającego w klastrze kubernetes należy ustawić pola tensorflow_serving i kubernetes .

infra_validator=InfraValidator(
    model=trainer.outputs['model'],
    serving_spec=ServingSpec(
        tensorflow_serving=TensorFlowServing(
            tags=['latest']
        ),
        kubernetes=KubernetesConfig()
    )
)

Aby dokładniej skonfigurować ServingSpec , zapoznaj się z definicją protobuf .

`ValidationSpec`

Opcjonalna konfiguracja w celu dostosowania kryteriów walidacji infra lub przepływu pracy.

infra_validator=InfraValidator(
    model=trainer.outputs['model'],
    serving_spec=ServingSpec(...),
    validation_spec=ValidationSpec(
        # How much time to wait for model to load before automatically making
        # validation fail.
        max_loading_time_seconds=60,
        # How many times to retry if infra validation fails.
        num_tries=3
    )
)

Wszystkie pola ValidationSpec mają domyślną wartość dźwiękową. Sprawdź więcej szczegółów z definicji protobuf .

`RequestSpec`

Opcjonalna konfiguracja, aby określić, jak budować przykładowe żądania podczas uruchamiania walidacji infra w trybie LOAD_AND_QUERY . Aby użyć trybu LOAD_AND_QUERY , wymagane jest określenie zarówno właściwości wykonania request_spec , jak i examples kanału wejściowego w definicji komponentu.

infra_validator = InfraValidator(
    model=trainer.outputs['model'],
    # This is the source for the data that will be used to build a request.
    examples=example_gen.outputs['examples'],
    serving_spec=ServingSpec(
        # Depending on what kind of model server you're using, RequestSpec
        # should specify the compatible one.
        tensorflow_serving=TensorFlowServing(tags=['latest']),
        local_docker=LocalDockerConfig(),
    ),
    request_spec=RequestSpec(
        # InfraValidator will look at how "classification" signature is defined
        # in the model, and automatically convert some samples from `examples`
        # artifact to prediction RPC requests.
        tensorflow_serving=TensorFlowServingRequestSpec(
            signature_names=['classification']
        ),
        num_examples=10  # How many requests to make.
    )
)

Ograniczenia

Obecny InfraValidator nie jest jeszcze ukończony i ma pewne ograniczenia.

Można zweryfikować tylko format modelu TensorFlow SavedModel .
Podczas uruchamiania TFX na Kubernetes potok powinien być wykonywany przez KubeflowDagRunner wewnątrz Kubeflow Pipelines. Serwer modelowy zostanie uruchomiony w tym samym klastrze Kubernetes i przestrzeni nazw, której używa Kubeflow.
InfraValidator koncentruje się głównie na wdrożeniach w TensorFlow Serving i chociaż nadal jest przydatny, jest mniej dokładny w przypadku wdrożeń w TensorFlow Lite i TensorFlow.js lub innych strukturach wnioskowania.

Istnieje ograniczone wsparcie na LOAD_AND_QUERY trybie do przewidzenia podpis metody (co jest jedynym sposobem eksportowalne w TensorFlow 2). InfraValidator wymaga podpisu Predict, aby korzystać z serializowanego tf.Example jako jedynego wejścia.

@tf.function
def parse_and_run(serialized_example):
  features = tf.io.parse_example(serialized_example, FEATURES)
  return model(features)

model.save('path/to/save', signatures={
  # This exports "Predict" method signature under name "serving_default".
  'serving_default': parse_and_run.get_concrete_function(
      tf.TensorSpec(shape=[None], dtype=tf.string, name='examples'))
})

Zapoznaj się z przykładowym kodem Penguin, aby zobaczyć, jak ten podpis współdziała z innymi składnikami TFX.