Roteamento de modelos: modelo certo para cada tarefa

A intuição de padronizar tudo num modelo forte parece simplicidade, mas é a decisão que mais infla a fatura de um sistema com LLM. A maioria das requisições de um produto real não é raciocínio complexo: é classificação de intenção, extração de campo, reformulação de texto, resposta curta de FAQ, roteamento de fila. Essas tarefas são resolvidas com folga por um modelo pequeno e barato, e mandá-las para o modelo topo de linha é pagar preço de raciocínio profundo por trabalho de rotina. O inverso também custa caro: padronizar tudo no modelo barato entrega resposta pobre nas poucas tarefas que exigem raciocínio, e o custo aparece disfarçado de retrabalho, de reclamação e de tarefa refeita à mão.

O ponto central é que a distribuição de dificuldade das requisições é desigual: um punhado de tarefas difíceis e uma multidão de tarefas triviais. A tabela abaixo mostra por que a escolha de um modelo único, seja ele forte ou fraco, deixa dinheiro ou qualidade na mesa.

O roteamento não é sobre usar o modelo mais barato sempre, é sobre usar o modelo mais barato que ainda resolve aquela tarefa. Quando a maioria das requisições é trivial, mover essa maioria para um modelo dez vezes mais barato corta a fatura de forma expressiva, enquanto as poucas tarefas difíceis continuam recebendo o modelo forte. O ganho vem da distribuição: você não baixa a qualidade média, você para de pagar preço de raciocínio por trabalho de rotina.

O coração do roteador é a classificação: antes de escolher o modelo, ele precisa saber que tipo de tarefa está diante dele. Três eixos bastam para decidir bem. O primeiro é a complexidade: a tarefa é padrão (classificar, extrair, reformular) ou exige raciocínio de várias etapas, síntese ou julgamento. O segundo é o risco: um erro na resposta é um incômodo tolerável ou uma falha cara (dado financeiro, jurídico, médico). O terceiro é o custo aceitável: quanto aquela tarefa pode gastar por chamada dado o valor que ela gera. Uma classificação de fila que roda milhões de vezes ao dia tem orçamento por chamada minúsculo; uma análise de contrato que roda dez vezes ao dia tolera pagar caro.

A classificação em si pode ser barata. Muitas vezes a própria natureza do endpoint já define a classe (o endpoint de "classificar intenção" é sempre trivial, o de "analisar documento" é sempre complexo), e nesse caso o roteamento é uma tabela estática, sem custo de inferência. Quando o mesmo endpoint recebe tarefas de dificuldade variável, um classificador leve (um modelo pequeno ou até heurística de tamanho e palavras-chave) decide a rota. A regra é não gastar mais para classificar do que se economiza roteando.

// router/classify.js
// Classifica a tarefa antes de escolher o modelo.
// Barato de proposito: a classificacao nao pode custar mais do que economiza.

export function classifyTask(req) {
  // Muitas vezes a rota ja esta implicita no tipo do endpoint.
  if (req.kind === 'intent' || req.kind === 'extract') {
    return { tier: 'small', reason: 'tarefa padrao de rotina' };
  }
  if (req.kind === 'analysis' || req.kind === 'reasoning') {
    return { tier: 'large', reason: 'exige raciocinio de varias etapas' };
  }

  // Quando o mesmo endpoint recebe dificuldade variavel, uma heuristica leve
  // (tamanho, palavras-chave) escolhe a rota sem custo de inferencia.
  const long = (req.text || '').length > 2000;
  const sensitive = req.risk === 'high';
  if (long || sensitive) return { tier: 'large', reason: 'entrada longa ou risco alto' };

  return { tier: 'small', reason: 'padrao' };
}

Repare que a classificação é conservadora no que importa: risco alto e entrada longa já empurram para o modelo forte, mesmo sem certeza de que a tarefa é difícil. Errar mandando uma tarefa trivial para o modelo forte custa alguns centavos; errar mandando uma tarefa crítica para o modelo fraco custa uma resposta errada num contexto sensível. O roteador deve errar sempre para o lado seguro, e é o fallback da próxima seção que corrige o outro tipo de erro sem exigir classificação perfeita.

Nenhum classificador acerta sempre, e exigir classificação perfeita torna o roteador frágil. A saída elegante é o fallback: mande a tarefa para o modelo barato primeiro, valide a resposta e, se ela não passar na validação, escale para o modelo forte. Assim o roteador não precisa prever de antemão toda tarefa difícil; ele tenta o barato, e só paga o caro quando o barato prova que não deu conta. O fluxo abaixo mostra o caminho completo de uma requisição, da classificação ao fallback.

Caminho de uma requisição pelo roteador de modelos

  requisição
        |
        v
  classifica a tarefa (complexidade, risco, custo)
        |
        v
  [ tier? ]
     |  small                   |  large
     v                          v
  chama modelo barato       chama modelo forte
        |                       |
        v                       v
  [ resposta válida? ]      devolve resposta
     |  sim      |  não
     v           v
  devolve     FALLBACK: chama modelo forte
                  |
                  v
              devolve resposta forte

  maioria trivial resolve no barato = economia
  minoria difícil escala no fallback = qualidade

// router/route.js
// Roteia para o modelo mais barato que resolve. Se o barato falhar
// na validacao, escala para o forte. Fallback corrige erro de classificacao.

export function createRouter({ callSmall, callLarge, validate }) {
  return async function route(req) {
    const { tier } = classifyTask(req);

    if (tier === 'large') {
      // Tarefa ja classificada como dificil: vai direto ao modelo forte.
      return { answer: await callLarge(req), model: 'large', escalated: false };
    }

    // Tenta o modelo barato primeiro.
    const small = await callSmall(req);
    if (validate(small, req)) {
      return { answer: small, model: 'small', escalated: false };
    }

    // Barato nao passou na validacao: escala para o forte (fallback).
    const large = await callLarge(req);
    return { answer: large, model: 'large', escalated: true };
  };
}

O detalhe que faz o fallback funcionar é a validação: ela precisa detectar de forma barata quando o modelo barato entregou uma resposta ruim. Para tarefas estruturadas isso é objetivo (o JSON não bate no schema, o campo esperado veio vazio, a classificação caiu fora do conjunto de rótulos válidos). Para tarefas abertas é mais sutil, e às vezes vale um segundo modelo pequeno como juiz. A chave é que o fallback só compensa se a taxa de escalonamento for baixa: se metade das tarefas triviais falha e escala, você paga o barato e o caro, e teria sido melhor mandar tudo para o forte. Monitorar essa taxa é o que a seção de métricas cobre.

O roteamento só é uma decisão informada se você tiver o custo de cada modelo por tipo de tarefa na frente. Sem essa tabela, "modelo barato" e "modelo forte" são rótulos vagos, e a escolha vira palpite. Com ela, o roteamento vira aritmética: você sabe quanto custa cada rota, qual a fração de tráfego que cai em cada uma e quanto o roteamento economiza frente ao cenário de modelo único. A tabela abaixo é o formato mínimo dessa análise, com números ilustrativos para mostrar a estrutura da decisão.

A leitura dessa tabela é o argumento inteiro do roteamento. As tarefas mais caras por chamada (análise de documento, raciocínio) são justamente as de menor volume; as de maior volume (classificar, extrair) são as mais baratas por chamada. Quando você multiplica custo por volume, a conta do modelo único fica dominada pelo custo de rodar o forte no trivial de alto volume. O roteamento quebra essa multiplicação: o alto volume passa a rodar barato, e o custo do forte fica confinado ao baixo volume onde ele é necessário. Sem essa tabela você não sabe se o roteamento vale o esforço; com ela, o ganho é calculável antes de escrever a primeira linha.

O risco do roteamento não é técnico, é de qualidade: mandar uma tarefa que precisava do modelo forte para o barato e servir uma resposta pior sem ninguém perceber. A defesa contra isso é dupla. A primeira camada é a classificação conservadora, que já vimos: na dúvida, sobe de tier. A segunda é a validação da resposta do modelo barato, que transforma o fallback numa rede de segurança. Juntas, elas garantem que a economia não vem às custas de qualidade nas tarefas que importam.

1. Valide estrutura sempre que possível: se a tarefa espera JSON, um rótulo de um conjunto fechado ou um campo específico, a validação é objetiva e barata, e o fallback dispara sozinho quando o barato erra o formato.
2. Use um juiz leve para tarefas abertas: quando não há estrutura, um modelo pequeno pode pontuar a resposta do barato (completa? no tópico? sem recusa indevida?) e decidir se escala, ainda mais barato que rodar o forte direto.
3. Trave tarefas de risco alto fora do modelo barato: cobrança, jurídico, saúde e qualquer coisa cara de errar devem ir direto ao forte, sem passar pela tentativa barata, porque ali o custo de um erro supera a economia.
4. Limite a profundidade do fallback: uma tentativa barata e uma escalada bastam; não encadeie três modelos, senão o pior caso paga todos e a latência explode.

A regra que amarra tudo: o roteador economiza no caso comum e protege no caso raro. O caso comum (tarefa trivial de alto volume) roda barato e passa na validação, e é dali que vem a economia. O caso raro (tarefa difícil ou classificada errado) é capturado pela validação e escalado pelo fallback, e é dali que vem a garantia de qualidade. Um roteador sem validação é só uma aposta de que a classificação nunca erra, e classificação sempre erra em algum ponto. A validação é o que transforma o roteamento de aposta em engenharia.

Um roteador sem métrica é uma promessa de economia que ninguém checou. Quatro sinais dizem se ele está entregando. A economia real compara o custo com roteamento contra o custo hipotético de rodar tudo no modelo forte, e é a justificativa da camada. A taxa de escalonamento mede quantas tarefas que foram para o barato acabaram escalando para o forte: se ela é alta, o barato está falhando demais e o roteamento paga duas vezes. A distribuição por tier mostra quanto do tráfego cai em cada modelo e confirma se a classificação está enviando a maioria para o barato como esperado. E a qualidade por rota, medida por amostragem, verifica se as respostas servidas pelo barato não estão piores do que as do forte.

A taxa de escalonamento é a métrica que denuncia um roteador mal calibrado, porque ela captura o pior cenário: pagar o barato e o caro na mesma requisição. Escalonamento alto significa que a classificação está otimista demais, mandando para o barato tarefas que ele não resolve, e a correção é subir o tier de origem dessas classes de tarefa em vez de confiar no fallback. Já uma distribuição concentrada no forte indica o oposto, uma classificação conservadora demais que anula a economia. O ponto de operação saudável é a maioria do tráfego no barato, escalonamento baixo e qualidade por rota indistinguível entre barato e forte nas tarefas que o barato atende. É esse equilíbrio que o roteamento persegue.

O roteamento de modelos é uma das otimizações de melhor retorno num sistema com LLM: mexe direto no maior item de custo (a chamada ao modelo) sem tocar na experiência do usuário quando bem feito. Mas é uma otimização de qualidade sensível, então a ordem de implantação importa: comece protegendo a qualidade e afrouxe a economia com dado na mão.

1. Comece pela tabela de custo por tarefa: sem saber o custo e o volume de cada tipo, você não sabe se o roteamento vale nem quais tarefas mover primeiro. Priorize as de alto volume e baixa complexidade.
2. Roteie primeiro o que é obviamente trivial: classificação, extração e FAQ curta são seguros de mandar para o barato desde o dia um, e já entregam a maior fatia da economia.
3. Ligue o fallback com validação antes de descer mais: só depois de ter a rede de segurança do fallback funcionando é seguro mover tarefas de dificuldade duvidosa para o barato.
4. Instrumente as quatro métricas: economia real, escalonamento, distribuição por tier e qualidade por rota. Sem elas você não sabe se economizou ou degradou.
5. Mantenha risco alto fora do roteamento barato: tarefas caras de errar vão direto ao forte, sempre. A economia vem do volume trivial, não de arriscar o crítico.

A diferença entre um roteador que corta a fatura sem ninguém notar e um que degrada a qualidade no escuro está inteira na classificação conservadora, na validação com fallback e na métrica de escalonamento, não na esperteza do critério de escolha. O critério é simples: o modelo mais barato que ainda resolve. O que torna isso confiável em produção é a rede de segurança que captura os erros de classificação e a instrumentação que prova que a economia é real e a qualidade se manteve. Bem montado, o roteamento é dinheiro deixado na mesa por quem padroniza tudo no modelo forte, recuperado sem que o usuário perceba diferença nas respostas.