Por que o teste de IA generativa quebra a asserção de sempre
Se você afirmar que a resposta é igual a uma string fixa, o teste falha na segunda execução por um motivo que nada tem a ver com o seu produto. Se afrouxar para uma substring, ele passa em uma saída sutilmente errada. Nenhuma das duas opções é útil, e ficar alternando entre elas é o caminho que leva as equipes a concluir que recursos generativos não podem ser testados.
Quais asserções fazer no lugar
| Propriedades | JSON válido, campos obrigatórios presentes, dentro do limite de tamanho, cita uma fonte que existe. Verificável e estável entre execuções. |
| Recusas | Ele recusa o que deve recusar, e faz isso de forma consistente. Muitas vezes, é a verificação de maior valor da suíte. |
| Fundamentação | Toda afirmação remete a algo no contexto fornecido. Pega invenções sem julgar o estilo. |
Taxas, não resultados
Uma única execução não diz nada. Rode a mesma entrada muitas vezes e acompanhe com que frequência a propriedade se mantém. Sua unidade de medida é uma taxa, e seu sinal é uma mudança nessa taxa, não uma falha isolada.
Isso também muda o que significa uma regressão. A pergunta nunca é "está perfeito", e sim "esta mudança piorou o resultado em relação à semana passada".
Como escolher as propriedades a verificar
A parte difícil disso não é a mecânica, é decidir o que verificar quando você não pode verificar a resposta. Um bom caminho é perguntar o que tornaria a saída inutilizável, em vez de o que a tornaria boa.
Inutilizável é concreto: saída malformada que o chamador não consegue interpretar, uma citação a algo que não existe, uma recusa que deveria ter sido uma resposta, uma resposta que deveria ter sido uma recusa, conteúdo que ultrapassa um limite mais adiante no fluxo. Cada um desses casos é binário e verificável, e cada um corresponde a um incidente real, não a uma opinião sobre qualidade.
Bom, por outro lado, é um julgamento que varia de revisor para revisor e não vale a pena codificar como um portão. Acompanhe isso se quiser, com revisão humana por amostragem, e mantenha fora do pipeline, onde vai gerar discussões em vez de decisões.
A parte que se testa normalmente
A maior parte de um produto que contém um recurso generativo é software determinístico comum: autenticação, armazenamento, limitação de requisições, a interface em torno do recurso. Tudo isso deve ser testado de forma convencional, e tratar o produto inteiro como não determinístico porque uma parte dele é faz você perder muita cobertura barata.
Trace a fronteira de forma explícita. Dentro dela, propriedades e taxas. Fora dela, asserções normais contra a aplicação em execução.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Se você prefere não instalar nada, o painel faz a mesma coisa. Todo o resto que a linha de comando permite fazer está no repositório da CLI.
São duas rotas, e a escolha é, na prática, sobre quem é dono do pipeline. Conectar o GitHub App pelo painel não exige nenhuma mudança no seu repositório, porque ele reage ao deploy que o seu build já emite. Adicionar uma etapa do GitHub Actions coloca a verificação no repositório, onde ela passa por revisão como o resto do build.
O que a TestSprite cobre em torno do recurso
A maioria determinística do produto, que para a maior parte das equipes é de longe a maior fatia. Autenticação, armazenamento, limitação de requisições, a interface em torno do recurso e cada fluxo que um usuário realmente percorre são software comum e se testam de forma convencional. Auto-Authentication mantém as sessões ativas ao longo de uma execução, Dynamic Variables levam valores de uma chamada para outra, Dependency Chains derivam a ordem de execução, e Auto-Cleanup remove exatamente o que a execução criou.
A cobertura é gerada a partir do seu produto e refinada em linguagem simples, e roda contra a aplicação implantada a cada mudança, de modo que as partes do sistema que podem ser verificadas com exatidão são verificadas com exatidão.
O recurso generativo em si precisa de propriedades e taxas, o que significa uma estrutura de testes separada, com sua própria noção de aprovação. Traçar essa fronteira de forma explícita é o que impede uma equipe de aplicar métodos estatísticos a código determinístico ou de abandonar de vez as asserções porque as comparações exatas viviam falhando.
Podemos usar uma IA para avaliar a saída?
É comum e funciona, com uma ressalva: o avaliador tem seus próprios modos de falha e precisa da própria calibração. Compare-o com o julgamento humano em uma amostra antes de confiar nele.
Quantas execuções formam uma taxa significativa?
O suficiente para que o número pare de se mexer quando você adiciona mais. Comece com dezenas, não centenas, e observe a estabilidade.
Testes generativos devem bloquear um merge?
Uma queda grande em uma taxa de recusa, sim. Pequenas variações de qualidade, não, ou o pipeline vira ruído.
E o custo?
Execuções repetidas custam dinheiro. Use amostragem em vez de rodar o conjunto completo a cada mudança, e rode o conjunto completo em uma agenda definida.
Testar prompts é a mesma coisa?
É algo relacionado. Mudanças de prompt são a causa mais comum de mudanças nas taxas, o que é um bom argumento para tratar prompts como artefatos versionados.
Propriedades e taxas, não igualdade.
O teste de IA generativa substitui asserções exatas por propriedades, recusas e fundamentação, medidas como taxas ao longo de muitas execuções. Teste normalmente a maioria determinística do produto e trace a fronteira de forma explícita.