Anleitungen

Tutorial: ein Klassifikator und ein Regressor

Ein ausführbarer Rundgang für drei prädiktive Modelle, evaluiert über die Kommandozeile: ein binärer Churn-Klassifikator, ein Ticket-Router mit drei Klassen, Klasse für Klasse evaluiert, und ein Lieferzeit-Regressor, bewertet über den absoluten Fehler innerhalb eines deklarierten Bereichs. Jeder läuft lokal ohne Provider, ohne Schlüssel und ohne Netzwerk, und jeder endet mit einer Kandidatenänderung, die gegen die Baseline gemessen wird.

Diese Seite ist das praktische Gegenstück zu Klassifikatoren und Regressoren, die jedes Feld erklärt; lesen Sie jene Seite als Referenz und diese, um es einmal von Anfang bis Ende zu tun. Begriffe wie Intervall, Entscheidungszustand und Release-Aktion sind in Konzepte definiert.

Was Oloproof bei einem prädiktiven Modell misst und was nicht

Modell	Was Sie bekommen	Was Sie nicht bekommen
Binärer Klassifikator	Accuracy, Recall, Precision, Brier-Score, Log Loss, ROC-AUC und Average Precision, dazu Konfusionszählungen, eine Kalibrierungstabelle und einen Schwellenwert-Sweep	einen empfohlenen Schwellenwert
Mehrklassen-Klassifikator	einen Recall und eine Precision pro Klasse, jeweils eine binäre Metrik, deren positive Klasse diese Klasse ist (eine gegen den Rest)	eine Metrik als Makro- oder Mikro-Mittel
Regressor	mittlerer absoluter Fehler, begrenzt durch einen von Ihnen deklarierten target_range	quadratischer Fehler, R-Quadrat oder ein Fehler ohne deklarierten Bereich

Das Modell selbst bleibt Ihres. Oloproof ruft eine Python-Funktion auf, auf die Sie es verweisen, liest die Vorhersage, die sie zurückgibt, und sieht nie Features, Gewichte oder Interna.

Voraussetzungen

Python 3.11 oder neuer und pip install oloproof in einer virtuellen Umgebung, wie im Schnellstart.
Die Beispieldateien, die mit dem Paket ausgeliefert werden. Kopieren Sie sie in ein neues Verzeichnis, damit die Stores der Läufe dort landen:

oloproof init --example predictive ~/oloproof-predictive
cd ~/oloproof-predictive

Jeder Befehl unten läuft in einem der drei Unterverzeichnisse. Jeder Lauf schreibt seine Evidenz in ein .oloproof/-Verzeichnis neben der oloproof.yaml, die er gelesen hat.

predictive/
  binary/        app.py  oloproof.yaml  candidate.yaml  release.yaml  comparison.yaml  data/accounts.jsonl
  multiclass/    app.py  oloproof.yaml  candidate.yaml  release.yaml  data/tickets.jsonl
  regression/    app.py  oloproof.yaml  candidate.yaml  release.yaml  data/orders.jsonl

Teil 1: ein binärer Klassifikator

Der Adapter

binary/app.py enthält Modell und Adapter in einer Datei. Das Modell ist dasselbe deterministische Churn-Modell wie im Beispiel churn_model (oloproof init --example churn_model); der Adapter ist die dekorierte Funktion, die Oloproof aufruft:

from oloproof import system


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


@system(name="churn-model", version="candidate-cutoff-0.4")
def run_candidate(account):
    score = churn_score(account)
    return {"label": score >= 0.4, "score": round(score, 4)}

Um Ihr eigenes Modell zu evaluieren, behalten Sie die Form und ersetzen churn_score durch einen Aufruf Ihres Modells, zum Beispiel model.predict_proba([features(account)])[0][1] für ein scikit-learn-Modell, das Sie einmal beim Import laden. Ändern Sie version, wann immer sich das Modell oder sein Schwellenwert ändert: Die Version ist Teil des Cache-Schlüssels, ein unter derselben Version neu trainiertes Modell würde also die alten Vorhersagen wiederverwenden.

Formen von Eingabe und Ausgabe

Eine Zeile von data/accounts.jsonl ist ein Fall:

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

Teil	Form	Wer es liest
input	das Objekt, das Ihre Funktion erhält	Ihr Adapter
expected.label	true oder false, die Wahrheit	die Evaluatoren
metadata.plan	beliebiges JSON	nur Slices
zurückgegebenes label	true oder false, die Vorhersage	die Evaluatoren
zurückgegebener score	eine Zahl in [0, 1], die Wahrscheinlichkeit der positiven Klasse	Brier, Log Loss, Ranking, Kalibrierung, Sweep

Die Evaluatoren, und warum diese

binary/oloproof.yaml:

version: 1
project: churn-tutorial
dataset: data/accounts.jsonl
system:
  name: churn-model
  version: baseline
  callable: app:run
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}
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]
slices: [metadata.plan, "confidence:0.5"]
min_slice_support: 20

Accuracy, Recall und Precision sind drei Raten über drei verschiedene Mengen von Zeilen: jedes Konto, die Konten, die gekündigt haben, und die Konten, die das Modell markiert hat. Ein Churn-Modell braucht alle drei, weil etwa ein Drittel der Konten kündigt; ein Modell, das vorhersagt, dass niemand kündigt, hat also 68 % Accuracy und findet niemanden.
Brier und Log Loss bewerten die Wahrscheinlichkeit hinter dem Label. Log Loss braucht clip, weil ein einziger selbstsicherer Fehler sonst unendlich ist.
predictive_ranking plus zwei metrics:-Einträge ergeben ROC-AUC und Average Precision. Sie beantworten, wie gut das Modell Konten ordnet, unabhängig davon, wo der Schwellenwert liegt.
Der predictive:-Block sagt, wo Label, Score und Wahrheit liegen, und erzeugt neben den Metriken die Konfusionszählungen, die Kalibrierungstabelle und den Schwellenwert-Sweep.

Die Policy

binary/release.yaml setzt eine Untergrenze für jede Rate:

version: 1
confidence_level: 0.95
block_on: [FAIL, INSUFFICIENT_EVIDENCE, MANUAL_REVIEW]
rules:
  - {id: accuracy-floor, metric: accuracy, min: 0.75}
  - {id: recall-floor, metric: recall, min: 0.60}
  - {id: precision-floor, metric: precision, min: 0.60}

Eine Regel besteht, wenn die untere Schranke des Intervalls die Untergrenze überschreitet, scheitert, wenn die obere Schranke darunter liegt, und liest sonst INSUFFICIENT_EVIDENCE.

Ausführen

cd binary
oloproof run

Gekürzt:

Run run_... [DECIDED/COMPLETE]
Gate: ALLOW (exit 0)
│ accuracy-floor  │ accuracy  │ PASS  │ lower_bound_meets_minimum │
│ recall-floor    │ recall    │ PASS  │ lower_bound_meets_minimum │
│ precision-floor │ precision │ PASS  │ lower_bound_meets_minimum │

│ 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 │

So lesen Sie es:

Gate: ALLOW (exit 0) bedeutet, dass keine Regel einen Zustand erreicht hat, auf den die Policy blockiert. Es ist keine Aussage, dass das Modell über die drei von Ihnen geschriebenen Untergrenzen hinaus gut ist.
Die excluded-Zählungen sind die Nenner bei der Arbeit: Recall wird über die 64 Konten gemessen, die gekündigt haben, daher sind die 136, die es nicht taten, davon ausgeschlossen, nicht als Fehlschläge gezählt.
pr_auc hat kein Intervall. Bei 200 Zeilen hält die Engine eine Schranke zurück, die sie nicht stützen kann; eine Regel darauf würde INSUFFICIENT_EVIDENCE mit interval_unavailable lesen.

Unter den Metriken gibt dieselbe Ausgabe die Konfusionszählungen, die Kalibrierungstabelle und den Schwellenwert-Sweep aus:

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

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

│ 0.3     │ 57.4%     │ 96.9%  │ 62/108 predicted positive · 62/64 actual positive │
│ 0.4     │ 62.6%     │ 89.1%  │ 57/91 predicted positive · 57/64 actual positive  │
│ 0.5     │ 82.5%     │ 81.2%  │ 52/63 predicted positive · 52/64 actual positive  │
│ 0.6     │ 83.3%     │ 54.7%  │ 35/42 predicted positive · 35/64 actual positive  │
│ 0.7     │ 100.0%    │ 37.5%  │ 24/24 predicted positive · 24/64 actual positive  │

Die Zählungen sind keine Raten, und keine Regel darf sie benennen. Die Kalibrierungszeilen sagen, dass die Wahrscheinlichkeiten des Modells danebenliegen: Im Band von 0,2 bis 0,3 behauptet es etwa einen Kündiger von vieren, und keiner der 34 hat gekündigt. Der Sweep trägt den Titel Thresholds (exploratory; recommends nothing): Er zeigt, was jeder Schwellenwert gemessen hätte, und überlässt die Wahl Ihnen, denn nur Sie wissen, was ein verpasster Kündiger im Vergleich zu einem vergeudeten Halteanruf kostet.

Die Fehlschläge untersuchen

oloproof inspect RUN_ID --failures --limit 5

23 of 200 cases failed, errored or did not finish

account_032
  output: {"label": false, "score": 0.07}
  accuracy: failed
  recall: failed

account_037
  output: {"label": false, "score": 0.37}
  accuracy: failed
  recall: failed
...

RUN_ID ist die ID in der ersten Zeile der Laufausgabe. oloproof inspect RUN_ID --case account_037 zeigt Eingabe, erwarteten Wert, Ausgabe und jedes Urteil eines Falls. Mehrere verpasste Kündiger liegen knapp unter dem Schwellenwert 0,5 (0,37, 0,43), was die Zeile 0,4 des Sweeps bereits nahelegte.

Eine sinnvolle nächste Maßnahme folgt aus dem, was Sie sehen, nicht aus dem Gate: Hier häufen sich die Fehlgriffe unter dem Schwellenwert, also probiert der Kandidat einen niedrigeren. Wären es selbstsichere Fehlgriffe gewesen (0,07), läge die nächste Maßnahme bei den Features des Modells, und kein Schwellenwert würde helfen.

Eine Kandidatenänderung und der Vergleich

binary/candidate.yaml ist oloproof.yaml mit zwei geänderten Zeilen:

system:
  name: churn-model
  version: candidate-cutoff-0.4
  callable: app:run_candidate

oloproof run --config candidate.yaml

Gate: BLOCK (exit 3)
│ accuracy-floor  │ accuracy  │ INSUFFICIENT_EVIDENCE │ interval_overlaps_threshold │
│ recall-floor    │ recall    │ PASS                  │ lower_bound_meets_minimum   │
│ precision-floor │ precision │ INSUFFICIENT_EVIDENCE │ interval_overlaps_threshold │

│ accuracy  │ 79.5%    │ [73.2%, 84.9%]  │ 159 / 200 observed · 0 missing · 0 excluded                                │
│ recall    │ 89.1%    │ [78.7%, 95.5%]  │ 57 / 64 observed · 0 missing · 136 excluded                                │
│ precision │ 62.6%    │ [51.8%, 72.6%]  │ 57 / 91 observed · 0 missing · 109 excluded                                │

Genau die Zeile 0,4 des Sweeps: Recall hoch, Precision runter. Exit 3 ist INSUFFICIENT_EVIDENCE, nicht FAIL: Die Untergrenzen liegen innerhalb der Intervalle, 200 Konten können also nicht sagen, auf welcher Seite der Kandidat liegt. Die Scores haben sich nicht geändert, daher sind Brier, Log Loss und ROC-AUC identisch.

Vergleichen Sie nun die beiden Läufe Fall für Fall. binary/comparison.yaml enthält Vergleichsregeln:

version: 1
confidence_level: 0.95
block_on: [FAIL, INSUFFICIENT_EVIDENCE, MANUAL_REVIEW]
rules:
  - {id: recall-no-worse, kind: non_inferiority, metric: recall, margin: 0.05}
  - {id: accuracy-no-worse, kind: non_inferiority, metric: accuracy, margin: 0.05}

oloproof compare CANDIDATE_RUN_ID BASELINE_RUN_ID --policy comparison.yaml

Comparison sha256:... of run_... against run_... · 200 paired cases
accuracy: -9.0 points [-17.9, -1.4] · 200 paired · 0 missing · 0 excluded
recall: +7.8 points [-2.8, +21.9] · 64 paired · 0 missing · 136 excluded
  excluded 136: not_a_positive_case
precision: +0.0 points [-8.3, +8.3] · 63 paired · 0 missing · 137 excluded
  excluded 137: not_predicted_positive
...
Decisions
  recall-no-worse  recall  non-inferiority, margin 5.0 points  PASS  lower_bound_above_margin
  accuracy-no-worse  accuracy  non-inferiority, margin 5.0 points  INSUFFICIENT_EVIDENCE  interval_overlaps_margin
    no sample size would make this PASS: the difference itself (-9.0 points) is outside the margin, so more cases would move it toward FAIL
Gate: BLOCK (exit 3)

Lesen Sie die Precision-Zeile genau. Die eigene Precision des Kandidaten fiel von 82,5 % auf 62,6 %, und doch ist die gepaarte Differenz +0.0 über 63 Paare. Ein Vergleich paart Zeilen: Eine Precision-Differenz wird nur über Konten gemessen, die beide Modelle markiert haben, und bei diesen 63 lagen beide richtig. Die 28 zusätzlichen Konten, die der Kandidat markiert hat, 23 davon Fehlalarme, liegen außerhalb dieser Menge. Deshalb schützt comparison.yaml bei einer Schwellenwertänderung die Accuracy statt der Precision; Vergleichsregeln enthält die Regelarten.

Die Entscheidung ist der nützliche Teil: Recall ist als nicht schlechter gezeigt, und Accuracy kann nicht als innerhalb von fünf Punkten gezeigt werden; die Hinweiszeile sagt, dass mehr Daten sie in Richtung FAIL schieben würden. Ob es sich lohnt, neun Punkte Accuracy gegen acht Punkte Recall zu tauschen, ist eine Geschäftsentscheidung, die das Gate sichtbar gemacht hat.

Teil 2: ein Mehrklassen-Klassifikator, Klasse für Klasse

multiclass/app.py leitet ein Support-Ticket in eine von drei Queues und hat einen absichtlichen Fehler: Jedes aus der mobilen App gesendete Ticket geht an technical.

@system(name="ticket-router", version="baseline")
def route(ticket):
    if ticket["channel"] == "app":
        return {"queue": "technical"}
    return {"queue": classify(str(ticket["subject"]))}

Ein Fall:

{"expected": {"queue": "billing"}, "id": "ticket_000", "input": {"channel": "email", "subject": "update the card on file"}, "metadata": {"channel": "email"}}

Es gibt keine Mehrklassen-Metrik zum Einschalten. Jede Klasse bekommt ihren eigenen binären Block: Recall für billing ist der binäre Recall, dessen positive Klasse billing ist. multiclass/oloproof.yaml:

evaluators:
  - {type: predictive_correct, criterion: accuracy, field: queue, expected_field: queue}
  - {type: predictive_recall, criterion: recall_billing, field: queue, expected_field: queue, positive: billing}
  - {type: predictive_precision, criterion: precision_billing, field: queue, expected_field: queue, positive: billing}
  - {type: predictive_recall, criterion: recall_technical, field: queue, expected_field: queue, positive: technical}
  - {type: predictive_precision, criterion: precision_technical, field: queue, expected_field: queue, positive: technical}
  - {type: predictive_recall, criterion: recall_account, field: queue, expected_field: queue, positive: account}
  - {type: predictive_precision, criterion: precision_account, field: queue, expected_field: queue, positive: account}
slices: [metadata.channel]

Oloproof berechnet darüber kein Makro- oder Mikro-Mittel. Wenn Sie eines brauchen, ist es eine Zahl, die Sie selbst aus den Zählungen pro Klasse ableiten, und keine Regel kann darauf gaten. Die Policy setzt eine Untergrenze für die Klassen, auf die es ankommt, denn ein Router kann insgesamt genau sein und eine Queue verlieren:

rules:
  - {id: billing-recall-floor, metric: recall_billing, min: 0.80}
  - {id: account-recall-floor, metric: recall_account, min: 0.80}
  - {id: technical-precision-floor, metric: precision_technical, min: 0.80}

cd ../multiclass
oloproof run

Gate: BLOCK (exit 1)
│ billing-recall-floor      │ recall_billing      │ FAIL                  │ upper_bound_below_minimum   │
│ account-recall-floor      │ recall_account      │ INSUFFICIENT_EVIDENCE │ interval_overlaps_threshold │
│ technical-precision-floor │ precision_technical │ FAIL                  │ upper_bound_below_minimum   │

│ accuracy            │ 81.3%    │ [74.1%, 87.3%]  │ 122 / 150 observed · 0 missing · 0 excluded │
│ recall_billing      │ 66.0%    │ [51.2%, 78.8%]  │ 33 / 50 observed · 0 missing · 100 excluded │
│ precision_billing   │ 100.0%   │ [89.4%, 100.0%] │ 33 / 33 observed · 0 missing · 117 excluded │
│ recall_technical    │ 100.0%   │ [92.8%, 100.0%] │ 50 / 50 observed · 0 missing · 100 excluded │
│ precision_technical │ 64.1%    │ [52.4%, 74.7%]  │ 50 / 78 observed · 0 missing · 72 excluded  │
│ recall_account      │ 78.0%    │ [64.0%, 88.5%]  │ 39 / 50 observed · 0 missing · 100 excluded │
│ precision_account   │ 100.0%   │ [90.9%, 100.0%] │ 39 / 39 observed · 0 missing · 111 excluded │

Exit 1 bedeutet, dass mindestens eine Regel FAIL ist. Jede Klasse hat ihren eigenen Nenner: 78 Tickets wurden technical zugeordnet, das ist also der Nenner der Precision für technical. Die Slice-Tabelle zeigt auf die Ursache; Slices sind explorativ und gaten nie, aber ein markierter Slice ist eine Spur, die sich zu lesen lohnt:

│ metadata.channel=app   │ accuracy            │ 42.9%    │ [28.8%, 57.8%]  │ 21 / 49 observed · ... │ marked (p 0.0001)    │

oloproof inspect RUN_ID --failures --limit 2

28 of 150 cases failed, errored or did not finish

ticket_011
  output: {"queue": "technical"}
  accuracy: failed
  precision_technical: failed
  recall_account: failed
...

Der Kandidat (route_candidate, ausgeführt mit oloproof run --config candidate.yaml) lässt die Kanal-Abkürzung weg. Auf diesen synthetischen Daten leitet er jedes Ticket richtig, und das Gate lässt durch:

Gate: ALLOW (exit 0)
│ billing-recall-floor      │ recall_billing      │ PASS  │ lower_bound_meets_minimum │
│ account-recall-floor      │ recall_account      │ PASS  │ lower_bound_meets_minimum │
│ technical-precision-floor │ precision_technical │ PASS  │ lower_bound_meets_minimum │

oloproof compare funktioniert hier genau wie in Teil 1, eine Differenz pro Klassenmetrik.

Teil 3: ein Regressor, bewertet über den absoluten Fehler

regression/app.py schätzt Liefertage und ignoriert, ob der Artikel auf Lager ist:

@system(name="delivery-estimator", version="baseline")
def estimate(order):
    return {"days": round(base_days(order), 1)}

Ein Fall, mit der Wahrheit als Zahl:

{"expected": {"days": 11}, "id": "order_000", "input": {"distance_km": 468, "express": false, "in_stock": false}, "metadata": {"in_stock": false}}

Der einzige Regressions-Evaluator ist der absolute Fehler, und er braucht den Bereich, in dem jedes Ziel liegt. Ein absoluter Fehler ist ein begrenzter Mittelwert, dessen Intervall nur innerhalb dieses Bereichs gilt, daher wird er deklariert, nie per Standard gesetzt. Lieferungen dauern hier 0 bis 20 Tage:

evaluators:
  - type: predictive_absolute_error
    criterion: days_error
    field: days
    expected_field: days
    target_range: [0, 20]
slices: [metadata.in_stock]

Die Policy ist ein Budget, eine max:-Regel: Sie besteht, wenn die obere Schranke des Intervalls auf oder unter ihm liegt.

rules:
  - {id: error-budget, metric: days_error, max: 2.0}

cd ../regression
oloproof run

Gate: BLOCK (exit 1)
│ error-budget │ days_error │ FAIL  │ lower_bound_above_maximum │

│ days_error │ 2.66     │ [2.01, 3.57] │ mean of 120 observed · 0 missing · 0 excluded │

│ metadata.in_stock=false │ days_error │ 5.18     │ [4.60, 6.65] │ mean of 53 observed · ... │
│ metadata.in_stock=true  │ days_error │ 0.67     │ [0.51, 2.19] │ mean of 67 observed · ... │

FAIL, weil sogar die untere Schranke des Intervalls über dem Budget von zwei Tagen liegt. Ein Score-Evaluator hat kein Bestanden oder Nicht-bestanden pro Fall, daher listet oloproof inspect RUN_ID --failures keinen auf; lesen Sie stattdessen einen Fall:

oloproof inspect RUN_ID --case order_000

output: {
  "days": 6.1
}
judgments:
  days_error: score 4.9

Der Slice sagt, wo man suchen muss: Bestellungen ohne Lagerbestand liegen fünf Tage daneben. Der Kandidat (estimate_candidate) addiert fünf Tage für einen nicht vorrätigen Artikel:

oloproof run --config candidate.yaml

Gate: ALLOW (exit 0)
│ error-budget │ days_error │ PASS  │ upper_bound_meets_maximum │
│ days_error │ 0.70     │ [0.56, 1.57] │ mean of 120 observed · 0 missing · 0 excluded │

Fehlerbehebung

Symptom	Ursache und Abhilfe
Configuration error: evaluator 'recall' counts 'churned' as the positive class, and no case's 'label' is 'churned'	positive: nennt einen Wert, den kein Fall hat. Verwenden Sie den Wert genau so, wie er unter expected steht, einschließlich true gegenüber "true".
release rule ... refers to unknown metric 'false_positives'	Konfusionszählungen sind keine Metriken. Gaten Sie auf Recall oder Precision.
Ein Regressions-Evaluator wird vor dem Lauf abgewiesen	target_range fehlt oder ist leer. Deklarieren Sie den Bereich, den die Ziele tatsächlich annehmen können; ein breiterer Bereich ergibt ein breiteres Intervall.
Eine Ranking-Regel liest INSUFFICIENT_EVIDENCE (interval_unavailable)	Die Suite ist zu klein für das Intervall dieser Statistik, typischerweise pr_auc. Gaten Sie auf roc_auc oder fügen Sie Fälle hinzu.
Der Kandidat meldet die Zahlen der Baseline	Beide Läufe teilen eine version, daher wurden die gecachten Vorhersagen wiederverwendet. Geben Sie jeder Änderung ihre eigene Version.
Ein Fall ist missing statt falsch	Ihre Funktion hat eine Ausnahme geworfen, oder das Feld, das der Evaluator liest, fehlt oder ist keine Zahl. oloproof inspect RUN_ID --case ID zeigt den Fehler.

Einschränkungen

Kein empfohlener Schwellenwert. Der Sweep meldet, was jeder deklarierte Schwellenwert gemessen hätte.
Keine Metrik als Makro- oder Mikro-Mittel für Mehrklassen und keine Multi-Label-Unterstützung über einen Block pro Label hinaus.
Regression ist nur absoluter Fehler innerhalb eines deklarierten target_range: kein quadratischer Fehler, kein R-Quadrat und kein unbegrenzter Fehler.
Kalibrierung wird als Tabelle angezeigt, weder gegatet noch korrigiert.
Eine gepaarte Precision-Differenz deckt nur Zeilen ab, die beide Modelle markiert haben, wie Teil 1 zeigt.
Die Beispiele sind deterministisch und synthetisch. Ihre Entscheidungen zeigen die Mechanik, nicht wie sich ein echtes Modell auf echten Daten verhält.

Wie es weitergeht

Klassifikatoren und Regressoren ist die Referenz Feld für Feld.
Einen Kandidaten mit einer Baseline vergleichen und Vergleichsregeln behandeln den Vergleichsablauf.
Slices behandelt confidence:-Bänder und Slice-Support.
CI gaten listet die Exit-Codes auf.