Avaliação de um sistema escalável de classificação CNAE implementado em cloud computing

Texto

(1)Lucas de Paula Veronese. Avaliação de um Sistema Escalável de Classificação CNAE Implementado em Cloud Computing. Vitória - ES, Brasil.

(2) Lucas de Paula Veronese. Avaliação de um Sistema Escalável de Classificação CNAE Implementado em Cloud Computing Dissertação submetida ao Programa de PósGraduação em Informática da Univesidade Federal do Espírito como requisito parcial a obtenção do grau Mestre em Informática.. Orientador:. Prof. Dr. Elias Silva de Oliveira. P ROGRAMA DE P ÓS -G RADUAÇÃO EM I NFORMÁTICA C ENTRO T ECNOLÓGICO U NIVERSIDADE F EDERAL DO E SPÍRITO S ANTO. Vitória - ES, Brasil.

(3)

(4) Resumo Em problemas de classificação automática de texto com um grande número de rótulos, as bases de dados de treinamento são extensas, o que pode tornar o tempo de classificação proibitivo para os sistemas on-line. Destarte, nossa motivação para a realização deste trabalho veio da necessidade de o Governo Federal implementar no país um Cadastro Sincronizado Nacional (CSN) de empresas, onde a Classificação Nacional de Atividades Econômicas (CNAE) seria parte constituinte. Nesta tarefa de classificação, são associados um ou mais códigos CNAE-Subclasses à descrição de atividades econômicas de empresas. Vale destacar que, em 2009, a tarefa de atribuir ou revisar tais códigos CNAE foi realizada no país cerca de duas milhões de vezes. Diante disto, para a realização deste trabalho, nós investigamos o uso de servidores Web baseado em Cloud Computing devido à escalabilidade e ao baixo custo de desenvolvimento e operação. Pela facilidade de utilização e fornecimento de quotas livres, o servidor de Cloud Computing escolhido para desenvolvimento da aplicação foi o Google App Engine. Desta forma, nós projetamos, implementamos e hospedamos um sistema de classificação de textos dentro de tal servidor. No entanto, o Google App Engine cobra pelo serviço que ultrapassa a quantidade de quota livre (renovável diariamente), então, quanto menor a complexidade do processamento do sistema, menor o custo financeiro da aplicação. Foi feita uma otimização no sistema de armazenamento dos classificadores, aproveitando as características das bases de dados textuais. Houve uma redução do custo computacional do sistema e, em consequência, para a demanda atual de requisições CNAE o custo financeiro anual seria de 2000 dólares americanos. Este é um valor irrisório se comparado aos custos de infra-estrutura, manutenção e energia necessários para realizar um serviço semelhante ao de um servidor Web tradicional..

(5) Abstract In problems in automatic text classification with a large number of labels, training databases are large, therefore the classification time can become prohibitive for online rating systems. Thus, our motivation for this work came from the need of the Federal Government to implement a Cadastro Sincronizado Nacional (CSN) of companies, where the Classificação Nacional de Atividades Econômicas (CNAE) would compose the system. In this classification task one or more CNAE-Subclasses codes are associated to the description of the economic activities of companies. It is worth noticing that in 2009, the task of assigning codes or revise the CNAE was done in the country about 2 million times. This way, we investigated the use of Web servers based on Cloud Computing on its scalability and low cost of development and operation. Due to the ease of use and free quotas, the Cloud Computing server chosen for this application development was Google App Engine. Thus, we designed, implemented and hosted a system of classification of such texts on the server. However, Google App Engine service charges for exceeding the amount of free quota (renewable every day), whereas the lower the complexity of the processing system, the lower the financial cost of implementation. Aiming this, an optimization was performed on the storage system of classifiers, taking advantage of the features of the text base. We successfully reduced the computational cost of the system and, in consequence, it was estimated that for the current demand of requests the CNAE annual financial cost would be $ 2,000. This is a small amount when it is compared to the cost of infrastructure, maintenance and power that would take to perform a similar service to a traditional Web server..

(6) Dedicatória Dedico este trabalho aos meus pais Jésus e Marina, ao meu irmão Danilo e à minha namorada Ariadna; pelo amor, pela compreensão e pelo apoio..

(7) Agradecimentos Agradeço aos meus familiares por terem me ajudado muito em toda a minha vida; Agradeço a minha namorada por ter corrigido alguns erros na escrita, bem como por ter sido compreensiva nas inúmeras vezes em que me ausentei; Agradeço aos meus professores de graduação e mestrado, em especial ao meu orientador Dr. Elias Silva de Oliveira pelas oportunidades concedidas; Agradeço aos amigos Patrick, Lauro José, Filipe Mutz, André Almeida, Jorcy e Lucas Catabriga pela grande ajuda na implementação e na conclusão deste trabalho; Agradeço aos amigos Bruno Zanete e Felipe Pedroni que trabalharam comigo no LCAD; Por fim, agradeço ao CNPq pela bolsa de mestrado fornecida..

(8) Conteúdo. Lista de Figuras Lista de Tabelas 1. 2. 3. Introdução. p. 11. 1.1. Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 13. 1.2. Descrição do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 13. 1.3. Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 14. 1.4. Estrutura da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 14. Cloud Computing. p. 16. 2.1. Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 16. 2.1.1. Vantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 17. 2.1.2. Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 18. 2.1.3. Google App Engine-GAE . . . . . . . . . . . . . . . . . . . . . . .. p. 21. Classificação Multi-Rótulo de Texto. p. 26. 3.1. Classificação Multi-Rótulo de Texto . . . . . . . . . . . . . . . . . . . . . .. p. 26. 3.2. Indexação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 27. 3.3. Classificador k-Nearest Neighbors (k-NN) . . . . . . . . . . . . . . . . . . .. p. 28. 3.4. Rede Neural Probabilística . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 28. 3.5. Armazenamento dos Dados. . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 30. 3.6. Classificação de Atividade Econômicas . . . . . . . . . . . . . . . . . . . .. p. 35.

(9) 3.7 4. Métricas de Avaliação de Classificadores. . . . . . . . . . . . . . . . . . . .. Uma Arquitetura para o Sistema Servidor de Classificação de Códigos CNAE. p. 39. 4.1. O Sistema de Codificação Automática de Atividades Econômicas - SCAE . .. p. 39. 4.2. Provendo Escalabilidade do Serviço de Classificação Via Programação no Google Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 5. 6. p. 36. p. 41. Experimentos. p. 49. 5.1. Descrição das Bases de Dados . . . . . . . . . . . . . . . . . . . . . . . . .. p. 49. 5.2. Qualidade da Classificação . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 52. 5.3. Impacto do Tamanho da Base de Treino no Desempenho das Respostas . . .. p. 58. 5.4. Medida de Desempenho de Requisições Por Segundo . . . . . . . . . . . . .. p. 64. Conclusões e trabalhos futuros. p. 68. 6.1. Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 68. 6.2. Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 70. Bibliografia. p. 71.

(10) Lista de Figuras 2.1. Arquitetura de uma Cloud Computing (BUYYA, 2009). . . . . . . . . . . . .. p. 19. 2.2. Script Python helloworld.py . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 24. 2.3. Arquivo de configuração app.yaml . . . . . . . . . . . . . . . . . . . . . . .. p. 24. 2.4. Interface de Administração da aplicação no Google App Engine . . . . . . .. p. 25. 3.1. Arquitetura da Rede Neural Probabilística. . . . . . . . . . . . . . . . . . . .. p. 29. 3.2. Matriz mTV de treinamento. . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 31. 3.3. Matriz mTV Compactada. . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 32. 3.4. Armazenamento da matriz mTV na forma de índices invertido. . . . . . . . .. p. 33. 3.5. Vetor compactado do documento d j . . . . . . . . . . . . . . . . . . . . . . .. p. 33. 4.1. Arquitetura do SCAE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 40. 4.2. Dinâmica do Sistema de Classificação no Google App Engine. . . . . . . . .. p. 44. 4.3. Interface do Sistema de Classificação CNAE. . . . . . . . . . . . . . . . . .. p. 48. 4.4. Interface do Sistema de Classificação CNAE com a tabela de resposta. . . . .. p. 48. 5.1. Distribuição do número de classes por documento na base de dados VIX. . .. p. 50. 5.2. Distribuição do número de classes por documento na base de dados BH. . . .. p. 50. 5.3. Distribuição do número de classes por documento na base de dados EX100. .. p. 51. 5.4. Distribuição do número de classes por documento na base de dados AT100. .. p. 52. 5.5. Resultados da métrica One Error para base EX100,(a), e AT100, (b). Quanto menor, melhor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 5.6. p. 56. Resultados da métrica Hamming Loss para base EX100,(a), e AT100, (b). Quanto menor, melhor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 56.

(11) 5.7. Resultados da métrica Coverage para base EX100,(a), e AT100, (b). Quanto menor, melhor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 5.8. Resultados da métrica Ranking Loss para base EX100,(a), e AT100, (b). Quanto maior, melhor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 5.9. p. 57. p. 57. Resultados da métrica Average Precision para base EX100,(a), e AT100, (b). Quanto maior, melhor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 58. 5.10 Usuários do Sistema de Classificação CNAE. . . . . . . . . . . . . . . . . .. p. 59. 5.11 Gráfico de tempo para tratar 500 requisições a medida que a base de dados aumenta. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 61. 5.12 Gráfico do tempo (s) médio de CPU gasto para tratar cada requisição. . . . .. p. 62. 5.13 Gráfico de quota de CPU consumida por dia com o aumento do tamanho da base de dados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. p. 64. 5.14 Gráfico do Custo Diário do Sistema de Classificação CNAE. . . . . . . . . .. p. 65. 5.15 Gráfico Custo Anual do Sistema de Classificação CNAE. . . . . . . . . . . .. p. 66. 5.16 Página de administração do Google App Engine ao final do experimento. . . .. p. 67.

(12) Lista de Tabelas 2.1. Quotas Livre diárias do Google App Engine . . . . . . . . . . . . . . . . . .. p. 22. 3.1. Seções e denominações da tabela. . . . . . . . . . . . . . . . . . . . . . . .. p. 36. 3.2. Exemplo de hierarquia da tabela CNAE. . . . . . . . . . . . . . . . . . . . .. p. 37. 4.1. Linha do Arquivo “canonical_table.bin”. . . . . . . . . . . . . . . . . . . . .. p. 42. 5.1. Resultado de classificação da base de dados EX100 feita pelo algoritmo PNN.. p. 54. 5.2. Resultado de classificação da base de dados AT100 feita pelo algoritmo PNN.. p. 54. 5.3. Resultado de classificação da base de dados EX100 feita pelo algoritmo kNN.. p. 55. 5.4. Resultado de classificação da base de dados AT100 feita pelo algoritmo kNN.. p. 55. 5.5. Resultados dos experimentos de análise de custo computacional com aumento do tamanho da base de treino em potência de dois. . . . . . . . . . . .. 5.6. Custo médio da aplicação em dólares, considerando que a aplicação rodará o mesmo número de requisições todos os dias do ano. . . . . . . . . . . . . . .. 5.7. p. 60. p. 63. Custo médio da aplicação em dólares, considerando que a maioria das requisições são feitas em dias úteis. . . . . . . . . . . . . . . . . . . . . . . . . .. p. 63.

(13) 11. 1. Introdução. Na classificação multi-rotulada de texto, um sistema tipicamente produz um conjunto de rótulos, cujo tamanho é desconhecido a priori para cada documento sob análise. Em problemas do mundo real, a classificação multi-rotulada é frequentemente necessária (COMITE; GILLERON; TOMMASI, 2003; SCHAPIRE; SINGER, 2000). Diante disso, recentemente algumas abordagens foram propostas para tratar este tipo de problema, tais como árvores de decisão (COMITE; GILLERON; TOMMASI, 2003), métodos de núcleo (ELISSEEFF; WESTON, 2001), redes neurais artificiais (SOUZA et al., 2009) ou métodos de aprendizagem preguiçosa (ZHANG; ZHOU, 2007a). Para se obter um bom desempenho de classificação com estas técnicas, tipicamente são necessários muitos exemplares de treinamento para cada rótulo. Por essa razão, em problemas com um grande número de rótulos, as bases de dados de treinamento são grandes, o que pode tornar o tempo de classificação proibitivo para sistemas on-line. Uma possível solução seria utilizar cluster de servidores Web para tratar a demanda destes sistemas. No entanto, servidores Web são alocados para quando há picos de requisições. Desta maneira, esta solução gera um custo de energia e manutenção muito grande, pois eles ficam ociosos a maior parte do tempo. Outra saída seria a utilização de máquinas com alto grau de processamento, tais quais servidores comuns equipados com GPU. Contudo, as GPUs possuem limitações de memória e as trocas de mensagens entre CPU e GPU podem ser os gargalos de um sistema desta natureza. Todavia, um novo paradigma de servidores Web, chamado de Cloud Computer, tornou-se uma boa solução para os problemas de escalabilidade e consumo de energia. Sob este prisma, diversas aplicações compartilham os mesmos servidores, sendo que, as mesmas só são ativadas quando requisitadas. Há um baixo consumo de energia que aumenta a eficiência do sistema. Além disto, os usuários não precisam se preocupar com as estruturas dos Clouds nem como estão distribuídos. Os servidores de Cloud se encarregam de escalar a aplicação, sendo assim, não há sobrecarga de servidores. O principal problema desta solução é que os dados ficam concentrados em um único ponto.

(14) 12. e podem ser violados. Em aplicações onde o grau de sigilo não é muito grande, esta pode ser uma boa estratégia. Por esta via os usuários pagam somente pelo que usam, proporcionando uma grande economia. Para a nossa aplicação os Clouds se encaixam perfeitamente, pois dados numéricos pré-processados são enviados aos servidores, resguardando informações relevantes de terceiros. Para a realização de deste trabalho, escolhemos o servidor Google App Engine, como ferramenta para o desenvolvimento do Sistema de Classificação CNAE. Seu uso revelou-se extremamente satisfatório, com amplo acesso a diversos recursos tais como: vídeos, fóruns e textos em português e em inglês. A disponibilização de quotas gratuitas é outro fator decisivo na escolha deste servidor. Contudo, o Google App Engine peca em relação ao número de linguagens disponíveis, permite implementações somente em Java e em Python. Dentro do contexto de classificação multi-rotulada, nossa motivação para a realização deste trabalho veio da necessidade do Governo Federal implementar no país um Cadastro Sincronizado Nacional (CSN) de empresas (MF, 2010), onde a Classificação Nacional de Atividades Econômicas (CNAE) comporia o sistema supra citado. O CSN integra as administrações tributárias federal, estaduais e municipais bem como os demais órgãos envolvidos no processo de formalização das empresas, simplificando e racionalizando os procedimentos de abertura, manutenção e baixa de empresas. Uma das premissas do CSN é a coleta única de dados, desobrigando o cidadão a comparecer a vários órgãos para formalizar a sua empresa o que, por consequência, melhora o ambiente de negócios no país. Uma etapa importante no cadastro de uma empresa é a informação de códigos CNAE que descrevam o mais fielmente possível suas atividades econômicas. A tabela CNAE atual (CNAE 2.1) lista as 1.317 atividades econômicas legalmente aceitas no país. Sempre que uma empresa é constituída ou tem seu cadastro alterado, seus códigos CNAE devem ser atribuídos ou revistos, respectivamente. A automação da classificação de atividades econômicas de companhias, a partir de descrições destas atividades na forma de texto livre, é um grande desafio para a administração tributária. Atualmente, esta tarefa tem sido executada repetidas vezes por funcionários públicos das três esferas do governo, sendo que nem todos são apropriadamente treinados para esta tarefa. Além disso, quando o problema de classificação é resolvido diretamente por humanos, sua subjetividade traz um problema: diferentes classificadores humanos podem atribuir diferentes categorias à uma mesma descrição de atividade econômica. Isto pode causar distorções na informação usada para planejamento, tributação e outras obrigações governamentais nos três níveis da administração: municipal, estadual e federal..

(15) 13. 1.1. Motivação. A burocracia para se abrir uma empresa no Brasil leva, em média, 152 dias, sendo uma das mais longas da América Latina. O tempo é demorado porque praticamente todo o processo de registro de uma empresa é manual. Diante de tantas dificuldades (o custo para treinar classificadores humanos, a impaciência dos usuários, o grande crescimento do país, etc) o foco desse trabalho foi automatizar o processo de classificação de objetos sociais de empresas. Estimamos que sejam necessárias cerca de 130.000 descrições de atividades econômicas com seus respectivos códigos CNAE para tornar possível a implementação de um classificador automático com bom desempenho de classificação (cerca de 100 exemplares para cada código CNAE). Com esta quantidade de dados de treinamento, o tempo de classificação pode ser proibitivo para sistemas on-line. Vale destacar que, em 2009, a tarefa de atribuir ou revisar códigos CNAE de empresas foi realizada no país cerca de 2.100.000 vezes (DNRC, 2007; SOUZA et al., 2009).. 1.2. Descrição do Problema. No Brasil, assim como em muitos outros países, uma empresa necessita de um contrato com a sociedade para operar legalmente. Este contrato é denominado contrato social e deve conter a declaração de propósitos de atividades a serem exercidas por essa empresa. Essas atividades econômicas da empresa devem ser classificadas dentro de uma ou mais atividades legais por autoridades do governo brasileiro. Para isso, todas as atividades legais são catalogadas utilizando-se de uma tabela chamada Tabela de Classificação Nacional de Atividades Econômicas(CNAE) (CNAE, 2003a; OLIVEIRA et al., 2008; SOUZA et al., 2009). Para realizar esse tipo de classificação, funcionários do governo (em nível Federal, Estadual e Municipal) devem encontrar uma correspondência semântica entre a descrição das atividades econômicas da empresa e uma ou mais entradas da tabela CNAE. Existe um código numérico para cada entrada da tabela CNAE e, na tarefa de classificação, os funcionários do Governo atribuem manualmente um ou mais códigos para cada empresa (OLIVEIRA et al., 2008; SOUZA et al., 2009). Um sistema centralizado de classificação seria muito útil, pois poderia fornecer apenas um subconjunto dos códigos CNAE-Suclasses para cada empresa. Desta forma, a subjetividade da classificação, o tempo de criação de uma empresa e a demanda de mão de obra seriam reduzidas. Contudo, o sistema centralizado de classificação deverá ser muito requisitado, pois ele terá.

(16) 14. que tratar toda a demanda brasileira. Com isto, a escalabilidade do Sistema de Classificação CNAE se faz necessária. Portanto, seria adequado o uso de servidores que proporcionam este serviço.. 1.3. Contribuições. Neste trabalho nós avaliamos a viabilidade de se criar um sistema online de classificação multi-rotulada de textos num ambiente escalável automaticamente. A função do sistema é auxiliar os classificadores humanos para acelerar a codificação CNAE e diminuir a subjetividade no processo, gerando economia e facilitando a abertura de novas empresas no Brasil. O resultado deste estudo foi implementado e está disponível no site www.cnae.net.br. Diante disto, para a realização deste trabalho, nós investigamos o uso de servidores Web baseado em Cloud Computing devido à escalabilidade e ao baixo custo de desenvolvimento e operação. Pela facilidade de utilização e fornecimento de quotas livres, o servidor de Cloud Computing escolhido para desenvolvimento da aplicação foi o Google App Engine. Desta forma, nós projetamos, implementamos e hospedamos um sistema de classificação de textos dentro de tal servidor. No entanto, o Google App Engine cobra pelo serviço que ultrapassa a quantidade de quota livre (renovável diariamente), então, quanto menor a complexidade do processamento do sistema, menor o custo financeiro da aplicação. Sendo assim, nós estudamos formas alternativas de armazenamento de dados com intuito de reduzir a utilização de espaço no servidor hospedeiro. Para tanto, avaliamos as modernas estratégias de armazenamento de dados utilizadas pela atuais search engines (BAEZA-YATES; RIBEIRO-NETO, 1999; BADUE et al., 2001). Em consequência, houve uma redução do custo computacional do sistema. Para a demanda um 36 milhões requisições por ano, o custo financeiro anual seria de 2000 dólares americanos. Este é um valor baixo se comparado aos custos de infra-estrutura, manutenção e energia necessários para realizar um serviço semelhante ao de um servidor Web tradicional.. 1.4. Estrutura da Dissertação. Após esta introdução, esta dissertação está estruturada da seguinte forma: • O Capítulo 2 apresenta uma descrição da arquitetura de Cloud Computing, além disto, descreveremos com mais detalhes o sistema comercial de Cloud Computing do Google..

(17) 15. • Uma definição formal de classificação multi-rotulada de textos é descrita no Capítulo 3. Em adicional, são mencionadas as técnicas de classificação, as estruturas de dados para armazenamento do treinamento dos algoritmos, as métricas de avaliação da classificação e, por fim, o problema de clasi de atividades econômicas; • O Capítulo 4 mostra a arquitetura do Sistema de Codificação Automática de Atividades Econômicas o SCAE, além da arquitetura e o projeto do Sistema de Classificação CNAE hospedado no Google App Engine. • O Capítulo 5 apresenta uma descrição das bases de dados utilizadas nos experimentos, uma discussão dos resultados de classificação e uma avaliação da escalabilidade do sistema. • Por fim, o Capítulo 6 sumariza os resultados obtidos, apresenta as nossas conclusões e propostas de trabalhos futuros..

(18) 16. 2. Cloud Computing. Neste capítulo, formalizaremos a arquitetura de Cloud Computing segundo (BUYYA, 2009), além disto, apresentaremos com mais detalhes o sistema comercial de Cloud Computing do Google (GOOGLE, 2010).. 2.1. Cloud Computing. Com a evolução dos sistemas de computação (SC) e da internet ao longo dos anos, as pessoas hoje podem realizar inúmeras atividades virtualmente, sejam estas de natureza social (redes sociais), acadêmica (ensino à distância) ou, até mesmo, laboral (home office).Em consonância com estas novas tendências, surgiram inúmeros paradigmas de computação dentre os quais destacamos Cluster Computing, Grid Computing, Peer to peer (P2P) Computing, Service Computing, Market- Oriented Computing e o mais recente Cloud Computing (BUYYA, 2009). As tecnologias de Cloud Computing são uma evolução das tecnologias de Grid Computing (AYMERICH; FENU; SURCIS, 2008). Nesta fase de transição em direção ao Cloud Computing, novas categorias de serviços de tecnologia da informação (TI) estão sendo criados para todos os tipos de aplicações, tais como: banco de dados e serviços, provendo armazenamento, backups, proteção de dados, segurança. As principais categorias são: Software como um Serviço (Software as a Service-SaaS), Infraestrutura como um Serviço (Infrastructure as a Service-IaaS), Banco de Dados como um Serviço (Database as a Service-DaaS) e Plataforma como um Serviço (Platform as a Service-PaaS) (BUYYA, 2009; AMAZON, 2010; GOOGLE, 2010). Como exemplos de categorias de serviços oferecidos por Cloud Computing destacamos: o SaaS Google Docs os usuários podem utilizar o editor para escrever e compartilhar textos. O Google App Engine um IaaS, os usuários compartilham recursos de processamento, banda e banco de dados para hospedarem páginas Web. No DaaS pessoas de um mesmo grupo podem compartilhar arquivos, como o Google Groups. Na PaaS todos compartilham recursos de uma.

(19) 17. plataforma, a Amazon, oferece um Cluster de computadores para que os usuários possam rodar aplicações de alto desempenho. O Cloud Computing promete serviços confiáveis entregues através da nova geração de datacenters que são construídos dentro das tecnologias de computação e armazenamento virtual. Os consumidores poderão acessar as aplicações e os dados de um Cloud Computing em qualquer lugar no mundo. Em outras palavras, o Cloud Computing se apresenta como um único ponto de acesso para todas as necessidades de computação dos consumidores (BUYYA, 2009). O Cloud Computing é um tipo de sistema paralelo e distribuído que consiste em um conjunto de computadores interligados e virtualizados. Os computadores são dinamicamente alocados e apresentados como um ou mais recursos de computação unificada baseada em acordos de nível de serviço estabelecido através de negociação entre o prestador de serviços e os consumidores (BUYYA, 2009). Os consumidores de cloud computing não estão interessados em construir sua própria infraestrutura. Eles, ao invés de gastarem muito dinheiro e tempo na construção de uma estrutura de hardware, alugam servidores de terceiros. Desta forma, o consumo de recursos é um serviço e é pago somente o que é usado pela aplicação. Compartilhando recursos computacionais entre milhares de usuários, assim, servidores não são usados desnecessariamente o que pode reduzir significativamente os custos enquanto aumenta a velocidade de desenvolvimento de aplicações (BUYYA, 2009). Entre as principais plataformas de cloud disponíveis para desenvolvimento estão Google e Amazon. O Amazon Elastic Compute Cloud (EC2) (AMAZON, 2010) fornece um ambiente virtual de computação que permite aos usuários rodarem aplicações Linux. Os usuários podem criar um novo Amazon Machine Image (AMI) contendo as aplicações, bibliotecas (libs), dados e os modelos de codificações, ou selecionar libs globais disponíveis nos AMIs. Por sua vez, O Google App Engine permite que os usuários desenvolvedores rodem aplicações Web escritas em Python e Java as administrem facilmente através de uma página Web. Atualmente, o Google libera para os desenvolvedores uma quota livre de 5 milhões de page views (acessos à página) e 500MB de armazenamento (BUYYA, 2009; GOOGLE, 2010).. 2.1.1. Vantagens. De uma maneira geral, serviço de plataforma é uma evolução da terceirização na área de TI. A maioria das empresas não tem como atividade principal a gestão de TI, de forma que se mostra coerente a contratação de uma plataforma externa robusta para apoiar processos como.

(20) 18. gestão empresarial, pagamentos e recebimentos, banco de dados, desenvolvimento de produtos (como renderização de vídeos, CAD, etc.), apoio a serviços (processamento de dados, etc.) e demais. Nesse caso, a TI passa a ser efetivamente uma ferramenta de suporte ao negócio, ou seja, o foco do cliente é a informação e não a forma como ela é mantida e processada. Mesmo para as organizações de TI, há vantagens, pois elas gastam 80% de seu tempo com a manutenção de sistemas, e isto não é seu objetivo de negócio (BARROS, 2008). Sendo assim, as empresas e desenvolvedores não precisam se preocupar onde e como suas aplicações estão rodando, tornando-as mais simples e fácil de manter, consequentemente mais baratas, seguras, robustas e escaláveis. Deste modo, não gastam tempo e dinheiro projetando e mantendo uma infraestrutura de hardware e software, então a única preocupação passa ser o desenvolvimento (AYMERICH; FENU; SURCIS, 2008). Como a infraestrutura de um cloud é compartilhada, os datacenters quase nunca ficam ociosos. Por outro lado, as soluções de infraestrutura tradicionais que são projetadas para suportar picos de uso das aplicações, ficam ociosas boa parte do tempo gastando energia desnecessariamente. Portanto, um cloud datacenter em geral consume menos energia, refrigeração e espaço físico. Consequentemente contribui para preservação e uso racional dos recursos naturais (AYMERICH; FENU; SURCIS, 2008; BUYYA, 2009). O investimento em aplicações passa a ser muito menor, o desenvolvimento e armazenamento dos dados são simplificados, logo a produtividade das empresas pode aumentar muito. De uma maneira geral isto é importante para todos os tipos de negócios, pois os dados passam a ser centralizados, desta maneira podem ser compartilhados e acessados em tempo real de qualquer lugar do mundo. Com isto muitas empresas têm migrado para este tipo de solução, principalmente as de pequeno e médio porte (AYMERICH; FENU; SURCIS, 2008).. 2.1.2. Arquitetura. O sistema de computação cloud computing é uma forma de armazenamento remoto compartilhado, assim, precisa garantir uma qualidade de serviço ou Quality of Service-QoS. Para isto, um cloud datacenter precisa de uma arquitetura robusta. A constituição de um cloud é composta por um sistema de hardware e sotfware com muitos componentes. Tal estrutura foi construída com a filosofia UNIX, de múltiplos programas, cada um realizando uma atividade distinta, tendo em comum uma interface universal. A complexidade é controlada e os sistemas resultantes são mais facilmente gerenciáveis (AYMERICH; FENU; SURCIS, 2008) (BUYYA, 2009)..

(21) 19. Os dois componentes mais importantes da arquitetura de um cloud computing são o frontend e o back-end. O front-end é a parte que é vista pelo cliente. Isto inclui a rede do cliente e as aplicações que são usadas para acessar o cloud via um usuário, por exemplo um browser. Por outro lado o back-end é composta pela infraestrutura do cloud, contendo vários computadores e dispositivos de armazenamento. O detalhamento mais profundo do back-end da arquitetura de um cloud é mostrado na Figura 2.1 (BUYYA, 2009):. Figura 2.1: Arquitetura de uma Cloud Computing (BUYYA, 2009).. • Usuário/Brokers: Usuários ou Brokers submetem uma requisição, de qualquer lugar do mundo, para ser processada no Cloud. • Service Level Agreements - SLA: O SLA (em português, Acordos de Nível de Serviço) funciona como uma interface entre o prestador de serviço do Cloud e os usuários. Para.

(22) 20. fazer o interfaceamento, ele requer uma interação com os seguintes recursos de gerenciamento. – Serviço Examinador de Requisições e Controle de Admissão: Quando um serviço é submetido, o Serviço Examinador de Requisições e Controle de Admissão interpreta a submissão para requisitos de QoS antes de determinar se aceita ou rejeita a requisição. Assim, ele garante que não haja sobrecarga dos recursos e todos os pedidos de serviços sejam executados com sucesso. É necessário, também, receber as informações mais recentes sobre a disponibilidade de recursos (Monitor da Virtual Machine-VM, em português Máquina Virtual) e carga de processamento (Monitor de Requisições), a fim de tomar decisões de alocação de recursos de forma eficaz. Em seguida, ele atribui as solicitações para VM e determina os recursos a serem alocados nas mesmas. – Avaliador: O Avaliador decide como o serviço de requisição será carregado. Ele administra os recursos, a demanda computacional e dá prioridades na alocação dos recursos. – Contador: O Contador mantém o uso atual dos recursos por requisições, então o custo final pode ser atualizado para cada usuário. Em adicional, mantém o histórico das informações de uso que pode ser usado pelo Serviço Examinador de Requisições e Controle de Admissão para melhorar alocação de recursos. – Monitor da VM: O Monitor da VM mantém a disponibilidade e os recursos das VMs. – Despacho: O Despacho começa a execução de uma requisição na VM. – Monitor de Requisições: O Monitor de Requisições mantém o caminho e progresso de uma requisição. • VMs: Múltiplas VMs podem ser executadas e terminadas dinamicamente em uma única máquina, dando o máximo de flexibilidade para configurar a divisão dos recursos. Deste modo, várias VMs podem rodar concorrentemente em um mesmo Servidor com diferentes Sistemas Operacionais. • Servidores Físicos: Os Servidores Físicos são os DataCenters onde as VMs executarão, para tratar as requisições..

(23) 21. 2.1.3. Google App Engine-GAE. Google App Engine é uma plataforma de execução baseada em Python e Java que fornece hospedagem de aplicações Web, armazenamento de dados e redes de alta velocidade, executando em cima da gigantesca infraestrutura do Google. O GAE é uma tecnologia de computação em Cloud que virtualiza aplicações em vários servidores, sua versão beta foi lançada em abril de 2008. O App Engine difere de serviços como o Amazon Web Services (AWS), pois o AWS é uma IaaS, enquanto que o GAE é uma PaaS (CIURANA, 2009). A infraestrutura oferecida pelo Google é automática, procurando moldar o tráfego e balanceamento de carga para seu aplicativo, distribuindo-o em vários servidores. Cada aplicativo é executado em sua própria área de memória (sandbox), independente de outras aplicações e conflitos em potencial. Deste modo, o GAE permite que vários aplicativos execute no mesmo servidor sem que o comportamento de um aplicativo afete o outro. Além de limitar o acesso ao sistema operacional, o ambiente de execução também limita a quantidade de tempo do relógio, uso de CPU e memória que um pedido pode tomar. O App Engine mantém esses limites flexíveis e aplica limites mais rigorosos para as aplicações que utilizam mais recursos para proteger os recursos compartilhados (SANDERSON, 2009). Esta restrições permitem que o App Engine escalone melhor as requisições para que, na sua estimativa, o servidor forneça a resposta o mais rápido possível. O GAE também limita a manipulação de arquivos, uma aplicação só consegue ler seus próprios arquivos, a criação e as gravações de outros não são permitidas. O GAE é projetado para hospedar aplicações com muitos usuários simultâneos. Quando uma aplicação pode servir a muitos usuários simultâneos sem prejudicar o desempenho, dizemos que ela é escalável. Os aplicativos escritos para o App Engine escalam automaticamente. Quanto mais as pessoas usarem a aplicação, o App Engine aloca mais recursos para a aplicação e administra o uso desses recursos. Assim, a aplicação em si não precisa saber nada sobre os recursos que estão sendo usados(CIURANA, 2009). Para garantir a escalabilidade, as aplicações hospedadas no Google App Engine são tratadas em qualquer número de instâncias (instâncias são as unidades de computação que o App Engine usa para escalar sua aplicação automaticamente) a qualquer momento, isto depende do volume de requisições que são recebidas. Cada instância tem sua própria fila para receber os pedidos. O App Engine monitora o número de pedidos aguardando na fila de cada instância. Se App Engine detecta que as filas para um aplicativo estão sobrecarregadas, ele automaticamente cria uma nova instância do aplicativo para lidar com essa carga excedente. Quando o número de.

(24) 22. requisições diminui o App Engine escala no sentido inverso, ou seja, reduz o número de recursos alocados. Deste modo, ele garante que todas as instâncias correntes da aplicação estão sendo tratadas com máxima eficiência. Esta escalabilidade automática faz com que o Google App Engine rode com um custo efetivo baixo (GOOGLE, 2010). Ao contrário de Web hosting (servidores de hospedagem de sites) tradicionais de hospedagem ou servidores gerenciáveis, com o Google App Engine você paga apenas pelos recursos que você usa. Esses recursos são medidos em gigabyte, sem mensalidades ou taxas pré-pagas. Os recursos pagos para uso incluem CPU, armazenamento por mês de banda, entrada e saída, e vários recursos específicos para serviços de App Engine. Para ajudar a começar, cada desenvolvedor recebe uma certa quantidade de recursos livres que são renovados a cada dia, o suficiente para pequenas aplicações com baixo tráfego. O Google estima que, com os recursos livres, um aplicativo pode acomodar cerca de 5 milhões de page views por mês (CIURANA, 2009). As aplicações para rodar no Google App Engine são fáceis de construir, manter e escalar. Na prática não há limitações do que pode ser feito usando este tipo de sistema. Os desenvolvedores podem construir desde aplicações simples ou até aplicações que demandem muito poder de processamento. Este tipo de tecnologia ainda é muito recente, portanto, algumas empresas e usuários estão receosos em mudar suas aplicações para este tipo de solução, pois os dados ficam concentrados em um único ponto. Outra característica relevante do GAE são as quotas livres diárias. Isto facilita o desenvolvimento e os testes da nova aplicação (CIURANA, 2009; GOOGLE, 2010). A Tabela 2.1 mostra a quantidade de quotas livres. Quota Emails Quantidade de dados de entrada Quantidade de dados de saída Tempo CPU Dados para armazenamento. Limite 100 1 GB 1 GB 6.5 horas 1 GB. Tabela 2.1: Quotas Livre diárias do Google App Engine. Embora o GAE seja flexível quanto ao uso de seus servidores, um requisição feita para uma aplicação tem no máximo 30 segundos para retornar uma resposta para o cliente. Isso possa parecer um valor suficientemente confortável para uma aplicação Web, o App Engine é otimizado para aplicativos que respondem em menos de um segundo. Além disso, se um aplicativo usa muitos ciclos de CPU, o App Engine pode retardá-lo, assim o aplicativo não monopoliza o processador em uma máquina que está servindo várias aplicações (SANDERSON, 2009)..

(25) 23. Apesar das grades vantagens do uso desta plataforma, o GAE não flexibiliza o desenvolvimento restringindo o uso das linguagens. Deste modo, o desenvolvimento das aplicações devem cumprir vários requisitos a fim de garantir a segurança e robustez da infraestrutura do Cloud. Uma aplicação hospedada no GAE deve ser chamada somente por requisições HTTP e seus arquivos de armazenamento podem ser lidos durante a execução, porem nunca podem ser escritos. No upload dos arquivos do sistema para o GAE eles devem conter somente Python puro sem nenhum modulo C. Já as aplicações escritas em Java podem conter somente um subconjunto restrito de classes da edição padrão da linguagem e, além disto, as mesmas não poderem criar novas threads de execução (CIURANA, 2009; GOOGLE, 2010). Construção de uma Aplicação no Google app Engine Quando uma nova aplicação é criada dentro do GAE ela tem um endereço contendo o nome da aplicação seguido de .appspot.com. Caso desenvolvedor deseje criar um domínio www, ele deve registrá-lo em algum servidor de DNS e apontar para o domínio que registrado no GAE (CIURANA, 2009; GOOGLE, 2010). Todavia, não é necessário ter uma conta no Google para começar o desenvolvimento de uma aplicação, assim, o primeiro passo para construir uma aplicação que rodará no Cloud da Google é fazer o download do Software Development Kit, SDK, que pode ser Java ou Python. Todo o desenvolvimento da nossa aplicação que está rodando no Google app foi feita em Python, por isto estaremos explicando como construir uma aplicação utilizando o SDK de Python. As aplicações podem ser construídas em vários tipos de Sistema Operacional: Linux, MAC OS X, Windows. Como, nós conhecemos melhor o Linux então a nossa explicação estará baseada nele. A seguir, crie um diretório onde ficarão os arquivos da sua aplicação, neste caso, nossa primeira aplicação será o helloworld. Agora entre no diretório e crie um arquivo helloworld.py (o nome do arquivo pode ser qualquer desde que ele termine com “.py”), e coloque nele o conteúdo da Figura 2.2. Este script Python responde a uma solicitação com um cabeçalho HTTP descrevendo o conteúdo, uma linha em branco e a mensagem Hello, world!. Um aplicativo do Google App Engine possui um arquivo de configuração, denominado app.yaml. Entre outras coisas, esse arquivo descreve quais scripts trataram tais URLs. Dentro do diretório, crie um arquivo denominado app.yaml e coloque nele o conteúdo da Figura 2.3. Sendo assim, o aplicativo helloworld está pronto para ser testado. O SDK do Google App Engine fornece um servidor Web para testar a aplicação, desta forma, execute o servidor com o seguinte comando: python google_appengine/dev_appserver.py helloworld/. Com isto a apli-.

(26) 24. Figura 2.2: Script Python helloworld.py. Figura 2.3: Arquivo de configuração app.yaml cação pode ser chamada através do browser pela URL: http://localhost:8080/. Além do suporte ao desenvolvimento o Google App Engine oferece uma interface de administração da aplicação, que é mostrada na Figura 2.4. Nela podemos monitorar o quanto de processamento e espaço que a aplicação está consumindo, além disto, ela guarda os logs das requisições. Esta interface oferece um gerenciamento completo da aplicação, facilitando o monitoramento do consumo de quotas e, caso necessário, a contratação de novas..

(27) 25. Figura 2.4: Interface de Administração da aplicação no Google App Engine.

(28) 26. 3. Classificação Multi-Rótulo de Texto. Neste capítulo apresentaremos uma definição formal da classificação multi-rotulada de textos e os algoritmos k-Nearest Neighbor (kNN) e a Probalistic Neural Network (PNN) que foram estudados neste trabalho. Além disto, explicaremos os métodos de armazenamento de dados otimizados para algoritmos de classificação, e as métricas de avaliação dos mesmos. Por fim, descreveremos o problema de descrições de atividades econômicas de empresas brasileiras segundo a Classificação Nacional de Atividades Econômicas (CNAE) (CNAE, 2003b).. 3.1. Classificação Multi-Rótulo de Texto. Seja D um domínio de documentos, C = c1 , c2 , ..., c|C| um conjunto pré-definido de categorias e Ω = d1 , d2 , ..., d|Ω| um corpus inicial de documentos previamente classificados manualmente por peritos do domínio. Na classificação multi-rótulo, cada documento di ∈ Ω é classificado em uma ou mais categorias de C (VERONESE et al., 2009b, 2009a, 2009c). Em um sistema de classificação baseado em aprendizado de máquina, Ω é dividido em dois subconjuntos, TV e Te. TV é usado para treinar (e validar eventuais parâmetros de) o sistema. Este treinamento é feito associando subconjuntos apropriados de C a características extraídas de cada documento di ∈ TV . Te, por outro lado, consiste de documentos para os quais as categorias apropriadas não são do conhecimento do sistema de classificação. Depois de ser treinado e validado com TV , o sistema de classificação é usado para predizer o conjunto de categorias de cada documento d j ∈ Te (VERONESE et al., 2009b, 2009a, 2009c). Um sistema automático de classificação multi-rótulo tipicamente implementa uma função na forma f : D × C → ℜ que retorna um número real que representa o grau de crença de cada par hd j , ci i ∈ hD × Ci isto é, um número que representa a confiança do classificador de que o documento de teste d j deve ser classificado sob a categoria ci . A função f (., .) pode ser transformada numa função de ranking r(., .), tal que, se f (d j , ci ) > f (d j , ck ), então r(d j , ci ) < r(d j , ck ), e se f (d j , ci ) < f (d j , ck ), então r(d j , ci ) > r(d j , ck ) (VERONESE et al., 2009b, 2009a,.

(29) 27. 2009c). Seja C j o conjunto de categorias pertinentes ao documento de teste d j . Um sistema de classificação bem sucedido tenderá a posicionar as categorias pertencentes a C j em posições mais elevadas no ranking do que aquelas não pertencentes a C j (VERONESE et al., 2009b, 2009a, 2009c).. 3.2. Indexação. Antes de serem classificados, os textos devem ser convertidos para um formato apropriado para o classificador, por meio de um procedimento denominado indexação (SEBASTIANI, 2002) (a indexação é um mecanismo de extração de características). Para o classificador, um → − texto d j deve ser convertido em um vetor de pesos de termos d j = hw1, j , w2, j , ..., w|V |, j i onde V é o conjunto de termos (ou palavras) que ocorrem pelo menos uma vez em um documento de TV , e O ≤ wk, j ≤ 1 busca representar o quanto um termo tk contribui para a classificação do documento d j . A representação dos documentos na forma de vetores é conhecida na literatura como modelo de espaço vetorial (BAEZA-YATES; RIBEIRO-NETO, 1999). Assim, a base TV de documentos será transformada em uma matriz mTV de termos por documentos, onde cada célula da matriz é o peso de cada termo em um documento (VERONESE et al., 2009b, 2009a, 2009c; SEBASTIANI, 2002). A função t f id f (tk , d j ) usualmente é empregada no processo de indexação (t f id f significa term frequency inverse document frequency) (SEBASTIANI, 2002). t f id f (tk , d j ) retorna o peso wk, j do termo tk no documento d j , sendo dada por: t f id f (tk , d j ) = t f (tk , d j ) · log. |TV | d f (tk ). (3.1). onde t f (tk , d j ), ou term frequency, denota o número de vezes que tk ocorre em d j e d f (tk ), ou document frequency, denota o número de documentos em TV nos quais tk ocorre. Para que os pesos estejam no intervalo [0, 1] e para que os documentos sejam representados por vetores de magnitude igual, os pesos computados por t f (tk , d j ) são geralmente normalizados conforme a Equação 3.2 (SEBASTIANI, 2002).. wk, j = s. t f id f (tk , d j ) |V |. ∑ (t f id f (ts , d j ))2 s=1. (3.2).

(30) 28. 3.3. Classificador k-Nearest Neighbors (k-NN). O classificador k-NN (SEBASTIANI, 2002) encontra os k vizinhos mais próximos de um documento de entrada d j no conjunto de documentos previamente aprendidos, TV , de acordo com alguma métrica de distância. Nos experimentos reportados neste trabalho, usamos o cosseno do ângulo entre o vetor que representa d j e o vetor que representa cada documento di ∈ TV . O cosseno é uma métrica de distância comumente usada na literatura (SEBASTIANI, 2002) e é dada por: |V |. → − → − cos( d j , di ) = s. ∑ wz, j · wz,i s. z=1 |V |. |V |. z=1. z=1. ∑ w2z, j. (3.3). ∑ w2z,i. A função f (d j , ck ) do classificador k-NN retorna o maior valor de cos(d j , di ) para di ∈ TV e ck ∈ Ci , onde Ci é o conjunto de categorias pertinentes ao documento di . O classificador k-NN extrai os k pares hd j , ci i ∈ hD×Ci no topo do ranking construído a partir de f (., .) (VERONESE et al., 2009b, 2009a; MELOTTI, 2009). O principal custo computacional do classificador k-NN está relacionado ao cômputo do numerador da Equação 3.3 – um produto de matriz por vetor –, uma vez que, para se encontrar o → − → − → − → − maior cos( d j , di ) para di ∈ TV e ck ∈ Ci , todos os di ∈ TV têm que ser examinados. O custo → − computacional do denominador é pequeno porque a norma de d j só precisa ser computada → − → − uma vez para cada d j (primeiro somatório no denominador) e as normas de di ∈ TV (segundo somatório no denominador) podem ser computadas previamente e usadas para todos os documentos d j que se deseje classificar (VERONESE et al., 2009b, 2009a; MELOTTI, 2009).. 3.4. Rede Neural Probabilística. A Rede Neural Probabilística (Probabilistic Neural Network - PNN) foi inicialmente proposta em (SPECHT, 1990). Ela é uma rede neural de arquitetura direta, multi-camadas com mapeamento não linear da entrada para a saída. Esta rede foi projetada para fazer a classificação de problemas com único rótulo (single-label). Porém nosso problema é multi-rótulo (multi-label), e através de uma modificação feita em Oliveira et al. (2008), agora ela é capaz de resolver problemas de classificação de texto com múltiplos rótulos. Esta PNN é composta por três camadas: camada de entrada, de padrões e de soma (VERONESE et al., 2009a, 2009c). A Figura 3.1 mostra um exemplo da PNN..

(31) 29. Figura 3.1: Arquitetura da Rede Neural Probabilística.. No treinamento, a PNN recebe e armazena uma matriz, mTV , de documentos × termos, e uma matriz, mC, de documentos × categorias. O documento di é a linha i da matriz mTV e as categorias associadas a ele são aquelas da linha i da matriz mC. Os pesos dos termos que ocorrem em cada documento di estão nas colunas da matriz mTV . Cada coluna de mC representa, então, uma das categorias de C (VERONESE et al., 2009a, 2009c). Para cada documento di da matriz mTV é criado um conjunto de neurônios, um para cada → − categoria ck ∈ Ci , onde cada neurônio nk,i armazena o vetor di com um vetor de pesos de termo −→ Wk,i (VERONESE et al., 2009a, 2009c). Na fase de classificação é apresentado à camada de entrada um documento d j , o qual se deseja classificar. Nessa camada nada é computado, ela simplesmente passa o documento d j para a camada de padrões. Cada neurônio nk,i da camada de padrões possui a função de ativação → − A( d j , ck , ni ), apresentada na Equação 3.4: ! − −→ → Wk,i · d j − 1 1 exp ; k = 1, ..., |C|; i = 1, ..., |Dk | (3.4) A(d j , ck , ni ) = 2πσ σ2 onde σ é constante para todos os neurônios (ajustada no treino para o melhor desempenho de classificação), C é o conjunto de categorias possíveis, e Dk é o conjunto de documentos.

(32) 30. associados à categoria ck (VERONESE et al., 2009a, 2009c). A principal operação realizada pelo algoritmo é o produto interno Wk,i · d j . Apesar de um documento de treino di resultar na criação de mais de um neurônio na camada de padrões, i.e., → − um para cada ck , o produto só precisa ser computado uma vez para cada di . Ou seja, todos → − os produtos necessários podem ser obtidos por meio do produto matriz por vetor mTV · d j (VERONESE et al., 2009a, 2009c). O próximo passo é o cômputo da camada onde são feitas as somas dos resultados da camada de padrões. Na camada de soma, que tem |C| neurônios, cada neurônio está associado com uma categoria ck e computa a função f (d j , ck ), que é apresentada na Equação 3.5. |Nk |. f (d j , ck ) =. ∑ A(d j , ck , ni); k = 1, ..., |C|. (3.5). i=1. onde |Nk | é o número de neurônios da camada de padrões associados à ck (VERONESE et al., 2009a, 2009c).. 3.5. Armazenamento dos Dados. → − Em ambos classificadores a operação mais custosa na classificação é mTV · d j . Suponha → − que a matriz mTV tenha dimensões n × m, onde n = |TV | e m = |V | e d j tenha dimensão m. Desta forma, para classificar um documento d j o custo computacional é n · m. Se n ' m, então a complexidade dos algoritmos de classificação é O(n2 ). O problema não está relacionado somente com a complexidade quadrática do produto → − mTV · d j , outro agravante é o armazenamento da mTV . Se mTV for armazenada na forma de uma matriz comum a complexidade de armazenamento será também O(n2 ). Para calcular a quantidade de memória gasta por mTV é só multiplicar (n2 ) ∗ 4, onde 4 é o tamanho em Bytes do número em precisão simples do padrão IEEE-754. Se n = 130.000 então o espaço consumido por mTV é igual a 62, 96 GB. Para os computadores de hoje isto não é um tamanho tão grande, pois já existem servidores com mais de 100GB de memória principal e 2000 GB de Hard Disk-HD. Entretanto, se indexamos a Web para a construção de uma máquina de busca, armazenar os dados desta forma seria inviável, pois a Web mundial contém trilhões de páginas. Portanto, o uso de formas compactas de armazenamento é muito importante, tanto para reduzir a complexidade de processamento quanto a de armazenamento dos dados de treinamento. Uma forma de comprimir os vetores dos documentos de treinamento seria retirar os zeros do vetor, por causa da grande esparsidade de mTV . Na remoção das posições nulas de mTV basta.

(33) 31. criar duas matrizes (com linhas de tamanho variado), uma de ponto flutuante para armazenar os pesos não nulos e um outro de inteiros para armazenar as colunas onde os pesos são diferentes de zero. Suponha que TV contenha 9 documentos e 7 termos distintos, com isto, a matriz mTV , que está representada pela Figura 3.2, tem um tamanho 9 × 7 e consome 252Bytes para ser armazenada. Dado Pn o número de posições não nulas de mTV , então, o espaço consumido pela compressão de mTV é calculado pela equação 4 × (Pn + Pn + |TV |) Bytes, onde 4 é o tamanho em Bytes de um inteiro e de um número em precisão simples. A compressão de mTV , que contém 19 pesos não nulas, consome 4 × (19 + 19 + 9) = 188Bytes. As duas matrizes geradas na compressão de mTV estão representadas pela Figura 3.3. Na matriz mTVC são armazenados os pesos não nulos, na matriz mTV POS as colunas referente aos termos onde os pesos são −→ diferentes de zero e tam o número de posições não nulas de cada linha da matriz mTV .. d0 d1 d2 d mTV = 3 d4 d5 d6 d7 d8. t0 t1 t2 t3 t4 t5 t6 0.1 0.0 0.0 0.44 0.0 0.0 0.33 0.21 0.03 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.32 0.4 0.1 0.0 0.6 0.0 0.0 0.03 0.0 0.0 0.0 0.3 0.0 0.0 1.0 0.0 0.33 0.34 0.0 0.0 0.0 0.0 0.3 0.0 0.0 0.3 0.0 0.8 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.4 0.0 0.0 0.0 0.74 0.0 0.0 0.0 0.0. Figura 3.2: Matriz mTV de treinamento. Assim, o problema de armazenamento estaria resolvido e na hora de fazer o processamento é só descomprimir os vetores. Contudo, a complexidade de processamento continuaria quadrática e os usuários esperam uma resposta imediata em sistemas on-line. Para tanto, os vetores de treinamento podem ser mantidos compactos na hora de fazer um consulta, igual ao mostrado na Figura 3.3. → − → − Sendo assim, o produto mTV · d j pode ser feito da seguinte forma: seja d j (documento que → − → − desejamos classificar) um vetor descompacto, e mTV compactada. No produto interno di · d j , → − as colunas armazenadas em mTV POS indexarão em d j qual posição que deverá ocorrer um pro→ − → − duto. Por exemplo, o produto d2 · d j é feito da seguite forma: o conteúdo de mTV POSd2 ,0 = 4 indexará o produto mTVCd2 ,0 ×d j,4 na quarta posição; na próxima iteração mTV POSd2 ,1 = 5 indexará a quinta posição do produto mTVCd2 ,1 × d j,5 ; por fim, como mTV POSd2 ,2 = 6 o produto → − → − é dado por mTVCd2 ,2 × d j,6 . Assim, no produto d2 · d j são feitos 3 operações de multiplicação de ponto flutuante e não 7 se mTV estivesse descomprimida. Isto pode ser melhor compreen-.

(34) 32. d0 d1 d2 d3 mTVC = d4 d5 d6 d7 d8. 0.1 0.44 0.33 0.21 0.03 0.32 0.4 0.1 0.6 0.03 0.3 1.0 0.33 0.34 0.3 0.3 0.8 0.4 0.74. d0 d1 d2 d3 mTV POS = d4 d5 d6 d7 d8. 0 0 4 1 1 0 1 5 2. 3 6 1 5 6 4 4 6 5 3. −→ tam = 3 2 3 2 3 2 2 1 1 Figura 3.3: Matriz mTV Compactada. → − dido no produto matriz vetor mTV · d j que é mostrado no Algoritmo 3.1 (escrito na linguagem C). No Algoritmo 3.1 o f or mais externo itera nos documentos fazendo o produto interno entre → − → − d j e os di documentos de TV , sendo N = |TV |. No f or mais interno é feito o produto interno de → − → − d j (documento que desejamos classificar) por di (documento de treinamento), neste momento, −→ M recebe de tam o número de posições não nulas. A cada iteração do f or mais interno, pos recebe a posição de d j que será multiplicada, e o resultado da multiplicação é acumulado em r. Ao terminar, o resultado do produto interno é salvo no vetor resultado que será retornado. Com |TV | → − isto, a complexidade do produto mTV · d j é calculada da seguinte forma: L = ∑ tami . Como i=0. o treinamento foi armazenado de forma compacta M ≤ |V |, sendo assim L ≤ O(n2 ). Algoritmo 3.1: produto matriz vetor mTV · d j . 1. f o r ( i n t i = 0 ; i < N ; i ++) {. 2. i n t M = tam [ i ] ;. 3. float r = 0.0;. 4. i n t pos ;. 5. f o r ( i n t j = 0 ; j < M; j ++) {. 6. p o s =mTVpos [ i ] [ j ] ;. 7. r = r + d j [ p o s ] ∗mTVc [ i ] [ j ] ;.

(35) 33. 8. }. 9. r e s u l t a d o [ i ]= r ;. 10. }. Outra forma de armazenamento que é muito utilizada em Search Engine, ou máquina de busca, é o índice invertido. As principais vantagens do índice invertido são o baixo custo para a construção, manutenção, recuperação e armazenamento (BADUE et al., 2001). Índice invertido (ou arquivo invertido) é um mecanismo orientado a palavra para indexar uma coleção de documentos em ordem, para acelerar uma busca. A estrutura de índice invertido é composta de dois elementos: o vocabulário e as ocorrências. O vocabulário é o conjunto de todas as palavras diferentes na coleção. Para cada palavra há uma lista de tuplas. Cada tupla desta lista é um par hdk , wi,k i, onde dk é o documento onde o termo ti ocorre e wi,k é o peso do termo ti dentro do documento dk . A Figura 3.4 mostra um exemplo de armazenamento com índice invertido da coleção de treinamento TV representada pela matriz da Figura 3.2. t0 → hd0 , 0.1ihd1 , 0.21ihd5 , 0.34i t1 → hd1 , 0.03ihd3 , 0.6ihd4 , 0.3ihd6 , 0.3i t2 → hd8 , 0.74i t3 → hd0 , 0.44ihd6 , 0.8i t4 → hd2 , 0.32ihd3 , 0.03ihd4 , 1.0i t5 → hd2 , 0.4ihd5 , 0.3ihd7 , 0.4i t6 → hd0 , 0.33ihd2 , 0.1ihd4 , 0.33i Figura 3.4: Armazenamento da matriz mTV na forma de índices invertido. Nesta forma de armazenamento o vetor do documento d j é armazenado na memória princi→ − pal compactado, retirando os pesos nulos. A Figura 3.5 mostra a forma como d j é comprimido. → − Portanto, a latência da transmissão de d j em uma rede de sistema paralelo como um cluster é menor. −→ d j c = 0.1 0.65 0.44 0.33 −−−→ d j pos = 0 1 3 6 Figura 3.5: Vetor compactado do documento d j . → − No Algoritmo 3.2 podemos ver o produto matriz vetor mTV · d j utilizando armazenamento → − por índice invertido. O f or mais externo itera o número posições não nulas de d j , e a variável tam_d jc guarda este número. A cada iteração ele chama o f or mais interno que percorre a lista do termo a qual o f or externo está iterando. Por via de otimização de acesso a memória, o peso.

(36) 34. e o índice do termo são armazenados em variáveis. A variável peso_tk recebe o peso do termo e −−−−→ a tk o índice. A variável Q recebe de tam_tk o tamanho da lista do termo que está sendo processado, isto é, o número de iterações que o f or mais interno fará. Para facilitar a legibilidade do código, a variável aux, dentro do f or mais interno, recebe o número do documento que contém o termo tk (que está sendo processado na interação k). Esta variável indexa o vetor resultado onde são acumulados os resultados do produto interno. Algoritmo 3.2: Produto matriz vetor mTV · d j utilizando armazenamento por índice invertido. 1. f o r ( i n t k = 0 ; k < t a m _ d j c ; k ++) {. 2. i n t peso_tk = djc [ k ] ;. 3. i n t tk = djpos [ k ] ;. 4. i n t Q = tam_tk [ tk ] ;. 5. f o r ( i n t j = 0 ; j < Q ; j ++) {. 6. i n t aux = invmTV [ t k ] [ j ] . documento. 7. r e s u l t a d o [ aux ] += p e s o _ t k ∗ invmTV [ t k ] [ j ] . p e s o ; }. 8 9. }. → − Com esta forma de armazenamento a complexidade do produto matriz vetor mTV · d j é tam_d jc → − dada por ∑ tam_tk , onde tam_d jc é o número de posições não nulas de d j e tam_tk o k=0 → − tamanho da lista do termo k. Quando |V | = tam_d jc não há como compactar d j , sendo assim, o f or mais externo do Algoritmo 3.2 será todo percorrido. Com isto, todas as posições não tam_d jc. nulas de mTV serão percorridas, e portanto,. ∑ k=0. |TV |. tam_tk = ∑ tami . Logo a complexidade i=0. do armazenamento por índice invertido será a mesma do armazenamento por eliminação de posições nulas. → − Por outro lado, se tam_d jc < |V |, d j poderá ser comprimido. Desta maneira, serão feitas tam_d jc. menos iterações do f or mais externo. Então,. ∑ k=0. |TV |. tam_tk < ∑ tami , logo o número de multii=0. plicações feitas utilizando o armazenamento por índice invertido será menor do que o armazenamento por eliminação de posições não nulos. De certo modo, o armazenamento dos dados em sistemas de recuperação da informação é importante para o desempenho em termos de tempos. A forma de compressão por eliminação de posições não nulas é boa. Entretanto, a melhor forma de armazenamento estudada neste trabalho é a por índice invertido que no pior caso tem complexidade de processamento igual a do armazenamento por eliminação de zero. Assim, neste trabalho foi utilizado o armazenamento por índice invertido..

(37) 35. 3.6. Classificação de Atividade Econômicas. A classificação de companhias de acordo com as respectivas atividades exercidas é uma etapa importante do processo de obtenção de informações para a realização de análises estatísticas das atividades econômicas de uma cidade ou país. Com as companhias classificadas, é possível realizar uma análise estruturada de cada setor da economia, auxiliando empresas e governos em suas decisões (MELOTTI, 2009). Para facilitar e melhorar a qualidade de classificação das empresas de acordo com as atividades econômicas, o governo brasileiro está criando uma biblioteca digital centralizada com as declarações de propósitos de todas as empresas no país. Esta biblioteca vai ajudar as três esferas de governo – federal, os 27 Estados, e os mais de 5.000 municípios brasileiros – na tarefa de classificar as empresas de acordo com a lei Brasileira vigente (MELOTTI, 2009). A classificação oficial das atividades econômicas adotada pelos órgãos da administração federal é baseada na Classificação Nacional de Atividades Econômicas (CNAE). A CNAE foi desenvolvida tendo como referência a International Standard Industrial Classification of All Economic Activities - ISIC, 3a revisão, das Nações Unidas. A ISIC é uma padronização internacional definida pelas Nações Unidas para a disseminação das estatísticas econômicas no mundo. A partir da elaboração da CNAE foi derivada outra classificação, a CNAE-FISCAL, ou CNAE-Subclasse (CNAE, 2003b), que é um detalhamento das Classes da CNAE para uso nos cadastros da administração pública, em especial da administração tributária, nas três esferas do governo (MELOTTI, 2009). A tabela CNAE é dividida em 5 níveis: seção, divisão, grupo, classe e subclasse. A estrutura hierárquica ajuda os classificadores humanos na classificação de empresas no nível de subclasse. A codificação da tabela segue um estrutura de árvore, onde cada seção é distribuída em uma ou mais divisões (como é mostrado na Tabela 3.1), a divisão em um ou mais grupos, e assim por diante até a subclasse. A Tabela 3.2 apresenta como são distribuídos os códigos dentro da hierarquia da CNAE. A CNAE versão 1.1 no nível superior te m 17 seções, que são distribuídas em 59 divisões, que são divididas em 222 grupos, e depois em 580 classes e finalmente em 1183 subclasses (MELOTTI, 2009). Atualmente, a determinação de quais códigos devem ser atribuídos a cada empresa é feita manualmente por codificadores humanos treinados para tal e apoiados por ferramentas computacionais de busca em versões eletrônicas da tabela CNAE-Subclasse. O codificador (ou classificador) humano treinado deve associar/combinar a descrição da atividade da empresa com a informação na tabela CNAE-Subclasse e com seu conhecimento, fruto de seus vários anos de.

(38) 36. SEÇÕES A B C D E F G H I J K L M N O P Q. DENOMINAÇÃO DA SEÇÃO Agricultura, pecuária, silvicultura e exploração florestal Pesca Indústrias extrativas Indústria de transformação Produção e distribuição de eletricidade, gás e água Construção Comércio, reparação de veículos automotores, objetos pessoais e domésticos Alojamento e alimentação Transporte, armazenagem e comunicações Intermediação financeira, seguros, previdência complementar e serviços relacionados Atividades imobiliárias, aluguéis e serviços prestados às empresas Administração pública, defesa e seguridade social Educação Saúde e serviços sociais Outros serviços coletivos, sociais e pessoais Serviços domésticos Organismos internacionais e outras instituições extraterritoriais. DIVISÕES 01 a 02 05 10 a 14 15 a 37 40 a 41 45 50 a 52 55 60 a 64 65 a 67 70 a 74 75 80 85 90 a 93 95 99. Tabela 3.1: Seções e denominações da tabela. educação e experiência profissional, para atribuir códigos CNAE-Subclasse (MELOTTI, 2009). Conforme as características apresentadas anteriormente, o problema de classificação de atividades econômicas consiste em: dada uma descrição textual do propósito de uma empresa, categorizá-la em um ou mais dos 1.183 possíveis códigos (ou categorias) CNAE-Subclasse. O grande número de possíveis categorias torna este problema complexo quando comparado com outros apresentados na literatura (SEBASTIANI, 2002; MELOTTI, 2009).. 3.7. Métricas de Avaliação de Classificadores. Tipicamente, a categorização de texto é avaliada principalmente pelas métricas de Recall e Precision (BAEZA-YATES; RIBEIRO-NETO, 1999). No entanto, alguns trabalhos na literatura têm mostrado que medidas de Precision e Recall podem não ser as métricas mais adequadas para problemas que envolvem muitas classes e, também, classes raras (HAO et al.,.