Como comparar modelos para uma tarefa do produto

Comparar modelos para uma tarefa do produto exige manter claros o uso pretendido, os casos avaliados e o critério de sucesso. Uma demonstração atraente ou uma nota agregada não decide qual modelo serve melhor ao seu contexto. A comparação precisa mostrar qualidade, limites e condições de operação para a tarefa escolhida. O resultado pode ser manter o modelo atual, trocar em um recorte específico ou concluir que a evidência ainda é insuficiente.

Escolha a tarefa que a comparação precisa esclarecer

Comece por um verbo observável: resumir um pedido, classificar uma solicitação, recuperar uma informação ou executar uma ação autorizada. “Escolher o melhor modelo” é amplo demais porque mistura necessidades diferentes.

Descreva a entrada, a saída esperada e o que uma pessoa fará com o resultado. Um resumo usado como rascunho pode admitir condições diferentes de uma classificação que altera automaticamente o encaminhamento de uma tarefa. A comparação deve refletir esse uso.

Se o produto tem várias tarefas, examine cada uma antes de consolidar uma decisão. Um resultado médio pode esconder que uma opção é adequada para um tipo de entrada e insuficiente para outro. A segmentação deve ser definida por necessidades relevantes, não escolhida depois para favorecer uma alternativa.

Monte casos representativos e critérios verificáveis

Inclua exemplos de uso esperado e situações que revelem limites importantes: informação ausente, instruções ambíguas, exceções conhecidas e solicitações fora do escopo. Registre por que cada grupo de casos está presente.

A Anthropic sobre avaliações de agentes distingue a trajetória de execução do resultado efetivo no ambiente e discute entradas, critérios de sucesso e verificadores. Para uma tarefa que executa ações, não avalie somente a explicação apresentada. Confira se o resultado esperado ocorreu dentro dos limites definidos.

Critérios úteis podem observar fidelidade às informações disponíveis, cumprimento de restrições, tratamento de ausência de dados e conclusão da tarefa. Escolha os que realmente mudam a decisão do produto. Uma lista extensa de indicadores sem consequência torna a comparação difícil de interpretar.

Declare as condições de cada alternativa

Registre modelo, configuração, instrução, contexto, ferramentas e forma de avaliação. Se a proposta é comparar modelos sob a mesma configuração, mantenha os demais elementos estáveis dentro do que for possível e documente as diferenças inevitáveis.

Outra pergunta legítima é comparar soluções ajustadas para cada modelo. Nesse caso, explicite que a unidade de comparação inclui configuração e preparação. Não apresente o resultado como efeito isolado do modelo.

Defina também como lidar com variação entre execuções. A repetição de casos pode revelar comportamentos que uma única saída não mostra. Não invente um número universal de tentativas: escolha uma abordagem proporcional ao risco e declare o que ela permite observar.

Exemplo fictício: escolher um modelo para classificar pedidos

Imagine um sistema de serviços internos que classifica pedidos antes da revisão por uma pessoa. A equipe quer comparar o modelo atual com uma alternativa. Os casos incluem pedidos completos, pedidos com mais de uma intenção e textos sem informação suficiente.

O critério não é apenas acertar uma categoria. A funcionalidade também precisa reconhecer quando não há evidência suficiente para classificar. A equipe observa quais erros aumentariam o trabalho de triagem e quais poderiam encaminhar a solicitação para o lugar errado.

Uma alternativa pode produzir textos mais elegantes e ainda classificar pior os casos ambíguos. Outra pode exigir contexto adicional. O exemplo não define um vencedor; mostra por que a comparação precisa terminar em uma decisão ligada ao uso, e não à aparência da resposta.

Examine operação junto da qualidade

Depois de conferir o comportamento, observe as condições para manter a solução: tempo de resposta, falhas, consumo atribuído à tarefa e esforço de revisão. Use dados efetivamente coletados na configuração avaliada. Preços e limites de fornecedores devem ser verificados no momento da decisão, sem transportar condições antigas para uma comparação atual.

O Google SRE sobre objetivos de serviço descreve metas de confiabilidade usadas para orientar decisões de engenharia, com acordos e processo de revisão. A aplicação proposta é declarar quais condições operacionais a tarefa precisa cumprir para que uma alternativa seja aceitável.

Não compense uma falha eliminatória de comportamento com uma média atraente de outros indicadores. Se a tarefa exige preservar uma restrição e uma alternativa não a respeita nas condições avaliadas, registre esse limite antes de discutir conveniência operacional.

Registre a escolha e o que poderia mudá-la

O parecer final deve reunir a tarefa, os casos, as condições, os resultados e os limites da conclusão. Descreva se a alternativa foi escolhida para todo o uso permitido ou para um recorte específico.

Uma decisão inconclusiva também pode orientar o próximo passo. Talvez faltem casos de uma exceção, talvez o critério esteja ambíguo ou talvez a diferença observada não justifique a mudança. Registre qual evidência falta e evite repetir a comparação sem alterar seu desenho.

Escolha modelos por tarefa e mantenha a decisão revisável. O produto precisa saber por que a opção atual foi aceita, onde ela não deve ser usada e quais sinais justificariam uma nova avaliação.

Se quiser discutir essa decisão no contexto da sua empresa, converse com a dooop.

Leituras para continuar

• Inteligência no produto: como evoluir um software com IA
• Como organizar versões de prompts em um produto
• Como escolher uma funcionalidade de IA para o produto

Fontes

• Anthropic: avaliações de agentes
• Google SRE: objetivos de serviço

Para continuar esta leitura

• Como decidir se o produto precisa de múltiplos agentes