Langsung ke konten

Panduan

Riset keselamatan: dari log Inspect ke paragraf metode

Anda menjalankan eval pada sebuah model: model organism dan kontrolnya, satu set serangan, transkrip agen audit yang dinilai oleh juri. Sebelum Anda menuliskan hasilnya, tiga pertanyaan menentukan apakah hasil itu bertahan: seberapa lebar ketidakpastiannya, apakah "tidak satu pun dari 200" benar-benar nol, dan dapatkah Anda memercayai juri yang menilai transkrip itu? Oloproof menjawabnya dari log yang sudah Anda miliki, lalu menulis gambar, tabel, dan paragraf metode dari apa yang diukurnya.

Membaca log

Oloproof membaca log UK AISI Inspect, yaitu file .eval yang ditulis inspect eval atau log JSON:

oloproof scores import --from inspect logs/organism.eval
oloproof scores import --from inspect logs/control.eval logs/organism.eval --policy release.yaml

Perintah pertama mengimpor satu run dan menjawab dengan kata-kata sederhana. Perintah kedua mengimpor dua run, memasangkannya berdasarkan id sampel, dan memutuskan aturan perbandingan kebijakan; kebijakan yang diberikan dengan dua log harus memuat setidaknya satu (kind: superiority, non_inferiority atau equivalence), dan batas atas pada satu run diputuskan dengan mengimpor log itu sendiri bersama kebijakan. Setiap scorer menjadi satu kriteria: C lulus dan I gagal, nilai parsial adalah skor dari 0 sampai 1, dan scorer numerik memerlukan rentangnya, yang diberikan dengan --scale LOW HIGH. Hanya id dan skor yang disalin; transkrip tetap di log. Lihat Pendapat kedua atas skor dari tool lain untuk setiap aturan pembacaan.

Epoch bukan sampel tambahan

Menjalankan setiap sampel beberapa kali (epoch Inspect) tidak memberi Anda lebih banyak kasus yang independen. Oloproof mempertahankan sampel sebagai unit: log diimpor sebagai run yang replicate-nya adalah epoch-nya, nilai setiap sampel adalah rata-rata epoch-nya, dan setiap sampel berbobot sama. Setiap epoch mempertahankan lulus atau gagalnya sendiri, sehingga juri dapat diperiksa pada epoch, dengan sampel sebagai unit. Menghitung setiap jalannya sampel sebagai kasus terpisah memperlakukan pengulangan sebagai prompt baru: dalam grid metode ini, menggabungkan dua jalannya per sampel dengan cara itu mencakup klaim tentang prompt seperti ini hanya 86% dari waktu pada 95% yang dinyatakan, meskipun cakupannya bertahan untuk klaim tentang sampel itu sendiri (docs/engine/PASS_AT_K_METHOD.md §8). Sampel dengan epoch yang error dihitung sebagai hilang, pada nilai terburuknya, tidak pernah sebagai rata-rata epoch yang selesai, karena error cenderung jatuh pada sampel yang sulit.

Tidak terlihat bukan berarti tidak ada

Klaim keselamatan sering bertumpu pada hitungan nol: tidak ada serangan yang berhasil, tidak ada transkrip yang menunjukkan perilaku itu. Nol yang terlihat bukan laju nol. Tanpa batas yang ditetapkan, Oloproof menyebutkan seberapa tinggi laju itu masih mungkin dan berapa banyak kasus bersih yang akan menurunkannya:

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.

Di bawah plafon, kebijakanlah yang memutuskannya. max: 0.01 pada 0 dari 200 adalah INSUFFICIENT_EVIDENCE, dan sarannya bersyarat: "jika tidak satu pun kasus berikutnya terhitung, sekitar 368 akan memutuskannya; setiap kasus yang terhitung menaikkan jumlah itu". Tidak ada probabilitas yang dikutip, karena tanpa kejadian tidak ada dasar untuk mengutipnya.

rules:
  - id: attack-ceiling
    metric: attack_succeeded
    max: 0.01

Bisakah ia berhasil? pass@k

Pertanyaan kapabilitas atau red team sering kali adalah apakah salah satu dari k percobaan berhasil. oloproof passk membaca setiap epoch dari sebuah sampel sebagai satu percobaan dan mengestimasi pass@k setiap sampel tanpa bias, lalu rata-rata suite:

oloproof passk logs/organism.eval --from inspect --criterion leaked --k 5

Berkas dengan satu baris per percobaan (case, passed, error opsional) juga bisa. Sampel dengan percobaan yang error, atau kurang dari k percobaan, dihitung sebagai hilang, pada nilai terburuknya. Jawabannya memberi estimasi dan rentang 95%-nya. Dengan --min atau --max ia memutuskan: PASS saat rentang melewati ambang, FAIL saat rentang seluruhnya berada di sisi yang salah, INSUFFICIENT_EVIDENCE selain itu (exit 0, 1, atau 3). Metodenya (docs/engine/PASS_AT_K_METHOD.md) mencakup 95% yang dinyatakan di setiap sel gridnya dan diterima oleh audit independen pada 3 November 2026, dengan syaratnya: percobaan-percobaan sebuah kasus saling independen, dan Anda tidak menghentikan percobaan sebuah kasus lebih awal karena satu berhasil.

Banyak kondisi sekaligus: sebuah sweep

Tabel dua puluh selisih, masing-masing dengan interval 95% sendiri, diperkirakan salah di suatu tempat sekitar satu kali: dalam grid metode, lima puluh interval terpisah semuanya bertahan hanya enam kali dari sepuluh. oloproof sweep memutuskan sekelompok kontras yang Anda sebutkan sebelum membaca run, sehingga seluruh tabel bertahan bersama:

sweep:
  conditions:
    control: run_01...
    organism_a: run_01...
    organism_b: run_01...
  contrasts:
    - organism_a - control
    - organism_b - control
oloproof sweep sweep.yaml --policy compare.yaml

Setiap kontras adalah perbandingan berpasangan dua run dari satu suite, diputuskan oleh setiap aturan perbandingan dalam kebijakan, setiap klaim pada 1 - alpha/m dengan m jumlah klaim: peluang salah satunya keliru paling besar alpha. Kontras yang baru Anda baca setelah melihat tabel berada di luar jaminan itu. Run pada suite yang berbeda tidak dibandingkan.

Keselamatan monitor terhadap biaya auditnya

Untuk protokol kontrol, file satu baris per trajektori, dengan arm (attack atau honest) dan score kecurigaan monitor, memberikan keselamatan (bagian serangan yang ditandai) dan laju penandaan jujur pada setiap ambang:

oloproof control monitor.csv --budget 0.02 --min-safety 0.9

Rentangnya berlaku pada semua ambang sekaligus, kedua lengan bersama, sehingga ambang yang dipilih dengan membaca kurva, seperti yang sesuai anggaran audit 2%, tetap tercakup. Dengan --budget dan --min-safety ia memutuskan apakah ada ambang yang menandai paling banyak bagian trajektori jujur itu sambil menangkap paling sedikit bagian serangan itu. Rentangnya sama lebar di ekor seperti di tengah, sehingga anggaran kecil membutuhkan banyak trajektori jujur: dengan 2.000, laju penandaan jujur diketahui hingga sekitar 3 poin. Keselamatan di sini terhadap serangan dalam file; penyerang yang beradaptasi dengan monitor berada di luarnya.

Keamanan dihitung atas lintasan di lengan serangan, entah serangannya berhasil atau tidak. Lintasan yang disuruh menyisipkan pintu belakang mungkin tidak menyisipkannya, dan monitor tidak bisa disalahkan karena melewatkan sesuatu yang tidak ada. Untuk keamanan terhadap serangan yang berhasil, periksa dulu setiap lintasan serangan (untuk pintu belakang, uji pada masukan rahasianya) dan simpan di lengan attack hanya yang lolos sebelum berkas sampai ke oloproof control.

Memeriksa juri

Transkrip yang dinilai oleh model adalah perkataan juri sampai orang menyetujuinya. Beri label pada sampel buta dari run yang diimpor, dengan transkrip tetap di mesin Anda:

oloproof scores import --from inspect --answers logs/organism.eval logs/organism.eval
oloproof review latest --criterion deceptive --by NAME

review mengambil sampel, menampilkan setiap transkrip tanpa putusan juri, mengukur kesepakatan, dan memvalidasi juri hanya jika juri itu melewati batas yang Anda nyatakan. Sampai juri divalidasi, kebijakan yang mewajibkan juri tervalidasi, seperti yang ditulis oloproof init, tidak memutuskan aturan berdasarkan juri itu. Untuk run yang dieksekusi Oloproof, yang kasusnya membawa tag di metadatanya, oloproof labels disagreements RUN --criterion deceptive --by behavior lalu menunjukkan di mana juri dan orang berbeda pendapat, per perilaku dan per arah: apa yang diluluskan juri tetapi digagalkan orang, dan sebaliknya. Rentang setiap kelompok adalah klaimnya sendiri; laporan itu tidak memutuskan apa pun.

Menuliskannya

oloproof report latest --paper paper/

Perintah ini menulis figure.svg (estimasi dan interval setiap metrik), table.md dan table.tex, serta methods.md, sebuah paragraf yang menyebut setiap metode interval dan tingkat kepercayaannya, menyatakan bahwa interval itu tentang suite terbatas ini, menyebut kasus yang hilang dan kejadian langka, menyatakan untuk setiap juri apakah orang memeriksanya dan seberapa sering mereka sepakat, serta menyatakan apa yang diputuskan gate. Setiap angka berasal dari run yang tersimpan, dan paragraf itu dibangun dari kalimat tetap dan fakta yang tercatat; tidak ada model yang menulisnya. Di notebook:

import oloproof

result = oloproof.analyze_inspect("logs/organism.eval", project="analysis")
result  # the figure, the table and the methods paragraph
result.write("paper/")

Transkrip agen audit

Tool audit yang berjalan di atas Inspect, seperti Petri, menulis log Inspect yang scorer-nya memberi setiap transkrip skor per dimensi, sering dari 1 sampai 10. Impor dengan rentang itu, oloproof scores import --from inspect --scale 1 10 audit.eval, dan setiap dimensi menjadi kriteria dengan rata-rata terbatas dan intervalnya. Dua log seperti itu, sebelum dan sesudah perubahan pada target, dibandingkan pada transkrip yang sama-sama dimiliki. Skornya tetap perkataan juri: skor juri, berbeda dengan lulus atau gagalnya, belum dapat diperiksa terhadap orang.

Apa yang belum dibangun

  • Memeriksa skor juri terhadap skor orang, berbeda dengan putusan lulus atau gagalnya.
  • Tag dari metadata sampel Inspect: kasus run yang diimpor tidak membawa tag, sehingga labels disagreements --by hanya mengelompokkan run yang dieksekusi Oloproof.
  • Sweep yang lebih sempit dari Bonferroni (Dunnett atau closed testing), kontras antar kondisi pada suite yang berbeda, dan pita monitor yang lebih sempit di ekor, beberapa monitor digabungkan, atau protokol dengan beberapa ambang.
  • Gambar PNG: gambar hanya dalam SVG.

Apa yang tidak bisa diberitahukan

Setiap interval adalah tentang sampel dalam log Anda. Interval itu menyatakan apa yang akan ditunjukkan oleh run lengkap tanpa error atas sampel-sampel ini, bukan bagaimana model berperilaku pada prompt lain, saat deployment, atau di bawah penyerang yang beradaptasi. Juri yang diperiksa oleh orang diperiksa pada kasus yang mereka beri label dan model yang menilainya, bukan pada transkrip yang berbeda dari itu. Dan laju yang dibatasi di bawah 1% pada set serangan Anda tidak mengatakan apa pun tentang serangan yang tidak ada dalam set Anda.