Testes Automatizados
Foi utilizado como ferramenta de estudo a wiki disponibilizado pelo Rasa (https://rasa.com/docs/core/evaluation/#evaluation), no qual se teve conhecimento da utilidade e de como deve ser ministrado. O documento em si, relata as formas disponíveis que a plataforma nos oferece, onde avalia um modelo já treinado com o conjunto de histórias de teste, e no outro usa em conjunto o RASA NLU para analisar as mensagens de intenção. Sendo nossas exigências o caráter de avaliação do fluxo com relação as intenções, escolheu-se a segunda opção, onde se pré define mensagens no formato do usuário e correlacionando-os com as utters_esperadas de acordo com as utters_ocorridas.
Sabe-se que o teste do Rasa nos possibilita avaliar o fluxo de ponta a ponta, com as intenções pré definidas pelo mesmo, desta forma, ele nos disponibiliza uma forma de visualização desse teste no qual ele nos fornece:
- "precision" - quantidade de utters_esperadas divididas pela quantidade de utters_ocorridas
- "recall" - porcentagem de respostas que corresponderam a utter esperada.
- "f1-score" - a porcentagem de relação da precisão com o recall, sendo (2x precisão x recall) / (precisão + recall)
- "support" - o tanto de vezes que teste utiliza cada variável.
Desses dados gera uma matriz pelo script que permite visualizar a distribuição de confiança para todas as previsões
Essa matriz nos permite visualizar a relação entre as utters_esperadas (criadas pelos testes) e as utters_ocorridas (as que realmente foram respondidas mediante ao fluxo), priorizando o fluxo em que a conversa segue e a intenções que as correspondem, como pode ser visto no exemplo acima onde todas as utters_esperadas correlacionam com as utters_ocorridas. Forma-se uma matriz quadrada onde sua coluna 0 e linha 0 são respectivamente, a quantidade de utters_esperadas que correlacionaram com as utters ocorridas + as utters_esperadas que não resultaram em nenhum valor e a action_list (o numero de intenções no teste).
Há apenas uma exceção nesse quesito, quando houver um texto que retorne o fallback, ele criará uma matriz onde a coluna 0 e linha 0 são respectivamente, fallback e NONE. Isso pode ser visto na imagem abaixo no qual o texto retornou um fallback e a relação com a utter_esperada na ultima linha.
Pode-se dizer que as linhas são a utters_esperadas e as colunas são as utters_ocorridas, e os números são as quantidades de vezes que uma utter corresponde a outra ou deixa de corresponder naquele fluxo da conversa. Quando as utters_esperadas são relacionadas com as corretas utters_ocorridas este número irá ficar na diagonal principal sinalizando a quantidade de vezes de correspondência.
Nessa matriz acima pode-se perceber que existem dois números fora da diagonal principal, eles correspondem a utters que não corresponderam a sua respectiva resposta esperada. No número fora da diagonal na linha 0, conclui-se que é uma ação que ocorreu de algum utter que não foi esperada, já no segundo número fora da diagonal é uma utter esperada que não correspondeu a utter_ocorrida.
- Não há como negar que o teste faz uma varredura de ponta a ponta na história criada e a correlaciona com o que realmente irá responder, julgando o fluxo e a intent que as utters correspondem.
- Entretanto a visualização é limitada e de difícil compreensão para uso imediato, tem-se necessidade de um estudo sobre os resultados gerados e vários testes para a compreensão do mesmo.
- Ao encontrar um erro no fluxo, não há uma possibilidade de visibilidade do cume do problema, nesse caso é necessário a revisão de todo o código até o encontro do erro.
O teste é de extrema importância para a identificação de erros no fluxo da TAIS, tendo em vista todos os testes já feitos pelos beta testers, temos um grande acumulo de possíveis fluxos a serem seguidos e serem testados automaticamente, trazendo soluções rápidas para erros que circundam a assistente virtual. Além disso, podemos comprovar a eficacia da TAIS em determinados assuntos e melhorando a mediantes outros. Contudo, como já citado, o teste é de difícil visibilidade no foco do problema, sendo possível apenas identificar a utter que está ocorrendo o erro, mas não localiza-la dentro do fluxo, acarretando mais um empecilho para a equipe de ajuste.