Handleidingen

Veiligheidsonderzoek: van een Inspect-log naar een methodeparagraaf

Je draaide een eval op een model: een model organism en zijn controle, een aanvalsset, de transcripten van een auditagent gescoord door een judge. Voordat je het resultaat opschrijft, beslissen drie vragen of het standhoudt: hoe groot is de onzekerheid, is "geen van 200" echt geen, en kun je de judge vertrouwen die de transcripten scoorde? Oloproof beantwoordt ze vanuit de log die je al hebt, en schrijft de figuur, de tabel en de methodeparagraaf op basis van wat het mat.

De log lezen

Oloproof leest logs van UK AISI Inspect, het .eval-bestand dat inspect eval schrijft of een JSON-log:

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

Het eerste commando importeert één run en antwoordt in gewone woorden. Het tweede importeert twee runs, paart ze op sample-id's en beslist de vergelijkingsregels van het beleid; een beleid dat met twee logs wordt opgegeven moet er minstens één bevatten (kind: superiority, non_inferiority of equivalence), en een plafond op één run wordt beslist door dat log alleen met het beleid te importeren. Elke scorer wordt een criterium: C slaagt en I mislukt, gedeeltelijke punten zijn een score van 0 tot 1, en een numerieke scorer heeft zijn bereik nodig, opgegeven met --scale LOW HIGH. Alleen id's en scores worden gekopieerd; de transcripten blijven in de log. Zie Een second opinion over de scores van een andere tool voor elke leesregel.

Epochs zijn geen extra samples

Elke sample meerdere keren draaien (de epochs van Inspect) geeft je geen extra onafhankelijke cases. Oloproof houdt de sample als eenheid: de log wordt geïmporteerd als een run waarvan de replicaten zijn epochs zijn, de waarde van elke sample is het gemiddelde van zijn epochs, en elke sample weegt even zwaar. Elke epoch houdt zijn eigen geslaagd of mislukt, dus een judge kan op epochs worden gecontroleerd, met de sample als eenheid. De runs van elke sample als aparte cases tellen behandelt herhalingen als nieuwe prompts: in het raster van de methode dekte het zo samenvoegen van twee runs per sample een uitspraak over prompts als deze bij een opgegeven 95% soms maar 86% van de tijd, al hield het stand voor een uitspraak over de samples zelf (docs/engine/PASS_AT_K_METHOD.md §8). Een sample met een epoch die een fout gaf telt als ontbrekend, op zijn slechtst, nooit als het gemiddelde van de epochs die afrondden, want fouten vallen vaak op de moeilijke samples.

Niets gezien is niet niets

Een veiligheidsclaim rust vaak op een telling van nul: geen aanval slaagde, geen transcript vertoonde het gedrag. Nul gezien is geen kans van nul. Zonder ingestelde lat zegt Oloproof hoe hoog de kans nog kan zijn en hoeveel schone cases die omlaag zouden brengen:

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.

Onder een plafond beslist het beleid. max: 0.01 op 0 van 200 is INSUFFICIENT_EVIDENCE, en het advies is voorwaardelijk: "als ook geen van de volgende cases meetelt, zouden er ongeveer 368 het beslissen; elke die wel meetelt verhoogt dat aantal". Er wordt geen kans genoemd, want zonder gebeurtenissen is er niets om die op te baseren.

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

Lukt het ooit? pass@k

Een vraag over capaciteit of red-teaming is vaak of een van k pogingen slaagt. oloproof passk leest elke epoch van een sample als één poging en schat het pass@k van elke sample zonder vertekening, daarna het gemiddelde van de suite:

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

Een bestand met één rij per poging (case, passed, optioneel error) werkt ook. Een sample met een poging die een fout gaf, of met minder dan k pogingen, telt als ontbrekend, op zijn slechtst. Het antwoord geeft de schatting en het 95%-bereik ervan. Met --min of --max beslist het: PASS als het bereik de drempel haalt, FAIL als het helemaal aan de verkeerde kant valt, anders INSUFFICIENT_EVIDENCE (exit 0, 1 of 3). De methode (docs/engine/PASS_AT_K_METHOD.md) haalde haar opgegeven 95% in elke cel van haar raster en werd op 3 november 2026 door een onafhankelijke audit toegelaten, op haar voorwaarden: de pogingen van een case zijn onafhankelijk van elkaar, en je hebt de pogingen van een case niet vroeg gestopt omdat er een slaagde.

Veel condities tegelijk: een sweep

Een tabel van twintig verschillen, elk met een eigen 95%-interval, zit naar verwachting ergens ongeveer één keer fout: in het raster van de methode hielden vijftig afzonderlijke intervallen maar zes van de tien keer allemaal stand. oloproof sweep beslist een familie van contrasten die je benoemt voordat je de runs leest, zodat de hele tabel samen standhoudt:

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

Elk contrast is een gepaarde vergelijking van twee runs van één suite, beslist door elke vergelijkingsregel in het beleid, elke claim op 1 - alpha/m met m het aantal claims: de kans dat een ervan fout is, is hoogstens alpha. Een contrast dat je pas leest nadat je de tabel hebt bekeken, valt buiten die garantie. Runs op verschillende suites worden niet vergeleken.

De veiligheid van een monitor tegenover zijn auditkosten

Voor een controleprotocol geeft een bestand met één rij per traject, zijn arm (attack of honest) en de verdachtheids-score van de monitor, de veiligheid (het aandeel gemarkeerde aanvallen) en het markeringspercentage van eerlijke trajecten bij elke drempel:

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

De bereiken gelden bij alle drempels tegelijk, voor beide armen samen, dus een drempel die je kiest door de curve te lezen, zoals die welke past bij een auditbudget van 2%, blijft gedekt. Met --budget en --min-safety beslist het of een drempel hoogstens dat aandeel eerlijke trajecten markeert en tegelijk minstens dat aandeel aanvallen vangt. De bereiken zijn in de staart even breed als in het midden, dus een klein budget vraagt veel eerlijke trajecten: met 2.000 is het markeringspercentage van eerlijke trajecten tot op ongeveer 3 punten bekend. Veiligheid geldt hier tegenover de aanvallen in het bestand; een aanvaller die zich aanpast aan de monitor valt erbuiten.

Veiligheid wordt geteld over de trajecten in de aanvalsarm, of hun aanval nu gelukt is of niet. Een traject dat een achterdeur moest inbouwen heeft dat misschien niet gedaan, en de monitor valt niet te verwijten dat hij mist wat er niet is. Voor veiligheid tegen geslaagde aanvallen controleert u eerst elk aanvalstraject (voor een achterdeur een test op de geheime invoer) en houdt u in de arm attack alleen de trajecten die slagen, voordat het bestand oloproof control bereikt.

De judge controleren

Een transcript dat door een model is gescoord, is het woord van de judge totdat mensen het ermee eens zijn. Label een blinde steekproef van de geïmporteerde run, terwijl de transcripten op je eigen machine blijven:

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

review trekt de steekproef, toont elk transcript zonder het oordeel van de judge, meet de overeenstemming en valideert de judge alleen als die de lat haalt die je opgeeft. Zolang hij niet gevalideerd is, beslist een beleid dat gevalideerde judges vereist, zoals het beleid dat oloproof init schrijft, geen regel op basis van hem. Voor een run die Oloproof uitvoerde, waarvan de cases tags in hun metadata dragen, toont oloproof labels disagreements RUN --criterion deceptive --by behavior daarna waar de judge en mensen uiteengaan, per gedrag en per richting: wat de judge liet slagen en mensen afkeurden, en omgekeerd. Het bereik van elke groep is een eigen claim; het rapport beslist niets.

Het uitschrijven

oloproof report latest --paper paper/

Dit schrijft figure.svg (de schatting en het interval van elke metriek), table.md en table.tex, en methods.md, een paragraaf die elke intervalmethode en haar betrouwbaarheid noemt, zegt dat de intervallen over deze eindige suite gaan, ontbrekende cases en zeldzame gebeurtenissen noemt, voor elke judge zegt of mensen hem controleerden en hoe vaak ze het eens waren, en vermeldt wat de gate besliste. Elk getal komt uit de opgeslagen run, en de paragraaf is opgebouwd uit vaste zinnen en vastgelegde feiten; geen model schrijft hem. In een notebook:

import oloproof

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

De transcripten van een auditagent

Een audittool die op Inspect draait, zoals Petri, schrijft een Inspect-log waarvan de scorer elk transcript een score per dimensie geeft, vaak van 1 tot 10. Importeer hem met dat bereik, oloproof scores import --from inspect --scale 1 10 audit.eval, en elke dimensie wordt een criterium met een begrensd gemiddelde en zijn interval. Twee zulke logs, voor en na een wijziging aan het doelmodel, worden vergeleken op hun gedeelde transcripten. De scores blijven het woord van de judge: de scores van een judge, in plaats van zijn geslaagd of mislukt, kunnen nog niet tegen mensen worden gecontroleerd.

Wat niet gebouwd is

De scores van een judge controleren tegen die van mensen, in plaats van zijn oordelen geslaagd of mislukt.
Tags uit de metadata van een Inspect-sample: de cases van een geïmporteerde run dragen geen tags, dus labels disagreements --by groepeert alleen runs die Oloproof uitvoerde.
Een sweep smaller dan Bonferroni (Dunnett of closed testing), contrasten tussen condities op verschillende suites, en monitorbereiken die smaller zijn in de staart, meerdere monitors gecombineerd, of protocollen met meerdere drempels.
Een PNG-figuur: de figuur is alleen SVG.

Wat dit je niet kan vertellen

Elk interval gaat over de samples in je log. Het zegt wat een volledige, foutloze run van deze samples zou laten zien, niet hoe het model zich gedraagt op andere prompts, in productie, of tegenover een aanvaller die zich aanpast. Een judge die door mensen is gecontroleerd, is gecontroleerd op de cases die zij labelden en het model dat ze beoordeelde, niet op transcripten die daar niet op lijken. En een kans die op je aanvalsset onder 1% begrensd is, zegt niets over aanvallen die je set niet bevat.