Unidade 9 / 11

Monitoramento Contínuo, Observabilidade e Deriva

Ganhos:

  • Capacidade de definir métricas que monitoram sinais de uso, segurança, qualidade e desempenho
  • Capacidade de detectar desvios na qualidade de saída com linha de base e amostragem
  • Capacidade de definir alarme e ciclo de feedback para anomalias e ondas de jailbreak

Colocar um sistema de IA em produção é o começo, não o fim. Mesmo que o modelo permaneça o mesmo, o mundo muda: o comportamento dos utilizadores, os dados recebidos, as técnicas de ataque e o contexto empresarial estão em constante mudança. A resposta correta de ontem pode estar errada hoje. Portanto, o pilar final da segurança é o monitoramento e a observabilidade contínuos – a capacidade de ver de fora o que está acontecendo dentro do sistema. Nesta unidade, aprenderemos quais métricas monitorar, como capturar desvios na qualidade da saída e como alertar sobre anomalias.

Por que monitoramento contínuo?

No software clássico, “funciona” é uma questão binária: ou responde ou não. Na IA, embora o sistema pareça “funcionar”, ele pode deteriorar-se silenciosamente: as respostas tornam-se lentamente imprecisas, os custos aumentam, as tentativas de jailbreak aumentam. A única maneira de capturá-los é medir constantemente os sinais corretos.

Atenção: O mau funcionamento mais perigoso é o silencioso e não o barulhento. O sistema não gera erros, sua qualidade apenas diminui. Se você não configurar o monitoramento, a primeira pessoa a notar será seu cliente ou auditor, e não você.

Quatro famílias de sinais para observar

  • Uso e custo: volume de solicitações, consumo de tokens, custo por usuário. Salto repentino; Pode ser um sinal de abuso, uma integração maluca ou um interruptor com vazamento.
  • Sinais de segurança: tentativas de jailbreak/injeção, chamadas de veículos rejeitadas, erros de autorização. Um aumento pode indicar uma campanha de ataque ativa.
  • Qualidade e desvio: Diminuição na qualidade da saída ao longo do tempo (desvio). Por exemplo, taxa de aprovação na verificação, taxa de correção na aprovação humana, satisfação do usuário.
  • Desempenho: Latência, taxa de erro, tempo limite. Afeta diretamente a experiência e o custo do usuário.

O que é deriva e como capturá-la?

A deriva ocorre quando a qualidade das entradas ou saídas do modelo muda despercebida ao longo do tempo. Existem dois tipos: desvio de dados (a distribuição das solicitações recebidas muda – novo tópico, novo idioma) e desvio de qualidade (o resultado do mesmo trabalho piora gradualmente). Uma linha de base é necessária para capturar: registrar o intervalo normal de métricas quando o sistema está íntegro; Deixe o desvio se tornar um alarme.

Passo a passo: configurando o monitoramento

  1. Meça a linha de base. Registre a faixa normal de cada sinal quando o sistema estiver íntegro.
  2. Defina limite e alarme. Qual desvio avisará quem e como?
  3. Amostragem + inspeção humana. Faça com que uma análise humana revise regularmente uma amostra dos resultados (o desvio de qualidade geralmente é apenas visível).
  4. Instale um painel. Monitore quatro famílias de sinais em uma tela.
  5. Ciclo de feedback. Vincule as descobertas do monitoramento à melhoria imediata/controlada.

Quatro modelos copiáveis

Prompt de avaliação de amostragem de qualidade (rastreamento de desvio com LLM como juiz):

Abaixo estão 20 impressões aleatórias desta semana. Classifique cada um como “bom/aceitável/ruim” e escreva uma breve justificativa. Finalmente compararei a taxa ruim com a taxa da semana passada; Se houver um padrão (recorrência do mesmo tipo de erro) que se destaque nesta semana, marque-o.<outputs>{{ exemplos }}</outputs>

Solicitação de resumo de anomalia:

Examine as seguintes métricas diárias: número de solicitações, tokens, custo, chamada de ferramenta rejeitada, tentativas de jailbreak, latência média. Marque qualquer métrica que se desvie mais de 30% da linha de base como "ANOMALIT" e estime a possível causa (ataque, bug, abuso).<metrics>{{ daily_data }}</metrics>

Regra de definição de limite de alarme:

Defina alarmes para cada sinal: - Custo: se exceder 2x a média diária -> alerta de alta prioridade - Tentativas de jailbreak: se exceder 10 por hora -> notificar a equipe de segurança - Taxa de aprovação na verificação: se cair abaixo de 90% -> revisão de qualidade - Latência: se p95 exceder a meta em 2x -> revisão de desempenho

Solicitação de pesquisa de deriva:

A taxa de aprovação na verificação caiu de 94% para 78% nas últimas 2 semanas. Ajude-me a responder a estas perguntas: (1) Um novo tópico/idioma/formato apareceu nas solicitações recebidas? (2) Os erros estão concentrados numa categoria específica? (3) O momento coincide com uma mudança de prompt/modelo/ferramenta? Nomeie os dados a serem verificados para cada um.

Alerta Fraco/Prompt Forte

abordagem pobre

Abordagem forte

“Se houver um erro, veremos”

Linha de base + limite + alarme proativo

Apenas verificando se o sistema está de pé.

Monitorando quatro famílias de sinais (uso, segurança, qualidade, desempenho)

Não amostrar a qualidade da saída

Amostragem humana regular + LLM como juiz

Não coletar e analisar métricas

Painel + ciclo de feedback

Três Mini Estojos

Caso 1 — O alarme de custo detectou o vazamento da chave. O custo diário do token de uma empresa triplicou durante a noite. O alarme de limite alertou a equipe de segurança; a investigação mostrou que uma chave de teste vazou e foi usada por um bot. A chave foi revogada em 25 minutos; Se não tivesse havido alarme, a conta teria sido paga no final do mês.

Caso 2 — Desvio silencioso de qualidade. A taxa de aprovação na verificação de um assistente de suporte caiu silenciosamente de 95% para 80% em três semanas. A amostragem semanal capturou isso; O motivo foi que os clientes começaram a perguntar sobre uma nova linha de produtos e a base de conhecimento do modelo estava incompleta. A taxa recuperada quando a base de conhecimento foi atualizada.

Caso 3 — A onda de jailbreak foi precoce. As tentativas de injeção feitas em um assistente aumentaram de 2 para 40 por hora em um dia. Alarme de segurança acionado; Foi visto que uma “receita” para quebrar o sistema foi compartilhada em um fórum. A equipe atualizou o prompt de defesa e contas suspeitas com taxa limitada; A onda cessou antes de se transformar em um verdadeiro vazamento.

Dica: não se contente apenas com métricas de máquina. O desvio de qualidade geralmente é detectado apenas pela leitura humana dos resultados da amostra. Uma pequena rotina de revisão de 15 a 20 impressões aleatórias por semana detectará antecipadamente as falhas silenciosas mais caras.

Erros comuns

  • Não colocar em produção e montar monitoramento (“está funcionando, ok”).
  • Não ser capaz de identificar a anomalia sem medir a linha de base.
  • Perder o desvio de qualidade olhando apenas para "isso se mantém de pé".
  • Não amostrar a qualidade da saída através de olhos humanos.
  • Não dar alarme e descobrir o problema com o cliente/supervisor.
  • Não conectar as descobertas do monitoramento à melhoria (sem ciclo de feedback).

Em resumo

  • Os sistemas de IA podem deteriorar-se silenciosamente; O mau funcionamento mais perigoso é aquele que não gera erros, mas apenas reduz a qualidade.
  • Acompanhe quatro famílias de sinais: uso/custo, segurança, qualidade/desvio e desempenho.
  • O desvio (o desvio da qualidade de entrada ou saída ao longo do tempo) é capturado apenas em comparação com uma linha de base.
  • Amostragem humana regular, além de métricas de máquina, captura desvios de qualidade.
  • Conecte o monitoramento ao alarme e ao circuito de feedback; Medir e não olhar não é monitorar.

Tarefa de aplicativo

Escolha pelo menos uma métrica de cada uma das quatro famílias de sinais para o seu próprio sistema de IA e anote suas linhas de base atuais (ou estimadas). Defina um limite de alarme para cada métrica. Em seguida, pegue 15 dos resultados do último semestre e avalie-os com a solicitação de amostragem acima; Observe a taxa “ruim”. Deixe que esta seja sua primeira linha de base para comparar a deriva no futuro.

lista de verificação

  • [] Defini métricas de quatro famílias de sinais (uso, segurança, qualidade, desempenho).
  • [] Defino uma linha de base e um limite de alarme para cada métrica.
  • [] Eu regularmente testo a qualidade da saída através de olhos humanos.
  • [ ] Eu monitoro os sinais em uma única tela com um painel de exibição.
  • [] O alarme vai para a equipe de segurança por anomalias e ondas de jailbreak.
  • [ ] Atribuo os resultados do monitoramento à melhoria da agilidade/controle.