Guia prático de escolha de modelo por tarefa

O melhor modelo não é automaticamente o maior. É o mais simples que passa nos critérios reais da tarefa com qualidade, latência, risco e custo aceitáveis.

Quando um novo modelo é lançado, a primeira pergunta costuma ser se ele é melhor do que os anteriores. Essa pergunta ajuda a entender o mercado, mas ajuda pouco na hora de construir uma funcionalidade.

Um modelo pode se destacar em raciocínio complexo e ser desnecessário para classificar mensagens. Outro pode ser rápido e barato, mas falhar demais em uma extração com formato rígido. Um terceiro pode produzir bom texto e ainda não oferecer a modalidade, a ferramenta ou a política de dados que o fluxo exige.

Por isso, venho usando uma pergunta mais prática: qual é o modelo mais simples que atende aos critérios desta tarefa com qualidade aceitável? Essa mudança tira a decisão do ranking genérico e aproxima o teste do produto real.

Comece pela tarefa, não pelo catálogo

`Usar IA para atendimento` é amplo. `Classificar mensagens em cinco categorias e devolver JSON válido` já permite definir entrada, saída, erro e consequência. Antes de comparar modelos, a tarefa precisa caber em uma frase específica.

• Quem ou qual sistema envia a entrada?
• Qual contexto está disponível e qual é realmente necessário?
• Qual saída é esperada e como será usada?
• Quais erros são toleráveis e quais invalidam a execução?
• Qual é o risco de uma resposta incorreta?
• Quanto tempo e custo o fluxo admite?

Também vale separar tarefas que parecem uma só. Buscar documentos, selecionar trechos, gerar uma resposta, validar formato e executar uma ação exigem capacidades e controles diferentes. Usar um único modelo em tudo pode ser a linha de base, mas não precisa ser uma hipótese permanente.

Transforme qualidade em critérios observáveis

`A resposta ficou boa` é uma impressão. Para comparar modelos, eu escreveria critérios que duas pessoas consigam aplicar de forma parecida. Em uma extração estruturada, por exemplo:

• Todos os campos obrigatórios estão presentes.
• Datas e valores usam o formato esperado.
• Informação ausente é marcada como ausente, não inventada.
• O JSON passa no schema definido pelo produto.
• Campos críticos apontam para a origem quando necessário.

Nem todos os critérios têm o mesmo peso. Um erro de estilo pode admitir correção automática; um valor financeiro inventado pode invalidar a execução inteira. Registrar gravidade evita que uma média esconda falhas críticas.

Monte um conjunto pequeno e representativo

Não é necessário começar com centenas de exemplos. Um conjunto inicial pequeno já é melhor do que um único prompt feliz, desde que represente a distribuição e os riscos da tarefa.

• Casos comuns e representativos.
• Entradas incompletas ou ruidosas.
• Formatos inesperados, mas válidos.
• Contexto longo e casos conhecidos por causar erro.
• Situações que exigem recusa, confirmação ou revisão humana.
• Pelo menos um caso em que a informação não existe.

Os casos precisam proteger dados sensíveis. Quando exemplos reais não podem ser usados, versões sintéticas devem preservar a estrutura do problema sem copiar conteúdo privado. A mesma versão de prompt, configuração, schema e ferramentas precisa ser executada nos candidatos para que a comparação faça sentido.

Crie uma linha de base antes de sofisticar

Eu começaria com um único modelo, prompt versionado, configuração explícita e validação de saída. O objetivo é descobrir onde o fluxo realmente falha. Sem linha de base, é fácil adicionar roteamento, fallback e vários provedores antes de saber se o problema está no modelo.

Às vezes, selecionar melhor o contexto, tornar o schema mais claro ou corrigir a recuperação dos documentos produz mais ganho do que trocar de modelo. A linha de base também permite identificar regressões quando uma opção melhora casos comuns e piora justamente os casos críticos.

Compare o custo da tarefa concluída

Preço por token é uma entrada, não a decisão completa. Um modelo mais barato pode sair caro se exige várias tentativas. Um modelo mais capaz pode ser desperdício se uma opção menor já passa nos critérios.

• Tokens de entrada, saída e raciocínio quando aplicável.
• Chamadas de ferramentas e recuperação de contexto.
• Retries por formato inválido, timeout ou falha transitória.
• Segunda chamada para corrigir uma saída.
• Revisão humana e tratamento de exceções.
• Infraestrutura de cache, fallback e observabilidade.

A métrica mais útil costuma ser custo por tarefa concluída com qualidade aceitável, não custo por chamada isolada.

Latência precisa ser medida no fluxo completo

Uma execução rápida não descreve a experiência inteira. Vale observar tempo até o primeiro feedback útil, duração total, ferramentas externas, retries, validação e percentis mais altos. Para uma sugestão interativa, alguns segundos extras podem interromper o fluxo; para um relatório em background, previsibilidade pode importar mais.

Streaming pode melhorar a percepção, mas não reduz a duração da tarefa e pode não servir para uma saída que precisa ser validada por inteiro antes de aparecer.

Capacidades precisam ser testadas como contratos

Uma lista de funcionalidades declaradas não garante que a integração funcione no seu caso. Saída estruturada exige schemas reais; ferramentas exigem teste de escolha, argumentos, confirmação e recuperação; imagens, áudio e documentos exigem amostras representativas.

• Tamanho de contexto realmente necessário.
• Qualidade em português e nos idiomas do produto.
• Consistência no seguimento de instruções.
• Disponibilidade, limites de taxa e regiões.
• Retenção, privacidade e política de dados.
• Suporte a lote, cache ou execução assíncrona.
• Facilidade de observação e versionamento.

Modelo único, fallback ou roteamento

Um modelo padrão

É a opção mais simples de operar. Faz sentido quando um modelo atende à maior parte dos casos dentro do orçamento e não existe requisito forte de redundância.

Um modelo padrão com fallback

Fallback pode ajudar em indisponibilidade ou limite de capacidade, mas precisa obedecer ao mesmo contrato. Trocar silenciosamente para um modelo que interpreta schemas ou ferramentas de outra forma pode transformar disponibilidade em erro funcional.

Roteamento por tarefa ou dificuldade

Roteamento pode enviar classificações simples para uma opção menor e casos complexos para outra mais capaz. O ganho só existe quando a decisão de rota é confiável, o custo de manutenção é aceitável e a observabilidade explica por que cada caminho foi escolhido. Esse tema merece um guia próprio; aqui, o ponto é não adicionar o router antes de medir a linha de base.

Exemplo hipotético com três perfis

Considere um exemplo fictício de extração de cinco campos para JSON validado. O conjunto tem 50 documentos sintéticos representativos, com imagens ruins, campos ausentes e formatos diferentes. O critério exige schema válido, nenhuma invenção em campos ausentes e acerto acima do limite definido para campos críticos.

• Perfil rápido: menor custo e latência, aprovado apenas se atingir a qualidade mínima.
• Perfil equilibrado: maior consistência em entradas variadas.
• Perfil avançado: reservado para documentos ambíguos ou de maior risco.

Se o perfil rápido passa nos casos simples e falha nos ambíguos, o sistema pode usar o equilibrado como padrão, melhorar a preparação do documento, escalar apenas casos com um sinal confiável ou pedir revisão humana. A decisão vem da taxa de sucesso, dos tipos de falha, da latência e do custo total, não do nome do perfil.

Registre e revise a decisão

Modelos mudam, prompts evoluem, preços e limites variam e o conjunto de entradas cresce. Uma escolha não deve existir apenas na memória da equipe.

• Tarefa e versão do contrato.
• Modelos e configurações testados.
• Versões de prompt, schema e ferramentas.
• Conjunto de evals, critérios e pesos.
• Resultados de qualidade, latência e custo.
• Motivo da escolha e gatilho para nova avaliação.

Checklist de escolha

1. A tarefa está específica o suficiente para ser testada?
2. A saída esperada e os erros críticos estão definidos?
3. Existem casos comuns, limites e adversos?
4. Há uma linha de base simples?
5. Qualidade, latência e custo são medidos no mesmo fluxo?
6. Formato, ferramentas e modalidades foram testados como contrato?
7. Privacidade, região, retenção e disponibilidade atendem ao produto?
8. O custo inclui retries, validação e revisão?
9. Fallback ou roteamento resolvem um problema medido?
10. A decisão está versionada e tem data de revisão?

Limites e conclusão

Um conjunto de evals nunca representa todas as entradas futuras. Avaliações automáticas também falham, principalmente em critérios subjetivos. Julgadores baseados em modelos precisam ser calibrados contra exemplos avaliados por pessoas, e casos de maior risco continuam pedindo revisão humana e monitoramento.

Benchmarks públicos ajudam a formar hipóteses, mas não substituem o teste da tarefa. Quando critérios e casos estão claros, o modelo mais capaz continua valioso onde a complexidade exige e o modelo menor continua valioso onde já entrega qualidade suficiente. A escolha deixa de ser preferência e vira uma decisão verificável.