Mês: julho 2020

Publicado em

Arquiteturas de Redes Neurais Convolucionais para reconhecimento de imagens

Dando continuação ao artigo anterior, vamos entender agora como o conceito da convolução se relaciona com as redes neurais para reconhecimento de imagens. Para este tipo de classificação, é necessária uma boa performance, geralmente alcançada através da utilização de Deep Learning, ou seja, uma rede neural de múltiplas camadas, mais especificamente uma rede neural convolucional – conhecida pela sigla CNN.

Ela recebe este nome porque possui camadas de convolução que, juntamente com outros tipos de camadas, determinam uma arquitetura específica para esta finalidade, como veremos adiante. Uma rede neural profunda possui camadas de neurônios: uma camada de entrada, algumas camadas intermediárias (ou ocultas), e uma camada de saída:

Hipoteticamente, em uma rede completamente conectada, teríamos cada pixel de uma imagem 300×300 – por exemplo – ligado a cada um dos neurônios na entrada. Para isso, precisaríamos de 90 mil neurônios, resultando em uma quantidade extremamente alta de parâmetros, e uma descorrelação espacial entre os pixels da imagem, ou seja, um enorme desperdício de recurso.

Por isso, a aplicação de camadas convolucionais sobre os pixels da imagem, reduz muito a quantidade de parâmetros e facilita a descoberta de padrões. Geralmente utiliza-se filtros espaciais lineares como visto no artigo anterior.

Uma camada convolucional realiza o aprendizado de múltiplos filtros, onde cada filtro – ou kernel – extrai uma informação da imagem. Como dito anteriormente, outras camadas são utilizadas em conjunto com a convolucional. O módulo Keras para desenvolvimento de uma CNN fornece uma camada convolucional para imagens, chamada de Conv2D, e também outras camadas (ou layers) para se utilizar em combinação sequencial. São elas:

● MaxPooling2D

● Dropout

● Flatten

● Dense e

● Activation

● Na camada Conv2D: realiza-se a convolução e deve-se especificar a quantidade de filtros, e o tamanho do kernel;

● Na camada Activation: utiliza-se uma função de ativação, ao final de uma camada Conv2D e da camada Dense. A inspiração biológica é que inicialmente acreditava-se que os neurônios só conseguiam transmitir uma informação adiante pelo axônio após receberem um certo nível de estímulo (ou de saturação), e nessa situação estariam ativados. Esta função tentava representar esse cenário. Na prática, a função de ativação insere um comportamento necessário de não-linearidade, após a função linear dos pesos com as entradas, do corpo da célula:

 

As principais funções de ativação 

‒ Sigmóide: muito utilizada para aprendizado de funções lógicas, pois espreme os valores entre 0 e 1. Não é centrada em torno de zero, o uso de exponencial é relativamente custoso, e não é boa para reconhecimento de imagens;

‒ Tangente Hiperbólica: utilizada em redes LSTM (um tipo de rede neural recorrente), esta função espreme os valores entre -1 e 1, mas não é boa para funções binárias (pelo intervalo negativo);

‒  ReLU (Unidade Linear Retificada): muito utilizada para imagens, não satura na região positiva, converge bem mais rápido do que a sigmóide ou tangente hiperbólica sobre imagens, não é centrada em zero, porém é ruim para funções lógicas, e não é utilizada em redes recorrentes;

‒  Leaky ReLU: esta função nunca satura, é semelhante a ReLU porém faz tratamento para entradas negativas;

‒  ELU (Unidade Linear Exponencial): apresenta todos os benefícios da ReLU, produz saídas com médias próximas de zero, porém necessita de exponencial para seu cálculo;

‒ Softmax: esta função produz uma distribuição das probabilidades para cada classe de imagem durante uma classificação, diferente da sigmóide capaz de lidar com apenas duas classes. É utilizada na camada de saída da CNN.

● Na camada de Pooling ou Agrupamento: geralmente usa-se a função de valor máximo para processamento de imagens. No Keras é a função MaxPooling2D que age reduzindo ou agrupando pixels de uma determinada região, com a finalidade de diminuir a variância a pequenas alterações e também de reduzir a quantidade de parâmetros. O pooling também pode ser feito por função de soma ou de média.

● Na camada Dropout: realiza-se um regularização, onde alguns neurônios são desligados aleatoriamente, juntamente com suas conexões, durante o treinamento apenas. Durante a predição todos os neurônios são mantidos ativos. O motivo de se fazer isso é evitar overfitting no treinamento. Deve-se informar a porcentagem de desligamento.

● Na camada Flatten: a matriz resultante das camadas anteriores de convoluções e poolings é redimensionada para se tornar um array linear, de uma única dimensão. Esta etapa é um preparo para se entrar na camada principal da rede neural totalmente conectada.

● Na camada Dense: é implementada a rede neural totalmente conectada, ou fully connected (conhecido pela sigla FC em inglês), e deve-se informar a dimensão da saída e a função de ativação a ser utilizada. No contexto de reconhecimento de imagens é comum se projetar esta camada densa com a função de ativação ReLU e, por fim, outra camada densa com a dimensão igual a quantidade de classes a serem classificadas com a função de ativação softmax (para múltiplas classes).

Fonte da imagem: site https://medium.com

Arquiteturas de CNNs ou ConvNETs

Sobre arquiteturas de CNNs ou ConvNETs, inicialmente podemos citar três projetos que contribuíram para as arquiteturas atuais: 

LeNET: foi proposta em 1998 e já continha camadas de convolução com filtros 5×5 e passo 1, e agrupamentos com filtros 2×2 com passo 2, intercaladas, seguidas de camadas FC. A sequência de camadas eram: CONV-POOL-CONV-POOL-FC-FC.

AlexNET: proposta em 2012, bem mais complexa que a LeNET. Essa arquitetura continha cinco camadas de convolução, batch de tamanho 128, e primeiro uso da função de ativação ReLU.

VGG: em 2014 surge a arquitetura VGG com a ideia de filtros menores (3×3) em redes mais profundas com mínimo de 12 convoluções e maxpooling com filtros 2×2. Filtros menores geram menos parâmetros. Porém as camadas FC geravam uma quantidade muito grande de parâmetros e, as convoluções iniciais utilizavam muita memória RAM, tornando essa rede muito pesada.

Sobre as redes mais recentes, podemos citar dois projetos: a GoogleNET e ResNET.

GoogleNET: também em 2014 surgiu a ideia de se utilizar filtros de forma paralela, mais especificamente, fazer uso de uma nova camada chamada Inception, que se tornou elemento básico desta rede, onde tinha-se em sequência, nove módulos do tipo Inception. Este módulo possui convoluções 3×3 e 5×5 precedidas de convoluções 1×1 a fim de se reduzir o custo computacional.

ResNET: ou rede residual, proposta em 2015, de forma simplificada, a ideia é de se realizar um curto-circuito a cada duas convoluções, acrescentando um resultado anterior ao resultado futuro. Assim, diferentemente de uma rede tradicional, quanto mais camadas, menor o erro. Porém para os atuais projetos ResNET de 50, 101 e 152 camadas, ao invés de se trabalhar com 2 camadas convolucionais de 3×3, uma é retirada e são inseridas duas convoluções 1×1, diminuindo o custo computacional, como visto na GoogleNET.

Gostou deste artigo? Acompanhe outros textos aqui no nosso blog ou entre em contato com um dos nossos especialistas.

Publicado em

Entendendo de vez a convolução: base para processamento de imagens

Quem tem a formação em áreas como engenharia, estatística ou matemática, no mínimo tem uma ideia do que é uma convolução, pois essa técnica é muito utilizada para se criar filtros digitais em processamento de sinais, definição de correlação em estatística, etc.

Atualmente ouve-se muito o termo convolução na área de Inteligência Artificial, especificamente no Aprendizado de Máquina, que utiliza processamento de imagens como pré-tratamento para classificar ou extrair informações relevantes. 

Mas afinal que é convolução?

Convolução é simplesmente uma operação de somatório do produto entre duas funções, ao longo da região em que elas se sobrepõem, em razão do deslocamento existente entre elas. Na teoria, o cálculo da convolução contínua é dada pela integral deste produto, desde que as funções sejam integráveis no intervalo:

Na computação, utiliza-se o cálculo discreto, que realiza um somatório do produto:

 

 

Quando se trata de utilizar a convolução em processamento de imagens para Inteligência Artificial, são necessários dois somatórios pois temos duas dimensões – altura e largura:

Neste caso a convolução tem o papel de fazer uma filtragem para extração de informações de interesse na imagem. Mais especificamente, o uso de filtros espaciais lineares é feito através de matrizes denominadas máscaras ou kernels – como são mais conhecidos na prática.

Dependendo da dimensão e dos valores presentes nessa matriz ou kernel, é possível se obter características diferentes nas imagens como: suavização, deslocamento, contraste, bordas, texturas, remoção de ruídos, dentre outras.

Durante a aplicação da convolução em uma imagem, o kernel vai se deslocando ao longo da imagem, como uma janela móvel, que vai multiplicando e somando os valores sobrepostos, segundo um número de passos determinados, conhecidos por stride.

Para facilitar o entendimento, vamos considerar uma imagem de 32x32x3, onde a altura e a largura têm 32 pixels, com 3 canais de cores – que é a profundidade da matriz. Suponha um kernel de 5x5x3, onde a altura e a largura têm 5 pixels, com obrigatoriamente a mesma profundidade da imagem – que é 3. Deslizando-se o kernel sobre toda a área da imagem, considerando um stride igual a um, teremos uma matriz convoluída de tamanho 28x28x1, pois a cada passo, é calculado o somatório do produto de todos os valores sobrepostos resultando em um único valor:

Para uma imagem NxN, um kernel FxF, e com passo S, o resultado da convolução será uma matriz GxG tal que:

Com este exemplo, fica fácil perceber que a matriz convoluída será menor que a imagem original, e mesmo ajustando-se o stride igual a um, não será possível cobrir os pixels da borda da imagem original. Para resolver este problema, é usual a inclusão de mais pixels nas bordas da imagem original, com a quantidade P tal que:

Esse preenchimento é chamado de padding, e pode-se preencher com zeros, para se minimizar o efeito de redução rápida de dimensionalidade espacial da imagem convoluída. Agora, considerando a mesma nomenclatura do exemplo anterior, pode-se calcular o tamanho GxG da matriz convoluída incluindo o padding, tal que:

 

No contexto de redes neurais convolucionais (as CNNs), utiliza-se uma coleção de kernels ou agrupamento de filtros. Essa coleção é conhecida como camada convolucional. No exemplo visto anteriormente, onde a convolução resultou em uma matriz 28x28x1, aplicando-se seis kernels 5x5x1, a saída será uma matriz 28x28x6, ou seis mapas de ativação – como também é conhecido na prática.

Vejamos outro exemplo, agora utilizando padding: de acordo com a fórmula explicada anteriormente, para filtros 5×5, utilizaremos um padding de valor 2, preenchendo uma imagem de 32x32x3 com 2 camadas de zeros acima, abaixo e nas laterais. Aplicando-se uma primeira convolução com seis filtros 5x5x3, obtém-se uma imagem de 32x32x6. Após uma segunda convolução com dez filtros 5x5x6, obtém-se uma imagem de 32x32x10, e assim por diante. Com esse exemplo verifica-se que as dimensões altura e largura da imagem de entrada não se alteram.

Este texto é a base para o próximo artigo, onde veremos mais detalhes sobre as camadas de uma rede neural convolucional. Gostou? Então visite nosso Instagram e fique por dentro de mais conteúdos ou fale com um especialista da Viceri. 

Publicado em

Aplicações Serverless: quais as vantagens de usar esta arquitetura?

Neste texto vamos falar sobre aplicações serverless, o que são e quais as vantagens de usar esta arquitetura. O principal ponto de uma Arquitetura Serverless, é propiciar que empresas de software criem e mantenham aplicativos web sem se preocupar com a infraestrutura em que eles estão funcionando. Mas antes de entrar neste tema, vamos recapitular algumas coisas que já falamos aqui no blog e falar sobre as arquiteturas existentes.  

Arquitetura Monolítica

Arquitetura Monolítica é quando uma única aplicação de software em camadas contém a interface do usuário, as regras de negócio e código de acesso a dados. Tudo isso são combinados em apenas um único programa e uma única plataforma. Então, uma aplicação monolítica é autônoma e independente de outras aplicações.

É uma arquitetura simples de desenvolver, simples de testar e de implementar, porém, tem também suas desvantagens. É difícil de escalar: quando você precisar escalar essa aplicação ou fazer com que ela tenha maior disponibilidade, precisa escalar a aplicação inteira. Isso se torna inviável, o custo fica muito alto, e conforme essa aplicação cresce, complica a manipulação. Depois disso vieram os microsserviços, para solucionar esses problemas.

Arquitetura de microsserviços

A Arquitetura de Microsserviços é uma arquitetura de software diferente do monolito, no qual sistemas grandes e complexos são transformados em componentes individuais. Eles são quebrados e cada um fica espalhado com sua responsabilidade. As vantagens dos microsserviços são a sua escalabilidade distribuída, ou seja, não é preciso crescer a aplicação inteira para solucionar um problema, podemos escalar apenas recursos específicos. Deploys mais rápidos e não ficamos presos a uma linguagem de programação.

Ou seja, se quisermos fazer um componente em java, um outro componente em C# (C Sharp), podemos porque eles são diversas soluções com pequenas responsabilidades. As desvantagens dos microsserviços são: a complexidade de se manter, e se os serviços não forem bem definidos, viram uma bagunça.

◼️ Leia também: Como transformar seu monolito em microsserviço 

Iniciamos falando dessas arquiteturas porque elas enfrentam um problema ainda com o gerenciamento e controle de servidores, ou seja, você precisa de um servidor em funcionamento para que a aplicação continue em funcionamento, independente se está em uso ou não. Os microsserviços já solucionam muitos problemas em relação a escalabilidade, porém, ele ainda não solucionou o problema da ociosidade, ou seja, se o microsserviço está ativo, ele está ocupando recursos gerando custos mesmo em ociosidade.

Arquitetura Serverless

Então, aí entra a Arquitetura Serverless. Embora o seu nome signifique “sem servidor”, na tradução literal, não é bem assim que funciona. A aplicação continua funcionando em um servidor, porém o gerenciamento do servidor ficará por conta de um provedor de nuvem. Um desenvolvedor não precisará se preocupar com configurações relacionadas a infraestrutura em que sua aplicação irá funcionar. Essas decisões ficarão por conta da nuvem.

BaaS (Backend as a Service)

Existem algumas formas de construir aplicações serverless. Vamos tratar sobre BaaS (Backend as a Service). Backend as a Service é uma plataforma que automatiza o desenvolvimento de backend e gerencia a infraestrutura na nuvem. Com o BaaS você precisará apenas focar em desenvolvimento no core do seu sistema. O Backend as a service possui um conjunto de recursos para agilizar o desenvolvimento como APIs, integração com mídia social, armazenamento de arquivos e notificações push. 

E quais são as razões para utilizar o Backend as a Service? O objetivo do BaaS é de reduzir o tempo total de desenvolvimento da aplicação, dando velocidade ao desenvolvimento de um sistema e reduzindo custos. Você foca apenas no core do sistema se preocupando apenas com a necessidade real do seu cliente. E por ser serverless, não tem gerenciamento sobre infraestrutura, isso fica por conta do Backend as a Service.

FaaS (Function as a Service)

Além do BaaS existe também o FaaS, ou Function as a Service. É um modelo de execuções de funções orientados a eventos executado em containers stateless, ou seja, não armazena dados, apenas os processam. Simplificando um pouco, FaaS é uma maneira de executar funções de negócio acionadas por um determinado evento.

Quais as vantagens de usar FaaS? Um dos principais motivos para utilizar FaaS, é seu modelo de cobranças, as cobranças são feitas em relação ao tempo de processamento dessas funções, ou seja, caso elas estejam ociosas, não será cobrado valor algum, diferentemente das arquiteturas monolítica e de microsserviços que precisam de servidores e clusters ativos para mantê-los ativos mesmo sem uso.

Agora que sabemos de serverless, abaixo vou citar algumas ferramentas que possibilitam a construção de uma arquitetura onde não precisaremos nos preocupar com infraestrutura.

AWS Lambda

O AWS Lambda é a ferramenta de FaaS da AWS no qual permite executar código backend sem precisar provisionar ou gerenciar servidores cobrando apenas pelo tempo de processamento das funções.

Google Firebase

O Google Firebase é a ferramenta de BaaS da Google. Com ele é possível agilizar o desenvolvimento de sistemas web ou mobile. No Firebase temos a possibilidade de facilitar o envio de notificações push, ter uma análise do comportamento dos usuários do seu aplicativo utilizando o Firebase Analytics e com o Firebase Authentication é possível fazer o controle de autenticações do seu sistema de uma forma segura e dinâmica. Essas são algumas das ferramentas que o Firebase possui para agilizar o desenvolvimento backend do seu sistema e, claro, tudo isso sem gerenciar infraestrutura.

S3

O S3 é uma ferramenta da AWS para armazenamento de objetos. Tem uma interface simples e você consegue armazenar e recuperar qualquer quantidade de arquivos. Sua precificação fica por conta da quantidade de arquivos armazenados nessa plataforma, ou seja, será pago apenas pelos arquivos armazenados.

DynamoDB

O DynamoDB é um serviço de banco de dados nosql, que possui uma capacidade escrita e leitura muito rápida e segura, e é totalmente gerenciado com segurança e backups. Sua precificação pode ser controlada de duas maneiras, em uma delas, é cobrado por leituras e gravações que a aplicação faz nas tabelas, não será necessário especificar uma taxa de transferência para essas execuções, pois o Dynamo irá se ajustar de acordo com a demanda. E no outro modo é possível especificar a taxa de transferência da sua aplicação e seu custo pode ser controlado.

Amazon API Gateway

O API Gateway é um serviço que permite desenvolvedores criar APIs REST (Representational State Transfer) totalmente escalável e distribuído sem ter que cuidar de infraestrutura. Sua precificação fica por conta do número de chamadas que suas APIs recebem e quantidade de dados que são transferidas.

Para concluir, vimos que com a arquitetura serverless é possível ter as vantagens da escalabilidade e a computação distribuída, sem necessidade de provisionamento e gerenciamento de infraestrutura, e o custo da sua aplicação será proporcional a sua utilização.

Gostou deste conteúdo? Confira outros conteúdos no nosso Instagram ou fale com um de nossos especialistas. 

Publicado em

Integrando chatbot Rasa com outras aplicações

Já falamos aqui anteriormente sobre o Rasa. No artigo anterior fizemos um resumo geral e agora vamos aprofundar, focando especificamente na integração com outros sistemas, ou seja, como fazer o chatbot entender uma conversa e buscar informações em uma base de dados. Neste texto, vamos lembrar alguns termos que foram apresentados e que precisamos que estejam claros.  

Intenção (Intent): é o que o chatbot acha que você está querendo dizer. A partir de uma lista de exemplos que são treinados no chatbot é criado um modelo. Com esse modelo o Rasa vai tentar prever ou predizer o que o usuário está querendo falar.

Ação Personalizada (Custom Action): é possível escrever rotinas para fazer uma consulta num banco de dados, cálculos, relatórios, logs, enfim, qualquer coisa que possa ser feita num programa, e ainda acessar informações sobre a conversa, como interações anteriores com o chatbot. As ações personalizadas são escritas em Python.

Entidade (Entity): é uma parte variável da frase que pode ser considerada uma informação distinta. Isso parece confuso, então vamos dar um exemplo: Se tivermos uma intenção tipo “quais os hospitais em tal cidade?”, o “tal cidade” é uma entidade. Mesmo se a cidade fosse diferente de uma pergunta para outra, isolamos essa informação e fazemos uma busca para os hospitais da cidade especificada. 

Do mesmo jeito, uma frase do tipo “quais as minhas reuniões para tal dia?”, esse “tal dia” seria uma entidade. Uma entidade pode ter vários formatos. No caso do “tal dia” pode ser “quais as minhas reuniões para a próxima quarta”, “quais as minhas reuniões para o dia 10 de setembro”, ou ainda “quais as minhas reuniões para amanhã”. Em todos esses casos a entidade “data” é extraída da frase, e passada para uma ação personalizada para recuperar as informações daquele dia.

Slot: Não tem uma palavra específica no português, mas seria “ranhura” ou “fresta”. Imagine uma caixinha de correspondência que tem uma fresta por onde você pode passar uma folha de papel com um texto escrito. No Rasa, slots são usados para guardar informações no decorrer da conversa, que podem ser consultadas depois. Essas informações são guardadas nestas caixinha ou slots. Na programação tradicional o equivalente seriam as variáveis. Uma variável tem um nome e um valor, e um slot, do mesmo jeito, tem um nome e um conteúdo. Um slot pode ser de dois tipos básicos: um valor que não interfere no fluxo da conversa (que pode guardar qualquer tipo de informação); ou um valor que pode alterar o fluxo da conversa.

Como assim “interfere no fluxo da conversa”?

Se temos um slot com o sexo do usuário, quando ele (ou ela) escrever “como vai?”, podemos desviar uma conversa de acordo com o conteúdo desse slot, mostrando respostas diferentes para cada caso. Se for um homem mostramos “Eu vou bem, e o senhor, como está?” e se for uma mulher respondemos “Eu vou bem, e a senhora, como está?”. Dentro do tipo que interfere no fluxo da conversa, temos tipos específicos de slot: podemos ter slots numéricos, de texto, lógicos (tipo verdadeiro ou falso) ou categóricos (onde temos uma opção dentro de uma lista de possibilidades). Um exemplo de slot categórico seria sexo: masculino, feminino ou não informado.

Mas um detalhe, mesmo sendo do tipo que interfere no fluxo da conversa, somente conseguimos analisar o conteúdo do slot quando se trata de um slot categórico. Para os outros tipos só sabemos se tem algo no slot, ou se está vazio.

Podemos alterar o conteúdo de um slot de várias formas: preencher automaticamente com a informação extraída de uma entidade com o mesmo nome, mandar diretamente um valor para um slot através de uma API, ou alterar dentro de uma ação personalizada.

Observe que podemos usar a mesma entidade para preencher vários slots! Vamos supor que seja para calcular a área de um retângulo, onde área é igual a altura vezes a largura. Uma entidade “comprimento” pode ser ora a altura, ora a largura. E qual valor dependerá da conversa em si.

Resposta (ou Response): É uma frase que o chatbot irá responder para o usuário. Pode ser só um texto ou pode conter slots no meio da frase. Por exemplo, se temos uma frase de bom dia, e um slot contendo o nome do usuário, podemos colocar essa informação no meio da frase e falar “Bom dia, João” ou “Bom dia, Paulo”. Podemos cadastrar várias frases diferentes, e neste caso, o chatbot irá escolher aleatoriamente uma das respostas, e com isso tornamos as conversas mais humanas e menos fixas.

Respostas também podem conter botões. Definimos os botões, o que deve aparecer no botão, e se o usuário clicar em um desses botões será enviada a frase programada no botão para o chatbot.

Formulário (Form em Inglês): definimos um ou mais slots obrigatórios, e então o formulário age como se fosse uma “trava” na conversa, permitindo apenas que o usuário siga adiante caso todos esses slots estejam preenchidos. Podem ser preenchidos com qualquer texto que o usuário digitar, ou a partir de entidades extraídas de diálogos que o usuário escrever. Formulários são programados em Python, assim como ações personalizadas. Devemos ter frases resposta específicas para solicitar cada um dos slots que ainda não foram preenchidos.

Vamos ver um exemplo disso: se temos uma conversa que vai mostrar quais são os hospitais da minha cidade, eu não posso prosseguir na conversa até que o slot contendo o nome da cidade esteja preenchido. Neste caso, o formulário vai olhar o slot, e se não estiver preenchido, vai disparar a frase “Em que cidade?” e esperar a pessoa digitar o nome da cidade.

Podemos validar o nome da cidade dentro do formulário, e caso não seja um nome válido, pedimos novamente. Somente depois que o usuário digitar uma cidade válida é que seguimos e fazemos a consulta num banco de dados para mostrar quais os hospitais cadastrados para aquela cidade.

Estória (ou Story): é a cola que junta todos esses pedaços. É uma sequência de intenções, respostas, formulários ou ações do chatbot que vai dar forma à conversa. A forma mais simples de uma estória é uma intenção e uma resposta, que vai criar o seguinte comportamento: se o usuário digitar determinada coisa, responde com tal coisa. 

Estórias mais complexas usam ações personalizadas e formulários para enriquecer a experiência do usuário. Todas essas informações ficam distribuídas em vários arquivos. Temos o arquivo de configuração, config.yml, onde ficam os parâmetros de treinamento, e qual a sequência de módulos que serão usados para interpretar o texto e treinar o modelo.

Temos o domain.yml contendo uma lista de todas as ações (ações personalizadas e respostas do chatbot), intenções, entidades e slots, além de todos os textos de respostas que o chatbot deve mostrar. Dentro de uma pasta chamada data colocamos as estórias e as frases de exemplo para o treinamento do chatbot, sendo que temos a opção de organizar melhor os arquivos, colocando em duas subpastas: data/core (para as estórias) e data/nlu (para as frases de exemplo).

Na Viceri desenvolvemos uma ferramenta para administrar o chatbot com mais facilidade, permitindo que através de uma aplicação web, você consiga gerenciar todas essas informações.

Depois de conhecer estes termos, nos próximos artigos vamos entrar mais nos detalhes da programação e dar exemplos mais detalhados de como se encaixa tudo isso.

Ficou interessado em saber mais sobre o assunto? O time da Viceri tem especialistas que podem ajudar você a encontrar as respostas que precisa. Entre em contato com a gente!

Publicado em

Formatos de dados necessários para treinar seu chatbot

Antes de começar a ler este artigo, é importante que você esteja familiarizado com alguns termos e explicações que demos em outros textos anteriormente. Por isso, leia também Integrando chatbot Rasa com outras aplicações e RASA: Conheça o software em python utilizado para criação de chatbots.

Neste artigo vamos começar a examinar os formatos de dados necessários para você treinar seu chatbot. Basicamente, o treino vai pegar informações de NLU (que é a compreensão de linguagem natural – Natural Language Understanding), dados de estórias (fluxos de conversa), e o arquivo de domínio (respostas do chatbot e organização das conversas) e vai aplicar o processo definido no arquivo de configuração. Então temos:

NLU + Estórias + Domínio -> Config -> Modelo

O RASA espera que os arquivos estejam organizados da seguinte forma: Domain.yml e config.yml na pasta “raiz”. NLU e estórias (com extensão .md) na subpasta “data”. Você também pode criar duas subpastas dentro de “data” (chamados “core” e “nlu”) e colocar os arquivos dentro das respectivas subpastas. Caso não for fazer isso, o arquivo com NLU deve se chamar nlu.md e o arquivo de estórias, story.md.

Se você separar nas subpastas “data/nlu” e “data/core”, pode dividir os exemplos e estórias por assunto e separar em vários arquivos, com qualquer nome desde que estejam nas pastas corretas.

Os arquivos Domain e Config são no formato yml e os arquivo de exemplo (nlu) e estórias (core) são no formato md (de markdown). Numa versão próxima do RASA provavelmente todos os arquivos serão no formato yml, mas aqui vamos ver o formato atual, md.

Para você começar com um conjunto de arquivos base, pode executar o comando “rasa init”, mas cuidado: isto vai limpar dados que já existirem na pasta onde você executar o comando.

O arquivo domain.yml

O arquivo domain é dividido em várias “seções”: Declaração de intenções; Declaração de ações; Declaração de entidades; Declaração de slots; Respostas do chatbot; Dados sobre seção do usuário.

Veja os exemplos de cada seção

Cada seção começa com uma linha com o nome da seção seguido de dois pontos. Vamos ver um exemplo da seção de intenções:

intents:
– saudação
– despedida
– feliz
– triste

Observe que cada nome de intenção começa com um – e um espaço. Isto tem de ser obrigatoriamente dessa forma. Todas as intenções que for usar nas conversas devem estar relacionadas aqui. Logo mais vamos ver melhor como define uma intenção, mas por enquanto basta saber que uma intenção é composta de um nome e vários exemplos. Aqui colocamos o NOME. Deve estar escrita exatamente da mesma forma que no arquivo NLU.

Para nomes de ações, intenções, slots e entidades, recomenda-se usar apenas as 26 letras do alfabeto (sem acentos) e números de 0 a 9 e o underscore (símbolo do sublinhado), sempre começando com uma letra. Use nomes que têm a ver com o assunto, como procura_hospital, escolher_filmes e assim por diante. Não há limite para o comprimento do nome, mas nomes compridos demais podem dificultar na hora de digitar o nome.

Depois de listar todas as intenções, vamos colocar as ações, que podem ser ações personalizadas ou então respostas do chatbot.

Um exemplo da seção de ações está abaixo:

actions:
– utter_saudacao
– utter_despedida
– utter_alegrar
– action_busca_hospital

Temos o nome da seção “action”, seguido de dois pontos, e cada uma das ações na sua linha, começando com hífen seguido de espaço. Repare como separamos as palavras com sublinhado (_). Os nomes não podem conter espaços, então use o sublinhado (_) para separar as palavras. Não junte tudo (comoAlgumaLinguagensDeProgramacaoFazem), e dê nomes que tem a ver com o que a ação faz.

Por padrão, uma resposta do chatbot começa com “utter” que quer dizer “falar” ou “expressar”. Pronuncia-se “a-ter”. A pronúncia correta é essencial. Se você for falar “u-ter” com qualquer estrangeiro, ele não vai entender do que está falando e provavelmente achar engraçado. Existem alguns nomes “padrões” para utter que veremos quando formos falar a respeito de formulários.

Assim como uma resposta do chatbot começa com “utter”, uma ação personalizada por padrão começa com “action”.

Depois de listar todas as ações do seu projeto, vamos definir as entidades e os slots.

Veja um exemplo de seção de entidades:

entities:
– grupo
– cor
– cidade

Entidades são informações que serão extraídas de frase. Um exemplo seria extrair a cor da frase “Estou procurando uma caixa verde”.

Na parte onde formos falar de NLU (exemplos para o chatbot) falaremos mais sobre entidades. Por enquanto, basta saber que você atribui um nome a uma entidade. Se não tiver nenhuma entidade a ser extraída de frases, não é necessário ter uma seção de entidades no domain.

Depois de declarar entidades, deve declarar os slots. Caso queira que o slot seja preenchido automaticamente por uma entidade, basta defini-lo com o mesmo nome.

Um exemplo de seção de slots:

slots:
nome:
type: unfeaturized
perfil:
type: categorical
values:
– anonimo
– basico
– vip
descricao:
type: unfeaturized

Na hora de declarar os slots, você precisa informar o tipo, que pode ser:

Text: irá guardar uma informação texto;
Boolean: irá guardar uma informação verdadeiro/falso;
Categorical: irá guardar a seleção entre uma lista de possibilidades (sexo masculino, feminino ou não informado);
Float: irá guardar uma informação numérica;
List: irá guardar uma lista de valores;
Unfeaturized: este é o ÚNICO tipo que não influencia no fluxo da conversa.

Para todos os tipos exceto unfeaturized, boolean e categorical, só é possível saber que há um valor no slot, mas não comparar com outros valores. O unfeaturized, por definição, não influencia no andamento da conversa. É possível verificar o valor de um slot categórico ou boolean e influenciar no andamento da conversa.

No domain também declaramos formulários da mesma forma:

forms:
– registro_form

A Viceri desenvolveu uma ferramenta que você pode usar para criar estes arquivos automaticamente, sem se preocupar com a formatação das informações. Basta preencher os exemplos com as frases que o chatbot irá falar, montar as conversas de uma forma interativa, e a partir de um painel administrativo solicitar para treinar um modelo.

Nos próximos artigos continuaremos vendo como declarar respostas ao usuário no arquivo domain.yml, e como são formatados os arquivos de exemplos (NLU) e estórias. Gostou?

Confira nossos próximos posts ou fale agora com o time da Viceri. Estamos sempre prontos para auxiliar você sempre que precisar.