Como escolher um LLM para produção sem depender do ranking

1. Defina o que significa resolver a tarefa#

Um assistente que escreve rascunhos e um extrator de notas fiscais podem usar o mesmo modelo, mas precisam de critérios de aceitação diferentes. Antes de testar provedores, escreva o contrato do produto: o que ele recebe, o que devolve, quanto tempo pode levar e quais ações precisam de revisão humana. Uma resposta convincente não basta se ela inventa um identificador ou muda o valor de uma nota.

Para um extrator, separe campos obrigatórios, formato, evidência e regras de negócio. Para um assistente de código, verifique se a proposta compila, respeita permissões e passa nos testes relevantes. Um JSON válido só prova a forma da resposta. A aplicação ainda precisa validar referências, faixas de valores e autorização antes de executar uma ação.

2. Monte um conjunto capaz de contradizer você#

Parta de exemplos representativos e autorizados da sua aplicação. Inclua entradas incompletas, documentos longos, português com variações regionais e casos em que a resposta correta é se abster. Mantenha uma partição que você não usa para ajustar prompts. Se você otimiza e aprova com as mesmas perguntas, acaba medindo o quanto decorou a própria prova.

• Guarde entrada, saída esperada, critérios de aceitação e criticidade. Evite segredos ou dados pessoais desnecessários.
• Classifique as falhas por causa: recuperação, raciocínio, formato, ferramentas ou infraestrutura.
• Rode a mesma versão do conjunto com o mesmo prompt, orçamento e ferramentas em cada candidato.

Você pode começar com um conjunto pequeno revisado manualmente e ampliá-lo com as falhas observadas. Esse conjunto inicial serve para descobrir problemas, não para sustentar uma promessa estatística de precisão. Informe sempre tamanho, distribuição e número absoluto de erros.

3. Calcule o custo por resultado aceito#

A tarifa por milhão de tokens é só uma das entradas da decisão. A conta de uma tarefa também inclui retries, recuperação, ferramentas e revisão. Um modelo barato que obriga a repetir três vezes pode sair mais caro que outro com tarifa maior. Use os tokens cobrados quando estiverem disponíveis e registre separadamente entrada, saída e cache.

type Run = { costUsd: number; accepted: boolean };

function costPerAcceptedTask(runs: Run[]) {
  const accepted = runs.filter(r => r.accepted).length;
  const total = runs.reduce((sum, r) => sum + r.costUsd, 0);
  return accepted === 0 ? null : total / accepted;
}

Compare janelas de contexto e condições de tarifa antes de multiplicar. No catálogo, as fichas explicam se o preço muda com o horário ou com o tamanho da entrada. O custo normalizado facilita uma primeira seleção; o seu orçamento final deve sair de uma reprodução da carga esperada.

Documentação: DeepSeek: condições de preço ↗ · xAI: contexto e preços do Grok 4.6 ↗

4. Meça a experiência completa#

O tempo até o primeiro token importa numa interface conversacional; o tempo até concluir a tarefa importa quando o usuário espera um arquivo ou uma ação. Meça os dois onde fizer sentido. Separe tempo de fila, recuperação, chamada ao modelo e ferramentas para não culpar o componente errado.

Não publique diferenças de milissegundos obtidas com três requisições como se fossem um benchmark. Repita em janelas diferentes, documente região e concorrência e observe a dispersão. O objetivo é saber se o produto cumpre o orçamento, não vencer uma corrida artificial.

5. Projete a falha antes de trocar de provedor#

Um timeout pode chegar depois que uma ferramenta já gravou em outro sistema. Repetir a conversa inteira sem uma chave de idempotência pode duplicar esse efeito. Separe a geração da proposta da execução autorizada; imponha limites de tentativas, tempo total e custo. O modelo de fallback também precisa passar nas validações do contrato.

Repita os casos difíceis com o candidato de fallback. Se ele não atender, a saída segura pode ser pedir informações adicionais ou encaminhar a tarefa para revisão. Defina quais erros permitem fallback e quais devem interromper o fluxo. Trocar de provedor automaticamente não conserta uma entrada inválida nem uma falta de permissão.

6. Publique uma decisão reproduzível#

Guarde um manifesto com identificador do modelo, data, prompt, versão do conjunto, configuração e resumo dos resultados. Fixe versões quando o provedor oferecer e acompanhe o ciclo de vida delas. Promova de forma gradual, com a possibilidade de voltar à configuração anterior e métricas que separem erros do modelo de erros da aplicação.

• Selecione dois ou três candidatos por capacidade, condições e orçamento.
• Rode a avaliação e revise manualmente os erros de maior impacto.
• Aprove qualidade, latência e custo com critérios definidos antes do experimento.
• Reavalie quando mudarem o modelo, o prompt, as ferramentas ou a distribuição dos dados.

Documentação: Mistral: catálogo e ciclo de vida dos modelos ↗