“Parecia bom quando eu testei” é como a maioria das regressões de prompts chega à produção. Teste e avaliação de prompts substituem isso por evidência: um conjunto fixo de entradas, uma definição de saída correta e uma verificação que roda toda vez que o prompt muda.
Os dois termos se sobrepõem. Avaliação é medir quão bom é um prompt ou sua saída. Teste é executar essas medições automaticamente e falhar quando um limite não é atingido.
Duas coisas que você pode avaliar
O próprio prompt. Ele é claro, completo, consistente e seguro como está escrito? Isso é análise estática. Não precisa de nenhuma chamada a modelo, então é instantânea, gratuita e dá o mesmo resultado sempre.
A saída do modelo. Dado este prompt e esta entrada, a resposta está correta? Isso exige chamadas ao modelo e uma forma de julgar o resultado.
Elas pegam problemas diferentes, e um bom processo usa as duas. As verificações estáticas rodam a cada tecla e a cada commit. A avaliação de saída roda quando uma mudança pode afetar o comportamento.
Camada 1: verificações estáticas do prompt
Uma verificação estática lê o texto do prompt e procura defeitos conhecidos:
- Nenhum objetivo declarado, ou nenhum formato de saída.
- Palavras vagas e tamanhos sem números.
- Instruções que se contradizem ou se repetem.
- Variáveis de modelo sem delimitação.
- Formulações de injeção, credenciais ou dados pessoais.
- Contagem de tokens acima de um orçamento.
É isso que faz a avaliação de prompts do PromptFlowEngine. A pontuação é 100 menos uma penalidade fixa por achado (30 para crítico, 10 para aviso, 3 para informativo), limitada a 50 quando algo é crítico, com a mesma aritmética para cada uma das oito dimensões. Como a fórmula é publicada, uma mudança de pontuação sempre pode ser rastreada até um achado específico.
Uma pontuação estática não diz se a resposta do modelo está certa. Ela diz se o prompt dá ao modelo uma chance justa.
Camada 2: um conjunto de testes
Um conjunto de testes é uma lista de entradas com expectativas. Comece pequeno.
| Tipo de caso | Por quê |
|---|---|
| Entradas típicas | Confirma que o caminho principal funciona |
| Casos extremos | Vazio, muito longo, idioma errado, malformado |
| Entradas adversariais | Tentativas de sobrepor as instruções |
| Falhas passadas | Cada bug encontrado vira um teste permanente |
Vinte casos bem escolhidos valem mais que duzentos quase duplicados. Tire-os do tráfego real quando puder, com os dados pessoais removidos.
Camada 3: decidir se uma saída passa
Use o método mais barato capaz de julgar a propriedade.
Asserções de código. Determinísticas e gratuitas. Use-as sempre que possível.
- É analisada como JSON e corresponde ao esquema.
- Contém, ou não contém, uma determinada string.
- Tamanho dentro dos limites.
- O rótulo é igual ao rótulo esperado.
- Resposta numérica dentro da tolerância.
Comparação com referência. Compare com uma boa resposta conhecida por correspondência exata ou uma medida de similaridade. Adequada para extração e classificação, fraca para escrita aberta.
Avaliação por modelo. Um segundo modelo julga a saída segundo uma rubrica. Use-a para qualidades que o código não consegue verificar: fidelidade a uma fonte, tom, completude.
You are grading an answer against a source document.
Does the answer contain any claim not supported by the source?
Reply with a JSON object: {"unsupported_claims": [string], "pass": boolean}.
<source>{{source}}</source>
<answer>{{answer}}</answer>
Os avaliadores por modelo são, eles mesmos, prompts, com seus próprios modos de falha. Limite cada rubrica a uma pergunta, peça a evidência antes do veredito e confira o avaliador com uma amostra de julgamentos humanos antes de confiar nele.
Revisão humana. O padrão de referência, e o mais caro. Use-a para calibrar os métodos automáticos e revisar uma amostra da saída de produção.
Métricas que valem a pena acompanhar
| Métrica | O que ela diz |
|---|---|
| Taxa de aprovação | Parcela dos casos de teste que atendem às expectativas |
| Validade do formato | Parcela das saídas que são analisadas corretamente |
| Fidelidade | Parcela das respostas sustentadas pelo contexto fornecido |
| Precisão de recusa | Recusa o que deve, responde o que deve |
| Consistência | Concordância entre execuções repetidas de uma entrada |
| Tokens e latência | Custo da qualidade que você obtém |
Informe a taxa de aprovação junto com o número de casos. “90%” em 10 casos é uma falha.
Lidando com o não determinismo
O mesmo prompt e a mesma entrada podem produzir saídas diferentes. Leve isso em conta:
- Defina a temperatura baixa para tarefas que exigem consistência.
- Execute cada caso várias vezes e informe a taxa de aprovação, não um único resultado.
- Faça asserções sobre propriedades (“menciona o prazo de reembolso”) em vez do texto exato.
- Fixe a versão do modelo e reexecute a suíte quando ela mudar.
Testes de regressão na CI
Os testes só protegem você se rodarem automaticamente.
A cada commit: verificações estáticas. São rápidas e não precisam de chave de API. A barreira de teste de prompts faz uma pull request falhar quando um arquivo de prompt cai abaixo de uma pontuação mínima, excede um limite de tokens ou contém um achado crítico, como uma chave vazada.
- run: promptflow check "prompts/**/*.md" --min-score 70 --max-tokens 1500
Em mudanças de prompt ou de modelo: o conjunto de testes de saída, com um limite de taxa de aprovação.
Em agenda: o conjunto completo contra o modelo em produção, para detectar mudanças do lado do provedor.
O PromptFlowEngine cobre o primeiro desses itens. Ele não executa prompts contra um modelo; a avaliação de saída exige seu próprio executor de testes e acesso ao modelo.
Comparando duas versões
Ao escolher entre rascunhos, compare-os nas mesmas entradas e observe o que mudou, não só os totais: quais casos passaram de aprovado a reprovado, como os tokens se moveram e se algum problema novo foi introduzido. A visualização de comparação no espaço de trabalho informa as diferenças de qualidade, tokens e custo entre dois prompts e lista os achados que cada versão resolve ou introduz.
Um processo mínimo para começar
- Execute a verificação estática e corrija os avisos.
- Escreva 20 casos de teste com expectativas.
- Adicione asserções de código para formato e conteúdo obrigatório.
- Registre a taxa de aprovação de referência.
- Condicione as pull requests à verificação estática.
- Reexecute o conjunto de testes sempre que o prompt ou o modelo mudar.
Para saber como usar esses resultados para melhorar um prompt, veja a otimização de prompts. Para manter versões e resultados organizados, veja o gerenciamento de prompts.