Adicionar Caminho de Fallback

Problema

Às 14h, o provedor do modelo principal começa a devolver 503. O bot de voz de um banco não tem segundo caminho. Cada ligação cai no silêncio depois de quatro segundos. O call center lotou. Quando o modelo, a ferramenta ou o provedor falha ou fica lento, o produto inteiro para junto, e ninguém definiu o que deveria acontecer. É o smell Refém de um Provedor.

Solução

Defina, para cada dependência, o que acontece quando ela falha: timeout curto, um caminho alternativo já avaliado (outro modelo, outro provedor, uma resposta fixa, uma fila, uma pessoa) e um disjuntor que para de insistir num serviço que está fora.

Antes e depois

-def answer(call):
-    reply = client.messages.create(model=PRIMARY, messages=call.messages)
-    return speak(reply)
+def answer(call):
+    if breaker.is_open("primary"):                         # disjuntor aberto: nem tenta
+        return fallback(call)
+    try:
+        reply = client.with_options(timeout=2.5, max_retries=0).messages.create(
+            model=PRIMARY, messages=call.messages, max_tokens=400)
+        breaker.record_success("primary")
+        return speak(reply)
+    except (APITimeoutError, APIConnectionError, InternalServerError, RateLimitError):
+        breaker.record_failure("primary")
+        return fallback(call)
+
+def fallback(call):
+    reply = backup_client.create(model=BACKUP, prompt=BACKUP_PROMPT, ...)  # avaliado no eval
+    if reply is None:
+        return speak_fixed("Vou transferir você para um atendente.") or transfer(call)
+    return speak(reply)

Antes: um caminho só.

flowchart LR
  C(["1. Ligação"]):::io --> P(["2. Modelo principal"]):::llm
  P -->|"falha ou lentidão"| X(["3. Silêncio e queda"]):::io

Depois: timeout, disjuntor e degraus de fallback.

flowchart LR
  C(["1. Ligação"]):::io --> B{"2. Disjuntor aberto?"}
  B -->|não| P(["3. Modelo principal, timeout curto"]):::llm
  B -->|sim| F(["4. Modelo reserva"]):::llm
  P -->|"erro ou timeout"| F
  F -->|"também falhou"| H((("5. Atendente humano"))):::human
  P --> OUT(["Resposta"]):::io
  F --> OUT

1. A requisição chega.
2. Se o serviço principal falhou várias vezes há pouco, o disjuntor está aberto e nem se tenta.
3. O modelo principal tem um timeout compatível com o produto (segundos, não minutos).
4. O reserva já foi avaliado com o seu próprio prompt.
5. Se tudo falhar, há um caminho definido que não depende de modelo.

Por que funciona

Falhas de provedor são raras, mas certas. As páginas de status dos grandes provedores registram incidentes públicos com alguma frequência. Sem um plano, cada falha vira uma decisão manual, tomada tarde e sob pressão. Com um plano em código, a troca acontece em segundos e do mesmo jeito toda vez.

As três peças se completam. O timeout curto impede que requisições presas consumam todos os recursos. O disjuntor evita insistir num serviço que está fora, o que piora a falha e atrasa a recuperação. O fallback avaliado garante que o caminho alternativo funciona antes de ser necessário.

Exemplo trabalhado: voz com teto de 3 segundos

Produto: URA de banco no telefone, pausa máxima que o cliente tolera cerca de 3 segundos. SDK padrão espera 10 minutos e faz 2 retries. Sem mexer nisso, uma lentidão do provedor segura 200 ligações simultâneas até o timeout.

Configuração: timeout=2.5, max_retries=0. Disjuntor abre depois de 5 falhas em 30 segundos. Fallback: modelo de outro provedor, com prompt próprio. Suponha que o eval mostre o reserva uns 4 pontos abaixo do principal na classificação de intenção. Terceiro degrau: frase fixa e transferência ao atendente.

Às 14h o principal devolve 503. As primeiras 5 ligações falham em 2,5s e caem no reserva. O disjuntor abre. As seguintes nem tentam o principal. O call center recebe só o que o reserva também não cobriu. Sem o plano, todas as ligações iam ao silêncio.

Checagem +20 XP de primeiraO SDK do provedor tem timeout de 600s e 2 retries. Seu bot de voz precisa responder em 3s. Você só implementou um modelo reserva, sem mexer no cliente HTTP. O que acontece numa lentidão?

O reserva entra na hora, porque a falha é óbvia

A ligação espera o timeout e os retries do SDK; o reserva chega minutos depois, se chegar

O disjuntor abre sozinho depois da primeira ligação lenta

Passo a passo seguro

0. Meça. Levante a latência p95 e p99 do modelo, a taxa de erro e o que acontece hoje numa falha (simule em homologação).
1. Defina os timeouts a partir da experiência que o produto aceita, não do padrão da biblioteca.
2. Escolha o fallback de cada dependência: outro modelo, outra região, outro provedor, resposta fixa, fila ou pessoa. Tarefa noturna não precisa do mesmo degrau que voz ao vivo.
3. Avalie o fallback com o eval, com prompt próprio se necessário. Saiba quanto a qualidade cai. Sem isso, o reserva é uma surpresa no pior dia.
4. Implemente o disjuntor com limiar de falhas, tempo aberto e teste de recuperação (meia-aberta: uma sonda, não um dilúvio).
5. Registre no trace qual caminho atendeu cada requisição.
6. Ensaie a falha: derrube o principal em homologação e confira que o fallback assume.
7. Meça de novo a disponibilidade e a qualidade no caminho alternativo.

Armadilha: dois modelos no mesmo provedor

gpt-4o e gpt-4o-mini caem juntos quando a API daquele provedor, naquela região, está fora. Diversifique provedor ou região quando o produto não pode parar. Se não puder, o último degrau não pode ser modelo: frase fixa, fila, pessoa.

Outra armadilha: fallback que ninguém rodou no eval. Formato diferente, tom diferente, ferramenta com nome antigo. O dia da queda é a primeira vez que aquele prompt vê produção.

Checagem +20 XP de primeiraO reserva nunca passou pelo eval. No ensaio de homologação ele responde em texto livre, e o produto espera JSON com intent. O que você faz antes de ir para produção?

Nada. No dia da queda, texto livre ainda é melhor que silêncio

Rodar o mesmo eval do principal no reserva, com prompt próprio, e só promover se o formato bater e a qualidade for aceitável

Pedir no prompt do reserva ‘responda igual ao principal’, sem dataset

Riscos

• Fallback nunca testado. Um modelo reserva que ninguém avaliou pode responder pior ou em outro formato. O eval do reserva é obrigatório.
• Fallback que também cai. Dois modelos no mesmo provedor e região falham juntos. Diversifique quando o produto exigir.
• Oscilação. Disjuntor mal configurado abre e fecha o tempo todo. Ajuste limiar e janela. Uma sonda na meia-aberta, não 100% do tráfego de volta de uma vez.
• Custo inesperado. O reserva pode ser mais caro. Monitore o custo quando ele estiver em uso.

Desafio

Um gerador de relatórios noturno usa um modelo para resumir vendas. Se o provedor cair, o relatório não sai. Que fallback faz sentido aqui?

Ver solução

Para uma tarefa assíncrona, o fallback mais simples é tempo: retry com espera crescente por algumas horas, só para erros transitórios, e alerta se não concluir até um horário limite. Se o relatório precisa sair de qualquer jeito, um segundo degrau pode gerar uma versão sem resumo (só as tabelas calculadas em código), marcada como incompleta. Modelo reserva só se o eval mostrar que ele resume bem.

Relacionados

• Trata o smell Refém de um Provedor.
• Erros que merecem retry, não troca de caminho: Classificar Erro Antes de Tentar de Novo.
• Sem linha de base no reserva: Criar Eval Antes de Mexer no Prompt.

Teste seu entendimento

Checagem +20 XP de primeiraO disjuntor abre. Você aponta 100% do tráfego de volta ao principal depois de 30s, sem sonda. O provedor ainda está instável. O que acontece?

Oscilação: o disjuntor fecha, as falhas voltam, ele abre de novo, e o produto treme no ritmo da recuperação

Nada de grave. 30s é tempo suficiente para qualquer incidente acabar

O reserva continua atendendo em paralelo, então o dilúvio não importa

Checagem +20 XP de primeiraUm job noturno de NF-e resume notas. O provedor cai às 2h. Qual degrau de fallback cabe primeiro?

Transferir cada nota para um atendente humano às 2h

Esperar e retentar erros transitórios até um horário limite; se não der, emitir o relatório só com os totais calculados em código, marcado como incompleto

Trocar na hora para o modelo mais caro de outro provedor, sem eval, porque o relatório precisa sair

Checagem +20 XP de primeiraO principal e o reserva estão na mesma região do mesmo provedor. O status page acende vermelho nessa região. O que o seu desenho deveria ter previsto?

Nada. Região única simplifica latência e já basta o disjuntor

Um terceiro degrau que não é modelo: frase fixa, fila ou pessoa, porque os dois modelos caem juntos

Retries mais longos no principal, para atravessar o incidente