Evalml: API التحقق من البيانات

اكتشاف القيم المتطرفة (وربما إزالتها اختياريًا؟)

البطانية التي تستخدم قضبان الحماية مقابل الطراز أو قضبان الحماية الخاصة بالمشكلة؟

أعيد استخدام هذه الملحمة للإشارة إلى مشروع Data Check API (المعروف سابقًا باسم "Guard Rails API").

@ angela97lin و @ kmax12 التقيت للتو لمناقشة ما يجب القيام به بهذا المشروع. قررنا:

• تغيير نطاق المشروع
  
  
  
  • تصميم واجهة برمجة تطبيقات لتحديد عمليات التحقق من البيانات ، مما يؤدي إلى حدوث أخطاء / تحذيرات
  
  
  • يعتبر اتخاذ إجراء بناءً على تلك الأخطاء / التحذيرات خارج النطاق في الوقت الحالي ، ومن المحتمل أن يكون مشروعًا في المستقبل
  
  
• قم بتغيير الاسم من "Guard Rails" إلى "Data Check" ، لأننا نشعر أن هذا أكثر وصفيًا
• @ angela97lin سوف أرشفة مستند تصميم قضبان الحماية القديم ، وإنشاء مستند جديد بالنطاق الجديد

@ angela97lin لقد انتهيت للتو من مستند التصميم الجديد . أشياء جيدة! إنها تبدو رائعة.

تركت بعض التعليقات والاقتراحات ، لكن من وجهة نظري ، هذا جاهز للتنفيذ! مثيرة 👏

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

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

من # 509:

لا نريد أن يستخدم الأشخاص "متوسط" / "متوسط" كاستراتيجية impute_strategy لأنواع السلاسل. قد يكون من الجيد إضافة نوع من فحص البيانات لحساب هذا؟

من # 504: انقل _check_multiclass إلى فحص البيانات :)

لقد قمت أنا و angela97lin بمراجعة التصميم مرة أخرى

هذا المشروع جاهز للتنفيذ!

@ angela97lin سيبدأ هذا المشروع يوم الاثنين. تاريخ الانتهاء المستهدف هو الاثنين ، 25 مايو ، في الوقت المناسب تمامًا لإصدار مايو 2020!

قمنا أيضًا بتنظيف المشكلات القديمة في هذه الملحمة. تم تمهيد البعض إلى icebox كميزات مستقبلية ، وتم تمييز البعض الآخر (الأخطاء التي سيتم إصلاحها عن طريق فحص البيانات) على أنها محظورة في هذه الملحمة.

لقد ناقشت أنا و angela97lin للتو: لم نقم بتضمين التصميم بأي طريقة للحصول على نتائج فحص البيانات للمستخدمين الذين يستخدمون بحث automl مباشرة (في بيثون).

ناقشنا خيارين لذلك:
1) اطلب من AutoSearchBase.search إرجاع شيء مثل {'status': 'complete'} ، ثم إذا فشلت عمليات التحقق من البيانات ، فيمكننا تضمين {'status': 'error', 'data_checks': [..]}
2) احفظ النتائج AutoSearchBase.search داخليًا واكشف عن getter latest_data_check_results (ليس المقصود منه الاسم النهائي) للحصول عليها. ثم رفع استثناء للإشارة بوضوح إلى وجود مشكلة.

نحن نحب الخيار الثاني أكثر ، لذلك سنعمل على ذلك. يبدو الأمر أكثر انسجامًا مع أنماط التصميم الحالية لدينا من أ) الاستثناءات على أكواد الخطأ و ب) وجود كائنات AutoSearchBase تكون حاويات للحالة بدلاً من كائنات الاستخدام لمرة واحدة.

إليك بعض التعليمات البرمجية التي سخرنا منها أثناء المكالمة ، والتي تهدف إلى الدخول في AutoSearchBase.search قبل الحلقة الرئيسية while التي تقوم بتشغيل البحث الحقيقي:

        data_check_results = checks.validate(X, y)
        # option 1
        if len(data_check_results) > 0:
            logger.error('Data checks found problems')
            return {'status': 'error', 'data_check_results': data_check_results}
        # option 2
        if len(data_check_results) > 0:
            logger.error('Data checks found problems')
            self._latest_data_check_results = data_check_results
            raise SearchException('One or more data checks failed. Look at latest_data_check_results')

        <strong i="20">@property</strong>
        def latest_data_check_results(self):
            return self._latest_data_check_results

@ angela97lin : خطتنا الحالية هي القيام بإصدار مايو بعد أسبوع من اليوم. هل تعتقد أننا سنكون قادرين على دمج # 709 و # 370 في الوقت المناسب لذلك؟ إذا لم يكن كذلك ، فكم من الوقت برأيك ضروري؟ يمكننا بسهولة إرسال # 710 إلى الإصدار التالي.

دمجت @ angela97lin معظم هذا في إصدار مايو! العدد الوحيد المتبقي هو # 710. لذا ، أغلق هذه الملحمة 🎉