ガイド

別のツールのスコアへのセカンドオピニオン

評価のスコアが上がりました。それは本物でしょうか。そして、それを測ったジャッジは信頼できるでしょうか。すでに別のツールで評価しているなら、変更の前と後のケースごとの結果をそのツールから書き出してください。Oloproof は何も再実行せずに、その結果に基づいて両方の問いに答えます。

読み込むもの

システムのバージョンごとに 1 ファイル、CSV または JSON Lines で、ケースと基準の組み合わせごとに 1 行です。

列	内容
case_id	ケースの ID。2 つのファイルは、両方に含まれる ID でのみペアになります
criterion	メトリクスの名前。これがルールが名指しするメトリクスになります
score	メトリクスの尺度上の数値。ツールがそのケースを採点しなかった場合は空欄
passed	スコアの代わりに true または false、あるいは空欄
score_min, score_max	スコアが位置する尺度（ほとんどのツールでは 0 と 1）。スコアには必須です
judge, judge_version	モデルが判定した場合、判定したモデル。任意

それ以外は何も読み込まれず、ほかの列を持つファイルは拒否されます。ファイルが保持するのはケース ID とスコアだけであり、質問や回答、そのほかの内容は決して含みません。以下のレシピが、各ツールの結果をこのファイルに変換します。

実行する

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

このサンプルには、サポートアシスタントの 150 の質問に対する忠実性を、プロンプトの変更の前と後について、別のツールのジャッジが採点したとおりに書き出した 2 つのファイルが含まれています。0 から 1 のスコアと、0.7 での合格または不合格です。make_exports.py はそれらを書き出したシミュレーションです。平均スコアは約 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.

各ファイルが 1 つの実行になり、2 つの実行がケースごとに比較されました。答えは 2 つに分かれます。

それは本物か。まだわかりません。スコアは 0.023 上がりましたが、区間は 0.024 低い側から 0.068 高い側まで広がっています。150 の質問では、これほど小さな変化はノイズと区別できません。ジャッジが合格とする回答の割合は 5.3 ポイント上がり、その区間は 6.9 ポイント低い側から 18.0 ポイント高い側までです。
ジャッジは信頼できるか。誰も確認していません。release.yaml は、人間のラベルがジャッジを測定した後でなければ、そのジャッジにリリースを判定させません（require_validated_evaluators: true）。そのため、どちらのルールも区間に到達する前に evaluator_not_validated で止まります。

ジャッジが確認済みであるかのように、前半だけを見るには次のようにします。

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

CI では --summary markdown >> "$GITHUB_STEP_SUMMARY" を追加します。プルリクエストは「Is it real?」とルールごとの 1 行で始まり、「not established」とその理由を示します。終了コードは変わりません。インポート自体の出力は標準エラーに出るため、サマリーには答えだけが入ります（CI）。

--policy を指定しない場合、このコマンドは比較を報告し、何も判断しません。ファイルが 1 つの場合はその実行を報告し、--policy はポリシーの実行ルールでその実行をゲートします。

ジャッジを確認する

インポートした実行のケースから無作為に抽出したサンプルに、人がジャッジに対してブラインドでラベルを付け、Oloproof はそれと照らし合わせてジャッジを測定します。

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

サンプルには各ケースの ID が表示され、ジャッジの判定は一切表示されません。ラベル付け担当者は、ケースを保持しているツールでその ID によってケースを読み、passed に pass または fail を書き込みます。評価器の ID は oloproof evaluators list で確認できます。検証が済めば、そのジャッジを読むルールはエビデンスだけに基づいて判断します。

ラベルは合格または不合格なので、確認できるのはジャッジの合格または不合格の判定であり、スコアではありません。サンプルが faithfulness_passed で行っているように、判定をスコアと並べてインポートしてください。それが、人が検証できる基準です。

お使いのツールから

サンプルの recipes/ フォルダーには、ツールごとに短いスクリプトが 1 つずつ入っています。それぞれがそのツールの結果を読み、ID とスコアだけを残してファイルを書き出します。バージョンごとに 1 回実行し、2 つのファイルをインポートしてください。

ツール	レシピ	2 つの実行にわたってケースを識別するもの	補足
DeepEval	deepeval_results.py RESULTS_JSON OUT	テストケースの name	DisplayConfig(results_folder=...) で結果を保存し、すべての LLMTestCase に名前を付けてください。各メトリクスは、スコアと、その合格または不合格を <metric>_passed として、ジャッジのモデルとともに出力します
Braintrust	braintrust_experiment.py PROJECT EXPERIMENT OUT	実験が実行したデータセットのレコード（origin.id）	スコアは 0 から 1。1 つのモデルがすべてを判定した場合は、--judge でそのモデルを指定します
LangSmith	langsmith_experiment.py EXPERIMENT OUT --scale LOW HIGH	データセットの例（reference_example_id）	true または false のスコアは合格または不合格になります。数値には尺度が必要です
Langfuse	langfuse_experiment.py EXPERIMENT SINCE OUT	データセットの項目（experiment_item_id）	Langfuse 5 の実験。数値スコアはスコア設定の範囲、または --scale に基づきます

レシピは 2026 年 10 月 16 日時点で公開されている各ツールの SDK（DeepEval 4.3.1、braintrust 0.46.1、langsmith 0.14.11、langfuse 5.0.2）に従っており、その形の結果でテストされていますが、実際のアカウントに対してはテストされていません。ツールがフィールドの名前を変えると、壊れるのはそのレシピであり、インポートではありません。契約となるのは、レシピが書き出すファイルです。

ファイルが守るべきこと

一方のファイルにしかないケースは、もう一方の側では欠損として数えられ、最悪の値で範囲を定められます。別のケースとペアにされることは決してありません。
1 つのケースと基準に対する 2 行目、score_min と score_max の範囲外のスコア、スコアと合格または不合格の両方を持つ行、そして一方のファイルではスコアでもう一方では合格または不合格である基準は、その行を示して拒否されます。
比較するファイルは、各基準の尺度とジャッジについて一致していなければなりません。2 つのジャッジによるスコアは 2 つの測定器であり、その差の一部は測定器の差になってしまいます。
各ファイルは、その内容によって識別されるシステムのバージョンです。同じファイルをもう一度インポートすると、保存済みのものが再利用されます。何も実行されることはないので、再実行によってインポートしたスコアを再現したり変えたりすることはできません。
--tool はスコアの出どころを記録し、--name は各ファイルのシステムに名前を付けます。どちらも実行とともに保持されます。

まだ作られていないもの

ツール独自のエクスポート形式を直接読むこと。上記のファイルへの変換はレシピが行います。
何もインストールせずに、ホスト型のサイトへファイルをアップロードすること。
ジャッジの合格または不合格の判定ではなく、そのスコアを検証すること。

次に読むページ

候補をベースラインと比較するでは、対応のある比較が何を読むかを扱います。
比較ルールでは、優越性、非劣性、同等性を扱います。
ジャッジでは、ジャッジがゲートを許される前に人と照らし合わせてどのように測定されるかを扱います。