設定リファレンス

oloproof.yaml と release.yaml のすべてのフィールドを、その型、デフォルト、受け付ける値、例とともに示します。内容はファイルを読み込むモデルから取っています。フィールドを調べるときに使ってください。ワークフローを学ぶにはクイックスタートとゲーティングのページを読んでください。

どちらのファイルも、何かが実行される前に検証されます。未知のフィールド、綴りの誤ったフィールド、型の誤った値は設定エラーであり、コマンドはケースを 1 つも実行せずに 2 で終了します。どちらのファイルにも JSON Schema があり、JSON Schema を読むエディターは補完に使えます。インストールされたパッケージは、結果のスキーマとともに、現在のディレクトリの schemas/v1/ にそれらを書き出します。python -m oloproof_core.models.schema_export（2 つのファイルは project_config.schema.json と release_policy.schema.json）です。

以下の表で「必須」とは、そのフィールドがなければファイルが拒否されることを意味します。それ以外のフィールドには、省略したときに使われる値を示しています。

oloproof.yaml の概観

小さく完全なプロジェクトです。Python 関数をローカルで実行し、ネットワークもキーも必要とせず、oloproof init が用意する形をしています。

# oloproof.yaml
version: 1
project: support-bot
dataset: datasets/support.jsonl
system:
  name: support-bot
  callable: app.bot:answer
evaluators:
  - type: exact_match
    criterion: correct_label
    field: label

トップレベルのフィールド

concurrency

pricing のエントリ

Oloproof は価格表を同梱していません。各エントリは、評価器の model: が指定するのとまったく同じ名前でモデルを指定します。

# oloproof.yaml
version: 1
project: support-bot
dataset: datasets/support.jsonl
system:
  name: support-bot
  callable: app.bot:answer
evaluators:
  - type: exact_match
    criterion: correct_label
    field: label
pricing:
  - model: my-judge-model
    input_per_mtok: 0.15
    output_per_mtok: 0.6
egress: [raw_outputs]

system

システムには callable、http、rag のうちちょうど 1 つが必要です。

system.http

# oloproof.yaml
version: 1
project: support-api
dataset: datasets/support.jsonl
system:
  name: support-api
  version: "2026-10-08"
  http:
    url: http://localhost:8000/answer
    output_path: answer
    artifacts:
      retrieval/v1: debug.retrieval
evaluators:
  - type: hit_rate
    k: 5

リクエストとレスポンスの契約、そしてタイムアウトや HTTP エラーのときに何が起きるかは、結果と実行にあります。

system.rag

ここで指定した設定は、クラスが宣言するものを上書きします。段階的システムは自身の retrieval/v1、context/v1、citations/v1 アーティファクトを記録するため、それと並べて records を書くと拒否されます。RAG を参照してください。

evaluators

すべてのエントリは type と、次の 2 つの共通フィールドを取ります。

fail は合格・不合格の評価器にのみ適用され、スコアの評価器でこれを使うと設定エラーです。on_execution_error は YAML のフィールドです。SDK の評価器クラスはそのような引数を取らず、エラーになったケースは欠測として数えられます。

評価器の種類

「読むもの」は評価器の判定が依存するものを列挙しており、それはキャッシュされた判定のキーでもあります。「SDK」は oloproof.evaluators のクラスを示します。

ホスト型モデルを呼び出すジャッジは、ケースの内容をそのプロバイダーに送り、そのプロバイダーから請求されます。キーは api_key_env で指定した環境変数から読まれ、Oloproof がこれらのファイルに保存することはありません。

決定的評価器

モデルジャッジ

rubric_judge、groundedness_judge、citation_support_judge は次のフィールドを共有します。rubric_judge には rubric_file と rubric_text のちょうど一方が必要です。2 つの RAG ジャッジは多くとも一方を取り、なければ組み込みのルーブリックを使います。それらの criterion のデフォルトは groundedness と citation_support です。

probability_judge は型付きの質問をし、モデルの確率を読みます。

cascade は安価なジャッジを先に実行し、不確かなケースをエスカレーションします。

各段階はカスケード自身の criterion を判定します。別の基準を指定した段階は拒否されます。

model_classifier は、TEI 互換のサーバー上の学習済みモデルでテキストを採点します。

RAG の評価器

エージェントの評価器

各エージェントの型にはデフォルトの criterion があるため、省略できます。それ自身の型名か、設定から組み立てた名前（agent_steps_le_8、agent_tool_lookup_called、agent_handoffs_le_2）です。エージェントを参照してください。

予測の評価器

positive、field、expected_field を書いていない予測の評価器は、それを predictive: ブロックから取ります。書いた値はそのまま保たれます。

predictive

metrics

各評価器の基準はすでにメトリクスです。metrics: のエントリは、type で区別されるメトリクスをもう 1 つ追加します。

# oloproof.yaml
version: 1
project: support-bot
dataset: datasets/support.jsonl
system:
  name: support-bot
  callable: app.bot:answer
evaluators:
  - type: exact_match
    criterion: correct_label
    field: label
metrics:
  - id: latency_p95
    type: quantile
    source: latency_ms
    quantile: 0.95

release.yaml

リリースポリシーです。どのルールが判断し、どの判断がブロックするかを定めます。省略した設定はデフォルトを保つため、ルールだけを指定したポリシーでも FAIL、INSUFFICIENT_EVIDENCE、MANUAL_REVIEW でブロックします。

# release.yaml
version: 1
rules:
  - id: label_accuracy
    metric: correct_label
    min: 0.8

rules

1 つのリストが両方の種類を保持します。実行ルールは min、max、max_failures のちょうど 1 つを取ります。比較ルールはその kind を指定し、2 つの実行の差を判断します。比較ルールを参照してください。

families

# release.yaml
version: 1
warn_on: [INSUFFICIENT_EVIDENCE]
block_on: [FAIL, MANUAL_REVIEW]
rules:
  - id: label_accuracy
    metric: correct_label
    min: 0.8
    max_missing_fraction: 0.05
  - id: no_regression
    metric: correct_label
    kind: non_inferiority
    margin: 0.02

アーティファクトの種類

アーティファクトは、システムが出力の横に書き込む型付きのレコードで、たとえば検索したものです。種類は小文字の名前に任意のバージョンを付けたもので、^[a-z][a-z0-9_]*(/v[1-9][0-9]*)?$ に一致します。アーティファクトを必要とする評価器はそれを指定し、必要な種類をシステムが宣言していない実行は、すべてのケースを欠測として数えるのではなく、開始前に拒否されます。

呼び出し可能システムは記録する種類を records:（または @system(records=...)）で宣言し、HTTP システムは http.artifacts で宣言し、段階的 RAG システムは自身のものを記録します。

バージョン、キャッシュキー、無効化

Oloproof は入力が変わっていない作業を再利用し、何が「変わっていない」かを内容のダイジェストで決めます。それぞれエンジンが計算し、実行とともに記録されます。

Oloproof から見えないものは、あなたが宣言する必要があります。

• HTTP システムの挙動はサーバー上にあります。URL の背後にあるものが変わるたびに system.version を変えてください。そうしないと、古いキャッシュ済みの出力が新しいシステムの代わりになってしまいます。
• 呼び出し可能オブジェクトの補助モジュールは、code_paths が一致したときにだけハッシュされます。これがなければ、補助モジュールを編集してもバージョンは変わりません。
• メソッドや呼び出し可能オブジェクトはバージョンを宣言しなければならず、オブジェクトの状態が変わればバージョンも変えなければなりません。
• RAG インデックスは index_version で識別されます。インデックスを再構築したら変えてください。
• モデルジャッジの識別はその設定であり、プロバイダーの重みではありません。プロバイダーが同じ名前の背後でモデルを更新しても、キャッシュでは検出されません。
• カスタムの @evaluator は、それを定義するモジュールファイルをハッシュし、その判定は cacheable=True を宣言したときにだけ実行をまたいで再利用されます。組み込みのルーブリックジャッジはキャッシュ可能です。決定的評価器は再計算されますが、それは安価です。

キャッシュされた作業はプロジェクトのローカルストア、つまり oloproof.yaml の横の .oloproof/store.sqlite（または OLOPROOF_HOME の下）にあります。ストアを削除すると、すべてのキャッシュとすべての実行が破棄されます。ホスト型ワークスペースでは、プッシュがそれらに書き込めるため、エンジンはキャッシュ済みの実行、判定、分析を再利用せず、再計算します。