Quando se especifica uma funcionalidade com uma componente de IA, o critério de aceitação deixa de ser «dado X o sistema devolve Y». O critério de aceitação passa a ser uma eval: um conjunto de dados etiquetado, uma função de pontuação e uma pontuação-alvo que o sistema tem de atingir antes do lançamento e novamente após cada troca de modelo ou alteração de prompt. A regra simples: se não conseguir escrever a eval, a funcionalidade ainda não está especificada. Este artigo decompõe as quatro componentes de um critério de aceitação probabilístico e explica como escrevê-las na prática.
O que se parte exatamente numa especificação tradicional
Uma especificação clássica assenta num pressuposto: a mesma entrada produz sempre a mesma saída. Toda a estrutura de testes, definições e condições de saída decorre daí. No momento em que uma componente do sistema é um modelo de linguagem, esse pressuposto desmorona-se, e com ele desmorona-se todo o instrumental construído por cima.
A expressão mais tangível disto é o teste de aceitação. «O utilizador clica em enviar e recebe um resumo do ticket» não é um requisito testável, porque não existe uma única resposta correta. Dois resumos diferentes podem ser ambos excelentes, e um terceiro que parece semelhante pode estar completamente errado. O que é preciso é definir um intervalo de comportamento aceitável em vez de um resultado único.
O teste que poupa meses de desenvolvimento: antes de escrever uma linha de código, tente escrever a eval. Se não conseguir definir o que conta como boa resposta e como medi-la, o requisito ainda está vago. As funcionalidades que encalham em piloto falham quase sempre nesta fase, não na implementação.
As quatro componentes de um critério de aceitação de IA
| Componente | O que define | Exemplo |
|---|---|---|
| Descrição do comportamento | O que o sistema deve fazer, formulado de modo a admitir variabilidade | Um resumo do ticket que contenha o problema, a ação tomada e o estado |
| Limiar de avaliação | Uma pontuação mínima num conjunto de teste reservado, nunca usado no desenvolvimento | 90% dos resumos incluem os três elementos |
| Restrição de segurança | O que constitui uma saída inaceitável, independentemente da pontuação | Nenhum resumo contém alguma vez o número de telefone de um cliente |
| Ponto de retoma humana | O que acontece nos casos que o modelo não consegue resolver | Uma pontuação de confiança baixa encaminha o ticket para uma fila humana |
A diferença entre a segunda e a terceira componente é fundamental. O limiar é estatístico e tolera falhas isoladas. A restrição é binária e não tolera nenhuma. Sem essa separação, fica com uma funcionalidade que passa com 92% de sucesso enquanto uma fuga de dados se esconde nos 8% restantes.
Como construir uma eval sem equipa de investigação
Uma eval não é um projeto. No caso típico são três pequenos ativos mantidos ao longo do tempo:
Um conjunto de dados. Entre 50 e 150 casos reais do sistema existente, incluindo os incómodos. Importa que sejam recolhidos no terreno em vez de inventados, porque os casos inventados são sempre demasiado convenientes. Associe a cada um a resposta que um especialista do domínio daria.
Uma função de pontuação. Não tem de ser sofisticada. Em muitos casos basta verificar a presença de elementos obrigatórios, a conformidade com uma estrutura definida ou a correspondência de palavras-chave. Onde é necessário juízo, pode usar um modelo como juiz, desde que amostre manualmente parte das pontuações para confirmar que o próprio juiz não está a derivar.
Um limiar e uma linha de base. Meça uma vez antes de mudar seja o que for. Sem uma linha de base não consegue saber se uma alteração ao prompt melhorou ou estragou as coisas, e a maioria das equipas descobre isto tarde demais.
Quando executá-la: uma eval não é uma verificação única antes do lançamento. É repetida a cada troca de modelo, a cada alteração de prompt e a cada mudança numa fonte de dados que alimenta o sistema. É precisamente isso que distingue uma eval de um caso de teste, e a razão pela qual deve ser ligada ao processo de build desde o primeiro dia.
Seis secções a acrescentar ao documento de especificação
| Secção | O que leva |
|---|---|
| Especificação do comportamento do modelo | O que o modelo deve fazer, em que tom, e o que está fora de âmbito |
| Limiares de aceitação | As métricas e as pontuações mínimas, incluindo os dados em que são medidas |
| Catálogo de modos de falha | A lista de formas como a funcionalidade pode falhar e o que acontece em cada uma |
| Restrições comportamentais | Linhas vermelhas binárias: o que nunca pode aparecer na saída |
| Plano de avaliação | O conjunto de dados, o método de pontuação e a frequência de execução |
| Dados e privacidade | Que dados entram no prompt e em que nível de classificação |
A última secção liga-se diretamente à vossa política de classificação de dados. Se ainda não a definiram, o modelo de classificação em quatro níveis é o ponto de partida, porque sem ele a especificação vai definir uma capacidade que não estão autorizados a operar.
O catálogo de modos de falha: a secção que mais vale a pena escrever
Num sistema determinístico um modo de falha é um erro. Num sistema com uma componente de IA um modo de falha é normalmente uma resposta que parece perfeitamente correta e não está. O catálogo tem por isso de enumerar as falhas pelo que o utilizador experiencia, não pelo que o sistema reporta.
Quatro são especialmente comuns: uma resposta errada mas confiante, que obriga a citar fontes para ser verificável; uma recusa em responder a uma pergunta legítima, que obriga a uma via alternativa; uma resposta parcial que omite uma condição relevante; e a deriva ao longo do tempo, em que a fonte de dados muda e a saída degrada-se sem que ninguém tenha tocado numa linha de código. A última é a principal razão para uma eval ter de correr periodicamente e não apenas antes do lançamento.
O que isto faz aos prazos e ao orçamento
O impacto prático é uma deslocação do esforço. Numa especificação clássica a maior parte do tempo vai para a definição de ecrãs e fluxos. Numa funcionalidade de IA uma fatia significativa desloca-se para a recolha e etiquetagem de casos de teste, e isso é trabalho de especialista do domínio e não de programador. Orçamentem-no explicitamente, senão é espremido e chegam ao lançamento sem forma de saber se o sistema funciona.
Segunda deslocação: a funcionalidade nunca «acaba». Carrega um custo de manutenção contínuo, o de executar a eval e manter o conjunto de teste. Quando calculam a viabilidade, esse custo pertence ao modelo unitário desde o início em vez de aparecer no segundo trimestre.
E se a funcionalidade responde a partir dos vossos próprios documentos, a especificação tem de cobrir também a camada de recuperação, porque é aí que se decide a maior parte da precisão real. O detalhe completo está no guia da base de conhecimento empresarial. Acompanhamos todo o processo, da especificação ao lançamento, dentro das nossas áreas de especialização.
Perguntas frequentes
O que é uma eval e em que difere de um teste de aceitação normal?
Uma eval é um conjunto de dados etiquetado com uma função de pontuação e um limiar mínimo. Um teste de aceitação normal verifica uma única saída e devolve passa ou falha, enquanto uma eval mede uma distribuição de qualidade em dezenas de casos e é repetida a cada mudança de modelo, prompt ou fonte de dados.
Quantos casos de teste são precisos para começar?
Entre 50 e 150 casos reais do sistema existente chegam para a maioria das funcionalidades. O que importa é que sejam recolhidos no terreno em vez de inventados, e que incluam os casos difíceis e não apenas os convenientes.
Como se escrevem critérios de aceitação para uma saída sem uma única resposta correta?
Definam quatro componentes: uma descrição do comportamento que admita variabilidade, um limiar de avaliação num conjunto de teste reservado, uma restrição de segurança binária que não tolera exceções, e um encaminhamento para uma pessoa nos casos que o modelo não consegue resolver.
Porquê separar o limiar de avaliação da restrição de segurança?
Porque o limiar é estatístico e tolera uma percentagem de falhas, enquanto a restrição é binária. Sem essa separação uma funcionalidade pode passar com pontuação alta enquanto uma violação grave, como a exposição de dados pessoais, se esconde na percentagem de falha.
Pode usar-se um modelo como juiz para pontuar a saída?
Sim, e é um método comum onde é necessário juízo. A condição é amostrar manualmente parte das pontuações e compará-las com o juízo humano, para confirmar que o próprio juiz não está a derivar ao longo do tempo.