本文へスキップ

ガイド

ゼロからご自身のアプリの判定まで

質問に答える Python 関数があり、それを出荷してよいかを知りたいとします。手書きの YAML なしに、3 つのコマンドでその関数からリリースの判断まで進めます。oloproof init --system が関数の周りにプロジェクトを書き出し、oloproof check が何かを費やす前にそれが動くかを伝え、oloproof run が判断します。すべてご自身のマシン上で動き、アカウントもモデル呼び出しも必要ありません。

以下の出力はすべて、示した関数に対してこれらのコマンドを実行したものです。

1. あなたの関数

1 つのケースを受け取って回答を返す関数であれば何でもかまいません。この例は bot.py で、インポートする補助モジュールがあります。

from prompts import GREETING


def answer(question):
    text = question.lower()
    if "refund" in text:
        reply = "Refunds are available within 30 days of purchase."
    elif "ship" in text:
        reply = "We ship to the US and Canada."
    else:
        reply = "A support agent will follow up within one business day."
    return {"reply": f"{GREETING} {reply}", "topic": "support"}

2. その周りにプロジェクトを書き出す

bot.py があるディレクトリで次を実行します。

oloproof init --system bot:answer
Initialized Oloproof project in . around bot:answer
  Each case's input is a string, read from the function's first parameter.

Fill in before a run means anything:
  data/cases.jsonl  3 placeholder cases: give each a real input and, as its expected
                    phrase, words a right answer contains. Add more: see below.
  oloproof.yaml     the check reads the whole answer; if your function returns an
                    object, add `field:` naming the key that holds the text.
  release.yaml      a placeholder bar of 0.80; set the one your release needs.

What this suite can decide, if every case is measured:
  mentions-floor (mentions_expected at least 0.8, 3 cases):
    1 or more pass: INSUFFICIENT_EVIDENCE (not established yet); 0: FAIL
    (ruled out). With 50 cases, PASS from 46; with 100, from 89.

Next: oloproof check, then oloproof run

参照はまずインポートされ、関数に解決されない限り何も書き出されません。モジュール内のエラーがあれば、そのファイルと行を示してここで止まります。関数は呼び出されません。3 つのファイルが現れます。oloproof.yaml(関数と 1 つのチェック)、data/cases.jsonl(3 件のプレースホルダーのケース)、release.yaml(基準)です。最初のパラメーター名が question なので、ケースの入力は文字列になります。case、inputs、row という名前のパラメーターや、dict と注釈されたパラメーターには、代わりにオブジェクトが渡されます。

チェックは contains です。回答にケースの期待フレーズが含まれていれば、そのケースは合格です。決定的なチェックなので、判断に使う前に人と照らし合わせて測る必要はありません。ほかのすべてのチェックと判定器はスイートのガイドにあります。

3. ケースを埋める

プレースホルダーを、実際の質問と正しい回答に含まれる語句に置き換えます。1 行に 1 ケースです。

{"id": "refund_01", "input": "Can I get a refund?", "expected": {"phrase": "30 days"}}
{"id": "ship_01", "input": "Do you ship to Canada?", "expected": {"phrase": "US and Canada"}}
{"id": "other_01", "input": "My order is late", "expected": {"phrase": "follow up"}}

上の表のとおり、3 件のケースでは 0.80 の基準を満たせません。3 件では最善でも INSUFFICIENT_EVIDENCE です。以下の実行では、このようなケースを話題ごとに 10 件、合計 30 件使います。この場合 29 件の合格で十分です。

4. 実行の前にチェックする

oloproof check

フィールドを設定する前は、次のように表示されました。

ok   System: callable bot:answer imports.
ok   Called on case refund_01: it answered {"reply": "Thanks for writing in. Refunds are available within 30 days of purchase.", "topic": "support"}

Evaluators on that answer (one case, not a result):
ok   mentions_expected (contains) can read the answer; it passed this case.
note   It reads the whole answer object; `field:` can name one of reply, topic.

そこで oloproof.yaml のチェックの下に field: reply を加え、もう一度チェックします。

ok   System: callable bot:answer imports.
ok   Called on case refund_01: it answered {"reply": "Thanks for writing in. Refunds are available within 30 days of purchase.", "topic": "support"}

Evaluators on that answer (one case, not a result):
ok   mentions_expected (contains) can read the answer; it passed this case.

Code: the system's version hashes bot.py, prompts.py. Edit one and the next run calls the system again.

What this suite can decide, if every case is measured:
  mentions-floor (mentions_expected at least 0.8, 30 cases):
    29 or 30 pass: PASS (established); 19 to 28: INSUFFICIENT_EVIDENCE (not
    established yet); 18 or fewer: FAIL (ruled out). With 50 cases, PASS from
    46; with 100, from 89.

CI: no model key is needed for the evaluators. Keys your own function reads are not checked here.

Ready. Next: oloproof run

各部分の意味は次のとおりです。

  • インポートと回答:システムは oloproof run とまったく同じ方法で構築され、最初のケースで呼び出されます(--case ID で別のケースを選び、--no-call で呼び出しを省きます)。例外が発生した場合、その行はエラーと、あなたのコード内のファイルと行を示します。
  • 評価器:モデルを必要としない各チェックが、その 1 つの回答に対して実行されます。見つからないフィールドは、回答が持つフィールドとともに示されます。ここでの合格や不合格は 1 ケースであり、結果ではありません。モデルの判定器が check で呼び出されることはありません。そのことが表示され、実行時に呼び出されます。
  • コード:その内容がシステムのバージョンとなるファイルです。システムのモジュールと、それがインポートするプロジェクトのモジュール、さらに system.code_paths があればそれも含みます。システムのインポートや呼び出しの際に読み込まれたプロジェクトのファイルで、これらに含まれないもの(たとえば実行時に名前でインポートされるモジュール)は、ハッシュされていないものとして一覧に出ます。code_paths に加えてください。そうしないと、それを変更しても古い回答が再利用されます。
  • 判断できること:oloproof plan と同じ表です。release.yaml がない場合は、実行は平易な言葉で答え、何も判断しないと表示されます。
  • CI:プロジェクトが呼び出す各モデルと、そのために CI ジョブが必要とするシークレットです。api_key_env が別の名前を指定しない限り ANTHROPIC_API_KEY または OPENAI_API_KEY で、このマシン上のサーバーには何も必要ありません。

check は何も保存しません。修正すべきものがあれば 2 で、そうでなければ 0 で終了します。oloproof check --json は同じ所見を 1 つのドキュメントとして出力します。

5. 実行する

oloproof run
Gate: ALLOW (exit 0)
mentions-floor:
  100.0%, range 88.4% to 100.0% (exact binomial interval); 30 of 30 cases

実行のレポートはもっと長く、これはその判定とルールの行です。30 件すべてが合格し、率が収まる範囲は 88.4% から始まり、基準の 0.80 を上回っています。そのためルールは PASS となり、ゲートはリリースを許可します。oloproof inspect latest で改めて読めます。

次に

  • ゲートをプルリクエストに加える:oloproof init --ci github がこのプロジェクトの横にワークフローを書き出します(CI のガイド)。
  • フレーズでは正しい回答を言い表せないときは、チェックを判定器に置き換えます(判定器のガイド)。その後 oloproof check が CI に必要なキーを示します。
  • 関数ではなく、すでにファイルに回答がある場合は、oloproof eval answers.jsonl がプロジェクトなしでそれをチェックします。