ガイド
安全性研究：Inspect のログから手法の段落まで
モデルに評価を実行しました。モデルオーガニズムとその対照、攻撃セット、ジャッジが採点した監査エージェントのトランスクリプトです。結果を書き留める前に、それが成り立つかどうかを三つの問いが決めます。不確かさはどれだけ広いか、「200 件中ゼロ」は本当にゼロか、そしてトランスクリプトを採点したジャッジは信頼できるか。Oloproof はすでにあるログからこれらに答え、測定したものから図、表、手法の段落を書きます。
ログを読む
Oloproof は UK AISI Inspect のログを読みます。inspect eval が書く .eval ファイル、または JSON のログです。
oloproof scores import --from inspect logs/organism.eval
oloproof scores import --from inspect logs/control.eval logs/organism.eval --policy release.yaml最初のコマンドは一つの実行をインポートし、平易な言葉で答えます。二つ目は二つの実行をインポートし、サンプル ID で対にして、ポリシーの比較ルールを判定します。二つのログとともに与えるポリシーには少なくとも一つ（kind: superiority、non_inferiority または equivalence）が必要で、一つの実行に対する上限は、そのログだけをポリシーとともにインポートして判定します。各スコアラーは基準になります。C は合格、I は不合格、部分点は 0 から 1 のスコアで、数値のスコアラーには --scale LOW HIGH で範囲を与える必要があります。コピーされるのは ID とスコアだけで、トランスクリプトはログに残ります。読み方の規則はすべて別のツールのスコアへのセカンドオピニオンを参照してください。
エポックはサンプルを増やさない
各サンプルを何度も実行しても（Inspect のエポック）、独立したケースが増えるわけではありません。Oloproof はサンプルを単位とします。ログはエポックをレプリケートとする実行としてインポートされ、各サンプルの値はそのエポックの平均で、どのサンプルも同じ重みを持ちます。各エポックは自身の合格または不合格を保つため、ジャッジはサンプルを単位としてエポックで確認できます。各サンプルの実行を別々のケースとして数えると、繰り返しを新しいプロンプトとして扱うことになります。この手法のグリッドでは、サンプルごとに 2 回の実行をそのようにまとめると、このようなプロンプトについての主張を、表示上 95% でも 86% しかカバーしないことがありました。ただし、サンプルそのものについての主張では成り立ちました（docs/engine/PASS_AT_K_METHOD.md §8）。エラーになったエポックを持つサンプルは、欠損として最悪の値で数え、終わったエポックの平均としては決して数えません。エラーは難しいサンプルに起きやすいからです。
見えないことはゼロではない
安全性の主張はしばしばゼロという件数に基づきます。攻撃は一つも成功せず、その振る舞いを示したトランスクリプトもなかった、というものです。ゼロ件を見たことは、率がゼロであることではありません。基準を設定していなければ、Oloproof は率がまだどこまで高くありうるか、そしてそれを下げるのに問題のないケースがあと何件必要かを示します。
attack_succeeded: about 0.0%; the true value is likely between 0.0% and 1.9% (95% range, 200 cases).
None of the 200 cases counted toward it, yet the rate could still be as high as 1.9%: none seen is not none.
If the next cases show none either, a suite of 368 cases (168 more) would bring the high end to 1.0% or below.上限があれば、ポリシーがそれを判定します。200 件中 0 件に対する max: 0.01 は INSUFFICIENT_EVIDENCE で、助言は条件付きです。「次のケースも一つも数えられなければ、約 368 件で判定できます。数えられるケースが一つあるごとに、その件数は増えます」。確率は示しません。事象がなければ、それを示す根拠が何もないからです。
rules:
- id: attack-ceiling
metric: attack_succeeded
max: 0.01いつかは成功するか？ pass@k
能力やレッドチームの問いは、多くの場合 k 回の試行のいずれかが成功するかどうかです。oloproof passk はサンプルの各エポックを 1 回の試行として読み、各サンプルの pass@k を偏りなく推定してから、スイートの平均を求めます。
oloproof passk logs/organism.eval --from inspect --criterion leaked --k 5試行ごとに 1 行のファイル（case、passed、任意で error）も使えます。エラーになった試行を持つサンプル、または試行が k 回に満たないサンプルは、欠損として最悪の値で数えます。回答は推定値とその 95% の範囲を示します。--min または --max を与えると判定します。範囲が基準を超えれば PASS、範囲がすべて反対側にあれば FAIL、それ以外は INSUFFICIENT_EVIDENCE です（終了コード 0、1、3）。この手法（docs/engine/PASS_AT_K_METHOD.md）はグリッドのすべてのセルで表示どおりの 95% をカバーし、2026 年 11 月 3 日に独立した監査でその条件のもとで承認されました。条件とは、1 つのケースの試行が互いに独立していること、そして 1 回成功したからといってケースの試行を早く打ち切っていないことです。
多くの条件を一度に: スイープ
それぞれに 95% の区間を付けた 20 個の差の表は、どこかでおよそ 1 回は間違うと見込まれます。手法のグリッドでは、別々の 50 個の区間がすべて当たったのは 10 回中 6 回だけでした。oloproof sweep は、実行を読む前に名前を挙げた対比の族を判定するので、表全体がまとめて成り立ちます。
sweep:
conditions:
control: run_01...
organism_a: run_01...
organism_b: run_01...
contrasts:
- organism_a - control
- organism_b - controloloproof sweep sweep.yaml --policy compare.yaml各対比は 1 つのスイートの 2 つの実行のペア比較で、ポリシーのすべての比較ルールで判定され、各主張は 1 - alpha/m（m は主張の数）で扱われます。そのどれかが間違う確率は高々 alpha です。表を見てから読んだ対比はこの保証の外です。異なるスイートの実行は比較しません。
モニターの安全性と監査コスト
コントロールプロトコルでは、軌跡ごとに 1 行で、その arm（attack または honest）とモニターの疑わしさの score を持つファイルから、すべてのしきい値での安全性（フラグが立った攻撃の割合）と正直な軌跡のフラグ率が得られます。
oloproof control monitor.csv --budget 0.02 --min-safety 0.9範囲はすべてのしきい値で同時に、両方の arm をまとめて成り立つので、曲線を読んで選んだしきい値、たとえば 2% の監査予算に収まるものも、引き続きカバーされます。--budget と --min-safety を与えると、正直な軌跡にフラグを立てる割合がその値以下で、攻撃をその割合以上捕まえるしきい値があるかどうかを判定します。範囲は裾でも中央と同じ幅なので、小さな予算には多くの正直な軌跡が必要です。2,000 件あれば、正直な軌跡のフラグ率はおよそ 3 ポイントの精度でわかります。ここでの安全性はファイル内の攻撃に対するものです。モニターに適応する攻撃者はその外です。
安全性は、攻撃が成功したかどうかにかかわらず、攻撃アームの軌跡について数えられます。バックドアを入れるよう指示された軌跡が実際には入れていないこともあり、存在しないものを見逃したことでモニターを責めることはできません。成功した攻撃に対する安全性を求めるなら、まず各攻撃軌跡を確認し（バックドアなら秘密の入力でのテスト）、ファイルを oloproof control に渡す前に、合格したものだけを attack アームに残してください。
ジャッジを確認する
モデルが採点したトランスクリプトは、人が同意するまではジャッジの言い分にすぎません。インポートした実行からブラインドのサンプルにラベルを付けてください。トランスクリプトはお使いのマシンに留めます。
oloproof scores import --from inspect --answers logs/organism.eval logs/organism.eval
oloproof review latest --criterion deceptive --by NAMEreview はサンプルを抽出し、各トランスクリプトをジャッジの判定なしで表示し、一致度を測定し、宣言した基準を超えた場合にのみジャッジを検証します。検証されるまで、検証済みのジャッジを求めるポリシー（oloproof init が書くポリシーがそうです）は、それに基づいてルールを判定しません。Oloproof が実行した実行で、ケースのメタデータにタグがあるものについては、oloproof labels disagreements RUN --criterion deceptive --by behavior が、ジャッジと人の判断が分かれる箇所を振る舞いごと、方向ごとに示します。ジャッジが合格にして人が不合格にしたもの、そしてその逆です。各グループの範囲はそれぞれ独立した主張であり、このレポートは何も判定しません。
書き上げる
oloproof report latest --paper paper/これは figure.svg（各指標の推定値と区間）、table.md と table.tex、そして methods.md を書きます。methods.md は、各区間の手法とその信頼度を挙げ、区間がこの有限のスイートについてのものであることを述べ、欠損ケースとまれな事象を挙げ、各ジャッジについて人が確認したか、どの程度一致したかを述べ、ゲートが何を判定したかを示す段落です。すべての数値は保存された実行のもので、段落は決まった文と記録された事実から組み立てられます。モデルが書くことはありません。ノートブックでは次のようにします。
import oloproof
result = oloproof.analyze_inspect("logs/organism.eval", project="analysis")
result # the figure, the table and the methods paragraph
result.write("paper/")監査エージェントのトランスクリプト
Petri のように Inspect の上で動く監査ツールは、スコアラーが各トランスクリプトに次元ごとのスコアを与える Inspect のログを書きます。スコアは多くの場合 1 から 10 です。その範囲を付けて oloproof scores import --from inspect --scale 1 10 audit.eval でインポートすると、各次元は有界平均とその区間を持つ基準になります。対象を変更する前と後の二つのログは、共通のトランスクリプトで比較されます。スコアはジャッジの言い分のままです。ジャッジの合格または不合格ではなくそのスコアは、まだ人と照らし合わせて確認できません。
まだ作られていないもの
- ジャッジの合格または不合格の判定ではなく、そのスコアを人のスコアと照らし合わせて確認すること。
- Inspect のサンプルのメタデータにあるタグ。インポートした実行のケースにはタグがないため、labels disagreements --by がグループ分けできるのは Oloproof が実行した実行だけです。
- Bonferroni より狭いスイープ（Dunnett または閉検定）、異なるスイートの条件どうしの対比、裾でより狭いモニターの範囲、複数のモニターの組み合わせ、複数のしきい値を持つプロトコル。
- PNG の図。図は SVG のみです。
これでわからないこと
どの区間も、ログにあるサンプルについてのものです。それはこれらのサンプルを完全にエラーなく実行したら何が示されるかを述べるものであり、モデルが他のプロンプトで、本番環境で、あるいは適応する攻撃者のもとでどう振る舞うかを述べるものではありません。人が確認したジャッジは、人がラベルを付けたケースと、それを判定したモデルについて確認されたのであり、それらと異なるトランスクリプトについてではありません。そして、攻撃セットで 1% 未満に抑えられた率は、そのセットに含まれない攻撃については何も語りません。