Anleitungen

Referenz: Ergebnisse und Ausführung

Was ein Lauf an ein HTTP-System sendet und zurückerwartet, wie jeder Fall in den Nenner einer Metrik eingeht, die Entscheidungszustände und die Begründungscodes, die sie erklären, die Exit-Codes und welche Daten lokal bleiben oder in einen gehosteten Workspace wandern. Die Ideen dahinter stehen in Konzepte; die Policy-Felder in der Konfigurationsreferenz.

Der Vertrag eines HTTP-Systems

Ein HTTP-System (system.http in oloproof.yaml) wird einmal pro Fall und einmal pro Replikat aufgerufen.

Aspekt	Verhalten
Anfrage	Standardmäßig POST (GET und PUT werden akzeptiert). Der Body ist der input-Wert des Falls als JSON.
Header und Authentifizierung	Keine konfigurierbar. Die Anfrage trägt nur die Standardwerte des HTTP-Clients. Ein Endpunkt, der einen Schlüssel braucht, gehört hinter ein Python-Callable-System, das ihn hinzufügt.
Antwort	Muss JSON sein. output_path wählt die Ausgabe über einen Punktpfad wie result.answer; ohne ihn ist der ganze Body die Ausgabe. Ein fehlendes output_path-Feld wird als Ausführungsfehler für diesen Fall aufgezeichnet.
Artefakte	Jeder http.artifacts-Eintrag liest einen Punktpfad aus der Antwort. Ein deklariertes Feld, das in einer Antwort fehlt, ist ein Vertragsfehler, und der Lauf stoppt mit Exit 2.
Timeout	http.timeout_s pro Anfrage, standardmäßig 30 Sekunden.
Wiederholungen	Timeouts, Verbindungsfehler und HTTP 408, 429 und 5xx werden wiederholt, insgesamt bis zu vier Versuche, mit zufällig gestreutem exponentiellem Backoff, der Retry-After beachtet. Andere 4xx-Antworten werden nicht wiederholt.
Nach dem letzten Versuch	Die Ausführung des Falls wird als Fehler aufgezeichnet, und der Fall zählt als fehlend (oder als fehlgeschlagen unter on_execution_error: fail). Der Lauf geht weiter.
Nebenläufigkeit	Höchstens concurrency.system Anfragen gleichzeitig, standardmäßig 8.

URL, Methode, Ausgabepfad und Artefakt-Zuordnung gehen in die Version des Systems ein, das Verhalten des Servers aber nicht. Ändern Sie system.version, wann immer sich das Verhalten des Servers ändert; warum, steht in der Konfigurationsreferenz.

Drei verschiedene Vokabulare

Ein Ergebnis hat drei Arten von Zustand, und keine steht für eine andere.

Art	Werte	Beantwortet
Entscheidungszustand	PASS, FAIL, INSUFFICIENT_EVIDENCE, MANUAL_REVIEW	Was die Evidenz über eine Regel sagt.
Ausführungszustand	Laufstatus RUN_ERROR oder CANCELLED; Lauf-Vollständigkeit PARTIAL; Fallausführung ERROR oder TIMEOUT	Was mit dem Lauf oder dem Aufruf eines Falls geschah. Kein Qualitätsergebnis.
Release-Aktion	ALLOW, WARN, BLOCK	Was Ihre Policy mit jeder Entscheidung tut: Zustände in block_on blockieren, Zustände in warn_on warnen, andere lassen durch.

Ein Lauf, der normal endet, ist DECIDED, oder DECIDED_EARLY, wenn ein frühes Stoppen ihn beendet hat. Ein Lauf, der durch Ctrl-C oder Task-Abbruch unterbrochen wurde, ist CANCELLED; einer, dessen Harness eine Ausnahme warf, ist RUN_ERROR. Beides lässt den Lauf PARTIAL, behält die abgeschlossenen Fälle und erlaubt dem nächsten Lauf, ihre gecachten Datensätze wiederzuverwenden. Siehe Fehler.

Für eine Mindestschwelle T und ein Intervall [L, U] ist eine Regel PASS, wenn L >= T, FAIL, wenn U < T, und sonst INSUFFICIENT_EVIDENCE. Eine Höchstschwelle ist symmetrisch. Bevor sie das Intervall liest, prüft eine Regel, ob sie überhaupt entscheiden soll: zuerst die Gründe für MANUAL_REVIEW, dann die für INSUFFICIENT_EVIDENCE. Die erste Stufe mit einem Grund entscheidet und listet jeden Grund auf, den sie gefunden hat.

Begründungscodes

Jede Entscheidung trägt einen oder mehrere Begründungscodes.

MANUAL_REVIEW

Code	Bedeutung
policy_requires_review	Die Regel setzt requires_manual_review: true.
unsupported_method	Für diese Metrik gibt es in dieser Situation kein zugelassenes Intervall. Siehe unten.
unsupported_dependence_structure	Die Suite deklariert Cluster (group_id), und keine zugelassene Methode behandelt sie für diese Metrik.
approximate_method_not_permitted	Das einzige Intervall ist approximativ, und die Policy setzt nicht allow_approximate_methods: true.
evaluator_retired	Ein Evaluator hinter der Metrik wurde stillgelegt.

INSUFFICIENT_EVIDENCE

Code	Bedeutung
no_observations	Für diese Metrik wurde kein Fall beobachtet.
missingness_exceeds_policy	Mehr der zulässigen Fälle fehlen, als max_missing_fraction der Regel erlaubt.
missingness_unbounded	Die Methode lässt fehlende Fälle weg, statt sie zu begrenzen, und die Regel deklariert kein max_missing_fraction.
evaluator_not_validated	Ein Modell-Judge hinter der Metrik wurde nicht gegen menschliche Labels validiert, und require_validated_evaluators ist an (der Standard).
evaluator_recalibration_required	Der Judge wurde auf einem bereitgestellten Modell validiert, von dem die Urteile dieses Laufs nicht stammen.
interval_unavailable	Die Metrik hat kein Intervall zum Lesen.
insufficient_clusters	Weniger Cluster als min_clusters der Policy.
interval_monte_carlo_uncertain	Die Schwelle liegt innerhalb der Simulationsunsicherheit einer geclusterten Schranke.
interval_overlaps_threshold	Das Intervall enthält die Schwelle. Mehr Fälle würden es verengen.
interval_unbounded	Das Intervall hat keine Schranke auf der Seite, die die Regel liest.
missing_could_change_outcome	Eine observed_count-Regel: Die fehlenden Fälle könnten die Fehlschläge über max_failures bringen.
interval_overlaps_zero, interval_overlaps_margin, interval_overlaps_margins	Ein Vergleich, dessen Differenzintervall null oder eine Marge überspannt.
insufficient_support	Eine Slice-Vergleichsregel, deren Slice weniger Fälle hat als ihr min_support.
family_correction_withheld	Eine Regel in einem families:-Eintrag, vor der die Holm-Korrektur angehalten hat.

PASS und FAIL

Code	Zustand
lower_bound_meets_minimum, upper_bound_meets_maximum	PASS
upper_bound_below_minimum, lower_bound_above_maximum	FAIL
observed_failures_within_limit	PASS
observed_failures_exceed_limit	FAIL
difference_above_zero, lower_bound_above_margin, interval_within_margins	PASS (Vergleich)
difference_below_zero, upper_bound_below_margin, interval_outside_margins	FAIL (Vergleich)
cost_ceiling_exceeded	Steht neben dem Zustand einer Kostenregel, deren deklarierte Obergrenze eine aufgezeichnete Ausführung überschritten hat

Nur im gehosteten Workspace

Ein Workspace, der einen gepushten Lauf selbst entscheidet, kann eine Entscheidung zurückhalten mit ppi_not_verified (er hat das Intervall, auf dem die Entscheidung beruht, nicht verifiziert), execution_not_verified (die Ausgaben stammen nicht von einem registrierten Runner) oder workspace_cannot_decide (er hält keine Kopie der Policy oder konnte die Evidenz nicht lesen). Siehe Gating.

Wie jeder Fall in den Nenner eingeht

Jede Metrik meldet vier Zählungen: n_total (Fälle in der Suite), n_eligible, n_observed und n_missing, mit n_eligible = n_observed + n_missing. Fälle außerhalb von n_eligible stehen unter exclusions mit einem Grund.

Was mit dem Fall geschah	Zählt als	Im Nenner
Der Evaluator lieferte bestanden oder nicht bestanden	beobachtet, Erfolg oder Fehlschlag	ja
Der Evaluator erklärte sich für nicht anwendbar (zum Beispiel kein erwarteter Wert zum Vergleichen)	ausgeschlossen, mit Grund	nein
Der Systemaufruf schlug fehl oder lief in ein Timeout	fehlend, oder Fehlschlag unter on_execution_error: fail	ja
Der Evaluator warf eine Ausnahme, oder die Antwort eines Judges war nicht lesbar	fehlend	ja
Der Fall lief nie, weil der Lauf unterbrochen wurde	fehlend, und der Lauf ist PARTIAL	ja

Ein fehlender Fall wird begrenzt, nicht weggelassen. Für eine Bestehensrate behandelt die untere Schranke des Intervalls jeden fehlenden Fall als Fehlschlag und die obere als Erfolg, sodass ein Lauf mit vielen fehlenden Fällen ein breites Intervall hat, das keine anspruchsvolle Regel bestehen kann; ein begrenzter Mittelwert setzt auf dieselbe Weise die Enden seines deklarierten Bereichs ein. Eine Methode, die fehlende Fälle nicht begrenzen kann (etwa eine Ranking-Statistik), lässt sie weg und zeichnet die Annahme auf, und eine Regel darüber liest missingness_unbounded, bis sie max_missing_fraction deklariert.

Eine observed_count-Regel zählt Fehlschläge über die ausgeführte Suite und liest kein Intervall. Sie besteht nur, wenn die beobachteten Fehlschläge plus jeder fehlende Fall noch in max_failures passen.

Metriken ohne zugelassenes Intervall

Eine Regel entscheidet nur auf einem Intervall, dessen Methode durch ein Audit zugelassen wurde. Wo keines existiert, wird die Metrik trotzdem berechnet und angezeigt, und eine Regel darüber leiht sich keine unvalidierte Methode:

Situation	Was eine Regel darüber liest
Eine Score-Metrik (Mittelwert) ohne deklarierten Bereich, etwa ein eigener Score-Evaluator ohne score_range	MANUAL_REVIEW, unsupported_method
Eine Mittelwert-, Quantil-, Ranking- oder Kostenmetrik auf einer Suite, die group_id deklariert	MANUAL_REVIEW, unsupported_dependence_structure
Eine Bestehensrate auf einer geclusterten Suite	ein approximatives Intervall: MANUAL_REVIEW, außer bei allow_approximate_methods: true, dann die Cluster-Prüfungen oben
Eine Quantil- oder Ranking-Metrik mit replicates über 1	MANUAL_REVIEW, unsupported_method
Jede Metrik auf einer Suite mit group_id und Replikaten zugleich	MANUAL_REVIEW, unsupported_dependence_structure
Ein Vergleich auf einer geclusterten Suite	MANUAL_REVIEW
Ein Slice unter min_slice_support	kein Intervall, aber Slices erreichen das Gate nie
Metriken human_score, human_preference oder cost_per_accepted	beim Lesen der Datei abgewiesen, Exit 2

Exit-Codes

oloproof gate, oloproof run mit einer Policy und die anderen entscheidenden Befehle verwenden alle dieselben Codes.

Code	Bedeutung
0	Nichts, worauf die Policy blockiert: Jede Regel hat bestanden, oder die übrigen liegen außerhalb von block_on.
1	Eine Regel in block_on ist durchgefallen.
2	Die Konfiguration oder der Aufruf war falsch, oder ein System hat seinen Vertrag gebrochen; nichts wurde entschieden.
3	Eine Regel in block_on las INSUFFICIENT_EVIDENCE.
4	Eine Regel in block_on las MANUAL_REVIEW.
5	Der Lauf wurde nicht abgeschlossen, und block_on_partial_run ist an (der Standard).

Wenn mehrere zutreffen, wird der erste von 1, 5, 4, 3 gemeldet. Ein Zustand, der nicht in block_on steht, kann den Exit-Code nicht ändern: Mit block_on: [FAIL] und warn_on: [INSUFFICIENT_EVIDENCE] warnt eine unentschiedene Regel, und das Gate endet mit 0. Exit 0 bedeutet daher nur, dass nichts eingetreten ist, worauf Ihre Policy blockiert, nicht dass jede Regel bestanden hat. Siehe Gating.

Wo die Arbeit läuft und wohin die Daten gehen

Lokal, der Standard

oloproof run, oloproof gate und das SDK laufen auf Ihrem Rechner. Jeder Datensatz (Fälle, Ausgaben, Artefakte, Urteile, Metriken und Entscheidungen) wird in .oloproof/store.sqlite neben oloproof.yaml geschrieben, oder unter OLOPROOF_HOME, wenn gesetzt. Nichts wird an Oloproof gesendet. Der einzige Netzwerkverkehr ist der, den Ihre Konfiguration verursacht: Aufrufe an die URL Ihres HTTP-Systems und Aufrufe, die ein Modell-Judge oder Modell-Klassifikator an seinen Provider macht, der den beurteilten Fallinhalt erhält und Ihnen dafür Rechnung stellt.

In einen gehosteten Workspace pushen

oloproof push sendet die Evidenz eines Laufs an den Workspace, den Sie mit oloproof login verbunden haben. Standardmäßig sendet es Metriken, Intervalle, Entscheidungen und aggregierte Slices sowie Identität, Status, Zeiten und Verbrauch jedes Datensatzes, aber nicht seinen Inhalt. Roher Inhalt wird Feld für Feld geschwärzt, bevor irgendetwas den Rechner verlässt, und ein geschwärzter Datensatz sagt, welche Kategorien zurückgehalten wurden. Eine Kategorie geht nur mit, wenn egress: in oloproof.yaml sie aufführt:

Kategorie	Was sie umfasst
raw_inputs	Szenario-Eingaben, erwartete Werte und Fall-Metadaten: die Zeilen des Datensatzes
raw_outputs	Was das getestete System für jeden Fall zurückgab
judge_rationales	Der Text, mit dem ein Judge ein Urteil begründet hat und der die Ausgabe zitiert
artifacts	Retrieval-Kontext, Zitate und Trajektorien, die während eines Laufs aufgezeichnet wurden
error_detail	Ausnahmemeldungen und Details, die oft die Eingabe wörtlich enthalten
system_config	Die deklarierte Konfiguration des getesteten Systems und seiner Evaluatoren
label_notes	Die Notiz, die eine Person neben ein Label geschrieben hat und die oft die Ausgabe zitiert
span_names	Trace-, Span-, Tool- und Agentennamen, die eine Instrumentierung aufgezeichnet hat

Datensatz-Digests werden nach dem Schwärzen nicht neu berechnet, sodass ein gehosteter Datensatz weiterhin die ursprüngliche Evidenz benennt, die auf Ihrem Rechner bleibt. Schwärzen ist keine Verschlüsselung, und eine Metrik über einen sehr kleinen Slice kann die Fälle dahinter dennoch identifizierbar machen.

Wenn Reviewer Fälle in der gehosteten Review-Queue labeln, holt ihr Browser den Fallinhalt von oloproof collect, das auf Ihrer Seite läuft; er geht nicht durch den Workspace. Provider-Schlüssel, die ein Workspace verwendet, werden mit oloproof credentials set gespeichert, und oloproof credentials list zeigt ihre Namen, nie ihre Werte. Ein verwalteter Job läuft auf einem Worker, den Oloproof betreibt und der Ihren Python-Code nicht ausführt; oloproof job meldet sein Ergebnis und endet entsprechend seinem Gate.

In einem gehosteten Workspace verwendet die Engine gecachte Ausführungen, Urteile oder Analysen nie wieder, weil ein Push diese Caches beschreiben kann; sie berechnet sie neu.