Não existe um modelo de IA “melhor” para tudo. Claude, da Anthropic, GPT, da OpenAI, Gemini, do Google, e os modelos abertos como Llama, Qwen e DeepSeek trocam de posição nos rankings a cada poucos meses, e a diferença entre eles muda conforme a tarefa. A escolha certa sai de um processo: definir o tipo de trabalho, filtrar por restrições (custo, latência, privacidade, integração) e testar os finalistas com casos reais da sua empresa.
Este guia entrega esse processo em forma de framework. Ele não depende de qual versão saiu no mês passado: você aplica os mesmos critérios hoje e daqui a um ano, só atualizando a lista de candidatos na página de cada fornecedor.
Resumo rápido
- Comece pela tarefa (texto, código, documentos, multimodal, agentes), não pela marca.
- Filtre por restrições objetivas: janela de contexto, custo por token, latência, retenção de dados e onde o modelo está hospedado.
- Dentro de cada fornecedor, a escolha entre modelo pequeno e grande costuma pesar mais no custo do que a troca de fornecedor.
- Decida com um teste próprio (eval) de 20 a 30 casos reais, com critério de aprovação definido antes de rodar.
- Arquitete para trocar de modelo: o líder de hoje dificilmente será o líder daqui a seis meses.
Por que “qual é o melhor modelo?” é a pergunta errada
Rankings públicos medem desempenho em conjuntos de testes genéricos: olimpíadas de matemática, desafios de programação, perguntas de múltipla escolha. Sua empresa não responde olimpíadas. Ela classifica tickets, resume contratos, responde clientes no WhatsApp e gera descrições de produto. Um modelo que lidera em matemática pode escrever pior em português comercial, e um modelo menor pode acertar 98% das classificações de que você precisa por uma fração do preço.
Além disso, os três grandes fornecedores lançam versões novas várias vezes por ano, e cada um oferece uma família inteira: modelos grandes (mais capazes, mais caros, mais lentos) e modelos pequenos (rápidos e baratos). Na prática, você não escolhe “Claude ou GPT”; escolhe uma combinação de fornecedor, tamanho de modelo, nível de raciocínio e forma de acesso para cada tarefa.
Passo 1: classifique a tarefa
Antes de abrir qualquer página de preços, escreva em uma frase o que o modelo vai fazer e em que volume. Quase todo uso empresarial cai em uma destas categorias:
- Texto longo e redação: artigos, propostas, e-mails, atendimento. Aqui pesam tom, fluência em português e obediência a instruções de estilo.
- Código: gerar, revisar e corrigir software. Pesa a capacidade de trabalhar em vários arquivos, entender o projeto inteiro e usar ferramentas como terminal e testes automatizados.
- Análise de documentos: contratos, laudos, planilhas, PDFs extensos. Pesam janela de contexto, leitura de tabelas e fidelidade ao texto (não inventar cláusulas).
- Multimodal: entender imagens, prints, notas fiscais fotografadas, áudio ou vídeo. Nem todo modelo aceita todos os formatos, e a qualidade varia por tipo de mídia.
- Agentes: o modelo decide sozinho uma sequência de passos e chama ferramentas (APIs, banco de dados, navegador). Pesam confiabilidade no uso de ferramentas, capacidade de manter o objetivo em tarefas longas e de se recuperar quando uma etapa falha.
- Classificação e extração em volume: triagem de e-mails, extração de campos, roteamento. Aqui um modelo pequeno quase sempre basta, e o custo por chamada manda na decisão.
Uma mesma empresa normalmente tem duas ou três dessas categorias. Isso é um sinal de que provavelmente vai usar mais de um modelo, e tudo bem.
Passo 2: aplique os critérios de filtro
Com a tarefa definida, use os critérios abaixo para cortar candidatos. Os valores exatos (tamanho de contexto, preço por milhão de tokens) mudam com frequência; consulte sempre a página oficial do fornecedor no dia da decisão.
| Critério | O que verificar | Quando pesa mais |
|---|---|---|
| Janela de contexto | Quantos tokens (pedaços de palavra) cabem em uma chamada, somando entrada e saída | Contratos longos, bases de código, histórico de conversa extenso |
| Custo por token | Preço separado de entrada e de saída; descontos de lote (batch) e de cache de prompt | Alto volume: atendimento, classificação, geração em massa |
| Tamanho do modelo | Versão pequena, média ou grande da mesma família | Sempre: é a alavanca de custo mais forte |
| Latência | Tempo até o primeiro token e tempo total de resposta | Chat ao vivo, voz, autocompletar |
| Raciocínio | Se o modelo tem modo de “pensar mais” e como se ajusta o esforço | Análise complexa, planejamento, código difícil |
| Privacidade e retenção | Uso dos dados para treino, prazo de retenção, opção de retenção zero, região de processamento | Dados pessoais, saúde, jurídico, financeiro |
| Português e Brasil | Qualidade em português, disponibilidade de cobrança e suporte para empresas brasileiras | Atendimento ao cliente, conteúdo público |
| Integração | API direta, Amazon Bedrock, Google Cloud Vertex AI, Microsoft Azure/Foundry, SDKs | Empresas que já têm contrato e governança em uma nuvem |
Contexto grande não substitui organização
Janelas de contexto cresceram muito, e hoje há modelos que aceitam o equivalente a centenas de milhares de palavras. Isso não significa que você deve jogar tudo no prompt. Cada token de entrada é cobrado em toda chamada, e a precisão tende a cair quando a informação relevante está enterrada no meio de um volume enorme. Para bases de conhecimento que mudam, a busca por trechos relevantes antes da chamada, o chamado RAG, costuma sair mais barata e mais precisa; detalhamos isso no guia prático de RAG.
Pequeno versus grande
Todos os grandes fornecedores mantêm famílias com níveis diferentes. Na Anthropic, por exemplo, a divisão histórica é Haiku (rápido e barato), Sonnet (equilíbrio) e Opus (mais capaz); OpenAI e Google têm variantes equivalentes, como versões “mini”, “flash” ou “lite”. A diferença de preço entre o menor e o maior modelo da mesma família costuma ser bem maior que a diferença entre fornecedores no mesmo nível. Por isso, a pergunta mais lucrativa é: “o modelo pequeno resolve esta tarefa?”. Muitas vezes resolve.
Privacidade não é detalhe de rodapé
Nas APIs empresariais dos três grandes, a política padrão hoje é não usar os dados enviados para treinar modelos, mas os detalhes variam: prazo de retenção para monitoramento de abuso, existência de contrato de retenção zero, regiões onde os dados são processados. Planos gratuitos de chat para consumidor podem ter regras diferentes das da API. Se você trata dados pessoais, isso entra na avaliação de impacto exigida pela LGPD; veja nosso material sobre segurança e LGPD na implantação de IA.
Onde o modelo roda
Você não precisa contratar cada fornecedor diretamente. Claude está disponível na API da Anthropic, no Amazon Bedrock, no Google Cloud (Vertex AI) e no Microsoft Foundry. Modelos da OpenAI são oferecidos também via Azure. Gemini roda na API do Google e no Vertex AI. Se sua empresa já tem conta, faturamento e regras de segurança em uma dessas nuvens, contratar o modelo por ali simplifica compras, auditoria e controle de rede. Confira em cada nuvem quais modelos e regiões estão liberados, porque a disponibilidade nem sempre é idêntica à da API do fornecedor.
E os modelos abertos?
Modelos de pesos abertos (open-weights), como Llama, Qwen, DeepSeek, Mistral e Gemma, entram na disputa quando você precisa de pelo menos uma destas coisas: que os dados nunca saiam da sua infraestrutura, custo previsível em volume muito alto, ou ajuste fino (fine-tuning) profundo para um domínio específico. Em troca, você assume a operação: servidores com GPU, atualização, monitoramento e segurança.
Para a maioria das pequenas e médias empresas, o caminho mais eficiente é começar com uma API comercial e manter um modelo aberto como opção avaliada no mesmo teste. Também dá para usar modelos abertos via provedores de nuvem, sem administrar hardware. As diferenças de licença entre eles são relevantes e tratamos isso em detalhe no guia de modelos abertos.
Passo 3: monte seu próprio teste (eval)
Um eval é um conjunto de casos de teste com resposta esperada ou critério de correção. Ele transforma “achei que o modelo X escreveu melhor” em uma comparação repetível. Não precisa de ferramenta sofisticada; uma planilha e um script curto bastam.
Como montar em uma tarde
- Colete 20 a 30 casos reais. Pegue entradas verdadeiras do seu dia a dia (e-mails, tickets, trechos de contrato), anonimizadas. Inclua casos fáceis, médios e os difíceis que hoje dão trabalho para a equipe.
- Defina o que é acerto antes de rodar. Para classificação, a categoria correta. Para extração, os campos esperados. Para redação, uma rubrica curta: tom adequado, sem informação inventada, dentro do tamanho pedido.
- Use o mesmo prompt para todos os candidatos. Ajuste mínimo por fornecedor só se a documentação oficial pedir.
- Rode cada caso mais de uma vez nos modelos que variam a resposta, para ver consistência, não só o melhor resultado.
- Registre custo e latência de cada chamada junto com a nota de qualidade.
- Decida com uma regra simples: o modelo mais barato que atinge a nota mínima vence. Empate técnico se resolve por latência, privacidade ou integração.
Um esqueleto em Python para o caso de classificação, independente de fornecedor:
import csv, time
def avaliar(nome_modelo, chamar_modelo, casos):
acertos, custo_total, tempos = 0, 0.0, []
for caso in casos:
inicio = time.time()
resposta, custo = chamar_modelo(caso["entrada"])
tempos.append(time.time() - inicio)
custo_total += custo
if resposta.strip().lower() == caso["esperado"].strip().lower():
acertos += 1
taxa = acertos / len(casos)
print(f"{nome_modelo}: acerto={taxa:.0%} custo={custo_total:.4f} "
f"latencia_media={sum(tempos) / len(tempos):.1f}s")
with open("casos.csv", encoding="utf-8") as f:
casos = list(csv.DictReader(f)) # colunas: entrada, esperado
# chamar_modelo_a e chamar_modelo_b encapsulam o SDK de cada fornecedor
# e devolvem (texto_da_resposta, custo_estimado_da_chamada)
# avaliar("modelo_a", chamar_modelo_a, casos)
# avaliar("modelo_b", chamar_modelo_b, casos)Para tarefas de redação, a comparação exata não funciona. Nesses casos, faça avaliação cega: uma pessoa da equipe lê as respostas sem saber de qual modelo vieram e dá nota pela rubrica. Também é possível usar um segundo modelo como avaliador, desde que você confira uma amostra manualmente.
Exemplo prático: escritório de contabilidade em Belo Horizonte
Um escritório com 15 funcionários quer automatizar três coisas: classificar os e-mails que chegam dos clientes (cerca de 400 por dia), extrair dados de notas fiscais e boletos enviados em PDF ou foto, e redigir respostas a dúvidas tributárias recorrentes para revisão humana.
- Classificação de e-mails: o eval com 30 e-mails reais mostra que os modelos pequenos dos três fornecedores acertam praticamente o mesmo. Vence o mais barato, que já está disponível na nuvem que o escritório usa.
- Extração de documentos: aqui a diferença aparece em fotos tortas e boletos escaneados. Um modelo intermediário com boa leitura de imagem passa no teste; o pequeno erra campos de valor. Como o volume é menor, o custo extra compensa.
- Respostas tributárias: o teste cego com o sócio avaliando 20 respostas indica um modelo grande, com raciocínio ativado em nível médio. Como tudo passa por revisão humana e o volume é baixo, latência não importa.
Resultado: três tarefas, dois fornecedores, três tamanhos de modelo. Como os dados incluem CPF e informações fiscais, o escritório confirma por escrito a política de retenção de cada API e registra isso no relatório de impacto exigido pela LGPD.
Erros comuns
- Escolher pelo ranking da semana. Rankings medem tarefas que não são as suas. Use-os só para montar a lista de candidatos.
- Testar com três exemplos inventados. Casos fáceis e fictícios aprovam qualquer modelo. O valor do eval está nos casos difíceis e reais.
- Usar o modelo mais caro para tudo. É o erro de custo mais frequente. Teste o menor modelo primeiro e suba só se ele falhar.
- Ignorar o custo de saída. Tokens de saída costumam custar várias vezes mais que os de entrada. Respostas longas e raciocínio estendido pesam na conta.
- Prender o código a um fornecedor. Isole a chamada ao modelo em uma função ou camada própria. Assim, trocar de modelo vira mudar configuração, não reescrever o sistema.
- Esquecer de reavaliar. Rode o mesmo eval a cada lançamento relevante ou a cada trimestre. O teste já está pronto; repetir custo pouco.
Perguntas frequentes
Vale a pena assinar mais de um assistente de IA?
Para uso individual, uma assinatura costuma bastar, e você pode testar outras nas versões gratuitas. Para empresas que integram IA em processos, usar mais de um modelo via API é comum e saudável: cada tarefa fica com o modelo de melhor custo-benefício e você reduz a dependência de um único fornecedor.
Qual modelo escreve melhor em português?
Os grandes modelos comerciais escrevem bem em português, e a diferença entre eles depende do tipo de texto e do prompt. A única forma confiável de saber é o teste cego com textos do seu segmento. Modelos abertos menores tendem a ser menos consistentes em português que os grandes comerciais, mas isso também deve ser medido.
Preciso de uma janela de contexto enorme?
Só se você realmente precisa analisar documentos muito longos de uma vez. Para perguntas sobre uma base de documentos, RAG costuma ser mais barato e preciso. Lembre que cada token enviado é cobrado em toda chamada.
Os fornecedores usam meus dados para treinar os modelos?
Nas APIs empresariais de Anthropic, OpenAI e Google, a política padrão divulgada é não treinar com dados de clientes, mas os termos mudam e há diferenças entre API, planos de chat e versões gratuitas. Leia a política de dados vigente do produto exato que você vai contratar e guarde a versão consultada.
De quanto em quanto tempo devo rever a escolha?
Uma revisão trimestral funciona bem para a maioria das empresas, além de uma rodada extra quando um fornecedor lança uma família nova. Com o eval pronto, a revisão leva poucas horas.
