Seu fallback provavelmente não é um fallback
Uma lista ordenada de modelos parece resiliência, mas só vira fallback quando o próximo degrau consegue fazer o mesmo trabalho.
Um fallback (caminho alternativo) para IA parece simples. Você escolhe um modelo de IA (programa que gera respostas) e põe outro depois dele. Talvez inclua um terceiro para emergências. Se o primeiro falhar, o sistema tenta o próximo.
Essa lista quase sempre engana.
O erro é tratar o nome do modelo como medida de segurança. Na prática, pode falhar um limite de uso, uma assinatura, uma capacidade, uma ferramenta ou um tipo de tarefa. Se o próximo passo depende das mesmas coisas, a lista cai pelo mesmo motivo.
Redundância não é nome diferente
A primeira armadilha é contar nomes diferentes como proteção. Dois clientes podem usar a mesma assinatura. Dois modelos podem consumir o mesmo limite. Duas rotas podem depender da mesma conta ou permissão.
Quando o limite acaba, os dois param.
Por isso, penso no fallback pelos recursos e limites que cada opção usa, não pelo nome. Em vez de perguntar "tenho dois modelos?", pergunto: "se este limite acabar, o próximo tem outro limite?". Se não tiver, a lista só parece mais profunda.
Isso vale para fornecedor, projeto, tipo de conta e qualquer etapa que possa negar o pedido antes de o modelo responder. O sistema não precisa guardar detalhes privados. Precisa registrar quais opções dependem do mesmo ponto.
A mesma tarefa
A segunda armadilha parece sucesso. O primeiro modelo edita arquivos. O segundo só devolve texto. O primeiro falha e o segundo responde com um plano ou um patch formatado. A automação marca o trabalho como concluído.
Mas nada mudou.
O próximo passo só serve como fallback se puder fazer a mesma tarefa. Se o trabalho exige abrir uma ferramenta, gravar um arquivo, ler uma imagem ou chamar outro sistema, o fallback precisa dessas mesmas capacidades. Perder qualidade pode ser aceitável. Trocar de tarefa sem avisar, não.
É melhor mostrar um erro claro do que esconder a perda de capacidade. O erro interrompe o processo. Um sucesso falso segue adiante e entrega ausência como se fosse trabalho.
Quando a capacidade muda, a rota também precisa mudar. Pode passar a responder só por texto, pedir revisão ou bloquear. Não pode manter o mesmo combinado.
Falha momentânea ou falta definitiva
A terceira armadilha é confundir uma falha temporária com a perda de um recurso. Um limite de chamadas diz que o pedido não passou naquele momento. Não diz que o recurso acabou para sempre. Uma resposta de acesso negado ou item não encontrado indica outro problema.
Quando o roteador (programa que escolhe qual modelo recebe cada pedido) trata todas as falhas do mesmo jeito, ele tira de uso uma opção saudável. Um pico temporário vira uma falsa prova de que o caminho escolhido parou. Depois, o sistema usa uma opção pior, mesmo quando a primeira já voltou.
Por isso, o fallback precisa registrar a causa e o destino. "Foi para o segundo modelo" não basta. Preciso saber se houve limite, indisponibilidade, falta de permissão, recurso ausente ou incapacidade para a tarefa. Sem isso, não dá para ajustar as escolhas.
Um ponto de passagem
Na minha experiência, o jeito mais simples de acompanhar tudo é usar um gateway (serviço que recebe os pedidos e os encaminha). Toda chamada passa por ele.
Esse serviço precisa saber qual tarefa foi pedida, quais capacidades ela exige, quais opções são independentes e qual modelo respondeu.
O registro do modelo que respondeu é obrigatório. Sem ele, você pode achar que o sistema usa a primeira opção. Na verdade, talvez use a última há semanas. O produto continua funcionando, mas a margem acabou.
Um fallback que funciona precisa de um combinado: quais capacidades o trabalho exige, quais opções são independentes, qual falha permite tentar de novo e qual exige parar.
Onde isso quebra
Um gateway único também pode ser o único ponto de falha. Se ele parar, tudo que depende dele para. Ele precisa ser tratado como parte importante do sistema, com acompanhamento e uma forma manual de atender operações críticas.
O registro das escolhas também é dado sensível. Ele mostra o que você envia para fora, quando envia e que tipo de fornecedor recebe. Guarde esse registro como dado de operação, não como anotação solta.
A escolha automática de modelos também pode esconder uma piora. Sem olhar os dados de uso, você só descobre que a melhor opção parou quando a última também parar.