Às 3 da Manhã, Meu Agente Enlouqueceu

Eu construí um sistema RAG para um projeto. Durante a demo, tudo funcionava perfeitamente: respostas rápidas, precisas, bem formatadas. O cliente aprovou. Fomos para produção.

Duas semanas depois, recebi uma mensagem à noite: “Seu sistema está dando respostas erradas.” Abri os logs. Tudo parecia normal. A requisição entrou. A resposta saiu. HTTP 200. Nenhum erro. Nenhum crash. Nenhum timeout.

Mas a resposta estava categoricamente errada — e entregue com a confiança de um professor de universidade explicando seu tema favorito.

Levei dois dias para encontrar o problema. O cliente tinha feito upload de um PDF com formatação estranha — tabelas dentro de imagens, texto em duas colunas que o parser leu como uma só, e uma seção crucial que ficou perdida entre chunks de forma que nenhuma query de similaridade conseguia recuperar. O agente, não encontrando a informação correta no RAG, fez o que LLMs fazem: improvisou. E improvisou com confiança total.

Essa experiência me ensinou algo que nenhum tutorial cobriu: a distância entre demo e produção em IA não é técnica. É epistemológica. O agente não sabe o que não sabe. E isso é fundamentalmente diferente de qualquer bug de software que eu já enfrentei.

O “Paraíso” do RAG (E o Inferno que Vem Depois)

A maioria dos desenvolvedores passa semanas construindo pipelines de RAG que funcionam lindamente em ambiente controlado:

Você usa PDFs e planilhas “limpos”. A IA recupera informação com precisão. As respostas são rápidas e corretas. A demo encanta o cliente.

O problema começa quando o usuário real entra na jogada. Ele faz upload de arquivos bagunçados, com formatações estranhas, dados incompletos, PDFs escaneados com OCR duvidoso. E o pipeline silenciosamente começa a falhar:

Embeddings perdidos. Partes do texto não são transformadas em vetores corretamente — especialmente tabelas, listas e conteúdo dentro de imagens.

Chunking estranho. O sistema corta a informação no lugar errado. Uma frase crítica fica dividida entre dois chunks, e nenhum dos dois faz sentido sozinho.

Erros de indexação. O dado está lá, mas o índice não o encontra. O threshold de similaridade pode estar apertado demais, ou o embedding não captura a semântica corretamente para aquele domínio específico.

Como alguém resumiu: “Dumb RAG” — jogar tudo no contexto — é a armadilha número um. Karpathy compara a context window à RAM. Você não joga seu disco rígido inteiro na RAM.

Por Que IA Falha Diferente de Software Tradicional

A distinção que mais me ajudou a entender o problema é esta:

Em software tradicional, um erro produz um rastro claro. “Erro na linha 42: Conexão Recusada.” Você sabe o que quebrou, onde quebrou, e geralmente por quê.

Em um agente de IA, uma decisão errada baseada em contexto incompleto parece normal nos logs. O log mostra o que entrou e o que saiu, mas não o porquê da decisão. Você vê um HTTP 200 que contém dados completamente alucinados. Seu stack de observabilidade tradicional — métricas, logs, traces — foi projetado para sistemas determinísticos. Mesma entrada, mesma saída. Agentes de IA quebraram esse contrato.

E o problema se agrava com a composição. Um workflow de 1 passo com 85% de precisão por passo tem 85% de sucesso. Aceitável. Um workflow de 5 passos: 85%⁵ = 44% de sucesso. Metade dos seus usuários falha. Um workflow de 10 passos: 85%¹⁰ = 20% de sucesso. Quatro em cada cinco usuários falham.

O benchmark APEX-Agents 2026 encontrou que mesmo os modelos com melhor performance completaram apenas 24% das tarefas do mundo real na primeira tentativa. E a Gartner prevê que 40% ou mais dos projetos agênticos serão abandonados até 2027 — não por qualidade de modelo, mas por custos escalantes, valor de negócio incerto e controles de risco inadequados.

Soluções Que Funcionam (O Playbook Que Eu Queria Ter Lido Antes)

Depois de enfrentar esse problema na prática e pesquisar extensivamente o que equipes de produção estão fazendo em 2026, cheguei a um playbook de seis camadas que reduziu drasticamente as falhas nos meus sistemas:

1. Observabilidade Específica para Agentes

Seu Datadog ou Grafana não é suficiente. Você precisa de ferramentas projetadas para IA:

Langfuse para trace-level debugging — captura prompts, respostas, custos e traces de execução. Open source, self-hosted ou cloud. Guardrails AI para validação de inputs e outputs contra políticas configuráveis — detecção de alucinações, coerência, aderência ao contexto. AgentOps para monitoramento de workflows multi-step e multi-agente.

A chave é rastrear não apenas “o que entrou e saiu”, mas quais chunks foram recuperados, qual foi o score de similaridade, e qual decisão o modelo tomou em cada passo. Sem isso, debugging é cego.

2. RAG “Defensivo” (Não “Dumb RAG”)

Pare de jogar tudo no contexto. Implemente:

Chunking semântico — por seções e headings, não por tamanho fixo. Use overlap entre chunks para não perder informação nas bordas.

Retrieval híbrido — combine busca vetorial densa (embeddings) com BM25 (keyword search). Modelos fazem keyword matching melhor do que você imagina, e a combinação cobre lacunas de cada abordagem.

Re-ranking — depois da busca inicial, use um modelo de re-ranking (como Cohere Rerank ou cross-encoder) para reordenar os resultados por relevância real.

Threshold de confiança — defina um score mínimo de similaridade. Se nenhum chunk ultrapassa o threshold, o agente deve dizer “não encontrei informação suficiente” em vez de improvisar. Essa é a mudança mais importante e mais simples.

3. Citações Obrigatórias

Force o agente a citar fontes para cada afirmação. Se ele não consegue apontar de qual documento/chunk veio a informação, ele não deveria estar afirmando. Isso muda o comportamento do modelo fundamentalmente: em vez de “gerar resposta plausível”, ele precisa “encontrar evidência e reportar”.

4. Verificação em Cada Fronteira de Agente

Em sistemas multi-agente, cada passagem de mensagem entre agentes é um ponto de propagação de erro. Implemente verificação: o agente receptor não deveria aceitar uma mensagem sem citações. Um dado inventado no passo 1 que não é checado no passo 2 pode se transformar em uma ação catastrófica no passo 5.

Um desenvolvedor relatou que seu sistema multi-agente de reconciliação de medicamentos teve um caso onde o Agente A alucionou um medicamento, o Agente B verificou esse medicamento alucinado contra outro real e encontrou uma “interação perigosa”, e o Agente C escreveu um alerta urgente para o médico. Tudo errado. Tudo confiante.

5. “Abstenção Calibrada” — Ensine o Agente a Não Saber

O problema mais profundo: LLMs são treinados para responder, não para se abster. Mas você pode configurar o harness para forçar abstenção:

Regra de evidência mínima — se menos de N chunks relevantes são recuperados acima do threshold, o agente responde “Não tenho informação suficiente para responder com segurança.”

Múltiplas amostragens — gere 3-5 respostas independentes (variando temperatura ou prompt) e compare. Discordância significativa é sinal forte de incerteza.

Escalação automática — quando confiança cai abaixo de um limiar (85% é o padrão que vejo funcionar), escale para revisão humana.

6. Testes com Dados “Feios”

Pare de testar com PDFs limpos. Construa um corpus de testes com:

  • PDFs escaneados com OCR ruim
  • Planilhas com células mescladas e formatação inconsistente
  • Documentos com informação contraditória
  • Queries ambíguas que não têm resposta clara no corpus

Se seu sistema não falha graciosamente com esses inputs, ele não está pronto para produção.

O Que Eu Gostaria de Ter Sabido

Se eu pudesse voltar no tempo e me dar um conselho antes daquela noite de produção falha, seria este: otimize para a falha, não para a demo.

Cada hora que você gasta fazendo a demo brilhar é uma hora que não gastou preparando para quando o sistema receber inputs que você nunca imaginou. E em produção, 100% dos inputs são inputs que você nunca imaginou.

A IA é uma consultora brilhante que sofre de excesso de confiança. Seu papel não é ser o fã-clube. É ser o auditor que garante que ela só fale quando realmente tiver evidências nas mãos. E para isso, você precisa de infraestrutura, não de fé.

Conclusão: Construa Com Ceticismo

O segredo para sobreviver como desenvolvedor de IA em 2026 é simples de dizer e difícil de fazer: trate seu agente como um sistema distribuído não-determinístico. Porque é isso que ele é.

Isso significa: observabilidade profunda, tolerância a falhas, abstenção calibrada, citações obrigatórias, verificação em cada fronteira, e testes com dados do mundo real. Não é glamoroso. Não fica bonito na demo. Mas é o que separa sistemas que funcionam de sistemas que funcionam na demo.

E se depois de tudo isso seu agente ainda falhar? Pelo menos agora você vai saber por quê — e isso, na engenharia de IA, é metade da batalha.

Compartilhe se isso salvou algum projeto:

Demo é marketing. Produção é engenharia. E a distância entre os dois é onde carreiras de IA são construídas ou destruídas.

Leia Também