Um prompt pode funcionar muito bem em uma conversa e falhar quando recebe outro cliente, outro formato de documento ou uma instrução incompleta. A resposta convincente do primeiro teste não demonstra consistência. Para decidir se um prompt merece entrar na rotina, é mais seguro tratá-lo como uma hipótese e submetê-lo a casos definidos antes de ver o resultado.
Este guia mostra como montar uma avaliação pequena, manual e reproduzível. Você não precisa programar nem contratar uma plataforma de testes. Uma planilha com entradas, critérios, resultados e observações já permite comparar versões do prompt sem depender da memória ou da impressão de que uma resposta “pareceu melhor”.
A orientação da OpenAI sobre avaliações recomenda testes específicos para a tarefa, registro dos resultados e combinação de métricas com julgamento humano. A documentação da Anthropic também parte de critérios específicos e mensuráveis e pede casos que reflitam a distribuição real da tarefa, inclusive situações de borda. O método abaixo adapta esses princípios para uma rotina de trabalho sem automação.
A imagem de capa é uma ilustração editorial exclusiva do Bastidores da IA. Não é captura de tela, interface real, painel de avaliação ou evidência de um teste executado.
Resultado esperado
Ao final, você terá uma ficha de avaliação com a finalidade do prompt, critérios de aprovação, pelo menos oito casos de teste, respostas preservadas, resultados comparáveis e uma decisão registrada: aprovado para o escopo, aprovado com supervisão ou reprovado até nova revisão.
O resultado não certifica o modelo nem torna qualquer saída automaticamente correta. Ele mostra como uma versão específica do prompt se comportou, em uma data, com um conjunto conhecido de entradas e sob condições registradas. Mudanças no modelo, nas ferramentas conectadas, nas fontes ou na própria tarefa podem exigir uma nova rodada.
Pré-requisitos
- Escolha uma tarefa repetida e delimitada, como resumir chamados, classificar solicitações ou preparar uma primeira versão de resposta.
- Separe exemplos reais já autorizados para teste ou crie exemplos sintéticos sem dados pessoais, segredos e informações de clientes.
- Defina quem conhece o assunto e pode revisar respostas duvidosas.
- Registre modelo, produto, data, configurações relevantes e ferramentas conectadas.
- Preserve a versão exata do prompt. Não corrija o texto no meio de uma rodada.
Se a tarefa envolve saúde, crédito, contratação, direitos, segurança, finanças ou outra decisão de alto impacto, um conjunto pequeno não basta para autorizar uso autônomo. Nesses casos, use a avaliação apenas como triagem e exija validação especializada, controles de privacidade e critérios proporcionais ao risco.
Passo 1: descreva a tarefa em uma frase observável
Evite objetivos como “responder melhor” ou “ser mais inteligente”. Escreva o comportamento que alguém consegue verificar. Exemplo: “Transformar a descrição de um chamado em resumo de até cinco linhas, separar fato de hipótese e listar a próxima ação sem inventar prazo”.
Registre também o que fica fora do escopo. O prompt não deve aprovar reembolso, diagnosticar a causa definitiva nem enviar a resposta ao cliente. Esse limite impede que um teste de redação seja interpretado como autorização para uma decisão operacional.
O NIST inclui contexto, finalidade, limites de conhecimento e supervisão humana entre os elementos que devem ser documentados ao avaliar sistemas de IA. O núcleo do AI Risk Management Framework também orienta testar antes da implantação e continuar medindo durante o uso.
Passo 2: transforme qualidade em critérios verificáveis
Escolha de três a cinco critérios que realmente mudam a decisão. Para o exemplo do chamado, uma ficha simples pode usar:
- Fidelidade: nenhum fato novo foi acrescentado.
- Cobertura: problema, impacto e próxima ação aparecem quando estão presentes na entrada.
- Separação: hipóteses são rotuladas e não aparecem como causa confirmada.
- Formato: o resumo respeita cinco linhas e a estrutura pedida.
- Segurança: a resposta não expõe dado desnecessário nem executa decisão fora do escopo.
Defina a regra antes de rodar o teste. Um critério pode receber “passa”, “falha” ou “revisão necessária”. Use falhas bloqueantes para comportamentos que invalidam a resposta, como inventar um prazo, omitir uma negativa, expor um identificador ou afirmar uma causa sem evidência. Não esconda uma falha grave em uma média alta.
Passo 3: monte um conjunto mínimo que represente a rotina
Comece com oito a doze casos. Quantidade sozinha não garante representatividade, mas um único exemplo quase sempre favorece uma conclusão apressada. Inclua entradas de tipos diferentes:
- um caso comum, completo e bem escrito;
- um caso curto, mas suficiente;
- um caso longo com detalhes irrelevantes;
- um caso ambíguo, que deveria gerar pedido de esclarecimento;
- um caso contraditório, com duas informações incompatíveis;
- um caso sem o dado necessário para concluir;
- um caso contendo dado sensível que não deve reaparecer;
- um caso fora do escopo, que a IA deveria recusar ou encaminhar.
Os exemplos devem refletir o trabalho real, não apenas situações fáceis. A OpenAI recomenda que avaliações sigam a distribuição de produção e que os registros de uso alimentem novos casos. A Anthropic destaca situações de borda. Na prática, guarde falhas reais devidamente anonimizadas e acrescente uma linha ao conjunto quando surgir um padrão novo.
Passo 4: crie a planilha de execução antes de gerar respostas
Use uma linha por caso e colunas para identificador, entrada, motivo do caso, resultado esperado, critérios, resposta obtida, versão do prompt, ambiente, data, avaliador e observações. Evite colocar apenas uma nota geral. Uma resposta pode cumprir o formato e falhar em fidelidade.
O resultado esperado não precisa ser um texto perfeito. Para tarefas abertas, registre os elementos obrigatórios e proibidos. Exemplo: “deve dizer que o prazo não foi informado; não pode propor uma data; deve pedir confirmação ao responsável”. Isso torna a revisão mais consistente sem fingir que existe uma única redação correta.
Se você pretende comparar duas respostas lado a lado, o guia interno sobre como comparar respostas com critérios reproduzíveis ajuda a controlar ordem, contexto e preferência por estilo. Aqui o foco é testar uma regra de trabalho ao longo de vários casos.
Passo 5: congele o prompt e execute a primeira rodada
Copie o mesmo prompt para todos os casos. Mantenha constantes o modelo, as ferramentas, o contexto adicional e qualquer configuração disponível. Se o produto não mostra esses detalhes, registre pelo menos o nome do serviço, a data e se houve pesquisa na web, acesso a arquivos ou conexão com contas.
Salve a resposta bruta antes de editar. Não dê uma dica adicional apenas nos casos difíceis, pois isso cria outra versão do teste. Quando o prompt depende de um documento, mantenha o mesmo método de anexação e anote qual arquivo foi usado.
Como sistemas generativos podem variar, repita os casos bloqueantes pelo menos mais uma vez. Duas execuções não medem toda a variabilidade, mas revelam rapidamente um prompt que alterna entre respeitar e ignorar a mesma regra. Para uma adoção ampla, aumente amostra, diversidade e repetição conforme o risco.
Passo 6: avalie sem reescrever a resposta
Compare cada saída com a ficha e marque os critérios separadamente. Quando houver dúvida factual, volte à entrada e à fonte autorizada. Não peça ao mesmo chat que atribua a nota final à própria resposta sem uma rubrica clara e sem conferência humana.
Avaliação automática pode ajudar em regras objetivas, como presença de um campo, limite de caracteres ou formato válido. Julgamentos como fidelidade, tom apropriado e omissão relevante exigem contexto. A documentação oficial da OpenAI recomenda combinar métricas com julgamento humano, e o NIST afirma que revisão independente pode reduzir vieses do processo de medição.
Quando possível, peça a uma segunda pessoa para avaliar ao menos os casos bloqueantes sem ver sua nota. Divergência entre avaliadores é um achado. Ela pode indicar que o critério está vago, que o resultado esperado é discutível ou que a tarefa precisa de conhecimento especializado.
Passo 7: altere uma coisa por vez e rode novamente
Liste as falhas por padrão. Se três respostas inventaram prazos, acrescente uma regra direta e um comportamento alternativo, como “se o prazo não estiver na entrada, escreva ‘prazo não informado’ e peça confirmação”. Se o problema foi formato, ajuste a estrutura. Se foi conhecimento ausente, o prompt sozinho talvez não resolva.
Crie uma nova versão, por exemplo V2, e execute todos os casos novamente. Não teste apenas a entrada que falhou. Uma correção pode melhorar segurança e piorar cobertura, ou tornar o texto tão rígido que os casos comuns perdem utilidade.
Preserve V1, V2, as respostas e a decisão. O guia interno sobre registro mínimo de uma tarefa feita com IA oferece uma base para documentar versão, fontes, revisão e aprovação.
Passo 8: decida o uso permitido e programe nova avaliação
Uma regra simples de decisão pode ser: nenhuma falha bloqueante, todos os casos comuns aprovados e casos ambíguos encaminhados corretamente. Registre também onde o prompt pode ser usado, quem revisa a saída e quais ações continuam proibidas.
Use três estados em vez de um “funciona” absoluto:
- Aprovado para o escopo: passou nos critérios definidos e ainda exige o controle humano registrado.
- Aprovado com restrição: serve para rascunho ou triagem, mas não para decisão ou envio direto.
- Reprovado: apresentou falha bloqueante ou inconsistência que não foi resolvida.
Repita a avaliação quando o prompt mudar, quando o modelo ou produto for atualizado, quando novas ferramentas forem conectadas ou quando aparecer uma falha no uso real. Avaliação é um ciclo, não uma aprovação permanente.
Exemplo ilustrativo
Uma equipe quer usar IA para transformar relatos internos em respostas preliminares de suporte. Ela cria dez casos sintéticos. O primeiro prompt passa nos casos completos, mas inventa prazo em dois casos incompletos e repete um número de contrato que deveria ser omitido.
A equipe classifica as duas ocorrências como bloqueantes, ajusta o prompt para declarar informação ausente e remover identificadores, depois roda todos os dez casos outra vez. A nova versão não inventa prazo, mas deixa de informar a próxima ação em um caso comum. A equipe corrige apenas essa regra e executa uma terceira rodada.
A versão final é aprovada somente para gerar rascunhos. Uma pessoa continua responsável por conferir a fonte e enviar a resposta. O exemplo é fictício e não representa teste real, cliente, ferramenta ou taxa de desempenho.
Erros comuns
- Aprovar o prompt porque uma resposta ficou boa.
- Criar somente casos fáceis e completos.
- Mudar o prompt no meio da rodada sem registrar nova versão.
- Dar notas depois de ver as respostas, sem critérios prévios.
- Usar média para esconder uma falha grave.
- Copiar dados reais para o teste sem autorização ou anonimização.
- Confundir formato correto com fato correto.
- Usar outro modelo como avaliador sem validar a rubrica.
- Não repetir casos críticos diante da variabilidade da geração.
- Tratar aprovação como permanente após mudar modelo, ferramenta ou contexto.
Checklist antes de adotar
- A tarefa e o que está fora do escopo estão escritos.
- Os critérios são específicos, observáveis e definidos antes das respostas.
- O conjunto inclui casos comuns, incompletos, ambíguos, contraditórios e fora do escopo.
- As entradas não expõem dados pessoais, confidenciais ou segredos.
- Prompt, modelo, ferramentas, arquivos e data foram registrados.
- As respostas brutas foram preservadas.
- Falhas bloqueantes não foram diluídas em uma média.
- Uma segunda pessoa revisou os casos de maior risco quando necessário.
- A versão aprovada, suas restrições e o responsável humano estão claros.
- Existe um gatilho para repetir a avaliação.