مكون خط أنابيب InfraValidator TFX

InfraValidator هو أحد مكونات TFX الذي يتم استخدامه كطبقة إنذار مبكر قبل دفع النموذج إلى الإنتاج. جاء اسم أداة التحقق من الصحة "infra" من حقيقة أنها تقوم بالتحقق من صحة النموذج في النموذج الفعلي الذي يخدم "البنية التحتية". إذا كان Evaluator هو ضمان أداء النموذج، فإن InfraValidator هو ضمان أن النموذج جيد ميكانيكيًا ويمنع دفع النماذج السيئة.

كيف يعمل؟

يأخذ InfraValidator النموذج، ويقوم بتشغيل خادم نموذجي مع النموذج، ويرى ما إذا كان من الممكن تحميله بنجاح والاستعلام عنه اختياريًا. سيتم إنشاء نتيجة التحقق من صحة الأشعة تحت الحمراء في مخرجات blessing بنفس الطريقة التي يفعلها المُقيم .

يركز InfraValidator على التوافق بين نموذج الخادم الثنائي (على سبيل المثال TensorFlow Serving ) والنموذج المطلوب نشره. على الرغم من اسم أداة التحقق من الأشعة تحت الحمراء، تقع على عاتق المستخدم مسؤولية تكوين البيئة بشكل صحيح، ولا تتفاعل أداة التحقق من الأشعة تحت الحمراء إلا مع الخادم النموذجي في البيئة التي قام المستخدم بتكوينها لمعرفة ما إذا كانت تعمل بشكل جيد. سيضمن تكوين هذه البيئة بشكل صحيح أن نجاح أو فشل التحقق من صحة الأشعة تحت الحمراء سيكون مؤشرًا على ما إذا كان النموذج سيكون قابلاً للعرض في بيئة خدمة الإنتاج. وهذا يعني بعضًا مما يلي، على سبيل المثال لا الحصر:

  1. يستخدم InfraValidator نفس النموذج الثنائي للخادم الذي سيتم استخدامه في الإنتاج. وهذا هو المستوى الأدنى الذي يجب أن تتقارب عنده بيئة التحقق من صحة الأشعة تحت الحمراء.
  2. يستخدم InfraValidator نفس الموارد (مثل كمية التخصيص ونوع وحدة المعالجة المركزية والذاكرة والمسرعات) التي سيتم استخدامها في الإنتاج.
  3. يستخدم InfraValidator نفس تكوين الخادم النموذجي الذي سيتم استخدامه في الإنتاج.

اعتمادًا على الموقف، يمكن للمستخدمين اختيار الدرجة التي يجب أن يكون بها InfraValidator مطابقًا لبيئة الإنتاج. من الناحية الفنية، يمكن التحقق من صحة النموذج بالأشعة تحت الحمراء في بيئة Docker محلية ومن ثم تقديمه في بيئة مختلفة تمامًا (مثل مجموعة Kubernetes) دون مشكلة. ومع ذلك، لن يقوم InfraValidator بالتحقق من هذا الاختلاف.

وضع التشغيل

اعتمادًا على التكوين، يتم التحقق من صحة الأشعة تحت الحمراء في أحد الأوضاع التالية:

  • وضع LOAD_ONLY : التحقق مما إذا كان النموذج قد تم تحميله بنجاح في البنية التحتية للخدمة أم لا. أو
  • وضع LOAD_AND_QUERY : وضع LOAD_ONLY بالإضافة إلى إرسال بعض نماذج الطلبات للتحقق مما إذا كان النموذج قادرًا على تقديم الاستدلالات. InfraValidator لا يهتم بما إذا كان التنبؤ صحيحًا أم لا. فقط ما إذا كان الطلب ناجحًا أم لا.

كيف أستخدمه؟

عادةً ما يتم تعريف InfraValidator بجوار مكون المُقيِّم، ويتم تغذية مخرجاته إلى أداة الدفع. إذا فشل InfraValidator، فلن يتم دفع النموذج.

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

تكوين مكون InfraValidator.

هناك ثلاثة أنواع من النماذج الأولية لتكوين InfraValidator.

ServingSpec

يعد ServingSpec التكوين الأكثر أهمية لـ InfraValidator. وهو يحدد:

  • ما نوع الخادم النموذجي الذي سيتم تشغيله
  • أين يتم تشغيله

بالنسبة لأنواع الخوادم النموذجية (وتسمى الخدمة الثنائية)، فإننا ندعمها

منصات التقديم التالية مدعومة حاليًا:

  • Local Docker (يجب تثبيت Docker مسبقًا)
  • Kubernetes (دعم محدود لـ KubeflowDagRunner فقط)

يتم اختيار الخدمة الثنائية ومنصة التقديم عن طريق تحديد كتلة oneof من ServingSpec . على سبيل المثال، لاستخدام TensorFlow Serving الثنائي الذي يعمل على مجموعة Kubernetes، يجب تعيين حقل tensorflow_serving و kubernetes .

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

لمزيد من تكوين ServingSpec ، يرجى مراجعة تعريف protobuf .

ValidationSpec

تكوين اختياري لضبط معايير التحقق من صحة الأشعة تحت الحمراء أو سير العمل.

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

تحتوي كافة حقول ValidationSpec على قيمة افتراضية سليمة. تحقق من مزيد من التفاصيل من تعريف protobuf .

RequestSpec

تكوين اختياري لتحديد كيفية إنشاء طلبات نموذجية عند تشغيل التحقق من صحة الأشعة تحت الحمراء في وضع LOAD_AND_QUERY . من أجل استخدام وضع LOAD_AND_QUERY ، يلزم تحديد كل من خصائص تنفيذ request_spec بالإضافة إلى examples لقناة الإدخال في تعريف المكون.

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

إنتاج SavedModel مع عملية الاحماء

(من الإصدار 0.30.0)

نظرًا لأن InfraValidator يتحقق من صحة النموذج من خلال طلبات حقيقية، فيمكنه بسهولة إعادة استخدام طلبات التحقق هذه كطلبات تمهيدية لـ SavedModel. يوفر InfraValidator خيارًا ( RequestSpec.make_warmup ) لتصدير SavedModel مع عملية الإحماء.

infra_validator = InfraValidator(
    ...,
    request_spec=tfx.proto.RequestSpec(..., make_warmup=True)
)

بعد ذلك، ستحتوي قطعة InfraBlessing الناتجة على SavedModel مع عملية إحماء، ويمكن أيضًا دفعها بواسطة Pusher ، تمامًا مثل قطعة Model .

القيود

InfraValidator الحالي لم يكتمل بعد، وله بعض القيود.

  • يمكن التحقق من صحة تنسيق نموذج TensorFlow SavedModel فقط.
  • عند تشغيل TFX على Kubernetes، يجب تنفيذ خط الأنابيب بواسطة KubeflowDagRunner داخل خطوط أنابيب Kubeflow. سيتم إطلاق الخادم النموذجي في نفس مجموعة Kubernetes ومساحة الاسم التي يستخدمها Kubeflow.
  • يركز InfraValidator في المقام الأول على عمليات النشر إلى TensorFlow Serving ، وعلى الرغم من أنه لا يزال مفيدًا، إلا أنه أقل دقة لعمليات النشر إلى TensorFlow Lite و TensorFlow.js ، أو أطر عمل الاستدلال الأخرى.

  • يوجد دعم محدود في وضع LOAD_AND_QUERY لتوقيع أسلوب التنبؤ (وهو الأسلوب الوحيد القابل للتصدير في TensorFlow 2). يتطلب InfraValidator توقيع التنبؤ لاستهلاك tf.Example المتسلسل كمدخل وحيد.

    @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'))
})
    • تحقق من نموذج التعليمات البرمجية لمثال Penguin لمعرفة كيفية تفاعل هذا التوقيع مع المكونات الأخرى في TFX.