Evalml: Prend en charge le paramétrage des vérifications de données ; avoir InvalidTargetDataCheck valider la cible en utilisant problem_type

Créé le 15 juil. 2020  ·  6Commentaires  ·  Source: alteryx/evalml

Corrige #970 .

D'après la discussion avec @freddyaboulton au #929, ce serait bien si nous pouvions transmettre des informations supplémentaires à DataChecks. Cela nécessiterait de mettre à jour l'API DataCheck et de tenir compte de son interaction avec AutoML, car nous n'instancions pas d'instance de DataChecks et ne transmettons qu'une classe DataChecks en tant que paramètre à search() .

enhancement

Commentaire le plus utile

Vous savez quoi, @angela97lin @freddyaboulton utilisons ce problème pour suivre à la fois a) la mise à jour d'automl et de l'API de vérification des données pour prendre en charge le paramétrage et b) la mise à jour InvalidTargetDataCheck pour valider la cible et générer des erreurs intelligentes, pour toute la cible types que nous prenons en charge.

Mentionnant parce que je viens de déposer un bogue # 970 et en y regardant de plus près, le problème serait résolu par ce qui précède. Cela fermera donc #970.

Tous les 6 commentaires

@ angela97lin pourriez-vous s'il vous plaît décrire le cas d'utilisation pour cela?

@dsherry Bien sûr ! Dans #929, @freddyaboulton et moi discutions de la façon dont ce serait bien si le InvalidTargetDataCheck pouvait être encore plus utile s'il était conscient du type de problème qu'il traitait. Par exemple, si nous savions que notre problème était une classification binaire mais que l'entrée de la vérification des données avait plus de deux classes, nous pourrions lancer un avertissement/erreur. Par conséquent, ce serait bien de pouvoir transmettre des paramètres d'une manière ou d'une autre ou simplement plus d'informations à la vérification des données. Malheureusement, cela ne fonctionne pas bien avec notre conception actuelle, où nous passons des classes et non des instances.

Alternativement, nous pourrions créer des classes de vérification des données pour chaque type de problème, comme BinaryClassificationInvalidTargetDataCheck, mais cela pourrait également devenir assez poilu, lors de la détermination de ce que DefaultDataChecks devrait inclure (ou cela devrait-il également être décomposé en DefaultBinaryClassificationDataChecks ?)

Je viens de discuter avec @angela97lin @freddyaboulton

Nous aimons l'idée de refléter le modèle que nous utilisons pour component_graph dans les pipelines :

  • La liste des vérifications de données peut être spécifiée initialement pour la recherche automatique sous la forme d'une liste de sous-classes DataCheck (ou identiques mais à l'intérieur DataChecks ), et non d'instances
  • Une fois que la recherche automatique veut exécuter les vérifications de données, elle peut créer une instance de la classe DataChecks
  • À ce stade, nous lui transmettons un dict data_check_parameters , similaire à notre pipeline parameters , qui contient une configuration facultative pour une ou plusieurs vérifications de données.
  • Si les utilisateurs veulent utiliser DataChecks directement, ils peuvent suivre un modèle similaire
  • data_check_parameters devrait être None par défaut pour que les gens n'aient pas besoin de le créer si ce n'est pas nécessaire. Mais si un argument requis est manquant dans une vérification de données (comme problem_type pour certains), cela devrait entraîner une erreur d'initialisation

Voici un croquis de ce à quoi cela pourrait ressembler dans la recherche automl :

# today this helper standardizes the input to a list of `DataCheck` instances, and wraps that in a `DataChecks` instance
# after this work, this would standardize the input to a `DataChecks` class.
# if `data_checks` was already a `DataChecks` class, do nothing. else if `data_checks` is a list of `DataCheck` classes, define a `AutoMLDataChecks` class to wrap and return that
data_checks_class = self._validate_data_checks(data_checks)
# next we create the `DataChecks` instance by passing in data checks parameters
data_check_parameters = {'Target Datatype Data Check': {'problem_type': self.problem_type}}
data_checks = data_checks_class(data_check_parameters)
data_check_results = data_checks.validate(X, y)

L'utilisation directe serait similaire.

Prochaines étapes

  • @angela97lin @freddyaboulton d'autres examinent le croquis ci-dessus et vérifient sa santé mentale
  • @angela97lin déposera un problème pour suivre l'ajout d'une vérification de données TargetDatatype (nom à déterminer), sur la base de notre discussion sur #960 . Cette vérification des données nécessiterait la transmission d'un paramètre problem_type
  • Celui qui récupère ce problème devrait également récupérer ce problème de TargetDatatype en même temps et le construire ! 🛠️ 😁

@dsherry Le plan m'a l'air bien ! La seule chose que j'ajouterais est que je préfère augmenter le InvalidTargetDataCheck déjà existant plutôt que de créer une nouvelle vérification des données, mais l'une ou l'autre approche fonctionnerait pour moi. Quelle que soit la personne qui le récupère, assurez-vous de vérifier que la cible n'a que deux valeurs uniques lorsque le problem_type est binaire. Cela a été mentionné dans la critique du n ° 929.

if problem_type == "binary" and len(set(y)) != 2:
    # Warn that we do not have two unique values in y

Vous savez quoi, @angela97lin @freddyaboulton utilisons ce problème pour suivre à la fois a) la mise à jour d'automl et de l'API de vérification des données pour prendre en charge le paramétrage et b) la mise à jour InvalidTargetDataCheck pour valider la cible et générer des erreurs intelligentes, pour toute la cible types que nous prenons en charge.

Mentionnant parce que je viens de déposer un bogue # 970 et en y regardant de plus près, le problème serait résolu par ce qui précède. Cela fermera donc #970.

@dsherry Comme c'est opportun ! ça me tente bien 😊

Cette page vous a été utile?
0 / 5 - 0 notes