Evalml: Unterstützung der Parametrisierung von Datenprüfungen; Lassen Sie InvalidTargetDataCheck das Ziel mithilfe von problem_type validieren

Erstellt am 15. Juli 2020  ·  6Kommentare  ·  Quelle: alteryx/evalml

Behebt #970 .

Gemäß der Diskussion mit @freddyaboulton in #929 wäre es schön, wenn wir zusätzliche Informationen an DataChecks weitergeben könnten. Dazu müsste die DataCheck-API aktualisiert und überlegt werden, wie sie mit AutoML interagiert, da wir keine Instanz von DataChecks instanziieren und nur eine DataChecks-Klasse als Parameter an search() übergeben.

enhancement

Hilfreichster Kommentar

Weißt du was, @angela97lin @freddyaboulton , lass uns dieses Problem verwenden, um sowohl a) die Aktualisierung von automl und der Datenprüfungs-API zur Unterstützung der Parametrisierung als auch b) die Aktualisierung InvalidTargetDataCheck zu verfolgen, um das Ziel zu validieren und intelligente Fehler für alle Ziele zu melden Typen, die wir unterstützen.

Erwähnung, weil ich gerade einen Fehler #970 eingereicht habe und bei näherer Betrachtung das Problem durch das oben Gesagte behoben werden würde. Das schließt also #970.

Alle 6 Kommentare

@angela97lin könntest du bitte den Anwendungsfall dafür beschreiben?

@dsherry Sicher! In #929 diskutierten @freddyaboulton und ich darüber, wie schön es wäre, wenn InvalidTargetDataCheck noch nützlicher sein könnte, wenn es sich der Art des Problems bewusst wäre, das es behandelt. Wenn wir beispielsweise wüssten, dass unser Problem die binäre Klassifizierung war, aber die Eingabe für die Datenprüfung mehr als zwei Klassen hatte, könnten wir eine Warnung/einen Fehler ausgeben. Daher wäre es schön, irgendwie Parameter oder einfach mehr Informationen an die Datenprüfung übergeben zu können. Leider funktioniert dies nicht gut mit unserem aktuellen Design, wo wir Klassen und keine Instanzen herumreichen.

Alternativ könnten wir Datenprüfungsklassen für jeden Problemtyp erstellen, z. B. BinaryClassificationInvalidTargetDataCheck, aber das könnte auch ziemlich haarig werden, wenn es darum geht, zu bestimmen, was DefaultDataChecks enthalten soll (oder sollte dies auch in DefaultBinaryClassificationDataChecks heruntergebrochen werden?)

Gerade mit @angela97lin @freddyaboulton besprochen

Uns gefällt die Idee, das Muster zu spiegeln, das wir für component_graph in Pipelines verwenden:

  • Die Liste der Datenprüfungen kann anfänglich für die automatische Suche als Liste von DataCheck Unterklassen (oder gleich, aber innerhalb DataChecks ) angegeben werden, nicht von Instanzen
  • Sobald die automatische Suche die Datenprüfungen ausführen möchte, kann sie eine Instanz der Klasse DataChecks erstellen
  • An diesem Punkt übergeben wir ihm ein data_check_parameters Diktat, ähnlich unserer Pipeline parameters , das eine optionale Konfiguration für eine oder mehrere Datenprüfungen enthält.
  • Wenn Benutzer DataChecks direkt verwenden möchten, können sie einem ähnlichen Muster folgen
  • data_check_parameters sollte standardmäßig None sein, damit die Leute das nicht erstellen müssen, wenn es nicht erforderlich ist. Aber wenn ein erforderliches Argument bei einer Datenprüfung fehlt (wie problem_type für einige), sollte dies zu einem Initialisierungsfehler führen

Hier ist eine Skizze, wie dies in der Automl-Suche aussehen könnte:

# 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)

Die direkte Nutzung würde ähnlich aussehen.

Nächste Schritte

  • @angela97lin @freddyaboulton andere sehen sich die obige Skizze an und prüfen sie auf ihre Vernunft
  • @angela97lin wird ein Problem melden, um das Hinzufügen einer TargetDatatype Datenprüfung (Name TBD) basierend auf unserer Diskussion zu #960 zu verfolgen. Diese Datenprüfung würde die Übergabe eines problem_type -Parameters erfordern
  • Wer diese Ausgabe aufgreift, sollte gleichzeitig auch die TargetDatatype -Ausgabe aufgreifen und dies bauen! 🛠️ 😁

@dsherry Der Plan sieht gut aus für mich! Das einzige, was ich hinzufügen möchte, ist, dass ich es vorziehe, das bereits vorhandene InvalidTargetDataCheck zu erweitern, anstatt eine neue Datenprüfung zu erstellen, aber beide Ansätze würden für mich funktionieren. Wer auch immer das aufgreift, stellt bitte sicher, dass das Ziel nur zwei eindeutige Werte hat, wenn problem_type binär ist. Dies wurde in der Rezension für Nr. 929 erwähnt.

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

Weißt du was, @angela97lin @freddyaboulton , lass uns dieses Problem verwenden, um sowohl a) die Aktualisierung von automl und der Datenprüfungs-API zur Unterstützung der Parametrisierung als auch b) die Aktualisierung InvalidTargetDataCheck zu verfolgen, um das Ziel zu validieren und intelligente Fehler für alle Ziele zu melden Typen, die wir unterstützen.

Erwähnung, weil ich gerade einen Fehler #970 eingereicht habe und bei näherer Betrachtung das Problem durch das oben Gesagte behoben werden würde. Das schließt also #970.

@dsherry Wie aktuell! Das klingt gut für mich 😊

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen