가이드
안전성 연구: Inspect 로그에서 방법 단락까지
모델에 평가를 실행했습니다. 모델 오거니즘과 그 대조군, 공격 세트, 심사 모델이 채점한 감사 에이전트의 트랜스크립트입니다. 결과를 적기 전에, 그것이 유효한지는 세 가지 질문이 결정합니다. 불확실성이 얼마나 넓은가, "200개 중 0개"는 정말 0인가, 그리고 트랜스크립트를 채점한 심사 모델을 믿을 수 있는가. 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는 샘플을 단위로 유지합니다. 로그는 에포크를 반복(replicate)으로 하는 실행으로 가져와지고, 각 샘플의 값은 그 에포크들의 평균이며, 모든 샘플은 같은 가중치를 가집니다. 각 에포크는 자신의 통과 또는 실패를 유지하므로, 심사 모델을 샘플을 단위로 하여 에포크에서 확인할 수 있습니다. 각 샘플의 실행을 별개의 케이스로 세면 반복을 새 프롬프트처럼 다루게 됩니다. 이 방법의 그리드에서 샘플당 두 번의 실행을 그렇게 합치자, 이런 프롬프트에 대한 주장을 명시된 95%에서도 86%밖에 포함하지 못한 경우가 있었지만, 샘플 자체에 대한 주장에서는 유지되었습니다(docs/engine/PASS_AT_K_METHOD.md §8). 오류가 난 에포크가 있는 샘플은 누락으로, 가장 나쁜 값으로 세며, 끝난 에포크들의 평균으로 세지 않습니다. 오류는 어려운 샘플에서 일어나기 쉽기 때문입니다.
보이지 않았다고 없는 것은 아닙니다
안전성 주장은 흔히 0이라는 건수에 기댑니다. 성공한 공격이 없었고, 그 행동을 보인 트랜스크립트도 없었다는 것입니다. 0건을 본 것은 비율이 0이라는 뜻이 아닙니다. 기준을 설정하지 않으면, 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는 샘플의 각 에포크를 한 번의 시도로 읽고, 각 샘플의 pass@k를 편향 없이 추정한 다음 스위트의 평균을 냅니다.
oloproof passk logs/organism.eval --from inspect --criterion leaked --k 5시도마다 한 행인 파일(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일 독립 감사에서 그 조건 아래 승인되었습니다. 조건은 한 케이스의 시도들이 서로 독립이라는 것, 그리고 한 번 성공했다고 케이스의 시도를 일찍 멈추지 않았다는 것입니다.
여러 조건을 한꺼번에: 스윕
각각 95% 구간을 붙인 차이 20개의 표는 어딘가에서 대략 한 번은 틀릴 것으로 예상됩니다. 방법의 격자에서 별개의 구간 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 - alpha/m(m은 주장의 수)에서 다뤄집니다. 그중 어느 하나라도 틀릴 확률은 많아야 alpha입니다. 표를 본 뒤에야 읽은 대비는 이 보장 밖에 있습니다. 서로 다른 스위트의 실행은 비교하지 않습니다.
모니터의 안전성 대 감사 비용
제어 프로토콜에서는 궤적마다 한 행으로, 그 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% 미만으로 묶인 비율은 그 세트에 없는 공격에 대해서는 아무것도 말해 주지 않습니다.