InfraValidator est un composant TFX qui est utilisé comme couche d'alerte précoce avant de pousser 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 desservant « l'infrastructure ». Si Evaluator est de garantir la performance du modèle, InfraValidator est de garantir le modèle est mécaniquement fine et empêche les mauvais modèles d'être poussé.
Comment ça marche?
InfraValidator prend le modèle, lance un serveur de modèle en bac à sable avec le modèle et voit s'il peut être chargé avec succès et éventuellement interrogé. Le résultat infra de validation sera généré dans la blessing sortie de la même manière que Evaluator fait.
InfraValidator met l' accent sur la compatibilité entre le binaire du serveur modèle (par exemple tensorflow service ) et le modèle à déployer. Malgré le nom « infra » validateur, il est de la responsabilité de l'utilisateur de configurer l'environnement correctement, et infra validateur seulement interagit avec le serveur de modèle dans l'environnement configuré par l' utilisateur pour voir si cela fonctionne bien. La configuration correcte de cet environnement garantira que la réussite ou l'échec de la validation infra indiquera si le modèle sera utilisable dans l'environnement de production. Cela implique certains des éléments suivants, sans s'y limiter :
- 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 d'infra doit converger.
- InfraValidator utilise les mêmes ressources (par exemple, la quantité allouée et le type de CPU, de mémoire et d'accélérateurs) que celles qui seront utilisées en production.
- InfraValidator utilise le même modèle de configuration de serveur que celui qui sera utilisé en production.
Selon la situation, les utilisateurs peuvent choisir dans quelle mesure InfraValidator doit être identique à l'environnement de production. Techniquement, un modèle peut être infra validé 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 se fait dans l'un des modes suivants :
-
LOAD_ONLYMode: vérifier si le modèle a été chargé avec succès dans l'infrastructure au service ou non. OU -
LOAD_AND_QUERYMode:LOAD_ONLYMode , plus envoyer des demandes échantillon pour vérifier si le modèle est capable de servir des conclusions. InfraValidator ne se soucie pas que la prédiction soit correcte ou non. Seul le fait que la demande ait abouti ou non importe.
Comment l'utiliser ?
Généralement, 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 la InfraValidator. Il définit :
- quel type de serveur modèle à terme
- où l' exécuter
Pour les types de serveurs modèles (appelés binaires de service), nous prenons en charge
Les plates-formes de diffusion 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 pour servir la plate - forme binaire et le service sont faites en spécifiant un oneof bloc du ServingSpec . Par exemple , pour utiliser tensorflow service binaire fonctionnement sur le cluster Kubernetes, tensorflow_serving et kubernetes champ doit être défini.
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 d' autres ServingSpec , s'il vous plaît vérifier la définition de protobuf .
ValidationSpec
Configuration optionnelle 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 correcte. Voir plus de détails de la définition de protobuf .
RequestSpec
Configuration facultative pour spécifier comment construire les demandes d'échantillons lors de l' exécution infra validation en LOAD_AND_QUERY le mode. Pour utiliser LOAD_AND_QUERY mode, il est nécessaire de préciser les request_spec propriétés d'exécution ainsi que des examples canal d'entrée dans la définition de 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.
)
)
Production d'un modèle enregistré avec échauffement
(À partir de la version 0.30.0)
Depuis le modèle de InfraValidator aux demandes réelles, il peut facilement réutiliser ces demandes de validation que les demandes de warm - up d'un SavedModel. InfraValidator fournit une option ( RequestSpec.make_warmup ) pour exporter un SavedModel avec warm - up.
infra_validator = InfraValidator(
...,
request_spec=tfx.proto.RequestSpec(..., make_warmup=True)
)
Ensuite , la sortie InfraBlessing artefact contiendra un SavedModel avec warm - up, et peut également être poussé par le Pusher , tout comme le Model artefact.
Limites
L'InfraValidator actuel n'est pas encore terminé et présente certaines limitations.
- Seulement tensorflow SavedModel format modèle peut être validé.
- Lors de l' exécution TFX sur Kubernetes, le pipeline doit être exécuté par
KubeflowDagRunnerà l' intérieur Kubeflow Pipelines. Le serveur de modèle sera lancé dans le même cluster Kubernetes et dans l'espace de noms que Kubeflow utilise. - InfraValidator se concentre principalement sur les déploiements à tensorflow Au service , et utile tout en elle est moins précise pour les déploiements à tensorflow Lite et TensorFlow.js , ou d' autres cadres d'inférence.
Il y a un support limité sur
LOAD_AND_QUERYle mode pour la Prédire signature de la méthode (qui est la seule méthode exportables dans tensorflow 2). InfraValidator exige la signature Prédire de consommer une sérialisétf.Examplecomme la 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 Penguin exemple de code pour voir comment cela interagit avec d' autres composants signature dans TFX.