結果と実行のリファレンス

実行が HTTP システムに送るものと期待する応答、各ケースがメトリクスの分母にどう入るか、判断状態とそれを説明する理由コード、終了コード、そしてどのデータがローカルに残り、どのデータがホスト型ワークスペースに移るか。背景となる考え方は基本概念を、ポリシーのフィールドは設定リファレンスを読んでください。

HTTP システムの契約

HTTP システム（oloproof.yaml の system.http）は、ケースごとに 1 回、反復ごとに 1 回呼び出されます。

URL、メソッド、出力パス、アーティファクトの対応はシステムのバージョンに含まれますが、サーバーが何をするかは含まれません。サーバーの挙動が変わったら必ず system.version を変えてください。理由は設定リファレンスを参照してください。

3 つの異なる語彙

結果には 3 種類の状態があり、互いに代わりになることはありません。

正常に終わった実行は DECIDED、早期停止で終わった場合は DECIDED_EARLY です。Ctrl-C やタスクのキャンセルで中断された実行は CANCELLED、ハーネスが例外を出した実行は RUN_ERROR です。どちらも実行を PARTIAL のままにし、完了したケースを保持し、次の実行がそのキャッシュ済みレコードを再利用できるようにします。エラーを参照してください。

最小しきい値 T と区間 [L, U] について、ルールは L >= T のとき PASS、U < T のとき FAIL、それ以外は INSUFFICIENT_EVIDENCE です。最大しきい値は対称です。区間を読む前に、ルールはそもそも判断すべきかを確認します。まず MANUAL_REVIEW の理由、次に INSUFFICIENT_EVIDENCE の理由です。理由を持つ最初の段階が判断し、見つけたすべての理由を列挙します。

理由コード

すべての判断は 1 つ以上の理由コードを持ちます。

MANUAL_REVIEW

INSUFFICIENT_EVIDENCE

PASS と FAIL

ホスト型ワークスペースのみ

プッシュされた実行を自ら判断するワークスペースは、ppi_not_verified（判断の基になる区間を検証していない）、execution_not_verified（出力が登録済みランナーから来ていない）、workspace_cannot_decide（ポリシーのコピーを持たない、またはエビデンスを読めなかった）によって判断を保留できます。ゲーティングを参照してください。

各ケースが分母にどう入るか

すべてのメトリクスは 4 つの件数を報告します。n_total（スイート内のケース）、n_eligible、n_observed、n_missing で、n_eligible = n_observed + n_missing です。n_eligible に含まれないケースは、理由とともに exclusions に列挙されます。

欠測ケースは除外されるのではなく、境界づけられます。合格率では、区間の下限はすべての欠測ケースを失敗として、上限は成功として扱います。そのため欠測ケースの多い実行は区間が広く、厳しいルールには合格できません。有界平均も同じように、宣言された範囲の両端で置き換えます。欠測ケースを境界づけられない手法（たとえばランキング統計量）はそれらを除外して仮定を記録し、その上のルールは max_missing_fraction を宣言するまで missingness_unbounded となります。

observed_count ルールは実行されたスイート全体の失敗を数え、区間を読みません。観測された失敗にすべての欠測ケースを足しても max_failures に収まるときにだけ合格します。

認められた区間を持たないメトリクス

ルールは、監査によって認められた手法の区間に基づいてのみ判断します。それがない場合でもメトリクスは計算・表示されますが、その上のルールは検証されていない手法を借りません。

終了コード

oloproof gate、ポリシー付きの oloproof run、その他の判断を行うコマンドは、すべて同じコードを使います。

複数が当てはまるとき、報告されるコードは 1、5、4、3 のうち最初のものです。block_on から外した状態は終了コードを変えられません。block_on: [FAIL] と warn_on: [INSUFFICIENT_EVIDENCE] では、判断のつかないルールは警告し、ゲートは 0 で終了します。したがって終了コード 0 は、すべてのルールが合格したことではなく、ポリシーがブロックするものが何も起きなかったことだけを意味します。ゲーティングを参照してください。

作業がどこで実行され、データがどこへ行くか

ローカル（デフォルト）

oloproof run、oloproof gate、SDK はあなたのマシン上で実行されます。すべてのレコード（ケース、出力、アーティファクト、判定、メトリクス、判断）は oloproof.yaml の横の .oloproof/store.sqlite に、または設定されていれば OLOPROOF_HOME の下に書き込まれます。Oloproof には何も送られません。ネットワーク通信は設定が引き起こすものだけです。HTTP システムの URL への呼び出しと、モデルジャッジやモデル分類器がプロバイダーに行う呼び出しで、プロバイダーは判定するケースの内容を受け取り、その分をあなたに請求します。

ホスト型ワークスペースへのプッシュ

oloproof push は、実行のエビデンスを oloproof login で接続したワークスペースに送ります。デフォルトでは、メトリクス、区間、判断、集計スライス、そしてすべてのレコードの識別子、ステータス、所要時間、使用量を送りますが、その内容は送りません。生の内容は、何かがマシンを出る前にフィールドごとに編集除去され、除去されたレコードはどのカテゴリが保留されたかを示します。カテゴリは、oloproof.yaml の egress: に列挙されたときにだけ送られます。

レコードのダイジェストは編集除去の後に再計算されないため、ホスト上のレコードは元のエビデンスを指し示し、それはあなたのマシンに残ります。編集除去は暗号化ではなく、非常に小さなスライスのメトリクスは背後のケースを特定できることがあります。

レビュアーがホスト型レビューキューでケースにラベルを付けるとき、レビュアーのブラウザはあなたの側で動く oloproof collect からケースの内容を取得します。内容はワークスペースを通りません。ワークスペースが使うプロバイダーキーは oloproof credentials set で保存され、oloproof credentials list はその名前を示し、値は決して示しません。マネージドジョブは Oloproof が運用するワーカー上で実行され、そこではあなたの Python コードは実行されません。oloproof job は結果を報告し、そのゲートに従って終了します。

ホスト型ワークスペースでは、プッシュがキャッシュに書き込めるため、エンジンはキャッシュ済みの実行、判定、分析を決して再利用せず、再計算します。