5.3 — Roteamento Dinâmico de Modelos: Balanceamento de Carga Cognitivo

Objetivo da Aula

Explicar o conceito de balanceamento de carga cognitivo e por que nem toda tarefa justifica o modelo mais caro disponível

Definir critérios objetivos de classificação de complexidade de tarefa para decidir a qual tier de modelo uma chamada deve ser roteada

Desenhar uma arquitetura de roteamento dinâmico com escalonamento (fallback) entre tiers de modelo

Avaliar o trade-off entre custo, latência e qualidade em cada decisão de roteamento

Reconhecer os riscos de um roteador mal calibrado: subdimensionamento (economia que gera retrabalho) e sobredimensionamento (qualidade que ninguém precisava pagar)

Por que isso importa

Um erro comum de arquitetura em sistemas de IA corporativos é tratar "qual modelo usar" como uma decisão única, tomada uma vez no design do sistema e fixada em configuração. Isso ignora um fato simples: dentro de um único fluxo de negócio, as tarefas individuais variam enormemente em complexidade. Classificar um e-mail como "spam ou não spam" e sintetizar um parecer jurídico de 40 páginas não deveriam competir pelo mesmo orçamento de tokens por chamada — mas em um sistema sem roteamento, competem, porque tudo passa pelo mesmo modelo, dimensionado para o pior caso.

Balanceamento de carga cognitivo é a prática de rotear cada tarefa para o tier de modelo mínimo suficiente para resolvê-la com a qualidade exigida — reservando os tiers mais caros e mais lentos (modelos de raciocínio pesado) apenas para as tarefas que de fato precisam desse poder computacional. É a mesma lógica de balanceamento de carga em sistemas distribuídos tradicionais, aplicada à dimensão de "capacidade cognitiva" em vez de "capacidade de processamento".

Impacto direto no seu trabalho: um arquiteto que roteia tudo para o modelo mais caro está pagando um imposto de capacidade não utilizada em 80% das chamadas. Um arquiteto que roteia tudo para o modelo mais barato está gerando retrabalho, erro e insatisfação de usuário nos 20% de casos que realmente precisavam de raciocínio mais profundo. O roteamento dinâmico é a arquitetura que evita os dois erros simultaneamente — e este capítulo mostra como desenhá-la com critério, não com regra fixa "sempre use o modelo X".

Conceitos Fundamentais

Model tiering: comoditizado vs. raciocínio pesado

O mercado de modelos de linguagem se organiza, de forma genérica, em tiers de capacidade e custo. Não existe uma nomenclatura universal entre fornecedores, mas a distinção estrutural se repete: modelos comoditizados (rápidos, baratos, otimizados para volume) e modelos de raciocínio pesado (mais lentos, mais caros, com capacidade maior de decomposição de problemas complexos e cadeias de inferência longas).

A tabela acima é deliberadamente genérica: o objetivo não é recomendar um fornecedor específico, mas fixar o modelo mental de tiering — porque o mercado de modelos muda de nome e de fornecedor com frequência, mas a distinção estrutural entre "otimizado para volume" e "otimizado para profundidade de raciocínio" tende a persistir como categoria arquitetural.

Critérios de classificação de complexidade de tarefa

Rotear corretamente exige um classificador que decida, antes (ou durante) da execução, qual tier atende a tarefa. Três abordagens são comuns, e raramente são usadas isoladamente — um roteador maduro combina as três.

1. Classificação por regra/heurística (mais barata, menos flexível)
   - Tipo de tarefa conhecido de antemão (ex: "classificação de e-mail"
     sempre vai para Tier 1, por política fixa)
   - Tamanho do input (acima de N tokens, sobe de tier)
   - Presença de palavras-chave que indicam complexidade
     ("compare", "avalie o risco de", "explique o motivo")

2. Classificação por modelo pequeno dedicado (custo baixo, adaptativa)
   - Um modelo Tier 1, barato, é usado SÓ para classificar a
     complexidade da tarefa antes de decidir o roteamento
   - Custo do classificador é uma fração pequena do custo evitado
     ao não subir desnecessariamente uma tarefa simples para Tier 3

3. Escalonamento reativo por confiança (mais robusta, requer nova chamada)
   - A tarefa começa no tier mais barato
   - Se o modelo reporta baixa confiança, ou a resposta falha
     validação, escala automaticamente para o tier acima

Nenhuma dessas três é superior em todos os casos — regra/heurística é barata mas rígida (não captura complexidade fora do padrão previsto); classificador dedicado é adaptativo mas adiciona uma chamada extra de latência e custo (ainda que pequena); escalonamento reativo é o mais robusto contra erro de classificação, mas paga o custo da primeira tentativa mesmo quando ela falha.

Arquitetura de um roteador dinâmico

O fluxo do roteador segue uma árvore de decisão:

• A requisição chega ao harness e é avaliada pelo classificador de complexidade (regra + modelo Tier 1 dedicado), que decide entre três caminhos:
  • Complexidade baixa → roteia para Tier 1. Se a resposta tiver confiança baixa ou falhar na validação, escalona para o Tier 2.
  • Complexidade média → roteia para Tier 2. Se a resposta tiver confiança baixa ou falhar na validação, escalona para o Tier 3.
  • Complexidade alta → roteia direto para Tier 3, que já é o tier máximo: não há escalonamento adicional, apenas nova tentativa (retry) ou revisão humana (HITL) em caso de falha.

O ponto crítico dessa arquitetura é que o escalonamento é uma exceção monitorada, não o caminho comum. Um roteador bem calibrado deve ter a maioria das chamadas resolvidas no tier de entrada, com escalonamento acontecendo numa fração pequena e mensurável dos casos — o Capítulo 5.2 já deu o vocabulário para instrumentar exatamente essa taxa (motivo_escalonamento, no schema de telemetria).

Trade-off custo-latência-qualidade

Toda decisão de roteamento é, na prática, uma decisão em um triângulo de três variáveis que raramente se otimizam juntas.

* valores ilustrativos de ordem de grandeza, não benchmark de nenhum fornecedor específico — a proporção entre tiers varia por provedor e por momento de mercado.

A leitura crítica dessa tabela não é "Tier 3 é sempre melhor" — é que Tier 3 custa até 60x mais e responde até 15x mais devagar do que Tier 1, para uma tarefa que Tier 1 já resolveria igualmente bem. Rotear uma tarefa simples para Tier 3 não é "mais seguro" — é desperdício de orçamento e de tempo de resposta, sem ganho de qualidade perceptível pelo usuário final. O objetivo do roteador é justamente evitar esse desperdício sistemático, sem cair no erro oposto de subdimensionar tarefas que realmente precisam de Tier 3.

Aprofundamento Técnico

Escalonamento em cascata: o padrão dominante em produção

Na prática de arquiteturas maduras, o padrão mais comum não é "classificar e rotear uma vez", mas escalonamento em cascata: sempre tentar primeiro no tier mais barato capaz de, estatisticamente, resolver a maioria das tarefas do fluxo, e escalar apenas quando há sinal concreto de insuficiência.

função processar_tarefa(tarefa):
    resposta = chamar(tier=1, tarefa)
    se confianca(resposta) >= limiar_aceitavel E valida(resposta):
        retornar resposta   # ~70-80% dos casos, no fluxo bem calibrado

    resposta = chamar(tier=2, tarefa)
    se confianca(resposta) >= limiar_aceitavel E valida(resposta):
        retornar resposta   # ~15-25% dos casos

    resposta = chamar(tier=3, tarefa)
    retornar resposta        # ~5% dos casos — os realmente complexos
    # se falhar mesmo aqui, escalar para revisão humana (HITL,
    # Capítulo 1.3), não insistir infinitamente no tier máximo

O custo total desse padrão em cascata precisa ser comparado com cuidado contra o custo de rotear direto para o tier certo (quando o classificador consegue prever com boa precisão): a cascata paga o custo da(s) tentativa(s) que falham antes de escalar. Em fluxos de altíssimo volume, mesmo esse custo "desperdiçado" nas tentativas de tier baixo costuma ser menor do que rotear tudo direto para Tier 3 — porque a fração de tarefas que realmente precisa de Tier 3 tende a ser pequena.

O custo dos dois tipos de erro de roteamento

Um roteador mal calibrado erra de duas formas, com consequências econômicas assimétricas — e é essa assimetria que deve orientar onde colocar a margem de segurança do classificador.

Um roteador mal calibrado erra de duas formas, com consequências econômicas assimétricas:

Subdimensionamento (tarefa complexa vai para tier barato demais)

• Resposta de baixa qualidade ou incorreta, gerando retrabalho humano, ou pior, decisão errada tomada com base na resposta.
• Custo real = custo do token barato + custo de retrabalho/correção + custo de risco de decisão errada.

Sobredimensionamento (tarefa simples vai para tier caro demais)

• Custo e latência desperdiçados, sem ganho de qualidade percebido pelo usuário.
• Custo real = custo do token caro (sem componente de retrabalho, mas sem economia proporcional).

Subdimensionamento tende a ser mais caro no agregado do que sobredimensionamento, porque carrega um custo de risco além do custo de token — uma resposta errada em um fluxo de decisão de negócio pode custar ordens de magnitude mais do que a diferença de preço entre tiers. Por isso, roteadores maduros calibram o limiar de confiança de forma assimétrica: é aceitável escalar "na dúvida" com mais frequência do que o estritamente necessário, porque o custo de escalar sem necessidade é previsível e pequeno, enquanto o custo de não escalar quando necessário é variável e potencialmente grande.

Deriva de calibração: por que um roteador não é "configure e esqueça"

A calibração inicial de um roteador — os limiares de confiança, as regras de classificação de complexidade — reflete a distribuição de tarefas observada no momento em que foi desenhada. Essa distribuição muda: um fluxo de negócio evolui, novos tipos de tarefa entram no mesmo endpoint, usuários descobrem casos de uso que ninguém previu. Sem revisão periódica, o roteador degrada silenciosamente — continua funcionando, mas cada vez mais desalinhado com a realidade que deveria classificar.

Sintoma de deriva de calibração (observável via telemetria, Cap. 5.2):

Mês 1: taxa de escalonamento Tier1 → Tier2 = 18%
Mês 2: taxa de escalonamento Tier1 → Tier2 = 19%
Mês 3: taxa de escalonamento Tier1 → Tier2 = 34%  ← alerta

Hipóteses a investigar, em ordem de probabilidade:
  1. O perfil de tarefas mudou (novo tipo de uso do fluxo)
  2. O classificador de complexidade ficou desatualizado
     em relação ao vocabulário/formato das tarefas recentes
  3. O modelo do Tier 1 teve uma atualização de versão pelo
     fornecedor, e a taxa de confiança reportada mudou de
     comportamento sem que o limiar tenha sido recalibrado

A prática recomendada é tratar os limiares do roteador como um artefato de configuração com dono e ciclo de revisão — por exemplo, revisão trimestral com base na taxa de escalonamento observada — em vez de uma constante fixada uma vez no código e nunca mais revisitada. Isso é particularmente crítico quando o fornecedor do modelo em qualquer tier lança uma nova versão: o comportamento de confiança e a distribuição de acertos podem mudar mesmo que a interface da API permaneça idêntica.

Governança do roteador: quem decide os critérios

Um roteador dinâmico é, na prática, um ponto de política de negócio embutido em código — decide, silenciosamente, quanto orçamento cada tipo de tarefa recebe. Isso exige governança explícita, não apenas engenharia:

Perguntas de governança que o arquiteto precisa responder
antes de colocar um roteador em produção:

- Quem aprova os limiares de escalonamento (confiança mínima,
  tamanho de input, palavras-chave de complexidade)?
- Os critérios de roteamento são auditáveis — dá para reconstruir,
  para uma tarefa específica, por que ela foi para o Tier 2 e não
  o Tier 3? (telemetria do Capítulo 5.2 precisa registrar isso)
- Existe um teto de custo por fluxo/dia que força o roteador a
  degradar (Capítulo 6.1 trata isso como fallback routing de
  segurança, não só de custo)?
- Mudanças no classificador de complexidade passam por revisão,
  como qualquer outra mudança de lógica de negócio crítica?

Tratar o roteador como "só um detalhe de infraestrutura" é o erro mais comum de arquitetos que o desenham bem tecnicamente, mas o entregam sem trilha de auditoria. Quando uma decisão de negócio de alto impacto foi tomada com base numa resposta de Tier 1 que deveria ter escalado, a primeira pergunta será "por que o roteador não escalou" — e a resposta precisa estar na telemetria, não na memória de quem escreveu o código.