Eine Änderung, von Anfang bis Ende

Ihr Score ist nach einer Änderung gestiegen. Diese Seite verfolgt eine echte Änderung durch jede Frage, die Oloproof stellt, bevor es die Änderung ausliefern lässt: Ist der Judge vertrauenswürdig, erreicht die Änderung die Schwelle für sich allein, ist sie besser als das, was sie ersetzt, nach dem Judge und nach Menschen, und was als Nächstes zu versuchen ist. Das System ist ein kleiner Support-Bot, der aus 40 Dokumenten antwortet, ausgeführt auf Ihrem Rechner mit lokalen Modellen; jede Zahl unten ist das, was die Engine ausgegeben hat. Kopieren Sie es aus examples/one_change und führen Sie REVIEWER=yourname ./run_demo.sh aus.

Die Änderung

Der Baseline-Prompt weist den Bot an, die exakten Zahlen, Namen und Einheiten beizubehalten. Der Kandidat verlangt einen oder zwei warme, natürliche Sätze. Beide laufen auf denselben 120 Fragen, mit einer deterministischen Prüfung (answer_correct: enthält die Antwort den erwarteten Fakt) und einem lokalen Modell-Judge (judge_correct: antwortet sie mit demselben Fakt):

oloproof run --policy release.yaml
oloproof run --config candidate.yaml --policy release.yaml

Richtige Antworten stiegen von 80.0% auf 82.5%, die Bestehensrate des Judges von 82.5% auf 83.3%. Das ist die scheinbare Verbesserung. Noch entscheidet keiner der beiden Runs etwas: Die Release-Regel liest den Judge, und der Judge wurde nicht geprüft, also lautet die Regel INSUFFICIENT_EVIDENCE mit evaluator_not_validated.

Kann man dem Judge vertrauen?

Menschen labeln eine blinde Zufallsstichprobe der Antworten des Kandidaten, ohne das Urteil des Judges, und die Engine misst den Judge an ihnen:

oloproof review CANDIDATE --criterion judge_correct --by you

In der aufgezeichneten Sitzung stimmte der Judge bei 77 von 79 gelabelten Fällen überein (97.5%, untere Grenze 91.2%), mit einem Bias von -2.5 Punkten, innerhalb der Standardschwellen (Übereinstimmung 0.70, Bias 0.35); er wurde also validiert und darf entscheiden. In dieser Sitzung wurden die Labels von einem Agenten gegeben, der für einen Reviewer einsprang; das zeigt den Ablauf und ist nicht das Urteil eines Menschen. Wenn Sie es ausführen, sind Sie der Reviewer.

Erreicht der Kandidat die Schwelle für sich allein?

release.yaml verlangt eine Bestehensrate des Judges von mindestens 80%:

oloproof gate CANDIDATE --policy release.yaml --config candidate.yaml

83.3% mit einem Bereich von 75.4% bis 89.6% überspannt 80%, also lautet die Regel INSUFFICIENT_EVIDENCE, und die Engine sagt, dass etwa 592 Fälle sie entscheiden würden. Ein vertrauenswürdiger Judge macht ein knappes Ergebnis nicht eindeutig.

Ist er besser als die Baseline?

compare.yaml stellt zwei Fragen. Ist der Kandidat nach dem Judge besser, nur gültig, wenn Menschen zeigen, dass der Judge sich bei beiden Prompts gleich irrt (judge_bias_bar: 0.10)? Und ist er nach den eigenen Labels der Menschen zu beiden Antworten derselben Fälle (people_pass_diff, eine human_difference-Metrik) nicht mehr als 10 Punkte schlechter?

oloproof review CANDIDATE --against BASELINE --criterion judge_correct --by you --sample 40
oloproof compare CANDIDATE BASELINE --policy compare.yaml --config candidate.yaml

Das Review zeigt beide Antworten als A und B, in einer per Münzwurf bestimmten Reihenfolge, ohne die Runs zu nennen. In der aufgezeichneten Sitzung betrug die Differenz des Judges +0.8 Punkte (-5.1 bis +7.3): INSUFFICIENT_EVIDENCE, und etwa 3,690 gepaarte Fälle wären nötig, um sie zu entscheiden. Menschen ließen den Kandidaten 36-mal und die Baseline 35-mal in 40 Paaren bestehen: +2.5 Punkte (-11.1 bis +17.7), also war „nicht mehr als 10 Punkte schlechter" ebenfalls INSUFFICIENT_EVIDENCE. Das Gate blockierte. Die Änderung war eine Stiländerung, die die Scores kaum bemerkten, und 120 Fälle können eine Änderung um 1 Punkt nicht von keiner unterscheiden.

Warum scheitert er dort, wo er scheitert?

oloproof diagnose CANDIDATE --intervention gold-context --criterion answer_correct --config candidate.yaml

Die Engine führte die 21 Fehlschläge erneut aus, mit der richtigen Passage für das Modell, und noch einmal ohne sie als Kontrolle. Die Kontrolle holte keinen zurück; die richtige Passage holte 14 zurück: 7, bei denen das Retrieval die Passage nie fand, 7, bei denen sie gefunden, aber unter den Top 3 eingeordnet wurde, und 7, die trotzdem scheiterten. Sie schlug ein tieferes top_k als Hypothese vor und testete es dann auf denselben Fällen:

oloproof diagnose CANDIDATE --intervention top-k --top-k 8 --criterion answer_correct --config candidate.yaml

Alle 7 zu tief eingeordneten Fälle wurden zurückgeholt, mit einer Kontrolle, die keinen zurückholte.

Der nächste Schritt

followup.yaml ist der Kandidat mit top_k: 8, eine neue Systemversion, vollständig ausgeführt:

oloproof run --config followup.yaml --policy release.yaml
oloproof compare FOLLOWUP CANDIDATE --policy followup_compare.yaml --config followup.yaml

Ihre Bestehensrate des Judges lag bei 90.0% (83.1% bis 94.8%), also war die Untergrenze von 80% PASS. Gegenüber dem Kandidaten blieb „mehr richtige Antworten" (+3.3 Punkte) INSUFFICIENT_EVIDENCE, und „Bestehensrate des Judges nicht mehr als 5 Punkte schlechter" war PASS. Der Judge wurde an den Antworten des Kandidaten geprüft, nicht an denen des nächsten Schritts, und niemand hat ein Paar des nächsten Schritts gelabelt, also entscheidet die Differenz nach Menschen dort nichts.

Was das nicht sagen kann

Ein kleiner Bot, eine Änderung, 120 Fälle und lokale Modelle. Es zeigt, wie die Engine jede Entscheidung bei einer echten Änderung erreicht; über ein anderes System sagt es nichts. Eine lokale Stichprobe ist guter Glaube: Nur eine Stichprobe, die ein Workspace zieht, wird dort geprüft. Der vollständige Bericht mit jeder Run-ID ist docs/audits/DOGFOOD_LARKSPUR_2026-10-26.md. Siehe Judges, Vergleichsregeln, RAG-Evaluation und Grenzen.