Habr AI وSpar: كيف تختبر أنظمة ML عندما تنجرف البيانات وتفسد التوقعات

نشر Habr AI دليلاً عملياً لاختبار أنظمة ML—ليس من الناحية النظرية، بل على مشروع مباشر لطلب السيارات التلقائي لسلسلة تجزئة Spar. يوضح المؤلف أن هذه المنتجات لا تنكسر فقط في النماذج نفسها: الأخطاء تختبئ في البيانات والموسمية والتكاملات وحتى في اختيار المقاييس.

لماذا هذا صعب

في فريق الضمان الكلاسيكي، يمكنك الحصول على المتطلبات وإعداد حالات الاختبار ومقارنة النتيجة الفعلية بالنتيجة المتوقعة. في ML، يعمل هذا النهج جزئياً فقط. النموذج لا يصدر "إجابة صحيحة" وفقاً لقاعدة صارمة؛ بل يبني توقعاً احتمالياً.

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

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

كيفية بناء السيطرة

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

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

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

الأعطال من الإنتاج

الجزء الأكثر توضيحاً من المادة هو الأعطال الحقيقية. في حالة واحدة، خلطت الفريق بين معاملين متشابهين تقريباً من خوارزمية موسمية: prediction_share و predict_share. كان هذا كافياً لكي يبالغ النظام بشكل كبير في التنبؤ بالزبدة والقشدة الحامضة والجبن البيضاء.

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

بدأت الموسمية الأسبوعية تُحسب بشكل غير صحيح، وتحركت ذروة الطلب من نهايات الأسبوع إلى منتصف الأسبوع. بسبب أحجام المبيعات المنخفضة، لم يتم ملاحظة المشكلة على الفور، لكن بالنسبة للعملاء كان التأثير بسيطاً: اختفى المنتج من الرفوف بالضبط عندما احتاجوا إليه. حدث عطل آخر في أوائل 2025: فسر النموذج حقل year بشكل غير صحيح وفعلياً "لم يفهم" أن سنة جديدة قد وصلت، ولم تلتقطه نظام اكتشاف الشذوذ.

الخلاصة قاسية: يجب اختبار ML ليس فقط على البيانات المعروفة بل أيضاً على فترات مستقبلية ونطاقات قيمة جديدة وأعطال آليات الحماية.

ما يعنيه هذا

توضح مقالة Habr AI بوضوح تحولاً في كيفية فهم QA بالنسبة لـ ML. هنا، تشغيل حالات الاختبار مقابل الكود غير كافٍ: تحتاج إلى مزيج من المقاييس والبيانات والمراقبة والسياق التجاري. بالنسبة للفرق التي تنشر التنبؤات في التجزئة والخدمات اللوجستية والتكنولوجيا المالية، لم تعد هذه انضباطاً إضافياً بل طبقة إلزامية من الحماية من الأخطاء المكلفة والصامتة.