Handleidingen

Een second opinion over de scores van een andere tool

Je evaluatiescore ging omhoog. Is dat echt? En kun je de judge vertrouwen die hem mat? Als je al met een andere tool evalueert, exporteer dan de resultaten per case van voor en na een wijziging, en Oloproof beantwoordt beide vragen op basis daarvan zonder iets opnieuw te draaien.

Wat het leest

Eén bestand per systeemversie, CSV of JSON Lines, met één rij per case en criterium:

Kolom	Wat erin staat
case_id	De id van de case. Twee bestanden paren alleen op een id die in beide voorkomt
criterion	De naam van de metriek, die de metriek wordt die een regel noemt
score	Een getal op de schaal van de metriek, of leeg als de tool die case niet scoorde
passed	true of false in plaats van een score, of leeg
score_min, score_max	De schaal waarop een score ligt (0 en 1 voor de meeste tools), verplicht bij een score
judge, judge_version	Het model dat oordeelde, als een model dat deed. Optioneel

Verder wordt niets gelezen, en een bestand met een andere kolom wordt geweigerd: een bestand bevat case-id's en scores, nooit een vraag, een antwoord of andere inhoud. De recepten hieronder zetten de resultaten van elke tool om in dit bestand.

Draai het

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

Het voorbeeld bevat twee exports van de getrouwheid van een supportassistent op 150 vragen, voor en na een promptwijziging, zoals de judge van een andere tool ze scoorde: een score van 0 tot 1, en zijn geslaagd of mislukt bij 0.7. make_exports.py is de simulatie die ze schreef. De gemiddelde score ging met ongeveer 0.02 omhoog.

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.

Elk bestand werd een run, en de twee runs werden case voor case vergeleken. Het antwoord heeft twee helften.

Is het echt? Nog niet. De score steeg met 0.023, maar het interval loopt van 0.024 lager tot 0.068 hoger: met 150 vragen valt een zo kleine wijziging niet van ruis te onderscheiden. Het aandeel antwoorden dat de judge laat slagen steeg met 5.3 punten, met een interval van 6.9 punten lager tot 18.0 hoger.
Kun je de judge vertrouwen? Niemand heeft hem gecontroleerd. release.yaml laat een judge pas over een release beslissen wanneer labels van mensen hem hebben gemeten (require_validated_evaluators: true), dus beide regels stoppen bij evaluator_not_validated voordat ze het interval bereiken.

Om de eerste helft alleen te zien, alsof de judge was gecontroleerd:

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

Voeg in CI --summary markdown >> "$GITHUB_STEP_SUMMARY" toe: de pull request opent dan met "Is it real?" en één regel per beleidsregel, die "not established" zegt en waarom, en de exitcode blijft dezelfde. De eigen regels van de import gaan naar standaardfout, zodat de samenvatting alleen het antwoord ontvangt (CI).

Zonder --policy rapporteert de opdracht de vergelijking en beslist niets. Met één bestand rapporteert hij die run, en --policy gatet hem op de runregels van de policy.

De judge controleren

Mensen labelen een willekeurige steekproef van de cases van een geïmporteerde run, blind voor de judge, en Oloproof meet de judge daaraan:

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

De steekproef toont de id van elke case en niets van het oordeel van de judge. De labelaar leest de case, aan de hand van zijn id, in de tool die hem bevat, en schrijft pass of fail in passed. oloproof evaluators list geeft de id van de evaluator. Eenmaal gevalideerd beslissen de regels die die judge lezen op het bewijs alleen.

Labels zijn geslaagd of mislukt, dus ze controleren het oordeel geslaagd of mislukt van een judge, niet zijn score. Importeer het oordeel naast de score, zoals het voorbeeld doet met faithfulness_passed: dat is het criterium dat mensen kunnen valideren.

Vanuit je tool

De map recipes/ van het voorbeeld bevat één kort script per tool. Elk leest de resultaten van die tool en schrijft het bestand, met alleen id's en scores. Draai er één per versie, en importeer dan de twee bestanden.

Tool	Recept	Wat een case over twee runs heen identificeert	Opmerkingen
DeepEval	deepeval_results.py RESULTS_JSON OUT	De name van de testcase	Sla resultaten op met DisplayConfig(results_folder=...) en geef elke LLMTestCase een naam. Elke metriek levert zijn score en zijn geslaagd of mislukt als <metric>_passed, met het model van de judge
Braintrust	braintrust_experiment.py PROJECT EXPERIMENT OUT	Het datasetrecord dat het experiment draaide (origin.id)	Scores van 0 tot 1; --judge noemt het model als één model ze allemaal beoordeelde
LangSmith	langsmith_experiment.py EXPERIMENT OUT --scale LOW HIGH	Het datasetvoorbeeld (reference_example_id)	Een score true of false wordt geslaagd of mislukt; een getal heeft zijn schaal nodig
Langfuse	langfuse_experiment.py EXPERIMENT SINCE OUT	Het datasetitem (experiment_item_id)	De experimenten van Langfuse 5; numerieke scores op het bereik van hun scoreconfiguratie, of --scale

De recepten volgen de SDK van elke tool zoals gepubliceerd op 16 oktober 2026 (DeepEval 4.3.1, braintrust 0.46.1, langsmith 0.14.11, langfuse 5.0.2) en zijn getest op resultaten van die vorm, niet tegen een live account. Een tool die een veld hernoemt, breekt zijn recept, niet de import: het bestand dat het recept schrijft is het contract.

Wat een bestand goed moet hebben

Een case die maar in één bestand staat, ontbreekt aan de andere kant, wordt geteld en in het slechtste geval begrensd; hij wordt nooit met een andere case gepaard.
Een tweede rij voor één case en criterium, een score buiten score_min en score_max, een rij met zowel een score als een geslaagd of mislukt, en een criterium dat in het ene bestand een score is en in het andere geslaagd of mislukt, worden geweigerd, met vermelding van de rij.
Vergeleken bestanden moeten het eens zijn over de schaal en de judge van elk criterium: scores van twee judges zijn twee meetinstrumenten, en hun verschil zou deels dat van de instrumenten zijn.
Elk bestand is een systeemversie die door zijn inhoud wordt geïdentificeerd. Hetzelfde bestand opnieuw importeren hergebruikt wat was opgeslagen; er wordt nooit iets uitgevoerd, dus geen nieuwe run kan een geïmporteerde score reproduceren of veranderen.
--tool legt vast waar de scores vandaan kwamen, en --name geeft het systeem van elk bestand een naam; beide worden bij de run bewaard.

Wat niet gebouwd is

Het eigen exportformaat van een tool rechtstreeks lezen: een recept zet het om in het bestand hierboven.
De bestanden uploaden naar de gehoste site zonder iets te installeren.
De scores van een judge valideren, in plaats van zijn oordelen geslaagd of mislukt.

Verder lezen

Een kandidaat met een baseline vergelijken: wat een gepaarde vergelijking leest.
Vergelijkingsregels: superioriteit, non-inferioriteit en equivalentie.
Judges: hoe een judge aan mensen wordt gemeten voordat hij mag gaten.