Evalml: Rückruf als Automl-Ziel nicht zulassen

Ich denke, Präzision und Genauigkeit sind in dem Sinne in Ordnung, dass sie Ihnen kein triviales Modell geben.

Wir wollen Recall nicht unbedingt als Ziel löschen, es sollte nur nicht in der Automl-Suche dagegen optimiert werden. Zum Beispiel möchte ich vielleicht für f1 optimieren, aber dann meine Erinnerungspunktzahl daneben sehen

@kmax12 Ja, richtig, wir möchten den Code, der den Rückruf berechnet, nicht löschen, und wir möchten die Berechnung des Rückrufs weiterhin als Punktzahl in einer Pipeline unterstützen, aber wir möchten dies als unterstütztes Optimierungsziel in automl verbieten.

Dies erinnert mich an die anhaltende Diskussion um die Plotting-/Info-Methoden für binäre Klassifikationen für ROC und Konfusionsmatrix (#427, #365). Das sind keine Metriken, für die wir in automl optimieren können, und es sind auch keine Einzahl-Scores, aber unter unserer API bestand die einfachste Möglichkeit, sie zu definieren, darin, sie als Instanzen von ObjectiveBase hinzuzufügen.

Wir haben derzeit eine Reihe von Dingen, die mit Pipelines berechnet werden können:

1. Vorhersagen
2. Zielfunktionswerte für automl
3. Scoring-Metriken, nach automl
4. Plotten von Daten (Beispiel für binäre Klassifikation: ROC-Kurve, Konfusionsmatrix)
5. Feature-Bedeutungen

Ich denke, bis heute haben wir versucht, ObjectiveBase zu verwenden, um 2, 3 und 4 darzustellen. Mit anderen Worten, uns fehlt eine klare API, um Scoring-Methoden und Plot-Methoden zu definieren, getrennt vom Automl-Prozess .

Ich denke, der nächste Schritt hier sollte darin bestehen, diese APIs zu entwerfen. Sieht so aus, als hätte ich das bereits als #392 abgelegt. Ich werde dieses Ticket so aktualisieren, dass es darauf blockiert wird.

Für die derzeitige Überarbeitung der Ziel-API haben wir ROC und Confusion Matrix stattdessen nach PlotMetrics verschoben (weniger Designaufwand, dies war der einfachste Weg, diese beiden von den übrigen Zielen ohne zu trennen Dinge kaputt machen). Wir haben auch can_optimize_threshold als Attribut für BinaryClassificationObjective hinzugefügt, wenn also fit() mit einem Ziel mit can_optimize_threshold=True aufgerufen wird, dann optimieren wir für dieses Ziel, andernfalls optimieren wir für Genauigkeit. Gedanken dazu und wie könnte dies mit einigen der hier aufgeworfenen Fragen übereinstimmen? Wäre es unklar, wenn ein Benutzer bei Recall fit anruft, wir aber stattdessen auf Genauigkeit optimiert haben?

@angela97lin ja, ich denke, dass die Verschiebung von ROC/confusion von ObjectiveBase ein positiver Schritt war! Ich denke, #392 sollte weitergehen. Lassen Sie uns stattdessen das Gespräch darüber fortsetzen, wie die API auf #392 aktualisiert wird. Auf diese Weise kann dieses Problem nur den Rückruf von Aktualisierungen verfolgen, sobald wir eine Entscheidung darüber getroffen haben, wie wir mit diesem Zeug allgemeiner umgehen.

Ich denke auch, dass die Optimierung der Schwellenwerte für die binäre Klassifizierung ein separates Thema ist, und zum Glück eines, das Ihre laufende Arbeit in # 346 zu 100% behandelt!

Zusammenfassende Diskussion mit @eccabay und @jeremyliweishih vorhin : Optionen, dies zu unterstützen, sind:

• Löschen Sie die Rückrufziele vollständig.
• Löschen Sie die Einträge für die Rückrufziele in objectives/utils.py OPTIONS und bestätigen Sie, dass diese Ziele in automl nicht zugelassen werden.