Como criar um agente de suporte com fallback routing em IA: tutorial completo

O suporte ao cliente é um dos casos de uso mais poderosos para agentes de IA. Milhões de empresas recebem diariamente perguntas repetitivas como “onde está meu pedido?”, “quero um reembolso” ou “não consigo acessar minha conta”. Um agente de IA bem treinado poderia responder instantaneamente à maioria dessas solicitações, reduzindo custos operacionais e melhorando a experiência do cliente.

Mas nem toda solicitação tem o mesmo nível de complexidade. Algumas são simples e de baixo risco. Outras são sensíveis, ambíguas ou críticas para o negócio. É aí que entra o fallback routing — um padrão de orquestração de IA que roteia cada solicitação para o modelo mais adequado.

O que é fallback routing

Fallback routing é um padrão onde uma solicitação é inicialmente enviada para um modelo primário (rápido e barato). A qualidade da resposta é então avaliada. Se atingir os thresholds de confiança, segurança e política, a resposta é entregue ao cliente. Caso contrário, a solicitação é encaminhada para um modelo mais forte, um especialista, ou um atendente humano.

Arquitetura do agente

Um agente de suporte com fallback routing contém seis componentes principais:

1. Canal de entrada: chat ao vivo, e-mail, WhatsApp, widget no site, aplicativo mobile, ou software de help desk
2. Classificador de intenção: identifica o tipo de solicitação (cobrança, reembolso, suporte técnico, envio, acesso à conta, reclamação)
3. Camada de recuperação (RAG): consulta bases de conhecimento — FAQ, documentação de produto, banco de pedidos, CRM, histórico de tickets
4. Roteador: decide qual modelo deve processar a solicitação com base no tier do cliente, tópico, dificuldade esperada, carga do sistema, orçamento de latência e custo
5. Modelo primário: gera a resposta inicial para consultas simples e rotineiras
6. Avaliador de confiança: verifica thresholds de confiança, qualidade da recuperação, conformidade com políticas, linguagem de incerteza, completude da resposta e sentimento do cliente

Quando usar o modelo primário vs fallback

Modelo primário (rápido e barato)

Use para tarefas como:

• Responder perguntas frequentes (FAQ)
• Fornecer status de pedidos
• Explicar políticas da empresa
• Instruções passo a passo simples
• Confirmação de dados cadastrais

Exemplo: um cliente pergunta “Como faço para resetar minha senha?” O modelo primário recupera a política de senhas, gera uma resposta concisa e encerra o diálogo sem escalonamento.

Modelo de fallback (mais capaz)

Use para casos como:

• Disputas de cobrança e reembolsos
• Problemas legais ou de compliance
• Clientes insatisfeitos ou em risco de churn
• Consultas técnicas muito específicas
• Solicitações ambíguas com múltiplas intenções

Exemplo: um cliente escreve “Fui cobrado em dobro, o suporte não me respondeu, e quero meu dinheiro de volta AGORA.” Isso envolve cobrança, follow-up de reclamação, insatisfação do cliente e política de reembolso — complexidade demais para o modelo simples.

Sinais que disparam o fallback

O fallback pode ser acionado por vários sinais:

• Score de confiança baixo: o modelo não tem certeza da resposta
• Qualidade de recuperação ruim: a base de conhecimento não retornou informações relevantes
• Violação de política: a resposta proposta infringe alguma regra
• Linguagem de incerteza: o modelo usou frases como “eu acho que” ou “possivelmente”
• Sentimento negativo: o cliente demonstrou frustração ou raiva

Fallback invisível para o cliente

Um princípio importante: o cliente não deve perceber que houve fallback. A conversa deve fluir normalmente, sem indicadores de que o sistema trocou de modelo. O fallback também pode receber o rascunho da resposta do modelo primário e editá-lo, validá-lo ou substituí-lo — isso reduz esforço duplicado e ajuda o modelo mais forte a entender por que a primeira resposta foi insuficiente.

Restrições de latência e custo

O roteador deve considerar restrições operacionais:

• Latência: respostas em tempo real (chat) precisam de modelos rápidos — o fallback pode adicionar 2-5 segundos
• Custo: se o modelo de fallback custa 10x mais que o primário, o roteador precisa garantir que ele só seja usado quando realmente necessário
• Carga do sistema: em horários de pico, o roteador pode ser mais conservador nos escalonamentos para evitar sobrecarga

Prós e contras do fallback routing

✅ Vantagens

• Custo otimizado: 80-90% das consultas vão para o modelo barato
• Qualidade preservada: casos complexos recebem o melhor modelo disponível
• Escalabilidade: suporta picos de volume sem degradação
• Experiência do cliente: respostas rápidas para consultas simples, precisão para as difíceis
• Flexibilidade: fácil trocar modelos primário e fallback conforme novos modelos são lançados

⚠️ Desvantagens

• Complexidade de implementação: exige classificador de intenção, RAG, roteador e avaliador de confiança
• Latência adicional no fallback: o cliente espera mais quando a consulta é escalada
• Calibragem do threshold: definir o ponto ideal de escalonamento requer experimentação

Exemplo prático de fluxo

Um cliente envia: “Comprei o produto X há 3 dias, paguei com cartão de crédito, mas recebi o produto Y. Quero o produto correto ou meu dinheiro de volta.”

1. Classificador: identifica como “envio incorreto + reclamação + reembolso”
2. RAG: recupera política de trocas, dados do pedido e histórico do cliente
3. Roteador: detecta múltiplas intenções, insatisfação e menção a reembolso → encaminha direto para o modelo de fallback (nem tenta o primário)
4. Fallback: gera resposta com pedido de desculpas, instruções de devolução, confirmação de reenvio e informação sobre prazos
5. Entrega: cliente recebe resposta completa em ~5 segundos

Requisitos técnicos

Troubleshooting: problemas comuns

• ❌ Fallback sendo acionado demais (>30%): o threshold de confiança está muito alto ou o modelo primário é fraco demais. Solução: reduza o threshold ou troque o modelo primário por um mais capaz.
• ❌ Cliente percebe a troca de modelo: o fallback está gerando respostas com tom ou formato diferente. Solução: garanta que ambos os modelos sigam o mesmo prompt de sistema e tom de voz.
• ❌ Latência inaceitável no fallback: o modelo de fallback é pesado e o tempo de resposta passa de 10 segundos. Solução: use streaming ou considere um modelo intermediário.
• ❌ Classificador errando intenções: confunde “quero cancelar” com “quero reembolso”. Solução: refine o prompt do classificador com exemplos de cada categoria.
• ❌ Custo explodindo: o fallback está sendo usado em 50%+ das consultas. Solução: melhore a base RAG e o prompt do modelo primário para resolver mais casos sem escalonamento.

FAQ

Dá para usar um único modelo para tudo? Dá, mas você vai pagar o preço do modelo mais caro em 100% das consultas — inclusive nas mais simples que um modelo barato resolveria. Fallback routing reduz o custo total em 60-80%.

Preciso de um classificador de intenção dedicado? Não necessariamente. O próprio modelo primário pode ser instruído a avaliar sua confiança na resposta. Mas um classificador separado é mais confiável para detectar casos de alto risco.

Qual a taxa ideal de fallback? Depende do negócio, mas 10-20% é um bom alvo. Menos que 5% sugere que você está usando um modelo primário mais caro do que precisa. Mais que 30% sugere que o primário é fraco demais.

Funciona com qualquer provedor? Sim. O padrão é agnóstico de provedor. Você pode usar OpenAI + Anthropic, Google + Meta, ou qualquer combinação.

Preciso de um endpoint dedicado para o roteador? Em produção, sim. Mas para prototipagem, uma função simples que avalia o score de confiança e decide a rota é suficiente.