¡Únase a la comunidad de SIG TFX-Addons y ayude a que TFX sea aún mejor!

El componente de canalización InfraValidator TFX

InfraValidator es un componente TFX que se utiliza como una capa de alerta temprana antes de llevar un modelo a producción. El nombre de validador "infra" proviene del hecho de que está validando el modelo en el modelo real que sirve a la "infraestructura". Si Evaluator va a garantizar el rendimiento del modelo, InfraValidator garantizará que el modelo sea mecánicamente correcto y evitará que se empujen modelos defectuosos.

¿Como funciona?

InfraValidator toma el modelo, lanza un servidor de modelos en caja de arena con el modelo y ve si se puede cargar correctamente y, opcionalmente, consultar. El resultado de la infravalidación se generará en la salida de 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 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 asegurará que la validación de infra que pase o falle sea indicativo de si el modelo podría ser útil en el entorno de servicio de producción. Esto implica algunos de, entre otros, los siguientes:

  1. InfraValidator está utilizando 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.
  2. InfraValidator está usando los mismos recursos (por ejemplo, cantidad de asignación y tipo de CPU, memoria y aceleradores) que se usarán en producción.
  3. InfraValidator está utilizando 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 se puede validar infra en un entorno Docker local y luego servir en un entorno completamente diferente (por ejemplo, un clúster de Kubernetes) sin ningún problema. Sin embargo, InfraValidator no habrá verificado esta divergencia.

Modo de operación

Dependiendo de la configuración, la validación de infra 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 : modo LOAD_ONLY más el envío de algunas solicitudes de muestra para verificar si el modelo es capaz de servir inferencias. A InfraValidator no le importa que la predicción sea correcta o no. Solo importa si la solicitud fue exitosa o no.

¿Como 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 enviará.

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(...)
)

Configuración de un componente InfraValidator.

Hay tres tipos de protos para configurar InfraValidator.

ServingSpec

ServingSpec es la configuración más crucial para InfraValidator. Se define:

  • qué tipo de servidor modelo ejecutar
  • donde ejecutarlo

Para los tipos de servidor modelo (llamado servidor binario) admitimos

Actualmente se admiten las siguientes plataformas de servicio:

  • Local Docker (Docker debe instalarse de antemano)
  • Kubernetes (soporte limitado solo para KubeflowDagRunner)

La elección para servir binario y sirviendo plataforma se hacen mediante la especificación de un oneof de bloques de la ServingSpec . Por ejemplo, para usar el binario TensorFlow Serving que se ejecuta en el clúster de tensorflow_serving , se deben configurar tensorflow_serving y kubernetes .

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

Para configurar más ServingSpec , consulte la definición de protobuf .

ValidationSpec

Configuración opcional para ajustar los criterios de validación de infra o flujo de trabajo.

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
    )
)

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 el 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 de 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=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.
    )
)

Limitaciones

El InfraValidator actual aún no está completo y tiene algunas limitaciones.

  • Solo se puede validar el formato de modelo de modelo guardado de TensorFlow.
  • Al ejecutar TFX en Kubernetes, KubeflowDagRunner debe ejecutar la KubeflowDagRunner dentro de Kubeflow Pipelines. El servidor modelo se lanzará en el mismo clúster de Kubernetes y en el espacio de nombres que usa 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 una compatibilidad limitada en el modo LOAD_AND_QUERY para la firma del método Predict (que es el único método exportable en TensorFlow 2). InfraValidator requiere la firma Predict para consumir un tf.Example serializado. tf.Example 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 ejemplo de Penguin para ver cómo esta firma interactúa con otros componentes en TFX.