RSVP para seu evento TensorFlow Everywhere hoje mesmo!
Esta página foi traduzida pela API Cloud Translation.
Switch to English

O componente de pipeline do InfraValidator TFX

O InfraValidator é um componente TFX usado como uma camada de alerta antes de colocar um modelo em produção. O nome "infra" validador veio do fato de que ele está validando o modelo no modelo atual atendendo a "infraestrutura". Se o Avaliador deve garantir o desempenho do modelo, o InfraValidator deve garantir que o modelo está mecanicamente bem e evita que modelos ruins sejam empurrados.

Como funciona?

O InfraValidator pega o modelo, inicia um servidor de modelo sand-box com o modelo e vê se ele pode ser carregado com sucesso e opcionalmente consultado. O resultado da validação de infra será gerado na saída de blessing da mesma forma que o avaliador .

O InfraValidator se concentra na compatibilidade entre o binário do servidor de modelo (por exemplo, TensorFlow Serving ) e o modelo a ser implantado. Apesar do nome "infra" validador, é responsabilidade do usuário configurar o ambiente corretamente, e o infra validador só interage com o servidor do modelo no ambiente configurado pelo usuário para ver se funciona bem. A configuração correta deste ambiente garantirá que a aprovação ou reprovação da validação de infra-estrutura seja um indicativo de se o modelo pode ser servido no ambiente de serviço de produção. Isso implica alguns dos, mas não está limitado ao seguinte:

  1. O InfraValidator está usando o mesmo binário de servidor de modelo que será usado na produção. Este é o nível mínimo para o qual o ambiente de infra-validação deve convergir.
  2. O InfraValidator está usando os mesmos recursos (por exemplo, quantidade de alocação e tipo de CPU, memória e aceleradores) que serão usados ​​na produção.
  3. O InfraValidator está usando a mesma configuração de servidor de modelo que será usada na produção.

Dependendo da situação, os usuários podem escolher em que grau o InfraValidator deve ser idêntico ao ambiente de produção. Tecnicamente, um modelo pode ser infra-validado em um ambiente Docker local e, em seguida, servido em um ambiente completamente diferente (por exemplo, cluster Kubernetes) sem problemas. No entanto, o InfraValidator não terá verificado esta divergência.

Modo de operação

Dependendo da configuração, a infra-validação é feita em um dos seguintes modos:

  • Modo LOAD_ONLY : verificar se o modelo foi carregado com sucesso na infraestrutura de serviço ou não. OU
  • Modo LOAD_AND_QUERY : modo LOAD_ONLY mais o envio de algumas solicitações de amostra para verificar se o modelo é capaz de servir inferências. O InfraValidator não se importa se a previsão estava correta ou não. Apenas se a solicitação foi bem-sucedida ou não importa.

Como eu uso isso?

Normalmente, o InfraValidator é definido próximo a um componente do Avaliador e sua saída é alimentada para um Pusher. Se o InfraValidator falhar, o modelo não será enviado.

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

Configurando um componente InfraValidator.

Existem três tipos de protos para configurar o InfraValidator.

ServingSpec

ServingSpec é a configuração mais importante para o InfraValidator. Ele define:

  • que tipo de servidor modelo executar
  • onde executá-lo

Para tipos de servidor de modelo (chamados de binário servindo), oferecemos suporte

As seguintes plataformas de serviço são atualmente suportadas:

  • Docker local (o Docker deve ser instalado com antecedência)
  • Kubernetes (suporte limitado para KubeflowDagRunner apenas)

A escolha de servir a plataforma binária e servir é feita especificando-se oneof bloco do ServingSpec . Por exemplo, para usar o binário do TensorFlow Serving em execução no cluster tensorflow_serving , os tensorflow_serving e kubernetes devem ser definidos.

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

Para configurar melhor o ServingSpec , verifique a definição do protobuf .

ValidationSpec

Configuração opcional para ajustar os critérios de validação de infra ou fluxo de trabalho.

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 os campos ValidationSpec têm um valor padrão de som. Verifique mais detalhes na definição do protobuf .

RequestSpec

Configuração opcional para especificar como construir solicitações de amostra ao executar a validação de infra no modo LOAD_AND_QUERY . Para usar o modo LOAD_AND_QUERY , é necessário especificar as propriedades de execução request_spec , bem como o canal de entrada de examples na definição do 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.
    )
)

Limitações

O InfraValidator atual ainda não está completo e tem algumas limitações.

  • Apenas o formato do modelo TensorFlow SavedModel pode ser validado.
  • Ao executar TFX em Kubernetes, o pipeline deve ser executado por KubeflowDagRunner dentro de Kubeflow Pipelines. O servidor de modelo será iniciado no mesmo cluster Kubernetes e no namespace que o Kubeflow está usando.
  • O InfraValidator é focado principalmente em implantações para TensorFlow Serving e, embora ainda seja útil, é menos preciso para implantações para TensorFlow Lite e TensorFlow.js ou outras estruturas de inferência.
  • Há um suporte limitado no modo LOAD_AND_QUERY para a assinatura do método Predict (que é o único método exportável no TensorFlow 2). O InfraValidator requer a assinatura Predict para consumir um tf.Example serializado como a ú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'))
    })
    
    • Confira um exemplo de código do Penguin para ver como essa assinatura interage com outros componentes no TFX.