Blog
Como escolher o modelo de IA para um caso real: baseline, braços e votos cegos
Quando alguém pergunta "qual modelo de IA é o melhor", a resposta certa é outra pergunta: melhor para qual caso, medido como, decidido por quem. Escolha de modelo não é questão de gosto. É decisão de engenharia, e decisão de engenharia se testa.
Este texto descreve um jeito de montar esse teste, entre outros caminhos possíveis. Ele sustenta a decisão depois porque reúne sete peças: baseline explícito, braços comparáveis rodando sobre o mesmo contexto, respostas geradas em lote sobre casos sintéticos representativos, revisão qualitativa antes do voto, votação humana às cegas, um holdout guardado até o fim e uma escolha final que pode discordar da métrica.
Comece pelo baseline
Todo experimento de modelo precisa de um ponto de partida declarado: o modelo já em uso, ou o mais simples que resolve parte do problema. Sem baseline, dizer que "o modelo novo é melhor" não quer dizer nada, porque falta o "melhor em relação a quê".
O baseline entra no mesmo teste que os candidatos, sob as mesmas regras. Se ele falha nos mesmos casos que os concorrentes, isso também é um resultado, e vale registrar.
Braços comparáveis, mesmo contexto
Um braço é uma configuração testada: um modelo, com uma versão, um fornecedor e um conjunto de parâmetros (temperatura, orçamento de raciocínio, limite de tokens). Comparar braços só faz sentido quando todos recebem o mesmo contexto: o mesmo prompt de base, os mesmos dados de entrada, o mesmo corte temporal quando o caso envolve uma conversa em andamento.
Igualar o contexto é mais trabalho do que parece. Cada fornecedor trata limite de tokens, papéis de instrução e formato de resposta de um jeito diferente. Sem essa tradução cuidadosa, o teste mede a diferença de configuração, não a diferença de modelo.
Casos sintéticos representativos, gerados em lote
Testar um modelo com dois ou três exemplos escolhidos na hora não sustenta decisão nenhuma. O caminho é escrever um corpus pequeno e explícito, cobrindo os casos que o problema real produz: o caso fácil, o caso difícil, a pergunta fora do escopo, a instrução ambígua, o idioma diferente. Esse corpus fica congelado antes de rodar qualquer braço, e nenhum ajuste de prompt acontece depois de ver as respostas.
Cada braço roda o mesmo corpus mais de uma vez, para separar variação de modelo de variação aleatória de uma única resposta. O resultado é um lote de respostas geradas de uma vez, pronto para revisão, não uma conversa ao vivo com alguém julgando por cima do ombro.
Revisão qualitativa antes do voto
Antes de qualquer votação, alguém lê as respostas com atenção: aponta alucinação, resposta fora do papel esperado, formato quebrado, resposta que ignora uma instrução explícita do caso. Essa etapa tira de circulação braços com falha grave antes de gastar tempo de voto humano com eles, e documenta o que cada falha foi, para orientar prompt ou corpus na rodada seguinte.
Revisão qualitativa não substitui o voto. Ela filtra o que chega até ele.
Voto cego, não opinião de quem escreveu o prompt
Quem decide vota sem saber qual modelo gerou qual resposta. As respostas aparecem lado a lado, em ordem aleatória, com a mesma formatação. Só depois do voto o modelo é revelado, junto com a latência e o custo daquela resposta.
Sem esse cegamento, a decisão carrega o viés de quem escreveu o prompt e sabe, mesmo sem querer, qual resposta veio de qual fornecedor. O voto também precisa de uma escala simples e honesta, do tipo "eu usaria assim", "útil, mas eu editaria" e "não ajudou": categorias que descrevem uso real, não uma nota de zero a dez sem critério declarado.
Holdout: o teste que ninguém viu
Uma parte dos casos fica fora do ajuste inteiro: nunca entra na revisão, no ajuste de prompt nem na primeira rodada de votos. Esse holdout só é aberto no fim, com os finalistas já escolhidos, para checar se o resultado se sustenta fora do corpus que moldou a decisão. Se o desempenho cai no holdout, o processo revelou isso antes de o problema aparecer em produção.
"Melhor na métrica" não é sempre "escolhido"
O modelo com mais votos "eu usaria assim" não é automaticamente o modelo escolhido. Em um projeto recente que conduzi antes de fundar a Tecela AI, um assistente ao vivo para reuniões comerciais, testamos configurações de modelos de fornecedores diferentes sobre o mesmo contexto congelado, com cenários sintéticos de desenvolvimento, não sobre uma call real.
A votação cega reuniu 48 votos humanos sobre 24 pares de respostas comparadas lado a lado. Um modelo recebeu mais votos "eu usaria assim" que qualquer outro. Ainda assim, quem decidiu escolheu um modelo diferente para o uso ao vivo, considerando também a latência e o custo medidos no mesmo teste sintético, e manteve o mais votado como alternativa principal para a próxima comparação, já com dados de uma conversa real.
Parece contraditório, mas não é: a métrica informa a decisão, ela não a substitui. Quem carrega a responsabilidade pelo resultado é quem decide com a métrica na mão, não a métrica sozinha.
Custo e latência entram na decisão, não depois dela
Um modelo mais lento ou mais caro pode ganhar em qualidade e ainda perder na escolha, se a espera quebra a experiência ou o custo não fecha em escala. Meça latência (primeiro texto visível, resposta completa) e custo (tokens de entrada, saída, cache) no mesmo teste que mede qualidade, com os mesmos casos e a mesma amostra. Custo e latência não são critério de desempate: são parte da pergunta desde o início.
O modelo do "ao vivo" pode não ser o modelo da preparação
Um sistema pode usar mais de um modelo, cada um para uma tarefa com pressão diferente. Uma resposta durante uma conversa ao vivo precisa vir rápido. Uma tarefa de preparação ou de revisão depois do evento tem mais tempo disponível e pode valer a pena usar um modelo com mais capacidade de raciocínio, mesmo que mais lento. Não existe uma resposta única para "qual modelo usar": existe uma resposta por tarefa, testada em separado, porque a pressão de tempo e o tipo de erro tolerável mudam de uma tarefa para outra.
Um roteiro mínimo em 7 passos
- Defina o baseline. O modelo em uso hoje, ou o mais simples que já resolve parte do problema.
- Escreva um corpus pequeno e representativo. Casos sintéticos ou anonimizados, cobrindo o fácil, o difícil e o caso fora do padrão. Congele o corpus antes de rodar qualquer braço.
- Iguale o contexto entre braços. Mesmo prompt de base, mesmos dados, mesmo corte temporal. Traduza parâmetros com cuidado entre fornecedores diferentes.
- Rode em lote, com repetição. Gere respostas para cada braço sobre o corpus inteiro, mais de uma vez por caso, para separar modelo de ruído.
- Faça revisão qualitativa antes do voto. Elimine falhas graves e documente o que cada uma foi.
- Vote às cegas, com escala honesta. Modelo oculto até o voto, categorias que descrevem uso real.
- Reserve um holdout e decida com custo e latência na mesa. Abra o holdout só com os finalistas já escolhidos. A decisão final pesa a métrica, mas não obedece só a ela.
Uma decisão, não uma opinião
O objetivo desse processo não é achar um número que prove qual modelo é "o melhor" para sempre. É montar uma decisão que qualquer pessoa envolvida no projeto consiga reconstruir depois: qual foi o baseline, quais braços entraram, o que o corpus cobria, quem votou e com que informação disponível, o que o holdout mostrou, e por que a escolha final pesou custo e latência do jeito que pesou. Modelo de IA muda de mês em mês. O processo para escolher um é o que fica.
Se o seu produto depende de escolher e trocar modelo de IA com critério, e não por lançamento de fornecedor, é um bom ponto de partida para conversar.