Teste de regressão LLM: transforme falhas em portas de liberação

As ferramentas atuais conectam falhas de produção a testes off-line

A documentação de avaliação mantida por LangSmith descreve comparações off-line, avaliação on-line e adição de rastreamentos de produção com falha aos conjuntos de dados. A orientação da Anthropic para 2026 também discute conjuntos de regressão dentro de uma prática de avaliação mais ampla. Esses são fluxos de trabalho suportados e não são evidências de que um conjunto automatizado de passagem por si só seja suficiente para o lançamento.

Evidência: Avaliação LangSmith [1]Desmistificando avaliações para agentes de IA [2]

Construa um conjunto de testes em camadas

Rubrex recomenda começar com verificações determinísticas rápidas: formato de saída, campos obrigatórios, identificadores permitidos, aplicação de permissão e cálculos exatos. Adicione verificações semânticas para requisitos como suporte de evidências ou conclusão de tarefas. Mantenha um conjunto menor de testes completos de fluxo de trabalho para comportamento de integração.

Trate o avaliador como uma dependência. Uma alteração em seu prompt ou modelo pode mover pontuações mesmo quando o aplicativo permanece inalterado. Armazene a configuração do avaliador junto com o candidato e a linha de base. Quando uma verificação semântica for instável, investigue sua confiabilidade antes de torná-la um bloqueador de liberação automática.

Defina falhas que uma média não pode desculpar

Escolha portas rígidas para resultados claramente inaceitáveis ​​e separe-as das tendências de qualidade. Por exemplo, uma resposta malformada pode falhar num contrato de integração, independentemente da qualidade da sua prosa. Uma pequena melhoria média não deve compensar uma mudança de estado não autorizada.

Mantenha um processo para resultados inconclusivos. Uma diferença marginal em uma amostra pequena e ruidosa pode justificar mais evidências, em vez de uma aprovação ou reprovação forçada. Registre o proprietário, a decisão e o trabalho de acompanhamento. Um processo de divulgação deve tornar a incerteza visível em vez de codificar limites arbitrários como certeza.

Exemplo ilustrativo: uma alteração de esquema interrompe uma tarefa antiga

Uma equipe adiciona um campo obrigatório à saída gerada. Novos exemplos são aprovados, mas variantes de tarefas mais antigas omitem as informações necessárias para preenchê-las. O modelo inventa um valor para satisfazer o esquema. Um teste estrutural é aprovado enquanto um requisito semântico falha.

Adicione um caso que permita explicitamente informações desconhecidas ou indisponíveis de acordo com o contrato do produto. Teste o esquema e o significado juntos. Preserve as variantes de tarefas anteriores para que a próxima alteração de esquema não possa restringir silenciosamente os casos de uso suportados.

Mantenha as execuções reproduzíveis e as falhas acionáveis

Salve a versão do conjunto de dados, o identificador do modelo, o prompt, o instantâneo de recuperação, a configuração da ferramenta, as saídas, as decisões do juiz e os logs de erros com controles de dados apropriados. Execute o menor conjunto útil durante a iteração e um conjunto de decisões mais amplo antes do lançamento. Após um incidente, adicione um caso de regressão revisado e teste se a correção proposta é generalizada.

• Mantenha falhas conhecidas e casos de rotina representativos.
• Distinguir falhas de ambiente de falhas de tarefas sem descartar nenhuma delas.
• Exigir evidências para atualizar ou remover um teste com falha.
• Mantenha um conjunto resistente para reivindicações além das regressões conhecidas.

Teste LLM e avaliação imediata antes do envio de uma mudança

O teste de LLMs começa com requisitos que sobrevivem a uma mudança no texto. Em uma avaliação de prompt, execute os prompts antigos e novos em entradas idênticas e mantenha as configurações de modelo, ferramenta e recuperação fixas sempre que possível. Pontue primeiro os requisitos exatos e depois inspecione as diferenças semânticas com uma rubrica calibrada. Se várias partes do sistema foram alteradas, rotule o resultado como uma comparação ponta a ponta, em vez de atribuí-lo apenas ao prompt.

Para uma lista de verificação de teste LLM, Rubrex recomenda um caso de rotina, uma falha conhecida, uma entrada incompleta, uma falha de dependência e um caso que deve ser recusado ou transferido. Registre quais verificações foram realizadas, quais foram inconclusivas e quais evidências justificam a liberação. Converta uma falha de produção confirmada em um caso de regressão revisado com um resultado esperado.

Perguntas comuns