Konfigurationsreferenz

Jedes Feld von oloproof.yaml und release.yaml, mit seinem Typ, seinem Standardwert, den akzeptierten Werten und einem Beispiel, entnommen den Modellen, die die Dateien lesen. Schlagen Sie hier ein Feld nach; den Ablauf lernen Sie auf den Seiten Schnellstart und Gating.

Beide Dateien werden validiert, bevor etwas läuft. Ein unbekanntes Feld, ein falsch geschriebenes Feld oder ein Wert vom falschen Typ ist ein Konfigurationsfehler, und der Befehl endet mit 2, ohne einen Fall auszuführen. Beide Dateien haben JSON-Schemas, die ein Editor, der JSON Schema liest, zur Vervollständigung nutzen kann. Das installierte Paket schreibt sie zusammen mit den Ergebnis-Schemas in schemas/v1/ unter dem aktuellen Verzeichnis: python -m oloproof_core.models.schema_export (die beiden heißen project_config.schema.json und release_policy.schema.json).

In den Tabellen unten bedeutet "erforderlich", dass die Datei ohne das Feld abgewiesen wird; jedes andere Feld zeigt den Wert, der verwendet wird, wenn es fehlt.

oloproof.yaml auf einen Blick

Ein kleines, vollständiges Projekt. Es führt eine Python-Funktion lokal aus, braucht weder Netzwerk noch Schlüssel und hat die Form, die oloproof init anlegt.

# oloproof.yaml
version: 1
project: support-bot
dataset: datasets/support.jsonl
system:
  name: support-bot
  callable: app.bot:answer
evaluators:
  - type: exact_match
    criterion: correct_label
    field: label

Felder der obersten Ebene

concurrency

Einträge in pricing

Oloproof liefert keine Preistabelle mit. Jeder Eintrag benennt ein Modell genau so, wie es das model: eines Evaluators benennt.

# oloproof.yaml
version: 1
project: support-bot
dataset: datasets/support.jsonl
system:
  name: support-bot
  callable: app.bot:answer
evaluators:
  - type: exact_match
    criterion: correct_label
    field: label
pricing:
  - model: my-judge-model
    input_per_mtok: 0.15
    output_per_mtok: 0.6
egress: [raw_outputs]

system

Ein System braucht genau eines von callable, http oder rag.

system.http

# oloproof.yaml
version: 1
project: support-api
dataset: datasets/support.jsonl
system:
  name: support-api
  version: "2026-10-08"
  http:
    url: http://localhost:8000/answer
    output_path: answer
    artifacts:
      retrieval/v1: debug.retrieval
evaluators:
  - type: hit_rate
    k: 5

Der Vertrag für Anfrage und Antwort und was bei Timeouts und HTTP-Fehlern geschieht, stehen in Ergebnisse und Ausführung.

system.rag

Hier angegebene Einstellungen überschreiben die, die die Klasse deklariert. Ein gestuftes System zeichnet seine eigenen Artefakte retrieval/v1, context/v1 und citations/v1 auf, daher wird records daneben abgewiesen. Siehe RAG.

evaluators

Jeder Eintrag nimmt einen type und diese beiden gemeinsamen Felder:

fail gilt nur für Bestanden/Nicht-bestanden-Evaluatoren; ein Score-Evaluator damit ist ein Konfigurationsfehler. on_execution_error ist ein YAML-Feld; die SDK-Evaluatorklassen nehmen kein solches Argument, und ein fehlerhafter Fall zählt als fehlend.

Evaluatortypen

"Liest" führt auf, wovon das Urteil des Evaluators abhängt, und damit auch, worauf sein gecachtes Urteil verschlüsselt ist. "SDK" benennt die Klasse in oloproof.evaluators.

Ein Judge, der ein gehostetes Modell aufruft, sendet Fallinhalt an diesen Provider und wird von ihm abgerechnet. Schlüssel werden aus der in api_key_env benannten Umgebungsvariable gelesen; Oloproof speichert sie nie in diesen Dateien.

Deterministische Evaluatoren

Modell-Judges

rubric_judge, groundedness_judge und citation_support_judge teilen diese Felder. Genau eines von rubric_file oder rubric_text verlangt rubric_judge; die beiden RAG-Judges nehmen höchstens eines und verwenden sonst eine eingebaute Rubrik. Ihr criterion ist standardmäßig groundedness und citation_support.

probability_judge stellt eine typisierte Frage und liest die Wahrscheinlichkeiten des Modells:

cascade führt zuerst einen günstigen Judge aus und eskaliert die unsicheren Fälle:

Die Stufen beurteilen das eigene criterion der Kaskade; eine Stufe, die ein anderes benennt, wird abgewiesen.

model_classifier bewertet Text mit einem trainierten Modell auf einem TEI-kompatiblen Server:

RAG-Evaluatoren

Agenten-Evaluatoren

Jeder Agententyp hat ein Standard-criterion, es darf also fehlen: sein eigener Typname oder einer, der aus seiner Einstellung gebildet wird (agent_steps_le_8, agent_tool_lookup_called, agent_handoffs_le_2). Siehe Agenten.

Prädiktive Evaluatoren

Ein prädiktiver Evaluator, der positive, field oder expected_field nicht angibt, übernimmt sie aus dem predictive:-Block; ein Wert, den er angibt, bleibt erhalten.

predictive

metrics

Jedes Evaluator-Kriterium ist bereits eine Metrik. Ein metrics:-Eintrag fügt eine weitere hinzu, unterschieden durch type.

# oloproof.yaml
version: 1
project: support-bot
dataset: datasets/support.jsonl
system:
  name: support-bot
  callable: app.bot:answer
evaluators:
  - type: exact_match
    criterion: correct_label
    field: label
metrics:
  - id: latency_p95
    type: quantile
    source: latency_ms
    quantile: 0.95

release.yaml

Die Release-Policy: welche Regeln entscheiden und welche Entscheidungen blockieren. Weggelassene Einstellungen behalten ihre Standardwerte, sodass eine Policy, die nur ihre Regeln nennt, weiterhin auf FAIL, INSUFFICIENT_EVIDENCE und MANUAL_REVIEW blockiert.

# release.yaml
version: 1
rules:
  - id: label_accuracy
    metric: correct_label
    min: 0.8

rules

Eine Liste enthält beide Arten. Eine Laufregel nimmt genau eines von min, max oder max_failures. Eine Vergleichsregel nennt ihre kind und entscheidet eine Differenz zwischen zwei Läufen; siehe Vergleichsregeln.

families

# release.yaml
version: 1
warn_on: [INSUFFICIENT_EVIDENCE]
block_on: [FAIL, MANUAL_REVIEW]
rules:
  - id: label_accuracy
    metric: correct_label
    min: 0.8
    max_missing_fraction: 0.05
  - id: no_regression
    metric: correct_label
    kind: non_inferiority
    margin: 0.02

Artefaktarten

Ein Artefakt ist ein typisierter Datensatz, den ein System neben seine Ausgabe schreibt, etwa was es abgerufen hat. Eine Art ist ein kleingeschriebener Name mit optionaler Version, passend zu ^[a-z][a-z0-9_]*(/v[1-9][0-9]*)?$. Evaluatoren, die ein Artefakt brauchen, benennen es, und ein Lauf, dessen System eine erforderliche Art nicht deklariert, wird vor dem Start abgewiesen, statt jeden Fall als fehlend zu zählen.

Ein Callable-System deklariert die Arten, die es aufzeichnet, in records: (oder @system(records=...)); ein HTTP-System in http.artifacts; ein gestuftes RAG-System zeichnet seine eigenen auf.

Versionen, Cache-Schlüssel und Invalidierung

Oloproof verwendet Arbeit wieder, deren Eingaben sich nicht geändert haben, und entscheidet anhand von Inhalts-Digests, was "unverändert" bedeutet. Jeder wird von der Engine berechnet und mit dem Lauf aufgezeichnet.

Was Oloproof nicht sehen kann, müssen Sie deklarieren:

• Das Verhalten eines HTTP-Systems liegt auf dem Server. Ändern Sie system.version, wann immer sich ändert, was hinter der URL steht, sonst steht eine alte gecachte Ausgabe für das neue System.
• Die Hilfsmodule eines Callables werden nur gehasht, wenn code_paths sie erfasst. Ohne das ändert das Bearbeiten eines Hilfsmoduls die Version nicht.
• Eine Methode oder ein aufrufbares Objekt muss eine Version deklarieren, und die Version muss sich ändern, wenn sich der Zustand des Objekts ändert.
• Ein RAG-Index wird durch index_version identifiziert; ändern Sie sie, wenn der Index neu gebaut wird.
• Die Identität eines Modell-Judges sind seine Einstellungen, nicht die Gewichte des Providers. Wenn ein Provider das Modell hinter demselben Namen aktualisiert, erkennt der Cache das nicht.
• Ein eigener @evaluator hasht die Moduldatei, die ihn definiert, und seine Urteile werden über Läufe hinweg nur wiederverwendet, wenn er cacheable=True deklariert. Eingebaute Rubrik-Judges sind cachebar; deterministische Evaluatoren werden neu berechnet, was günstig ist.

Gecachte Arbeit liegt im lokalen Store des Projekts, .oloproof/store.sqlite neben oloproof.yaml (oder unter OLOPROOF_HOME). Das Löschen des Stores verwirft jeden Cache und jeden Lauf. In einem gehosteten Workspace verwendet die Engine gecachte Ausführungen, Urteile oder Analysen nicht wieder, weil ein Push sie schreiben kann; sie berechnet neu.