Como escolher o modelo certo para a tarefa (e para o orçamento)

Um modelo mental útil: primeiro o tipo de tarefa, depois o modelo

Na prática, classifico as cargas de trabalho de LLMs em cinco eixos antes mesmo de olhar os nomes dos modelos:

A escolha do modelo fica muito mais fácil quando você para de perguntar “qual modelo é o mais inteligente?” e começa a perguntar “qual modo de falha estou pagando para reduzir?”.

Por exemplo:

• Um sumarizador de solicitações de redefinição de senha precisa de consistência e baixo custo.
• Um assistente de migração de código precisa de raciocínio e uso de ferramentas.
• Uma ferramenta de comparação de contratos precisa de contexto longo, mas também de atribuição cuidadosa.
• Um agente voltado ao cliente precisa mais de previsibilidade de latência do que de desempenho máximo em benchmarks.
• Um pipeline de enriquecimento em lote pode priorizar o volume processado por dólar em vez da elegância da resposta.

Muitas vezes, o modelo errado não é tecnicamente inadequado. Ele é economicamente inadequado.

Uma escala prática de modelos

Esta é a escala que uso na maioria dos sistemas de produção.

Modelos da classe Haiku: a escolha padrão para tarefas de linguagem rápidas e baratas

Os modelos da classe Haiku são excelentes para uma primeira etapa de processamento. Eu os uso em tarefas nas quais a resposta é curta, a entrada é limpa e o formato da saída é restrito.

Bons casos de uso:

• Marcação de chamados
• Resumos curtos
• Classificação de sentimento
• Normalização de assuntos de e-mail
• Correspondência com perguntas frequentes
• Extração simples de JSON
• Pré-filtros de moderação de baixo risco

Exemplo de prompt para um classificador econômico de primeira etapa:

{
  "model": "claude-haiku-4.5",
  "temperature": 0,
  "max_tokens": 120,
  "response_format": { "type": "json" },
  "messages": [
    {
      "role": "system",
      "content": "Classify the support ticket. Return only valid JSON."
    },
    {
      "role": "user",
      "content": "Subject: Refund not received\nBody: I canceled two weeks ago and still see a charge."
    }
  ]
}

Saída esperada:

{
  "category": "billing",
  "urgency": "medium",
  "needs_human": true,
  "reason": "Refund dispute involving payment status"
}

Uma armadilha comum: as equipes pedem a modelos econômicos que raciocinem e formatem perfeitamente em uma única tentativa. Se o modelo às vezes gerar JSON inválido, não passe imediatamente para o Opus. Primeiro, delimite melhor a tarefa:

• Defina temperature: 0
• Use um esquema JSON ou uma chamada de ferramenta
• Reduza o escopo das instruções
• Separe a classificação da explicação
• Valide a saída e tente novamente uma vez

Para muitas tarefas em produção, uma nova tentativa com um modelo da classe Haiku ainda é mais barata e rápida do que usar por padrão um modelo de raciocínio de ponta.

Modelos da classe Sonnet: a base para a lógica real do produto

Os modelos da classe Sonnet costumam ser minha escolha para funcionalidades interativas de produtos. São suficientemente capazes para raciocinar, estáveis para usar ferramentas e, em geral, rápidos para fluxos voltados ao usuário.

Bons casos de uso:

• Redação de respostas de suporte ao cliente
• Fluxos de trabalho com agentes e ferramentas
• Explicação de código e refatoração leve
• Perguntas e respostas sobre documentos em várias etapas
• Fluxos de trabalho com copilotos para vendas ou sucesso do cliente
• Extração estruturada a partir de entradas desorganizadas

Na prática, o Sonnet costuma ser a melhor escolha para quem não quer pensar demais no roteamento. Se você só puder integrar uma categoria de modelos a uma nova funcionalidade, comece por aqui.

Exemplo: um agente de suporte que pode consultar um pedido, uma política e chamados anteriores.

SYSTEM = """
You are a support resolution assistant.
Use tools before making claims about orders, refunds, or account state.
If policy is ambiguous, say what is ambiguous and escalate.
Return:
- summary
- recommended_action
- customer_reply
- escalate: true/false
"""

request = {
    "model": "claude-sonnet-4.6",
    "temperature": 0.2,
    "max_tokens": 900,
    "tools": [
        {"name": "get_order", "description": "Fetch order state"},
        {"name": "get_refund_policy", "description": "Fetch current refund rules"},
        {"name": "search_prior_tickets", "description": "Search customer history"}
    ],
    "messages": [
        {"role": "system", "content": SYSTEM},
        {"role": "user", "content": "Customer says they returned item A but were charged again."}
    ]
}

O que realmente acontece quando você executa esse tipo de fluxo de trabalho em produção: a maioria das falhas não ocorre porque “o modelo é burro”. São falhas de integração.

• A ferramenta retorna um estado desatualizado.
• O modelo recebe contexto irrelevante demais.
• O documento de política contém trechos contraditórios.
• O agente pode continuar após uma chamada de ferramenta malsucedida.
• O prompt pede tanto uma análise interna quanto um texto pronto para o cliente, sem separá-los.

Um modelo da classe Sonnet oferece inteligência suficiente para contornar certa desorganização, mas não elimina a necessidade de contratos de ferramentas bem definidos.

Modelos da classe Opus: caros, mas às vezes mais baratos do que os erros

Os modelos da classe Opus são indicados para tarefas em que o custo de uma resposta ruim supera o custo da inferência.

Recorro ao Opus quando:

• A entrada é ambígua e envolve riscos elevados
• Há muitas restrições que interagem entre si
• O usuário espera um raciocínio aprofundado
• A tarefa envolve escolhas e concessões relacionadas a código, políticas ou arquitetura
• Uma tentativa malsucedida com um modelo econômico desperdiçaria tempo de pessoas

Exemplos:

• Revisar um plano de migração de banco de dados
• Analisar a cronologia de um incidente em produção
• Gerar uma comparação complexa de políticas jurídicas para revisão humana
• Depurar uma falha de agente que envolve vários serviços
• Avaliar se uma ação automatizada é segura

Não uso o Opus para toda tarefa “importante”. Importância e dificuldade são coisas diferentes. Um milhão de chamados de redefinição de senha são importantes para os usuários, mas não são difíceis individualmente. Uma única migração que envolva uma exclusão sutil de dados pode ser importante e difícil ao mesmo tempo.

Um padrão útil é “escalonar em caso de incerteza”:

def choose_model(task):
    if task["context_tokens"] > 700_000:
        return "fable-5"

    if task["risk"] == "high" and task["requires_reasoning"]:
        return "claude-opus-4.8"

    if task["requires_tools"] or task["multi_step"]:
        return "claude-sonnet-4.6"

    return "claude-haiku-4.5"

Isso é intencionalmente simples. O roteador deve ser simples o suficiente para que sua equipe consiga depurá-lo às 2 da manhã.

Fable 5 e contexto de 1M: use quando a recuperação de informações for o problema

Modelos de contexto longo são tentadores porque eliminam boa parte do trabalho de engenharia de recuperação de informações. A janela de contexto de 1M do Fable 5 muda o que você pode tentar diretamente: revisão de documentos inteiros, síntese de transcrições enormes, inspeção de grandes repositórios e análise de políticas em vários arquivos.

Mas contexto longo não faz mágica.

Uma janela de 1M tokens ajuda quando a parte difícil é “o fato relevante pode estar em qualquer lugar”. Ela não garante que o modelo raciocinará perfeitamente sobre todo o milhão de tokens, nem torna gratuito o contexto irrelevante. Prompts longos ainda custam dinheiro, aumentam a latência e podem diluir a atenção.

Uso contexto longo no estilo do Fable quando:

• O corpus é interconectado demais para uma divisão ingênua em blocos
• Deixar passar um detalhe é pior do que pagar por contexto adicional
• O usuário pode tolerar respostas mais lentas
• A tarefa se beneficia do acesso ao material bruto ao redor

Exemplo de arquitetura para revisão de documentos extensos:

User request
  -> lightweight classifier
  -> retrieve obvious relevant sections
  -> if confidence high: Sonnet answer with citations/quotes from chunks
  -> if confidence low or query is global: Fable 5 over full document set
  -> optional Opus review for high-risk final answer

Essa abordagem híbrida funciona melhor do que “sempre colocar tudo no contexto”. Na prática, os modelos de contexto longo são mais valiosos como alternativa quando a confiança na recuperação de informações é baixa.

Modelos com pesos abertos: controle, custo e capacidade de processamento

Modelos com pesos abertos, como Llama, Qwen, DeepSeek, MiniMax e Kimi, não são apenas “alternativas mais baratas”. São escolhas operacionais.

Eles fazem sentido quando você precisa de:

• Implantação local ou em VPC
• Custo previsível para processamento em lote de alto volume
• Ajuste fino ou destilação
• Otimizações personalizadas de inferência
• Controle sobre a residência dos dados
• Custo marginal extremamente baixo após a configuração

Eles são especialmente bons para tarefas específicas e repetitivas. Por exemplo, uma variante de Qwen ou Llama servida pelo vLLM pode realizar classificação, extração e enriquecimento interno com alta capacidade de processamento, desde que você controle o tamanho do prompt e o formato da saída.

Exemplo de configuração para disponibilização local:

vllm serve Qwen/Qwen3-14B \
  --host 0.0.0.0 \
  --port 8000 \
  --tensor-parallel-size 2 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.90

Depois, faça a chamada por meio de um cliente compatível com a OpenAI:

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8000/v1",
    api_key="local"
)

result = client.chat.completions.create(
    model="Qwen/Qwen3-14B",
    temperature=0,
    messages=[
        {"role": "system", "content": "Return valid JSON only."},
        {"role": "user", "content": "Classify: user cannot access invoice PDF"}
    ]
)

A contrapartida é assumir a responsabilidade pela engenharia. Com modelos de ponta hospedados, outra pessoa cuida da capacidade, das atualizações, das escolhas de quantização e do trabalho de desempenho no nível do kernel. Com modelos abertos, isso passa a ser sua responsabilidade.

Modelos com pesos abertos são uma ótima opção quando a carga de trabalho é estável. São menos adequados quando o produto muda semanalmente e a qualidade dos prompts importa mais do que o custo bruto de disponibilização do modelo.

Roteamento com prioridade para modelos econômicos e escalonamento

Um bom roteador não é um ranking. É um sistema de controle de risco.

Aqui está um padrão adequado para produção:

1. Tente o modelo mais barato que, em princípio, seja capaz de realizar a tarefa.
2. Valide a saída de forma mecânica.
3. Peça ao modelo uma autoverificação calibrada apenas com base em critérios observáveis.
4. Escalone se a validação falhar, a confiança for baixa ou o risco for alto.
5. Registre a rota e o resultado para ajustes posteriores.

Exemplo de roteador:

def run_with_escalation(task, input_text):
    first_model = pick_first_model(task)

    response = call_model(
        model=first_model,
        input=input_text,
        schema=task["schema"],
        temperature=0
    )

    validation = validate(response, task["schema"])

    if not validation.ok:
        return call_model(
            model="claude-sonnet-4.6",
            input=input_text,
            schema=task["schema"],
            temperature=0
        )

    if task["risk"] == "high" and response.get("needs_review"):
        return call_model(
            model="claude-opus-4.8",
            input=input_text,
            schema=task["schema"],
            temperature=0
        )

    return response

O importante é que o escalonamento se baseie em sinais mensuráveis, não em impressões.

Sinais úteis para escalonamento:

• JSON inválido
• Campos obrigatórios ausentes
• Resposta contraditória
• Falha na chamada de ferramenta
• Evidências recuperadas são fracas
• O usuário está solicitando uma ação irreversível
• A entrada excede o tamanho normal
• O modelo indica explicitamente incerteza
• O classificador detecta conteúdo jurídico, médico, de segurança ou financeiro

Evite usar apenas a “confiança do modelo” como pontuação numérica. A confiança de um LLM não é uma probabilidade calibrada. Ela ainda é útil quando se limita a verificações específicas: “A entrada continha informações suficientes para responder?” é melhor do que “Qual é o seu grau de confiança?”

Latência, preço e experiência do usuário

O modelo mais rápido nem sempre oferece a melhor experiência do usuário. A melhor experiência é aquela que leva o usuário a um resultado correto com uma espera tolerável.

Para sistemas interativos, penso em limites de latência:

Não esconda um raciocínio demorado atrás de um indicador de carregamento sem fornecer feedback. Se uma tarefa do Opus ou Fable precisar de 90 segundos, apresente-a explicitamente como uma tarefa de análise:

Analyzing 184 files...
✓ Indexed repository structure
✓ Found 12 migration scripts
✓ Checking rollback safety

Isso muda a percepção do usuário porque o sistema está realizando um trabalho visível.

Além disso, use streaming sempre que possível. O streaming não reduz o tempo total de conclusão, mas melhora drasticamente a latência percebida em fluxos de conversa e elaboração de textos.

Decisões reais por tarefa

Estas são escolhas concretas que eu faria hoje.

Triagem de chamados de suporte

Use Haiku primeiro.

• Entrada: texto curto do chamado
• Saída: categoria, urgência, fila de encaminhamento
• Escale para Sonnet em disputas de cobrança, casos de clientes irritados e ambiguidades nas políticas
• Revisão humana para reembolsos acima do limite

Este é um fluxo de trabalho clássico que começa pela opção mais barata.

Agente de suporte voltado ao cliente

Use Sonnet.

• Precisa usar ferramentas
• Precisa controlar o tom
• Precisa lidar com políticas
• Precisa escalar os casos de forma adequada

Use Haiku apenas no pré-processamento. Use Opus para revisão de supervisão em casos de alto risco.

Assistente de revisão de código

Use Sonnet para revisões comuns de PRs. Use Opus para alterações sensíveis à arquitetura, concorrência, segurança, migrações de dados e trabalhos que envolvam questões sutis de correção.

Um erro comum é fornecer todo o repositório por padrão. Comece pelo diff, pelo grafo de dependências e pelos arquivos relacionados. Escale para Fable ou outro modelo de contexto longo apenas quando a alteração abranger muitas áreas.

Comparação de contratos ou políticas extensos

Use recuperação de informações com Sonnet para perguntas específicas. Use Fable 5 quando a pergunta for global, como “encontre todas as contradições entre estes documentos”.

Se a saída influenciar uma decisão jurídica ou de conformidade real, use o modelo para preparar a análise, não para tomar a decisão.

Enriquecimento de dados em alto volume

Use um modelo de pesos abertos se o volume for alto e a tarefa for estável.

Exemplo:

• Normalizar nomes de empresas
• Extrair etiquetas de setor
• Classificar leads recebidos
• Gerar resumos internos curtos

Execute lotes noturnos, valide amostras e escale casos excepcionais para um modelo hospedado.

Assistente de pesquisa em grandes acervos

Use Gemini 3, GPT-5.5, Opus ou Fable, dependendo do tamanho do contexto e das necessidades de raciocínio. Eu não começaria pela opção mais barata nesse caso, a menos que a consulta fosse claramente simples. As falhas de pesquisa costumam ser silenciosas: o modelo fornece uma resposta plausível, mas deixa de considerar o documento essencial.

Planejamento de orçamento sem se enganar

A maneira mais fácil de gastar demais é otimizar o custo por chamada enquanto se ignoram novas tentativas, correções humanas e fluxos de trabalho que falharam.

Acompanhe estas métricas por tipo de tarefa e modelo:

• Tokens de entrada
• Tokens de saída
• Latência p50/p95
• Taxa de falhas de validação
• Taxa de escalonamento
• Taxa de intervenções humanas
• Taxa de novas tentativas pelo usuário
• Custo por tarefa bem-sucedida, não custo por chamada

Essa última métrica importa. Um modelo barato que exige três novas tentativas e ainda causa revisão manual pode ser mais caro que Sonnet. Uma chamada ao Opus que evita uma migração problemática pode ser a decisão mais barata da semana.

Se você usa um gateway para vários modelos, incluindo algo como o acesso via API da AI Prime Tech às famílias Claude, GPT e Gemini, o principal benefício não é apenas a possibilidade de escolher fornecedores. É facilitar o roteamento e a medição entre classes de modelos. Mas a parte difícil continua sendo o projeto da sua tarefa.

Recomendações Práticas

• Comece pelo formato da tarefa: transformação, extração, raciocínio, síntese de contexto longo ou enriquecimento em lote.
• Use modelos da classe Haiku para trabalhos baratos, rápidos e restritos, com validação mecânica.
• Use modelos da classe Sonnet como padrão para funcionalidades de produto que precisam de raciocínio, ferramentas ou qualidade na interação com o usuário.
• Use modelos da classe Opus quando os erros custarem caro, a ambiguidade for alta ou o raciocínio profundo for importante.
• Use contexto longo no estilo do Fable 5 quando a incerteza na recuperação de informações for o principal problema, não como estratégia padrão de despejar conteúdo no prompt.
• Use modelos de pesos abertos quando a estabilidade da carga de trabalho, a privacidade, a capacidade de processamento ou o controle da implantação justificarem operar a inferência por conta própria.
• Crie um roteamento que comece pela opção mais barata, com sinais explícitos de escalonamento: saída inválida, evidências fracas, falhas de ferramentas, ações de alto risco e incerteza.
• Meça o custo por tarefa bem-sucedida, não o custo por token ou por chamada.
• Mantenha os roteadores simples o suficiente para depurá-los sob pressão.
• Trate a escolha de modelos como um mecanismo de controle de engenharia, não como uma decisão única sobre fornecedor.