Roteamento de fallback de modelos para agentes de IA sem perder controle

Roteamento de fallback de modelos significa enviar cada tarefa do agente para um modelo principal, com um segundo modelo já definido para entrar em ação quando o primeiro estiver indisponível, lento demais ou reprovar em uma checagem de qualidade. Bem feito, ele mantém um agente da empresa funcionando durante interrupções do fornecedor e trocas de versão de modelo, e só transfere uma tarefa para um modelo substituto que tenha sido testado com as mesmas regras de aceite. As regras de roteamento que você escreve, e não apenas a escolha do modelo, determinam se o agente continua seguro e útil.

Principais pontos

• Fallback é uma política que você escreve e testa, não um ciclo de repetição que você espera que funcione.
• Roteie por tipo de tarefa e risco, e declare quais tarefas nunca podem trocar de modelo em silêncio.
• Registre o modelo que produziu cada saída, para que custo e qualidade possam ser revisados depois.
• Teste cada modelo de fallback com o mesmo contrato de tarefa antes de colocá-lo em produção.
• Trate a troca de modelo como uma liberação, com avaliação, caminho de reversão e um responsável definido.

Por que o roteamento de fallback importa para um agente da empresa

Um agente da empresa depende de pelo menos um fornecedor de modelo, e essa dependência falha de formas fáceis de ignorar. Um fornecedor pode ficar indisponível, responder devagar em horários de pico, devolver erros para certos tamanhos de requisição ou aposentar uma versão de modelo para a qual um fluxo de trabalho foi ajustado. As três primeiras falhas são visíveis. A quarta é silenciosa: o substituto ainda responde, e a resposta parece razoável, enquanto a precisão nas suas tarefas específicas cai.

Essa falha silenciosa é justamente o que o roteamento de fallback precisa proteger. Um ciclo de repetição que envia a mesma requisição para outro modelo mantém a fila andando, mas não avisa ninguém que a saída mudou. A pergunta do responsável não é apenas se o agente respondeu. É se a resposta atendeu à qualidade que a tarefa exigia e se a equipe consegue ver qual modelo a produziu.

Defina quais tarefas podem trocar de modelo e quais devem pausar

Nem toda tarefa merece o mesmo comportamento de fallback. Por isso, separe o trabalho do agente em três grupos antes de escrever qualquer regra de roteamento.

O grupo um reúne trabalho de baixo risco e reversível: rascunhos de resumos internos, classificação de pedidos recebidos ou extração de campos para um esquema fixo. Um modelo de fallback é aceitável aqui, desde que passe nas mesmas checagens de esquema.

O grupo dois reúne trabalho em que uma resposta errada custa tempo, mas pode ser corrigida, como respostas que uma pessoa revisa antes de enviar ou atualizações de um documento compartilhado com histórico de versões. O fallback só é aceitável com um modelo testado e uma marcação visível no registro.

O grupo três reúne trabalho com compromissos externos ou efeitos irreversíveis, como uma declaração vinculante a um cliente, uma alteração de direitos de acesso ou um pagamento. Essas tarefas não deveriam trocar de modelo em silêncio, de forma nenhuma. Quando o modelo principal estiver indisponível, devem pausar, manter o estado e notificar o responsável.

Escrever essa classificação é o primeiro entregável. O princípio mais amplo de associar tarefas a modelos está tratado em Roteamento de modelos em agentes de IA: o modelo certo por tarefa, que complementa bem essa decisão.

Como montar uma cadeia de fallback passo a passo

Uma cadeia de fallback é uma lista ordenada de modelos para um grupo de tarefas, com regras para quando descer na lista. Monte nesta ordem.

• Passo 1: escreva primeiro o contrato da tarefa. Defina a entrada, o formato esperado da saída, as checagens de aceite e o que conta como tentativa falha. Sem isso, você não consegue saber se um fallback é bom o bastante.
• Passo 2: nomeie um modelo principal e no máximo dois fallbacks por grupo de tarefas, e registre a versão exata de cada um, em vez de um apelido que muda sozinho.
• Passo 3: defina gatilhos explícitos: um limite de tempo, uma classe específica de erro do fornecedor, uma falha de validação de esquema ou uma checagem automática reprovada. Não acione o fallback pelas declarações do próprio modelo sobre sua confiança, porque esse não é um sinal confiável.
• Passo 4: limite as repetições e o tempo total por tarefa. Um fallback que roda sem fim é uma falha de fila disfarçada.
• Passo 5: defina o que acontece no fim da cadeia. No grupo um, a resposta pode ser uma nova tentativa agendada para depois. No grupo dois, um item de revisão humana. No grupo três, uma tarefa pausada com aviso ao responsável.
• Passo 6: registre o identificador do modelo, o motivo de cada troca, a latência e os resultados das checagens de cada tarefa, para que a rota possa ser revisada depois.
• Passo 7: rode o mesmo conjunto de avaliação em cada modelo da cadeia antes de colocá-lo em produção, e repita sempre que uma versão mudar.

Mantenha a cadeia curta. Cada fallback adicional é mais um modelo cujo comportamento você precisa entender, testar e monitorar.

Como detectar falhas e queda silenciosa de qualidade?

Erros são a parte fácil. O caso mais difícil é a saída bem formada, mas errada. Para pegá-la, combine três tipos de sinal.

O primeiro é operacional: tempos limite, respostas de limite de taxa, códigos de erro e latência. A introdução de OpenTelemetry sobre observabilidade explica o vocabulário básico de traces, métricas e logs que permite registrar esses sinais de forma consistente entre serviços. Use o mesmo vocabulário para as chamadas de modelo, assim uma mudança de rota aparece em um painel e não em uma reclamação de cliente.

O segundo é estrutural: validação de esquema, campos obrigatórios presentes, valores dentro de faixas esperadas e citações que apontam para documentos que realmente existem na base de conhecimento. Essas checagens são baratas e podem rodar em todas as tarefas.

O terceiro é a amostragem de qualidade: uma revisão recorrente das tarefas concluídas contra o contrato da tarefa, feita por uma pessoa ou por uma checagem automática com pontuação. O guia de avaliações da OpenAI descreve como escrever casos de teste e avaliadores para esse tipo de medição repetida. A amostragem é o que revela desvios que nenhuma checagem de esquema consegue ver.

Um fallback que nunca foi registrado é uma decisão que ninguém tomou.

Cenário ilustrativo, não é um cliente real: um agente redige notas de conciliação de fornecedores para uma equipe de operações. O modelo principal atinge o tempo limite numa tarde movimentada, e a cadeia passa para um fallback. O fallback passa na validação de esquema, mas, na amostragem, o revisor percebe que ele omite o campo que marca faturas contestadas, algo que um resumo descuidado também faria. Como todas as rotas foram registradas, a equipe identifica que todas as notas daquela hora vieram do fallback, reexecuta essas tarefas no principal quando ele se recupera e acrescenta uma regra de esquema que exige o campo de contestação. A falha foi pega pela amostragem, não pelo caminho de erro, e é por isso que a etapa de amostragem deve estar no desenho desde o começo.

Se uma troca acontecer no meio de uma tarefa com várias etapas, o agente deve retomar a partir do último estado salvo, em vez de recomeçar em outro modelo sem nenhum registro do que já foi feito. O padrão está descrito em Checkpoints de agentes de IA: como retomar o trabalho.

Controle as mudanças de modelo antes que cheguem aos usuários

Roteamento não trata só de interrupções. Fornecedores atualizam modelos, aposentam versões e mudam padrões, e cada uma dessas mudanças pode alterar a saída sem nenhum erro visível. Trate cada mudança como uma liberação.

Fixe versões exatas de modelo na configuração. Quando surgir uma versão nova, rode o conjunto de avaliação sobre ela e compare os resultados com o principal atual nas mesmas tarefas. Promova a nova versão somente se ela atender às checagens de aceite de todos os grupos de tarefas que vai atender. Mantenha a versão anterior disponível como fallback por um período definido, para que uma reversão não exija reconstruir nada.

O NIST AI Risk Management Framework trata a medição e o monitoramento do comportamento de sistemas de IA depois da implantação como uma atividade contínua, e não como uma etapa única antes do lançamento. Essa visão combina bem com o roteamento, porque a cadeia que você testou no trimestre passado não está automaticamente valendo para a cadeia que roda hoje.

As permissões exigem a mesma disciplina. Cada endpoint de modelo é um serviço externo, com credenciais próprias e termos próprios de tratamento de dados. Um novo fornecedor de fallback cria um novo caminho de dados, que deve ser aprovado pela mesma pessoa que aprova o principal. Qualquer gancho que rode antes ou depois de uma chamada de modelo, como uma verificação que remove dados pessoais dos prompts, deve ser testado em todas as rotas da cadeia, conforme explicado em Hooks em agentes de IA: verificações automáticas antes e depois.

Em um projeto gerenciado, a Be Human escreve a política de roteamento com o responsável do negócio durante a primeira definição de papéis, redige os contratos de tarefa que o fallback precisa cumprir, opera os registros e as avaliações recorrentes e revisa as permissões de cada endpoint de modelo. Mudanças de modelo só são liberadas depois que o conjunto de avaliação passa. A memória, as ferramentas e o contexto operacional do agente continuam sob controle da empresa, de modo que trocar um modelo não significa reconstruir o agente.

Por onde começar

Comece pelo diagnóstico gratuito de IA da Be Human para identificar a primeira tarefa que vale entregar a um agente e, antes de qualquer outra coisa, escreva a cadeia de fallback dessa tarefa.

Perguntas frequentes

O que deve acontecer quando o modelo principal está fora do ar e a tarefa é de alto risco? A tarefa deve pausar em vez de passar para um modelo substituto. Seu estado é salvo, o responsável é avisado pelo canal combinado e a tarefa retoma quando o principal se recuperar ou quando uma pessoa aprovar uma alternativa documentada. A substituição silenciosa em compromissos externos é justamente a falha a evitar.

Um modelo de fallback mais barato é aceitável? Pode ser, mas só depois de passar pelo mesmo contrato de tarefa do principal, usando os seus próprios exemplos. Uma rota mais barata que produz saídas sem checagem transfere o custo para retrabalho e revisão. Meça o custo por tarefa concluída, e não o custo por chamada, porque um fallback que precisa de repetições pode custar mais no total.

Com que frequência devemos testar a cadeia de fallback? Rode o conjunto de avaliação sempre que uma versão de modelo mudar, depois de qualquer alteração em prompts ou permissões e em um calendário regular compatível com a frequência com que a tarefa roda. Uma rota que não foi exercitada há algum tempo pode falhar na primeira vez em que for necessária, então inclua um teste periódico que force uma troca em um ambiente seguro.

Precisamos construir isso internamente? Podem construir, mas aí vocês passam a ser donos dos registros, das avaliações, das credenciais e da resposta a incidentes de cada modelo da cadeia. Equipes podem montar tudo por conta própria ou usar um fornecedor gerenciado, e nos dois casos o negócio deve manter a titularidade dos contratos de tarefa e das regras de aprovação.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.