Dois modelos podem responder bem a uma pergunta simples e se separar quando encontram um comprovante borrado, uma cláusula ambígua ou uma ferramenta indisponível. A escolha fica confiável quando o teste contém esses casos e define, antes de olhar as respostas, o que conta como acerto e qual erro impede produção.
Ranking público e opinião de equipe ajudam a formar uma lista, mas não carregam o seu idioma, seus dados, seu prompt e a consequência de uma falha. Uma avaliação útil executa a mesma tarefa nos candidatos, guarda configuração e resultado e combina qualidade com latência e custo por trabalho concluído.
A Roteia reúne modelos e publica capacidades, contexto e preços no catálogo. Esse material reduz candidatos incompatíveis. O vencedor, se houver, vem do conjunto de avaliação da aplicação; o gateway não escolhe automaticamente qual modelo atende melhor ao negócio.
Recorte uma tarefa e um risco
Evite testar “atendimento” como uma coisa só. Identificar intenção, consultar pedido e redigir resposta são tarefas diferentes. Um primeiro experimento pode receber uma mensagem e devolver uma das categorias permitidas. Outro pode extrair campos de uma nota. Quanto menor a unidade, mais fácil entender por que o candidato acertou ou falhou.
Escreva a entrada, a saída e o consumidor. Se o resultado vai para uma pessoa, clareza e evidência podem dominar. Se alimenta código, formato e consistência ganham peso. Liste o erro caro: inventar um valor, trocar uma negativa, chamar a ferramenta errada ou revelar informação de outro cliente. Esse erro pode ser eliminatório mesmo quando a média parece boa.
Também descreva o que está fora do teste. Avaliar texto não autoriza concluir sobre visão; testar resposta final não prova segurança da execução de ferramentas. Um relatório honesto vale por aquilo que mediu e deixa o restante explícito.
Monte casos que representem a distribuição
Comece com exemplos reais autorizados e anonimizados quando necessário. Separe casos comuns, extremos e incidentes conhecidos. Para um classificador, mantenha exemplos de cada categoria e situações que não pertencem a nenhuma. Para extração, inclua campo ausente, formatos brasileiros, texto ruim e tentativa de induzir um valor. Para tools, cubra chamada necessária, desnecessária e proibida.
Crie uma resposta de referência ou uma rubrica curta. Nem toda tarefa tem uma frase única correta. Um resumo pode ser avaliado por fatos obrigatórios, ausência de invenção, clareza e tamanho. Faça duas pessoas pontuarem uma amostra e discuta divergências; se elas não concordam sobre o critério, o placar do modelo será instável.
Reserve um conjunto de validação. Use parte dos casos para melhorar prompt e configuração e mantenha outra parte fora desse ciclo. Quando cada erro vira uma mudança e é testado no mesmo exemplo, a nota pode subir por memorização do conjunto, não por melhoria geral.
- Caso comum para medir o volume predominante.
- Caso de borda que já causou retrabalho ou risco.
- Entrada sem resposta suficiente para avaliar recusa honesta.
- Entrada adversarial que tenta contornar instrução ou autorização.
Fixe configuração e registre a execução
Use o mesmo prompt, exemplos, temperatura, limite de saída e conjunto de ferramentas sempre que o contrato permitir. Se um modelo exige uma adaptação, registre uma rodada comparável e outra otimizada. Misturar respostas de prompts diferentes num único placar atribui ao modelo o efeito da configuração.
Guarde ID exato do modelo, data, parâmetros, entrada, saída, motivo de término, uso, latência, erro e identificador da chamada. Alias e catálogos mudam; sem esse registro, a equipe não consegue reproduzir uma diferença semanas depois. Proteja dados sensíveis e limite acesso ao material bruto.
Automatize o que é determinístico: parse de JSON, schema, correspondência exata, cálculo, teste de código e presença de campos. Use revisão humana ou juiz com rubrica para linguagem e qualidade sem resposta única. Se outro modelo pontuar, calibre suas notas contra pessoas e não trate esse juiz como verdade absoluta.
Dê peso ao erro que afeta a operação
Acurácia média pode esconder uma classe rara e importante. Calcule por categoria e destaque falsos positivos e falsos negativos com consequências diferentes. Em cobrança, afirmar pagamento sem prova pode reprovar o candidato; deixar de usar uma saudação preferida não deveria compensar esse erro na mesma escala.
Uma rubrica pequena facilita revisão. Por exemplo: fatos sustentados, instrução cumprida, formato válido e próximo passo apropriado. Para cada item, defina exemplos de aprovação e falha. Evite vinte critérios vagos com pesos escolhidos depois de ver o vencedor. Poucos critérios ligados ao fluxo tornam a decisão explicável.
Leia amostras de erro, não só o número final. Agrupe por causa provável: contexto insuficiente, prompt ambíguo, capacidade ausente, recuperação ruim, tool incorreta ou variação do modelo. Às vezes dividir a tarefa ou adicionar validação resolve mais do que trocar de fornecedor.
Meça latência, uso e custo juntos
Registre tempo total e, quando houver streaming, tempo até o primeiro conteúdo útil. Rode chamadas suficientes para enxergar variação e percentis; a melhor tentativa, sozinha, não representa o fluxo. Faça isso com entradas do tamanho esperado, porque uma frase curta não prevê a experiência de um contexto com documentos e ferramentas.
Calcule custo a partir do uso devolvido pela API e do preço vigente para o modelo. Separe tokens de entrada e saída quando a tarifa for distinta. Acrescente repetição por falha, chamadas de ferramenta, embeddings, transcrição e revisão humana que fazem parte do trabalho. A métrica útil pode ser custo por documento correto ou por conversa resolvida, não só por requisição.
Qualidade, latência e custo formam uma fronteira, não um ranking único. Um candidato pode justificar tarifa maior numa tarefa de risco e ser desperdício numa classificação simples. Defina limites mínimos e escolha entre quem passou; não permita que preço baixo compense uma falha eliminatória.
Teste falha, recusa e efeito externo
Simule timeout, limite, saldo insuficiente, resposta cortada e indisponibilidade. Verifique se a aplicação mostra estado correto, evita loop e permite nova tentativa segura. Um HTTP 200 num caso feliz não prova prontidão. A forma como o produto reage quando o modelo não responde protege mais a operação do que uma frase de fallback bonita.
Em tool calling, o teste precisa chegar ao executor controlado. Confirme nome, argumentos, autenticação, autorização e idempotência. Use ambientes sem efeito real ou funções simuladas para casos perigosos. O modelo pedir uma cobrança não prova que ela deveria ser feita; o backend precisa impedir e registrar a tentativa fora da regra.
Inclua recusas esperadas e indevidas. Uma recusa correta protege o usuário; uma recusa exagerada derruba utilidade. Marque ambas separadamente. Para conteúdo sensível, valide com responsáveis pela política antes de converter a nota em autorização de produção.
Promova por canário e transforme incidentes em regressão
Se um candidato passa no conjunto offline, envie uma fração pequena e controlada do tráfego elegível. Compare com a versão atual, mantenha caminho de retorno e não misture a troca do modelo com uma grande alteração de prompt. Monitore as mesmas métricas do teste e sinais de negócio, como correção humana e abandono.
Defina antes o critério de avanço e parada. Uma taxa de erro crítico acima do limite deve interromper o canário mesmo que custo e latência estejam melhores. Guarde o modelo anterior enquanto valida e registre quem decidiu, com qual amostra e em que data. Isso evita uma migração irreversível baseada em entusiasmo.
Depois da publicação, amostre respostas e transforme incidentes confirmados em novos casos. Rode a suíte quando prompt, modelo, ferramenta, catálogo ou regra de negócio mudar. Uma avaliação não é uma cerimônia de compra; é o mecanismo que permite evoluir sem repetir erros já conhecidos.
- Versão candidata passa pelos mínimos offline.
- Canário recebe tráfego permitido e pequeno.
- Métrica crítica tem limite de parada explícito.
- Rollback foi exercitado antes da expansão.
Dúvidas frequentes
Quantos exemplos preciso para testar um modelo?
Depende da variedade e do risco. Comece com uma amostra pequena que cubra casos comuns, bordas e erros caros, observe onde os candidatos ficam próximos e amplie essas regiões. Representatividade importa mais do que um número arbitrário.
Posso usar outro modelo para avaliar respostas?
Pode como apoio em tarefas subjetivas, desde que haja rubrica e calibração contra revisão humana. Um juiz automático tem vieses próprios e não substitui testes determinísticos nem validação da fonte.
Benchmark público basta para escolher?
Não. Ele ajuda na shortlist, mas usa dados e critérios diferentes do seu produto. Execute os finalistas com entradas reais, mesma configuração e erros ponderados pela consequência operacional.
Como comparar custo entre modelos?
Use o consumo real de entrada e saída, a tarifa vigente e todas as etapas necessárias. Compare custo por resultado aceito, incluindo repetição e revisão, para não premiar uma requisição barata que gera mais retrabalho.
Quando um modelo está pronto para produção?
Quando passa pelos mínimos de qualidade e segurança, reage de forma aceitável a falhas e confirma o resultado num canário com rollback. A aprovação vale para a tarefa, a configuração e a versão testadas.
Onde confirmar
Plataforma de terceiro muda de tela e de limite sem avisar. Confira na fonte oficial antes de tomar decisão baseada nesta página.