Plafonds de risque

Un plafond borne la fréquence ou l’ampleur d’un problème : des réponses dangereuses, des données divulguées, des attaques qui réussissent, un coût ou une latence. Oloproof mesure les plafonds que déclare votre politique, sur les cas que contient votre suite. Il n’écrit pas d’attaques et ne cherche pas de nouveaux échecs ; si un autre outil le fait, Oloproof lit les résultats par cas de cet outil et décide du plafond sur ces résultats.

Deux sortes de plafond

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: décide sur un intervalle. La règle réussit lorsque la borne supérieure de l’intervalle est égale ou inférieure au plafond, échoue lorsque sa borne inférieure le dépasse, et donne INSUFFICIENT_EVIDENCE entre les deux. L’intervalle est bilatéral au confidence_level de la politique, 95% par défaut, et un plafond ne lit que son extrémité supérieure, si bien qu’un système dont le taux réel dépasse le plafond réussit au plus 2.5% du temps, lorsque ses cas sont indépendants (une suite qui déclare des groupes est lue avec un intervalle qui en tient compte, Cas groupés). Pour un critère de réussite ou d’échec, le taux est la part des cas qui réussissent, donc le critère doit réussir lorsque ce qu’il faut borner s’est produit (unsafe réussit sur une réponse dangereuse). Un seuil minimal sur le critère opposé décide de la même manière : min: 0.98 sur un critère qui réussit sur une réponse sûre est la même règle que max: 0.02 sur un critère qui réussit sur une réponse dangereuse.

max_failures: compte. Il lit les cas qui n’ont pas réussi dans la suite telle qu’elle a été exécutée, sans intervalle, et n’affirme rien au-delà de ces cas. Il échoue dès que le décompte dépasse la limite ; un cas sans verdict compte contre la règle tant qu’il n’en a pas, si bien qu’une suite dont les verdicts manquants pourraient faire dépasser la limite donne INSUFFICIENT_EVIDENCE, pas une réussite. Utilisez-le pour ce qui ne doit jamais arriver dans une suite que vous avez écrite à dessein, où un taux sur une population ne voudrait rien dire.

Combien de cas demande un plafond

Un plafond bas demande beaucoup de cas, même quand rien ne tourne mal. À 95%, avec l’intervalle exact qu’Oloproof utilise pour un taux de réussite ou d’échec :

Sans échec observé, il en faut environ 3.7 divisé par le plafond. Une suite plus petite que cela ne peut pas faire réussir la règle, quoi que fasse le système, et la porte le dit : un plafond non tranché donne INSUFFICIENT_EVIDENCE, avec une ligne qui indique combien de cas supplémentaires le trancheraient.

Lire les résultats d’un outil de red team

Un outil de red team écrit les attaques et note chaque réponse. Ses notes par cas sont ce dont un plafond a besoin, et oloproof scores import les lit (Un second avis). Le dossier recipes/ de l’exemple en contient une pour 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

Chaque attaque devient un cas, et sa note devient resisted, qui réussit lorsque la cible a résisté. Les lignes que promptfoo n’a pas pu noter ne portent aucun verdict et comptent comme manquantes. Une politique pour ces résultats :

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 note avec un modèle, et Oloproof le traite comme il traite tout juge : tant que des personnes n’ont pas étiqueté un échantillon de ses notes, il ne peut pas décider d’une publication, et les règles s’arrêtent à evaluator_not_validated (Vérifier le juge). Pour comparer deux versions, exécutez le même redteam.yaml sur les deux : un cas est la place de l’attaque dans ce fichier, et générer à nouveau les attaques produit d’autres cas.

Ce qu’un plafond ne dit pas

• Un plafond de taux porte sur la population qu’échantillonne votre suite. Une suite de red team est faite d’attaques que quelqu’un a écrites, pas d’un échantillon du trafic réel, donc son taux est un taux sur ces attaques ; le décompte y est souvent la règle la plus claire.
• Aucune des deux sortes ne couvre un échec qu’aucun cas ne met à l’épreuve. La borne porte sur ce qui a été exécuté.
• Un plafond qui réussit est une preuve pour votre décision de publication, pas une certification de sécurité.

Pour aller plus loin

• Porte de CI : le fichier de politique, bloquer et avertir, et les codes de sortie.
• Un second avis : le fichier de scores qu’écrit chaque recette.
• Juges : mesurer un correcteur par rapport à des personnes avant qu’il puisse décider.