3 DESENVOLVIMENTO
Neste capítulo é descrito o projeto e desenvolvimento do protótipo do chatterbot para área imobiliária, descrevendo as tecnologias que foram utilizadas, os requisitos, as funcionalidades que são disponibilizadas, os diagramas e as etapas de desenvolvimento do trabalho.
Na Seção 3.1, situação problema, é apresentada a situação atual do atendimento de clientes da imobiliária, descrevendo a metodologia de atendimento utilizada na imobiliária, as informações disponibilizadas aos clientes através do atendimento, os problemas e deficiências encontrados como também a melhoria que o sistema poderá proporcionar aos atendentes.
Na Seção 3.2, modelagem do sistema RBC, é apresentada a modelagem do sistema RBC,
3.1 Situação pr oblema
A imobiliária que se pretende utilizar como estudo de caso está localizado nos municípios de Florianópolis e São José, distribuída em cinco agências de aluguéis, com mais de meio século de participação e vivência dentro do mercado imobiliário.
A imobiliária possui uma ampla carteira de serviços em negócios imobiliários, como locação e vendas de imóveis, assessoria jurídica, administração em condomínios, serviços de manutenção, reformas de imóveis e incorporação imobiliária. Para o desenvolvimento dos trabalhos será utilizada como "área foco" o atendimento a clientes da locação de imóveis.
Na área de locação possui uma carteira de imóveis com mais de 5.000 imóveis, tendo disponível em pauta para os clientes aproximadamente 650 imóveis. A central de atendimento da imobiliária utiliza um sistema de gestão integrado que dá suporte a realização das atividades da empresa, onde os atendimentos realizados são cadastrados, e com estes dados, é possível realizar estudos e análises estatísticas sobre os atendimentos.
Atualmente o atendimento a clientes é realizado de quatro maneiras: pessoalmente; via e
mail; via telefone; e via website. Em cada tipo de atendimento, a imobiliária busca melhorar cada vez mais a satisfação do cliente, porém, em determinados casos como tirar dúvidas, informações e consultar imóveis, podem existir dificuldades ou deficiências encontradas pelos clientes.
Para o desenvolvimento do protótipo, que busca criar um novo canal de atendimento aos clientes, foi analisado o atendimento a clientes realizado atualmente pela imobiliária. Inicialmente foram utilizadas as informações armazenadas no sistema de gestão da imobiliária, que para cada atendimento realizado a clientes que desejam alugar um imóvel são armazenadas as informações das consultas e dados dos clientes.
Para cada atendimento, os atendentes realizam as consultas a imóveis no sistema de gestão da imobiliária, selecionando os critérios informados pelos clientes como características que desejam nos imóveis para alugar. Na Figura 14 é possível visualizar a tela deste sistema de gestão com os critérios para pesquisa de imóveis utilizados pelos atendentes da imobiliária.
Figura 14. Interface da consulta de imóveis
Fonte: Adaptado do sistema de gestão imobiliária LinkBrognoli
Desta forma foram extraídas do sistema as informações de atendimentos realizados na imobiliária no período de 01 de abril de 2007 a 30 de abril de 2007. Para este período foi realizado um total de 3928 atendimentos. Em cada atendimento é possível realizar várias consultas e, em cada consulta, se podem buscar informações de diversos imóveis. Para cada consulta, o sistema armazena os critérios utilizados nesta consulta, como também os imóveis que se buscou mais informações. Na Figura 15 é apresentado o gráfico com a quantidade de atendimentos realizados neste período, em todas as agências da imobiliária.
Figura 15. Gráfico de atendimentos realizados no mês de abril
Na Figura 16 é apresentado o gráfico dos critérios utilizados em cada consulta a imóveis em atendimentos, no período de 01 de abril de 2007 a 30 de abril de 2007, somando um total de 9178 consultas a imóveis.
Figura 16. Gráfico dos critérios de consulta utilizados em atendimento
Estes gráficos apresentam os atendimentos realizados pelos atendentes da imobiliária, porém devese levar em consideração também os acessos realizados no website da imobiliária. No website não existe um processo que armazena as informações consultadas, porém o número de acessos a página é contabilizado e, no período de 01 de abril de 2007 a 30 de abril de 2007, obtevese um total de 43.168 acessos.
Com estes dados é possível analisar as informações relevantes para consultas a imóveis da imobiliária, sendo utilizados estes dados na modelagem do sistema RBC para auxiliar na determinação dos índices e pesos para os atributos dos casos.
Para analisar as informações da imobiliária, desenvolveuse um formulário (Apêndice A), que foi apresentado a quatro atendentes de locação e um gerente da agência, onde estes especialistas descreveram quais as informações relevantes os clientes buscam, ao entrarem em contato com a
que podem ser apresentadas pelo chatterbot através da Internet, sendo divididas em grupos de maneira sintética (resumida).
Tabela 3. Informações dos especialistas
Tipo Descrição
Informação Ramos de atividade
Apresentação da imobiliária Visão, missão, princípios
Produtos e serviços disponibilizados Tipos de imóveis
Vantagens em alugar
Dúvida Como alugar
Documentação necessária
Reserva, reserva de chaves, visita de imóveis Contrato de locação
Vistoria inicial e final em imóveis Reclamações e sugestões do cliente Apresentação dos
imóveis
Localização e endereço do imóvel Edifício
Características internas e externas Valor do aluguel
Contato Endereços das agências da imobiliária Telefones de contato
Email Website
Desta forma o desenvolvimento do protótipo de um chatterbot pode criar um novo canal de comunicação com os clientes, auxiliando estes clientes a tirar dúvidas simples sobre a imobiliária, como também consultar imóveis utilizando a linguagem natural para buscar as informações, estando disponível a qualquer momento de maneira rápida e simplificada.
3.2 Modelagem do Sistema RBC
O protótipo desenvolvido neste trabalho é capaz, além de conversar com os clientes da imobiliária, recuperar as informações dos imóveis para apresentação aos clientes, de acordo com as características desejadas. Desta forma os casos do sistema RBC são representados pelos imóveis, e para apresentação ao cliente, são recuperados da base de casos os imóveis mais similares às características informadas, não incluindo no sistema RBC as etapas de adaptação e aprendizado dos casos.
O primeiro passo para o desenvolvimento do sistema RBC foi a modelagem dos casos a serem armazenados na base de casos. Para isso se buscou as especificações dos imóveis, que são dados cadastrados pela imobiliária e estão armazenados no sistema de gestão, citado na Seção 3.1.
Na Tabela 4 estão apresentados os atributos dos imóveis que foram levados em consideração na modelagem do sistema RBC, bem como o tipo de informação que cada atributo armazena.
Tabela 4. Atributos do imóvel
Atributo Tipo Descrição
Código Inteiro Identificação única do imóvel
Tipo Literal Descrição do tipo do imóvel (Apartamento, Casa, Cobertura, Chácara, Galpão, Garagem, Kitinete, Loja, Pousada, Prédio, Quiosque, Sala, Sobrado, Sítio, Terreno) Agência Inteiro Código da agência de aluguel que o imóvel pertence Finalidade Caractere C: Comercial, R: Residencial, A: Ambos
Endereço Literal Descrição do endereço do imóvel
Bairro Literal Nome do bairro
Cidade Literal Nome da cidade
Região Literal Nome da região
Andar Inteiro Andar do imóvel (Em caso de edifício)
Edifício Literal Nome do edifício
Quartos Inteiro Número de quartos
Mobiliado Booleano Imóvel mobiliado (S: Sim , N: Não) Sacada Booleano Imóvel com sacada (S: Sim , N: Não)
Piso Literal Tipo de piso (Cerâmica, Carpet, Madeira, Forração, Misto, Outros)
Dep.empregada Booleano Imóvel com dependência de empregada (S: Sim , N: Não) Suíte Booleano Imóvel com suíte (S: Sim , N: Não)
Garagem Inteiro Número de vagas de garagem
Metragem Real Metragem quadrada do imóvel
Aluguel Real Valor do aluguel
TítuloAnúncio Literal Título do anúncio do imóvel
Fotos Imagens Imagens do imóvel para apresentação
Com a definição dos atributos dos imóveis, chegase a conclusão de que a representação baseada em pares atributovalor será suficiente para realizar a representação do conhecimento contido nos imóveis. Desta forma realizouse uma análise para determinação dos índices, que identificam as principais características dos imóveis. Para isso utilizouse de informações dos especialistas em conjunto com o gráfico dos critérios utilizados para seleção dos imóveis, apresentado na Figura 16.
considerados para o cálculo do valor de similaridade. Os atributos que não são discriminantes servem como informações adicionais para a escolha do imóvel.
Cada atributo discriminante no caso é utilizado como índice para recuperação, e para isso pode conter um peso de importância para o cálculo da medida de similaridade. Estes pesos serão prédeterminados neste momento, porém poderão ser alterados durante a execução do protótipo, através do painel de controle da aplicação que será desenvolvido. Na Tabela 5 são apresentados os atributos discriminantes dos imóveis, que serão utilizados como índices para recuperação dos casos.
Tabela 5. Definição dos pesos da medida de similaridade
Atributo Discriminante Peso
Tipo Sim 0.20
Finalidade Sim 0.05
Ender eço Sim 0.10
Bair ro Sim 0.10
Cidade Sim 0.10
Região Sim 0.10
Edifício Sim 0.05
Quartos Sim 0.125
Mobiliado Sim 0.025
Dep. empregada Sim 0.025
Suíte Sim 0.025
Garagem Sim 0.025
Metragem Sim 0.025
ValorAluguel Sim 0.05
Agência Não
Andar Não
Código Não
Fotos Não
Piso Não
Sacada Não
Título Anúncio Não
Após a seleção dos atributos discriminantes e seus respectivos pesos (Tabela 5), foi definida a medida de similaridade que será utilizada, onde foram analisadas as medidas que se adaptam as características citadas anteriormente.
A técnica do vizinho mais próximo, apresentada na Equação 1 (Seção 2.4.4), pode ser utilizada por ser simples e não necessitar de um processamento com número elevado de cálculos. O protótipo a ser desenvolvido poderá ser utilizado por diversos clientes simultaneamente, o que necessita de desempenho para o sistema, e para evitar sobrecargas no servidor, um método com poucos cálculos é mais indicado.
Além da medida de similaridade, também é necessária a determinação da função de similaridade que será utilizada para cada atributo do caso, onde devem ser levados em consideração os tipos de dados de cada atributo. A função de similaridade pode ser definida através de diferentes maneiras, entre as principais citadas por Wangenheim e Wangenheim (2003) estão:
· Matriz de similaridade: utilizada para determinação da similaridade de uma lista finita de valores (símbolos não ordenados), a medida que a similaridade pode ser definida como uma matriz triangular de valores no intervalo entre 0 e 1. Para valores idênticos atribui
se valor = 1 e para os demais valores são atribuídos valores de similaridade de acordo com o domínio da aplicação.
· Função escada: calcula uma similaridade 1 se a distância entre os dois valores for menor que o limiar definido pela função, senão a função retorna a similaridade 0. Desta forma será retornado um resultado binário; e
· Função linear: a similaridade aumenta com a redução da diferença entre os dois valores, ponderada pelo tamanho do intervalo assumido pelo domínio dos valores do atributo, seguindo a função apresentada na Equação 4.
Equação 4
Sendo ubo valor máximo e lbo valor mínimo que pode ser atribuído ao valor do atributo.
Na Tabela 6 são apresentados os atributos, tipos e as respectivas funções de similaridade que foram utilizadas.
Tabela 6. Definição dos pesos da medida de similaridade
Atributo Tipo Função
Tipo Literal Matriz de similaridade
Finalidade Caractere Função escada
Endereço Literal Função escada
Bairro Literal Matriz de similaridade
Cidade Literal Matriz de similaridade
Região Literal Matriz de similaridade
Edifício Literal Função escada
Quartos Inteiro Função linear
Mobiliado Booleano Função escada
Dep. Empregada Booleano Função escada
Suíte Booleano Função escada
Garagem Inteiro Função linear
Metragem Real Função linear
Valor Aluguel Real Função linear
Na Tabela 7 é apresentada a matriz de similaridade para o atributo Tipo de imóvel.
Tabela 7. Matriz de similaridade do tipo de imóvel
vi / vj
Apartamento Casa Cobertura Chácara Galpão Garagem Kitinete Loja Pousada Prédio Quiosque Sala Sobrado Sítio Terreno Apartamento 1 0.5 0.7 0.0 0.0 0.1 0.5 0.1 0.3 0.5 0.1 0.1 0.4 0.0 0.0
Casa 1 0.6 0.1 0.0 0.1 0.5 0.1 0.3 0.3 0.1 0.1 0.4 0.3 0.4 Cobertura 1 0.1 0.0 0.1 0.5 0.0 0.3 0.1 0.0 0.0 0.2 0.1 0.1 Chácara 1 0.0 0.0 0.1 0.0 0.1 0.0 0.0 0.0 0.1 0.6 0.3
Galpão 1 0.1 0.0 0.1 0.0 0.3 0.0 0.0 0.0 0.0 0.1
Garagem 1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0
Kitinete 1 0.0 0.3 0.1 0.1 0.1 0.1 0.1 0.1
Loja 1 0.1 0.5 0.5 0.5 0.1 0.1 0.1
Pousada 1 0.1 0.0 0.1 0.5 0.3 0.1
Prédio 1 0.3 0.5 0.1 0.0 0.0
Quiosque 1 0.3 0.1 0.1 0.1
Sala 1 0.1 0.1 0.1
Sobrado 1 0.1 0.3
Sítio 1 0.6
Ter reno 1
A matriz de similaridade para os atributos Bairro e Cidade é determinada pela matriz de similaridade de Região, pois todos os bairros e cidades dos imóveis estão cadastrados em uma região. Esta matriz possui aproximadamente treze regiões e inclui todos os bairros e cidades de abrangência da imobiliária. Na Tabela 8 é apresentada a matriz de similaridade das regiões comerciais dos imóveis.
Tabela 8. Matriz de similaridade das regiões comerciais
vi / vj
Barreiros Centro Fpolis Centro SJ Coqueiros Costeira Estreito Forquilhinhas João Paulo Kobrasol Leste Ilha Norte Ilha Sul Ilha Trindade Bar reiros 1 0.0 0.1 0.1 0.0 0.1 0.2 0.0 0.2 0.0 0.0 0.0 0.0 Centro Fpolis 1 0.0 0.0 0.0 0.2 0.0 0.1 0.0 0.3 0.1 0.1 0.2 Centro SJ 1 0.1 0.0 0.0 0.2 0.0 0.2 0.0 0.0 0.0 0.0 Coqueiros 1 0.0 0.2 0.1 0.0 0.1 0.0 0.0 0.0 0.0
Costeira 1 0.1 0.0 0.1 0.0 0.0 0.0 0.4 0.2
Estreito 1 0.0 0.0 0.2 0.0 0.0 0.0 0.1
Forquilhinhas 1 0.0 0.5 0.0 0.0 0.0 0.0
J oão Paulo 1 0.0 0.0 0.1 0.0 0.4
Kobrasol 1 0.0 0.0 0.0 0.0
Leste da Ilha 1 0.4 0.1 0.2
Norte da Ilha 1 0.1 0.2
Sul da Ilha 1 0.1
Trindade 1
Para as duas matrizes de similaridade, os valores apresentados podem ser alterados dinamicamente em tempo de execução do protótipo, caso seja necessário realizar alguma adaptação para melhoria da busca dos imóveis.
Com a definição dos atributos, pesos e métricas de similaridade foi iniciada a modelagem do banco de dados onde serão armazenadas estas informações. Será utilizado o sistema de gerenciamento de banco de dados relacional chamado Firebird versão 1.5, que é compatível com diversos sistemas operacionais, bastante seguro e suporta diversos usuários simultaneamente.
Para a modelagem do banco de dados utilizouse uma ferramenta chamada DBDesigner 4, que facilita a criação do banco de dados, uso de query e alterações das tabelas, tendo como
vantagem a parte gráfica do MER (Modelo Entidade Relacionamento). Na Figura 17 é apresentado o MER do banco de dados:
Figura 17. Modelo Entidade Relacionamento do Banco de Dados
As entidades “REGIAO”, “BAIRRO”, “CIDADE”, “TIPO_IMOVEL” armazenam as informações que são prédefinidas e são utilizados por todos os imóveis cadastrados posteriormente.
A entidade “BAIRRO_REGIAO” armazena o relacionamento dos Bairros com uma região que será utilizada pela matriz de similaridade para o cálculo da similaridade da localização do imóvel. A entidade “IMOVEL” armazena as informações dos imóveis, que para o sistema RBC serão os casos do sistema, formando os atributos dos imóveis.
A entidade “PESO” armazena os pesos que são utilizados para o cálculo do valor de similaridade dos casos do sistema RBC, onde cada atributo discriminante do caso deverá possuir um peso cadastrado. Estes pesos poderão ser alterados durante a execução do protótipo, de acordo com a necessidade de alterações para melhorar o cálculo da similaridade.
A entidade “MATRIZ_SIMILARIDADE” contém os valores de similaridade para os atributos “REGIAO” e “TIPO_IMOVEL”, tendo como identificação através do campo
“CD_MATRIZ” os valor 1 e 2 respectivamente. Os campos CD_ORIGEM e CD_DESTINO armazenam os códigos dos atributos que irão compor a matriz triangular de valores, tendo para cada registro o respectivo valor do peso. Desta forma o protótipo tornase passível de alterações para incrementar sua base de dados de regiões e de tipos de imóveis, pois os pesos tornamse dinâmicos para adicionar novas informações.
Com a modelagem do banco de dados gerouse um script através da ferramenta de modelagem DBDesigner e executouse este script no banco de dados Firebird. Com o banco de dados criado foi necessário extrair uma amostra dos dados cadastrados no sistema de gestão imobiliária, para ser possível realizar os testes do sistema RBC, onde se selecionou uma amostra de aproximadamente 450 imóveis. Foram também “populadas” as demais tabelas (Agência, Cidade, Bairro, Região, Tipo de Imóvel) com os dados referentes a estes imóveis, e também cadastrados as matrizes de similaridade e pesos do sistema RBC.
Na configuração do sistema RBC foram incluídos além dos pesos dos índices, dois campos para informar os limiares de apresentação dos imóveis:
· limiar de quantidade: podese informar a quantidade máxima de imóveis apresentados ao cliente em cada consulta do sistema RBC; e
· limiar de similaridade: podese informar o percentual de similaridade mínimo para apresentação ao cliente. Caso seja indicado o valor 0, são apresentados todos os imóveis encontrados e caso seja informado o valor 100 serão apresentados somente os imóveis totalmente similares ao imóvel desejado.
Estes dois limiares são levados em consideração para apresentação ao cliente, para que não seja exibida uma lista excessivamente grande de imóveis e também para que não sejam apresentados imóveis totalmente diferentes do imóvel desejado.
Para o cálculo da similaridade do sistema RBC optouse pela implementação utilizando Stored Procedure (SP), que é um conjunto de comandos SQL que podem ser armazenados no servidor, de forma a permitir um aumento no desempenho das aplicações visto que há uma redução
· o banco de dados Firebird permite a utilização de Store Procedures;
· todos os pesos e matrizes de similaridade do sistema RBC já estão armazenados na base de dados;
· para o cálculo da similaridade do sistema RBC é necessário analisar todos os casos da base, onde para implementação na aplicação seria necessário buscar todos os dados e realizar o cálculo na própria aplicação;
· torna a servidor WEB com menor processamento, melhorando o desempenho;
· para cada consulta ao sistema RBC são retornados somente os imóveis mais similares, não sendo necessário retornar todos os imóveis da base de dados; e
· disponibiliza o sistema RBC disponível para outras aplicações que venham a ser desenvolvidas.
Para a utilização da SP, chamada de SP_GET_SIMILAR, a aplicação deve passar como parâmetros os atributos do imóvel desejado, recebendo como retorno da SP o código do imóvel, o percentual de similaridade do imóvel em relação as características desejadas.
Ainda na SP foi utilizada para busca pelo nome do edifício e pelo endereço do imóvel uma função do banco de dados chamada SoundexBr, que é uma função desenvolvida por Paulo Roberto Quicoli disponibilizada gratuitamente para o banco de dados Firebird. Esta função realiza consultas fonéticas auxiliando o usuário a encontrar o imóvel caso não conheça exatamente a grafia correta do nome do edifício ou o endereço do imóvel. Um exemplo citado pelo desenvolvedor seria a consulta fonética para o nome Wellington, onde o usuário pode, por exemplo, informar como Wellington, Welington, Uelington, Wellingtom, entre outros, que a função realiza a consulta e localiza o respectivo nome correto.
No Apêndice C é apresentada a Stored Procedure SP_GET_SIMILAR, onde é possível visualizar os parâmetros de entrada e saída como também os cálculos realizados para o sistema RBC.
3.3 Modelagem do Pr otótipo
No Capítulo 2, fundamentação teórica, analisouse os chatterbots e tecnologias utilizadas atualmente na Internet, apresentando as principais características e funcionalidades disponibilizadas
por estes chatterbots. Entre as tecnologias citadas, a que se enquadra como mais apropriada para ser utilizada como base para o desenvolvimento do protótipo é o chatterbot ALICE, tendo como características que levaram a sua escolha:
· Licença: disponibilizado gratuitamente através da licença pública GNU.
· Base de conhecimento: utiliza a linguagem AIML, que é baseada em XML, de simples aprendizado e utilização.
· Interpretadores: disponibilidade em diferentes sistemas operacionais (plataformas) e linguagens de programação.
· Independência: a plataforma ALICE e a linguagem AIML são independentes, ou seja, não é necessário ser um programador com grande conhecimento para utilizar o programa.
· Documentação: os interpretadores e a linguagem AIML possuem uma grande quantidade de documentação, disponibilizadas através do website do chatterbot ALICE.
Com a escolha do chatterbot ALICE, realizouse a pesquisa dos interpretadores disponíveis, conforme apresentado na Seção 2.3.2. Para a escolha do interpretador, foram levados em consideração os seguintes pontos:
· Disponibilidade para web: como o chatterbot tem o objetivo de realizar o atendimento a clientes, é importante que esteja disponível através da Internet.
· Linguagem de programação: optase por utilizar a linguagem de programação Java, por possuir experiência na linguagem em trabalhos anteriores.
· Documentação: o interpretador deve possuir a documentação necessária para sua instalação, desenvolvimento e manutenção do protótipo.
· Manutenção do interpretador: o interpretador deve possuir um feedback quanto a resolução de problemas encontrados.
Para as características citadas, o interpretador que melhor se enquadra nos requisitos é o
“Program D”, que é desenvolvido utilizando a linguagem de programação Java, através da plataforma J2EE, tornando as aplicações disponíveis através da Internet. Disponibiliza a
periodicamente é atualizado com correção de possíveis problemas encontrados no interpretador.
Além destas características, o “Program D” é totalmente compatível com a linguagem AIML versão 1.0.1.
O “Program D” está atualmente na versão 4.6, disponibilizada em março de 2006. Em função de ser executado sobre a plataforma J2EE, necessita ser hospedado em um servidor de aplicações web Java, através da versão do Java 2 JRE (Java Runtime Edition). A versão do Java 2 JRE utilizada é jre1.5.0_06.
Como servidor de aplicações web Java optouse por utilizar o Apache Tomcat, que é distribuído como software livre e desenvolvido como código aberto dentro do conceituado projeto Apache Jakarta. O Tomcat é robusto e eficiente para ser utilizado tanto para pequenas aplicações como também para ambientes de produção, podendo ser instalado em diferentes sistemas operacionais. O Tomcat encontrase atualmente na versão 6.0.10 e está disponível no website http://tomcat.apache.org.
O código fonte do “Program D” é disponibilizado através de três maneiras diferentes:
· Binary: aplicação compilada, onde os arquivos não podem ser alterados, ou seja, prontos para execução.
· Source: código fonte da aplicação, onde os arquivos estão abertos e possibilitam a alteração do interpretador.
· Web application (WAR): aplicação compilada para o servidor web, onde os arquivos já se encontram no formato padrão e configurados para serem instalados no servidor web.
O protótipo que será desenvolvido utilizará o código fonte da aplicação (source), onde serão realizadas as alterações necessárias para integração do chatterbot com o sistema RBC. Ao fim do desenvolvimento será utilizada a estrutura de pastas e arquivos do formato WAR, para a instalação no servidor. Além do arquivo WAR, o chatterbot necessita de outras duas pastas em separado, onde são armazenadas as configurações e a base de conhecimento do chatterbot: “conf” e “resources”.
Na pasta “conf” estão localizadas as configurações do chatterbot, sendo composto por nove arquivos na extensão XML: Bots.xml; Core.xml; Listeners.xml; Log4j.xml; Plugins.xml;
Predicates.xml; Properties.xml; Sentencessplitters.xml; e Substitutions.xml. Cada um destes arquivos contém as configurações necessárias para o funcionamento do chatterbot.