Uma resposta de IA não prova que o sistema é confiável

Uma saída isolada não mede um sistema

Uma resposta correta mostra apenas que um sistema de IA consegue realizar uma tarefa uma vez. Ela não informa com que frequência o sistema acerta, quão consistente é nem como se comporta diante da variedade de situações encontradas no uso real. Como modelos de linguagem podem produzir respostas diferentes para a mesma entrada, uma avaliação precisa considerar várias observações, e não uma demonstração bem-sucedida.

Avaliação como estudo quantitativo

A fonte propõe aplicar à IA princípios já usados em estudos quantitativos de experiência do usuário. Em vez de testar uma única tarefa com uma pessoa, pesquisadores definem tarefas representativas, observam muitos participantes e calculam métricas médias, acompanhadas de intervalos de confiança. Na avaliação de IA, os participantes e tarefas são substituídos pelo sistema e por entradas de teste; as métricas podem incluir precisão, sucesso da tarefa ou uma pontuação de qualidade.

O desenho deve incluir múltiplas entradas representativas e várias execuções de cada uma. Em um exemplo de atendimento ao cliente, poderiam ser selecionadas 10 perguntas sobre devoluções, cancelamentos, pedidos danificados, assinaturas e garantias, e cada pergunta poderia ser enviada cinco vezes, gerando 50 respostas. Esses números são apenas ilustrativos, não recomendações universais. Antes do teste, a equipe deveria definir o que é uma resposta aceitável, considerando correção, condições e exceções importantes, consistência com as políticas da empresa e orientação sobre os próximos passos.

A avaliação deveria informar a porcentagem de respostas aceitáveis, um intervalo de confiança, a variação entre perguntas e a consistência das respostas para a mesma pergunta. O intervalo de confiança expressa uma faixa de valores plausíveis para o desempenho médio e lembra que o resultado é uma estimativa, não uma propriedade exata e permanente do sistema. Também é necessário registrar modelo e versão, instruções, configurações, ferramentas, contexto e data, pois mudanças nesses componentes podem exigir nova avaliação.

Duas fontes de variação

A variação entre entradas mostra como o sistema se sai no conjunto de perguntas que usuários podem fazer. Testes compostos principalmente por questões fáceis podem superestimar o desempenho; aumentar a quantidade de entradas não resolve o problema se elas não forem representativas. Já a variação entre execuções mostra se o sistema responde de modo consistente à mesma pergunta. Repetir uma entrada é necessário para distinguir um sistema que realiza a tarefa de forma confiável de outro que acerta apenas ocasionalmente. Mais entradas e mais execuções respondem a perguntas diferentes e uma não substitui a outra.

O significado das falhas

Dois sistemas podem atingir a mesma taxa geral de sucesso e ainda apresentar problemas distintos. Um pode acertar sempre oito de dez tipos de pergunta e falhar consistentemente nos outros dois; outro pode acertar quatro de cinco vezes em cada pergunta. O primeiro é previsível e talvez permita encaminhar certos casos a atendentes humanos. O segundo é menos previsível e pode ser útil quando suas respostas são revisadas antes de chegar ao cliente. A pontuação agregada, sozinha, não revela como as falhas se distribuem.

Aplicação prática

Métricas existentes, como pass@k em avaliações de programação, e classificações com intervalos de confiança mostram que métodos rigorosos já são usados, embora estejam mais concentrados na pesquisa acadêmica. Equipes de produto não precisam reproduzir todos esses métodos, mas deveriam coletar várias observações, considerar as principais fontes de variação e comunicar a incerteza.

O princípio vale para adoção de sistemas, lançamento de recursos e garantia de qualidade. Um teste tradicional que passa uma vez não constitui prova para um sistema não determinístico. Uma única execução pode servir à exploração inicial ou à verificação básica de funcionamento, mas decisões relevantes - como lançar uma funcionalidade, escolher um fornecedor ou alegar melhoria - deveriam usar entradas representativas, execuções repetidas, médias, intervalos de confiança e dados de consistência. Se repetir os testes for caro demais, a conclusão honesta é que as evidências são insuficientes.