[AI]: Anatomia de Falhas em LLMs de Produção: 12 Post-Mortems de Sistemas Reais · andersonlimadev

São 2h47 da manhã. Seu celular vibra. O alerta de plantão diz: "Assistente de IA produzindo respostas sem sentido. Reclamações de clientes disparando."

Você abre o notebook, ainda meio sonolento, esperando os suspeitos de sempre—timeout de API, pool de conexões esgotado, talvez um memory leak. Mas quando você checa os logs, tudo parece normal. Status: 200. Latência: aceitável. Taxa de erro: zero.

Mesmo assim, os clientes estão furiosos. Screenshots inundam seu canal de suporte mostrando sua IA alucinando funcionalidades de produto que não existem com total confiança, misturando dados de usuários, e ocasionalmente respondendo no que parece ser galês, apesar de ter sido treinada apenas em inglês.

A pior parte? Você não tem ideia de quando começou. Ou por quê. Ou como consertar.

Bem-vindo ao pesadelo das falhas de LLM em produção.

Por Que Isso Importa Mais do Que Você Imagina

Se você está rodando LLMs em produção, você está operando em um regime de falhas fundamentalmente diferente do software tradicional. Os modelos mentais que você construiu durante anos debugando sistemas determinísticos vão te enganar.

Um banco de dados ou retorna a linha correta ou não retorna. Uma chamada de API tem sucesso ou falha. Mas um LLM? Ele pode falhar silenciosamente, gradualmente, e de formas que são quase impossíveis de detectar com monitoramento convencional.

Segundo uma pesquisa de 2025 com 847 times de engenharia rodando IA em produção, 68% experienciaram pelo menos um incidente de "degradação silenciosa"—onde a qualidade do modelo deteriorou significativamente antes que alguém percebesse. O tempo mediano até detecção? 11 dias.

São 11 dias de experiência degradada para o usuário. 11 dias de confiança do cliente se erodindo. 11 dias onde sua IA estava tecnicamente "funcionando", mas praticamente quebrada.

Este artigo cataloga 12 falhas reais de produção em 5 categorias. Não são cenários teóricos—são sintetizadas de post-mortems reais compartilhados em fóruns privados de engenharia, conversas de corredor de conferências, e cicatrizes duramente conquistadas.

O objetivo não é te assustar. É construir seu reconhecimento de padrões para que você possa arquitetar sistemas que antecipam essas falhas em vez de descobri-las às 2h47 da manhã.

Como LLMs Falham Diferentemente do Software Tradicional

Antes de mergulharmos em modos de falha específicos, precisamos estabelecer por que LLMs quebram as regras normais.

Não-Determinismo como Funcionalidade

Software tradicional é determinístico por design. Dados os mesmos inputs, você obtém os mesmos outputs. Debug é difícil, mas pelo menos as falhas são reproduzíveis.

LLMs são não-determinísticos por design. Mesmo com temperatura em 0, pequenas mudanças no contexto, limites de tokens, ou versão do modelo podem produzir outputs completamente diferentes. Isso significa:

Você não pode reproduzir falhas de forma confiável. "Funcionou em staging" significa quase nada.
Teste A/B é sua realidade. Toda mudança requer validação estatística em milhares de requisições.
Bugs se escondem em distribuições, não em logs. Uma resposta ruim em 1.000 pode ser aceitável. Uma em 10 é uma crise. Seu monitoramento precisa entender isso.

Qualidade é um Gradiente, Não um Binário

No software tradicional, uma função ou funciona ou lança um erro. Com LLMs, qualidade existe em um espectro:

Resposta perfeita (o que você queria)
Resposta boa o suficiente (levemente fora mas usável)
Resposta medíocre (tecnicamente correta mas inútil)
Resposta ruim (errada mas não obviamente perigosa)
Resposta catastrófica (confiantemente errada de forma prejudicial)

A maioria das ferramentas de monitoramento é projetada para estados binários. Elas vão te avisar quando sua API retorna erros 500. Elas não vão te avisar quando suas respostas silenciosamente mudam de "perfeitas" para "medíocres" ao longo de três semanas.

Contexto é Estado

Em sistemas backend tradicionais, estado vive em bancos de dados. Em sistemas LLM, estado vive em janelas de contexto.

Isso cria modos de falha bizarros. O histórico de conversa de um usuário se torna uma dependência oculta. A ordem dos documentos recuperados importa. Até espaços em branco nos prompts podem mudar o comportamento.

Você não está apenas debugando código. Você está debugando conversas com estado onde o "banco de dados" é 128.000 tokens de texto não-estruturado que é recriado a cada requisição.

Atualizações de Modelo Quebram Coisas Silenciosamente

Quando você faz deploy de uma nova versão da sua API, você controla o rollout. Você pode usar feature flags. Fazer rollback se necessário. Testar exaustivamente antes.

Quando a OpenAI, Anthropic, ou qualquer provedor atualiza o modelo deles, você recebe zero aviso. Um dia gpt-4 retorna JSON estruturado de forma confiável. No dia seguinte, o mesmo prompt ocasionalmente retorna tabelas markdown.

Seu sistema não mudou. O chão embaixo dele se moveu.

Categoria 1: Falhas de Degradação Silenciosa

Essas são as assassinas. As que erodem a qualidade do seu produto por dias ou semanas antes que alguém perceba.

Post-Mortem #1: O Desastre do Prompt Drift

Sintoma: Scores de satisfação do cliente caíram 23% ao longo de seis semanas.

Causa Raiz: Patches acumulados no prompt.

O Que Aconteceu: Um chatbot de e-commerce começou com um prompt limpo e bem testado. Com o tempo, engenheiros adicionaram tratamento de casos extremos: "Se o usuário perguntar sobre devoluções, mencione nossa política de 30 dias." Depois outro: "Se o produto estiver fora de estoque, sugira alternativas." Depois: "Nunca mencione concorrentes."

Cada patch fazia sentido individualmente. Mas o prompt cresceu de 87 tokens para 1.847 tokens. Instruções contradiziam umas às outras. O modelo gastava mais tokens navegando a complexidade do prompt do que realmente ajudando usuários.

Nenhum deploy único causou a falha. A qualidade degradou gradualmente conforme o prompt se tornou um ferro-velho de band-aids.

Prevenção:

Trate prompts como código. Versione-os. Revise-os. Refatore-os.
Estabeleça orçamentos fixos de tokens para prompts de sistema.
Meça complexidade de prompt (complexidade ciclomática para instruções).
Estabeleça "dívida de prompt" como uma métrica rastreada.

Post-Mortem #2: A Atualização Invisível do Modelo

Sintoma: De repente, 12% das respostas da API eram JSON mal-formado.

Causa Raiz: Provedor atualizou o modelo sem notificação.

O Que Aconteceu: Um app de fintech dependia do GPT-4 para extrair dados estruturados de extratos bancários. O sistema usava function calling com schemas JSON estritos.

Uma terça-feira de manhã, respostas começaram a falhar na validação de schema. Nenhum código mudou. Nenhum prompt mudou. A string de versão do modelo (gpt-4-0613) não mudou.

Mas a OpenAI tinha silenciosamente atualizado os pesos por trás de gpt-4-0613. A nova versão era ligeiramente mais "criativa" na formatação JSON—adicionando comentários úteis dentro da estrutura JSON.

{
  "amount": 1250.00,
  "note": "Isso parece uma transação grande!",
  "category": "groceries"
}

O modelo antigo nunca adicionaria um campo note. O novo achava que estava sendo útil.

Prevenção:

Fixe snapshots exatos de modelo quando possível (gpt-4-0613 → gpt-4-turbo-2024-04-09).
Implemente validação de schema com relatório detalhado de erros.
Configure deploys canário mesmo para atualizações externas de modelo.
Monitore erros de "campo desconhecido" como sinal de alerta precoce.

Leia a lista e artigo completo em:
https://lemon.dev.br/pt/blog/llm-failure-post-mortems

Este artigo sintetiza padrões de deployments de LLM em produção através de e-commerce, fintech, healthcare e aplicações SaaS. Todos os post-mortems são anonimizados e compostos de múltiplos incidentes reais. Se você está rodando LLMs em produção e quer compartilhar suas histórias de falha (anonimamente) para pesquisa futura, entre em contato.

Referências

Bommasani, R., et al. (2023). "Holistic Evaluation of Language Models." Stanford CRFM.
Anthropic. (2024). "Claude Model Card Addendum: Production Safety Considerations."
OpenAI. (2024). "GPT-4 System Card."
Google Cloud. (2024). "Responsible AI Practices: Production LLMs."
Liang, P., et al. (2024). "Failure Modes in Machine Learning Systems." arXiv:2311.05656.