InfraValidator es un componente TFX que se utiliza como capa de alerta temprana antes de llevar un modelo a producción. El nombre de validador "infra" proviene del hecho de que valida el modelo en el modelo real que sirve a la "infraestructura". Si Evaluator debe garantizar el rendimiento del modelo, InfraValidator debe garantizar que el modelo esté mecánicamente bien y evite que se impulsen modelos defectuosos.
¿Cómo funciona?
InfraValidator toma el modelo, inicia un servidor de modelo en un espacio aislado con el modelo y comprueba si se puede cargar correctamente y, opcionalmente, consultarlo. El resultado de la infravalidación se generará en la salida blessing de la misma manera que lo hace el Evaluador .
InfraValidator se centra en la compatibilidad entre el modelo binario del servidor (por ejemplo, TensorFlow Serving ) y el modelo a implementar. A pesar del nombre de validador "infra", es responsabilidad del usuario configurar el entorno correctamente, y el validador infra solo interactúa con el servidor modelo en el entorno configurado por el usuario para ver si funciona bien. La configuración correcta de este entorno garantizará que la aprobación o el fracaso de la validación de infraestructura sea indicativo de si el modelo se podrá utilizar en el entorno de producción. Esto implica algo de lo siguiente, entre otros:
- InfraValidator utiliza el mismo modelo binario de servidor que se utilizará en producción. Este es el nivel mínimo al que debe converger el entorno de infravalidación.
- InfraValidator utiliza los mismos recursos (por ejemplo, cantidad de asignación y tipo de CPU, memoria y aceleradores) que se utilizarán en producción.
- InfraValidator utiliza la misma configuración de servidor modelo que se utilizará en producción.
Dependiendo de la situación, los usuarios pueden elegir hasta qué punto InfraValidator debe ser idéntico al entorno de producción. Técnicamente, un modelo puede validarse infra en un entorno Docker local y luego servirse en un entorno completamente diferente (por ejemplo, un clúster de Kubernetes) sin problemas. Sin embargo, InfraValidator no habrá comprobado esta divergencia.
Modo de operación
Dependiendo de la configuración, la infravalidación se realiza en uno de los siguientes modos:
- Modo
LOAD_ONLY: comprobar si el modelo se cargó correctamente en la infraestructura de servicio o no. O - Modo
LOAD_AND_QUERY: modoLOAD_ONLYmás el envío de algunas solicitudes de muestra para comprobar si el modelo es capaz de realizar inferencias. A InfraValidator no le importa si la predicción fue correcta o no. Sólo importa si la solicitud fue exitosa o no.
¿Cómo lo uso?
Por lo general, InfraValidator se define junto a un componente Evaluator y su salida se envía a un Pusher. Si InfraValidator falla, el modelo no se impulsará.
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(...)
)
Configuración de un componente InfraValidator.
Hay tres tipos de protos para configurar InfraValidator.
ServingSpec
ServingSpec es la configuración más importante para InfraValidator. Define:
- qué tipo de servidor modelo ejecutar
- donde ejecutarlo
Para los tipos de servidores modelo (llamados servidores binarios) admitimos
Actualmente se admiten las siguientes plataformas de servicio:
- Docker local (Docker debe instalarse con anticipación)
- Kubernetes (soporte limitado solo para KubeflowDagRunner)
La elección de servir binario y plataforma de servicio se realiza especificando un bloque oneof de ServingSpec . Por ejemplo, para utilizar el binario TensorFlow Serving ejecutándose en el clúster de Kubernetes, se deben configurar los campos tensorflow_serving y kubernetes .
infra_validator=InfraValidator(
model=trainer.outputs['model'],
serving_spec=tfx.proto.ServingSpec(
tensorflow_serving=tfx.proto.TensorFlowServing(
tags=['latest']
),
kubernetes=tfx.proto.KubernetesConfig()
)
)
Para configurar aún más ServingSpec , consulte la definición de protobuf .
ValidationSpec
Configuración opcional para ajustar los criterios de validación de infraestructura o el flujo de trabajo.
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
)
)
Todos los campos ValidationSpec tienen un valor predeterminado sólido. Consulte más detalles en la definición de protobuf .
RequestSpec
Configuración opcional para especificar cómo crear solicitudes de muestra cuando se ejecuta la validación de infraestructura en modo LOAD_AND_QUERY . Para utilizar el modo LOAD_AND_QUERY , es necesario especificar tanto las propiedades de ejecución request_spec como el canal de entrada examples en la definición del componente.
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.
)
)
Producir un modelo guardado con calentamiento
(Desde la versión 0.30.0)
Dado que InfraValidator valida el modelo con solicitudes reales, puede reutilizar fácilmente estas solicitudes de validación como solicitudes de preparación de un modelo guardado. InfraValidator proporciona una opción ( RequestSpec.make_warmup ) para exportar un modelo guardado con calentamiento.
infra_validator = InfraValidator(
...,
request_spec=tfx.proto.RequestSpec(..., make_warmup=True)
)
Luego, el artefacto InfraBlessing de salida contendrá un SavedModel con calentamiento y también puede ser impulsado por Pusher , al igual que el artefacto Model .
Limitaciones
El InfraValidator actual aún no está completo y tiene algunas limitaciones.
- Solo se puede validar el formato del modelo TensorFlow SavedModel .
- Al ejecutar TFX en Kubernetes,
KubeflowDagRunnerdebe ejecutar la canalización dentro de Kubeflow Pipelines. El servidor modelo se iniciará en el mismo clúster de Kubernetes y en el mismo espacio de nombres que utiliza Kubeflow. - InfraValidator se centra principalmente en implementaciones en TensorFlow Serving y, aunque sigue siendo útil, es menos preciso para implementaciones en TensorFlow Lite y TensorFlow.js u otros marcos de inferencia.
Hay soporte limitado en el modo
LOAD_AND_QUERYpara la firma del método Predict (que es el único método exportable en TensorFlow 2). InfraValidator requiere la firma Predict para consumir untf.Exampleserializado como única entrada.@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')) })- Consulte un código de muestra de Penguin para ver cómo interactúa esta firma con otros componentes en TFX.