Skip to content
AnmeldenLoslegen

Anleitungen

Klassifikatoren und Regressoren

Ein prädiktives Modell wird wie jedes andere System evaluiert: Ein Callable liefert für jeden Fall eine Vorhersage, und Evaluatoren lesen sie. Was sich ändert, sind die Nenner. Accuracy, Recall und Precision sind drei Raten über drei verschiedene Mengen von Zeilen, und ein Modell kann bei einer davon gut aussehen und zugleich an der Frage scheitern, die das Geschäft stellt.

examples/churn_model/ ist das Projekt, das diese Seite ausführt: zweihundert Kundenkonten, ein deterministisches Churn-Modell und keine Provider-Zugangsdaten.

Die Vorhersage

Das System liefert ein Label und, falls das Modell einen hat, den Score dahinter:

from oloproof import system


@system(name="churn-model", version="slice-f-example")
def run(account):
    score = churn_score(account)
    return {"label": score >= 0.5, "score": round(score, 4)}

Ein Fall deklariert die Wahrheit unter expected:

{"expected": {"label": false}, "id": "account_000", "input": {"recent_upgrade": true, "support_contacts": 0, "tenure_months": 0}, "metadata": {"plan": "enterprise"}}

Der Block `predictive:`

Wo die Vorhersage, ihr Score und die Wahrheit liegen, wird einmal für das Projekt deklariert:

predictive:
  label_field: label
  score_field: score
  expected_field: label
  positive: true
  calibration_bins: 10
  thresholds: [0.3, 0.4, 0.5, 0.6, 0.7]
FeldStandardBedeutung
label_fieldlabeldas Ausgabefeld mit dem vorhergesagten Label
score_fieldscoredas Ausgabefeld mit dem Score dahinter
expected_fieldlabeldas Feld unter expected mit der Wahrheit
positivetruewelcher Label-Wert als positiv zählt; refund, 1 oder true
calibration_bins10wie viele Score-Bänder die Kalibrierungstabelle verwendet
thresholdskeinerzu durchlaufende Schwellenwerte; jeder ist Evidenz, niemals eine Empfehlung
averagekeinermacro oder micro, für ein Aggregat über mehrere Klassen

Jeder prädiktive Evaluator, der field, expected_field oder positive nicht selbst angibt, übernimmt sie aus diesem Block, sodass eine Suite genau eine positive Klasse hat. Der Block erzeugt außerdem die Konfusionszahlen, die Kalibrierungstabelle und den Schwellenwert-Durchlauf; ein Projekt ohne ihn erhält die Metriken und nichts daneben.

Eine positive Klasse, zu der kein Label eines Falls passt, wird abgelehnt, bevor irgendetwas läuft, denn Recall darüber wäre eine Rate über nichts. Dasselbe Projekt mit positive: churned:

Configuration error: evaluator 'recall' counts 'churned' as the positive class, and no case's 'label' is 'churned' (labels: False, True); declare `positive:` on the evaluator or in the `predictive:` block

Die Evaluatoren

evaluators:
  - {type: predictive_correct, criterion: accuracy}
  - {type: predictive_recall, criterion: recall}
  - {type: predictive_precision, criterion: precision}
  - {type: predictive_brier, criterion: brier}
  - {type: predictive_log_loss, criterion: log_loss, clip: 0.02}
  - {type: predictive_ranking, criterion: rank}
metrics:
  - {id: roc_auc, type: ranking, criterion: rank, statistic: roc_auc}
  - {id: pr_auc, type: ranking, criterion: rank, statistic: average_precision}
slices: [metadata.plan, "confidence:0.5"]
min_slice_support: 20

predictive_log_loss erfordert clip, weil ein einziger selbstsicherer Fehler sonst unendlich ist. predictive_ranking ist das Kriterium, nach dem eine Ranking-Metrik Zeilen ordnet, und es benötigt einen metrics:-Eintrag, der die Statistik benennt: ROC-AUC und Average Precision beantworten unterschiedliche Fragen, und die Engine wählt nicht für Sie aus.

oloproof run
│ accuracy  │ 88.5%    │ [83.2%, 92.6%]  │ 177 / 200 observed · 0 missing · 0 excluded                                │
│ recall    │ 81.2%    │ [69.5%, 90.0%]  │ 52 / 64 observed · 0 missing · 136 excluded                                │
│ precision │ 82.5%    │ [70.9%, 91.0%]  │ 52 / 63 observed · 0 missing · 137 excluded                                │
│ brier     │ 0.120    │ [0.094, 0.154]  │ mean of 200 observed · 0 missing · 0 excluded                              │
│ log_loss  │ 0.389    │ [0.323, 0.499]  │ mean of 200 observed · 0 missing · 0 excluded                              │
│ roc_auc   │ 92.3%    │ [69.3%, 100.0%] │ roc_auc over 64 positive · 136 negative · 0 missing · 0 excluded           │
│ pr_auc    │ 86.5%    │                 │ average_precision over 64 positive · 136 negative · 0 missing · 0 excluded │

Lesen Sie die Spalte excluded. Recall wird über die 64 Konten gemessen, die abgewandert sind, daher sind die übrigen 136 davon ausgeschlossen; Precision über die 63, die das Modell markiert hat. Zweiunddreißig Prozent dieser Konten wandern ab, also ist ein Modell, das vorhersagt, dass niemand abwandert, zu 68 % korrekt und findet niemanden. Eine Untergrenze allein auf Accuracy würde es bestehen lassen, weshalb die Policy des Beispiels auf jede Rate eine Untergrenze legt.

pr_auc hat eine Schätzung und kein Intervall. Bei zweihundert Zeilen ist sein Intervall tatsächlich schwächer als das von ROC-AUC, und die Engine hält eine Schranke zurück, die sie nicht stützen kann, statt eine anzuzeigen. Eine Regel darauf lautet:

pr: INSUFFICIENT_EVIDENCE (interval_unavailable)

Neben den Metriken

Die Konfusionszahlen sind Anzahlen, keine Raten:

│ actually positive │ 52                 │ 12                 │
│ actually negative │ 11                 │ 125                │

Eine Release-Regel, die eine davon benennt, ist ein Konfigurationsfehler, denn eine Anzahl ist keine Metrik:

Configuration error: release rule 'fp' refers to unknown metric 'false_positives'

Die Kalibrierungstabelle stellt nach Score-Band gegenüber, was das Modell behauptet hat und was eingetreten ist:

│ 0.2-0.3 │ 26.7%   │ 0.0%     │ 34 rows │
│ 0.5-0.6 │ 53.4%   │ 81.0%    │ 21 rows │

Und der Schwellenwert-Durchlauf zeigt, was jeder deklarierte Schwellenwert gemessen hätte:

│ 0.3     │ 57.4%     │ 96.9%  │ 62/108 predicted positive · 62/64 actual positive │
│ 0.5     │ 82.5%     │ 81.2%  │ 52/63 predicted positive · 52/64 actual positive  │
│ 0.7     │ 100.0%    │ 37.5%  │ 24/24 predicted positive · 24/64 actual positive  │

Der Durchlauf trägt den Titel Thresholds (exploratory; recommends nothing). Welcher Schwellenwert richtig ist, hängt davon ab, was ein falsch positives Ergebnis im Vergleich zu einem falsch negativen kostet, und das kann die Engine nicht wissen.

Regression

Ein Regressor wird nach absolutem Fehler bewertet, wofür der Bereich benötigt wird, in dem seine Zielwerte liegen:

evaluators:
  - type: predictive_absolute_error
    criterion: days_error
    field: days
    expected_field: days
    target_range: [0, 20]
rules:
  - id: error-budget
    metric: days_error
    max: 1.5
│ days_error │ 1.02     │ [0.78, 1.88] │ mean of 120 observed · 0 missing · 0 excluded │
error-budget: INSUFFICIENT_EVIDENCE (interval_overlaps_threshold)

target_range ist Pflicht und hat keinen Standardwert. Ein absoluter Fehler ist ein beschränkter Mittelwert, und sein Intervall gilt nur innerhalb eines Bereichs, in dem jeder Wert liegt. Ein breiterer Bereich ergibt ein breiteres Intervall, deklarieren Sie also den Bereich, den die Zielwerte tatsächlich annehmen können. Die Regel kann nicht entscheiden: Die Schätzung liegt innerhalb des Budgets, und 120 Bestellungen können noch nicht zeigen, dass der wahre mittlere Fehler es auch tut.

Wie es weitergeht

  • Slices behandelt confidence:-Bänder und den Slice-Support.
  • Vergleichsregeln behandelt den Vergleich zweier Modellversionen.