Anleitungen

Ein trainiertes Modell validieren

Ein trainiertes Modell kann auf einer Suite, die es schon gesehen hat, gut abschneiden, seine Antwort ändern, wenn sich eine Eingabe ein wenig bewegt, und einen glücklichen Seed erwischen. Oloproof prüft jeden dieser Punkte, bevor das Modell ausgeliefert wird: die Suite gegen die Trainingsdaten, jede Vorhersage unter deklariertem Rauschen und das Trainingsrezept über mehrere Seeds. Kopieren Sie das Beispiel mit oloproof init --example model-validation: ein Kreditmodell, mit NumPy offline auf synthetischen Daten trainiert.

Die Suite gegen die Trainingsdaten

oloproof leakage check --training data/training.jsonl --record

Jeder Fall wird mit jeder Trainingszeile auf exakte Übereinstimmung verglichen, nachdem Zeichenketten kleingeschrieben und Leerraum zusammengefasst wurden (--round rundet Zahlen, --field nennt die zu vergleichenden Schlüssel). Die Trainingsdatei wird auf Ihrem Rechner gelesen und nie gespeichert oder gesendet; der Datensatz behält Fall-IDs und Anzahlen. Deklarieren Sie leakage: required in release.yaml, und das Gate ist blockiert (Exit-Code 3), bis eine saubere Prüfung dieser Suite aufgezeichnet ist. Ein in den Trainingsdaten gefundener Fall macht die Evidenz ungültig; er ist kein FAIL des Modells. Beinahe-Duplikate werden nicht geprüft.

Vorhersagen unter Rauschen

metamorphic:
  transforms:
    - name: noise
      field: features
      perturb: {kind: numeric_noise, scale: {income: 1.0, debt_ratio: 0.02}, seed: 7}
evaluators:
  - {type: metamorphic_relation, relation: same_label, transform: noise, field: label, passes_when: flipped}

Jeder Fall erhält eine Kopie mit geseedetem Rauschen auf den genannten Zahlen, und flips_under_noise ist der Anteil der Fälle, deren Label sich geändert hat. categorical_swap ersetzt Werte nach einer deklarierten Zuordnung, und blur, brightness, occlusion und jpeg verändern Bilder. Ein Regressor verwendet same_score_within mit einer Toleranz. Menschen können nicht beurteilen, ob Rauschen auf einer Zeile deren Bedeutung erhält, daher ist eine numerische Perturbation deklariert: Ihre Rate wird berichtet, und eine Regel darauf ergibt INSUFFICIENT_EVIDENCE mit transform_declared. Eine Bildtransformation entscheidet ein Gate, sobald die Labels von Menschen zeigen, dass sie die Bedeutung jedes Bildes erhält, wie eine Texttransformation. Das Projekt image/ des Beispiels zeigt beides: eine Unschärfe, die ihre Labels prüfen und deren Kipprate an einer Obergrenze scheitert, und einen grauen Fleck, der laut seinen Labels den Kratzer manchmal verdeckt und dessen Regel nicht entscheidet.

Das Rezept über Seeds

Der Checkpoint, den Sie ausliefern, wird auf seinem eigenen Lauf entschieden, wie jedes System. Eine zweite Frage ist, ob Ihre Art zu trainieren gut genug ist: Trainieren Sie nächsten Monat neu, erhalten Sie eine andere Ziehung. Trainieren Sie k Checkpoints mit k Seeds, führen Sie jeden auf derselben Suite aus und benennen Sie die Läufe:

seeds:
  recipe: loan-model
  checkpoints: {seed_1: latest~4, seed_2: latest~3, seed_3: latest~2, seed_4: latest~1, seed_5: latest}
  rule: {id: recipe_accurate, criterion: correct, min: 0.8}

oloproof seeds seeds.yaml --policy recipe.yaml liest die erwartete Bestehensrate über Seeds, mit einem Intervall, das sowohl die Fälle der Suite als auch die versuchten Seeds berücksichtigt. Im Beispiel erreichen fünf Seeds 85,7 % bis 90,3 %, und das Rezept ergibt 88,2 %, 83,2 % bis 91,9 %: PASS gegen 80 %. Das Intervall ist approximativ, daher braucht die Policy allow_approximate_methods: true, sonst lautet die Antwort MANUAL_REVIEW. Die Policy muss mindestens eine Regel enthalten; der Befehl liest ihr Konfidenzniveau, die Zustimmung und ihre Judge-Schwellen, sonst nichts. Er listet auch die Fälle auf, deren Urteil sich von einem Seed zum anderen ändert, und --html FILE schreibt eine Offline-Seite mit jedem Fall unter jedem Checkpoint.

Jeder Checkpoint zählt. Ein Seed, dessen Training fehlschlug, bleibt erhalten, und jeder Fall, den er nicht beantwortet hat, zählt für die untere Grenze als Fehlschlag und für die obere als Erfolg, sodass er das Intervall verbreitert. Weniger als drei Seeds ergeben INSUFFICIENT_EVIDENCE; etwa fünf sind nötig, um überhaupt etwas zu entscheiden. Ein Judge, dem das Gate nicht vertrauen würde, entscheidet auch kein Rezept. Jeder Checkpoint muss dieselbe Suite ausführen, mit je einer Systemversion, und eine Suite, die Gruppen deklariert, wird abgelehnt.

Was Ihnen das nicht sagen kann

Perturbationen, die niemand deklariert hat. Nur die deklarierten Transformationen werden versucht, in den deklarierten Größen, und eine niedrige Kipprate sagt nichts über größere Änderungen oder die Suche eines Angreifers.
Zertifizierte Robustheit. Für keine Eingabe wird eine Schranke bewiesen; die Kipprate ist eine Rate über die Fälle der Suite.
Wie das Modell trainiert wurde. Oloproof kann nicht sehen, ob die Seeds gewählt wurden, bevor irgendein Checkpoint evaluiert war, ob fehlgeschlagene Läufe verworfen wurden oder ob sich die Checkpoints nur durch ihren Seed unterscheiden.
Ein Fehlschlag, der seltener ist als etwa ein Seed von k. Scheitert das Rezept einmal in zehn Trainings und keiner von fünf Seeds ist gescheitert, kann das Intervall es nicht wissen.
Leakage, das die Trainingsdatei nicht zeigt: Beinahe-Duplikate, ein skaliertes Bild oder Zeilen, die zum Tuning verwendet, aber aus der Datei weggelassen wurden.
Leakage in den Seed-Läufen. oloproof seeds liest leakage: required nicht; der Checkpoint, den Sie ausliefern, wird auf seinem eigenen Lauf gegated, der es liest.

Was keine Evaluation Ihnen sagen kann, steht auf einer eigenen Seite.