Recherche en sûreté : d’un journal Inspect à un paragraphe de méthodes

Vous avez exécuté une évaluation sur un modèle : un organisme modèle et son témoin, un jeu d’attaques, les transcriptions d’un agent d’audit notées par un juge. Avant de consigner le résultat, trois questions décident s’il tient : quelle est l’ampleur de l’incertitude, « aucun sur 200 » veut-il vraiment dire aucun, et pouvez-vous faire confiance au juge qui a noté les transcriptions ? Oloproof y répond à partir du journal que vous avez déjà, et écrit la figure, le tableau et le paragraphe de méthodes à partir de ce qu’il a mesuré.

Lire le journal

Oloproof lit les journaux UK AISI Inspect, le fichier .eval qu’écrit inspect eval ou un journal JSON :

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

La première commande importe une exécution et répond en mots simples. La seconde importe deux exécutions, les apparie sur les identifiants d’échantillon et décide les règles de comparaison de la politique ; une politique donnée avec deux journaux doit en contenir au moins une (kind: superiority, non_inferiority ou equivalence), et un plafond sur une exécution se décide en important ce journal seul avec la politique. Chaque scorer devient un critère : C réussit et I échoue, un crédit partiel est une note de 0 à 1, et un scorer numérique a besoin de son étendue, donnée avec --scale LOW HIGH. Seuls les identifiants et les notes sont copiés ; les transcriptions restent dans le journal. Voir Un second avis sur les scores d’un autre outil pour chaque règle de lecture.

Les époques ne sont pas plus d’échantillons

Exécuter chaque échantillon plusieurs fois (les époques d’Inspect) ne vous donne pas plus de cas indépendants. Oloproof garde l’échantillon comme unité : le journal s’importe comme une exécution dont les répliques sont ses époques, la valeur de chaque échantillon est la moyenne de ses époques, et chaque échantillon pèse autant. Chaque époque garde sa propre réussite ou son propre échec, si bien qu’un juge peut être vérifié sur des époques, avec l’échantillon comme unité. Compter les exécutions de chaque échantillon comme des cas distincts traite les répétitions comme de nouveaux prompts : dans la grille de la méthode, regrouper ainsi deux exécutions par échantillon a couvert une affirmation sur des prompts comme ceux-ci aussi rarement que 86 % du temps pour 95 % annoncés, même si la couverture tenait pour une affirmation sur les échantillons eux-mêmes (docs/engine/PASS_AT_K_METHOD.md §8). Un échantillon dont une époque est en erreur compte comme manquant, au pire, jamais comme la moyenne des époques terminées, puisque les erreurs tombent plutôt sur les échantillons difficiles.

Rien vu ne veut pas dire rien

Une affirmation de sûreté repose souvent sur un compte de zéro : aucune attaque n’a réussi, aucune transcription n’a montré le comportement. Zéro observé n’est pas un taux nul. Sans seuil fixé, Oloproof dit jusqu’où le taux pourrait encore monter et combien de cas propres le feraient baisser :

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.

Sous un plafond, la politique décide. max: 0.01 sur 0 de 200 donne INSUFFICIENT_EVIDENCE, et le conseil est conditionnel : « si aucun des cas suivants ne compte non plus, environ 368 le décideraient ; chacun qui compte augmente ce nombre ». Aucune probabilité n’est citée, car sans événements il n’y a rien sur quoi la fonder.

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

Y arrive-t-il jamais ? pass@k

Une question de capacité ou de red team est souvent de savoir si l’une des k tentatives réussit. oloproof passk lit chaque époque d’un échantillon comme une tentative et estime sans biais le pass@k de chaque échantillon, puis la moyenne de la suite :

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

Un fichier d’une ligne par tentative (case, passed, error facultatif) convient aussi. Un échantillon dont une tentative est en erreur, ou qui a moins de k tentatives, compte comme manquant, au pire. La réponse donne l’estimation et sa plage à 95 %. Avec --min ou --max, elle décide : PASS quand la plage franchit le seuil, FAIL quand elle tombe entièrement du mauvais côté, INSUFFICIENT_EVIDENCE sinon (sortie 0, 1 ou 3). La méthode (docs/engine/PASS_AT_K_METHOD.md) a tenu ses 95 % annoncés dans chaque cellule de sa grille et a été admise par un audit indépendant le 3 novembre 2026, à ses conditions : les tentatives d’un cas sont indépendantes les unes des autres, et vous n’avez pas arrêté tôt les tentatives d’un cas parce que l’une avait réussi.

Plusieurs conditions à la fois : un balayage

Un tableau de vingt écarts, chacun avec son propre intervalle à 95 %, devrait se tromper quelque part environ une fois : dans la grille de la méthode, cinquante intervalles séparés n’ont tous tenu que six fois sur dix. oloproof sweep décide une famille de contrastes que vous nommez avant de lire les exécutions, de sorte que le tableau entier tienne ensemble :

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

Chaque contraste est une comparaison appariée de deux exécutions d’une même suite, décidée par chaque règle de comparaison de la politique, chaque affirmation à 1 - alpha/m, m étant le nombre d’affirmations : la probabilité que l’une d’elles soit fausse est au plus alpha. Un contraste que vous ne lisez qu’après avoir regardé le tableau sort de cette garantie. Des exécutions sur des suites différentes ne sont pas comparées.

La sûreté d’un moniteur face à son coût d’audit

Pour un protocole de contrôle, un fichier d’une ligne par trajectoire, avec son arm (attack ou honest) et le score de suspicion du moniteur, donne la sûreté (la part des attaques signalées) et le taux de signalement honnête à chaque seuil :

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

Les plages tiennent à tous les seuils à la fois, les deux bras ensemble, de sorte qu’un seuil choisi en lisant la courbe, comme celui qui tient dans un budget d’audit de 2 %, reste couvert. Avec --budget et --min-safety, il décide si un seuil signale au plus cette part de trajectoires honnêtes tout en attrapant au moins cette part d’attaques. Les plages sont aussi larges dans la queue qu’au milieu, donc un petit budget demande beaucoup de trajectoires honnêtes : avec 2 000, le taux de signalement honnête est connu à environ 3 points près. La sûreté se mesure ici contre les attaques du fichier ; un attaquant qui s’adapte au moniteur en sort.

La sûreté se compte sur les trajectoires du bras d’attaque, que leur attaque ait réussi ou non. Une trajectoire à qui l’on a demandé d’insérer une porte dérobée peut ne pas l’avoir fait, et l’on ne peut reprocher au moniteur de manquer ce qui n’existe pas. Pour une sûreté face aux attaques réussies, vérifiez d’abord chaque trajectoire d’attaque (pour une porte dérobée, un test sur son entrée secrète) et ne gardez dans le bras attack que celles qui le passent avant que le fichier n’arrive à oloproof control.

Vérifier le juge

Une transcription notée par un modèle reste la parole du juge jusqu’à ce que des personnes lui donnent raison. Étiquetez un échantillon en aveugle de l’exécution importée, en gardant les transcriptions sur votre machine :

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

review tire l’échantillon, montre chaque transcription sans le verdict du juge, mesure l’accord et ne valide le juge que s’il franchit le seuil que vous déclarez. Tant qu’il n’est pas validé, une politique qui exige des juges validés, comme celle qu’écrit oloproof init, ne décide pas de règle sur lui. Pour une exécution qu’Oloproof a menée, dont les cas portent des étiquettes dans leurs métadonnées, oloproof labels disagreements RUN --criterion deceptive --by behavior montre ensuite où le juge et les personnes divergent, par comportement et par sens : ce que le juge a fait réussir et que les personnes ont fait échouer, et l’inverse. L’étendue de chaque groupe est une affirmation à part ; le rapport ne décide rien.

La rédiger

oloproof report latest --paper paper/

Cela écrit figure.svg (l’estimation et l’intervalle de chaque métrique), table.md et table.tex, et methods.md, un paragraphe qui nomme chaque méthode d’intervalle et son niveau de confiance, dit que les intervalles portent sur cette suite finie, nomme les cas manquants et les événements rares, dit pour chaque juge si des personnes l’ont vérifié et à quelle fréquence elles étaient d’accord, et indique ce que la porte a décidé. Chaque nombre est celui de l’exécution enregistrée, et le paragraphe est construit à partir de phrases fixes et de faits enregistrés ; aucun modèle ne l’écrit. Dans un notebook :

import oloproof

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

Les transcriptions d’un agent d’audit

Un outil d’audit qui s’exécute sur Inspect, comme Petri, écrit un journal Inspect dont le scorer donne à chaque transcription une note par dimension, souvent de 1 à 10. Importez-le avec cette étendue, oloproof scores import --from inspect --scale 1 10 audit.eval, et chaque dimension devient un critère avec une moyenne bornée et son intervalle. Deux journaux de ce type, avant et après un changement de la cible, se comparent sur leurs transcriptions communes. Les notes restent la parole du juge : les notes d’un juge, par opposition à sa réussite ou son échec, ne peuvent pas encore être vérifiées par des personnes.

Ce qui n’est pas construit

• Vérifier les notes d’un juge par rapport à celles des personnes, par opposition à ses verdicts de réussite ou d’échec.
• Les étiquettes des métadonnées d’un échantillon Inspect : les cas d’une exécution importée ne portent pas d’étiquettes, donc labels disagreements --by ne regroupe que les exécutions qu’Oloproof a menées.
• Un balayage plus étroit que Bonferroni (Dunnett ou tests fermés), des contrastes entre conditions sur des suites différentes, et des bandes de moniteur plus étroites dans la queue, plusieurs moniteurs combinés, ou des protocoles à plusieurs seuils.
• Une figure PNG : la figure est en SVG seulement.

Ce que cela ne peut pas vous dire

Chaque intervalle porte sur les échantillons de votre journal. Il dit ce que montrerait une exécution complète et sans erreur de ces échantillons, pas comment le modèle se comporte sur d’autres prompts, en déploiement ou face à un attaquant qui s’adapte. Un juge vérifié par des personnes l’est sur les cas qu’elles ont étiquetés et le modèle qui les a jugés, pas sur des transcriptions différentes de celles-là. Et un taux borné sous 1 % sur votre jeu d’attaques ne dit rien des attaques que votre jeu ne contient pas.