Roteamento de modelos de IA por tarefa: guia

Um único modelo para tudo simplifica a compra e complica a operação

Uma empresa conecta o mesmo modelo à triagem de e-mails, à análise de contratos, à preparação de propostas e ao atendimento. A configuração parece eficiente: uma integração, uma fatura e um padrão técnico.

As tarefas, porém, exigem capacidades diferentes. Classificar uma solicitação comum pede velocidade e consistência. Interpretar fontes conflitantes pede análise mais cuidadosa. Uma atualização financeira pode exigir regra determinística e aprovação, mesmo quando o modelo produz uma boa recomendação.

Roteamento de modelos de IA é a política que escolhe qual recurso processará cada etapa. A rota pode usar código, um modelo leve, um modelo mais capaz, uma ferramenta especializada ou uma pessoa autorizada.

O objetivo é entregar cada unidade de trabalho dentro de limites conhecidos de qualidade, risco, tempo e custo. O roteador precisa tomar uma decisão verificável. Escolher pelo nome mais famoso ou pelo menor preço apenas muda o lugar onde a incerteza aparece.

O que o roteamento decide

Uma política de roteamento responde a cinco perguntas antes ou durante a execução:

que classe de tarefa chegou;
quais requisitos essa classe possui;
quais rotas estão aprovadas para atendê-la;
que sinal autoriza escalonamento ou bloqueio;
como o resultado será medido e atribuído à rota usada.

O roteador pode operar dentro de um gateway de IA, no orquestrador do processo ou em uma camada dedicada. A localização técnica depende da arquitetura. O contrato de decisão precisa permanecer o mesmo: entrada classificada, política vigente, rota escolhida, motivo e resultado observado.

Separe regra, modelo e autoridade humana

Roteamento começa pela natureza do trabalho, não pela tabela de preços dos fornecedores.

Regras e código para fatos verificáveis

Use lógica determinística quando a etapa envolve:

validar tipo, formato ou campo obrigatório;
calcular soma, prazo, faixa ou duplicidade;
consultar uma lista autorizada;
aplicar limite de valor ou volume;
verificar permissão, identidade ou estado;
confirmar uma gravação no sistema de destino.

Um modelo pode ajudar a extrair a informação que alimenta a regra. A decisão objetiva continua no componente que consegue produzir sempre o mesmo resultado para a mesma entrada.

Modelo leve para variação conhecida

Um modelo menor ou mais econômico pode atender tarefas como:

classificação de categorias estáveis;
extração estruturada de documentos conhecidos;
resumo curto para uso interno;
normalização de texto;
triagem inicial;
identificação de intenção em vocabulário recorrente.

Essa rota só é econômica quando a saída passa no critério de qualidade. Uma classificação barata que envia casos para a fila errada transfere custo para atendimento e cliente.

Modelo mais capaz para ambiguidade relevante

Rotas analíticas fazem sentido quando a etapa exige:

reconciliar fontes conflitantes;
interpretar documentos longos ou heterogêneos;
planejar várias etapas com ferramentas;
analisar exceções pouco frequentes;
produzir justificativa apoiada em evidência;
revisar uma saída de menor capacidade que apresentou sinais de dúvida.

Capacidade adicional deve responder a uma dificuldade observável. Enviar todo caso para a rota mais cara elimina o benefício do roteamento.

Pessoa para decisão de autoridade

Algumas decisões permanecem humanas por alçada, obrigação, sensibilidade ou irreversibilidade. Aprovar pagamento, alterar condição contratual, assumir risco jurídico ou tratar uma exceção reputacional exige uma pessoa definida pelo processo.

O agente pode reunir fatos, comparar políticas e preparar opções. A rota humana recebe um pacote com contexto, evidência, pendência e prazo. O guia de handoff entre agente e humano detalha essa transferência.

Defina classes de tarefa antes de escolher modelos

O erro comum é construir a política com nomes de modelos: simples vai para A, complexo vai para B. A palavra “complexo” não oferece critério de operação.

Crie classes baseadas na unidade de trabalho e na consequência.

Uma operação comercial pode separar:

| Classe | Exemplo | Requisito principal | Consequência | |---|---|---|---| | extração | identificar empresa e pedido em um e-mail | precisão de campos | baixa antes da validação | | classificação | definir assunto e fila | consistência por categoria | atraso se errar | | preparação | montar resumo e próxima ação | fonte e completude | revisão humana | | recomendação | sugerir prioridade comercial | evidência e calibração | influencia decisão | | execução | atualizar CRM ou enviar mensagem | permissão e confirmação | efeito externo |

Para cada classe, registre:

entrada e formato;
saída obrigatória;
fontes permitidas;
qualidade mínima;
latência máxima;
orçamento normal;
dados que podem ser processados;
ferramentas necessárias;
erros impeditivos;
rota principal e alternativas;
revisão ou aprovação exigida.

O artigo sobre configuração de modelos em produção ajuda a transformar cada responsabilidade em um perfil testado. O roteamento escolhe entre perfis aprovados; a configuração define como cada perfil opera.

Use sinais observáveis para escolher a rota

A política pode combinar sinais conhecidos antes da chamada e sinais produzidos durante a execução.

Sinais disponíveis antes da execução

tipo e tamanho da entrada;
idioma e formato;
cliente, processo ou ambiente;
classificação de sensibilidade;
urgência e prazo restante;
ferramentas exigidas;
orçamento da unidade;
volume e capacidade disponível;
regra contratual de provedor ou região.

Esses sinais permitem bloquear rotas incompatíveis antes de expor dados ou consumir orçamento.

Sinais encontrados durante a execução

campo obrigatório ausente;
conflito entre fontes;
saída fora do schema;
evidência insuficiente;
ferramenta recusada ou indisponível;
baixa confiança calibrada para aquela classe;
repetição sem progresso;
custo ou latência perto do teto;
erro crítico detectado pelo validador.

O escalonamento deve responder ao sinal específico. Saída fora do formato pode pedir reparo controlado. Fonte conflitante pode exigir modelo analítico ou pessoa. Permissão negada deve bloquear a ação. Chamar um modelo maior para um erro de credencial apenas produz uma explicação mais cara do mesmo bloqueio.

Monte uma matriz de roteamento

A matriz torna a política revisável por operação, produto, segurança e finanças.

| Classe | Rota principal | Escalonar quando | Rota seguinte | Bloquear quando | |---|---|---|---|---| | triagem comum | modelo leve | categoria incerta | modelo analítico | identidade ausente | | extração documental | perfil estruturado | validação falha após reparo | revisão humana | documento ilegível | | análise de conflito | modelo analítico | impacto acima da alçada | especialista | fonte oficial indisponível | | escrita no CRM | regra e API | sistema retorna estado ambíguo | reconciliação | permissão inválida | | mensagem externa | template aprovado | condição especial | vendedor | opt-out ou destinatário incerto |

Inclua também:

versão da política;
dono da classe;
modelos e fornecedores aprovados;
limite de tentativas;
custo máximo;
prazo máximo;
dados proibidos por rota;
conjunto de testes vigente;
condição de retorno para a rota normal.

Evite cadeias longas. Cada salto acrescenta contexto, latência, custo e dificuldade de investigação. Duas rotas bem testadas e um handoff claro costumam superar uma árvore com cinco modelos escolhidos por heurísticas frágeis.

Qualidade precisa ser medida por rota e por classe

Uma média geral esconde o motivo do roteamento. A rota leve pode funcionar muito bem em pedidos comuns e falhar em anexos. A rota avançada pode melhorar análise e aumentar tempo além da janela útil.

Meça por classe:

unidade concluída corretamente;
erro crítico;
rejeição por validação;
escalonamento correto;
escalonamento desnecessário;
correção humana;
tempo total;
custo técnico;
custo de revisão;
ação confirmada no destino;
impacto no indicador operacional.

A métrica econômica útil é custo por unidade válida. Ela soma consumo, tentativas e revisão e divide pelo trabalho aceito sem correção relevante. O guia de controle de custos de agentes organiza orçamentos e tetos ao redor dessa unidade.

Calibre o escalonamento com casos reais

Um score declarado pelo próprio modelo não deve governar sozinho a troca de rota. Confiança operacional depende da relação entre sinais e resultados observados.

Construa um conjunto de avaliação com:

casos comuns;
entradas incompletas;
categorias parecidas;
fontes divergentes;
conteúdo fora do escopo;
solicitações sensíveis;
falhas de ferramenta;
formatos inválidos;
exemplos que exigem bloqueio;
casos em que a rota leve deveria bastar.

Depois compare faixas e sinais com o desfecho validado. O artigo sobre nível de confiança em agentes de IA mostra como ligar incerteza a seguir, verificar, revisar ou bloquear.

Dois erros merecem atenção própria:

Escalonamento insuficiente

O sistema mantém uma rota fraca em caso ambíguo e produz erro, retrabalho ou risco.

Escalonamento excessivo

Quase tudo vai para o modelo caro ou para uma pessoa. O fluxo preserva qualidade, mas perde economia e capacidade.

A política boa reduz os dois sem perseguir uma taxa abstrata. Ela encontra a menor rota capaz de cumprir o contrato de cada classe.

Fallback e roteamento resolvem problemas diferentes

Roteamento distribui trabalho em condições normais. Fallback reage quando a rota prevista não consegue cumprir o contrato por indisponibilidade, cota, falha ou degradação.

Uma rota alternativa precisa respeitar os mesmos limites de dados, qualidade e autoridade. Disponibilidade técnica não autoriza enviar informação sensível para um provedor diferente ou aceitar uma saída que nunca passou pelos testes da tarefa.

O guia de fallback para agentes de IA detalha matriz de alternativas, modo degradado e retorno à rota principal.

Preserve rastreabilidade sem registrar conteúdo demais

Cada execução deve indicar:

classe da tarefa;
versão da política;
rota considerada e escolhida;
sinais usados na decisão;
modelo, perfil e versão conhecida;
escalonamentos e motivos;
validadores aplicados;
custo e duração;
resultado da unidade;
revisão humana;
confirmação do efeito.

Evite copiar documentos, conversas e dados pessoais para todos os logs. Identificadores, categorias, versões e referências podem preservar investigação com menor exposição. A política de retenção de dados em agentes define finalidade, acesso e prazo para essa evidência.

Implemente em sete etapas

1. Escolha um processo com volume e variação

Comece onde existem tarefas simples e exceções suficientes para justificar rotas diferentes. Um fluxo uniforme pode funcionar melhor com uma única configuração.

2. Registre a linha de base

Meça qualidade, tempo, custo, revisão e erros da rota atual. Sem base, qualquer redução de consumo parecerá ganho.

3. Declare classes e contratos

Defina entrada, saída, fonte, risco, limite e desfecho para cada classe. Separe decisão objetiva de interpretação.

4. Aprove poucas rotas

Use regras, um perfil principal, uma rota de escalonamento e uma pessoa quando necessário. Amplie somente quando houver falha que outra rota resolveria.

5. Teste offline e em modo sombra

Compare a política com casos históricos e entradas reais sem consequência. Registre onde o roteador escolheu mal mesmo quando o modelo produziu boa saída.

6. Libere com alcance limitado

Comece por classes reversíveis, baixo volume e revisão próxima. Versione a política junto com modelos, validadores e integrações.

7. Revise por resultado

Ajuste quando mudar distribuição de entradas, custo, capacidade dos modelos, política de dados ou taxa de exceção. Uma rota aprovada continua sujeita a drift.

Erros comuns

Escolher só pelo preço por token

Preço unitário ignora contexto, tentativas, latência, revisão e taxa de trabalho válido.

Usar tamanho do texto como sinônimo de dificuldade

Uma entrada curta pode conter conflito contratual. Um documento longo e padronizado pode aceitar extração previsível. Complexidade precisa representar o trabalho.

Deixar o próprio modelo decidir sem limites

O agente pode sugerir escalonamento, mas a política precisa restringir rotas, dados, orçamento e consequência.

Escalonar erro técnico para capacidade maior

Credencial vencida, API indisponível e schema quebrado pedem tratamento técnico. Outro modelo não corrige a dependência.

Manter nomes de modelos dentro de cada workflow

Essa dispersão torna troca, auditoria e correção mais lentas. Perfis por responsabilidade preservam a intenção operacional.

Otimizar custo e esquecer a fila humana

Uma rota barata que envia muitas exceções para especialistas reduz a conta do provedor e aumenta o gargalo mais caro.

Checklist da política de roteamento

As classes de tarefa representam unidades de trabalho reais?
Regras objetivas estão fora do julgamento do modelo?
Cada classe possui contrato de qualidade, prazo, custo e dados?
Rotas foram aprovadas com casos representativos?
Escalonamento usa sinais observáveis?
Bloqueios objetivos prevalecem sobre confiança alta?
Existe limite de saltos, tentativas e consumo?
Fallback está separado da distribuição normal?
A rota humana recebe contexto, evidência e prazo?
Métricas distinguem classe, rota e resultado válido?
A decisão fica ligada à versão da política?
Mudanças passam por teste e liberação controlada?

A rota certa é a menor que cumpre o contrato

Roteamento de modelos cria eficiência quando distribui julgamento, regra e autoridade de acordo com o trabalho. A empresa deixa de usar capacidade cara por padrão e evita entregar tarefas sensíveis a recursos insuficientes.

A matriz precisa nascer do processo: classe, fonte, consequência, qualidade, prazo e orçamento. Modelos entram como recursos aprovados dentro dessa arquitetura. Assim, trocar uma rota vira uma decisão mensurável, e não uma aposta repetida a cada lançamento.