Przewodniki

Druga opinia o wynikach z innego narzędzia

Twój wynik ewaluacji wzrósł. Czy to prawdziwa poprawa? I czy można ufać sędziemu, który go zmierzył? Jeśli już prowadzisz ewaluacje w innym narzędziu, wyeksportuj jego wyniki dla poszczególnych przypadków przed zmianą i po niej, a Oloproof odpowie na oba pytania na ich podstawie, niczego nie uruchamiając ponownie.

Co jest wczytywane

Jeden plik na wersję systemu, CSV lub JSON Lines, z jednym wierszem na przypadek i kryterium:

Kolumna	Co zawiera
case_id	Identyfikator przypadku. Dwa pliki parują się tylko na identyfikatorze, który zawierają oba
criterion	Nazwa metryki, która staje się metryką wskazywaną przez regułę
score	Liczba na skali metryki albo puste pole, jeśli narzędzie nie oceniło tego przypadku
passed	true lub false zamiast wyniku albo puste pole
score_min, score_max	Skala, na której leży wynik (0 i 1 w większości narzędzi), wymagana dla wyniku
judge, judge_version	Model, który oceniał, jeśli oceniał model. Opcjonalne

Nic innego nie jest wczytywane, a plik z jakąkolwiek inną kolumną zostaje odrzucony: plik zawiera identyfikatory przypadków i wyniki, nigdy pytanie, odpowiedź ani żadną inną treść. Opisane niżej przepisy przekształcają wyniki każdego narzędzia w taki plik.

Uruchomienie

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

Przykład zawiera dwa eksporty wierności (faithfulness) asystenta wsparcia na 150 pytaniach, przed zmianą promptu i po niej, tak jak ocenił je sędzia innego narzędzia: wynik od 0 do 1 oraz jego werdykt pass lub fail przy progu 0.7. make_exports.py to symulacja, która je zapisała. Średni wynik wzrósł o około 0.02.

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.

Każdy plik stał się przebiegiem, a oba przebiegi zostały porównane przypadek po przypadku. Odpowiedź ma dwie części.

Czy to prawdziwa poprawa? Jeszcze nie. Wynik wzrósł o 0.023, ale przedział rozciąga się od 0.024 w dół do 0.068 w górę: przy 150 pytaniach tak małej zmiany nie da się odróżnić od szumu. Odsetek odpowiedzi zaliczonych przez sędziego wzrósł o 5.3 punktu, z przedziałem od 6.9 punktu w dół do 18.0 w górę.
Czy można ufać sędziemu? Nikt go nie sprawdził. release.yaml pozwala sędziemu decydować o wydaniu dopiero wtedy, gdy zmierzą go etykiety nadane przez ludzi (require_validated_evaluators: true), więc obie reguły zatrzymują się na evaluator_not_validated, zanim dojdą do przedziału.

Aby zobaczyć samą pierwszą część, tak jakby sędzia był już sprawdzony:

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

W CI dodaj --summary markdown >> "$GITHUB_STEP_SUMMARY": pull request zaczyna się wtedy od „Is it real?” i jednego wiersza na regułę, który mówi „not established” i dlaczego, a kod wyjścia pozostaje ten sam. Własne wiersze importu trafiają na standardowe wyjście błędów, więc podsumowanie dostaje samą odpowiedź (CI).

Bez --policy polecenie raportuje porównanie i niczego nie rozstrzyga. Przy jednym pliku raportuje ten przebieg, a --policy poddaje go bramkowaniu według reguł polityki dotyczących przebiegów.

Sprawdzanie sędziego

Ludzie etykietują losową próbkę przypadków zaimportowanego przebiegu, nie znając werdyktu sędziego, a Oloproof mierzy sędziego względem tych etykiet:

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

Próbka pokazuje identyfikator każdego przypadku i nic z werdyktu sędziego. Osoba etykietująca odczytuje przypadek w narzędziu, które go przechowuje, po jego identyfikatorze, i wpisuje pass lub fail w passed. oloproof evaluators list podaje identyfikator ewaluatora. Po walidacji reguły, które odczytują tego sędziego, decydują wyłącznie na podstawie dowodów.

Etykiety mają postać pass lub fail, więc sprawdzają werdykt pass lub fail sędziego, a nie jego wynik. Zaimportuj werdykt obok wyniku, tak jak przykład robi to z faithfulness_passed: to jest kryterium, które ludzie mogą zwalidować.

Z Twojego narzędzia

Folder recipes/ przykładu zawiera jeden krótki skrypt na narzędzie. Każdy odczytuje wyniki danego narzędzia i zapisuje plik, zachowując tylko identyfikatory i wyniki. Uruchom jeden skrypt dla każdej wersji, a następnie zaimportuj oba pliki.

Narzędzie	Przepis	Co identyfikuje przypadek w dwóch przebiegach	Uwagi
DeepEval	deepeval_results.py RESULTS_JSON OUT	name przypadku testowego	Zapisz wyniki przez DisplayConfig(results_folder=...) i nadaj nazwę każdemu LLMTestCase. Każda metryka podaje swój wynik i swój werdykt pass lub fail jako <metric>_passed, wraz z modelem sędziego
Braintrust	braintrust_experiment.py PROJECT EXPERIMENT OUT	Rekord zbioru danych, na którym działał eksperyment (origin.id)	Wyniki od 0 do 1; --judge wskazuje model, jeśli to jeden model ocenił je wszystkie
LangSmith	langsmith_experiment.py EXPERIMENT OUT --scale LOW HIGH	Przykład ze zbioru danych (reference_example_id)	Wynik true lub false staje się werdyktem pass lub fail; liczba wymaga podania jej skali
Langfuse	langfuse_experiment.py EXPERIMENT SINCE OUT	Element zbioru danych (experiment_item_id)	Eksperymenty Langfuse 5; wyniki liczbowe w zakresie ich konfiguracji wyniku albo --scale

Przepisy odpowiadają SDK każdego narzędzia w wersji opublikowanej 16 października 2026 (DeepEval 4.3.1, braintrust 0.46.1, langsmith 0.14.11, langfuse 5.0.2) i są testowane na wynikach o tym kształcie, a nie na żywym koncie. Narzędzie, które zmieni nazwę pola, psuje swój przepis, a nie import: kontraktem jest plik, który przepis zapisuje.

Co plik musi zawierać poprawnie

Przypadek obecny tylko w jednym pliku jest brakujący po drugiej stronie, liczony i ograniczany w najgorszym wariancie; nigdy nie jest parowany z innym przypadkiem.
Drugi wiersz dla tego samego przypadku i kryterium, wynik spoza score_min i score_max, wiersz zawierający zarówno wynik, jak i pass lub fail, oraz kryterium, które w jednym pliku jest wynikiem, a w drugim pass lub fail, są odrzucane ze wskazaniem wiersza.
Porównywane pliki muszą być zgodne co do skali i sędziego każdego kryterium: wyniki od dwóch sędziów to dwa instrumenty, a ich różnica byłaby częściowo różnicą instrumentów.
Każdy plik to wersja systemu identyfikowana przez swoją zawartość. Ponowny import tego samego pliku wykorzystuje to, co zostało zapisane; nic nigdy nie jest wykonywane, więc żadne ponowne uruchomienie nie może odtworzyć ani zmienić zaimportowanego wyniku.
--tool zapisuje, skąd pochodzą wyniki, a --name nadaje nazwę systemowi każdego pliku; oba są przechowywane razem z przebiegiem.

Czego nie zbudowano

Bezpośredniego odczytu własnego formatu eksportu narzędzia: przepis przekształca go w opisany wyżej plik.
Przesyłania plików do hostowanej witryny bez instalowania czegokolwiek.
Walidacji wyników sędziego, w odróżnieniu od jego werdyktów pass lub fail.

Co dalej

Porównywanie kandydata z punktem odniesienia: co odczytuje porównanie sparowane.
Reguły porównań: wyższość, nie-gorszość i równoważność.
Sędziowie: jak sędzia jest mierzony względem ludzi, zanim będzie mógł bramkować.