Zum Inhalt springen
Doku
ÄnderungsprotokollPreiseKonsole öffnen

Anleitungen

Was eine Evaluation nicht sagen kann

Jedes Ergebnis von Oloproof ist eine gemessene Aussage mit benannten Grenzen. Diese Seite listet die Grenzen auf, die für jede Art von System gelten; jede Leitfadenseite nach System fügt unter „Was das nicht sagen kann“ ihre eigenen hinzu.

Was kein Ergebnis sagt

  • Eingaben, die der Suite nicht ähneln. Eine Entscheidung ist eine Aussage über die Population, aus der die Suite zieht, und sie ist nur so gut, wie die Suite eine faire Stichprobe dessen ist, was Ihrem System begegnen wird. Oloproof kann das nicht prüfen; eine neue Art von Eingabe oder der Verkehr des nächsten Monats liegt außerhalb davon (Wie weit ein Ergebnis reicht).
  • Dass eine Prüfung nie fehlschlagen kann. Eine Prüfung, die bei allen 300 Fällen bestanden hat, begrenzt, wie oft sie fehlschlägt (höchstens etwa 1,2 % bei 95 % Konfidenz); sie ist kein Beweis.
  • Wie Ihr System beim nächsten Mal antwortet. Ein Lauf misst eine Antwort pro Fall, es sei denn, Sie verlangen replicates: (Eine Suite schreiben).
  • Was die Scores eines ungeprüften Judges bedeuten. Ein Judge, der nie mit den Labels von Menschen verglichen wurde, bleibt UNVALIDATED, und seine Pass-Rate ist die Meinung des Judges. Eine Policy mit require_validated_evaluators: true lässt ihn nicht entscheiden (Judges).
  • Dass eine Regel fehlgeschlagen ist, wenn sie „noch nicht belegt“ sagt. INSUFFICIENT_EVIDENCE bedeutet, dass das Intervall die Schwelle noch überspannt, nicht dass das System sie verfehlt hat; oloproof plan sagt, wie viele weitere Fälle sie entscheiden würden.
  • Kosten oder Latenz, es sei denn, eine Regel fragt danach. Eine Release-Entscheidung deckt die Regeln ab, die Ihre Policy deklariert; ein Budget auf ein Latenz-Quantil oder auf die Kosten pro akzeptierter Aufgabe ist eine max:-Regel, die Sie hinzufügen (Gating).
  • Ob eine wiederverwendete Antwort noch aktuell ist. Eine gecachte Ausgabe oder ein gecachtes Urteil ist das frühere, wiederverwendet, weil ihre Eingaben gleich hashen; eine Änderung, die der Hash nicht sieht (ein Modell, das sich hinter demselben Namen geändert hat, eine Datei, die das System liest, aber nicht importiert, eine Umgebungsvariable), wird nicht gesehen (Versionen, Cache-Schlüssel und Invalidierung).
  • Einen Slice, den Sie nach dem Hinsehen gewählt haben. Slice-Ergebnisse sind Aussagen unter der deklarierten Korrektur für die Slices, die Sie deklariert haben; ein Schnitt, der gewählt wurde, weil er interessant aussah, trägt keine solche Garantie, und Slices gaten nie (Slices).
  • Warum ein Fall fehlgeschlagen ist. Evaluatoren sagen, was passiert ist; eine Ursache braucht eine Intervention neben einer Kontrolle, und selbst dann nennt Oloproof einen zu testenden Faktor, keine belegte Ursache.
  • Zeitlich geordnete Fälle, als wären sie unabhängig. Eine Suite, die time_order deklariert, liest MANUAL_REVIEW statt eines Intervalls, das unabhängige Fälle annimmt (Geclusterte Fälle).
  • Eine Metrik ohne zugelassenes Intervall. Eine Regel, die eines bräuchte, liefert MANUAL_REVIEW oder INSUFFICIENT_EVIDENCE mit ihrem Grund, statt eine nicht validierte Methode zu borgen.

Nach Art des Systems

Wie es weitergeht