Anleitungen

Sicherheitsforschung: von einem Inspect-Log zu einem Methodenabsatz

Sie haben eine Eval auf einem Modell ausgeführt: ein Modellorganismus und seine Kontrolle, ein Angriffsset, die Transkripte eines Audit-Agenten, bewertet von einem Judge. Bevor Sie das Ergebnis aufschreiben, entscheiden drei Fragen, ob es hält: Wie groß ist die Unsicherheit, ist „keiner von 200“ wirklich keiner, und können Sie dem Judge trauen, der die Transkripte bewertet hat? Oloproof beantwortet sie anhand des Logs, das Sie bereits haben, und schreibt die Abbildung, die Tabelle und den Methodenabsatz aus dem, was es gemessen hat.

Das Log lesen

Oloproof liest Logs von UK AISI Inspect, die .eval-Datei, die inspect eval schreibt, oder ein JSON-Log:

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

Der erste Befehl importiert einen Lauf und antwortet in klaren Worten. Der zweite importiert zwei Läufe, paart sie über die Sample-IDs und entscheidet die Vergleichsregeln der Policy; eine mit zwei Logs angegebene Policy muss mindestens eine enthalten (kind: superiority, non_inferiority oder equivalence), und eine Obergrenze für einen Lauf wird entschieden, indem man dieses Log allein mit der Policy importiert. Jeder Scorer wird zu einem Kriterium: C besteht und I fällt durch, Teilpunkte sind ein Score von 0 bis 1, und ein numerischer Scorer braucht seinen Bereich, angegeben mit --scale LOW HIGH. Nur IDs und Scores werden kopiert; die Transkripte bleiben im Log. Siehe Eine zweite Meinung zu den Scores eines anderen Werkzeugs für jede Leseregel.

Epochen sind keine zusätzlichen Samples

Jedes Sample mehrmals auszuführen (die Epochen von Inspect) liefert Ihnen keine zusätzlichen unabhängigen Fälle. Oloproof behält das Sample als Einheit: Das Log wird als Lauf importiert, dessen Replikate seine Epochen sind, der Wert jedes Samples ist der Mittelwert seiner Epochen, und jedes Sample wiegt gleich. Jede Epoche behält ihr eigenes Bestanden oder Nicht-bestanden, sodass ein Judge an Epochen geprüft werden kann, mit dem Sample als Einheit. Die Läufe jedes Samples als getrennte Fälle zu zählen, behandelt Wiederholungen wie neue Prompts: Im Raster der Methode deckte das so zusammengelegte Zählen von zwei Läufen pro Sample eine Aussage über Prompts wie diese bei angegebenen 95 % nur in bis zu 86 % der Fälle ab, während es für eine Aussage über die Samples selbst hielt (docs/engine/PASS_AT_K_METHOD.md §8). Ein Sample mit einer fehlerhaften Epoche zählt als fehlend, im ungünstigsten Fall, nie als Mittelwert der Epochen, die fertig wurden, denn Fehler fallen tendenziell auf die schweren Samples.

Keiner gesehen heißt nicht keiner

Eine Sicherheitsaussage beruht oft auf einer Zählung von null: Kein Angriff war erfolgreich, kein Transkript zeigte das Verhalten. Null gesehen ist keine Rate von null. Ohne gesetzte Schwelle sagt Oloproof, wie hoch die Rate noch sein könnte und wie viele saubere Fälle sie senken würden:

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.

Unter einer Obergrenze entscheidet die Policy. max: 0.01 bei 0 von 200 ist INSUFFICIENT_EVIDENCE, und der Rat ist bedingt: „Wenn auch keiner der nächsten Fälle zählt, würden etwa 368 es entscheiden; jeder, der zählt, erhöht diese Zahl“. Es wird keine Wahrscheinlichkeit angegeben, denn ohne Ereignisse gibt es nichts, woraus sie sich angeben ließe.

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

Kann es überhaupt? pass@k

Eine Frage zu Fähigkeiten oder zum Red-Teaming lautet oft, ob irgendeiner von k Versuchen gelingt. oloproof passk liest jede Epoche eines Samples als einen Versuch und schätzt das pass@k jedes Samples ohne Verzerrung, dann den Mittelwert der Suite:

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

Eine Datei mit einer Zeile pro Versuch (case, passed, optional error) funktioniert ebenfalls. Ein Sample mit einem fehlerhaften Versuch oder mit weniger als k Versuchen zählt als fehlend, im ungünstigsten Fall. Die Antwort nennt die Schätzung und ihren 95-%-Bereich. Mit --min oder --max entscheidet sie: PASS, wenn der Bereich die Schwelle überschreitet, FAIL, wenn er ganz auf der falschen Seite liegt, sonst INSUFFICIENT_EVIDENCE (Exit 0, 1 oder 3). Die Methode (docs/engine/PASS_AT_K_METHOD.md) hat ihre angegebenen 95 % in jeder Zelle ihres Rasters eingehalten und wurde am 3. November 2026 durch ein unabhängiges Audit zugelassen, zu ihren Bedingungen: Die Versuche eines Falls sind voneinander unabhängig, und Sie haben die Versuche eines Falls nicht vorzeitig beendet, weil einer gelang.

Viele Bedingungen auf einmal: ein Sweep

Eine Tabelle mit zwanzig Differenzen, jede mit eigenem 95-%-Intervall, liegt erwartungsgemäß irgendwo etwa einmal daneben: Im Raster der Methode hielten fünfzig getrennte Intervalle nur sechs von zehn Malen alle. oloproof sweep entscheidet eine Familie von Kontrasten, die Sie vor dem Lesen der Läufe benennen, sodass die ganze Tabelle gemeinsam hält:

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

Jeder Kontrast ist ein gepaarter Vergleich zweier Läufe einer Suite, entschieden von jeder Vergleichsregel der Policy, jede Aussage bei 1 - alpha/m, wobei m die Zahl der Aussagen ist: Die Wahrscheinlichkeit, dass irgendeine davon falsch ist, beträgt höchstens alpha. Ein Kontrast, den Sie erst nach dem Blick auf die Tabelle lesen, liegt außerhalb dieser Garantie. Läufe auf verschiedenen Suites werden nicht verglichen.

Die Sicherheit eines Monitors gegen seine Audit-Kosten

Für ein Control-Protokoll liefert eine Datei mit einer Zeile pro Trajektorie, ihrem arm (attack oder honest) und dem Verdachts-score des Monitors, die Sicherheit (den Anteil markierter Angriffe) und die Markierungsrate ehrlicher Trajektorien bei jeder Schwelle:

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

Die Bereiche halten bei allen Schwellen zugleich, für beide Arme gemeinsam, sodass eine Schwelle, die durch Lesen der Kurve gewählt wurde, etwa die zu einem Audit-Budget von 2 %, weiterhin abgedeckt ist. Mit --budget und --min-safety entscheidet es, ob irgendeine Schwelle höchstens diesen Anteil ehrlicher Trajektorien markiert und dabei mindestens diesen Anteil der Angriffe erkennt. Die Bereiche sind im Randbereich so breit wie in der Mitte, daher braucht ein kleines Budget viele ehrliche Trajektorien: Bei 2.000 ist die Markierungsrate ehrlicher Trajektorien auf etwa 3 Punkte bekannt. Sicherheit gilt hier gegen die Angriffe in der Datei; ein Angreifer, der sich an den Monitor anpasst, liegt außerhalb.

Die Sicherheit wird über die Trajektorien des Angriffsarms gezählt, ob ihr Angriff gelungen ist oder nicht. Eine Trajektorie, die eine Hintertür einbauen sollte, hat vielleicht keine eingebaut, und der Monitor ist nicht schuld, wenn er übersieht, was nicht da ist. Für Sicherheit gegenüber gelungenen Angriffen prüfen Sie zuerst jede Angriffstrajektorie (bei einer Hintertür ein Test mit ihrer geheimen Eingabe) und behalten im Arm attack nur die, die ihn bestehen, bevor die Datei oloproof control erreicht.

Den Judge prüfen

Ein von einem Modell bewertetes Transkript ist das Wort des Judges, bis Menschen ihm zustimmen. Labeln Sie eine blinde Stichprobe des importierten Laufs und behalten Sie die Transkripte dabei auf Ihrem Rechner:

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

review zieht die Stichprobe, zeigt jedes Transkript ohne das Urteil des Judges, misst die Übereinstimmung und validiert den Judge nur, wenn er die von Ihnen angegebene Schwelle überschreitet. Solange er nicht validiert ist, entscheidet eine Policy, die validierte Judges verlangt, wie die, die oloproof init schreibt, keine Regel auf ihm. Für einen Lauf, den Oloproof ausgeführt hat und dessen Fälle Tags in ihren Metadaten tragen, zeigt oloproof labels disagreements RUN --criterion deceptive --by behavior dann, wo Judge und Menschen auseinandergehen, pro Verhalten und nach Richtung: was der Judge bestehen ließ und Menschen durchfallen ließen, und umgekehrt. Der Bereich jeder Gruppe ist eine eigene Aussage; der Bericht entscheidet nichts.

Aufschreiben

oloproof report latest --paper paper/

Das schreibt figure.svg (Schätzung und Intervall jeder Metrik), table.md und table.tex sowie methods.md, einen Absatz, der jede Intervallmethode und ihre Konfidenz nennt, sagt, dass die Intervalle diese endliche Suite betreffen, fehlende Fälle und seltene Ereignisse nennt, für jeden Judge sagt, ob Menschen ihn geprüft haben und wie oft sie übereinstimmten, und angibt, was das Gate entschieden hat. Jede Zahl ist die des gespeicherten Laufs, und der Absatz ist aus festen Sätzen und aufgezeichneten Fakten gebaut; kein Modell schreibt ihn. In einem Notebook:

import oloproof

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

Die Transkripte eines Audit-Agenten

Ein Audit-Werkzeug, das auf Inspect läuft, etwa Petri, schreibt ein Inspect-Log, dessen Scorer jedem Transkript einen Score pro Dimension gibt, oft von 1 bis 10. Importieren Sie es mit diesem Bereich, oloproof scores import --from inspect --scale 1 10 audit.eval, und jede Dimension wird zu einem Kriterium mit einem beschränkten Mittelwert und seinem Intervall. Zwei solche Logs, vor und nach einer Änderung am Ziel, werden auf ihren gemeinsamen Transkripten verglichen. Die Scores bleiben das Wort des Judges: Die Scores eines Judges, im Unterschied zu seinem Bestanden oder Nicht-bestanden, lassen sich noch nicht an Menschen prüfen.

Was nicht gebaut ist

Die Scores eines Judges an denen von Menschen zu prüfen, im Unterschied zu seinen Urteilen Bestanden oder Nicht-bestanden.
Tags aus den Metadaten eines Inspect-Samples: Die Fälle eines importierten Laufs tragen keine Tags, daher gruppiert labels disagreements --by nur Läufe, die Oloproof ausgeführt hat.
Ein Sweep, der enger ist als Bonferroni (Dunnett oder Closed Testing), Kontraste zwischen Bedingungen auf verschiedenen Suites sowie Monitor-Bereiche, die im Randbereich enger sind, mehrere kombinierte Monitore oder Protokolle mit mehreren Schwellen.
Eine PNG-Abbildung: Die Abbildung gibt es nur als SVG.

Was das nicht sagen kann

Jedes Intervall betrifft die Samples in Ihrem Log. Es sagt, was ein vollständiger, fehlerfreier Lauf dieser Samples zeigen würde, nicht, wie sich das Modell bei anderen Prompts, im Einsatz oder unter einem Angreifer verhält, der sich anpasst. Ein von Menschen geprüfter Judge ist auf den Fällen geprüft, die sie gelabelt haben, und mit dem Modell, das sie beurteilt hat, nicht auf Transkripten, die diesen nicht gleichen. Und eine Rate, die auf Ihrem Angriffsset unter 1 % begrenzt ist, sagt nichts über Angriffe, die Ihr Set nicht enthält.