إجراء اختبار لـ LUIS DevOps

  • مقالة
  • قراءة خلال 7 دقائق

يمكن لمهندسي البرمجيات الذين يقومون بتطوير تطبيق فهم اللغة (LUIS) تطبيق ممارسات DevOps حول التحكم في المصدروعمليات الإنشاء التلقائيةوالاختباروإدارة الإصدار باتباع هذه الإرشادات.

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

تعد الاختبارات جزءا مهما من مهام سير عمل CI/CD. عندما يتم اقتراح تغييرات على تطبيق LUIS في طلب سحب (PR) أو بعد دمج التغييرات في الفرع الرئيسي، يجب أن تقوم مهام سير عمل CI بتشغيل الاختبارات للتحقق من أن التحديثات لم تتسبب في أي تراجعات.

كيفية القيام باختبار الوحدة واختبار الدفعات

هناك نوعان مختلفان من الاختبارات لتطبيق LUIS تحتاج إلى تنفيذهما في مهام سير عمل التكامل المستمر:

  • اختبارات الوحدة - اختبارات بسيطة نسبيا تتحقق من الوظائف الرئيسية لتطبيق LUIS الخاص بك. يمر اختبار الوحدة عندما يتم إرجاع النية المتوقعة والكيانات المتوقعة لنطق اختبار معين. يجب أن تمر جميع اختبارات الوحدة حتى يكتمل الاختبار بنجاح.
    يشبه هذا النوع من الاختبارات الاختبار التفاعلي الذي يمكنك القيام به في بوابة LUIS.

  • اختبارات الدفعات - اختبار الدفعات هو اختبار شامل على نموذجك الحالي المدرب لقياس أدائه. على عكس اختبارات الوحدة ، فإن اختبار الدفعات ليس اختبارا ناجحا | فاشلا. التوقع مع اختبار الدفعات ليس أن كل اختبار سيعيد النية المتوقعة والكيانات المتوقعة. بدلا من ذلك، يساعدك اختبار الدفعات على عرض دقة كل هدف وكيان في تطبيقك ويساعدك على المقارنة بمرور الوقت أثناء إجراء التحسينات.
    هذا النوع من الاختبارات هو نفسه اختبار الدفعات الذي يمكنك إجراؤه بشكل تفاعلي في مدخل LUIS.

يمكنك استخدام اختبار الوحدة من بداية مشروعك. لا يكون اختبار الدفعات ذا قيمة حقيقية إلا بعد تطوير مخطط تطبيق LUIS الخاص بك وتعمل على تحسين دقته.

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

اختبارات الكتابة

عند كتابة مجموعة من الاختبارات، تحتاج لكل اختبار إلى تعريف:

  • اختبار النطق
  • النية المتوقعة
  • الكيانات المتوقعة.

استخدم بناء جملة الملف الدفعي LUIS لتحديد مجموعة من الاختبارات في ملف بتنسيق JSON. على سبيل المثال:

[
  {
    "text": "example utterance goes here",
    "intent": "intent name goes here",
    "entities":
    [
        {
            "entity": "entity name 1 goes here",
            "startPos": 14,
            "endPos": 23
        },
        {
            "entity": "entity name 2 goes here",
            "startPos": 14,
            "endPos": 23
        }
    ]
  }
]

بعض أدوات الاختبار، مثل NLU. يدعم DevOps أيضا ملفات الاختبار بتنسيق LUDown.

تصميم اختبارات الوحدة

يجب تصميم اختبارات الوحدة لاختبار الوظائف الأساسية لتطبيق LUIS الخاص بك. في كل تكرار، أو سباق، من تطوير تطبيقك، يجب عليك كتابة عدد كاف من الاختبارات للتحقق من أن الوظيفة الرئيسية التي تنفذها في هذا التكرار تعمل بشكل صحيح.

في كل اختبار وحدة، بالنسبة لنطق اختبار معين، يمكنك:

  • اختبار إرجاع القصد الصحيح
  • اختبر أن الكيانات "الرئيسية" - تلك التي تعتبر حاسمة للحل الخاص بك - يتم إرجاعها.
  • اختبر أن درجة التنبؤ للنوايا والكيانات تتجاوز الحد الأدنى الذي تحدده. على سبيل المثال، يمكنك أن تقرر أنك لن تفكر في اجتياز الاختبار إلا إذا تجاوزت درجة التنبؤ للنية وللكيانات الرئيسية 0.75.

في اختبارات الوحدة، من الجيد اختبار أن الكيانات الرئيسية قد تم إرجاعها في استجابة التنبؤ، ولكن لتجاهل أي إيجابيات خاطئة. الإيجابيات الكاذبة هي كيانات موجودة في استجابة التنبؤ ولكن لم يتم تعريفها في النتائج المتوقعة لاختبارك. من خلال تجاهل الإيجابيات الكاذبة ، فإنه يجعل من الأقل إرهاقا لتأليف اختبارات الوحدة مع السماح لك بالتركيز على اختبار أن البيانات التي تعد أساسية لحلك يتم إرجاعها في استجابة تنبؤية.

تلميح

NLU. تدعم أداة DevOps جميع احتياجات اختبار LUIS الخاصة بك. compare سيؤكد الأمر عند استخدامه في وضع اختبار الوحدة أن جميع الاختبارات تمر ، وسيتجاهل النتائج الإيجابية الخاطئة للكيانات التي لم يتم تصنيفها في النتائج المتوقعة.

تصميم اختبارات الدفعات

يجب أن تحتوي مجموعات اختبار الدفعات على عدد كبير من حالات الاختبار، المصممة للاختبار عبر جميع المقاصد وجميع الكيانات في تطبيق LUIS الخاص بك. راجع اختبار الدفعات في مدخل LUIS للحصول على معلومات حول تعريف مجموعة اختبار الدفعات.

تشغيل الاختبارات

توفر بوابة LUIS ميزات للمساعدة في الاختبار التفاعلي:

  • يتيح لك الاختبار التفاعلي إرسال عينة من الكلام والحصول على استجابة من النوايا والكيانات المعترف بها من قبل LUIS. يمكنك التحقق من نجاح الاختبار عن طريق الفحص البصري.

  • يستخدم الاختبار الدفعي ملف اختبار دفعي كإدخال للتحقق من صحة الإصدار المدرب النشط لقياس دقة التنبؤ به. يساعدك اختبار الدفعات على عرض دقة كل هدف وكيان في الإصدار النشط، وعرض النتائج باستخدام مخطط.

تشغيل الاختبارات في سير عمل إنشاء تلقائي

تعد ميزات الاختبار التفاعلي في بوابة LUIS مفيدة ، ولكن بالنسبة ل DevOps ، فإن الاختبار التلقائي الذي يتم إجراؤه في سير عمل CI / CD يجلب متطلبات معينة:

  • يجب تشغيل أدوات الاختبار في خطوة سير عمل على خادم إنشاء. هذا يعني أن الأدوات يجب أن تكون قادرة على التشغيل في سطر الأوامر.
  • يجب أن تكون أدوات الاختبار قادرة على تنفيذ مجموعة من الاختبارات مقابل نقطة نهاية والتحقق تلقائيا من النتائج المتوقعة مقابل النتائج الفعلية.
  • في حالة فشل الاختبارات، يجب أن تقوم أدوات الاختبار بإرجاع رمز حالة لإيقاف سير العمل و "فشل الإنشاء".

لا يقدم LUIS أداة سطر أوامر أو واجهة برمجة تطبيقات عالية المستوى توفر هذه الميزات. نوصي باستخدام NLU. أداة DevOps لتشغيل الاختبارات والتحقق من النتائج ، سواء في سطر الأوامر أو أثناء الاختبار التلقائي ضمن سير عمل CI / CD.

لا تتطلب إمكانات الاختبار المتوفرة في مدخل LUIS نقطة نهاية منشورة وهي جزء من إمكانات تأليف LUIS. عندما تقوم بتنفيذ اختبار في سير عمل إنشاء تلقائي، يجب عليك نشر إصدار تطبيق LUIS ليتم اختباره إلى نقطة نهاية بحيث تكون أدوات الاختبار مثل NLU. يمكن ل DevOps إرسال طلبات التنبؤ كجزء من الاختبار.

تلميح

  • إذا كنت تقوم بتنفيذ حل الاختبار الخاص بك وكتابة التعليمات البرمجية لإرسال ألفاظ الاختبار إلى نقطة نهاية ، فتذكر أنه إذا كنت تستخدم مفتاح تأليف LUIS ، فإن معدل المعاملة المسموح به يقتصر على 5TPS. إما خنق معدل الإرسال أو استخدام مفتاح التنبؤ بدلا من ذلك.
  • عند إرسال استعلامات الاختبار إلى نقطة نهاية، تذكر استخدامها log=false في سلسلة الاستعلام الخاصة بطلب التنبؤ. يضمن ذلك عدم تسجيل أقوال الاختبار الخاصة بك بواسطة LUIS وينتهي بها المطاف في قائمة مراجعة أقوال نقطة النهاية التي تقدمها ميزة التعلم النشط LUIS ، ونتيجة لذلك ، تتم إضافتها عن طريق الخطأ إلى أقوال التدريب الخاصة بتطبيقك.

تشغيل اختبارات الوحدة في سطر الأوامر وفي مهام سير عمل CI/CD

يمكنك استخدام NLU. حزمة DevOps لتشغيل الاختبارات في سطر الأوامر:

  • استخدم NLU. أمر اختبار DevOps لإرسال الاختبارات من ملف اختبار إلى نقطة نهاية والتقاط نتائج التنبؤ الفعلية في ملف.
  • استخدم NLU. أمر مقارنة DevOps لمقارنة النتائج الفعلية مع النتائج المتوقعة المحددة في ملف اختبار الإدخال. يقوم compare الأمر بإنشاء إخراج اختبار NUnit ، وعند استخدامه في وضع اختبار الوحدة باستخدام --unit-test العلامة ، سيؤكد أن جميع الاختبارات تمر.

تشغيل اختبارات الدفعات في سطر الأوامر وفي مهام سير عمل CI/CD

يمكنك أيضا استخدام NLU. حزمة DevOps لتشغيل اختبارات الدفعات في سطر الأوامر.

  • استخدم NLU. أمر اختبار DevOps لإرسال الاختبارات من ملف اختبار إلى نقطة نهاية والتقاط نتائج التنبؤ الفعلية في ملف ، كما هو الحال مع اختبارات الوحدة.
  • استخدم NLU. أمر مقارنة DevOps في وضع اختبار الأداء لقياس أداء تطبيقك يمكنك أيضا مقارنة أداء تطبيقك بمعيار أداء أساسي، على سبيل المثال، النتائج الناتجة عن أحدث إصدار ملتزم بالإصدار الرئيسي أو الحالي. في وضع اختبار الأداء، compare يقوم الأمر بإنشاء مخرجات اختبار NUnit ونتائج اختبار الدفعات بتنسيق JSON.

تدريب LUIS غير الحتمي وتأثيره على الاختبار

عندما يقوم LUIS بتدريب نموذج ، مثل النية ، فإنه يحتاج إلى كل من البيانات الإيجابية - أقوال التدريب المصنفة التي قدمتها لتدريب التطبيق على النموذج - والبيانات السلبية - البيانات التي ليست أمثلة صالحة لاستخدام هذا النموذج. أثناء التدريب ، يقوم LUIS ببناء البيانات السلبية لنموذج واحد من جميع البيانات الإيجابية التي قدمتها للنماذج الأخرى ، ولكن في بعض الحالات يمكن أن يؤدي ذلك إلى اختلال توازن البيانات. لتجنب هذا الاختلال ، يقوم LUIS بأخذ عينات من مجموعة فرعية من البيانات السلبية بطريقة غير حتمية لتحسين مجموعة تدريب متوازنة بشكل أفضل ، وتحسين أداء النموذج ، ووقت تدريب أسرع.

نتيجة هذا التدريب غير الحتمي هي أنك قد تحصل على استجابة تنبؤ مختلفة قليلا بين جلسات التدريب المختلفة ، عادة للنوايا و / أو الكيانات التي لا تكون فيها درجة التنبؤ عالية.

إذا كنت ترغب في تعطيل التدريب غير الحتمي لإصدارات تطبيق LUIS التي تقوم بإنشائها لغرض الاختبار، فاستخدم واجهة برمجة تطبيقات إعدادات الإصدار مع UseAllTrainingData تعيين الإعداد إلى true.

الخطوات التالية