Diversas ferramentas foram utilizadas para o desenvolvimento deste pro- jeto. Algumas destas foram escolhidas em função do padrão utilizado no ambiente de desenvolvimento a Superintendência de Informática da UFRN (SINFO) e outras foram escolhidas após pesquisas e avaliações realizadas. Abaixo estão lis- tadas e brevemente introduzidas as principais ferramentas utilizadas no projeto: linguagem, softwares e principais bibliotecas.
Java
Java é uma linguagem de programação de propósito geral que tem como conceito principal a orientação a objetos. Derivada da linguagem C, ela foi iniciada em 1991 por James Gosling, Mike Sheridan e Patrick Naughton, e hoje é considerada juntamente à própria linguagem C e à C++, uma das mais populares linguagens
de programação (BYOUS, 1998;ORACLE, 2015).
Todo o projeto deste assistente virtual tem como base a linguagem Java, isto por- que, além de terem sido encontradas ferramentas de licença livre adequadas para o desenvolvimento do projeto - as quais serão mencionadas a seguir - também foi levado em consideração que os demais sistemas desenvolvidos e/ou em desenvolvi- mento na SINFO a utilizavam.
Spring
Spring é um web framework que permite a criação de modelos compreensíveis de programação e con guração. Ele foi criado por Rod Johnson e teve sua primeira
versão publicada em 2002. (JOHNSON,2006;PITOVAL,2018) No contexto deste
projeto, o Spring é utilizado para estruturar todo o funcionamento do módulo administrativo, facilitando a comunicação com o banco de dados.
Thymeleaf
Thymeleaf é um software de código aberto criado por Daniel Fernández, ele é uma ferramenta para desenvolvimento/con guração de templates para Java. Pos- sui total integração com o Spring Framework e tem capacidade para processar
os formatos XML, XHTML, CSS, Javascript e HTML (THYMELEAF, 2018). O
Thymeleaf é utilizado no projeto dentro do código HTML das páginas do módulo administrativo, com o objetivo exibir as consultas e permitir a manipulação dos dados exibidos.
Apache OpenNLP
Apache OpenNLP é uma biblioteca Java da Apache que possui algumas ferra-
mentas relacionadas ao PLN (APACHE FOUNDATION,2018). Neste projeto, foi
utilizado o módulo nameFinder da biblioteca para realizar a extração de entidades, técnica que permite a identi cação de palavras-chave no texto.
Deeplearning4j
Deeplearning4j, ou DL4J, é uma biblioteca Java de código aberto lançada em 2014 pela Skymind, que desde 2017 faz parte da Eclipse Foundation. DL4J per- mite ao usuário projetar seu próprio modelo de redes de aprendizado profunda (SKYMIND, 2018). Neste projeto, o DL4J foi utilizado para arquitetar uma rede neural convolucional, que é utilizada para realizar a identi cação das intenções nas mensagens recebidas pelo bot.
API de Sistemas da UFRN
A API de Sistemas da UFRN é uma interface de programação de aplicação que tem por objetivo permitir aos seus usuários o acesso aos dados referentes à UFRN e
aos seus funcionários e alunos, mediante identi cação e autorização prévia (SINFO,
2018). É através da API que é possível ao chatbot obter informações associadas a
um usuário especí co e às suas turmas. PostgreSQL & pgAdmin
O banco de dados interno da aplicação foi construído no pgAdmin, que é uma fer-
ramenta de gerenciamento de bancos de dados PostgreSQL (PGADMIN,2018). O
PostgreSQL é um sistema de bancos de dados objeto-relacionais (POSTGRESQL,
2018). Os bancos de dados em PostgreSQL são um dos padrões utilizados pela
SINFO.
4.3 Funcionamento
4.3.1 Administrador
O módulo administrador trabalha com o banco de dados interno da aplica- ção. Para isto, este módulo é composto por conjuntos de páginas web, em HTML, cada um representando uma tabela existente no banco de dados. As páginas de cada conjunto tem por objetivo criar, editar, exibir ou listar. Para o funcionamento adequado destas páginas, são criadas quatro classes Java para cada conjunto, se-
guindo a lógica do framework Spring utilizado: Model, Repository, Service e Con- troller.
Neste módulo é possível preparar os arquivos para treino, tanto da rede neural, quanto do reconhecedor de intenções. Também é possível visualizar as mensagens recebidas pelo bot e corrigir a intenção identi cada, caso a mensagem tenha sido classi cada erradamente. Além disso, pode-se adicionar palavras-chave que, se identi cadas na mensagem enviada por um usuário, esta receberá um peso maior, ganhando prioridade de visualização.
Todas as entradas salvas neste módulo e que serão encaminhadas para a rede neural são em formato de texto. Cada intenção é salva como um bloco único de texto, contendo diversas formas diferentes do usuário transmitir esta intenção, e cada entidade é adicionada individualmente e marcada com seu tipo.
4.3.2 Processador
O módulo processador se responsabiliza pela parte de conversação com o usuário, ele é capaz de receber a entrada (mensagem), utilizar as técnicas de inteli- gência arti cial para extrair da entrada as informações necessárias, e então utilizar estas informações para decidir o tipo de resposta que dará ao usuário e também sua formulação.
Inicia-se o módulo pelos treinamentos do reconhecedor de entidades e da rede. Primeiramente, é realizado o treinamento da rede neural, que recebe os dados de todas as intenções existentes no banco de dados, linha por linha. Em seguida, o reconhecedor de entidades é treinado com padrões de entrada pré-de nidos em código, que utilizam os dados das entidades e sinônimos salvos no banco de dados
para gerar textos marcados como os vistos na seção2.3.3. Com estes dois treinados,
o bot está apto a receber as mensagens dos usuários, cando a espera delas. Uma vez que uma mensagem é enviada, o chatbot veri ca se há algum assunto pendente, ou seja, se o usuário está respondendo algum questionamento feito pelo próprio programa. Caso haja, a resposta é encaminhada à função de continuação, que é responsável por dar continuidade ao uxo de conversa em curso. Caso não haja, é veri cado em seguida se há alguma marcação (tag) no início do
texto recebido e, se houver, o bot considerará isso como um comando e a mensagem será encaminhada à função responsável por eles. Caso também não haja marcação, o texto será nalmente tratado pelo reconhecedor de entidades e passará pela rede neural, onde será classi cado e então encaminhado à função seletora geral.
Usuário envia mensagem
Sim Há assuntopendente? Não
Há marcação inicial?
Trata continuação Sim Não
Chama função da marcação
Realiza classificação da mensagem
Figura 7 Fluxograma do funcionamento da função principal.
As funções seletoras são separadas em três tipos: de continuação, de marca- ção e geral. Estas funções possuem o objetivo simples de encaminhar a mensagem à sua função de resposta correta. A função seletora geral utiliza a intenção iden- ti cada pela rede neural para selecionar a função especí ca correta, enviando à função também as entidades identi cadas. A função de marcação seleciona exclu- sivamente pela marcação inicial identi cada, passando à função de resposta o texto subsequente. A função de continuação tem por objetivo permitir um uxo de con- versa entre o chatbot e o usuário, permitindo ao bot realizar questionamentos ao usuário em caso de informações incompletas ou até mesmo permitir uma interação ao estilo de preenchimento de formulário para o caso de algumas tarefas mais complexas.
Finalmente, as funções de resposta são as responsáveis em montar a resposta ao usuário, utilizando-se dos parâmetros passados pela função seletora e/ou de
acessos à API de Sistemas. Uma vez montada, a resposta é retornada à função principal, que responde ao usuário.
A Figura 8 é uma representação esquemática do procedimento descrito
acima, incluindo também a relação com o aplicativo de mensagens externo uti- lizado pelo usuário. Na gura é possível ver que toda interação deverá iniciar no usuário e encerrar no aplicativo, com a função principal, descrita no início desta seção, sendo a responsável por realizar a comunicação direta.
FUNÇÃO SELETORA
PRINCIPAL
Geral
de Marcação
de Continuação RESPOSTA FUNÇÃO
APLICATIVO DE MENSAGENS
USUÁRIO
CHATBOT
EXTERNO Variáveis de estado
RESPOSTA
S S
Banco de dados
API
Figura 8 Representação do funcionamento do módulo processador.
4.4 A rede convolucional
A rede neural convolucional foi construída com o auxílio a biblioteca De- eplearning4j e foi projetada para funcionar como um classi cador de intenções.
O modelo inicial projetado foi inspirado em Kim (2014), que realizou testes de
diferentes modelos de CNNs, e obteve resultados que defendem a universalidade dos modelos de palavras vetorizadas pré-treinados. Isto é, que programas que não possuem dados su cientes para criar modelos de vetores de palavras robustos po- dem utilizar modelos externos, como os disponibilizados por Google ou Wikipédia, sem perdas signi cativas.
jeto, nela é possível observar que a rede possui várias camadas convolucionais pa- ralelas, cada uma destas associada à camada de pooling, e uma camada de saída, que aplica os processos de descarte e a função de ativação Softmax. As camadas paralelas operam com um kernel e uma quantidade de n-gramas diferentes cada uma. A primeira camada usa trigramas, a segunda quadrigramas e a terceira quin- quegramas. As saídas destas camadas de convolução se unem para formar os ma- pas de características, que guardam as informações descobertas pelas convoluções. Na penúltima camada (pooling), os valores máximos destes mapas são ltrados e enviados à camada nal, onde a função Softmax é responsável por calcular a probabilidade para cada intenção.
Convolução 5xn Convolução 4xn Convolução 3xn
Entrada
Pooling
max softmaxSaída
o restaurante universitário vai abrir de que horas Resultado
Figura 9 Rede convolucional para a classi cação.
As demais características da rede desenvolvida foram deixadas como en- trada da função, de modo que esta pudesse ser testada em diversas con gurações diferentes, a m de encontrar a situação mais próxima da ótima para os objetivos deste trabalho.
4.4.1 Teste de hiperparâmetros
Para poder encontrar a con guração mais próxima de um funcionamento ideal foi criada uma rotina de testes que aleatoriamente testava diversas combina- ções possíveis de hiperparâmetros. Foram salvas as estatísticas dos testes destas
con gurações a cada época testada e com o auxílio de alguns scripts foi analisado o comportamento destas variações.
Quando alguma con guração aparecia como um possível resultado ótimo, esta era testada em uma nova rotina de testes, que utiliza exemplos de mensagens recebidas para testar a margem de certeza que a rede possui quando classi ca. Isto porque mesmo que uma con guração possua uma maior acurácia no âmbito geral, esta pode errar muito em casos especí cos, tornando alguma intenção muito difícil de ser identi cada. Dessa forma, o que se busca é uma função que possui uma boa taxa de acerto para cada intenção e que também identi que esta intenção com uma boa certeza (≥ 50%).
A rede neural sempre terá uma saída que corresponde a um vetor de ta- manho n, sendo n o número de classi cações (intenções) existentes, mesmo que a mensagem do usuário se re ra a algo que não corresponde a nenhuma das inten- ções. Esta saída é, portanto, importante para o comportamento do bot, já que ela revela o quanto o bot pode con ar na classi cação da rede. Uma intenção identi - cada com uma certeza muito baixa possui uma probabilidade maior da classi cação estar errada, e duas certezas altas porém próximas demonstram uma dúvida no sistema, independentemente de qual das duas tem maior probabilidade.
I % A 34 B 33 C 33 I % A 50 B 49 C 1 I % A 50 B 25 C 25 I % A 80 B 10 C 10 S1 S2 S3 S4
Figura 10 Exemplo de probabilidades de intenções na classi cação.
Na Figura 10, há um pequeno exemplo de como o classi cador poderia
prever uma intenção, considerando três intenções ctícias A, B e C. O classi cador determinará a probabilidade da mensagem recebida ser uma das três intenções de forma que a soma das suas probabilidades seja sempre de 100%. Nos testes gerais de
hiperparâmetros, aqueles que avaliam a con guração do sistema, todos os exemplos acima seriam classi cados igualmente, e considerando que todos sejam exemplos de intenção A, seriam todos classi cados como corretos.
Observa-se, porém, como existe uma diferença na certeza do classi cador. No primeiro caso (S1), a probabilidade é quase a mesma para as três intenções, com a probabilidade de não-A sendo, inclusive, muito alta (66%). No segundo caso, por mais que a probabilidade de A seja de 50%, dentro do limite desejado no projeto, a diferença para B é de apenas 1%, não havendo uma margem de certeza segura na avaliação do classi cador sobre a intenção escolhida. Nos exemplos S3 e
S4já se pode ver uma diferença bem mais signi cante na probabilidade da função
ser A em relação às demais.
No bot, os casos S1 e S2 devem resultar em alguma mensagem de erro (Ex.: "Não entendi, poderia escrever de outro modo?"), já os casos S3 e S4 resultariam em respostas esperadas para a intenção A.
5 Resultados
5.1 Hiperparâmetros
Para de nir os hiperparâmetros a serem utilizados foram realizados os pro- cedimentos mencionados no capítulo anterior. Inicialmente foram testadas diversas combinações aleatórias e aquelas que conseguiam resultados melhores pontuações, eram testadas mais a fundo com mensagens-teste para obter a margem de certeza. A maior parte das funções de maior aproveitamento foi descartada rapida- mente por confundir facilmente alguns casos mais próximos de intenções. Outras foram descartadas por depender demais de uma quantidade muito grande de exem- plos para a identi cação adequada de qualquer intenção. Ao nal, foi adotada a seguinte con guração:
Função de ativação Leaky ReLU Otimizador Adamax Tamanho do batch 16 Taxa de aprendizado 0,1
Tal con guração foi adotada por obter uma ótima pontuação geral, pos- suir boa margem de certeza e funcionar com tamanhos pequenos de exemplos de intenção. Apesar disso, nada garante que esta seja a melhor con guração para o problema de reconhecimento de intenções. Para garantir então que não fosse escolhida uma con guração muito distante do ótimo, foram comparados os resul- tados obtidos por cada con guração e foram comparadas as funções de ativação e otimização.
Figura 11 Comparação de funções de ativação no bot.
Na Figura 11, pode-se observar a comparação dos resultados das funções
de ativação testadas. Nela é possível ver que a Leaky ReLU escolhida é de fato a que obtém o melhor resultado geral, apresentando pontuação F1 consistentemente superior às demais funções a partir da terceira época de treinamento.
Na comparação de otimizadores foram levadas em consideração apenas as combinações com a função de ativação Leaky ReLU. Os resultados para os otimiza-
dores testados são apresentados na Figura 12. Nela, observa-se que houve grande
proximidade entre os resultados, com cinco funções obtendo pontuação F1 média superior a 0, 95 da quinta à décima época. Ainda assim, a função Adamax escolhida se encontra entre os dois melhores resultados em todas as épocas.
Os resultados do teste, portanto, foram favoráveis quanto à escolha desta con guração para a identi cação das intenções no módulo processador.
5.2 Administrador
Mensagens
Na seção de mensagens do administrador é possível visualizar todas as men- sagens recebidas pelo bot bem como julgar se cada uma foi classi cada correta-
mente. Esta visualização é apresentada na Figura13, em que a intenção é marcada
com uma chave (livro, neste caso). Se o administrador pressionar o botão con r- mar, os dados de treino da intenção livro serão incrementados com a mensagem observada. O administrador também pode corrigir a intenção, incrementando uma outra e assim ajudando o chatbot a classi cá-la corretamente no futuro.
Entidades
Na seção de entidade, pode-se observar os diferentes tipos de entidades, como cursos, componentes ou unidades; e também podem ser vistas as entidades
para cada tipo. Na Figura 14 pode ser observada uma lista de componentes para
serem identi cados. Enquanto na Figura 15 é possível observar as características
da entidades, em especial a lista de sinônimos, ou seja, as diferentes formas que essa entidade pode ser chamada.
Figura 14 Visualização de tipo de entidade do chatbot
Figura 15 Visualização de entidade do chatbot
Intenções
As páginas de intenções interferem diretamente na rede neural. Cada inten- ção adicionada é uma classe a mais a ser identi cada pela rede, e os dados recebidos pela rede estão todos lá para serem editados. Estes dados estão representados na
Figura 16 em Variações. É possível adicionar respostas-padrão para cada inten- ção na parte Respostas no nal da página. Quando uma intenção é con rmada ou corrigida na seção de mensagens, é exatamente no campo de variações que ela será adicionada.
Figura 16 Visualização de intenção do chatbot
5.3 Processador
O teste do processador é feito por meio da plataforma em que o chatbot está inserido. Aqui estão apresentadas em sequência algumas demonstrações do assistente identi cando textos de diferentes características enviados pelo usuário.
Os primeiros exemplos, na Figura 17, são de funções que utilizam somente
o identi cador de intenções (a rede convolucional). À esquerda, pode-se ver um exemplo de uma resposta-padrão, em que a intenção busca diretamente do banco de dados a resposta já pronta. À direita, vê-se exemplos de respostas em que os dados são coletados na API e modi cados para serem apresentados ao usuário.
Figura 17 Interação com o bot.
Na Figura 18, pode-se ver algumas respostas a mensagens em que existem
entidades. Neste caso, as entidades são identi cadas e é feita uma busca no banco de dados para saber qual o signi cado destas entidades. No exemplo, Engcomp equivale a Engenharia de Computação e ECT equivale à Escola de Ciências e Tecnologia. São enviados os nomes completos nas respostas para que, caso haja uma identi cação incorreta, esta seja facilmente veri cada pelo usuário.
Na seguinte, Figura19, há um exemplo de uma função com e sem entidade
identi cada. Observa-se como as entidades funcionam como um ltro na busca de notícias de turma, com o chatbot respondendo genericamente a última notícia entre todas as turmas quando uma especí ca não é encontrada.
Figura 18 Interação com o bot com entidades identi cadas.
Figura 19 Interação com o bot com mesma intenção m.
Há também a possibilidade de realização de uxos de conversa (utilizando as funções de continuação) para permitir ao bot a realização de tarefas mais complexas
de se entender em apenas uma sentença. Na Figura 20, vê-se uma consulta a livros
no acervo do SISBI (Sistema de Bibliotecas da UFRN). O usuário requisitou uma busca e o bot respondeu à requisição realizando duas perguntas, uma para saber o
ltro de busca (autor, título ou assunto) e outra para saber o nome a ser procurado. Devido ao pequeno tamanho das telas de smartphones, foram limitadas as buscas a 10 resultados, podendo o usuário requisitar os próximos 10, até que não hajam mais resultados.
Figura 20 Interação com o bot em uxo de conversa.
Finalmente, algumas consultas ao bot podem ser realizadas por meio de
marcadores. Na Figura21 seguem alguns exemplos destas consultas.
6 Conclusões
O objetivo deste projeto foi desenvolver um chatbot para ser aplicado à comunidade acadêmica da UFRN com base em técnicas modernas de aprendizado profundo. O projeto foi desenvolvido em Java, com uma rede neural convolucio- nal arquitetada para identi car as intenções nas mensagens recebidas. A rede foi projetada, testada e teve seus hiperparâmetros decididos através da avaliação de testes aleatórios de con gurações. Foi criada uma estrutura de edição de banco de dados em plataforma web para adicionar, remover e editar intenções e entidades, assim como também visualizar as mensagens enviadas pelos usuários.
Compreende-se que o objetivo do trabalho foi alcançado, uma vez que: a rede convolucional se mostrou capaz de identi car as intenções nas mensagens recebidas; os sinônimos de entidades foram identi cados; e o chatbot foi capaz de responder corretamente às mensagens do usuário.
Referências
AMAZON. Alexa Experience Guide. 2018. Disponível em:<https://www.amazon.
com/b?node=17934671011>. Acesso em: 17 de dez. de 2018. 17
APPLE. Siri. 2018. Disponível em: <https://www.apple.com/br/siri/>. Acesso
em: 17 de dez. de 2018. 17
BOJANOWSKI, P. et al. Enriching word vectors with subword information. Transactions of the Association for Computational Linguistics, v. 5, p. 135146,
2017. 25
BYOUS, J. Java Technology: The Early Years. 1998. Disponível em:
<https://web.archive.org/web/20050420081440/http://java.sun.com/features/