Le composant de pipeline InfraValidator TFX

InfraValidator est un composant TFX utilisé comme couche d'alerte précoce avant de mettre un modèle en production. Le nom de validateur « infra » vient du fait qu'il valide le modèle dans le modèle réel au service de « l'infrastructure ». Si Evaluator doit garantir les performances du modèle, InfraValidator doit garantir que le modèle est mécaniquement en bon état et empêcher que de mauvais modèles ne soient poussés.

Comment ça marche ?

InfraValidator prend le modèle, lance un serveur de modèles en bac à sable avec le modèle et voit s'il peut être chargé avec succès et éventuellement interrogé. Le résultat de la validation infra sera généré dans la sortie blessing de la même manière que le fait l'évaluateur .

InfraValidator se concentre sur la compatibilité entre le binaire du serveur de modèle (par exemple TensorFlow Serving ) et le modèle à déployer. Malgré le nom de validateur « infra », il est de la responsabilité de l'utilisateur de configurer correctement l'environnement, et le validateur infra interagit uniquement avec le serveur de modèles dans l'environnement configuré par l'utilisateur pour voir s'il fonctionne correctement. La configuration correcte de cet environnement garantira que la réussite ou l'échec de la validation infra indiquera si le modèle serait utilisable dans l'environnement de production. Cela implique certains des éléments suivants, sans toutefois s'y limiter :

1. InfraValidator utilise le même modèle binaire de serveur que celui qui sera utilisé en production. C’est le niveau minimal vers lequel l’environnement de validation infra doit converger.
2. InfraValidator utilise les mêmes ressources (par exemple, quantité d'allocation et type de processeur, mémoire et accélérateurs) que celles utilisées en production.
3. InfraValidator utilise la même configuration de serveur modèle que celle utilisée en production.

En fonction de la situation, les utilisateurs peuvent choisir dans quelle mesure InfraValidator doit être identique à l'environnement de production. Techniquement, un modèle peut être validé infra dans un environnement Docker local puis servi dans un environnement complètement différent (par exemple un cluster Kubernetes) sans problème. Cependant, InfraValidator n'aura pas vérifié cette divergence.

Mode de fonctionnement

Selon la configuration, la validation infra s'effectue dans l'un des modes suivants :

• Mode LOAD_ONLY : vérifier si le modèle a été chargé avec succès dans l'infrastructure de desserte ou non. OU
• Mode LOAD_AND_QUERY : mode LOAD_ONLY et envoi de quelques exemples de requêtes pour vérifier si le modèle est capable de servir des inférences. InfraValidator ne se soucie pas de savoir si la prédiction était correcte ou non. Seul le fait que la demande ait abouti ou non compte.

Comment puis-je l'utiliser ?

Habituellement, InfraValidator est défini à côté d'un composant Evaluator et sa sortie est transmise à un Pusher. Si InfraValidator échoue, le modèle ne sera pas poussé.

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

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

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

Configuration d'un composant InfraValidator.

Il existe trois types de protos pour configurer InfraValidator.

ServingSpec

ServingSpec est la configuration la plus cruciale pour InfraValidator. Il définit :

• quel type de serveur de modèles exécuter
• où l'exécuter

Pour les types de serveurs modèles (appelés serveur binaire), nous prenons en charge

• Service TensorFlow

Remarque : InfraValidator permet de spécifier plusieurs versions du même type de serveur de modèles afin de mettre à niveau la version du serveur de modèles sans affecter la compatibilité du modèle. Par exemple, l'utilisateur peut tester l'image tensorflow/serving avec la version 2.1.0 et latest versions, pour s'assurer que le modèle sera également compatible avec la dernière version tensorflow/serving .

Les plates-formes de service suivantes sont actuellement prises en charge :

• Docker local (Docker doit être installé à l'avance)
• Kubernetes (prise en charge limitée de KubeflowDagRunner uniquement)

Le choix du serveur binaire et de la plate-forme de service est effectué en spécifiant un bloc oneof de ServingSpec . Par exemple, pour utiliser le binaire TensorFlow Serving exécuté sur le cluster Kubernetes, les champs tensorflow_serving et kubernetes doivent être définis.

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

Pour configurer davantage ServingSpec , veuillez consulter la définition de protobuf .

ValidationSpec

Configuration facultative pour ajuster les critères de validation infra ou le workflow.

infra_validator=InfraValidator(
    model=trainer.outputs['model'],
    serving_spec=tfx.proto.ServingSpec(...),
    validation_spec=tfx.proto.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
    )
)

Tous les champs ValidationSpec ont une valeur par défaut solide. Vérifiez plus de détails dans la définition de protobuf .

RequestSpec

Configuration facultative pour spécifier comment créer des exemples de requêtes lors de l'exécution de la validation infra en mode LOAD_AND_QUERY . Afin d'utiliser le mode LOAD_AND_QUERY , il est nécessaire de spécifier à la fois les propriétés d'exécution request_spec ainsi que examples de canal d'entrée dans la définition du composant.

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=tfx.proto.ServingSpec(
        # Depending on what kind of model server you're using, RequestSpec
        # should specify the compatible one.
        tensorflow_serving=tfx.proto.TensorFlowServing(tags=['latest']),
        local_docker=tfx.proto.LocalDockerConfig(),
    ),
    request_spec=tfx.proto.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=tfx.proto.TensorFlowServingRequestSpec(
            signature_names=['classification']
        ),
        num_examples=10  # How many requests to make.
    )
)

Produire un SavedModel avec échauffement

(À partir de la version 0.30.0)

Étant donné qu'InfraValidator valide le modèle avec des requêtes réelles, il peut facilement réutiliser ces requêtes de validation comme requêtes de préchauffage d'un SavedModel. InfraValidator fournit une option ( RequestSpec.make_warmup ) pour exporter un SavedModel avec échauffement.

infra_validator = InfraValidator(
    ...,
    request_spec=tfx.proto.RequestSpec(..., make_warmup=True)
)

Ensuite, l'artefact InfraBlessing de sortie contiendra un SavedModel avec échauffement, et pourra également être poussé par le Pusher , tout comme l'artefact Model .

Limites

L'InfraValidator actuel n'est pas encore terminé et présente certaines limites.

• Seul le format de modèle TensorFlow SavedModel peut être validé.
• Lors de l'exécution de TFX sur Kubernetes, le pipeline doit être exécuté par KubeflowDagRunner dans Kubeflow Pipelines. Le serveur modèle sera lancé dans le même cluster Kubernetes et le même espace de noms que Kubeflow utilise.
• InfraValidator se concentre principalement sur les déploiements vers TensorFlow Serving , et bien qu'il reste utile, il est moins précis pour les déploiements vers TensorFlow Lite et TensorFlow.js , ou d'autres frameworks d'inférence.

• Il existe une prise en charge limitée en mode LOAD_AND_QUERY pour la signature de la méthode Predict (qui est la seule méthode exportable dans TensorFlow 2). InfraValidator nécessite que la signature Predict consomme un tf.Example sérialisé comme seule entrée.

  @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'))
  })
  

  • Consultez un exemple de code Penguin pour voir comment cette signature interagit avec d'autres composants dans TFX.