Escolha um modelo com base em provas

Defina a decisão

Uma comparação de modelos exige uma utilização concreta. Um modelo que explica bem uma função pequena pode não ter o mesmo desempenho numa alteração ampla ao repositório. Um modelo mais barato pode satisfazer a qualidade exigida para transformações de rotina. Uma investigação difícil pode exigir maior capacidade de raciocínio.

Comece por escrever 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. Uma pontuação alta noutro critério não compensa o incumprimento de uma restrição de tratamento de dados.

Use tarefas representativas

Crie um pequeno conjunto de avaliação com trabalho que a equipa realmente faz. Retire os dados sensíveis, a menos que o ambiente de avaliação esteja aprovado para esses dados. Inclua tarefas simples, tarefas difíceis e casos em que a resposta correta é pedir informação em falta.

Para um serviço fictício de relatórios, use um defeito conhecido de datas, uma pequena funcionalidade de filtragem e a 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 para avaliação, sem as usar no desenvolvimento do prompt. Se ajustar repetidamente o prompt a todos os exemplos, a pontuação final pode sobrestimar o desempenho geral. Um conjunto separado ajuda a perceber se o prompt melhorado funciona para além dos exemplos usados na sua criação.

Mantenha uma comparação justa

Registe 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 o repositório completo e outro apenas um ficheiro, o resultado compara processos de trabalho além de modelos.

Comparar processos também pode ser útil. Identifique corretamente o que está a comparar. Um produto com agentes inclui mais do que um modelo: a seleção de contexto, as ferramentas, os limites de execução e o comportamento de recuperação podem influenciar o resultado.

Repita as execuções quando a variação dos resultados for relevante. Registe as tentativas falhadas em vez de apresentar apenas o melhor resultado. Para critérios subjetivos, use uma grelha de avaliação escrita e, quando for viável, mais do que um revisor.

Avalie a qualidade antes da rapidez

Comece pelos critérios de aceitação obrigatórios. A alteração cumpre o requisito? Preserva os controlos de acesso? Os testes relevantes passam? Um revisor consegue compreender o diff?

Depois compare o esforço, o tempo decorrido e o custo dos resultados aceitáveis. Inclua novas tentativas e a revisão humana. Uma resposta barata que exija correções repetidas pode sair cara no conjunto da tarefa.

Os benchmarks públicos podem ajudar a identificar candidatos. Usam conjuntos de tarefas e métodos de pontuação específicos. Não trate a pontuação de um benchmark como medida direta da produtividade da sua equipa.

Registe a decisão e as condições para a rever

O resultado pode ser uma recomendação limitada. Por exemplo: «Usar este modelo para pequenas adições aos testes neste repositório, mantendo os requisitos de revisão existentes.» Não precisa de um único modelo para todas as tarefas.

Indique o que exigiria outra avaliação. Por exemplo, uma mudança de versão do modelo, outra configuração de ferramentas, uma nova categoria de dados ou um padrão persistente de falhas. Mantenha uma alternativa para tarefas que excedam a capacidade do modelo escolhido.

A avaliação serve para reduzir a incerteza de uma decisão real. Evite uma competição permanente entre modelos que consuma mais esforço do que o trabalho que deveria apoiar.