إن الخدمات التنبؤية وخدمات التحسين التي تستند إلى "التعلم الآلي" تهم العديد من الشركات اليوم: من البنوك الكبيرة إلى المتاجر الصغيرة عبر الإنترنت. لحل مشاكل العملاء المختلفين ، واجهنا عددًا من المشكلات ، والتي كانت بمثابة أساس لمناقشاتنا حول ميزات اختبار ML. بالنسبة لأولئك المهتمين ، هذه هي مقالتنا التالية من سيرجي أغالتسوف ، مدير اختبار Jet Infosystems.
في السابق ، كانت الشركات الكبيرة فقط هي التي يمكنها الاستفادة من التعلم الآلي ، حيث كانت باهظة الثمن وصعبة ، وكان هناك القليل جدًا من البيانات في المجال العام. اليوم أصبح أسهل بكثير. يمكن طلب الخبرة ML من شركة تكامل أو شركة متخصصة أو في موقع مواضيعي. هذا أمر جيد للجميع ، لأنه مع نمو الخبرة يتم تطوير خوارزميات جديدة ، ويتم باستمرار إثراء "بنك الخبرة" في مجال التعلم الآلي.
الجانب الوحيد الذي لم نعثر على حل جاهز له هو اختبار خدمات ML. غوغلينغ ، يمكنك التأكد من أنه في نتائج البحث لا يوجد ذكر لأنشطة المختبرين في تطوير مثل هذه الخدمات. بالطبع ، يقوم خبراء علوم البيانات بأنفسهم باختبار نماذجهم باستخدام مقاييس متنوعة ، ووفقًا لهذه المقاييس ، قد تكون الخدمة دقيقة قدر الإمكان ، ومع ذلك ، فإن الحقيقة هي أن النموذج غير قادر دائمًا على مراعاة الفروق الدقيقة في الإنتاج والاختناقات المختلفة. ثم يبدأ منطق التعلم الآلي في النمو إلى قرص صلب.
في هذا الصدد ، بدأنا نواجه عددًا من المشكلات:
- هل يأخذ نموذج التحسين لدينا في الاعتبار دائمًا قيود الإنتاج المحتملة؟
- هل نماذجنا قادرة على العمل مع الاختناقات؟
- هل نموذجنا قادر على الاستجابة لتغيرات الإنتاج بشكل صحيح؟
هذا هو المكان الذي قررنا تركيز فريق الاختبار عليه.
مهمتنا هي توحيد ممارسة اختبار ML من أجل أن نكون قادرين على الاستجابة لجميع المشاكل المذكورة أعلاه. في الوقت الحالي ، توصلنا إلى عدد من الاستنتاجات ، والآن سوف أخبرك بأي منها.
اختبار الامتثال لقيود ومتطلبات الإنتاج للنظر فيها بواسطة خوارزمية التحسين
في الاختبارات الكلاسيكية ، في أي اختبار لدينا دائمًا "النتيجة المتوقعة". نحن نعلم جيدًا ما هو رد فعل النظام على واحد أو آخر من بيانات الإدخال. ومع ذلك ، إذا كنا نتحدث عن ML في بيئات الإنتاج ، فقد تكون هذه النتيجة المرتقبة هي الامتثال للوثائق التنظيمية ، مثل GOST ، والتعليمات التقنية وصحائف التدفق المؤقتة ، التي تحد من كل من عمليات الإنتاج نفسها ومعايير الجودة للمنتج النهائي. أثناء الاختبار ، يجب أن نتأكد من مراعاة جميع هذه القيود بالفعل ، وعلى الرغم من عددها ، فنحن على يقين من أن كل منها مغطى بحالات اختبار.
على مثال مشروع حقيقي لتحسين إنتاج المواد N (لم نكشف بعد عن الحالة ، وبالتالي سنستخدم أسماء مجهولة) ، قمنا بحل هذه المشكلة على النحو التالي:
- قمنا بتصنيف جميع درجات خلائط المواد N حسب مستوى العناصر الكيميائية فيها. نتيجة لذلك ، حصلنا على قائمة ، خططنا لاحقًا لاستخدامها كأداة مساعدة لضمان تغطية اختبار كافية.
- كنا مقتنعين بأن التوصيات الصادرة عن النموذج لجميع هذه الخلائط قد تم قبولها في الواقع دون قيد أو شرط من قبل فنيي الإنتاج وسجّلت نتيجة هذه المشكلة في ملف CSV. وبالتالي ، تلقينا توصيات من نظام "المعيار الذهبي" معين.
- بعد ذلك تم كتابة نص برمجي قام بتشغيل قائمة المخاليط المرجعية من خلال النموذج من إصدار إلى إصدار وقارن نتيجة تسليمها مع ما تم تخزينه في ملف "المعيار الذهبي" الخاص بنا.
- إذا لم يتم اكتشاف أي تغييرات في سلوك النموذج ، يمكن اعتبار اختبارات الانحدار ناجحة. إذا لم يكن الأمر كذلك ، فقد تم إجراء "استخلاص المعلومات".
وبالتالي ، تمكنا من حل مشكلة اختبار الانحدار واكتساب الثقة بأن التغييرات التي أدخلت على النموذج لا تؤثر على النتائج السابقة لعملنا.
ركز الاختبار على الاختناقات
تعد نماذج التحسين أفضل قدرة على التنبؤ بما هو موجود في معظم الأحيان في البيانات التاريخية ، وعلى العكس من ذلك ، يمكن للنموذج "أن يتحول إلى قرع" بمجرد أن يواجه شيئًا غير عادي بالنسبة له.
في كثير من الأحيان ، في مثل هذه الحالات ، يتعين على "خدمة التحسين" أن "تطالب" بنموذج سلوك مناسب وهذا يولد القرص الثابت الذي كتبته سابقًا. ولكن كيف يمكن تحديد هذه الاختناقات وتصحيح الخدمة؟ سأخبر عن ذلك بشأن مثال تطوير خدمة للتوصيات المتعلقة بإدارة إنتاج المادة N (لا تخضع القضية بعد للكشف ، وبالتالي تتم الإشارة إلى الأسماء المحجبة أدناه).
أولاً وقبل كل شيء ، طور مهندسنا المعماري محاكي تكامل قام بإنشاء بيانات مماثلة للبيانات الإنتاجية ، وبالتالي ملأ إطار التاريخ ، الذي على أساسه أصدر نموذج التحسين توصيات لتجهيز المواد N. بعد ذلك ، حلل المختبر هذه التوصيات وحدد أكثرها إثارة للريبة - تلك التي خرجت إجمالي تدفق الكتلة أوصت المعلمات. بالفعل في هذه المرحلة ، تمكنا من تحديد العديد من المشكلات عندما يتعذر على النموذج بطريقة أو بأخرى معالجة دفق البيانات الواردة بشكل مناسب. هذا سمح لنا لتحقيق الاستقرار في حالة الخدمة والانتقال إلى الخطوة التالية.
المرحلة الثانية كانت اختبار "الصمت". تم رفع الخدمة في بيئة الإنتاج في الخلفية. لقد عمل دون صرف انتباه مشغل معالجة المواد N عن التحكم في الماكينة ، وقمنا بدوره بجمع "حلول المشغل" ، لمقارنتها بما أوصت به الخدمة. نتيجة لهذا ، وجدنا النقاط العمياء للنموذج التي لا يمكن اكتشافها في المرحلة السابقة.
يجب أن يكون النموذج قادرًا على الاستجابة لتغيرات الإنتاج.
لدينا مجموعة خدمات في محفظة مشاريعنا لتحسين إنتاج مواد الوقود. يكمن جوهر الخدمة في حقيقة أن الفني ينقل مخزون مكونات الإنتاج المتبقية إلى النموذج ، ويحدد المؤشرات المحددة لجودة المنتج ويحدد خطة الإنتاج اللازمة ، ويتلقى استجابةً توصية: في أي نسب يحتاج إلى استخدام مكونات معينة من أجل الحصول على الوقود بكمية معينة الجودة.
في عملية تطوير هذه الخدمة ، واجهنا مشكلة غريبة لم نتمكن من توقعها مقدمًا.
لعدة سنوات ، عملت الشركة في إنتاج الوقود في مجموعة معينة من الثورات الإجمالية وفي الوقت نفسه تستخدم زائد / ناقص نفس النسبة من المكونات.
لكن في الآونة الأخيرة ، قامت المنظمة بتغيير إمدادات هذه المكونات وأصبح من الممكن التعويض عن هذه الحقيقة عن طريق زيادة سرعة الوحدات. توقع العميل أن يكون النموذج قادرًا على الاستجابة لهذه التغييرات ، لذلك من وجهة نظر الإنتاج التكنولوجي - هذا حل مقبول ، لكن هذا لم يحدث. لماذا؟ الجواب واضح - تم تدريب النموذج على عينة تاريخية ، حيث لم يحدث هذا من قبل. يمكنك التحدث لفترة طويلة حول موضوع من هو على حق في هذا الموقف ومن يقع عليه اللوم ، ولكن في المستقبل خططنا للحد من احتمال حدوث مثل هذه الحالات على النحو التالي:
- العمل بشكل وثيق مع ممثل العميل من وحدة الإنتاج لتحديد الاختناقات والتغيرات المحتملة في المنتج.
- تغطية حالات الاختبار مع حالات مماثلة مقدما.
- اكتب autotests للتحقق من الامتثال لقيود الإنتاج وارتباط العلامات.
فقط بضع كلمات حول أدوات الاختبار التي كان علينا استخدامها:
- bugtracking - جيرا ،
- نظام إدارة الجودة - اختبار السكك الحديدية ،
- نظام التحكم في الإصدار - GitLab ،
- CI / CD - جنكينز ،
- autotests - Java + Junit / TestNG،
- نصية للتفاعل المباشر مع النموذج - Python + Jupyter.
هل اختبار ML؟
بالنسبة لنا ، أصبح بناء ممارسة اختبار ML تحديًا ، وكان لابد من نموها من البداية. لكن الاختبار ضروري - فهو يساعد في تقليل عدد الأخطاء قبل بدء التشغيل التجريبي وتقصير وقت التنفيذ.
اليوم ، نحن جميعا بحاجة لتبادل وتبادل الخبرات. من الضروري إطلاق مناقشات حول الاختبارات في المواقع المتخصصة والمنتديات المهنية ، والتي ، بالمناسبة ، أصبحت أكثر فأكثر في مجال ML. وإذا كان لديك بالفعل ممارسات راسخة لاختبار ML ، أعتقد أن الجميع سيكون مهتمًا بقراءتها ، لذلك شارك تجربتك في التعليقات.
سيرجي أغالتسوف ، مدير الاختبار ، جت انفورمز