ترجمت واجهة Cloud Translation API‏ هذه الصفحة.
Switch to English

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

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

كيف يعمل؟

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

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

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

تكوين مكون InfraValidator.

هناك ثلاثة أنواع من البروتوس لتكوين InfraValidator.

ServingSpec

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

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

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

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

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

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

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

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

ValidationSpec

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

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

جميع حقول 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=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.
    )
)

محددات

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