Treten Sie der SIG TFX-Addons-Community bei und helfen Sie, TFX noch besser zu machen!

Die InfraValidator TFX-Pipeline-Komponente

InfraValidator ist eine TFX-Komponente, die als Frühwarnschicht verwendet wird, bevor ein Modell in die Produktion gebracht wird. Der Name "Infra" -Validator kam von der Tatsache, dass das Modell in dem tatsächlichen Modell validiert wird, das der "Infrastruktur" dient. Wenn Evaluator die Leistung des Modells garantieren soll, soll InfraValidator sicherstellen, dass das Modell mechanisch in Ordnung ist und verhindert, dass fehlerhafte Modelle geschoben werden.

Wie funktioniert es?

InfraValidator nimmt das Modell, startet einen Sandbox-Modellserver mit dem Modell und prüft, ob es erfolgreich geladen und optional abgefragt werden kann. Die infra Prüfungsergebnis wird in dem erzeugt werden blessing Ausgang in der gleichen Weise wie Evaluator tut.

InfraValidator konzentriert sich auf die Kompatibilität zwischen der Modellserver-Binärdatei (z. B. TensorFlow Serving ) und dem zu implementierenden Modell. Trotz des Namens "Infra" -Validator liegt es in der Verantwortung des Benutzers , die Umgebung korrekt zu konfigurieren. Der Infra-Validator interagiert nur mit dem Modellserver in der vom Benutzer konfigurierten Umgebung, um festzustellen, ob er ordnungsgemäß funktioniert. Durch die korrekte Konfiguration dieser Umgebung wird sichergestellt, dass das Bestehen oder Nichtbestehen der Infra-Validierung anzeigt, ob das Modell in der Produktions-Serving-Umgebung gewartet werden kann. Dies impliziert einige der folgenden, ist aber nicht darauf beschränkt:

  1. InfraValidator verwendet dieselbe Modellserver-Binärdatei, die in der Produktion verwendet wird. Dies ist die minimale Ebene, auf die die Infra-Validierungsumgebung konvergieren muss.
  2. InfraValidator verwendet dieselben Ressourcen (z. B. Zuordnungsmenge und Typ der CPU, des Speichers und der Beschleuniger) wie in der Produktion.
  3. InfraValidator verwendet dieselbe Modellserverkonfiguration wie in der Produktion.

Je nach Situation können Benutzer auswählen, inwieweit InfraValidator mit der Produktionsumgebung identisch sein soll. Technisch gesehen kann ein Modell in einer lokalen Docker-Umgebung infra-validiert und dann problemlos in einer völlig anderen Umgebung (z. B. Kubernetes-Cluster) bereitgestellt werden. InfraValidator hat diese Abweichung jedoch nicht überprüft.

Betriebsmodus

Abhängig von der Konfiguration erfolgt die Infra-Validierung in einem der folgenden Modi:

  • LOAD_ONLY Modus: Überprüft, ob das Modell erfolgreich in die Serving-Infrastruktur geladen wurde oder nicht. ODER
  • LOAD_AND_QUERY Modus: LOAD_ONLY Modus sowie Senden einiger Beispielanforderungen, um zu überprüfen, ob das Modell Schlussfolgerungen LOAD_ONLY kann. InfraValidator ist es egal, ob die Vorhersage korrekt war oder nicht. Nur ob die Anfrage erfolgreich war oder nicht.

Wie benutze ich es?

Normalerweise wird InfraValidator neben einer Evaluator-Komponente definiert und seine Ausgabe wird einem Drücker zugeführt. Wenn InfraValidator fehlschlägt, wird das Modell nicht gepusht.

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

Konfigurieren einer InfraValidator-Komponente.

Es gibt drei Arten von Protos, um InfraValidator zu konfigurieren.

ServingSpec

ServingSpec ist die wichtigste Konfiguration für den InfraValidator. Es definiert:

  • welche Art von Modellserver ausgeführt werden soll
  • wo man es laufen lässt

Für Modellservertypen (Serving Binary genannt) unterstützen wir

Folgende Serving-Plattformen werden derzeit unterstützt:

  • Lokaler Docker (Docker sollte im Voraus installiert werden)
  • Kubernetes (nur eingeschränkte Unterstützung für KubeflowDagRunner)

Die Wahl für die binäre dient , und Serving - Plattform werden durch einen Spezifizierungs oneof Block des ServingSpec . Um beispielsweise die im Kubernetes-Cluster tensorflow_serving TensorFlow Serving-Binärdatei zu verwenden, tensorflow_serving kubernetes tensorflow_serving und kubernetes festgelegt werden.

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

Weitere ServingSpec zum Konfigurieren von ServingSpec finden Sie in der Protobuf-Definition .

ValidationSpec

Optionale Konfiguration zum Anpassen der Infra-Validierungskriterien oder des Workflows.

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

Alle ValidationSpec-Felder haben einen Standardwert. Weitere Details finden Sie in der Protobuf-Definition .

RequestSpec

Optionale Konfiguration, um anzugeben, wie Beispielanforderungen erstellt werden sollen, wenn die Infra-Validierung im LOAD_AND_QUERY Modus ausgeführt wird. Um den LOAD_AND_QUERY Modus verwenden zu können, müssen sowohl request_spec Ausführungseigenschaften von request_spec als auch examples Eingabekanal in der Komponentendefinition angegeben werden.

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

Einschränkungen

Der aktuelle InfraValidator ist noch nicht vollständig und weist einige Einschränkungen auf.

  • Es kann nur das TensorFlow SavedModel- Modellformat validiert werden.
  • Wenn Sie TFX auf Kubernetes KubeflowDagRunner , sollte die Pipeline von KubeflowDagRunner in Kubeflow-Pipelines ausgeführt werden. Der Modellserver wird im selben Kubernetes-Cluster und im von Kubeflow verwendeten Namespace gestartet.
  • InfraValidator konzentriert sich hauptsächlich auf Bereitstellungen in TensorFlow Serving. Obwohl es immer noch nützlich ist, ist es für Bereitstellungen in TensorFlow Lite und TensorFlow.js oder anderen Inferenz-Frameworks weniger genau.
  • Der LOAD_AND_QUERY Modus unterstützt die Predict- Methodensignatur (die einzige exportierbare Methode in TensorFlow 2) nur eingeschränkt. InfraValidator erfordert, dass die Predict-Signatur ein serialisiertes tf.Example als einzige Eingabe verwendet.

    @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'))
    })