Roteamento de modelos por complexidade é a escolha automática do modelo que deve responder a cada solicitação, considerando a dificuldade prevista, o custo e a qualidade mínima exigida. Uma tarefa simples pode seguir para um modelo econômico; uma análise com várias restrições pode exigir outro modelo. A economia só existe quando a resposta continua útil e o custo do próprio roteador cabe na conta.
Comece comparando dois modelos em tarefas reais, com critérios de aprovação definidos antes do teste. Depois construa uma regra de escolha e avalie o sistema completo. Contar quantas solicitações foram enviadas ao modelo barato não demonstra economia: é preciso incluir respostas refeitas, verificações, chamadas adicionais e revisão humana.
Resumo rápido
- Complexidade depende da tarefa e das evidências necessárias, não apenas do tamanho do prompt.
- O objetivo é reduzir custo por resposta aprovada, respeitando qualidade e prazo.
- Compare roteamento antecipado e escalonamento após uma tentativa econômica.
- Use regras de elegibilidade antes do classificador para preservar requisitos de dados e ferramentas.
- Valide em português e por tipo de tarefa; uma média geral pode esconder regressões.
O que o roteador precisa decidir
O roteador recebe uma solicitação e escolhe entre alternativas autorizadas. Aqui, a decisão é sobre capacidade de resolver o problema com qualidade suficiente. Ela difere do roteamento por intenção em sistemas multiagentes, que encaminha tarefas para departamentos, agentes ou ferramentas conforme o assunto.
Uma mesma intenção pode conter dificuldades diferentes. Em suporte técnico, localizar o horário de atendimento é uma consulta simples; reconciliar instruções contraditórias de dois manuais exige interpretação. Em extração de dados, um documento curto com layout irregular pode ser mais difícil do que um documento longo e padronizado.
Também separe dificuldade de risco. Uma transformação textual trivial pode envolver dados que não podem seguir para determinado ambiente. Uma pergunta complexa pode ser apenas um rascunho interno de baixo impacto. Regras de acesso, residência de dados, modalidade e ferramentas devem filtrar os candidatos antes da comparação de custo.
Não é necessário começar com muitos modelos. Dois candidatos deixam o experimento mais fácil de interpretar: uma opção econômica e uma opção de referência que atende melhor aos casos difíceis no seu conjunto de avaliação. Esses papéis são locais ao projeto, não rankings universais de fornecedores.
Como estimar complexidade antes de gerar a resposta
Monte sinais observáveis. Quantas fontes precisam ser conciliadas? Há exigência de cálculo verificável? O pedido depende de contexto ausente? Existem regras de negócio conflitantes? A saída precisa seguir um esquema rígido? Esses sinais ajudam a construir categorias úteis, desde que sua relação com erros seja medida.
O comprimento do prompt pode entrar como uma característica, mas não deve determinar tudo. Uma instrução curta como “encontre a inconsistência” pode exigir leitura extensa do histórico. Uma entrada longa com campos repetitivos pode ser resolvida por um procedimento simples. Analise o pacote completo que o modelo receberá, incluindo documentos e resultados de busca.
Há três caminhos comuns: regras escritas pela equipe, um classificador treinado com exemplos e uma chamada a um modelo para classificar a dificuldade. O último é simples de prototipar, mas acrescenta tokens, latência e possibilidade de erro. Sua saída deve pertencer a categorias fechadas, com comportamento definido quando não for válida.
Em vez de pedir ao classificador “qual é o melhor modelo?”, forneça uma tarefa restrita: identificar características que foram relacionadas a falhas no histórico. A aplicação combina esses sinais com a política de roteamento. Isso permite mudar preços e candidatos sem reconstruir toda a classificação.
Se não houver dados suficientes para decidir, encaminhe para o caminho de referência ou peça esclarecimento. A política precisa conter uma opção explícita para incerteza. Forçar toda solicitação para uma classe conhecida cria confiança artificial justamente nos pedidos novos.
Roteamento antecipado ou tentativa com escalonamento
| Estratégia | Funcionamento | Custo a observar |
|---|---|---|
| Regras antecipadas | Selecionam o modelo antes da geração | Manutenção das regras e erros de classificação |
| Classificador antecipado | Estima dificuldade e escolhe o candidato | Inferência do classificador e latência adicional |
| Cascata | Tenta uma opção econômica e escala quando a validação falha | Duas gerações nos casos escalados e custo do verificador |
| Modelo único | Usa sempre a mesma opção elegível | Referência simples para medir se o roteamento compensa |
Na cascata, o desafio é reconhecer uma resposta inadequada. Um JSON inválido é fácil de detectar. Uma explicação plausível baseada em uma premissa errada exige outro tipo de verificação. Não basta perguntar ao mesmo modelo se ele está satisfeito com a resposta.
Comece com validações determinísticas: campos obrigatórios, referências existentes, valores dentro de limites e cálculo refeito por código. Para aspectos subjetivos, use revisão humana amostral e critérios explícitos. Um avaliador baseado em modelo pode ajudar, mas precisa ser calibrado contra julgamentos humanos, como discute o guia de avaliadores de qualidade em português.
Defina quando a tentativa econômica será descartada. Enviar uma resposta errada como contexto ao modelo seguinte pode induzir a repetição do erro. Dependendo da tarefa, é melhor gerar novamente a partir das evidências originais e usar o diagnóstico da validação apenas como informação estruturada.
Imponha um teto de tentativas e um prazo total. Se o caminho de referência também falhar, a aplicação deve apresentar a limitação ou encaminhar a revisão. Alternar modelos indefinidamente transforma a busca por economia em uma sequência cara e difícil de depurar.
Como calcular economia sem perder qualidade
Use como unidade o trabalho concluído e aprovado. O custo total inclui entradas, saídas, uso do roteador, verificadores, repetições e infraestrutura aplicável. Se houver cache ou categorias de cobrança diferentes, registre o consumo real retornado pelo serviço e aplique a tabela vigente do contrato.
Uma conta operacional é dividir o custo de todas as tentativas pelo número de solicitações aprovadas. Mantenha também a taxa de aprovação, porque um sistema que rejeita quase tudo pode distorcer a comparação. Para fluxos revisados, acompanhe minutos de trabalho humano separadamente, com uma forma consistente de atribuir custo.
Compare três alternativas no mesmo conjunto: somente o modelo econômico, somente a referência e a política proposta. O roteamento precisa justificar a complexidade adicional. Se a opção econômica já atende ao padrão em quase todos os casos, talvez o classificador não acrescente valor suficiente.
Separe dados de ajuste e de teste. Escolher o limiar e medir o resultado nos mesmos exemplos favorece decisões que não se repetem em produção. Inclua casos comuns, exceções, solicitações incompletas e variações de português presentes na operação. Preserve um conjunto que não foi usado na construção das regras.
A documentação de avaliações da OpenAI recomenda critérios específicos da tarefa, dados representativos e avaliação contínua. Aplique esse princípio ao sistema inteiro, não só aos modelos isolados. Registre resultados por classe de dificuldade, cliente, tamanho de contexto e modalidade, usando divisões relevantes para sua operação.
Observe o tempo até a resposta final, inclusive a cauda de solicitações mais lentas. Uma cascata pode melhorar o custo médio e piorar os casos urgentes. A política só deve ser aprovada se respeitar simultaneamente o piso de qualidade e o limite de tempo definidos para o produto.
Exemplo: software de atendimento em Campinas
Considere uma empresa fictícia de software para distribuidores em Campinas. O exemplo é ilustrativo, sem promessa de redução percentual. Seu assistente responde perguntas sobre procedimentos e prepara resumos de chamados para os atendentes.
A equipe seleciona pedidos históricos com dados minimizados e remove respostas finais que revelariam o resultado esperado. Dois revisores estabelecem critérios: fidelidade ao manual, ausência de informação inventada, identificação de contexto ausente e formato adequado. Divergências entre revisores são discutidas antes de avaliar o roteador.
Solicitações de resumo com informações explícitas seguem inicialmente para a opção econômica. Pedidos que combinam políticas de devolução, exceções comerciais e documentos contraditórios vão para a referência. Se a tarefa exige consultar um pedido, a autorização da ferramenta é verificada antes, independentemente da dificuldade textual.
No piloto, o roteador opera em modo de observação: registra sua escolha, mas a resposta oficial continua no caminho já aprovado. Uma amostra de solicitações também é executada no candidato alternativo. Essa duplicação temporária aumenta o custo do experimento, mas ajuda a verificar se a escolha faria sentido.
Depois, a equipe libera uma parcela controlada do tráfego e acompanha qualidade, tentativas adicionais e reclamações. Se os resumos econômicos omitirem condições relevantes, ajusta o recorte ou volta ao caminho anterior. O resultado esperado é uma decisão sustentada por dados locais, não a confirmação de que modelos menores sempre bastam.
Erros comuns
Confundir preço por token com custo da tarefa. Uma saída barata pode exigir mais tokens, mais chamadas ou mais revisão. Compare consumo e qualidade observados no fluxo completo. Consulte preços oficiais ao calcular o orçamento; não fixe uma projeção permanente baseada em uma captura antiga.
Importar um roteador sem testar português. A documentação do intelligent prompt routing do Amazon Bedrock informa otimização para prompts em inglês e limitações para adaptar decisões aos dados específicos da aplicação. Isso torna a avaliação local necessária antes de adotar o recurso para atendimento em português.
Tratar disponibilidade como universal. O mesmo recurso do Bedrock documenta restrições de famílias de modelos e regiões. A presença de um modelo no catálogo de um provedor não implica que ele esteja elegível para qualquer roteador. Verifique a combinação efetiva da conta e do ambiente de implantação.
Usar o mesmo limiar em toda a empresa. Um classificador pode distinguir bem tarefas de resumo e falhar em conciliação. Mantenha critérios por fluxo quando houver dados que sustentem a separação. Com poucos exemplos, prefira uma política conservadora a dezenas de exceções sem evidência.
Esquecer versões e mudanças de tráfego. Registre a versão da política, do prompt e dos candidatos. Mudanças de documentos, idioma ou público podem alterar a dificuldade das solicitações. Reavalie após essas mudanças e mantenha uma forma simples de retornar à política anterior.
Confundir o padrão arquitetural com um produto pronto. A Anthropic descreve roteamento como um padrão de fluxo que direciona entradas a caminhos especializados. Isso não valida automaticamente um classificador criado para sua aplicação. Para recursos do fornecedor, consulte também o catálogo de integrações do Claude.
Perguntas frequentes
Um prompt longo sempre exige um modelo maior?
Não. Comprimento é apenas um dos sinais. Estrutura, ambiguidades, ferramentas necessárias e necessidade de conciliar evidências podem ser mais relevantes. A capacidade exigida deve ser inferida a partir dos erros observados nas suas tarefas.
Preciso treinar um classificador próprio?
Não necessariamente. Regras simples podem ser suficientes para um piloto. Treinar um classificador passa a fazer sentido quando há exemplos rotulados e uma dificuldade de decisão que as regras não resolvem com qualidade e manutenção aceitáveis.
O modelo mais caro serve como resposta correta?
Não. Ele também pode errar. Use critérios externos, referências verificáveis e revisão humana quando necessário. A opção de referência é uma base de comparação operacional, e não uma fonte automática de verdade.
Como evitar que a economia desapareça com repetições?
Registre todas as tentativas por solicitação e inclua seus custos. Estabeleça um teto de escalonamento e monitore a frequência com que o caminho econômico precisa ser refeito. Se isso ocorrer frequentemente, ajuste a seleção antecipada ou mantenha um único modelo.
Quando devo desistir do roteamento?
Quando a diferença de custo não compensar classificação, manutenção, avaliações e risco de queda de qualidade. Um modelo único bem configurado pode ser a opção mais eficiente. O experimento deve permitir essa conclusão, em vez de assumir que múltiplos modelos são obrigatórios.
