Evalml: API de vérification des données

détecter les valeurs aberrantes (et peut-être éventuellement supprimer ?)

Couverture appliquant des garde-corps par rapport à des garde-corps spécifiques à un modèle ou à un problème ?

Je réutilise cette épopée pour faire référence au projet Data Check API (anciennement connu sous le nom de "Guard Rails API").

@angela97lin , @kmax12 et moi venons de nous rencontrer pour discuter de ce qu'il faut faire avec ce projet. Nous avons décidé:

• Modifier la portée du projet
  
  
  
  • Concevoir une API pour spécifier des contrôles de données, qui entraînent des erreurs/avertissements
  
  
  • Agir sur la base de ces erreurs/avertissements est hors de portée pour l'instant, et sera probablement un projet sur la route
  
  
• Changez le nom de "Guard Rails" en "Data Check", car nous pensons que c'est plus descriptif
• @angela97lin archivera l'ancien document de conception des garde-corps et en créera un nouveau avec la nouvelle portée

@angela97lin Je viens de finir de parcourir le nouveau document de conception . Bon produit! Ça a l'air génial.

J'ai laissé quelques commentaires et suggestions, mais de mon point de vue, c'est prêt pour la mise en œuvre ! Excitant

Je pense qu'une fois que vous avez eu l'occasion d'examiner mes commentaires, la prochaine étape devrait être de créer un problème pour chaque tâche du plan de mise en œuvre et de les joindre à cette épopée. Nettoyons également les problèmes existants actuellement dans cette épopée. À première vue, je pense que nous pouvons soit les déplacer vers la glacière, soit les fermer.

@ angela97lin et moi venons de revoir le nouveau document de conception et de régler quelques détails de conception. Identique à la précédente : l'étape suivante consiste à créer des problèmes et à les attacher à cette épopée. Très cool!

À partir de #509 :

Nous ne voulons pas que les gens utilisent "mean"/"median" comme impute_strategy pour les types de chaîne. Il pourrait être bon d'ajouter une sorte de vérification des données pour en tenir compte ?

De #504 : déplacez _check_multiclass vers une vérification de données :)

@ angela97lin et moi venons de revoir la conception et d'apporter quelques modifications finales. Nous avons mis à jour le plan de mise en œuvre (actuellement d'une portée de 4 semaines au total) et classé les problèmes liés à cette épopée.

Ce projet est prêt à être mis en œuvre !

@angela97lin va commencer ce projet lundi. Notre date d'achèvement cible est le lundi 25 mai, juste à temps pour la sortie de mai 2020 !

Nous avons également nettoyé les anciens problèmes de cette épopée. Certains ont été démarrés dans la glacière en tant que fonctionnalités futures, et d'autres (des bogues qui seront corrigés par des vérifications de données) ont été marqués comme bloqués sur cette épopée.

@ angela97lin et moi venons de discuter : nous n'avons inclus dans la conception aucun moyen d'obtenir les résultats de la vérification des données pour les utilisateurs qui utilisent directement la recherche automatique (en python).

Nous avons discuté de deux options pour cela :
1) Demandez à AutoSearchBase.search renvoyer quelque chose comme {'status': 'complete'} , puis si les vérifications de données échouent, nous pouvons inclure {'status': 'error', 'data_checks': [..]}
2) Faites en sorte que AutoSearchBase.search enregistre les résultats en interne et exposez un latest_data_check_results getter (non destiné à être le nom final) pour les obtenir. Ensuite, soulevez une exception pour signaler clairement qu'il y avait un problème.

Nous aimons davantage la deuxième option, alors nous allons y aller. Cela semble plus conforme à nos modèles de conception existants de a) exceptions sur les codes d'erreur et b) avoir des objets AutoSearchBase être des conteneurs pour l'état plutôt que des objets à usage unique.

Voici du code que nous avons simulé lors de l'appel, destiné à entrer dans AutoSearchBase.search juste avant la boucle principale while qui exécute la vraie recherche :

        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 : notre plan actuel est de faire la sortie de mai dans une semaine à partir d'aujourd'hui. Pensez-vous que nous pourrons fusionner les numéros 709 et 370 à temps pour cela ? Si non, combien de temps faut-il selon vous ? Nous pouvons facilement passer le #710 à la prochaine version.

@angela97lin a fusionné la plupart de ces éléments dans la version de mai ! Le seul problème restant est le #710. Alors, clôture de cette épopée