Escolha um modelo com base em evidências

Defina a decisão

Uma comparação de modelos precisa de um uso específico. Um modelo que explica bem uma função pequena pode não lidar tão bem com uma grande alteração no repositório. Um modelo de menor custo pode atender à qualidade exigida em transformações rotineiras. Uma investigação difícil pode exigir maior capacidade de raciocínio.

Escreva primeiro a tarefa e as restrições. Inclua os dados permitidos, as ferramentas necessárias, o tempo de resposta e o custo máximo aceitável. Algumas restrições são obrigatórias. Não dilua uma restrição de tratamento de dados em uma média porque outra pontuação é alta.

Use tarefas representativas

Monte um pequeno conjunto de avaliação com trabalhos que a equipe realmente faz. Remova dados sensíveis, a menos que o ambiente de avaliação esteja aprovado para eles. Inclua tarefas simples, difíceis e tarefas em que a resposta correta é pedir as informações que faltam.

Para um serviço fictício de relatórios, use um defeito conhecido de data, uma funcionalidade pequena de filtro e uma explicação de uma regra de autorização. Prepare o resultado esperado antes de executar a comparação. Inclua um teste negativo que rejeite o defeito conhecido.

Reserve algumas tarefas fora do desenvolvimento do prompt. Se ajustar repetidamente o prompt com todos os exemplos, a pontuação final pode exagerar o desempenho geral. Um conjunto separado ajuda a revelar se o prompt melhorado funciona além dos exemplos usados para criá-lo.

Mantenha a comparação justa

Registre a versão exata do modelo, o prompt, o contexto fornecido, as ferramentas e as permissões. Use estados iniciais equivalentes. Se um modelo receber um repositório completo e outro receber um arquivo, o resultado comparará fluxos de trabalho além dos modelos.

Comparações de fluxos de trabalho podem ser úteis. Identifique-as corretamente. Um produto de agentes inclui mais que um modelo: seleção de contexto, ferramentas, limites de execução e comportamento de recuperação podem afetar o resultado.

Repita as execuções quando a variação da saída importar. Registre as tentativas que falharam em vez de relatar apenas o melhor resultado. Para critérios subjetivos, use critérios de pontuação escritos e mais de um revisor quando for viável.

Avalie a qualidade antes da velocidade

Primeiro, verifique os critérios obrigatórios de aceitação. A alteração atende ao requisito? Preserva os controles de acesso? Os testes relevantes passam? Um revisor consegue entender o diff?

Depois, compare o esforço, o tempo decorrido e o custo dos resultados aceitáveis. Inclua novas tentativas e revisão humana. Uma resposta barata que exige correções repetidas pode sair cara quando se considera a tarefa inteira.

Benchmarks públicos podem ajudar a identificar candidatos. Eles usam conjuntos específicos de tarefas e métodos de pontuação. Não trate uma pontuação de benchmark como medida direta da produtividade da sua equipe.

Registre a decisão e as condições para reavaliá-la

O resultado pode ser uma recomendação restrita. Por exemplo: “Use este modelo para pequenas adições de testes neste repositório, com as exigências de revisão existentes.” Não é necessário usar um modelo para todas as tarefas.

Informe o que exigiria outra avaliação. Exemplos incluem uma mudança na versão do modelo, uma configuração diferente de ferramenta, uma nova categoria de dados ou um padrão persistente de falhas. Mantenha uma alternativa para tarefas que excedam a capacidade do modelo escolhido.

O objetivo da avaliação é reduzir a incerteza sobre uma decisão real. Evite uma competição permanente entre modelos que consuma mais esforço que o trabalho que ela apoia.