Anleitungen

Eine zweite Meinung zu den Scores eines anderen Werkzeugs

Ihr Eval-Score ist gestiegen. Ist das echt? Und können Sie dem Judge trauen, der ihn gemessen hat? Wenn Sie bereits mit einem anderen Werkzeug evaluieren, exportieren Sie dessen Ergebnisse pro Fall vor und nach einer Änderung, und Oloproof beantwortet beide Fragen anhand dieser Ergebnisse, ohne etwas erneut auszuführen.

Was es liest

Eine Datei pro Systemversion, CSV oder JSON Lines, mit einer Zeile pro Fall und Kriterium:

Spalte	Was sie enthält
case_id	Die ID des Falls. Zwei Dateien werden nur über eine ID gepaart, die beide enthalten
criterion	Der Name der Metrik, der zu der Metrik wird, die eine Regel benennt
score	Eine Zahl auf der Skala der Metrik, oder leer, wenn das Werkzeug diesen Fall nicht bewertet hat
passed	true oder false anstelle eines Scores, oder leer
score_min, score_max	Die Skala, auf der ein Score liegt (0 und 1 bei den meisten Werkzeugen), für einen Score erforderlich
judge, judge_version	Das Modell, das geurteilt hat, falls ein Modell geurteilt hat. Optional

Nichts anderes wird gelesen, und eine Datei mit irgendeiner anderen Spalte wird abgelehnt: Eine Datei enthält Fall-IDs und Scores, niemals eine Frage, eine Antwort oder sonst einen Inhalt. Die Rezepte weiter unten wandeln die Ergebnisse jedes Werkzeugs in diese Datei um.

Ausführen

oloproof init --example second-opinion second-opinion
cd second-opinion

Das Beispiel enthält zwei Exporte der Faithfulness eines Support-Assistenten auf 150 Fragen, vor und nach einer Prompt-Änderung, so wie der Judge eines anderen Werkzeugs sie bewertet hat: ein Score von 0 bis 1 und sein Bestanden oder Nicht-bestanden bei 0.7. make_exports.py ist die Simulation, die sie geschrieben hat. Der durchschnittliche Score ist um etwa 0.02 gestiegen.

oloproof scores import before.csv after.csv --policy release.yaml

faithfulness: +0.023 [-0.024, +0.068] · 150 paired · 0 missing · 0 excluded
faithfulness_passed: +5.3 points [-6.9, +18.0] · 150 paired · 0 missing · 0 excluded
Decisions
  score-went-up  faithfulness  superiority  INSUFFICIENT_EVIDENCE  evaluator_not_validated
  more-answers-pass  faithfulness_passed  superiority  INSUFFICIENT_EVIDENCE  evaluator_not_validated
Gate: BLOCK (exit 3)
score-went-up, more-answers-pass: the judge (or model or custom evaluator) behind these rules has not been measured against people yet, so it may not decide.

Jede Datei wurde zu einem Lauf, und die beiden Läufe wurden Fall für Fall verglichen. Die Antwort hat zwei Hälften.

Ist es echt? Noch nicht. Der Score stieg um 0.023, aber das Intervall reicht von 0.024 niedriger bis 0.068 höher: Mit 150 Fragen lässt sich eine so kleine Änderung nicht von Rauschen unterscheiden. Der Anteil der Antworten, die der Judge bestehen lässt, stieg um 5.3 Punkte, mit einem Intervall von 6.9 Punkten niedriger bis 18.0 höher.
Können Sie dem Judge trauen? Niemand hat ihn geprüft. release.yaml lässt einen Judge erst dann über ein Release entscheiden, wenn die Labels von Menschen ihn gemessen haben (require_validated_evaluators: true), daher halten beide Regeln bei evaluator_not_validated an, bevor sie das Intervall erreichen.

Um die erste Hälfte allein zu sehen, als wäre der Judge geprüft worden:

oloproof scores import before.csv after.csv --policy statistics-only.yaml

  score-went-up  faithfulness  superiority  INSUFFICIENT_EVIDENCE  interval_overlaps_zero
  more-answers-pass  faithfulness_passed  superiority  INSUFFICIENT_EVIDENCE  interval_overlaps_zero

Fügen Sie in CI --summary markdown >> "$GITHUB_STEP_SUMMARY" hinzu: Der Pull Request beginnt dann mit „Is it real?“ und einer Zeile pro Regel, die „not established“ und den Grund nennt, und der Exit-Code bleibt derselbe. Die eigenen Zeilen des Imports gehen auf die Standardfehlerausgabe, sodass die Zusammenfassung nur die Antwort erhält (CI).

Ohne --policy meldet der Befehl den Vergleich und entscheidet nichts. Mit einer Datei meldet er diesen Lauf, und --policy prüft ihn mit einem Gate nach den Laufregeln der Policy.

Den Judge prüfen

Menschen labeln eine Zufallsstichprobe der Fälle eines importierten Laufs, ohne das Urteil des Judges zu sehen, und Oloproof misst den Judge an ihnen:

oloproof labels export RUN_ID --criterion faithfulness_passed --sample 60 --out sample.csv
oloproof labels import sample.csv
oloproof evaluators validate EVALUATOR_ID --by NAME

Die Stichprobe zeigt die ID jedes Falls und nichts vom Urteil des Judges. Die labelnde Person liest den Fall in dem Werkzeug, das ihn enthält, anhand seiner ID, und schreibt pass oder fail in passed. oloproof evaluators list gibt die ID des Evaluators aus. Sobald er validiert ist, entscheiden die Regeln, die diesen Judge lesen, allein auf Grundlage der Evidenz.

Labels sind Bestanden oder Nicht-bestanden, daher prüfen sie das Bestanden-oder-nicht-bestanden-Urteil eines Judges, nicht seinen Score. Importieren Sie das Urteil neben dem Score, wie es das Beispiel mit faithfulness_passed tut: Das ist das Kriterium, das Menschen validieren können.

Aus Ihrem Werkzeug

Der Ordner recipes/ des Beispiels enthält ein kurzes Skript pro Werkzeug. Jedes liest die Ergebnisse dieses Werkzeugs und schreibt die Datei, wobei es nur IDs und Scores behält. Führen Sie eines pro Version aus und importieren Sie dann die beiden Dateien.

Werkzeug	Rezept	Was einen Fall über zwei Läufe hinweg identifiziert	Hinweise
DeepEval	deepeval_results.py RESULTS_JSON OUT	Der name des Testfalls	Speichern Sie die Ergebnisse mit DisplayConfig(results_folder=...) und benennen Sie jeden LLMTestCase. Jede Metrik liefert ihren Score und ihr Bestanden oder Nicht-bestanden als <metric>_passed, mit dem Judge-Modell
Braintrust	braintrust_experiment.py PROJECT EXPERIMENT OUT	Der Datensatzeintrag, auf dem das Experiment lief (origin.id)	Scores von 0 bis 1; --judge benennt das Modell, falls eines sie alle beurteilt hat
LangSmith	langsmith_experiment.py EXPERIMENT OUT --scale LOW HIGH	Das Datensatzbeispiel (reference_example_id)	Ein Score true oder false wird zu Bestanden oder Nicht-bestanden; eine Zahl braucht ihre Skala
Langfuse	langfuse_experiment.py EXPERIMENT SINCE OUT	Das Datensatzelement (experiment_item_id)	Die Experimente von Langfuse 5; numerische Scores auf dem Bereich ihrer Score-Konfiguration, oder --scale

Die Rezepte folgen dem SDK jedes Werkzeugs, wie es am 16. Oktober 2026 veröffentlicht war (DeepEval 4.3.1, braintrust 0.46.1, langsmith 0.14.11, langfuse 5.0.2), und sind an Ergebnissen dieser Form getestet, nicht gegen ein echtes Konto. Ein Werkzeug, das ein Feld umbenennt, bricht sein Rezept, nicht den Import: Die Datei, die es schreibt, ist der Vertrag.

Was eine Datei richtig machen muss

Ein Fall, der nur in einer Datei vorkommt, fehlt auf der anderen Seite, wird gezählt und im ungünstigsten Fall begrenzt; er wird niemals mit einem anderen Fall gepaart.
Eine zweite Zeile für denselben Fall und dasselbe Kriterium, ein Score außerhalb von score_min und score_max, eine Zeile mit sowohl einem Score als auch einem Bestanden oder Nicht-bestanden und ein Kriterium, das in einer Datei ein Score und in der anderen ein Bestanden oder Nicht-bestanden ist, werden abgelehnt, unter Nennung der Zeile.
Verglichene Dateien müssen in der Skala und im Judge jedes Kriteriums übereinstimmen: Scores von zwei Judges sind zwei Messinstrumente, und ihre Differenz ginge teilweise auf die Instrumente zurück.
Jede Datei ist eine Systemversion, die durch ihren Inhalt identifiziert wird. Wird dieselbe Datei erneut importiert, wird wiederverwendet, was gespeichert wurde; nichts wird jemals ausgeführt, daher kann kein erneuter Lauf einen importierten Score reproduzieren oder verändern.
--tool hält fest, woher die Scores stammen, und --name benennt das System jeder Datei; beides wird mit dem Lauf aufbewahrt.

Was nicht gebaut ist

Das eigene Exportformat eines Werkzeugs direkt lesen: Ein Rezept wandelt es in die oben beschriebene Datei um.
Die Dateien auf die gehostete Seite hochladen, ohne etwas zu installieren.
Die Scores eines Judges validieren, im Gegensatz zu seinen Bestanden-oder-nicht-bestanden-Urteilen.

Wie es weitergeht

Einen Kandidaten mit einer Baseline vergleichen: was ein gepaarter Vergleich liest.
Vergleichsregeln: Überlegenheit, Nicht-Unterlegenheit und Äquivalenz.
Judges: wie ein Judge an Menschen gemessen wird, bevor er als Gate dienen darf.