Evalml: Datenüberprüfungs-API

Ausreißer erkennen (und eventuell optional entfernen?)

Decke mit Leitplanken im Vergleich zu modell- oder problemspezifischen Leitplanken?

Ich verwende dieses Epos um, um auf das Data Check API-Projekt (früher bekannt als "Guard Rails API") zu verweisen.

@angela97lin , @kmax12 und ich haben uns gerade getroffen, um zu besprechen, was mit diesem Projekt zu tun ist. Wir beschlossen:

• Projektumfang ändern
  
  
  
  • Entwerfen Sie eine API zum Angeben von Datenprüfungen, die zu Fehlern/Warnungen führen
  
  
  • Maßnahmen basierend auf diesen Fehlern/Warnungen zu ergreifen, ist vorerst nicht möglich und wird wahrscheinlich ein Projekt in der Zukunft sein
  
  
• Ändern Sie den Namen von "Leitplanken" in "Datenüberprüfung", da dies unserer Meinung nach aussagekräftiger ist
• @angela97lin wird das alte Leitplanken- Designdokument archivieren und ein neues mit dem neuen Umfang erstellen

@angela97lin Ich habe gerade das neue Design-Dokument durchgesehen. Gutes Zeug! Es sieht fantastisch aus.

Ich habe einige Kommentare und Vorschläge hinterlassen, aber aus meiner Sicht ist dies bereit für die Umsetzung! Aufregend

Ich denke, sobald Sie die Gelegenheit hatten, meine Kommentare zu lesen, sollte der nächste Schritt darin bestehen, für jede Aufgabe im Implementierungsplan ein Problem zu erstellen und es an dieses Epic anzuhängen. Lassen Sie uns auch die bestehenden Probleme in diesem Epos bereinigen. Auf den ersten Blick denke ich, dass wir sie entweder ins Eisfach verschieben oder schließen können.

@angela97lin und ich haben gerade das neue ausgebügelt . Wie zuvor: Der nächste Schritt besteht darin, Issues zu erstellen und sie an dieses Epic anzuhängen. Sehr cool!

Ab #509:

Wir wollen nicht, dass Leute "mean"/"median" als impute_strategy für String-Typen verwenden. Es könnte gut sein, eine Art Datenprüfung hinzuzufügen, um dies zu berücksichtigen?

Ab #504: verschiebe _check_multiclass in eine Datenprüfung :)

@angela97lin und ich haben das Design gerade noch einmal überprüft und einige letzte Optimierungen vorgenommen. Wir haben den Implementierungsplan (derzeit auf insgesamt 4 Wochen ausgelegt) aktualisiert und Probleme im Anhang zu diesem Epic eingereicht.

Dieses Projekt ist bereit für die Umsetzung!

@angela97lin wird dieses Projekt am Montag starten. Unser geplanter Fertigstellungstermin ist Montag, der 25. Mai, pünktlich zur Veröffentlichung im Mai 2020!

Wir haben auch die alten Probleme in diesem Epos aufgeräumt. Einige wurden als zukünftige Funktionen in die Eisbox gebootet, und andere (Fehler, die durch Datenprüfungen behoben werden) wurden in diesem Epos als blockiert markiert.

@angela97lin und ich haben gerade besprochen: Wir haben keine Möglichkeit in das Design aufgenommen, die Ergebnisse der Datenprüfung an Benutzer zu senden, die die automl-Suche direkt (in Python) verwenden.

Dafür haben wir zwei Möglichkeiten besprochen:
1) Lassen Sie AutoSearchBase.search etwas wie {'status': 'complete'} . Wenn die Datenprüfungen fehlschlagen, können wir {'status': 'error', 'data_checks': [..]} einschließen
2) Lassen Sie AutoSearchBase.search die Ergebnisse intern speichern und stellen Sie einen latest_data_check_results Getter (nicht als endgültiger Name gedacht) bereit, um sie zu erhalten. Geben Sie dann eine Ausnahme aus, um deutlich zu signalisieren, dass ein Problem aufgetreten ist.

Die zweite Option gefällt uns besser, also bleiben wir dabei. Es passt besser zu unseren bestehenden Entwurfsmustern a) Ausnahmen über Fehlercodes und b) AutoSearchBase Objekte als Container für Zustandsobjekte und nicht als Einmalobjekte zu verwenden.

Hier ist ein Code, den wir während des Anrufs verspottet haben und der in AutoSearchBase.search kurz vor der Hauptschleife while eingefügt werden soll, die die eigentliche Suche ausführt:

        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 : Unser aktueller Plan ist es, die Mai-Veröffentlichung in einer Woche ab heute zu veröffentlichen. Glaubst du, dass wir die #709 und #370 rechtzeitig zusammenlegen können? Wenn nicht, wie viel Zeit wird Ihrer Meinung nach benötigt? Wir können #710 problemlos auf die nächste Veröffentlichung setzen.

@angela97lin hat das meiste davon in der Mai-Version zusammengeführt! Das einzige verbleibende Problem ist #710. Also, schließt dieses Epos 🎉