Playbook de fallback multimodelo para APIs de IA confiáveis

Principais conclusões

Tente novamente na mesma rota apenas para falhas transitórias, como timeouts e respostas 429.

Faça failover para um modelo que atenda aos mesmos requisitos de capacidade e contrato de saída.

Defina um orçamento máximo de custo e latência para toda a solicitação, não para cada tentativa.

Registre o provedor, o modelo, a classe do erro, a quantidade de novas tentativas e a rota final de cada solicitação.

Separe novas tentativas de fallback

Uma nova tentativa envia a solicitação novamente pela mesma rota porque a falha pode ser temporária. Um fallback altera o provedor ou o modelo porque a rota original está indisponível ou é inadequada.

Tratar ambas as ações como um único loop genérico de novas tentativas dificulta o diagnóstico de incidentes e pode multiplicar os custos sem melhorar a taxa de sucesso.

Nova tentativa: timeout, redefinição de conexão, resposta 429 ou resposta 5xx temporária.
Fallback: falha repetida do provedor, problema de capacidade do modelo ou restrição de política.
Interrupção: solicitação inválida, parâmetro não compatível ou falha na validação da saída.

Crie uma tabela de rotas compatíveis com as capacidades

Os modelos de fallback devem ser agrupados por capacidade, e não por marca. Uma solicitação de visão não pode usar como fallback um modelo somente de texto, e um fluxo de trabalho com JSON estrito não deve ser direcionado a um modelo que viola o schema regularmente.

Modalidades de entrada e saída necessárias.
Contexto e comprimento mínimo da saída.
Suporte a chamadas de ferramentas e saídas estruturadas.
Preço e latência máximos aceitáveis.

Aplique um único orçamento por solicitação

O orçamento da solicitação deve abranger todas as novas tentativas e tentativas de fallback. Antes de iniciar outra tentativa, verifique se os orçamentos restantes de latência e custo podem suportá-la.

const routePolicy = {
  maxAttempts: 3,
  maxLatencyMs: 18_000,
  maxEstimatedCost: 0.12,
  retryOn: [408, 429, 500, 502, 503, 504],
  fallbackModels: ['primary-model', 'quality-fallback', 'fast-fallback'],
};

Meça a qualidade do fallback, não apenas a disponibilidade

Uma solicitação que retorna com sucesso ainda pode representar uma falha do produto. Acompanhe a validação da saída, a taxa de correção pelos usuários e a conclusão da tarefa após um evento de fallback.

Dashboard recomendado: sucesso da rota, taxa de fallback, latência p95, custo estimado, taxa de aprovação na validação e pontuação de qualidade por modelo.

Perguntas frequentes

Toda solicitação de IA com falha deve usar um modelo de fallback?

Não. Parâmetros inválidos, entradas não compatíveis e verificações de segurança malsucedidas devem interromper o processamento imediatamente. O fallback é apropriado quando outra rota compatível pode concluir realisticamente a mesma tarefa.

Quantas tentativas de fallback uma solicitação de IA deve permitir?

A maioria dos fluxos de trabalho interativos deve limitar o total a duas ou três tentativas. O limite correto depende do orçamento de latência restante, do valor da tarefa e do custo estimado.