Toda IA em produção tem um segredo desconfortável: ela depende de um provedor de LLM que não está sob o seu controle. E provedores caem. Ficam lentos numa terça de manhã. Retornam erro 529 de sobrecarga no pior momento. Se o seu agente depende de um único provedor, então a disponibilidade do seu produto é, na verdade, a disponibilidade do elo mais fraco da cadeia — e você terceirizou seu uptime para uma empresa que não te deve nada.
Em produção séria, isso é inaceitável. A solução é fallback de LLM, e é uma das primeiras coisas que eu coloco de pé em qualquer agente.
O problema, concretamente
Imagine um agente atendendo no WhatsApp ou numa ligação ao vivo. O cliente manda a mensagem, o agente chama o LLM primário e... timeout. Ou erro 500. Ou uma latência de 15 segundos. Sem fallback, o que o cliente vê é: silêncio. O atendimento morreu no meio. Numa ligação de voz, é ainda pior — não existe "tenta de novo daqui a pouco", a conversa é agora.
A causa não é sempre uma queda total. Muitas vezes é degradação: o provedor está de pé, mas lento ou instável. Do ponto de vista do cliente, lento demais é o mesmo que fora do ar.
A arquitetura: fallback em cascata
O princípio é simples: nenhum ponto único de falha na resposta. Na prática, eu monto uma cascata de modelos:
Requisição
→ LLM primário (rápido, bom, custo-benefício)
falhou/timeout? ↓
→ LLM secundário (outro provedor, capacidade equivalente)
falhou/timeout? ↓
→ LLM terciário (último recurso, só pra não morrer)
Regras que fazem funcionar:
Provedores diferentes em cada nível. Se o primário e o secundário são do mesmo provedor, uma queda derruba os dois. A resiliência vem da diversidade — modelos de empresas diferentes, infraestruturas diferentes.
Timeout agressivo antes de desistir. Não espere 30 segundos o primário responder. Se em X segundos não veio, considere falha e caia pro próximo. Latência alta é falha.
Retry com bom senso. Um retry rápido no mesmo provedor pode resolver um soluço momentâneo. Mas não fique tentando o elo quebrado — caia pro próximo cedo.
Transparência total pro cliente. Ele nunca deve saber que o primário caiu. A troca acontece em milissegundos, nos bastidores. O sucesso é o cliente não perceber nada.
Bônus: fallback também é otimização de custo
Depois que você tem a infraestrutura de rotear entre modelos, ela serve pra mais do que resiliência. A mesma camada permite escolher o modelo certo por tipo de mensagem: o modelo barato para intenções simples ("qual meu boleto?"), o modelo caro só quando a conversa exige raciocínio. A maioria das mensagens é simples — e essa escolha reduz o custo por conversa drasticamente.
Ou seja: a arquitetura que te salva quando um provedor cai é a mesma que economiza dinheiro todo dia. Dois problemas, uma solução.
O que observar (senão você não sabe que está quebrado)
Fallback silencioso é ótimo pro cliente e perigoso pra você: se o primário está caindo o tempo todo e o secundário segurando, tudo parece bem — até o secundário cair também. Por isso, meça: taxa de fallback por provedor, latência de cada nível, quantas requisições chegaram ao último recurso. Se o seu primário começou a falhar 30% das vezes, você quer saber antes que ele falhe 100%.
O princípio
Resiliência não é um recurso que você adiciona depois. É uma decisão de arquitetura que você toma no começo: o meu produto não pode ter a disponibilidade de terceiros que eu não controlo. Fallback de LLM é como você recupera esse controle — transformando a queda inevitável de um provedor em um não-evento que ninguém percebe.
Um agente sem fallback funciona lindamente na demo. Em produção, ele é uma bomba esperando o dia em que o provedor tem um mau dia. E o provedor sempre tem.
Construo IA resiliente para produção — com fallback, observabilidade e a engenharia que aguenta o mundo real. Se você tem uma IA que não pode cair, vamos conversar.