Introdução

Ao criar um aplicativo de IA ou modificar um aplicativo existente, você precisa verificar se ele se comporta como esperado. Com avaliações, você pode testar um conjunto de cenários de forma sistemática e detectar regressões antes que elas cheguem aos usuários.

Você pode usar o Promptfoo para executar avaliações no seu aplicativo de IA e contar com o Codex para criá-las e mantê-las.

Como usar

Use o Codex com a habilidade $promptfoo-evals do plugin do Promptfoo para criar uma suíte de avaliações que você possa executar repetidamente para testar um comportamento específico do aplicativo de IA. Se o aplicativo ainda não tiver um alvo de teste funcional no Promptfoo, $promptfoo-provider-setup ajuda a conectar a suíte ao fluxo do aplicativo que você quer testar.

O Codex pode examinar o aplicativo, propor casos com boas chances de revelar problemas, adicionar a configuração do Promptfoo e os dados de teste, executar a suíte localmente e fornecer um comando que você possa reutilizar.

Este caso de uso funciona melhor quando você tem algo concreto para verificar, como a qualidade das respostas de suporte, a fundamentação das respostas nos documentos recuperados, os rótulos atribuídos por um classificador, as chamadas a ferramentas, a estrutura do JSON, as regras de negócio ou a preservação do comportamento ao migrar para outro prompt ou modelo.

A primeira versão deve incluir código e dados de teste que você possa revisar. Isso inclui um arquivo promptfooconfig.yaml ou uma configuração equivalente, um pequeno diretório evals/, casos de teste, o adaptador necessário para chamar o aplicativo, se for o caso, e um comando para execução local, como npm run evals.

Escolha o que avaliar

Comece com um comportamento que o produto promete ao usuário e que ele pode observar. Evite pedir ao Codex que avalie todo o sistema de IA de uma só vez. Com uma suíte menor, fica mais fácil revisar os casos, confiar nos resultados e continuar executando os testes.

Alguns bons pontos de partida são:

• Correção: classificação, extração, resumo, roteamento ou transformação.
• Fundamentação: respostas que devem se basear nos documentos recuperados ou nas fontes citadas.
• Uso de ferramentas: escolha da ferramenta certa, passagem de argumentos válidos e tratamento de erros das ferramentas.
• Formato ou regras de negócio: schemas JSON, nomes de campos, limites definidos pelas regras de negócio ou requisitos que os textos exibidos na interface devem cumprir.
• Migração de prompt ou modelo: verificação de que os casos importantes continuam funcionando após uma mudança de prompt, modelo, mensagem de sistema ou configuração de recuperação de documentos.

Use como ponto de partida os requisitos do produto, os relatos de bugs, os chamados encaminhados pelo suporte ou exemplos dos quais foram removidos os dados sensíveis e que a equipe se sinta à vontade para incluir no repositório.

Peça um plano de avaliação

O Codex deve examinar o aplicativo antes de editar os arquivos. Peça um plano que identifique o fluxo a testar, os dados de preparação dos testes, as asserções, o adaptador e os comandos. Assim, você pode perceber se o plano aponta para o fluxo errado ou propõe casos de teste pouco úteis antes que o Codex adicione arquivos.

Revise o plano antes da implementação. Ele deve indicar o fluxo do aplicativo ou o endpoint que o Promptfoo vai chamar, os casos de teste iniciais, as asserções, os arquivos que o Codex vai criar, o comando para execução local e os segredos ou serviços necessários. Se o plano testar diretamente o modelo em vez de percorrer o fluxo que os usuários acessam no aplicativo, pergunte ao Codex se essa escolha foi intencional.

Implemente, execute e refine

Quando o plano estiver correto, peça ao Codex que o implemente. A primeira implementação deve ser simples. Basta incluir a configuração, os casos, os dados de preparação dos testes, um adaptador para o alvo de teste se necessário, um comando e a confirmação de que ele foi executado.

Uma suíte pequena que testa o aplicativo diretamente pode ter a seguinte estrutura:

evals/
  promptfooconfig.yaml
  tests/
    cases.yaml
  providers/
    provider.js  # only if the built-in provider cannot call the app directly

Execute a suíte antes de alterar o comportamento do aplicativo. Os resultados iniciais mostram se o aplicativo já falha em algum dos casos, se as asserções precisam de ajustes ou se há algum problema com o adaptador. Ajuste as asserções quando elas falharem por detalhes irrelevantes ou forem vagas demais, mas mantenha visíveis as falhas reais do produto.

Depois da primeira execução, use a suíte para comparar os resultados antes e depois de cada alteração no aplicativo, ainda antes do lançamento. Adicione casos sempre que um bug, um requisito de lançamento ou uma revisão do produto revelar um comportamento que você quer manter estável. Quando o comando local estiver estável, peça ao Codex que o adicione à integração contínua ou à lista de verificação de lançamento.