Fixieren Sie Bewertungsset und Vergleichsregeln vor dem Modellvergleich

Kontext und Empfehlung

Das Bewertungsset muss vor jedem Modellvergleich festgelegt sein. Dies bedeutet, die Aufteilungen, Teilmengen, Gewichte, Metriken und ihre Richtungen in einer Datei oder Konfiguration aufzuzeichnen. Die Hugging Face Evaluate-Bibliothek bietet Werkzeuge zum Laden von Metriken und zur konsistenten Berechnung, während der scoring-Parameter von scikit-learn Bewertungsregeln für die Modellauswahl definiert. Beide unterstützen reproduzierbare Bewertungen, wenn die Regeln schriftlich niedergelegt sind. Die Empfehlung lautet, eine Bewertungsspezifikation zu erstellen, die genau angibt, welche Beispiele verwendet werden, welche Metriken berechnet werden und wie die Ergebnisse aggregiert werden. Ohne dies können zwei Läufe oder zwei Autoren unterschiedliche Zahlen produzieren, die nicht vergleichbar sind. Die Spezifikation sollte die Reihenfolge der Aggregation enthalten, z. B. gewichteter Durchschnitt über Teilmengen, sowie die Regel, dass Modelle auf denselben Aufteilungen verglichen werden. Dies verhindert, dass versehentliche Änderungen bei der Vorverarbeitung oder Datenreihenfolge die Schlussfolgerung verändern. Das Ziel ist es, das Experiment reproduzierbar und den Vergleich transparent zu machen.

Die Bewertungsspezifikation sollte in einer Datei wie YAML oder JSON gespeichert werden, damit sie versioniert und wiederverwendet werden kann. Die Datei sollte die Aufteilungen, Teilmengen, Gewichte, Metriken und Vergleichsregeln auflisten. Beispielsweise könnte ein Klassifizierungsexperiment zwei Teilmengen A und B mit Gewichten 0,6 und 0,4 sowie zwei Metriken, Genauigkeit und Recall, beide zu maximieren, verwenden. Die Vergleichsregel besagt, dass dieselben Aufteilungen verwendet werden, jede Teilmenge separat berichtet wird und die Aggregation ein gewichteter Durchschnitt ist. Diese Datei wird zur einzigen Quelle der Wahrheit für das Experiment. Wenn zwei Modelle ausgeführt werden, lesen beide dieselbe Spezifikation, sodass die Ergebnisse direkt vergleichbar sind. Der Bericht sollte die Scores pro Teilmenge und die Aggregation enthalten, nicht nur die Aggregation. Auf diese Weise kann ein Modell, das im Durchschnitt gewinnt, als Verlierer in einer kritischen Teilmenge erkannt werden. Die Spezifikation zeichnet auch die Metrikrichtungen auf, wie Genauigkeit und Recall zu maximieren, damit die Aggregation sinnvoll ist.

Die Hugging Face Evaluate-Bibliothek und die scikit-learn Scoring-API sind praktische Werkzeuge für diesen Workflow. Evaluate ermöglicht das Laden von Metriken und deren konsistente Berechnung auf Datensätzen. Der scoring-Parameter von scikit-learn definiert Modellbewertungsregeln für Kreuzvalidierung und Parametersuche. Beide Bibliotheken unterstützen die Idee, dass Bewertung ein Satz von Regeln ist, nicht nur eine einzelne Zahl. Der Schlüssel liegt darin, die Regeln in einer Datei oder Konfiguration aufzuzeichnen, damit dieselben Eingaben immer dieselben Ausgaben erzeugen. Dies ist besonders wichtig, wenn mehrere Autoren oder mehrere Läufe beteiligt sind. Die Spezifikation sollte dem Team geteilt und als Grundlage für den endgültigen Bericht verwendet werden. Der Bericht sollte die rohen Zahlen pro Teilmenge, die Aggregation und die Vergleichsregeln zeigen. Dies macht das Experiment auditierbar und die Schlussfolgerungen verteidigbar.

Das Beispiel in der Aufgabe zeigt zwei Klassifikatoren mit Genauigkeit 0,91 gegenüber 0,89, aber in Teilmenge B fällt die Recall-Rate von 0,78 auf 0,62. Wenn nur die Aggregation berichtet wird, ist der Verlust unsichtbar. Mit fixierter Spezifikation zeigt der Bericht sowohl die Aggregation als auch die Aufschlüsselung nach Teilmengen, sodass der Vergleich transparent und verteidigbar ist. Dasselbe Prinzip gilt für jeden Bereich, in dem mehrere Teilmengen oder Metriken verwendet werden. Das Bewertungsset muss fixiert, die Regeln müssen aufgezeichnet und der Bericht muss die Aufschlüsselung zeigen. Dies verhindert den häufigen Fehler, ein Modell basierend auf einer Zahl auszuwählen, die wichtige Ausfälle verdeckt. Die Spezifikation sollte vor Beginn des Experiments erstellt werden, nicht nachdem die Ergebnisse bekannt sind. Dies stellt sicher, dass der Vergleich fair ist und die Schlussfolgerungen auf vorab registrierten Regeln basieren.

eval_spec:
  splits: [train, validation, test]
  subsets:
    A: {weight: 0.6}
    B: {weight: 0.4}
  metrics:
    accuracy:
      direction: maximize
    recall:
      direction: maximize
  comparison:
    same_splits: true
    report_per_subset: true
    aggregate: weighted_average

Begründung und Abwägungen

Eine einzelne finale Metrik vereinfacht das Ranking, verbirgt jedoch die Verteilung der Fehler über Untergruppen, Horizonte und Fehlertypen.

Der Trade-off ist klar: Das Aufzeichnen von Regeln erfordert zusätzlichen Aufwand im Voraus, aber eine einzelne Aggregation kann das Ranking umkehren, wenn eine kritische Teilmenge betrachtet wird. Das Schreiben einer Spezifikationsdatei dauert Minuten; das Entdecken nach dem Deployment, dass ein Modell in einer Minderheitsuntergruppe versagt, dauert Wochen. Die Kostenasymmetrie spricht für die Spezifikation.

Im Beispiel hat Modell X eine Genauigkeit von 0,91 und Modell Y eine Genauigkeit von 0,89. In Teilmenge B fällt die Recall-Rate von 0,78 für Modell Y auf 0,62 für Modell X. Wenn die Aggregation ein gewichteter Durchschnitt der Genauigkeit über die Teilmengen A und B mit Gewichten 0,6 und 0,4 ist, erzielt Modell X insgesamt 0,91, während Modell Y 0,89 erzielt. Der Unterschied in der Aggregation beträgt nur 0,02, doch die Lücke in der Recall-Rate in Teilmenge B beträgt 0,16, eine Umkehrung, die die einzelne Zahl verdeckt.

Die feste Spezifikation zwingt den Bericht dazu, sowohl die Aggregation als auch die Aufschlüsselung nach Teilmengen hervorzuheben. Ohne die Spezifikation könnte ein Analyst Modell X aufgrund der höheren Aggregation auswählen und den Recall-Ausfall in Teilmenge B übersehen. Mit der Spezifikation ist der Vergleich transparent und der Ausfall vor dem Deployment sichtbar.

# Evaluation spec used for model comparison
spec = {
    "splits": ["train", "validation", "test"],
    "subsets": {"A": 0.6, "B": 0.4},
    "metrics": {"accuracy": "maximize", "recall": "maximize"},
    "aggregate": "weighted_average"
}

# Example: compare two models on the same splits with per-subset reporting
# Model X: accuracy 0.91, recall on subset B 0.62
# Model Y: accuracy 0.89, recall on subset B 0.78
# The aggregate alone hides the subset B failure for Model X

# The same spec is used for both models so the comparison is fair
# Report per-subset scores and the weighted aggregate
# This prevents a high aggregate from hiding a low score on a critical subset

Konkrete Illustration

Betrachten Sie zwei Klassifikatoren, die auf einem Datensatz evaluiert werden, der in Teilmenge A (60 Prozent der Beispiele) und Teilmenge B (40 Prozent der Beispiele) aufgeteilt ist. Modell X erreicht eine Genauigkeit von 0,91 in A und 0,90 in B. Modell Y erreicht eine Genauigkeit von 0,88 in A und 0,90 in B. Die gewichtete aggregierte Genauigkeit beträgt 0,6 mal 0,91 plus 0,4 mal 0,90 gleich 0,906 für Modell X und 0,6 mal 0,88 plus 0,4 mal 0,90 gleich 0,888 für Modell Y. Modell X gewinnt um 0,018 in der Aggregation.

Untersuchen Sie nun die Recall-Rate speziell in Teilmenge B. Modell X hat eine Recall-Rate von 0,62 in B, während Modell Y eine Recall-Rate von 0,78 in B hat. Die Lücke beträgt 0,16, weit größer als der Unterschied in der aggregierten Genauigkeit von 0,018. Wenn Teilmenge B eine kritische Minderheitengruppe darstellt, in der verpasste Positive hohe Kosten verursachen, ist der scheinbare Vorteil von Modell X illusorisch.

Die feste Spezifikation besagt, dass die Recall-Rate in Teilmenge B separat berichtet werden muss und dass die Vergleichsregel Sichtbarkeit pro Teilmenge erfordert. Wenn der Bericht aus der Spezifikation generiert wird, erscheinen sowohl die Aggregation als auch die Recall-Rate pro Teilmenge nebeneinander. Der Leser sieht, dass Modell X in der aggregierten Genauigkeit gewinnt, aber in der Recall-Rate in Teilmenge B schlecht abschneidet, und kann eine informierte Entscheidung treffen, anstatt einer einzelnen Zahl zu vertrauen.

Dieses durchgerechnete Beispiel zeigt, warum die Spezifikation betrieblich wichtig ist. Ohne sie berechnet der Analyst eine einzige Genauigkeitszahl, sieht 0,91 gegenüber 0,89 und wählt Modell X. Mit ihr ist derselbe Analyst gezwungen, die Aufschlüsselung zu zeigen, und der Recall-Ausfall in Teilmenge B wird unmöglich zu übersehen.

eval_spec:
  splits: [train, validation, test]
  subsets:
    A: {weight: 0.6}
    B: {weight: 0.4}
  metrics:
    accuracy:
      direction: maximize
    recall:
      direction: maximize
  comparison:
    same_splits: true
    report_per_subset: true
    aggregate: weighted_average

# Model X: accuracy 0.91, recall on subset B 0.62
# Model Y: accuracy 0.89, recall on subset B 0.78
# Aggregate alone hides the subset B failure for Model X
# The report must show per-subset scores and the weighted aggregate

Grenzen der Anwendbarkeit

Dieser Ansatz ersetzt kein separates finales Testset, wenn Hyperparameter abgestimmt werden. Er liefert nicht automatisch statistische Signifikanz; ein formaler Test ist für kleine oder verrauschte Unterschiede erforderlich. Ergebnisse bleiben nur vergleichbar, wenn das Bewertungsset und die Regeln unverändert bleiben, da sich ändernde Aufteilungen oder Gewichte einen neuen Vergleich erfordern. Es entfernt auch nicht die Notwendigkeit, die Validierungsstrategie, wie Kreuzvalidierung oder chronologische Aufteilungen, basierend auf dem Datentyp auszuwählen. Die Methode setzt voraus, dass mehrere Teilmengen oder Metriken existieren und dass die Entscheidung auf dem Modellvergleich basiert. Sie kann nicht garantieren, dass ein gewichteter Durchschnitt das richtige Geschäftsziel ist, und richtet keine Einbettungsräume aus oder etabliert Relevanz-Ground-Truth ohne gepaarte Encoder und unabhängige Referenzlabels.

Der Ansatz ist am nützlichsten, wenn das Bewertungsset verschiedene Untergruppen mit unterschiedlichen operativen Kosten enthält, wenn mehrere Autoren oder Teams Ergebnisse reproduzieren müssen und wenn die Entscheidungsschwelle nahe genug ist, dass eine einzelne Zahl das Ranking umkehren könnte.

eval_spec:
  splits: [train, validation, test]
  subsets:
    A: {weight: 0.6}
    B: {weight: 0.4}
  metrics:
    accuracy:
      direction: maximize
    recall:
      direction: maximize
  comparison:
    same_splits: true
    report_per_subset: true
    aggregate: weighted_average