Techos de riesgo

Un techo acota con qué frecuencia, o en qué medida, algo sale mal: respuestas inseguras, datos filtrados, ataques que tienen éxito, un coste o una latencia. Oloproof mide los techos que declara su política, en los casos que contiene su suite. No escribe ataques ni busca fallos nuevos; si otra herramienta lo hace, Oloproof lee los resultados por caso de esa herramienta y decide el techo sobre ellos.

Dos tipos de techo

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: decide sobre un intervalo. La regla pasa cuando el límite superior del intervalo está en el techo o por debajo, falla cuando su límite inferior lo supera, y es INSUFFICIENT_EVIDENCE entre ambos casos. El intervalo es bilateral al confidence_level de la política, 95% por defecto, y un techo solo lee su extremo superior, de modo que un sistema cuya tasa real supera el techo pasa como mucho el 2.5% de las veces, cuando sus casos son independientes (una suite que declara grupos se lee con un intervalo que los tiene en cuenta, Casos agrupados). Para un criterio de aprobado o suspenso, la tasa es la proporción de casos que pasan, así que el criterio debe pasar cuando ocurrió lo que hay que acotar (unsafe pasa con una respuesta insegura). Un mínimo sobre el criterio opuesto decide lo mismo: min: 0.98 sobre un criterio que pasa con una respuesta segura es la misma regla que max: 0.02 sobre uno que pasa con una insegura.

max_failures: cuenta. Lee los casos que no pasaron en la suite tal como se ejecutó, sin intervalo, y no afirma nada más allá de esos casos. Falla en cuanto el recuento supera el límite; un caso sin veredicto cuenta en su contra hasta que tenga uno, de modo que una suite con veredictos ausentes que podrían llevarla por encima del límite es INSUFFICIENT_EVIDENCE, no un aprobado. Úselo para lo que nunca debe ocurrir en una suite que usted escribió a propósito, donde una tasa sobre una población no significaría nada.

Cuántos casos necesita un techo

Un techo bajo necesita muchos casos, incluso cuando nada sale mal. Al 95%, con el intervalo exacto que Oloproof usa para una tasa de aprobado o suspenso:

Sin ningún fallo observado, hacen falta unos 3.7 divididos entre el techo. Una suite más pequeña que eso no puede pasar la regla, haga lo que haga el sistema, y el gate lo dice: un techo sin decidir es INSUFFICIENT_EVIDENCE, con una línea que dice cuántos casos más lo decidirían.

Leer los resultados de una herramienta de red team

Una herramienta de red team escribe los ataques y califica cada respuesta. Sus calificaciones por caso son lo que necesita un techo, y oloproof scores import las lee (Una segunda opinión). La carpeta recipes/ del ejemplo contiene una para 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

Cada ataque se convierte en un caso, y su calificación se convierte en resisted, que pasa cuando el objetivo resistió. Las filas que promptfoo no pudo calificar no llevan veredicto y cuentan como ausentes. Una política para ello:

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 califica con un modelo, y Oloproof lo trata como trata a cualquier juez: hasta que unas personas hayan etiquetado una muestra de sus calificaciones, no puede decidir una publicación, y las reglas se detienen en evaluator_not_validated (Comprobar el juez). Para comparar dos versiones, ejecute el mismo redteam.yaml en ambas: un caso es el lugar del ataque en ese archivo, y volver a generar los ataques produce otros casos.

Lo que un techo no dice

• Un techo sobre una tasa se refiere a la población que muestrea su suite. Una suite de red team está hecha de ataques que alguien escribió, no de una muestra de tráfico real, así que su tasa es una tasa sobre esos ataques; ahí el recuento suele ser la regla más clara.
• Ninguno de los dos tipos cubre un fallo que ningún caso ejercita. La cota se refiere a lo que se ejecutó.
• Un techo que pasa es evidencia para su decisión de publicación, no una certificación de seguridad.

Siguientes pasos

• Gates en CI: el archivo de política, bloquear y avisar, y los códigos de salida.
• Una segunda opinión: el archivo de puntuaciones que escribe cada receta.
• Jueces: medir a un calificador frente a personas antes de que pueda decidir.