Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Il componente della pipeline TFX di InfraValidator

InfraValidator è un componente TFX che viene utilizzato come strato di allarme rapido prima di mettere in produzione un modello. Il nome "infra" validator deriva dal fatto che sta convalidando il modello nell'attuale modello che serve "infrastruttura". Se il Valutatore deve garantire le prestazioni del modello, InfraValidator deve garantire che il modello funzioni meccanicamente bene e previene la spinta di modelli difettosi.

Come funziona?

InfraValidator prende il modello, avvia un modello di server in sandbox con il modello e vede se può essere caricato correttamente e facoltativamente richiesto. Il risultato della convalida infra sarà generato nell'output di blessing allo stesso modo del Valutatore .

InfraValidator si concentra sulla compatibilità tra il binario del server modello (ad es. TensorFlow Serving ) e il modello da distribuire. Nonostante il nome "infra" validator, è responsabilità dell'utente configurare correttamente l'ambiente, e infra validator interagisce solo con il server modello nell'ambiente configurato dall'utente per vedere se funziona bene. La corretta configurazione di questo ambiente garantirà che il superamento o il fallimento della convalida infra sia indicativo se il modello sarebbe utilizzabile nell'ambiente di servizio della produzione. Ciò implica alcuni dei seguenti, ma non è limitato a:

  1. InfraValidator utilizza lo stesso modello binario del server utilizzato nella produzione. Questo è il livello minimo a cui deve convergere l'ambiente di validazione dell'infrarosso.
  2. InfraValidator utilizza le stesse risorse (ad es. Quantità e tipo di allocazione di CPU, memoria e acceleratori) che verranno utilizzate nella produzione.
  3. InfraValidator utilizza la stessa configurazione del server modello utilizzata nella produzione.

A seconda della situazione, gli utenti possono scegliere in che misura InfraValidator dovrebbe essere identico all'ambiente di produzione. Tecnicamente, un modello può essere infra validato in un ambiente Docker locale e quindi servito in un ambiente completamente diverso (es. Cluster Kubernetes) senza problemi. Tuttavia, InfraValidator non avrà verificato questa divergenza.

Modalità di funzionamento

A seconda della configurazione, la convalida a infrarossi viene eseguita in una delle seguenti modalità:

  • Modalità LOAD_ONLY : verifica se il modello è stato caricato correttamente nell'infrastruttura di servizio o meno. O
  • Modalità LOAD_AND_QUERY : modalità LOAD_ONLY oltre all'invio di alcune richieste di esempio per verificare se il modello è in grado di fornire inferenze. InfraValidator non si preoccupa che la previsione sia corretta o meno. È importante solo se la richiesta ha avuto esito positivo o meno.

Come lo uso?

Di solito InfraValidator viene definito accanto a un componente Valutatore e il suo output viene inviato a un Pusher. Se InfraValidator fallisce, il modello non verrà spinto.

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

Configurazione di un componente InfraValidator.

Esistono tre tipi di proto per configurare InfraValidator.

ServingSpec

ServingSpec è la configurazione più cruciale per InfraValidator. Definisce:

  • quale tipo di server modello eseguire
  • dove eseguirlo

Per i tipi di server modello (chiamati servizio binario) supportiamo

Sono attualmente supportate le seguenti piattaforme di servizio:

  • Docker locale (Docker deve essere installato in anticipo)
  • Kubernetes (supporto limitato solo per KubeflowDagRunner)

La scelta per servire binario e servire piattaforma sono realizzati specificando un oneof blocchi del ServingSpec . Ad esempio, per utilizzare TensorFlow che serve binario in esecuzione sul cluster tensorflow_serving , è tensorflow_serving kubernetes campo tensorflow_serving e kubernetes .

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

Per configurare ulteriormente ServingSpec , controlla la definizione di protobuf .

ValidationSpec

Configurazione opzionale per regolare i criteri o il flusso di lavoro a infrarossi.

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

Tutti i campi ValidationSpec hanno un valore predefinito audio. Controlla maggiori dettagli dalla definizione di protobuf .

RequestSpec

Configurazione facoltativa per specificare come LOAD_AND_QUERY richieste di esempio quando si esegue la convalida a infrarossi in modalità LOAD_AND_QUERY . Per utilizzare la modalità LOAD_AND_QUERY , è necessario specificare sia le proprietà di esecuzione request_spec sia gli examples canale di input nella definizione 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.
    )
)
 

limitazioni

InfraValidator corrente non è ancora completo e presenta alcune limitazioni.

  • È possibile convalidare solo il formato del modello TensorFlow SavedModel .
  • Quando si esegue TFX su Kubernetes, la pipeline deve essere eseguita da KubeflowDagRunner all'interno delle pipeline di Kubeflow. Il server modello verrà avviato nello stesso cluster Kubernetes e nello spazio dei nomi utilizzato da Kubeflow.
  • InfraValidator si concentra principalmente sulle distribuzioni su TensorFlow Serving e, sebbene utile, è meno preciso per le distribuzioni su TensorFlow Lite e TensorFlow.js o altri framework di inferenza.
  • C'è un supporto limitato sulla modalità LOAD_AND_QUERY per la firma del metodo Predict (che è l'unico metodo esportabile in TensorFlow 2). InfraValidator richiede che la firma Predict utilizzi un tf.Example serializzato, ad tf.Example come unico input.
 @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'))
})
 
 -   Check out an
    [Iris example](https://github.com/tensorflow/tfx/blob/master/tfx/examples/iris/iris_utils_native_keras.py)
    sample code to see how this signature interacts with other components in
    TFX.