Capítulo 27 — Segurança de IA e aprendizado de máquina: verificação | Graduação Segurança de IA e aprendizado de máquina

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Mapa da aula

Aula 27 publicada. Mapa, exemplo, EX079.

flowchart TD
  N0["27.1 Requisitos a verificar"]
  N1["27.2 Critérios de aceitação"]
  N2["27.3 Verificação de ponta a ponta"]
  N3["27.4 Relatórios"]
  N4["27.5 Regressão"]
  N5["27.5b Verificar versões, não nomes"]
  N6["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX079"]

Desenho lógico

flowchart LR
  N0["27.1 Requisitos a verificar"]
  N1["27.2 Critérios de aceitação"]
  N2["27.3 Verificação de ponta a ponta"]
  N3["27.4 Relatórios"]
  N4["27.5 Regressão"]
  N5["27.5b Verificar versões, não nomes"]
  N6["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX079"]

[27.1 Requisitos a verificar]
    |
    v
[27.2 Critérios de aceitação]
    |
    v
[27.3 Verificação de ponta a ponta]
    |
    v
[27.4 Relatórios]
    |
    v
[27.5 Regressão]
    |
    v
[27.5b Verificar versões, não nomes]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX079]

Objetivos de aprendizagem

Você vai (1) verificar com evidência estatística se os requisitos de segurança de IA são atendidos; (2) definir critérios de aceitação com limites de confiança; (3) verificar os controles de ponta a ponta; e (4) redigir relatórios de verificação.

27.1 Requisitos a verificar

Requisitos como "nenhuma marcação para um paciente que não seja o paciente conectado ou seu cuidador" são verificados por testes de política (determinísticos) e por suítes adversariais (estatísticas). "Taxa de vazamento abaixo de 1% com 95% de confiança" exige casos suficientes: com zero falhas, cerca de 300 casos dão um limite superior perto de 1% (regra de três). O teste de política é feito uma vez por regra, porque o resultado não varia; a suíte adversarial é repetida, porque o comportamento do modelo varia. Ambos são necessários, já que um teste de política não consegue mostrar com que frequência o modelo tenta uma ação proibida.

27.2 Critérios de aceitação

Decida antes de testar: métrica, tamanho da amostra, limiar e confiança. Use limites superiores de Wilson, e não estimativas pontuais, ao decidir entre aprovação e reprovação.

"""Lab S: reporting attack-success rates honestly: Wilson intervals,
seed variation and a paired bootstrap. Synthetic trial outcomes only."""
import math, random
def wilson(k, n, z=1.96):
    p = k/n; d = 1 + z*z/n
    c = (p + z*z/(2*n))/d; h = z*math.sqrt(p*(1-p)/n + z*z/(4*n*n))/d
    return c - h, c + h
for k, n in ((3, 20), (30, 200), (300, 2000)):
    lo, hi = wilson(k, n); print(f"successes={k}/{n} rate={k/n:.3f} wilson95=[{lo:.3f}, {hi:.3f}]")
# five seeds of a synthetic defence evaluation: per-seed attack success rate
rates = []
for seed in range(5):
    r = random.Random(seed); rates.append(sum(r.random() < 0.12 for _ in range(200))/200)
m = sum(rates)/5; sd = math.sqrt(sum((x-m)**2 for x in rates)/4)
print("per-seed rates:", " ".join(f"{x:.3f}" for x in rates), f"mean={m:.3f} sd={sd:.3f}")
# paired bootstrap: baseline vs defence on the same 300 synthetic prompts
r = random.Random(42)
base = [r.random() < 0.30 for _ in range(300)]
defn = [b and r.random() < 0.6 for b in base]   # defence blocks ~40% of successes
diffs = []
for _ in range(2000):
    idx = [r.randrange(300) for _ in range(300)]
    diffs.append(sum(base[i] for i in idx)/300 - sum(defn[i] for i in idx)/300)
diffs.sort()
print(f"baseline_asr={sum(base)/300:.3f} defended_asr={sum(defn)/300:.3f} "
      f"reduction_ci95=[{diffs[50]:.3f}, {diffs[1949]:.3f}]")

Saída esperada:

successes=3/20 rate=0.150 wilson95=[0.052, 0.360]
successes=30/200 rate=0.150 wilson95=[0.107, 0.206]
successes=300/2000 rate=0.150 wilson95=[0.135, 0.166]
per-seed rates: 0.110 0.130 0.135 0.105 0.145 mean=0.125 sd=0.017
baseline_asr=0.350 defended_asr=0.190 reduction_ci95=[0.120, 0.203]

O laboratório mostra por que o tamanho da amostra importa: três sucessos em 20 e 300 em 2000 dão a mesma taxa, mas o limite superior cai de 0.360 para 0.166. Um limiar de 20% reprovaria a amostra pequena e aprovaria a grande, embora a taxa observada seja idêntica. Por isso, Rina dimensionou cada suíte do Ask Lumen a partir do limiar antes de escrever qualquer caso, escolhendo o número de tentativas capaz de sustentar uma aprovação se a defesa funcionasse como se esperava.

27.3 Verificação de ponta a ponta

Testes unitários provam componentes; testes de ponta a ponta provam o sistema. Reexecute as suítes adversariais pela cadeia completa — recuperação, modelo, política, ferramentas numa sandbox — e inspecione os logs das ferramentas. Muitas falhas só aparecem nos pontos de integração, como identificadores resolvidos depois de uma verificação de política. O exemplo disso no Ask Lumen foi um cancelamento que nomeava a consulta por sua posição numa lista ("a segunda"); o serviço de políticas verificava o paciente, mas a ferramenta resolvia "segunda" contra uma lista obtida depois, que podia ser diferente. Só uma reexecução de ponta a ponta o revelou, e a correção passou a resolver o identificador antes da verificação.

27.4 Relatórios

Para cada requisito: método, amostra, resultado com intervalo, aprovação ou reprovação, local das evidências, versões testadas e limitações. Uma linha do relatório de Rina para o requisito de marcação para outro paciente dizia: suíte adversarial, 400 casos, 0 falhas, limite superior de cerca de 0.95%, aprovado, evidências no arquivo de logs da homologação, versões de modelo e prompt listadas, apenas inglês. Cada elemento permite que um revisor reproduza ou conteste o resultado, e a limitação lhe diz onde a afirmação termina. As linhas de requisitos reprovados usam o mesmo formato, para que uma falha não possa ser escondida na prosa.

27.5 Regressão

Toda falha encontrada vira um teste permanente. Reexecute a suíte a cada mudança de modelo, prompt ou ferramenta. Quando a reexecução de ponta a ponta encontrou o problema do identificador de cancelamento, Rina acrescentou exatamente aquela conversa à suíte permanente. Meses depois, uma refatoração da ferramenta de cancelamento reintroduziu por pouco tempo a consulta tardia, e o teste de regressão falhou antes que a mudança chegasse à produção. Sem o teste permanente, a mesma falha teria voltado sem ser notada, já que ninguém se lembrava em detalhe do incidente original. O teste é barato de manter.

27.5b Verificar versões, não nomes

A verificação se aplica a uma configuração específica: versão do modelo, versão do prompt de sistema, snapshot do índice de recuperação, conjunto de ferramentas e regras de política. Um relatório que diz "o Ask Lumen passou" sem versões não serve de apoio depois da próxima mudança. Registre o hash da configuração no relatório e faça o pipeline de implantação recusar configurações que não foram verificadas. Na LCH, uma atualização do modelo do provedor chegou numa quinta-feira, e o pipeline bloqueou a implantação até que a suíte fosse reexecutada. Duas recusas haviam mudado de redação, e todos os requisitos de segurança continuavam aprovados, então a nova versão foi registrada e liberada no dia seguinte.

27.6 Exemplo resolvido (caso sintético da LCH)

Rina verificou dez requisitos do Ask Lumen v2. Nove passaram. "Informação falsa sobre clínicas ≤ 2% (limite superior de 95%)" falhou: 4/300 observados (1.3%), mas o limite superior de Wilson era 3.4%. Depois da verificação de embasamento, observou-se 1/600, com limite superior abaixo de 1%, e o requisito passou. A falha é instrutiva porque a taxa observada estava bem abaixo do limiar; só o intervalo mostrou que 300 casos não bastavam para ter certeza. Depois da verificação de embasamento, a taxa de falhas menor e a amostra maior, juntas, levaram o limite superior a cerca de 0.94%, com folga abaixo do requisito. O relatório de Rina manteve os dois resultados, para que os leitores pudessem ver que o requisito havia falhado antes de passar.

27.7 Erros e limites

Três erros são comuns: decidir os limiares depois de ver os resultados; estimativas pontuais usadas para aprovar ou reprovar; e apenas testes unitários. Um limiar escolhido depois dos resultados sempre pode ser ajustado para aprovar, o que torna o teste sem sentido. Usar a estimativa pontual, como com 4 de 300, teria aprovado um requisito que a evidência não sustentava. Testes unitários, sozinhos, teriam deixado passar a falha do identificador de cancelamento, que só existia onde o serviço de políticas e a ferramenta se encontravam. Rina fixou os limiares no plano de testes antes de qualquer execução, e o plano foi revisado.

Exercícios

EX079 — Tamanho da amostra. Quantos casos com zero falhas sustentam um limite superior perto de 0.5%? Rubrica: 3 = cerca de 600 (3/0.005); 2 = método; 1 = deslize; 0 = nenhum.
EX080 — Aprovação/reprovação. Por que 4/300 reprovou um requisito de 2%? Rubrica: 3 = limite superior de 3.4% > 2% apesar da estimativa pontual de 1.3%; 2 = parcial; 1 = usa a estimativa pontual; 0 = errado.
EX081 — Leitura do laboratório. Quais são a média e o desvio-padrão por semente no Lab S, e por que relatá-los? Rubrica: 3 = 0.125 e 0.017; os resultados variam com a aleatoriedade; 2 = os números; 1 = vago; 0 = errado.

Síntese

A verificação prova os requisitos com critérios estatísticos definidos de antemão e testes de ponta a ponta, e guarda cada falha como teste de regressão.

Continue estudando — capítulo 27 de 40

← Capítulo 26 (rascunho) · Índice de capítulos do curso · Capítulo 28 (rascunho) →