ガイド
ゼロからご自身のアプリの判定まで
質問に答える 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:answerInitialized 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 runGate: 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 で改めて読めます。