Ganhos:
- Capacidade de reconhecer causas silenciosas de degradação do modelo (desvio de dados, desvio de conceito, erro upstream) e estabelecer monitoramento de três camadas (operacional, entrada, saída)
- Capacidade de avaliar sistemas LLM em múltiplas camadas com verificações de regras, avaliação humana e de árbitro LLM, e calibrar com âncora humana de árbitro LLM
- Capacidade de projetar um conjunto de avaliações contendo casos extremos e de segurança e transformar cada erro detectado em um caso de teste permanente
Depois que um modelo entra em produção, seu trabalho não termina; A verdadeira responsabilidade apenas começa. Porque o modelo pode quebrar silenciosamente quando ninguém está olhando. Nesta unidade abordamos duas disciplinas complementares: avaliação (medir sistematicamente a qualidade do modelo) e monitoramento (monitoramento constante do modelo em produção). Especialmente em sistemas LLM, a avaliação é mais difícil e requer mais cuidado do que o ML clássico.
Por que o modelo de produção está desmoronando silenciosamente
Um bug trava, o log é impresso, o alarme dispara. Um modelo de ML, por outro lado, pode estar errado sem causar erros. Três causas principais de degradação:
- Desvio de dados: A distribuição dos dados de entrada muda ao longo do tempo (novos produtos, mudança no comportamento do usuário, sazonalidade). O modelo permanece o mesmo, mas o mundo muda.
- Desvio de conceito: a relação entrada-saída muda. As táticas de fraude e os padrões de spam evoluem; O que estava certo ontem estará errado hoje.
- Corrupção upstream: uma fonte de dados muda de formato, uma área fica livre; O modelo baba silenciosamente com informações corrompidas.
O rastreamento torna essas distorções silenciosas audíveis.
O que assistir: três camadas
Um bom monitoramento abrange três níveis:
- Métricas operacionais: latência, taxa de erros, volume de solicitações, uso de recursos. “O sistema está de pé?”
- Métricas de dados/entradas: A distribuição de entradas é semelhante à do treinamento? A taxa de valor faltante aumentou? Chegaram novas categorias? “O modelo está vendo dados familiares?”
- Métricas de modelo/saída: log de distribuição de previsão? As pontuações de confiança caíram? E se possível, qual é a precisão em comparação com a verdade básica? “O modelo ainda é preciso?”
A terceira camada é a mais valiosa, mas a mais difícil; porque o resultado real geralmente vem com atraso (depois de meses fica claro se um empréstimo será reembolsado ou não).
Dica: Se o resultado real estiver atrasado, monitore primeiro a entrada e a distribuição da previsão. A mudança na distribuição de entrada é um sinal precoce de degradação da precisão e pode disparar um alarme sem esperar pelo resultado real.
Avaliando sistemas LLM: o desafio especial
No ML clássico, a “resposta correta” é clara (classe 0 ou 1). O resultado do LLM, por outro lado, é aberto: pode haver muitas respostas corretas para a mesma pergunta, “correção” não cabe em um único número. Abordagens de avaliação LLM:
- Métricas referenciadas: Comparando o resultado com a resposta ideal. Limitado; porque pode considerar a resposta correta expressa de forma diferente como "errada".
- Verificações baseadas em regras: a saída é JSON válida? Existem palavras proibidas? Contém os campos desejados? Barato, confiável, compacto.
- Juiz LLM (LLM-como juiz): Não faça um modelo perguntar "esta resposta é boa de acordo com este critério?" Escala, mas o próprio árbitro deve ser verificado.
- Revisão humana: Padrão ouro, mas caro e lento. É usado na amostra.
Na prática, estes são usados em conjunto: verificações de regras baratas em cada saída, juiz LLM em uma amostra grande, avaliação humana em uma amostra pequena, mas rigorosa.
Abordagem fraca/abordagem forte
Fraco: "LLM-Perguntei ao árbitro, 92% das nossas respostas foram boas. O sistema é ótimo."
Güçlü: "Primeiro rotulamos 100 impressões humanas. Executamos o juiz LLM nas mesmas 100 impressões e medimos a concordância do juiz humano - 85% de concordância, aceitável. Documentamos onde o juiz errou sistematicamente (uma tendência de encontrar respostas longas injustamente boas) e corrigimos sua sugestão. Só então confiamos nas pontuações do juiz. "
A diferença: a abordagem forte verifica o árbitro com uma âncora humana, não cegamente. Um árbitro LLM não verificado dá uma confiança bonita, mas falsa.
Atenção: o árbitro LLM também é um modelo; alucinógeno, tendencioso (favorece respostas longas/confiantes), pode ser inconsistente. Calibre as pontuações dos árbitros com tags humanas antes de tomar decisões de produção.
Conjunto de avaliação: cuidadosamente projetado
Um bom conjunto de avaliações representa a variedade de uso real e casos difíceis. Uma avaliação repleta de exemplos fáceis deixará você com uma falsa confiança. Certifique-se de colocá-lo no cluster de avaliação:
- Casos extremos: entrada vazia, entrada muito longa, formato incomum.
- Casos difíceis conhecidos: Exemplos em que o modelo cometeu erros no passado (como um teste de regressão).
- Incidentes de segurança: tentativas de injeção imediata, solicitações maliciosas, armadilhas de violação de privacidade.
O cluster de avaliação cresce com o tempo: cada novo bug detectado na produção se torna um caso de teste para a próxima avaliação.
Alarme e intervenção
O monitoramento permanece incompleto sem um alarme. Deve haver um limite e um plano de resposta para cada métrica importante: "Notificar o engenheiro se o desvio de entrada exceder X", "Reversão automática se a taxa de erro exceder Y". Mantenha os alarmes significativos – muitos alarmes falsos dessensibilizam a equipe e fazem com que eles percam o alarme real.
três mini cases
Caso 1 – Alerta antecipado. A verdadeira precisão de um modelo de previsão de demanda só se tornou aparente no final da semana. A equipe estava monitorando a distribuição de insumos e viu o surgimento repentino de uma nova categoria de produto em uma terça-feira – algo que o modelo nunca tinha visto. Eles atualizaram o modelo sem esperar pela queda na precisão. O monitoramento de entrada economizou dias.
Caso 2 – Árbitro não verificado. Uma equipe relatou “nossa qualidade é excelente” com base no revisor do LLM. Quando as reclamações dos clientes aumentaram, o monitoramento humano foi introduzido: o árbitro considerou as respostas confiantes, mas incorretas, como "boas". Depois que o árbitro foi calibrado com etiquetas humanas, a verdadeira qualidade foi revelada e muito inferior. Lição: não confie no árbitro sem verificá-lo.
Caso 3 – Teste de regressão. Uma mudança imediata resolveu um problema e quebrou outro silenciosamente. Mas a equipe evitou os bugs no intervalo de avaliação; Quando a nova alteração foi testada neste cluster, o caso quebrado foi imediatamente detectado e a alteração foi corrigida. Lição: todo bug corrigido deve se tornar um caso de teste permanente.
Modelos copiáveis
Produza um plano de acompanhamento para este modelo de produção. Abrange três camadas:1) Operacional (latência, taxa de erro, volume)2) Entrada/dados (mudança de distribuição, valor faltante, nova categoria)3) Modelo/saída (distribuição de previsão, confiança, precisão, se possível)Modelo: [descrição]. Quanto tempo leva para o resultado real chegar: [duração]Adicione limite e recomendação de intervenção para cada métrica.
Propor uma estratégia de avaliação (avaliação) para este sistema LLM.Tarefa: [descrição]Determinar camadas:- Quais verificações baseadas em regras devem ser executadas em cada saída?- Quais critérios o árbitro LLM deve avaliar e como eles devem ser validados (âncora humana)?- Em qual amostra a avaliação humana deve ser realizada?Liste os casos extremos e de segurança que devo colocar no conjunto de avaliação.
Verifique este prompt do árbitro LLM: - Os critérios de avaliação são claros ou subjetivos? - É propenso a preconceitos de comprimento/confiança?
Escreva um runbook de resposta para este alarme de monitoramento.Alarme: [por exemplo. limite de desvio de entrada excedido]Deve conter: etapas iniciais de controle, possíveis causas, critérios de reversão, quem informar.
Tabela de causas de deterioração
distorção
sintoma
Maneira de detecção precoce
desvio de dados
Mudanças na distribuição de insumos
Monitoramento de distribuição de insumos
mudança de conceito
A justiça cai silenciosamente
Previsão + comparação real
erro inicial
Os campos ficam vagos/mudanças de formato
Validação de esquema + taxa ausente
Inconsistência de modelo
Mudanças na distribuição da produção
Monitoramento de distribuição de saída
Erros comuns
- Não estabelecer monitoramento. O modelo quebra silenciosamente, ninguém vê.
- Rastreie apenas métricas operacionais. O sistema está funcionando, mas as previsões podem estar erradas.
- Usar LLM sem verificar o árbitro. Dá falsa confiança.
- Avaliar com exemplos fáceis. Não indica dificuldade real.
- Não incluindo erros passados na avaliação. O mesmo erro retorna novamente.
- Alarmes altos. A equipe fica insensível, perdendo o verdadeiro alarme.
Em resumo
O modelo pode ser impreciso sem causar erros na produção; portanto, a avaliação e o monitoramento são tão importantes quanto o desenvolvimento. Estabelecer monitoramento em três níveis (operacional, entrada, saída); Use o desvio de entrada como um aviso antecipado se o resultado real estiver atrasado. Nos sistemas LLM, a avaliação é aberta; Use verificações de regras, árbitro LLM e avaliação humana juntos - mas certifique-se de validar o árbitro LLM com uma âncora humana. Enriqueça seu cluster Eval com casos extremos e de segurança e transforme cada erro detectado em um caso de teste permanente.
Tarefa de aplicativo
Escreva um plano de monitoramento de três camadas para um modelo de produção (ou quase produção) e defina limite + alarme para pelo menos uma métrica de distribuição de insumos. Se você tiver um sistema LLM: marque 30 resultados com humanos, execute um árbitro LLM nas mesmas saídas e meça a concordância homem-árbitro; Observe o preconceito sistemático do árbitro. Adicione pelo menos três arestas e dois casos de segurança ao seu cluster de avaliação.
lista de verificação
- [ ] O monitoramento abrange todas as três camadas (operacional, entrada, saída).
- [] Eu uso o desvio de entrada como um aviso antecipado se o resultado real estiver atrasado.
- [] Calibrei o árbitro LLM com rótulos humanos.
- [] O cluster Eval contém casos de borda e de segurança.
- [] Transformei cada bug que detectei em um caso de teste permanente.
- [] Cada métrica importante tem um limite e um plano de resposta.