Capítulo 13 — Segurança de IA e aprendizado de máquina: solução de problemas
Mapa da aula
Aula 13 publicada. Mapa, exemplo, EX049.
flowchart TD
N0["13.1 Passo a passo"]
N1["13.2 Ferramentas"]
N2["13.3 Causas"]
N3["13.4 Escalonamento"]
N4["13.6b Documentando a correção"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX049"]
Desenho lógico
flowchart LR
N0["13.1 Passo a passo"]
N1["13.2 Ferramentas"]
N2["13.3 Causas"]
N3["13.4 Escalonamento"]
N4["13.6b Documentando a correção"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX049"]
[13.1 Passo a passo]
|
v
[13.2 Ferramentas]
|
v
[13.3 Causas]
|
v
[13.4 Escalonamento]
|
v
[13.6b Documentando a correção]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX049]
Objetivos de aprendizagem
Você vai (1) diagnosticar problemas de serviços de IA passo a passo; (2) usar rastros, versões e registros de mudanças; (3) separar causas de dados, de configuração, de modelo e de ataque; (4) escalar corretamente.
13.1 Passo a passo
- Defina o sintoma: o quê, quem, desde quando, com que frequência. 2. Verifique as mudanças recentes: versão do modelo, prompt, fontes de recuperação, ferramentas, configuração. 3. Obtenha os rastros dos casos que falham. 4. Formule hipóteses e teste-as uma de cada vez na homologação. 5. Corrija, verifique, registre. No caso da restauração de fábrica, as etapas levaram menos de um dia. O sintoma: clientes orientados a restaurar as configurações de fábrica por problemas pequenos, desde dois dias antes, em muitas contas. Mudanças: nenhuma mudança no modelo ou no prompt, mas um artigo novo. Rastros: toda resposta com falha recuperava esse artigo. Hipótese: o passo 1 do artigo causava o problema; testada na homologação removendo o artigo e repetindo as perguntas das reclamações, que passaram a receber orientações normais. Correção: remover, avisar o responsável, acrescentar um teste de regressão, registrar.
13.2 Ferramentas
Os IDs de requisição ligam a mensagem do cliente, os documentos recuperados, a resposta do modelo, as chamadas de ferramentas e as decisões de política. O histórico de versões mostra o que mudou. Os painéis mostram quando o sintoma começou. Comparar um caso que falha com um caso semelhante que funciona costuma mostrar a diferença rapidamente. A comparação de Ana no caso da restauração de fábrica foi entre uma conversa com falha e uma que funcionava, ambas perguntando sobre Wi-Fi lento. Mesma versão do modelo, mesma versão do prompt, mesmo tipo de cliente; a única diferença no rastro era a lista de documentos recuperados, em que a conversa com falha incluía "Advanced troubleshooting". O painel datou a primeira reclamação no horário de publicação do artigo. Sem IDs de requisição juntando resposta, recuperação e chamadas de ferramentas, essa comparação teria levado horas.
13.3 Causas
Dados (um artigo está errado, vencido ou é malicioso); configuração (um limite removido, uma permissão de ferramenta ampliada); modelo (o fornecedor atualizou o modelo); ataque (alguém está provocando o problema de propósito). Várias causas podem se combinar. Os incidentes da Kestrel cobrem as quatro. Dados: o artigo da restauração de fábrica e o artigo que mandava o HelpBot reiniciar roteadores cinco vezes. Configuração: a ferramenta de reinicialização que aceitava qualquer roteador e a falta de um limite por conta no gateway. Modelo: a deriva do LineWatch foi uma mudança nos dados, e não no modelo, mas uma atualização do fornecedor no modelo do HelpBot ficaria aqui. Ataque: as 900 denúncias em massa de "não é spam". O artigo editado das reinicializações combinou duas causas: conteúdo ruim, mais uma ferramenta sem teto diário que limitasse seu efeito.
13.4 Escalonamento
Escale imediatamente se vir sinais de exposição de dados de clientes, ações em contas erradas ou ataque deliberado. Siga o processo de incidentes: preserve as evidências, avise o líder de plantão e não tente correções arriscadas sozinho.
"""Lab A: spotting extraction-style abuse in a synthetic API log.
Flags clients whose query volume or input diversity is anomalous."""
import random, statistics
rng = random.Random(21)
log = []
for c in range(12):
for _ in range(rng.randint(40, 90)):
log.append((f"client{c:02d}", round(rng.gauss(0, 1), 1)))
for i in range(600): # synthetic scraper: many, grid-like inputs
log.append(("client99", round(-3 + 6*(i % 61)/60, 1)))
by = {}
for c, x in log: by.setdefault(c, []).append(x)
vol = {c: len(v) for c, v in by.items()}
med = statistics.median(vol.values()); mad = statistics.median(abs(v-med) for v in vol.values())
for c in sorted(by):
z = (vol[c]-med)/(1.4826*mad); uniq = len(set(by[c]))/len(by[c])
flag = "FLAG" if z > 3.5 else "ok"
print(f"{c} queries={vol[c]:3d} robust_z={z:6.2f} distinct_ratio={uniq:.2f} {flag}")
Saída esperada:
client00 queries= 50 robust_z= -0.34 distinct_ratio=0.56 ok
client01 queries= 64 robust_z= 0.45 distinct_ratio=0.52 ok
client02 queries= 81 robust_z= 1.41 distinct_ratio=0.44 ok
client03 queries= 46 robust_z= -0.56 distinct_ratio=0.52 ok
client04 queries= 52 robust_z= -0.22 distinct_ratio=0.48 ok
client05 queries= 40 robust_z= -0.90 distinct_ratio=0.57 ok
client06 queries= 42 robust_z= -0.79 distinct_ratio=0.57 ok
client07 queries= 87 robust_z= 1.74 distinct_ratio=0.48 ok
client08 queries= 56 robust_z= 0.00 distinct_ratio=0.52 ok
client09 queries= 50 robust_z= -0.34 distinct_ratio=0.62 ok
client10 queries= 68 robust_z= 0.67 distinct_ratio=0.50 ok
client11 queries= 89 robust_z= 1.85 distinct_ratio=0.42 ok
client99 queries=600 robust_z= 30.58 distinct_ratio=0.10 FLAG
O achado do canário de Ana é um exemplo de quando escalar na hora: uma frase exclusiva da equipe aparecendo numa resposta a cliente é exposição de dados voltada ao cliente, mesmo na homologação, porque o mesmo arquivamento errado poderia existir na produção. Ela exportou o rastro, avisou o líder de plantão e deixou a mudança na coleção para o responsável pelo conteúdo. O caso da restauração de fábrica, por outro lado, não precisou de escalonamento de emergência depois que os rastros mostraram um erro de conteúdo, mas ainda assim passou pelo chamado de incidente normal.
13.5 Exemplo resolvido (caso sintético da Kestrel)
Os clientes relatam que o HelpBot os manda "restaurar as configurações de fábrica" por problemas pequenos — o que apaga a configuração deles. Ana verifica as mudanças: nenhuma no modelo ou no prompt. Os rastros mostram que toda resposta com falha recuperou um artigo novo, "Advanced troubleshooting", publicado dois dias antes pela conta de um prestador de serviço. O artigo contém a orientação de restauração de fábrica no passo 1. Não há instruções escondidas — é um erro de conteúdo, não um ataque. Ela remove o artigo, avisa o responsável pelo conteúdo e acrescenta um teste de regressão. Uma verificação separada no painel, usando escores z robustos como os do laboratório, não mostra atividade incomum em nenhuma conta. A saída do laboratório mostra o que a verificação do painel procura. Doze clientes comuns enviaram entre 40 e 89 consultas, com escores z robustos de cerca de -0,9 a 1,9; o raspador sintético enviou 600 consultas, com escore z robusto de cerca de 31 e apenas 10% de entradas distintas, uma varredura em forma de grade. No caso da restauração de fábrica, nenhuma conta chegou perto disso, o que apoiou a conclusão de que o artigo foi um engano, e não um ataque plantado.
13.6 Erros e limites
Três erros são comuns: mudar várias coisas ao mesmo tempo; corrigir em produção sem testes na homologação; e não escalar uma possível exposição de dados. Mudar várias coisas ao mesmo tempo teria tornado ambígua a correção da restauração de fábrica: se Ana tivesse removido o artigo e também mudado o prompt, não poderia dizer qual mudança resolveu o problema. Corrigir em produção sem testes na homologação arrisca uma segunda interrupção em cima da primeira. Não escalar uma possível exposição de dados é o mais grave dos três, porque as pessoas que precisam notificar clientes ou reguladores não podem agir sobre o que não lhes é contado.
13.6b Documentando a correção
Depois do diagnóstico, o técnico registra no chamado o sintoma, a causa, a correção e como ela foi verificada. A próxima pessoa que encontrar o mesmo sintoma no HelpBot acha a resposta em minutos, em vez de repetir a investigação. O chamado de Ana para o caso da restauração de fábrica tinha quatro linhas: sintoma (orientação de restauração de fábrica para problemas pequenos, desde a data de publicação); causa (passo 1 do artigo "Advanced troubleshooting" do prestador de serviço); correção (artigo removido, responsável avisado, teste de regressão acrescentado); verificação (perguntas das reclamações repetidas na homologação e na produção, com orientações normais como resposta). O chamado também nomeava o teste de regressão que agora faz a pergunta da reclamação original.
Exercícios
- EX049 — Etapas. Aplique as cinco etapas a "o HelpBot responde no idioma errado". Rubrica: 3 = as cinco, de forma concreta; 2 = quatro; 1 = duas; 0 = nenhuma.
- EX050 — Comparar. Como comparar um caso que falha com um que funciona ajuda? Rubrica: 3 = isola diferenças de recuperação, versão, entrada; 2 = parcial; 1 = vago; 0 = nada.
- EX051 — Escalonamento. Liste três sintomas que exigem escalonamento imediato. Rubrica: 3 = três pertinentes; 2 = dois; 1 = um; 0 = nenhum.
- EX052 — Laboratório de monitoramento. O que um escore z robusto de 30 para uma conta sugeriria? Rubrica: 3 = valor muito discrepante, possível raspagem/extração, investigar; 2 = parcial; 1 = vago; 0 = errado.
Síntese
Diagnosticar serviços de IA é um trabalho sistemático: definir, verificar mudanças, rastrear, testar hipóteses, corrigir e registrar — escalando na hora quando os clientes puderem ser prejudicados.
Continue estudando — capítulo 13 de 18
← Capítulo 12 (rascunho) · Índice de capítulos do curso · Capítulo 14 (rascunho) →