Evalml: Bei einigen Zielen, bei denen der Ausgangswert 0 war, ist „pct better than baseline“ gleich nan

Reproduzierender

import evalml
import pandas as pd
X = pd.read_csv('~/Downloads/fraud_500_data.csv').drop(['id', 'expiration_date'], axis=1)
y = X.pop('fraud')
automl = evalml.automl.AutoMLSearch(problem_type="binary", objective="f1")
automl.search(X, y)
# note that all percent_better_than_baseline values are nan in the rankings table
print(automl.rankings)
# can also check the scores of any pipeline other than the baseline pipeline, which should have id 0
print(automl.results['pipeline_results'][1]['percent_better_than_baseline_all_objectives'])

Datensatz ist hier

@dsherry @rpeck Dies ist das erwartete Verhalten, da die Baseline-Pipeline eine Punktzahl von 0 für die Ziele mit NaN ( F1 , MCCBinary , Precision ) erhält. Es gab Diskussionen darüber, bei dieser Methode die Division durch 0 entweder auf unendlich oder keine zu setzen, aber wir haben nie entschieden, dass diese besser als NaN sind, denn wenn die Basislinie die schlechtestmögliche Punktzahl für ein beliebiges Ziel erzielt, dann vergleichen Sie "Prozent besser" damit Das Ziel nützt nicht viel und das kann mit None, NaN oder Infinity vermittelt werden.

Abgesehen davon kann es andere Gründe geben, eine dieser Optionen gegenüber NaN zu wählen!

@freddyaboulton Ah, macht Sinn! Ich werde den Test ändern, um jedes Ziel zu überspringen, bei dem die Grundlinie 0 ist. Danke!

Danke @freddyaboulton ! @rpeck Entschuldigung, ich habe das nicht verstanden, als Sie mich gestern danach gefragt haben.

Lassen wir diese Frage offen für Diskussionen: Sollten wir das Verhalten in diesem Fall ändern?

@freddyaboulton , also sind F1, MCCBinary und Precision alles Metriken, bei denen größer besser ist, und sind im Bereich [-1, 1] (corr) oder [0, 1] begrenzt. Könnten wir die pct-Verbesserung impl ändern, um die absolute Differenz von 0 zu berechnen und diese als pct-Verbesserung zu verwenden? Und wenn wir das derzeit tun, würde ich nicht erwarten, dass eine Baseline von 0 eine nan pct-Verbesserung für diese Metriken ergibt.

@dsherry Wir haben vorgeschlagen, die absolute Differenz für durch [0, 1] begrenzte Ziele in der Entwurfsphase zu berechnen, aber wir entschieden, dass es verwirrend wäre, zwei verschiedene Berechnungen zu haben. Abgesehen davon sollten wir das vielleicht noch einmal überdenken, da die Baseline-Pipeline fast darauf ausgelegt ist, bei diesen Zielen 0 Punkte zu erzielen, lol. Erwähnenswert ist, dass wir, als wir diese Entscheidung zum ersten Mal trafen, nur den Prozentsatz besser für das primäre Ziel berechnet haben (das außer der Regression keins dieser begrenzten Ziele ist).

Selbst wenn wir die absolute Differenz berechnen, sollten wir in Betracht ziehen, das Nan/None/inf-Division-durch-0-Verhalten zu ändern. Ein interessanter Fall ist R2 , da es in den meisten Fällen [0, 1] ist, aber technisch gesehen (-inf, 1). Die Berechnung der absoluten Differenz ist also möglicherweise nicht mathematisch einwandfrei, da dies jedoch das Standardziel für die Regression ist , sollten wir damit rechnen, viele Baselines mit dem Wert 0 zu sehen.

Zusammenfassend können wir also zwei unabhängige Änderungen vornehmen, die zu vier möglichen Ergebnissen führen:

1. Berechnen Sie keine absolute Differenz für Ziele, die in [0, 1] begrenzt sind, Division durch 0 ist Nan. Aktuelles Verhalten.
2. Berechnen Sie keine absolute Differenz für Ziele, die in [0, 1] begrenzt sind, Division durch 0 ist inf.
3. Berechnen Sie absolute Differenzen für Ziele, die in [0, 1] begrenzt sind, Division durch 0 ist Nan.
4. Berechnen Sie absolute Differenzen für Ziele, die in [0, 1] begrenzt sind, Division durch 0 ist inf.

Obwohl ich es vorziehe, NaN zurückzugeben, wenn wir durch 0 dividieren, war die Bauchreaktion der Benutzer, wenn sie NaN sehen, anzunehmen, dass in automl etwas kaputt gegangen ist. Ich denke, die Rückgabe von inf würde klarer machen, dass nichts kaputt gegangen ist und dass die Pipeline tatsächlich besser ist als die Basislinie.

Bleiben die Optionen 2 und 4.

Ich denke, zwei verschiedene Berechnungen für "Prozent besser" zu haben, wird es schwieriger machen, den Benutzern mitzuteilen, was tatsächlich für jede Pipeline berechnet wird. Abgesehen davon sind unsere Baseline-Pipelines so konzipiert, dass sie für viele Ziele (R2, F1, MCC) 0 erzielen, insbesondere bei unausgeglichenen Problemen (wir sagen nur den Modus voraus). Das macht die Funktion „Prozent besser“ für die meisten realistischen Probleme nicht sehr nützlich, da alle Pipelines „unendlich“ besser sind als die Basislinie.

Ich glaube, ich neige zu 55 % zu Option 4 und zu 45 % zu Option 2, aber ich würde gerne andere Standpunkte hören, bevor ich diese Änderung vornehme!

Heute haben wir im Standup entschieden, dass es an der Zeit ist, das Verhalten „pct better than baseline“ zu aktualisieren. Wir gehen von den Optionen 2 und 4 oben aus:

• Verwenden Sie die relative Differenz für Ziele ohne Grenzen (MSE, Log-Verlust usw.)
• Verwenden Sie die absolute Differenz für Ziele mit [0, 1]-Grenzen (AUC, R2 usw.)
• Wir müssen Grenzfälle wie die Pearson-Korrelation ([-1, 1]) behandeln.
• Gibt inf anstelle von nan zurück, wenn ein Division-durch-0-Fehler auftritt

@freddyaboulton stimmt das mit dem überein, was wir besprochen haben?

Mögen. :-)

Weiter: Ich stimme der Entscheidung zu. Meiner Meinung nach, wenn eine Metrik [normalerweise mindestens] 0..1 ist, dann fühlt sich ein Wechsel von 0 auf 0,2 wie eine 20%ige Verbesserung an, obwohl es mathematisch gesehen nicht so ist. In gewisser Weise erinnert mich das an all diese Formeln, die log einer Menge nehmen, aber zuerst 1 addieren, damit sie nicht log von 0 nehmen. :slightly_smiling_face: