TDD aplicado aos fluxos de Chatbot — RASA 💜
Como funciona os fluxos do Rasa?
Rasa é uma tecnologia de chatbot que proporciona a construção de chatbots contextuais, ou seja, permite que Assistentes Virtuais consigam capturar o contexto dos assuntos falados pelos usuários. Mas, como fazemos isso? Temos as intents que são as entradas dos usuários e as entidades que são as partículas que comportam o contexto, tais recursos se encontram no nlu.md, este é o momento de reconhecimento do input do usuário, mas não acabou por aí, temos ainda que ensinar a nossa IA a entender um determinado assunto. É simples, nós destrinchamos uma conversa em uma espécie de estrutura que lembra uma linguagem de programação. Dizemos, se você entender a intent x, a entity x, o slot x pode enviar a utter x (mensagem do bot), este tipo de conteúdo fica armazenado no stories.md, são os fluxos conversacionais do Rasa.
## story_calabresa
* pizza
- utter_sabor
* sabor {“sabor”: “calabresa”}
- slot {“sabor”: “calabresa”}
- utter_pizza
Agora vamos imaginar a conversa referente à story_calabresa:
User: quero uma pizza
Bot: qual sabor?
User: calabresa
Bot: A sua pizza de calabresa está a caminho!
Testes de diálogo do Rasa
O Rasa possui vários testes automatizados, alguns de validação dos dados para termos uma noção da qualidade do cadastramento de dados do nosso bot. E, também possui um teste de diálogo que podemos utilizar para testar conversas reais de usuários. Estes testes de diálogo constituem o arquivo e2e_stories.md:
## end-to-end story 1
* pizza: por favor, quero uma pizza agora
- utter_sabor
* sabor: prefiro a de [calabresa](sabor)
- slot {“sabor”: “calabresa”}
- utter_calabresa
Neste teste podemos simular uma conversa real, é a junção dos dados cadastrados no chatbot com os inputs do usuário. Observe que mudei o input “quero uma pizza” para uma entrada diferente “por favor, quero uma pizza”, da mesma forma “calabresa” se tornou “prefiro a de calabresa”, assim estou testando se o meu chatbot possui a capacidade de abstrair informações novas que não possui em seu código. Vamos ver se funciona?
Correct 1/1: Nós temos um caso de teste cadastrado e ele está correto. Assim, podemos provar que com os dados cadastrados no meu bot, ele consegue entender aquela conversa real do exemplo. Se ele já consegue entender tal diálogo eu preciso cadastrar esta entrada? NÃO! Esta reflexão irá nos ajudar na próxima etapa: TDDD.
Como aplicar o TDD ao desenvolvimento de Stories?
Criamos o TDDD que é o Test Driven Dialogue Development, se você não conhece essa abordagem, tem uma postagem especial para você: Um pouco sobre TDD. Vou resumir um pouquinho, o TDD é uma prática de desenvolvimento voltada a testes. Antes de criar o software, módulos etc. Criamos primeiramente o caso de teste… Quando executamos o caso deve falhar, pois não possuímos aquele componente ainda, depois codamos, testamos até passar, quando passar refletimos em como podemos aprimorar o código. Esta metodologia prioriza a qualidade e é muito eficaz apesar de parecer trabalhosa.
Como isso pode ser útil para um chatbot? Vamos voltar no nosso caso de teste e2e. Se nós não tivéssemos testado aquela story nova, e tivéssemos cadastrado o novo exemplo na intent “por favor, quero uma pizza”, estaríamos perdendo tempo e cadastrando um exemplo de intent do qual não precisamos no nosso código, pois o nosso bot já consegue fazer esta abstração.
Então para usar o TDDD, teríamos sempre que começar pelo caso de teste, mesmo não tendo o determinado assunto, por exemplo poderíamos criar a intent suco com o exemplo “quero um suco”, criar o teste, executar o teste, ver o teste falhar, depois cadastrar o conteúdo no bot, executar o teste novamente e ver o teste passar. Assim, estamos tendo um controle sobre os assuntos que estamos cadastrando no nosso chatbot e tendo a certeza de que não estão afetando negativamente o nosso corpus. Teremos um nlu.md que não traz ruídos, um código limpo, eficiente e sólido.
AH, poxa, mas só isso? Não, tem mais!
Além de ter um código enxuto, podemos observar quais os exemplos de intent estão propensos a confusão com o novo assunto. Pode ocorrer duas situações, o exemplo da intent suco pode cair em fallback, isto ocorre quando seu bot não possui nada parecido com aquele assunto. Deste modo, o bot tem uma confiança abaixo da confiança esperada para enviar uma utter z. Porém, ele pode enviar a utter i com uma confiança baixa. Se ele envia a utter i, sabemos que o assunto suco está propenso a ser confundido com o assunto i. Antes mesmo de ter os dados cadastrados podemos prever a nossa matriz de confusão e pensar em como minimizar falhas.
O TDDD é uma maneira muito eficaz para equipes grandes, em que várias pessoas estão trabalhando no mesmo corpus, evitando que haja cadastramento indevido de dados, impedindo que o bot seja desvirtuado e se torne ineficiente.
PS: Este método foi criado por Raphael Pinto, Arthur Temporim, Paloma C Mamede.
