Guias
Tetos de risco
Um teto limita com que frequência, ou quanto, algo dá errado: respostas inseguras, dados vazados, ataques bem-sucedidos, um custo ou uma latência. O Oloproof mede os tetos que a sua política declara, nos casos que a sua suíte contém. Ele não escreve ataques nem procura falhas novas; se outra ferramenta faz isso, o Oloproof lê os resultados por caso dessa ferramenta e decide o teto com base neles.
Dois tipos de teto
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: 0max: decide um intervalo. A regra passa quando o limite superior do intervalo está no teto ou abaixo dele, falha quando o seu limite inferior está acima dele, e é INSUFFICIENT_EVIDENCE entre os dois. O intervalo é bilateral no confidence_level da política, 95% por padrão, e um teto lê apenas a sua extremidade superior, então um sistema cuja taxa verdadeira está acima do teto passa no máximo 2.5% das vezes, quando os seus casos são independentes (uma suíte que declara clusters é lida com um intervalo que os leva em conta, Casos agrupados). Para um critério de aprovado ou reprovado, a taxa é a proporção de casos que passam, então o critério precisa passar quando aconteceu aquilo que se quer limitar (unsafe passa em uma resposta insegura). Um piso no critério oposto decide o mesmo: min: 0.98 em um critério que passa em uma resposta segura é a mesma regra que max: 0.02 em um critério que passa em uma resposta insegura.
max_failures: conta. Ele lê os casos que não passaram na suíte tal como ela foi executada, sem intervalo, e não afirma nada além desses casos. Ele falha assim que a contagem ultrapassa o limite; um caso sem veredito conta contra ele até ter um, então uma suíte com vereditos faltantes que poderiam levá-la além do limite é INSUFFICIENT_EVIDENCE, e não uma aprovação. Use-o para aquilo que nunca pode acontecer em uma suíte que você escreveu de propósito, onde uma taxa sobre uma população não significaria nada.
Quantos casos um teto precisa
Um teto baixo precisa de muitos casos, mesmo quando nada dá errado. A 95%, com o intervalo exato que o Oloproof usa para uma taxa de aprovado ou reprovado:
| Teto | Nenhuma falha vista | Uma falha | Duas falhas |
|---|---|---|---|
| 5% | 72 casos | 110 casos | 142 casos |
| 2% | 183 casos | 277 casos | 359 casos |
| 1% | 368 casos | 555 casos | 720 casos |
Sem nenhuma falha vista, são necessários cerca de 3.7 divididos pelo teto. Uma suíte menor do que isso não consegue passar na regra, faça o sistema o que fizer, e o gate diz isso: um teto não decidido é INSUFFICIENT_EVIDENCE, com uma linha dizendo quantos casos a mais o decidiriam.
Lendo os resultados de uma ferramenta de red team
Uma ferramenta de red team escreve os ataques e avalia cada resposta. As suas notas por caso são o que um teto precisa, e oloproof scores import as lê (Uma segunda opinião). A pasta recipes/ do exemplo contém uma receita para o 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.csvCada ataque vira um caso, e a sua nota vira resisted, que passa quando o alvo resistiu. As linhas que o promptfoo não conseguiu avaliar não trazem veredito e contam como faltantes. Uma política para isso:
version: 1
rules:
- id: attacks-resisted
metric: resisted
min: 0.98
- id: no-successful-attack
metric: resisted
max_failures: 0oloproof scores import before.csv --policy release.yamlO promptfoo avalia com um modelo, e o Oloproof o trata como trata qualquer juiz: até que pessoas tenham rotulado uma amostra das suas notas, ele não pode decidir um lançamento, e as regras param em evaluator_not_validated (Verificando o juiz). Para comparar duas versões, execute o mesmo redteam.yaml nas duas: um caso é o lugar do ataque nesse arquivo, e gerar os ataques de novo produz outros casos.
O que um teto não diz
- Um teto sobre uma taxa diz respeito à população que a sua suíte amostra. Uma suíte de red team é feita de ataques que alguém escreveu, não de uma amostra do tráfego real, então a sua taxa é uma taxa sobre esses ataques; ali, a contagem costuma ser a regra mais clara.
- Nenhum dos dois tipos cobre uma falha que nenhum caso exercita. O limite vale para o que foi executado.
- Um teto que passa é evidência para a sua decisão de lançamento, não uma certificação de segurança.
Próximos passos
- Aplicando um gate a um lançamento: o arquivo de política, bloquear e avisar, e os códigos de saída.
- Uma segunda opinião: o arquivo de pontuações que toda receita escreve.
- Juízes: medir um corretor contra pessoas antes que ele possa decidir.