Depois de feita uma análise de custo/benefício decidimos hospedar o Sistema de Classifi- cação CNAE nos servidores de Cloud Computing do Google (Google App Engine). Entretanto, o projeto do sistema foi um pouco complicado, pois no Google App Engine a aplicação só é aberta quando há uma requisição à ser tratada, ela não fica carregada na memória de um servi- dor esperando uma chamada.
Modelagem dos Dados
A princípio todas as tabelas utilizadas pelo sistema seriam colocadas no Banco de Dados (BD) do Google App Engine, o que facilitaria a implementação. Contudo, para aprender como funcionava o servidor, nós criamos um pesquisador de palavras canônicas, utilizando um di- cionário de 15.000 palavras. Hospedado no localhost o aplicativo de pesquisa funcionou sem
problemas. Quando a aplicação foi hospedada no Google App Engine, ao tentar carregar os dados do dicionário para BD do App Engine, a aplicação estourava o tempo de processamento permitido pelo Google.
Portanto, criamos um sistema de arquivos binário interligados. No arquivo dicionário cada linha contém uma tupla hpalavra, código canônicoi, onde a palavra é uma string de tamanho fixo (se uma palavra tiver um tamanho menor que a string, são impressos espaços vazios para preencher) e o código canônico é um índice (inteiro) que corresponde a forma canônica da palavra O tamanho fixo da linha é para facilitar a busca binária no dicionário.
O arquivo “canonical_table.bin” é onde estão contidas as informações sobre o índice in- vertido das palavras canônicas. Cada linha deste arquivo contém: FLOAT, LONG INT, INT, STRING que está ilustrado na Tabela 4.1. A linha 1 do arquivo contém informações sobre a palavra canônica 0, a linha 2 da palavra 1, a 100 da palavra 99 e assim sucessivamente. Suponha que minha string com o nome do arquivo tenha tamanho 8 Bytes. Então se eu quiser recuperar a informação da palavra canônica 50 o salto deve ser calculado da seguinte forma: 50 × (sizeo f ( f loat) + sizeo f (long int) + sizeo f (int) + 8 × sizeo f (char)). Depois é só fazer o salto e ler os dados da tabela.
IDF Endereço Tamanho Nome do Arquivo FLOAT LONG INT INT STRING
Tabela 4.1: Linha do Arquivo “canonical_table.bin”.
Na Tabela 4.1 o IDF representa o peso da palavra canônica na coleção. O Endereço é o tamanho do salto que deve ser dado dentro do arquivo que contém os índices invertidos. O Tamanho é para saber quantos Bytes devem ser lidos para recuperar um índice invertido de uma palavra canônica. O Nome do Arquivo é onde está contido o índice invertido referente a palavra canônica desta linha. O nome do arquivo não seria incluído no arquivo “canonical_table.bin”, entretanto, o Google App Engine só aceita carregar arquivos menores que 10MB, por este razão, foi necessário distribuir os índices invertidos em vários arquivos.
Os nomes e as classes da base de treinamento foram transformados em índices, pois isto facilitaria tanto o armazenamento quanto a recuperação da informação das classes e dos docu- mentos. Para enviar as classes dos documentos para o sistema foram criados dois arquivos. Em cada linha do arquivo “Documents_classes.bin” são armazenadas as classes referentes ao índice do documento de treinamento. As classes dos documentos de índice 0 ficam armazenadas na primeira linha do arquivo, a do documento 99 na linha 100 e assim sucessivamente para todos. Cada linha do outro arquivo contém o tamanho do salto no “Documents_classes.bin” necessário
para recuperar as classes de um documento, e o número de classes associadas ao documento de treinamento.
Com os saltos, compressão e os arquivos binários nós tentamos otimizar o armazenamento e processamento da aplicação. Toda parte de indexação da base de treino foi feita off-line nos servidores do LCAD. Os programas de codificação dos arquivos binários foram implementados na linguagem C. Porém, o indexador do treinamento foi feito em Python por causa da facilidade de manipulação de strings.
Arquitetura do Sistema de Classificação CNAE
A aplicação está on-line e pode ser acessada pela URL - http://www.cnae.net.br/. Para classificar um objeto social, o usuário acessa esta URL, que é uma página Web contendo uma caixa de texto onde o objeto social da empresa pode ser digitado. Depois de escrever o texto o usuário pressiona o botão e a solicitação de classificação é enviada ao sistema classificador que está hospedado no App Engine. Assim, o sistema recebe o texto, processa e retorna os códigos CNAE e suas descrições.
A Figura 4.2 apresenta a dinâmica do sistema de classificação hospedado no Cloud da Google. Esta dinâmica consiste em:
1. O usuário acessa a página do classificador, entra com o texto do objeto social na caixa de texto do classificador;
2. Via internet o texto é enviado ao sistema classificador que está hospedado no Google App Engine;
3. Quando o texto chega ao sistema imediatamente ele é enviado ao indexador;
(a) O texto é processado (lido) e transformado em uma lista de palavras, onde na lista contém um par: hpalavra,frequência(peso)i;
(b) Cada palavra da lista é buscada em um “arquivo dicionário” que contém hpalavra, código canônicoi;
(c) As frequências das palavras com o mesmo código canônico são somadas. Isto deve ser feito, pois algumas palavras podem ter a mesma palavra canônica. Por exemplo, o substantivo “casa” no singular tem o mesmo código canônico do plural “casas”. Então, se um texto contém as duas palavras o passo, “a” tratará como duas palavras diferentes, entretanto elas têm o mesmo significado;
4. A lista de palavras dos códigos canônicos é enviada para o classificador;
(a) Para cada código canônico da lista indexada é lido do arquivo “canonical_table.bin” uma linha que correspondente ao mesmo;
(b) O arquivo que contém o índice invertido é aberto, desta forma a lista invertida pode ser lida;
(c) São feitos os produtos;
(d) Volta ao passo “a” até que todas as palavras da lista indexada tenham sido proces- sadas;
5. Ordena a resposta do classificador e busca os códigos CNAE mais relevantes para o texto do objeto social classificado;
6. Escreve na página a resposta contendo os códigos CNAE-Subclasse e as descrições, e pela internet o usuário recebe a reposta.
Figura 4.2: Dinâmica do Sistema de Classificação no Google App Engine.
No passo 1 da dinâmica do sistema quando o usuário acessa a página Web do Classificador a função main, descrita no Algoritmo 4.1, é chamada para tratar a requisição. Na linha 2 é criada uma instância da classe ClassifierHandler que é executada pela função da linha 7.
Algoritmo 4.1: Função Main (escrita em Python) chamada quando há uma requisição à página do Classificador CNAE. 1 d e f main ( ) : 2 app = webapp . W S G I A p p l i c a t i o n ( 3 [ 4 (’ / ’, C l a s s i f i e r H a n d l e r ) , 5 ] , d e b u g = T r u e ) 6 7 w s g i r e f . h a n d l e r s . C G I H a n d l e r ( ) . r u n ( app ) 8 9 i f __name__ == ’ __main__ ’: 10 main ( )
Na classe ClassifierHandler descrita no Algoritmo 4.2 a função get da linha 2 é chamada quando o usuário acessa a página (descrito no passo 1 da dinâmica do sistema). Assim que o usuário digita um texto a ser classificado e aperta o bota classificar (passo 2 da dinâmica do sistema), o texto é enviado para a função post que tratará a requisição. Dentro da função post são chamadas as função de parser (linha 7) para indexar a query (passo 3) (objeto social a ser classificado). Em seguida a função classify (linha 10), que classificará o objeto social (passo 4). Por fim, no while (linha 12) seleciona as dez classes com maior grau de crença que será impressa no html da página que o usuário verá (passo 5).
Algoritmo 4.2: Classe ClassifierHandler.
1 c l a s s C l a s s i f i e r H a n d l e r ( webapp . R e q u e s t H a n d l e r ) : 2 d e f g e t ( s e l f ) : 3 s e l f . r e s p o n s e . o u t . w r i t e ( t e m p l a t e . r e n d e r (’ C l a s s i f i e r . h t m l ’, {’ d e s c r i p t i o n s ’: [ ] } ) ) 4 d e f p o s t ( s e l f ) :# t r a t a a r e q u i s i c a o de c l a s s i f i c a c a o 5 q u e r y = s e l f . r e q u e s t . g e t (’ q u e r y ’) 6 # i n d e x a d o r da q u e r y 7 p a i r s = p a r s e r ( q u e r y , s i z e o f _ d i c t i o n a r y , s i z e o f _ l i n e _ d i c t i o n a r y _ f i l e , maxWordSize ) 8 i f l e n ( p a i r s ) ! = 0 : 9 # c l a s s i f i c a d o r 10 c l a s s e s = c l a s s i f y ( p a i r s , sigma , t r a i n _ s i z e , n u m _ c l a s s e s , s i z e o f _ l i n e _ c a n o n i c a l _ f i l e ) 11 . . . 12 w h i l e i < 1 0 : 13 # P e g a a s 10 p r i m e i r a c l a s s e s que s e r a r e t o r n a d a ao u s u a r i o 14 d e s c r i p t i o n s . a p p e n d ( p a i r ( c a t e g o r y [ 0 : 4 ] + "−" + c a t e g o r y [ 4 ] + " / " + c a t e g o r y [ 5 : 7 ] , d e s c r i p t i o n ) )
15 i = i + 1
16 . . .
17 e l s e:
18 s e l f . r e s p o n s e . o u t . w r i t e ( t e m p l a t e . r e n d e r (’ C l a s s i f i e r . h t m l ’ , {’
d e s c r i p t i o n s ’: [ p a i r ("−1", " Not Found ! ") ] } ) )
No processo de indexação representada pelo Algoritmo 4.3(descrito no passo 3), no primeiro for (linha 2) o texto da query será processado, desta forma, uma lista com a frequência das palavras que ocorrem na query será gerada (isto é descrito no passo 3a). No for (linha 8) seguinte as palavras indexadas são buscadas no dicionário de palavras canônicas (passo 3b), e a frequência das palavras que contêm o mesmo código canônico serão somadas (passo 3c).
Algoritmo 4.3: Função do Indexador.
1 d e f p a r s e r ( q u e r y , s i z e o f _ d i c t i o n a r y , s i z e o f _ l i n e _ d i c t i o n a r y _ f i l e , maxWordSize ) : 2 f o r word i n q u e r y : # c a l c u l a f r e q u e n c i a d a s p a l a v r a s 3 i f p a i r s . h a s _ k e y ( word ) : 4 p a i r s [ word ] = p a i r s [ word ] + 1 5 e l s e: 6 p a i r s [ word ] = 1 7 c a n o n i c a l _ l i s t = d i c t ( ) 8 f o r word , f r e q i n p a i r s . i t e m s ( ) :# p e s q u i s a a s p a l a v r a s c a n o n i c a s no d i c i o n a r i o 9 c a n o n i c a l _ w o r d = b i n s e a r c h ( f i n , word , s i z e o f _ d i c t i o n a r y , s i z e o f _ l i n e _ d i c t i o n a r y _ f i l e , maxWordSize ) 10 i f c a n o n i c a l _ w o r d > 0 : 11 i f c a n o n i c a l _ l i s t . h a s _ k e y ( c a n o n i c a l _ w o r d ) : 12 c a n o n i c a l _ l i s t [ c a n o n i c a l _ w o r d ] = c a n o n i c a l _ l i s t [ c a n o n i c a l _ w o r d ] + f r e q 13 e l s e: 14 c a n o n i c a l _ l i s t [ c a n o n i c a l _ w o r d ] = f r e q 15 c a n o n i c a l _ l i s t . s o r t ( ) 16 r e t u r n c a n o n i c a l _ l i s t _ r e s u l t
O Algoritmo PNN, descrito na Seção 3.4, está representado na pelo Algoritmo 4.4. No primeiro for deste algoritmo será feito o produto matriz vetor da algoritmo PNN (os detalhes deste produto é descrito na Seção 3.5). O resultado do produto matriz vetor da (linha 4) é armazenado em na variável documents. No segundo for são calculados o valor da função de ativação da Equação 3.4, está operação é feita na linha 10. Na while da linha 14, é feita o calculo da camada de soma, representada pela Equação 3.5. Todos os passos do algoritmo de classificação são descritos nos passos 4a, 4b e 4c da dinâmica do Sistema de Classificação
CNAE.
Algoritmo 4.4: Função da Rede Neural WNN.
1 d e f c l a s s i f y ( c a n o n i c a l _ l i s t , sigma , num_docs , n u m _ c l a s s e s , o f f s e t ) : 2 . . . 3 # p a r a c a d a p a l a v r a da q u e r y m u l t i p l i c a o p e s o p e l a l i s t a i n v e r t i d a c o r r e p o n d e n t e no t r e i n a m e n t o 4 f o r x i n c a n o n i c a l _ l i s t : 5 # l e o i d f do a r q u i v o 6 normaQuery = normaQuery + x [ 1 ] ∗ i d f ∗∗ 2 7 d o c u m e n t s = p r o d u c t ( i n v e d t e d _ l i s t , s i z e , jump , x [ 1 ] ∗ i d f , d o c u m e n t s ) 8 normaQuery = normaQuery ∗∗ 0 . 5 9 f o r doc , i n n e r P r o d u c t i n d o c u m e n t s . i t e m s ( ) : 10 A= ( ( 2 ∗ P I ∗ s i g m a ) ∗∗ −1) ∗ exp ( ( i n n e r P r o d u c t / normaQuery − 1 ) / s i g m a ∗ ∗ 2 ) 11 tam = i n t ( s i z e 2 [ doc ] ) 12 j =0 13 H= d a t a [ doc ] . r s p l i t (’ ’) 14 w h i l e j < tam : 15 c = i n t (H[ j ] ) 16 c a t e g o r i e s [ c ] [ 0 ] = c a t e g o r i e s [ c ] [ 0 ] + A 17 j = j + 1 18 c a t e g o r i e s . s o r t ( r e v e r s e = T r u e ) 19 r e t u r n c a t e g o r i e s
Interface de Sistema do Classificação CNAE
Quando uma pessoa está criando uma empresa e deseja consultar em quais códigos CNAE a mesma será classificada, ela pode acessar a página do Classificador de texto de objetos sociais via Browser, e uma interface como a que está representada pela Figura 4.3 será aberta. O usuário digita na caixa de texto “Descrição das Atividades” o texto que descreverá as atividades econômicas da empresa.
Por fim, ela deve clicar no botão “Classificar” e o texto será enviado ao servidor do Google App Engine, onde o Sistema de Classificação CNAE está hospedado. O sistema classificador recebe o objeto social a ser classificado. Ele indexa, classifica e retorna ao usuário os 10 códigos mais relevantes. O retorno é escrito na forma de uma tabela. A interface de retorno é mostrada na Figura 4.4. Na tabela onde é escrita a resposta de classificação a primeira coluna corresponde aos códigos CNAE-Subclasse 1.1, a segunda corresponde as descrições do código da primeira coluna.
Figura 4.3: Interface do Sistema de Classificação CNAE.
5
Experimentos
Neste Capítulo descreveremos as bases de dados empregados neste trabalho para a avali- ação dos classificadores. Discutiremos os resultados de classificação, dentro das métricas de avaliação de classificação multi-rotulada. Desta maneira, decidiremos qual classificador será hospedado no servidor de Cloud Computing do Google, e qual a base de dados utilizada para treinar tal classificador. Outras avaliações importante são a medida de desempenho em termos de tempo dos classificadores, a escalabilidade do servidor e o consumo de quotas do Google App Engine.
5.1
Descrição das Bases de Dados
O conjunto de dados empregado em nossa avaliação experimental é composto de descrições textuais de atividades econômicas de empresas brasileiras. Todas essas descrições foram man- ualmente classificadas em uma ou mais atividades econômicas por funcionários públicos brasileiros treinados nesta tarefa. A leis do país determina que todas as empresas devem apresentar uma descrição textual das suas atividades econômicas para órgãos do governo para que elas sejam classificadas de acordo com a tabela oficial de atividades econômicas, Tabela CNAE-Subclasse (CNAE, 2003b).
Neste trabalho, contamos com descrições de atividades econômicas de empresas das cidades de Vitória – Espírito Santo e Belo Horizonte – Minas Gerais. A base de dados de Vitória, chamada de VIX, possui 3.281 documentos referentes a empresas da localidade classificados em 764 diferentes classes CNAE-Subclasse. O número médio de classes por documento é 4,3 (desvio padrão de 5,6 ) (MELOTTI, 2009).
A Figura 5.1 apresenta o histograma do número de documentos com um determinado número de classes. No gráfico da Figura 3.2, o eixo x representa o número de classes por documento e o eixo y o número de documentos. De 1 a 35 classes por documento, as barras do gráfico indicam exatamente o número de documentos com o respectivo número de classes. De
36 classes por documento em diante, só aparecem no eixo x do gráfico os números de classes por documento para os quais há documentos na base VIX (MELOTTI, 2009).
Figura 5.1: Distribuição do número de classes por documento na base de dados VIX.
O número de classes por documento varia de 1 a 109 , sendo que mais de 800 documentos possuem apenas uma classe e apenas um documento possui 109 classes. Como a Figura 5.1 mostra, a maior parte dos documentos da base VIX possui de 1 a 7 classes por documento (87, 53%) (MELOTTI, 2009).
A base de dados de Belo Horizonte, chamada BH, possui 88.000 documentos classificados em 1.002 diferentes classes CNAE-Subclasse. O número médio de classes por documento é 2,0 (desvio padrão de 1,7 ). A Figura 5.2 apresenta o histograma da base BH (MELOTTI, 2009).
Figura 5.2: Distribuição do número de classes por documento na base de dados BH.
50.000 documentos possuem apenas uma classe e apenas um documento possui 27 classes. Como a Figura 5.2 mostra, a maior parte dos documentos da base BH possui entre 1 e 3 classes (MELOTTI, 2009).
A partir das bases VIX e BH, geramos duas bases de dados que utilizamos para treinar, val- idar e testar. A primeira base gerada, chamada de EX100 (EXatamente 100), possui exatamente 100 exemplares de documentos de cada classe. Ela é composta de 6.911 documentos seleciona- dos aleatoriamente da união de VIX e BH; 105 classes diferentes ocorrem na base EX100, isto é, existem exatamente 100 documentos na base classificados dentro de cada uma destas 105 classes. O número médio de classes por documento é 1,52 (desvio padrão de 0,79). A Figura 3.4 apresenta o histograma da base EX100. Conforme a figura mostra, o número de classes por documento varia de 1 a 6 , sendo que mais de 4.000 documentos possuem apenas uma classe e 9 documentos possuem 6 classes. A maior parte dos documentos desta base possui entre 1 e 2 classes (89, 22%) (MELOTTI, 2009).
Figura 5.3: Distribuição do número de classes por documento na base de dados EX100.
Na segunda base gerada, chamada de AT100 (ATé 100), cada categoria ocorre em até 100 diferentes documentos, isto é, existem entre 1 e 100 exemplares de documentos de cada classe. Ela é composta de 10.495 documentos selecionados aleatoriamente da união de VIX e BH; 692 classes diferentes ocorrem na base AT100. O número médio de classes por documento é 1,49 (desvio padrão de 0,86) (MELOTTI, 2009).
A Figura 5.4 apresenta o histograma da base AT100. Conforme a figura mostra, o número de classes por documento varia de 1 a 12, sendo que mais de 7.000 documentos possuem apenas uma classe e um documento possui 12 classes. A maior parte dos documentos desta base possui entre 1 e 2 classes (MELOTTI, 2009).
Figura 5.4: Distribuição do número de classes por documento na base de dados AT100.
Além das bases EX100 e AT100, utilizamos a própria tabela CNAE-Subclasse, para treinar os classificadores. A tabela CNAE-Subclasse possui 1183 Subclasses. Cada uma destas Sub- classes possui um pequeno texto com sua denominação. Este texto foi utilizado, juntamente com o código CNAE correspondente, como documento de treinamento. Outra informação mais detalhada dos códigos CNAE-Subclasse, chamada de “Compreende”, foi utilizada no treina- mento dos classificadores (MELOTTI, 2009).
5.2
Qualidade da Classificação
Em todos os experimentos para teste de precisão dos algoritmos foi aplicada a abordagem de k Fold Cross Validation (em Português, Validação Cruzada). Neste procedimento a base de dados é dividida aleatoriamente em k conjuntos, sendo que um documento de um conjunto não pode estar em outro. Destes k conjuntos separa-se um conjunto para testar e os outros k − 1 para treinar. Depois, é feito uma troca, no qual o conjunto que estava sendo testado no fold anterior será utilizado para treinar o próximo passo da abordagem. Por exemplo, quando o teste do algoritmo por validação cruzada é iniciado, o fold 0 é selecionado para ser o conjunto T E, assim que o teste terminar, o fold 0 é adicionado ao conjunto TV e o fold 1 é retido de TV e ele passará a ser o conjunto T E. Isto é feito até passar pelos k conjuntos, completando o ciclo da validação cruzada (WITTEN; FRANK, 2005). Neste trabalho foi utilizado k = 10.
Para avaliar os algoritmos, ao final de cada fold são calculados resultados de classificação, aplicando as funções das métricas. Quando o ciclo da validação cruzada é completado, são reti- radas as médias dos resultados de cada métrica. Assim, há uma maior confiança nos resultados
da classificação e podemos avaliar com maior clareza a precisão dos algoritmos.
Todos os experimentos para teste de precisão dos algoritmos estudados neste trabalho foram feitos localmente (em máquinas do LCAD). Ou seja, a implementação dos algoritmos que estão rodando no Google App Engine foram alteradas de forma que funcionam via linha de comando. Para tanto, foram implementados programas na linguagem C para a preparação das bases de dados e calcular as métricas de avaliação dos classificadores. Na divisão dos k folds, o indexador e alguns scripts para tratamento de strings foram todos implementados em Python.
Para decidirmos qual algoritmo e base de dados treinaria o Sistema de Classificação, ambas as bases de dados EX100 e AT100 foram divididas em 10 folds. Deste modo, foram rodados os experimentos de validação cruzada para verificar a precisão dos algoritmos. Contudo, as bases de dados que temos para treinar os algoritmos são pequenas, com a EX100 representando 105 classes e AT100 692 classes. Sendo assim, o Sistema de Classificação CNAE só classificaria em um conjunto menor de classes do que o número real (1183) que ele precisaria classificar.
Para resolver este problema, nós utilizamos as descrições dos códigos CNAE-Subclasse juntamente com a descrição mais detalha dos códigos, chamado aqui de “Compreende”. Diante disso, os experimentos foram feitos da seguinte forma: primeiro o conjunto TV de treinamento dos folds foi composto somente por 90% e T E de teste por 10%. No segundo experimento, além dos 90% nós adicionamos ao conjunto de treino a descrição dos códigos CNAE e o “Com- preende”. Foi feito desta maneira para verificar se há uma melhora nos resultados de classifi- cação.
As Tabelas 5.1, 5.2, 5.3 e 5.4 mostram os resultados numérico de classificação para as métricas One Error, Average Precision, Coverage, Hamming Loss e Ranking Loss. A Seção 3.7 apresenta uma descrição detalhada das métricas. Nestas Tabelas são reportados os resulta- dos utilizando o treinamento com “Compreende” e sem “Compreende”, a segunda coluna das Tabelas corresponde ao treinamento com “Compreende”, e a terceira sem “Compreende”. As Tabelas 5.1 e 5.2 trazem os resultados de classificação das bases de dados EX100 e AT100, respectivamente, classificadas pelo algoritmo PNN. Por sua vez, As Tabelas 5.3 e 5.4 exibem os resultados para as base de dados EX100 e AT100, classificadas pelo algoritmo kNN.
As Figuras 5.5, 5.9, 5.7, 5.6 e 5.8 são as representações gráficas das Tabelas 5.1, 5.2, 5.3 e 5.4. Em todas Figuras, os Gráficos (a)s apresentam os resultados de classificação da base de dados EX100, com “Compreende” e sem “Compreende”. Da mesma forma, os Gráficos (b)s apresentam os resultados para AT100. O eixo x dos gráficos representam os algoritmos kNN e PNN, e o eixo y o resultado numérico das métricas de avaliação dos classificadores. Nos Gráficos (a)s a cor vermelha representa o treinamento incluindo a base de “Compreende”, a
EX100 com Compreende EX100 sem Compreende One Error 0,236001 0,236145 Hamming Loss 0,000710 0,008014 Coverage 3,203770 4,796171 Ranking Loss 0,005151 0,026764 Average Precision 0,810558 0,810250
Tabela 5.1: Resultado de classificação da base de dados EX100 feita pelo algoritmo PNN.
AT100 com Compreende AT100 sem Compreende One Error 0,391192 0,396244
Hamming Loss 0,001061 0,001832 Coverage 29,869699 32,138704 Ranking Loss 0,0241499 0,043636 Average Precision 0,653808 0,647783
Tabela 5.2: Resultado de classificação da base de dados AT100 feita pelo algoritmo PNN.
verde representa o treinamento sem a inclusão da base de “Compreende”. Já nos Gráficos (b)s a cor azul representa o treinamento incluindo a base de “Compreende”, e a amarela representa o treinamento sem a inclusão da mesma.
Na avaliação das métricas quando a base de dados de treinamento não inclui o “Com- preende” , os resultados são avaliados com a quantidade de classes que as bases de dados rep- resentam, no caso da EX100 105 classes, e na AT100 692 classes. Por outro lado se a base de treinamento inclui o “Compreende” a análise passa a ser feita com todas as classes da tabela CNAE. Para métricas que avaliam o ranking como um todo, por exemplo Coverage e Average Precision, ao avaliarmos de acordo com todas as classes CNAE o desempenho pode cair, por causa do número de empates no ranking.
A Figura 5.5 exibe os resultados da métrica One Error para as bases de dados EX100 e AT100. A métrica One Error avalia o topo do ranking, verificando se a classe do topo está na lista de classes associadas ao documento classificado. Para esta métrica, quanto menor o valor, melhor. Nos Gráficos 5.5(a) e 5.5(b) as duas primeira barras correspondem aos resultados para o algoritmo kNN, e as outras duas seguintes para PNN. O eixo y mostra numericamente os resultados para a métrica One Error.
O Gráfico 5.5(a) mostra que para ambos classificadores não há diferença quando o treina- mento é feito incluindo ou não o “Compreende”. Todavia, se olharmos a linha correspondente ao One Error nas Tabelas 5.1 e 5.3, percebemos que nesta métrica há uma melhora, porém, pequena. No Gráfico 5.5(b) esta diferença é mais perceptível. Os resultados numéricos estão
EX100 com Compreende EX100 sem Compreende One Error 0,342932 0,341196 Hamming Loss 0,000947 0,010681 Coverage 6,200637 3,924690 Ranking Loss 0,024150 0,043636 Average Precision 0,737751 0,738976
Tabela 5.3: Resultado de classificação da base de dados EX100 feita pelo algoritmo kNN.
AT100 com Compreende AT100 sem Compreende One Error 0,466305 0,477649
Hamming Loss 0,001223 0,002121 Coverage 23,718750 25,687139 Ranking Loss 0,019530 0,035703 Average Precision 0,621728 0,612492
Tabela 5.4: Resultado de classificação da base de dados AT100 feita pelo algoritmo kNN.
representados nas Tabelas 5.2 e 5.4.
Avaliando os classificadores no Gráfico 5.5(a) podemos perceber que para classificar a base de dados EX100, o algoritmo de classificação PNN foi melhor do que o kNN nesta métrica. Isto ocorre também no Gráfico 5.5(b).
Os resultados da métrica Hamming Loss são mostrados na Figura 5.6. O eixo y representa o resultado para a métrica Hamming Loss. Para esta métrica quanto menor o resultado melhor. Nos Gráficos 5.6(a) e 5.6(b) há melhora dos resultados, para ambos os algoritmos, quando o