Przewodniki

Badania bezpieczeństwa: od logu Inspect do akapitu o metodach

Uruchomiono ewaluację modelu: model organism i jego kontrola, zestaw ataków, transkrypty agenta audytującego ocenione przez sędziego. Zanim zapiszesz wynik, trzy pytania rozstrzygają, czy się utrzyma: jak duża jest niepewność, czy „żaden z 200” naprawdę znaczy żaden i czy można ufać sędziemu, który ocenił transkrypty? Oloproof odpowiada na nie na podstawie logu, który już masz, i zapisuje wykres, tabelę oraz akapit o metodach z tego, co zmierzył.

Wczytanie logu

Oloproof wczytuje logi UK AISI Inspect, plik .eval zapisywany przez inspect eval lub log JSON:

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

Pierwsze polecenie importuje jeden przebieg i odpowiada prostymi słowami. Drugie importuje dwa przebiegi, paruje je po identyfikatorach próbek i rozstrzyga reguły porównania polityki; polityka podana z dwoma logami musi zawierać co najmniej jedną (kind: superiority, non_inferiority lub equivalence), a pułap dla jednego przebiegu rozstrzyga się, importując sam ten log z polityką. Każdy scorer staje się kryterium: C oznacza zaliczenie, a I niezaliczenie, częściowe zaliczenie to wynik od 0 do 1, a scorer liczbowy wymaga podania zakresu przez --scale LOW HIGH. Kopiowane są tylko identyfikatory i wyniki; transkrypty zostają w logu. Każdą regułę odczytu opisuje Druga opinia o wynikach z innego narzędzia.

Epoki to nie więcej próbek

Wielokrotne uruchomienie każdej próbki (epoki Inspect) nie daje więcej niezależnych przypadków. Oloproof traktuje próbkę jako jednostkę: log jest importowany jako przebieg, którego replikacjami są jego epoki, wartość każdej próbki to średnia jej epok, a każda próbka waży tyle samo. Każda epoka zachowuje własny werdykt pass lub fail, więc sędziego można sprawdzić na epokach, z próbką jako jednostką. Liczenie uruchomień każdej próbki jako osobnych przypadków traktuje powtórzenia jak nowe prompty: w siatce metody takie połączenie dwóch uruchomień na próbkę obejmowało twierdzenie o takich promptach nawet tylko w 86% przypadków przy deklarowanych 95%, choć pokrycie utrzymało się dla twierdzenia o samych próbkach (docs/engine/PASS_AT_K_METHOD.md §8). Próbka z epoką zakończoną błędem liczy się jako brakująca, w najgorszym wariancie, nigdy jako średnia epok, które się zakończyły, bo błędy zwykle trafiają na trudne próbki.

Nic nie zaobserwowano to nie to samo co nic

Twierdzenie o bezpieczeństwie często opiera się na zerowej liczbie: żaden atak się nie powiódł, żaden transkrypt nie wykazał danego zachowania. Zero zaobserwowanych to nie zerowy odsetek. Bez ustawionego progu Oloproof mówi, jak wysoki może jeszcze być odsetek i ile czystych przypadków by go obniżyło:

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.

Przy górnym limicie rozstrzyga polityka. max: 0.01 przy 0 z 200 to INSUFFICIENT_EVIDENCE, a wskazówka jest warunkowa: „jeśli żaden z kolejnych przypadków też się nie liczy, rozstrzygnęłoby to około 368; każdy, który się liczy, zwiększa tę liczbę”. Nie podaje się żadnego prawdopodobieństwa, bo bez zdarzeń nie ma z czego go wyznaczyć.

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

Czy kiedykolwiek się uda? pass@k

Pytanie o możliwości lub z red teamingu często brzmi, czy którakolwiek z k prób się powiedzie. oloproof passk czyta każdą epokę próbki jako jedną próbę i szacuje bez obciążenia pass@k każdej próbki, a potem średnią z zestawu:

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

Działa też plik z jednym wierszem na próbę (case, passed, opcjonalnie error). Próbka z próbą zakończoną błędem albo z mniej niż k próbami liczy się jako brakująca, w najgorszym wariancie. Odpowiedź podaje oszacowanie i jego zakres 95%. Z --min lub --max rozstrzyga: PASS, gdy zakres przekracza próg, FAIL, gdy w całości leży po złej stronie, w przeciwnym razie INSUFFICIENT_EVIDENCE (kod wyjścia 0, 1 lub 3). Metoda (docs/engine/PASS_AT_K_METHOD.md) utrzymała deklarowane 95% w każdej komórce swojej siatki i została dopuszczona przez niezależny audyt 3 listopada 2026 roku, na swoich warunkach: próby jednego przypadku są od siebie niezależne i nie przerwałeś prób przypadku wcześniej dlatego, że jedna się udała.

Wiele warunków naraz: przegląd (sweep)

Tabela dwudziestu różnic, każda z własnym przedziałem 95%, powinna być błędna mniej więcej raz: w siatce metody pięćdziesiąt osobnych przedziałów utrzymało się wszystkie razem tylko sześć razy na dziesięć. oloproof sweep rozstrzyga rodzinę kontrastów, które nazywasz przed odczytaniem przebiegów, więc cała tabela trzyma się razem:

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

Każdy kontrast to porównanie parami dwóch przebiegów jednego zestawu, rozstrzygane przez każdą regułę porównania w polityce, każde twierdzenie na poziomie 1 - alpha/m, gdzie m to liczba twierdzeń: szansa, że którekolwiek z nich jest błędne, wynosi co najwyżej alpha. Kontrast odczytany dopiero po obejrzeniu tabeli wykracza poza tę gwarancję. Przebiegi na różnych zestawach nie są porównywane.

Bezpieczeństwo monitora względem kosztu audytu

Dla protokołu kontroli plik z jednym wierszem na trajektorię, jej arm (attack lub honest) i podejrzliwością monitora score, daje bezpieczeństwo (odsetek oznaczonych ataków) oraz odsetek oznaczonych uczciwych trajektorii przy każdym progu:

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

Zakresy obowiązują przy wszystkich progach naraz, dla obu ramion razem, więc próg wybrany przez odczytanie krzywej, na przykład ten mieszczący się w budżecie audytu 2%, nadal jest objęty. Z --budget i --min-safety rozstrzyga, czy jakiś próg oznacza co najwyżej taki odsetek uczciwych trajektorii, wyłapując co najmniej taki odsetek ataków. Zakresy są w ogonie tak samo szerokie jak w środku, więc mały budżet wymaga wielu uczciwych trajektorii: przy 2000 odsetek oznaczonych uczciwych jest znany z dokładnością do około 3 punktów. Bezpieczeństwo dotyczy tu ataków z pliku; atakujący, który dostosowuje się do monitora, wykracza poza to.

Bezpieczeństwo liczy się na trajektoriach ramienia ataku, niezależnie od tego, czy atak się udał. Trajektoria, której kazano wstawić tylne drzwi, mogła ich nie wstawić, a monitora nie można winić za przeoczenie czegoś, czego nie ma. Aby mierzyć bezpieczeństwo wobec udanych ataków, najpierw sprawdź każdą trajektorię ataku (dla tylnych drzwi test na jej tajnym wejściu) i zostaw w ramieniu attack tylko te, które go przechodzą, zanim plik trafi do oloproof control.

Sprawdzanie sędziego

Transkrypt oceniony przez model jest słowem sędziego, dopóki ludzie się z nim nie zgodzą. Oznacz ślepą próbę zaimportowanego przebiegu, trzymając transkrypty na własnym komputerze:

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

review losuje próbę, pokazuje każdy transkrypt bez werdyktu sędziego, mierzy zgodność i waliduje sędziego tylko wtedy, gdy przekroczy zadeklarowany próg. Dopóki nie jest zwalidowany, polityka wymagająca zwalidowanych sędziów, taka jak ta zapisywana przez oloproof init, nie rozstrzyga na jego podstawie żadnej reguły. Dla przebiegu wykonanego przez Oloproof, którego przypadki mają tagi w metadanych, oloproof labels disagreements RUN --criterion deceptive --by behavior pokazuje następnie, gdzie sędzia i ludzie się rozchodzą, według zachowania i kierunku: co sędzia zaliczył, a ludzie odrzucili, i odwrotnie. Zakres każdej grupy jest osobnym twierdzeniem; raport niczego nie rozstrzyga.

Opisanie wyników

oloproof report latest --paper paper/

To polecenie zapisuje figure.svg (oszacowanie i przedział każdej metryki), table.md i table.tex oraz methods.md, akapit, który wymienia każdą metodę przedziału i jej poziom ufności, stwierdza, że przedziały dotyczą tego skończonego zestawu, wymienia brakujące przypadki i rzadkie zdarzenia, podaje dla każdego sędziego, czy sprawdzili go ludzie i jak często się z nim zgadzali, oraz stwierdza, co rozstrzygnęła bramka. Każda liczba pochodzi z zapisanego przebiegu, a akapit jest zbudowany ze stałych zdań i zapisanych faktów; nie pisze go żaden model. W notatniku:

import oloproof

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

Transkrypty agenta audytującego

Narzędzie audytowe działające na Inspect, takie jak Petri, zapisuje log Inspect, którego scorer daje każdemu transkryptowi wynik w każdym wymiarze, często od 1 do 10. Zaimportuj go z tym zakresem, oloproof scores import --from inspect --scale 1 10 audit.eval, a każdy wymiar stanie się kryterium z ograniczoną średnią i jej przedziałem. Dwa takie logi, sprzed i po zmianie modelu docelowego, porównuje się na ich wspólnych transkryptach. Wyniki pozostają słowem sędziego: wyników sędziego, w odróżnieniu od jego werdyktów pass lub fail, nie można jeszcze sprawdzić względem ludzi.

Czego nie zbudowano

Sprawdzania wyników sędziego względem wyników ludzi, w odróżnieniu od jego werdyktów pass lub fail.
Tagów z metadanych próbki Inspect: przypadki zaimportowanego przebiegu nie mają tagów, więc labels disagreements --by grupuje tylko przebiegi wykonane przez Oloproof.
Przeglądu węższego niż Bonferroni (Dunnett lub testowanie domknięte), kontrastów między warunkami na różnych zestawach oraz pasm monitora węższych w ogonie, kilku połączonych monitorów lub protokołów z kilkoma progami.
Wykresu PNG: wykres jest tylko w formacie SVG.

Czego to nie może ci powiedzieć

Każdy przedział dotyczy próbek w twoim logu. Mówi, co pokazałby kompletny, wolny od błędów przebieg tych próbek, a nie jak model zachowuje się przy innych promptach, we wdrożeniu czy wobec atakującego, który się dostosowuje. Sędzia sprawdzony przez ludzi jest sprawdzony na przypadkach, które oznaczyli, i na modelu, który je oceniał, a nie na transkryptach do nich niepodobnych. A odsetek ograniczony poniżej 1% na twoim zestawie ataków nic nie mówi o atakach, których twój zestaw nie zawiera.