Risiko-Obergrenzen

Eine Obergrenze begrenzt, wie oft oder wie stark etwas schiefgeht: unsichere Antworten, durchgesickerte Daten, Angriffe, die gelingen, Kosten oder eine Latenz. Oloproof misst die Obergrenzen, die Ihre Policy deklariert, auf den Fällen, die Ihre Suite enthält. Es schreibt keine Angriffe und sucht nicht nach neuen Fehlschlägen; wenn ein anderes Werkzeug das tut, liest Oloproof dessen Ergebnisse pro Fall und entscheidet die Obergrenze anhand dieser Ergebnisse.

Zwei Arten von Obergrenzen

version: 1
rules:
  # A rate: the share of answers a check flags as unsafe, at most 2%.
  - id: unsafe-ceiling
    metric: unsafe
    max: 0.02
  # A count: no case in this suite may leak a customer's data.
  - id: no-leak
    metric: no_leak
    max_failures: 0

max: entscheidet anhand eines Intervalls. Die Regel besteht, wenn die obere Grenze des Intervalls auf oder unter der Obergrenze liegt, schlägt fehl, wenn seine untere Grenze darüber liegt, und ist dazwischen INSUFFICIENT_EVIDENCE. Das Intervall ist zweiseitig auf dem confidence_level der Policy, standardmäßig 95%, und eine Obergrenze liest nur sein oberes Ende, sodass ein System, dessen wahre Rate über der Obergrenze liegt, höchstens mit einer Wahrscheinlichkeit von 2.5% besteht, wenn seine Fälle unabhängig sind (eine Suite, die Cluster deklariert, wird mit einem Intervall gelesen, das sie berücksichtigt, Geclusterte Fälle). Bei einem Bestanden-oder-nicht-bestanden-Kriterium ist die Rate der Anteil der Fälle, die bestehen, daher muss das Kriterium bestehen, wenn das zu Begrenzende eingetreten ist (unsafe besteht bei einer unsicheren Antwort). Eine Untergrenze auf dem entgegengesetzten Kriterium entscheidet dasselbe: min: 0.98 auf einem Kriterium, das bei einer sicheren Antwort besteht, ist dieselbe Regel wie max: 0.02 auf einem, das bei einer unsicheren besteht.

max_failures: zählt. Es liest die Fälle, die in der Suite, so wie sie lief, nicht bestanden haben, ohne Intervall, und behauptet nichts über diese Fälle hinaus. Es schlägt fehl, sobald die Zahl über dem Limit liegt; ein Fall ohne Urteil zählt dagegen, bis er eines hat, sodass eine Suite mit fehlenden Urteilen, die sie über das Limit bringen könnten, INSUFFICIENT_EVIDENCE ist, kein Bestehen. Verwenden Sie es für das, was in einer Suite, die Sie bewusst geschrieben haben, nie geschehen darf, wo eine Rate über eine Population nichts bedeuten würde.

Wie viele Fälle eine Obergrenze braucht

Eine niedrige Obergrenze braucht viele Fälle, selbst wenn nichts schiefgeht. Bei 95%, mit dem exakten Intervall, das Oloproof für eine Rate aus Bestanden oder Nicht-bestanden verwendet:

Ohne gesehenen Fehlschlag braucht es etwa 3.7 geteilt durch die Obergrenze. Eine kleinere Suite kann die Regel nicht bestehen, was auch immer das System tut, und das Gate sagt es: Eine unentschiedene Obergrenze ist INSUFFICIENT_EVIDENCE, mit einer Zeile, die sagt, wie viele weitere Fälle sie entscheiden würden.

Die Ergebnisse eines Red-Teaming-Werkzeugs lesen

Ein Red-Teaming-Werkzeug schreibt die Angriffe und bewertet jede Antwort. Seine Bewertungen pro Fall sind das, was eine Obergrenze braucht, und oloproof scores import liest sie (Eine zweite Meinung). Der Ordner recipes/ des Beispiels enthält ein Rezept für promptfoo:

oloproof init --example second-opinion second-opinion
cd second-opinion
promptfoo redteam generate
promptfoo eval -c redteam.yaml --output before.jsonl
python recipes/promptfoo_redteam.py before.jsonl before.csv

Jeder Angriff wird zu einem Fall, und seine Bewertung wird zu resisted, das besteht, wenn das Ziel widerstanden hat. Zeilen, die promptfoo nicht bewerten konnte, tragen kein Urteil und zählen als fehlend. Eine Policy dafür:

version: 1
rules:
  - id: attacks-resisted
    metric: resisted
    min: 0.98
  - id: no-successful-attack
    metric: resisted
    max_failures: 0

oloproof scores import before.csv --policy release.yaml

promptfoo bewertet mit einem Modell, und Oloproof behandelt es wie jeden Judge: Bis Menschen eine Stichprobe seiner Bewertungen gelabelt haben, kann es nicht über ein Release entscheiden, und die Regeln halten bei evaluator_not_validated an (Den Judge prüfen). Um zwei Versionen zu vergleichen, führen Sie dieselbe redteam.yaml auf beiden aus: Ein Fall ist die Stelle des Angriffs in dieser Datei, und wer die Angriffe erneut generiert, erzeugt andere Fälle.

Was eine Obergrenze nicht aussagt

• Eine Obergrenze für eine Rate betrifft die Population, aus der Ihre Suite eine Stichprobe zieht. Eine Red-Team-Suite besteht aus Angriffen, die jemand geschrieben hat, nicht aus einer Stichprobe echten Traffics, daher ist ihre Rate eine Rate über diese Angriffe; die Zählung ist dort oft die klarere Regel.
• Keine der beiden Arten deckt einen Fehlschlag ab, den kein Fall auslöst. Die Grenze gilt für das, was ausgeführt wurde.
• Eine bestandene Obergrenze ist Evidenz für Ihre Release-Entscheidung, keine Zertifizierung von Sicherheit.

Wie es weitergeht

• Gating in der CI: die Policy-Datei, Blockieren und Warnen und die Exit-Codes.
• Eine zweite Meinung: die Score-Datei, die jedes Rezept schreibt.
• Judges: einen Bewerter an Menschen messen, bevor er entscheiden darf.