Motor de Pesquisa Avançada com Inteligência Artificial

(1)

Faculdade de Engenharia da Universidade do Porto

Motor de Pesquisa Avan¸cada com Inteligˆencia

Artificial

Nuno Diogo Gon¸calves Martins

Disserta¸c˜ao de Mestrado

Mestrado Integrado de Engenharia Eletrotécnica e de Computadores Major em Telecomunica¸cões, Eletrónica e Computadores

Orientador: Andr´e Monteiro de Oliveira Restivo Supervisor Externo: Telma Salgueiro

(2)

(3)

Resumo

Na época em que vivemos é cada vez mais comum o abandono dos t´ıpicos formatos f´ısicos, como o papel, em prol do formato digital. Através de solu¸cões informáticas existentes no mercado é poss´ıvel às empresas organizarem e gerirem os seus arquivos documentais de uma forma fácil e eficiente. Uma dessas solu¸cão é o iPortalDoc, um Sistema de Gestão Documental e de workflows desenvolvido pela IPBRICK, que vem permitir a desmaterializa¸cão de toda a informa¸cão das empresas e facilitar a sua gestão e o acesso por parte dos colaboradores.

No entanto, o iPortalDoc apresenta uma grande lacuna, que é o seu motor de pes-quisa. Este motor é ineficiente, apresentando tempos de resposta muito elevados que levam a perdas de tempo dos colaboradores, o que se pode refletir numa quebra de produtividade da empresa. Quando os resultados das pesquisas são finalmente apresentados verifica-se que, muitas vezes, estes são insatisfatórios, apresentando documentos que pouco ou nada têm a ver com o que o utilizador procura no topo da lista. Surge então a necessidade de renovar o motor de pesquisa do iPortalDoc, com o objetivo de melhorar o seu desempenho, colmatando então a principal falha do iPortalDoc.

A solu¸cão encontrada passou então por delegar a pesquisa de texto, que era respon-sabilidade do sistema de gestão de bases de dados, para uma ferramenta dedicada, o Apache Solr. Para complementar esta mudan¸ca foi também desenvolvido um módulo de classifica¸cão de documentos que aprende com as pesquisas dos utilizadores. O conhecimento retirado das pesquisas é então usado para prever a categoria do do-cumento que o utilizador procura, e promover então os documentos dessa categoria para o topo de lista de resultados.

Através da solu¸cão encontrada foi poss´ıvel reduzir drasticamente o tempo de res-posta do motor de pesquisa e ao mesmo tempo melhorar a qualidade dos resultados, aumentando-se o número de campos em que é feita a pesquisa e promovendo os re-sultados que possivelmente são mais relevantes para o utilizador. Além disso, com o uso do Solr, tornou-se o iPortalDoc mais future proof, deixando-o melhor preparado para escalar junto com o aumento do volume de informa¸cão que armazena.

(4)

(5)

Abstract

In the times we live in, it is getting more and more usual to store information in digital format, instead of the more traditional physical formats, like paper. Through the use of software solutions existent in the market, it is possible for companies to organize and manage their document archives in an easy and efficient way. One of those solutions is iPortalDoc, a Document and Process Management tool which allows the dematerialization of all the companies information and makes it easy to manage and access that information remotely.

However, iPortalDoc suffers from a flawed search engine. The engine is very ineffi-cient, showing extremely high response times that lead to a waste of collaborators time, which could potentially reflect itself in a drop of productivity. Also, when search results are finally presented to the user, most of the times they are not sa-tisfactory, with high ranking documents that have little to do with what the user is after. Because of this, the need arose to renew iPortalDoc’s search engine, with the objective of improving its performance, thus fixing its main flaw.

The solution found for this problem, was to migrate text search tasks, formerly done by the database management system, to a new dedicated Apache Solr server. To complement this change, a document classifier was also developed to learn from users searches and use the acquired knowledge to predict the category of the document the user is searching for, and boost documents belonging to that category to the top of the list.

Through this solution, we managed to drastically reduce the search engine’s response time and at the same time improve result precision, by searching in fields beside the document’s title and boosting the most likely relevant results to the top. Besides that, through the use of Solr, iPortalDoc has become more future proof, as it’s now better prepared to scale accordingly to the growth of volume of documents it manages.

(6)

(7)

Agradecimentos

Com a conclus˜ao desta disserta¸c˜ao, chega ao fim o meu percurso na grande Facul-dade de Engenharia da UniversiFacul-dade do Porto, sendo que reservo este espa¸co para agradecer a quem me apoiou nesta pequena longa viagem:

Aos meus pais, Isabel e Jorge, em primeiro lugar por sempre me terem apoiado na persegui¸cão dos meus sonhos. Em segundo lugar, por me terem dado for¸ca sempre que precisei e por demonstrarem um enorme orgulho em terem formado um engenheiro, sendo que deles vieram as maiores li¸cões: as de trabalho, esfor¸co, dedica¸cão e paixão por aquilo que fazemos. Só dessa forma é poss´ıvel sermos bem sucedidos.

`

A minha irmã, por puxar por mim e me incentivar a continuar a trabalhar quando a vontade era pouca e também por de certa forma o seu sucesso escolar me ter dado alento para estudar, só para ela não dizer que é mais inteligente que eu.

`

A minha namorada Patr´ıcia, por me aturar e compreender nos momentos mais dif´ıceis deste curso. Acompanhou-me desde o inicio desta viagem (que rapariga n˜ao quer namorar com um engenheiro?) e foi sempre um grande pilar que sempre me apoiou e deu motiva¸c˜ao, e que esteve sempre presente para me ouvir.

Aos meus colegas de curso, em especial o Jo˜ao Meira e a Sara Sousa, com os quais passei momentos que recordarei com saudade e com os quais fiz amizades que ficar˜ao para sempre.

Ao meu orientador, André Restivo, pelos conselhos que me deu durante a realiza¸cão desta disserta¸cão. Foi um professor que me marcou neste percurso pela forma como ensina, deixando transparecer para os alunos um gosto enorme pelo que faz. Além disso pelas nossas conversas e piadas durante as aulas e reuniões.

`

A IPBRICK, em especial à Eng.ª Telma, que me deu a oportunidade de realizar esta disserta¸cão, que me enriqueceu pessoal e profissionalmente. Também a toda a equipa pelo bom ambiente em que vivi durante este per´ıodo e pela disponibilidade que demonstraram ao ajudar sempre que foi necessário.

A toda a minha fam´ılia e amigos sempre me apoiaram e estiveram presentes nos momentos mais importantes.

(8)

(9)

”Do, or do not. There is no try.” Yoda

(10)

(11)

Conte´

udo

1 Introdu¸c˜ao 1 1.1 Motiva¸c˜ao . . . 1 1.2 Objetivos . . . 2 1.3 Metodologia . . . 2 1.4 A Empresa . . . 3 1.5 Estrutura do Documento . . . 3

2 Revisão Bibliográfica 5 2.1 Recupera¸cão de Informa¸cão . . . 5

2.1.1 Introdu¸cão à Recupera¸cão de Informa¸cão . . . 6

2.1.2 O Utilizador . . . 7

2.1.3 Os Documentos . . . 8

2.1.4 O Processo de Recupera¸c˜ao de Informa¸c˜ao . . . 9

2.1.5 Métricas de Avalia¸cão . . . 10 2.2 Técnicas . . . 12 2.2.1 Modelo Booleano . . . 12 2.2.2 Modelo Vetorial . . . 13 2.2.3 Modelos Probabil´ısticos . . . 14 2.3 Indexa¸cão . . . 17 2.3.1 Heap Files . . . 17 2.3.2 Índices . . . 19 2.4 Pesquisa no PostgreSQL . . . 22

(12)

Conte´udo

2.4.1 LIKE/ILIKE . . . 22

2.4.2 Full Text Search . . . 23

2.5 Ferramentas de Pesquisa . . . 25 2.5.1 Sphinx . . . 25 2.5.2 Apache Lucene . . . 25 2.5.3 Apache Solr . . . 25 2.5.4 Elasticsearch . . . 26 2.6 Aprendizagem Computacional . . . 26

2.6.1 Introdu¸c˜ao `a Aprendizagem Computacional . . . 27

2.6.2 Classifica¸c˜ao de Texto . . . 29

2.7 Algoritmos . . . 29

2.7.1 Naive Bayes . . . 29

2.7.2 k-Nearest Neighbours . . . 31

2.7.3 Support Vector Machine . . . 31

2.8 Bibliotecas de IA . . . 33 2.8.1 PyBrain . . . 33 2.8.2 TensorFlow . . . 33 2.8.3 scikit-learn . . . 34 3 Caracteriza¸c˜ao do Problema 35 3.1 Defini¸c˜ao do Problema . . . 35 3.2 Testes realizados . . . 35 3.2.1 Tempo de Resposta . . . 36

3.2.2 Qualidade dos Resultados . . . 39

3.3 Escalabilidade da Solu¸c˜ao Atual . . . 39

3.4 Objetivos . . . 41

4 Solu¸c˜ao Proposta 43 4.1 Testes de Performance . . . 43

(13)

Conteúdo 4.1.2 Updates . . . 45 4.1.3 Conclusões . . . 46 4.2 Módulo de Aprendizagem . . . 47 4.3 Arquitetura . . . 49 4.4 Implementa¸cão . . . 50 4.4.1 Estrutura de Dados . . . 50 4.4.2 Fluxo de Execu¸cão . . . 55 5 Valida¸cão da Solu¸cão 63 5.1 Tempo de Resposta . . . 63

5.2 Qualidade dos Resultados . . . 64

5.3 Previs˜ao . . . 64

6 Considera¸c˜oes Finais 69 6.1 Evolu¸c˜ao . . . 70

(14)

(15)

Lista de Figuras

2.1 Intera¸cões do utilizador com o sistema de recupera¸cão de informa¸cão 8

2.2 Processo de indexa¸c˜ao de documentos . . . 9

2.3 Processo de recupera¸c˜ao de informa¸c˜ao . . . 10

2.4 Ilustra¸c˜ao das m´etricas precision e recall . . . 11

2.5 Organiza¸c˜ao de ficheiro heap em lista ligada . . . 18

2.6 Organiza¸cão de ficheiro heap em diretório de páginas . . . 19

2.7 ´Indice em hash no campo idade . . . 20

2.8 ´Indice em ´arvore no campo idade . . . 21

2.9 Arquitetura t´ıpica de um sistema de aprendizagem computacional . . 28

3.1 Opera¸c˜ao mais demorada da pesquisa com ILIKE . . . 37

3.2 Opera¸c˜ao mais demorada da pesquisa com to_tsquery() . . . 38

4.1 Tempos de execu¸c˜ao (ms) de query sem cache . . . 44

4.2 Tempos de execu¸c˜ao (ms) de query com cache . . . 45

4.3 Tempos de processamento (ms) de updates . . . 46

4.4 Arquitetura da solu¸c˜ao proposta . . . 49

4.5 Excerto do modelo relacional do iPortalDoc . . . 50

(16)

(17)

Lista de Tabelas

2.1 Matriz termo-documento para pesquisa booleana . . . 12

2.2 Estrutura (simplificada) de um ´ındice invertido . . . 22

2.3 Exemplos de uso do operador LIKE . . . 23

3.1 Termos mais pesquisados . . . 36

3.2 Tempos de resposta para os termos mais pesquisados (ILIKE) . . . . 36

3.3 Tempos de resposta para os termos mais pesquisados (full text search) 38 3.4 Primeiros 25 resultados da pesquisa ’manual iportaldoc’ . . . 40

4.1 Tempos m´edios de resposta (sem cache) . . . 44

4.2 Tempos m´edios de resposta (com cache) . . . 45

4.3 Tempos m´edios de processamento de updates . . . 46

5.1 Tempos de resposta a solu¸c˜ao implementada . . . 63

5.2 M´edias do tempo de resposta das diferentes solu¸c˜oes . . . 64

5.3 Primeiros 25 resultados da pesquisa ’manual iportaldoc’ com a solu¸c˜ao encontrada . . . 65

5.4 Pesquisa por ’manual iportaldoc’ sem IA . . . 66

5.5 Pesquisa por ’manual iportaldoc’ com IA . . . 66

5.6 Primeira pesquisa por ’teste’ com IA . . . 67

(18)

(19)

Lista de Listagens

1 Excerto do componente de treino . . . 48

2 Excerto do componente de classifica¸c˜ao . . . 49

3 Primeira itera¸c˜ao da estrutura de dados do Solr . . . 51

4 Segunda itera¸c˜ao da estrutura de dados do Solr . . . 52

5 Ultima itera¸c˜´ ao da estrutura de dados do Solr . . . 53

6 Estrutura de dados final . . . 54

7 Configura¸c˜oes da periodicidade dos commits . . . 55

8 Configura¸c˜oes da cache de resultados de queries . . . 55

9 Configura¸c˜ao da janela de resultados das queries . . . 55

10 Verifica¸c˜ao do funcionamento do Solr no caso de queries ao ´ındice . . 57

11 Constru¸c˜ao das queries . . . 58

12 Ciclo de recupera¸c˜ao de documentos . . . 59

13 Ordena¸cão e configura¸cão do próximo documento a recuperar . . . 60 14 Verifica¸cão do funcionamento do Solr no caso de modifica¸cão do ´ındice 61

(20)

(21)

Abreviaturas e S´ımbolos

AJAX Asynchronous JavaScript And XML BD Base de Dados

CSS Cascading Style Sheets HTML HyperText Markup Language IA Inteligˆencia Artificial

JS JavaScript

JSON JavaScript Object Notation PHP PHP: Hypertext Preprocessor RI Recupera¸c˜ao de Informa¸c˜ao

SGBD Sistema de Gest˜ao de Bases de Dados

SMART System for the Mechanical Analysis and Retrieval of Text SQL Structured Query Language

TREC Text Retrieval Conference WWW World Wide Web

(22)

(23)

Cap´ıtulo 1

Introdu¸

c˜

ao

Nos dias que correm é cada vez maior o fluxo de informa¸cão com que as empresas lidam diariamente. Esta informa¸cão pode existir nas mais diversas formas, sejam fa-turas, propostas, manuais, ou até correspondência trocada dentro e fora da empresa, como emails ou até chamadas telefónicas.

O crescente volume da informa¸cão e a forma como está dispersa pelos vários depar-tamentos das organiza¸cões tornam a sua gestão complexa e demorada. Além disso, hoje em dia espera-se que a informa¸cão esteja facilmente acess´ıvel e que seja simples a sua partilha, possibilitando colabora¸cão à distância [1].

Estas questões exigem uma solu¸cão que permita a desmaterializa¸cão da informa¸cão e o seu arquivamento central, assim como o seu acesso remoto e autenticado. Apro-veitando esta lacuna de mercado a IPBRICK lan¸cou o iPortalDoc, um Sistema de Gestão Documental e Workflows.

Esta ferramenta permite às empresas aumentar a produtividade dos seus funcionários, não só porque estes gastam menos tempo na gestão da documenta¸cão, mas também porque possibilita um maior controlo das várias fases dos processos que a docu-menta¸cão percorre dentro da organiza¸cão.

1.1 Motiva¸

c˜

ao

Como foi descrito anteriormente, o iPortalDoc permite a gestão centralizada de toda a documenta¸cão e comunica¸cões das empresas, tornando o acesso a essa informa¸cão mais simples e independente da localiza¸cão dos colaboradores.

´

E importante, com a crescente quantidade de informa¸c˜ao, os utilizadores do iPor-talDoc conseguirem aceder aos documentos de uma forma expedita. Para isso, o iPortalDoc disponibiliza duas op¸c˜oes de pesquisa, simples e avan¸cada. A pesquisa simples procura todos os documentos que contenham o texto inserido e retorna todos os resultados poss´ıveis. Com o enorme volume de documentos na base de dados, este tipo de pesquisa acaba por ser pouco eficiente, apresentando os resultados com um

(24)

1.2. Objetivos

tempo de resposta inaceitável que acaba por fazer perder tempo dos colaboradores e assim reduzir a produtividade da empresa. Além disso, muitos dos resultados devol-vidos são irrelevantes para a pesquisa do utilizador, estando os resultados realmente importantes perdidos no meio destes.

A pesquisa pode ser feita de uma forma mais refinada, através do uso de códigos (que retornam um documento espec´ıfico) ou através de filtros. Embora este tipo de pesquisa seja mais exata, implica um esfor¸co adicional por parte do utilizador que se quer evitar, melhorando assim a facilidade de utiliza¸cão da aplica¸cão.

1.2 Objetivos

Os objetivos deste projeto passam por em primeiro lugar melhorar o tempo de resposta do motor de pesquisa do iPortalDoc de forma a que os utilizadores percam o m´ınimo de tempo poss´ıvel na procura dos documentos que necessitam para realizar o seu trabalho.

Numa segunda fase deverá ser integrado no iPortalDoc um módulo com capacidade de aprendizagem, utilizando uma técnica baseada em aprendizagem computacional, para melhorar a qualidade dos resultados que são apresentados ao utilizador. Este módulo deverá, com cada pesquisa realizada, aprender qual o(s) documento(s) mais relevante e dessa forma alterar a ordena¸cão dos documentos, promovendo o(s) resultado(s) pretendidos para o topo da lista.

Além disto, o motor de busca deve funcionar na l´ıngua do sistema, de forma a permitir a utiliza¸cão da funcionalidade nos diversos mercados em que a aplica¸cão é comercializada.

1.3 Metodologia

Como foi referido nas seçcões anteriores, o principal problema do iPortalDoc está no tempo de resposta do motor de pesquisa. Além disso, um segundo problema é a pobre qualidade dos resultados apresentados.

Para se poder compreender melhor o problema do tempo de resposta, e também para permitir encontrar a solu¸cão mais adequada, realizaram-se testes de performance, tanto do motor de pesquisa existente, como das solu¸cões consideradas. Estes testes serviram para se poder, de uma forma quantitativa, avaliar qual o melhor plano de ataque ao problema. Os testes foram realizados numa réplica da base de dados de produ¸cão da IPBRICK, pelo que apresentam resultados fiáveis devido ao grande volume de amostras.

J´a para compreender melhor o problema da qualidade dos resultados, os testes re-alizados tiveram como objetivo a recolha de amostras de resultados de pesquisas,

(25)

1.4. A Empresa

para se poder, de forma qualitativa, avaliar a relevância dos documentos. No en-tanto, após a implementa¸cão do módulo de aprendizagem, não foi poss´ıvel testar com uma amostra volumosa de dados, pelo que não é poss´ıvel avaliar com precisão o desempenho da solu¸cão.

Embora o problema do iPortalDoc seja muito espec´ıfico, o que impede reproduzir os resultados obtidos fora do ambiente de desenvolvimento da IPBRICK, a solu¸cão encontrada pode ser adaptada a diversos casos semelhantes, pois esta foi desenhada utilizando métodos usados frequentemente em problemas deste género.

1.4 A Empresa

A IPBRICK S.A. surgiu no ano 2000, na altura pelo nome de iPortalMais, fundada pelo Eng.º Raúl Oliveira, ex-professor de Engenharia Eletrotécnica e de Computa-dores na FEUP, impulsionada por época de intensa atividade de apoio ao sistema operativo Linux.

A sua área inicial de interven¸cão prendia-se no desenvolvimento de aplica¸cões para a internet, assentes em software open source. Em 2001 come¸cou a dar os primeiros passos de investiga¸cão e desenvolvimento e a conceber solu¸cões para comunica¸cões empresariais.

Devido `a sua impossibilidade de formar parceiros para a instala¸c˜ao de servidores Linux, decidiu criar uma ferramenta para instalar automaticamente o servidor Linux de intranet, surgindo assim o produto IPBrick.

Já em 2005, aproveitando a estabiliza¸cão tecnológica dos seus produtos e das cres-centes solicita¸cões do mercado externo deu passos ambiciosos na internacionaliza¸cão da empresa.

Hoje, a IPBRICK é uma empresa saudável que concorre num mercado mundial com grande potencial e quase sem limites com o que chama de quadrante mágico: comunica¸cões unificadas, gestão de documentos e processos, email e groupware e a sua rede social corporativa.

1.5 Estrutura do Documento

Este documento encontra-se organizado em seis cap´ıtulos. Neste primeiro cap´ıtulo foi feita uma breve apresenta¸cão do projeto, apresentando o contexto em que este se insere, a motiva¸cão para esta disserta¸cão e os seus objetivos gerais.

No Cap´ıtulo 2 é feita uma revisão bibliográfica, onde e apresenta o campo de recu-pera¸cão de informa¸cão, alguns métodos de pesquisa existentes e várias ferramentas relevantes. Descrevem-se também as solu¸cões de pesquisa textual que nos são dis-ponibilizadas no PostgreSQL, o sistema de gestão de bases de dados utilizado no

(26)

1.5. Estrutura do Documento

iPortalDoc, assim como vários tipos de ´ındices, estruturas de dados que permitem aumentar a velocidade da recupera¸cão da informa¸cão. Além disso é feito também um levantamento da área de aprendizagem computacional e mais especificamente de técnicas de classifica¸cão de documentos. Nesta seçcão analisar-se-á também várias ferramentas dispon´ıveis para a conce¸cão de sistemas com capacidades de aprendi-zagem, com o intuito de escolher a mais adequada para ser integrada no iPortal-Doc.

Feita a revisão bibliográfica, é então apresentado em mais detalhe, no Cap´ıtulo 3, a génese do problema, onde são expostos testes realizados que demonstram que a performance do motor de pesquisa do iPortalDoc está longe do que é aceitável. Conhecendo o problema em detalhe são estudadas diferentes possibilidades para a solu¸cão, que são apresentadas no Cap´ıtulo 4. Aqui é apresentado o modelo rela-cional do iPortalDoc, através do qual é poss´ıvel compreender a especificidade do problema e as dificuldades que foram encontradas ao longo do desenvolvimento do trabalho. Expõe-se também testes que foram realizados na tentativa de compreender a performance de várias solu¸cões e que levaram à escolha da solu¸cão implementada e revelada a arquitetura da solu¸cão. Já no Cap´ıtulo 5 apresentam-se os resultados obtidos com a solu¸cão implementada.

Por fim, no Cap´ıtulo 6, são tiradas as conclusões da disserta¸cão e discutem-se ideias interessantes para trabalho futuro.

(27)

Cap´ıtulo 2

Revis˜

ao Bibliogr´

afica

Para compreender melhor o problema é necessário antes compreender o estado do campo de recupera¸cão de informa¸cão e ter uma no¸cão das diferentes técnicas existen-tes e as vantagens e desvantagens de cada uma para quando for feita a arquitetura do sistema a desenvolver.

Neste cap´ıtulo é feita uma introdu¸cão ao campo de recupera¸cão de informa¸cão, se-guido de uma listagem e breve explica¸cão de diferentes técnicas usadas para o efeito. Exploram-se também as solu¸cões de pesquisa disponibilizadas no PostgreSQL, o SGBD utilizado no iPortalDoc, assim como os tipos de ´ındices que podem ser utili-zados para o efeito. São enumeradas algumas ferramentas relevantes.

Segue-se com uma introdu¸cão ao campo de inteligência artificial, mais especifica-mente, ao campo de aprendizagem computacional e apresentam-se alguns dos algo-ritmos mais relevantes para a classifica¸cão de documentos. São por fim apresentadas algumas ferramentas dispon´ıveis de serem utilizadas para integrar capacidades de aprendizagem no iPortalDoc.

2.1 Recupera¸

c˜

ao de Informa¸

c˜

ao

As primeiras bibliotecas surgiram à volta do ano 3000 AC, consistindo em arquivos de placas de barro, sendo que os sumérios desenvolveram formas de classificar e identificar cada placa, já percebendo na altura a importância de manter os arquivos organizados [2, 3].

Ao longo dos séculos, com o aparecimento do papel, tornou-se cada vez mais impor-tante encontrar formas eficientes de armazenar e recuperar a informa¸cão [2]. Com o aparecimento do computador come¸cou-se a perceber que estes poderiam ser usados para armazenar e recuperar grandes volumes de informa¸cão e estas ideias come¸caram a materializar-se na década de 50 [2].

As bibliotecas foram das primeiras a adotar sistemas de recupera¸cão de informa¸cão [4]. Estes sistemas foram inicialmente desenvolvidos em ambientes académicos e

(28)

2.1. Recupera¸c˜ao de Informa¸c˜ao

apenas mais tarde surgiram solu¸c˜oes comerciais. Numa primeira fase estes sistemas permitiam simplesmente pesquisar t´ıtulo e autor. Mais tarde os sistemas vieram-se a desenvolver para permitir a pesquisa por queries mais complexas [4].

Na década de 60 deram-se alguns grandes avan¸cos, com o desenvolvimento do sistema SMART na universidade de Cornell, onde se desenvolveram técnicas como a do modelo vetorial. Nos anos 70 e 80 vários novos modelos foram desenvolvidos e experimentalmente comprovados em pequenas cole¸cões de dados. No entanto, devido `

a falta de cole¸cões de tamanho considerável os investigadores possu´ıam dúvidas quanto à escalabilidade destes modelos [5, 2]. Para dar resposta a isto, surgiu nos anos 90 a TREC, uma conferência cujo objetivo era fomentar a colabora¸cão na constru¸cão de grandes cole¸cões de dados, o que levou à reformula¸cão de técnicas já existentes e ao desenvolvimento de novas técnicas que fossem eficientes em grandes volumes de dados [6].

Com o aparecimento da WWW, a necessidade de pesquisa na web levou a que algoritmos de recupera¸cão de informa¸cão (RI) fossem aplicados nesta área. Ao longo dos anos estes sistemas evolu´ıram para tirar partido das hiperliga¸cões entre páginas [7]. Hoje em dia, a web é a forma mais fácil e rápida para aceder a informa¸cão, o que permite chegar a um cada vez maior número de pessoas sem haver limita¸cões de fronteiras [4].

2.1.1 Introdu¸

c˜

ao `

a Recupera¸

c˜

ao de Informa¸

c˜

ao

O campo de recupera¸cão de informa¸cão pode ser definido como o campo que lida com a pesquisa e recupera¸cão de informa¸cão não estruturada (geralmente texto) que se encontram armazenados em cole¸cões, regra geral em computadores [5]. A informa¸cão dita não estruturada refere-se a informa¸cão que não tem uma estrutura clara para um computador, pois como é claro para nós humanos, o texto apresenta estrutura, como t´ıtulos, por exemplo. Já do mesmo ponto de vista, a informa¸cão estruturada é informa¸cão que ’encaixa’ bem, por exemplo, numa base de dados.

Portanto um sistema de recupera¸cão de informa¸cão deve ser capaz de armazenar os dados de uma forma a que seja poss´ıvel disponibilizar ao utilizador formas de pesquisa estruturada [5], como é o exemplo do iPortalDoc que permite realizar as pesquisas em diversos campos como t´ıtulo, sumário, descri¸cão, entre outros. A representa¸cão e organiza¸cão desta informa¸cão deve permitir ao utilizador um acesso fácil e rápido aos dados que procura [4].

A componente de recupera¸cão de dados de um sistema de recupera¸cão de informa¸cão tem como objetivo selecionar os documentos que contêm os termos pelos quais o uti-lizador pesquisou, o que geralmente não é suficiente para satisfazer o utilizador. En-quanto que um sistema de recupera¸cão de informa¸cão tem como objetivo recuperar a informa¸cão relevante para o utilizador, a recupera¸cão de dados apenas se interessa pela recupera¸cão da informa¸cão que satisfaz a query, sendo que se um simples erro implica que todo o processo falhou quando num sistema de RI, a recupera¸cão de alguma informa¸cão que não é totalmente precisa ou até relevante para o utilizador

(29)

por vezes passa despercebida [4]. ´

E portanto importante reter o conceito de relevância que é fundamental no campo de recupera¸cão de informa¸cão. Para a constru¸cão de uma solu¸cão que satisfa¸ca as necessidades dos seus utilizadores, um sistema de RI deve conseguir analisar os conteúdos dos documentos e com esses dados ordenar os resultados de acordo com a relevância para a query do utilizador [4].

Um sistema de informa¸cão pode ser classificado com respeita à escala em que ope-ram: pesquisas web, recupera¸cão de informa¸cão pessoal e o intermédio destes dois extremos, que é onde o iPortalDoc encaixa, o dom´ınio institucional [5].

A primeira categoria, de web, é obviamente a maior e provavelmente a mais compli-cada de trabalhar. A esta escala lidam-se com milhares de milhões de documentos, espalhados por inúmeros servidores por todo o mundo. Os principais desafios são a constru¸cão de sistemas que funcionem a esta escala, a indexa¸cão do enorme volume de informa¸cão e o desenvolvimento de algoritmos que sejam capazes de compreen-der o markup das páginas web para poderem eficazmente realizar o ranking e evitar tentativas fraudulentas de manipular esse ranking [5].

Na escala de recupera¸cão de informa¸cão pessoal compreendem-se por exemplo os sistemas de pesquisa integrados nos sistemas operativos. Os pontos foco destes sistemas são lidar com a enorme variedade de documentos existentes no computador do utilizador, evitar a necessidade de manuten¸cão do sistema e também assegurar que este é um sistema leve no que diz respeito ao consumo de recursos [5].

Por fim, no dom´ınio institucional temos, por exemplo, um sistema para recuperar informa¸cão das cole¸cões de uma empresa. Nestes casos, a informa¸cão tipicamente encontra-se armazenada numa base de dados, tendo um servidor que oferece fun¸cões de pesquisa dessa informa¸cão [5].

2.1.2 O Utilizador

A tarefa do utilizador, quando utiliza um sistema de recupera¸cão de informa¸cão, é a introdu¸cão da query no sistema [4]. Regra geral esta query é feita utilizando uma combina¸cão dos termos procurados.

Quando um utilizador realiza uma pesquisa num sistema de RI ou motor de pesquisa, está a comandar o sistema a executar uma a¸cão de recupera¸cão.

No entanto, pode acontecer que o utilizador não tenha uma ideia concreta do que procura e a sua intera¸cão com o sistema pode limitar-se a navegar na cole¸cão de dados até encontrar algo do seu interesse. Um exemplo concreto poderá ser na-vegar por uma loja online. Nesta caso dir-se-á que está a executar uma a¸cão de navega¸cão.

(30)

Figura 2.1: Intera¸cões do utilizador com o sistema de recupera¸cão de informa¸cão

Através da figura é poss´ıvel visualizar que geralmente os sistemas de RI oferecem a possibilidade de executar os dois tipos de a¸cões mencionadas (recupera¸cão e na-vega¸cão). No caso do iPortalDoc, um utilizador tanto pode encontrar o documento que procura através da pesquisa ou navegando a hierarquia de diretorias. O sis-tema pode também oferecer uma forma de utiliza¸cão que combina a recupera¸cão e a navega¸cão, no entanto ainda não é uma prática comum [4].

Também é poss´ıvel perceber que as a¸cões podem repetir-se, ou seja, o utilizador solicita a informa¸cão de uma forma interativa [4]. Um exemplo disto pode ser simplesmente a pagina¸cão que ocorre quando é realizada uma pesquisa. Quando o utilizador solicita mais documentos, a a¸cão de recupera¸cão repete-se para atender ao pedido do utilizador.

2.1.3 Os Documentos

Os documentos de uma cole¸cão são frequentemente representados por um ´ındice que contêm as suas palavras-chave. Estas palavras chave podem ser tiradas diretamente do texto do documento ou introduzidas manualmente pelo utilizador no momento de inser¸cão. De qualquer das formas esta representa¸cão das palavras-chave do do-cumento representam a visão lógica dos documentos [4].

Hoje em dia os computadores já permitem armazenar o texto completo do docu-mento, ou seja, representa-lo pelo conjunto completo de termos que contêm. No entanto, para cole¸cões com um grande volume de documentos esta solu¸cão torna-se pouco viável, recorrendo-se a processos de redu¸cão dos termos do documento como

(31)

´

e poss´ıvel observar na Figura 2.2 [4].

Figura 2.2: Processo de indexa¸c˜ao de documentos

Através da figura é poss´ıvel observar as diferentes fases por que um documento pode passar, desde ter o texto completo até o este estar representado pelo m´ınimo de termos poss´ıvel, que se encontram descritas de seguida [4]:

1. Nesta primeira fase, de análise de estrutura, o texto é analisado com o objetivo de reconhecer a estrutura do mesmo, como cap´ıtulos, seçcões, entre outros; 2. Na segunda fase ocorre a tokenization, ou seja, o texto é divido pelos espa¸cos

e pontua¸c˜ao, passando a ter v´arias strings com as palavras (tokens) em vez de apenas uma com o texto completo;

3. Na terceira fase realiza-se a remo¸cão de stopwords são retiradas palavras co-muns cujo significado é reduzido (como ’o’, ’a’, ’de’, ’do’);

4. Na fase de stemming as palavras são reduzidas à sua raiz (gatos, gata, gatinho são todos armazenados como gato, por exemplo)

5. Por fim os termos restantes, que descrevem o documento, são indexados Como é lógico, a indexa¸cão completa do documento é a solu¸cão que melhor o repre-senta, no entanto implica um maior custo computacional. É então comum armazenar uma visão lógica do documento mais concisa que irá levar a uma melhor performance do sistema mas poderá levar a resultados mais pobres [4].

2.1.4 O Processo de Recupera¸

c˜

ao de Informa¸

c˜

ao

O processo de recupera¸cão de informa¸cão é um processo que pode ser dividido em várias etapas que encontram representadas no esquema da Figura 2.3 [4].

Antes da execu¸cão do processo poder ter in´ıcio é necessário definir a visão lógica dos documentos. Para isso é necessário definir quais os documentos a serem usados, as opera¸cões que podem ser realizadas sobre o texto e modelo do texto que representa a sua estrutura e quais os campos que podem ser pesquisados [4].

(32)

Com a visão lógica dos documentos definida é constru´ıdo um ´ındice com os termos dos documentos. Um ´ındice é uma estrutura indispensável num sistema de RI pois permite agilizar o processo de pesquisa sobre grandes volumes de dados [4]. Existem diferentes tipos de ´ındices que serão descritos mais à frente.

Figura 2.3: Processo de recupera¸c˜ao de informa¸c˜ao

O processo de recupera¸cão de informa¸cão inicia-se então quando o utilizador insere o termos da sua pesquisa. Este texto introduzido pelo utilizador pode sofrer algumas opera¸cões (das referidas na fase de indexa¸cão, por exemplo) e com o resultado destas opera¸cões é formulada uma query que é então submetida ao sistema que armazena os documentos e é executada a pesquisa. Quando os resultados são devolvidos estes passam por uma fase de ordena¸cão onde o sistema irá reordenar os documentos tendo em conta a sua relevância para a pesquisa do utilizador [4].

2.1.5 M´

etricas de Avalia¸

c˜

ao

Quando o utilizador realiza uma pesquisa num sistema de recupera¸cão de informa¸cão, o objetivo deste deve ser apresentar a informa¸cão considerada relevante, devida-mente ordenada. No entanto, é normal que parte da informa¸cão recuperada seja de pouco interesse ou até mesmo irrelevante visto que um sistema de recupera¸cão de informa¸cão lida com linguagem humana, que pode conter ambiguidades ou até erros, enquanto que a informa¸cão está tipicamente armazenada em computadores onde existe uma estrutura de dados bem definida.

A eficiência de um sistema de recupera¸cão de informa¸cão pode ser medida com as métricas precision e recall [8] que se encontram representadas na Figura 2.4.

(33)

Figura 2.4: Ilustra¸c˜ao das m´etricas precision e recall

Note-se que o conjunto R representa todos os documentos relevantes e o conjunto D todos os documentos devolvidos pelo sistema de recupera¸cão de informa¸cão. A interce¸cão dos dois, o conjunto X, representa então o conjunto de documentos rele-vantes que foram devolvidos.

Precision define-se ent˜ao como a rela¸c˜ao entre o conjunto de documentos relevantes que foram retornados e o conjunto total de documentos retornados:

X D

Recall define-se como a rela¸c˜ao entre o n´umero de documentos relevantes que foram devolvidos e o conjunto total de documentos relevantes:

X R ´

E poss´ıvel aumentar aumentar uma métrica à custa da outra [9]. Isto deve-se ao facto de se estar a lidar com texto, que pode muitas vezes ser subjetivo. Se o utilizador quiser uma pesquisa mais abrangente poss´ıvel o sistema pode pesquisar não só pelos termos inseridos mas também por sinónimos ou conceitos relacionados, o que leva a um aumento da probabilidade de retornar documentos não relevantes. Por outro lado, se a pesquisa for muito estrita pode acontecer que haja documentos relevantes que não satisfazem a query e portanto não são devolvidos.

Também é necessário referir que a relevância de um documento é bastante subjetiva, podendo variar de utilizador para utilizador.

´

E então importante, durante a conce¸cão de um sistema de RI, encontrar um compro-misso entre estas métricas. Embora obter uma percentagem elevada de recall seja desejável e até relativamente simples (percorrendo a base de dados completamente),

(34)

2.2. T´ecnicas

é geralmente prefer´ıvel obter maior precisão, sendo que os utilizadores costumam necessitar apenas de um ou dois resultados relevantes [9]. A combina¸cão das duas métricas é conhecida por F-measure e é descrita pela seguinte equa¸cão:

F = (1 + α

2_{) · P · R}

(α2_{· P ) + R} (2.1)

A vari´avel P representa precision e R recall. α permite dar mais peso a uma ou outra m´etrica, sendo que α = 1 equivale a um balanceamento das duas.

2.2 T´

ecnicas

Nesta seçcão irão ser apresentados alguns dos principais modelos de recupera¸cão, come¸cando pelo modelo booleano, o mais básico, e cobrindo depois alguns dos mais usados nos dias que correm, o modelo vetorial e o modelo probabil´ıstico.

2.2.1 Modelo Booleano

Um dos primeiros modelos de recupera¸cão de informa¸cão a surgir foi o modelo booleano em que as queries são colocadas utilizando combina¸cões dos operadores AND, OR e NOT [2].

Devido a esta natureza bin´aria os resultados retornados correspondem exatamente `

as condi¸cões impostas na query, não pode haver uma correspondência parcial [5]. Além disso também se torna complicado para o utilizador exprimir queries mais complexas.

A desvantagem deste modelo ´e que apenas permite ordenar os documentos pela existˆencia dos termos pesquisados. A sua grande vantagem reside na sua simplici-dade.

De seguida é apresentado um exemplo de utiliza¸cão deste modelo. O primeiro passo é criar uma matriz que indique quais os documentos em que cada termo indexado está presente [5]:

T´aticas de Futebol B´ıblia Watchmen RI

Jesus 1 1 0 0

Rorschach 0 0 1 0

Boole 0 0 0 1

Tabela 2.1: Matriz termo-documento para pesquisa booleana

Cada coluna desta matriz é um vetor que contem informa¸cão acerca dos termos existentes no documento correspondente. O modelo booleano acaba então por ser um caso espec´ıfico do modelo vetorial que será apresentado na seçcão seguinte.

(35)

2.2. T´ecnicas

Se o utilizador quiser encontrar quais os documentos que contêm ’Boole’ ou ’Rors-chach’ mas não ’Jesus’ então poderia exprimir a query da seguinte forma: ’Boole’ OR ’Rorschach’ AND NOT ’Jesus’. De seguida calculava-se o resultado da seguinte expressão:

0001 OR 0010 AND 0011

O resultado desta express˜ao ´e 0011, correspondendo aos documentos ’Watchmen’ e ’RI’.

2.2.2 Modelo Vetorial

No modelo vetorial, tal como no booleano, os documentos são representados num vetor de termos, tipicamente palavras, em que cada uma se torna uma dimensão num espa¸co dimensional que será tanto maior quanto o número de termos existentes. Um determinado termo que exista num texto terá um valor não nulo no vetor do texto, na dimensão correspondente. Como um documento tem um conjunto limitado de termos de um enorme vocabulário, estes vetores são tipicamente muito esparsos [2].

Neste modelo é obtida a ’pontua¸cão’ de um documento calculando a similaridade entre o vetor que representa a query colocada pelo utilizador e o vetor do documento. Esta similaridade poderia ser calculada através do produto interno entre os vetores

~

D que representa o documento e ~Q que representa a query [10]:

~

D · ~Q (2.2)

No entanto esta forma de calcular n˜ao leva em conta o tamanho do documento. Um documento muito longo tende a ser considerado mais relevante pois como existe mais texto, as palavras tendem a aparecer mais vezes [10, 5], enquanto que os termos pesquisados aparecerem num documento mais curto indica, provavelmente, que esse documento ´e mais relevante.

Para compensar este efeito, é comum atribuir-se diferentes pesos aos termos exis-tentes num documento, tendo em conta a sua relevância. A similaridade entre dois documentos é tipicamente calculada pelo ângulo que existe entre os dois vetores aproveitando a propriedade do co-seno que nos dá o valor 1 para ângulos idênticos e 0 para ângulos ortogonais. Normalizando o valor dos vetores para ocuparem valores entre 0 e 1, o cálculo da similaridade é reduzido ao produto interno dos vetores do documento ~D e da query ~Q [2]:

Sim( ~D, ~Q) = X

ti∈Q,D

wtiQ· wtiD (2.3)

Onde wtiQ representa o peso do termo i na query Q e wtiD representa o peso do termo i no documento D. Estes pesos s˜ao geralmente calculados usando o m´etodo

(36)

2.2. T´ecnicas

de pesagem tf -idf (Term Frequency - Inverse Document Frequency).

O método tf -idf funciona relacionando duas métricas. A primeira, tf , indica a frequência do termo no documento, ou seja, o número de vezes que este aparece no documento [11]. Logo, quantas mais vezes o termo aparece no documento, maior vai ser este valor.

Para poder ter em conta o facto de várias palavras serem comuns ao longo da cole¸cão de documentos, o peso do termo é ajustado usando a idf que indica a propor¸cão do termo na cole¸cão de documentos, ou seja, este valor vai ser maior quanto mais raro for o termo. Este valor é calculado da seguinte forma [11]:

idf (t, D) = log N |ft,D|

(2.4)

Em que N representa o n´umero total de documentos na cole¸c˜ao e ft,D representa o

n´umero de documentos em que o termo t aparece.

O valor final do peso ´e ent˜ao calculado da seguinte forma [11]:

tf · idf = ft,d· log

N |ft,D|

(2.5)

A vantagem do modelo vetorial em rela¸cão ao modelo booleano é a possibilidade de obter correspondências parciais e calcular a semelhan¸ca entre as queries e os documentos e fazer desta forma uma ordena¸cão por relevância que leva em conta a frequência com que os termos aparecem nos documentos da cole¸cão.

2.2.3 Modelos Probabil´ısticos

Os modelos probabil´ısticos são uma fam´ılia de modelos de recupera¸cão de informa¸cão cujo princ´ıpio reside na ideia de que os documentos devem ser ordenados por ordem decrescente da probabilidade de serem relevantes a uma determinada query. A isto dá-se o nome de Probabilistic Ranking Principle (PRP). Estes modelos estimam essa probabilidade, mas a forma como o fazem varia de modelo para modelo [2].

O primeiro modelo probabil´ıstico foi proposto por Maron e Kuhns e tinha como principal ideia calcular a probabilidade de relevância dos termos de um documento para a query que foi realizada [12]. No entanto este modelo nunca foi posto em prática devido à dificuldade em estimar os parâmetros necessários [13].

Apresenta-se ent˜ao de seguida o Binary Independence Model (BIM), um modelo frequentemente usado com o PRP pois introduz algumas assun¸c˜oes que tornam mais simples o calculo das probabilidades [5].

(37)

2.2. T´ecnicas

Binary Independence Model

O BIM surge como uma generaliza¸cão do modelo proposto por Maron e Kuhns [13]. O modelo assume que os termos são independentes entre si (da´ı o nome). Embora esta assun¸cão seja errada, na prática os resultados são satisfatórios [5].

Este modelo come¸ca por representar a query por um vetor ~q = (q1, ..., qi) que

apre-senta o valor 1 nas dimens˜oes correspondentes aos termos que contˆem e 0 nas res-tantes (semelhante ao modelo vetorial):

qi =

1, Se a query contˆem o termo ti

0, Caso contr´ario

(2.6)

O objetivo do modelo ´e ent˜ao calcular a probabilidade de um documento ~d ser relevante dada uma query ~q, P (R, |dm, qk). Usando o teorema de Bayes:

P (R = 1| ~d, ~q) = P ( ~d|R = 1, ~q) · P (R = 1|~q)

P (~x|~q) (2.7)

P (R = 0| ~d, ~q) = P ( ~d|R = 0, ~q) · P (R = 0|~q)

P (~x|~q) (2.8)

As expressões P ( ~d|R = 1, ~q) e P ( ~d|R = 0, ~q) representam a probabilidade de, re-cuperado um documento relevante (R = 1) ou não (R = 0), a representa¸cão desse documento ser ~d. No entanto, como é complicado estimar estas probabilidades pode-se ordenar os documentos de acordo com a sua razão de relevância:

O(R| ~d, ~q) = P (R = 1| ~d, ~q) P (R = 0| ~d, ~q) = P ( ~d|R=1,~q)·P (R=1|~q) P (~x|~q) P ( ~d|R=0,~q)·P (R=0|~q) P (~x|~q) = P ( ~d|R = 1, ~q) · P (R = 1|~q) P ( ~d|R = 0, ~q) · P (R = 0|~q) (2.9)

A expressão P (R=1|~_{P (R=0|~}q)_q) é constante para uma dada query, pelo que não é necessário estimar. Como foi mencionado no inicio, assume-se que os termos são independentes entre si. Desta forma pode-se simplificar a equa¸cão para:

O(R| ~d, ~q) = O(R|~q) · n Y t=1 P (dt|R = 1, ~q) P (dt|R = 0, ~q) (2.10)

(38)

2.2. T´ecnicas

Como dt= 1 ∨ dt = 0 ´e poss´ıvel separar os termos obtendo ent˜ao:

Fazendo pt = P (dt = 1|R = 1, ~q) e ut = P (dt = 1|R = 0, ~q), e assumindo que

os termos que não ocorrem na query podem ocorrer igualmente em documentos relevantes e não relevantes, obtém-se então:

O(R| ~d, ~q) = O(R|~q) · Y t:dt=qt=1 pt ut · Y t:dt=0,qt=1 1 − pt 1 − ut = O(R|~q) · Y t:dt=qt=1 pt(1 − ut) ut(1 − pt) · Y t:qt=1 1 − pt 1 − ut (2.12) A express˜ao Qn t:qt=1 1−pt

1−ut é constante pelo que não é necessário estimar. É então apenas necessário estimar Retrieval Status Value (RSV):

RSVd= log Y t:dt=qt=1 pt(1 − ut) ut(1 − pt) = X t:dt=qt=1 log pt(1 − ut) ut(1 − pt) = X t:dt=qt=1 log pt (1 − pt) + log(1 − ut) ut (2.13)

Assumindo que os documentos relevantes são raros (o que se torna próximo da verdade em cole¸cões de grande volume) [2] é poss´ıvel fazer ut = f_Nt, em que ft

representa o n´umero de documentos em que o termo t aparece e N sendo o n´umero total de documentos: ut= log (1 − ut) ut ≈ logN − ft ft ≈ logN ft (2.14) ´

E poss´ıvel observar similaridade com a equa¸cão 2.4. Como este é um modelo binário, pode-se assumir que pt = 0.5, sendo que a expressão log_1−ppt_t = 1 e RSV torna-se

um somat´orio das idf .

Este modelo probabil´ıstico teve grandes influências no campo de RI, este apresenta algumas ’falhas’ que levam a que o seu uso, na forma apresentada, seja reduzido [14]. Em primeiro lugar o modelo não leva em conta as frequências dos termos

(39)

2.3. Indexa¸c˜ao

no documento, pelo que a repeti¸cão de um termo num documento não leva a que este documento seja considerado mais relevante quando deveria. Em segundo lugar, e tal como o modelo vetorial, também não considera o tamanho do documento, pelo que um termo que ocorre muitas vezes num documento longo vai levar a que esse documento tenha uma relevância maior quando provavelmente esse termo terá menos significado num documento longo do que num mais curto.

2.3 Indexa¸

c˜

ao

As técnicas de pesquisas que foram apresentadas preocupam-se apenas com a qua-lidade dos resultados, enquanto que para melhorar a performance de um sistema são utilizados ´ındices. Um ´ındice é uma estrutura de dados que permite organizar a informa¸cão de modo a otimizar as opera¸cões de recupera¸cão dessa informa¸cão [15].

Para compreender melhor o funcionamento de um ´ındice ´e necess´ario primeiro per-ceber a forma como a BD armazena os dados das tabelas.

2.3.1 Heap Files

Os dados encontram-se armazenados em heap files, que são ficheiros desordenados, ou seja, os dados encontram-se guardados de forma aleatória ao longo de várias páginas, sendo que uma página é uma unidade de dados em disco [15].

Como os dados se encontram armazenados de forma não ordenada, quando se rea-liza uma opera¸cão de pesquisa é necessário percorrer todas as páginas do ficheiro, verificando todos as entradas existentes e recuperar as que satisfazem as condi¸cões postas. Para se realizarem as pesquisas é necessário manter contagem das páginas e para se realizarem inser¸cões de novos dados é também necessário manter a listagem das páginas que têm espa¸co livre [15].

Existem várias formas de manter estes ficheiros, sendo que se irá apresentar a lista ligada de páginas e o diretório de páginas.

Lista Ligada de P´aginas

Na organiza¸cão por lista ligada o SGBD sabe onde se encontra a primeira página guardando pares de hnome ficheiro, apontador pagina 1 i. A organiza¸cão do ficheiro encontra-se ilustrada na Figura 2.5 [15].

Cada apontador representa um identificador da página. Repare-se também que na verdade existem duas listas ligadas: uma com as páginas com espa¸co livre e outra com as páginas que se encontram preenchidas. Isto permite ter acesso direto

(40)

2.3. Indexa¸c˜ao

Figura 2.5: Organiza¸c˜ao de ficheiro heap em lista ligada

a páginas com espa¸co para se poderem fazer inser¸cão de novos dados. Caso seja necessária uma nova página basta adicionar os apontadores à lista [15].

A grande desvantagem deste tipo de organiza¸cão dos ficheiros heap é que, caso os dados que se inserem sejam de tamanho variável, é altamente provável que todas as páginas estejam na lista de páginas livres pois ao inserir dados novos procura-se uma página que tenha espa¸co suficiente e é comum sobrarem sempre alguns bytes de espa¸co [15]. Para atacar este problema pode-se utilizar um diretório de páginas.

Diret´orio de P´aginas

Neste tipo de organiza¸cão o SGBD também guarda a localiza¸cão da primeira página de cada ficheiro heap, tal como na lista ligada [15]. A organiza¸cão do ficheiro encontra-se ilustrada na Figura 2.6 [15].

Como é poss´ıvel perceber através da figura, cada diretório é uma cole¸cão de páginas, e os diretórios estão conectados através de uma lista ligada. Cada entrada no di-retório identifica uma página do ficheiro. À medida que o ficheiro cresce ou diminui de tamanho o número de entradas no diretório aumenta ou diminui em concordância [15].

A gestão do espa¸co livre pode ser efetuada mantendo um bit por cada entrada do diretório que indica se a página correspondente têm espa¸co livre. Pode-se, em alternativa, guardar o espa¸co livre da página correspondente. Desta forma, ao inserir novos dados pode-se verificar qual o espa¸co livre de cada entrada e determinar se os dados podem ser armazenados na página correspondente. Desta forma torna-se mais eficiente procurar uma página com espa¸co suficiente para armazenar os dados.

(41)

2.3. Indexa¸c˜ao

Figura 2.6: Organiza¸cão de ficheiro heap em diretório de páginas

2.3.2 ´

Indices

Os ´ındices permitem recuperar eficientemente todas as entradas de uma tabela que satisfazem uma condi¸cão de um determinado campo, ou coluna. Para isto ser poss´ıvel é criado um ficheiro que organiza os dados numa de três op¸cões [15]:

1. Cada entrada k∗ contˆem toda a informa¸c˜ao de uma fila cujo valor indexado seja k;

2. Cada entrada armazena o par hk, eidi, sendo que eid representa o id de um entrada cujo valor indexado seja k;

3. Cada entrada armazena o par hk, lista eidi, sendo que listaeid representa uma

lista de ids de entradas cujos valores indexados sejam k;

No 1º tipo os dados, por defini¸c˜ao, encontram-se ordenados pelo valor da coluna indexada, sendo portanto classificado de ´ındice agrupado (clustered ) [15]. Tamb´em ´

e poss´ıvel armazenar os tipos 2 e 3 como ´ındices agrupados ordenando pela coluna indexada, no entanto esta opera¸cão torna-se complicada de manter com a inser¸cão de novos dados logo é mais comum usá-los como ´ındices desagrupados (unclustered ) [15].

Para efetuar queries de intervalos (por exemplo: SELECT ... BETWEEN x AND y), os ´ındices agrupados tornam-se muito mais eficientes pois os ids das entradas que satisfazem a query apontam para p´aginas cont´ıguas enquanto que num ´ındice

(42)

desa-2.3. Indexa¸c˜ao

grupado levaria a ter de ir muitas p´aginas separadas [15].

´_{Indices Hash}

Os ´ındices hash, como o nome indica, utilizam hashing para encontrar os dados pretendidos de forma r´apida e eficaz [15].

Os dados que se encontram num ficheiro estão agrupados, sendo que o grupo contêm uma página principal e, possivelmente, páginas adicionais ligadas. Para se descobrir o grupo em que uma determinada entrada se encontra basta fazer o hash da chave que se procura. Sabendo o grupo é poss´ıvel recuperar a página correspondente com apenas uma ou duas chamadas ao disco. Nas inser¸cões os dados são armazenados no grupo correspondente, criando mais páginas se for necessário [15].

Na Figura 2.7 [15] é poss´ıvel observar o funcionamento de um ´ındice hash. No exemplo apresentado a indexa¸cão é feita no campo idade, portanto, quando é feita uma consulta ao ´ındice, o valor procurado da idade passa por uma fun¸cão de hash que vai servir para identificar o grupo em que se encontram as entradas com essa hash (no exemplo, o grupo é identificado através dos dois últimos bits da hash).

Figura 2.7: ´Indice em hash no campo idade

Note-se que o ´ındice está representado com o 1º tipo apresentado anteriormente. A principal desvantagem destes ´ındices, é o facto de apenas suportarem compara¸cões de igualdade, pelo que quando é necessário compara¸cões em intervalos ou ordena¸cão de resultados é necessário usar outro tipo de ´ındices, como os ´ındices em árvore.

´_{Indices em ´}_Arvore

Outro método de indexa¸cão existente é a organiza¸cão dos dados em árvore. Neste tipo de ´ındices os dados são armazenados no n´ıvel mais baixo da árvore, a que se chamam folhas, e a estrutura em árvore permite localizar as entradas relevantes eficientemente comparando a chave procurada com os intervalos dos nós da árvore [15].

(43)

2.3. Indexa¸c˜ao

Em cada nó existe uma série de valores e um apontador de cada lado desses valores. Comparando o valor procurado com os valores do nó, é fornecida a localiza¸cão do próximo nó até se alcan¸car a folha procurada. Este fluxo pode ser observado na Figura 2.8 [15].

Figura 2.8: ´Indice em ´arvore no campo idade

A pesquisa come¸ca no nó da raiz. É poss´ıvel verificar que cada nó tem dois valores como já foi dito. À esquerda de cada valor k está um apontador para um sub-nó que contêm apenas valores menores que k e à sua direita encontra-se um apontador para um sub-nó que contêm valores maiores ou iguais a k [15].

´_{Indices Invertidos}

Os ´ındices invertidos s˜ao um tipo de ´ındice muito usado para pesquisa textual devido `

a sua simplicidade e boa performance [15].

A principal desvantagem dos ´ındices invertidos são o espa¸co que ocupam: podem chegar a ter 300% do tamanho do ficheiro original e são muito sens´ıveis ao número de termos existentes na cole¸cão [15]. Para tentar reduzir o tamanho do ´ındice é comum eliminar stopwords e aplicar stemming como foi mencionado na seçcão 2.1.3. O nome invertido vem da forma como o ´ındice está constru´ıdo: é mantida uma lista dos termos existentes, sendo que para cada termo contém uma lista invertida que aponta os documentos que contêm esse termo. Cada documento da lista pode conter uma lista que mostra onde o termo pode ser encontrado dentro do docu-mento [15]. Na tabela 2.2 apresenta-se uma simplifica¸cão da estrutura de um ´ındice invertido.

A cole¸c˜ao de listas invertidas, chamada de postings file, pode-se tornar muito grande para cole¸c˜oes de documentos muito volumosas. Muitas vezes os motor de pesquisa

(44)

2.4. Pesquisa no PostgreSQL

Termo Documentos (postings file) elefante 1, 3

azul 1, 2, 5

filme 4

computador 2, 4

Tabela 2.2: Estrutura (simplificada) de um ´ındice invertido

na web armazenam cada lista invertida numa página separada, e muitas listas podem ocupar várias páginas, sendo que nessa situa¸cão são mantidas como listas ligadas. Para se poder encontrar a lista invertida de um determinado termo é comum criar-se um segundo ´ındice em árvore [15].

A lista de termos, chamada de lexicon, é muito menor que o postings file uma vez que apenas contém uma entrada por termo. Cada entrada contém a posi¸cão (em disco) da sua lista invertida e pode também conter informa¸cão acerca dessa lista. O lexicon é geralmente mantido em memória permitindo assim recuperar a lista invertida de um dado termo muito rapidamente [15].

Para recuperar os documentos relevantes a uma pesquisa, come¸ca-se por percor-rer o lexicon para se recuperarem as listas invertidas correspondentes aos termos pesquisados. Com essas listas é poss´ıvel então recuperar os documentos que interes-sam. Feito isto, é comum então proceder-se à ordena¸cão por relavância, como já foi descrito anteriormente.

2.4 Pesquisa no PostgreSQL

O PostgreSQL apresenta duas maneiras de realizar pesquisa de texto, os operadores LIKE e ILIKE e as fun¸cões de full text search. Nesta seçcão serão apresentadas ambas as op¸cões.

2.4.1 LIKE/ILIKE

Os operadores LIKE e ILIKE são usados para verificar se uma determinada string corresponde ao padrão submetido. Não é então tanto uma ferramenta de pesquisa de texto mas mais uma ferramenta de expressões regulares. O operador ILIKE, ao contrário do ILIKE, é case-insensitive.

Na tabela 2.3 encontram-se exemplos de uso destes operadores [16]:

O s´ımbolo % faz o matching de qualquer sequˆencia de 0 ou mais caracteres, enquanto que o _ apenas faz match a um.

(45)

Declara¸c˜ao Resultado ’abc’ LIKE ’abc’ true ’abc’ LIKE ’a%’ true ’abc’ LIKE ’_b_’ true ’abc’ LIKE ’c’ false

Tabela 2.3: Exemplos de uso do operador LIKE raz˜oes [16]:

• Não suportam ordena¸cão por relevância dos resultados; • Não tem suporte lingu´ıstico (stopwords, stemming)

Além destas razões, as opera¸cões de pesquisa com estes operadores apenas conse-guem tirar partido de ´ındices no caso de o padrão a pesquisar ser constante e estar ancorado ao ´ınicio da string [16].

2.4.2 Full Text Search

As fun¸cões de full text search permitem pesquisar o texto de documentos armaze-nados numa BD e ordená-los de acordo com a relevância dos documentos.

O sistema de full text search do PostgreSQL permitem que os documentos sejam pré-processados e indexados para melhorar o acesso à informa¸cão. Além de permitir realizar stemming e a remo¸cão de stopwords, também torna poss´ıvel armazenar a localiza¸cão dos termos dentro do documento [16]. Esta informa¸cão é útil quando se realiza a ordena¸cão pois um documento que contenha os termos pesquisados próximos uns dos outros vai ser considerado mais relevante do que outro que também contenha os termos mas muito espa¸cados.

Além disso disponibiliza também funcionalidades como fuzzy search que permitem encontrar correspondências mesmo quando existem erros ortográficos na query rea-lizada [16, 17].

Observe-se um exemplo de uma pesquisa utilizando o full text searching do Post-greSQL:

SELECT ’O s´ımbolo do postgres ´e um elefante azul’ @@ to_tsquery(’elefantes’);

,→

O texto armazenado na base de dados encontra-se no tipo tsvector, que parte a string em palavras e a cada uma atribui um número que indica a sua posi¸cão. Sem qualquer tipo de remo¸cão de stopwords ou stemming, o resultado da conversão para tsvector do texto ’O s´ımbolo do postgres é um elefante azul’ seria:

(46)

A string é então matched ao tsquery pelo operador @@. O tsquery é o tipo de dado usado para fazer as compara¸cões com o tsvector. Caso existisse stemming, então ’elefantes’ seria reduzido à raiz e o resultado do exemplo seria true.

O PostgreSQL disponibiliza dois tipos de ´ındice pr´oprios para utilizar com o full text search, o GiST (Generalized Search Tree) e o GIN (Generalized Inverted In-dex).

GiST

O GiST é um ´ındice de árvore lossy: isto quer dizer que durante as pesquisas pode produzir falsos positivos, sendo necessário recuperar essas entradas da tabela para verificar se realmente o match está correto [16].

Isto acontece pois no ´ındice os documentos são representados por uma stream de bits de tamanho fixo. Esta stream é criada fazendo uma hash de cada palavra para um bit na stream de n bits. Depois é feito um OR de todos os bits que produz a stream. Se a hash de duas palavras produzir bits na mesma posi¸cão irá causar um falso positivo [16].

Esta carater´ıstica do ´ındice faz com que a performance se degrade devido a ter de recuperar entradas na tabela que ser˜ao falsos positivos.

GIN

O GIN é um ´ındice invertido. Ao contrário do GiST não produz falsos positivos. No entanto a sua performance depende logaritmicamente com o número de termos existentes no ´ındice [16].

Além disso este tipo de ´ındice não suporta o uso de pesos nos termos, pelo que para utilizar esses pesos é necessário recuperar as entradas novamente.

Os dois tipos de ´ındice apresentam performances diferentes para opera¸cões diferen-tes: Enquanto que os ´ındices GIN são mais rápidos nas pesquisas, os GiST apre-sentam a vantagem no que toca a inser¸cões e atualiza¸cões de entradas. Também há que ter em conta que os ´ındices GIN são duas a três vezes maiores que os GiST [16].

Portanto, os ´ındices GiST funcionam melhor quando os dados são dinâmicos, so-frende inser¸cões ou atualiza¸cões constantes, e se o número de termos andar na ordem dos 100 000. Já se houver uma cole¸cão de termos superior a 100 000 as pesquisas com o GIN serão cerca de três vezes mais rápidas mas será mais lento a atualizar [16].

A t´ecnica de full text searching j´a foi implementada no motor de pesquisa existente no iPortalDoc [18].

(47)

2.5. Ferramentas de Pesquisa

2.5 Ferramentas de Pesquisa

Nesta sec¸c˜ao encontram-se enumeradas algumas ferramentas de pesquisa que foram consideradas para o desenvolvimento de um novo motor de pesquisa para o iPortal-Doc.

2.5.1 Sphinx

O Sphinx ´e um motor de full text search desenhado para integrar com bases de dados e ser facilmente acedido por linguagens de scripting.

´

E poss´ıvel interagir com o Sphinx através de APIs nativas para PHP, Perl, Python, Ruby e Java. Além disso, sendo uma ferramenta focada exclusivamente em full text search tem um desempenho muito otimizado e um elevado número de funcionali-dades, como ordena¸cão por relevância leva em conta rankings de proximidades de termos [19].

Também é importante referir que suporta nativamente intera¸cão com o PostgreSQL, permitindo assim importar os documentos existentes no iPortalDoc.

2.5.2 Apache Lucene

O Lucene ´e uma biblioteca de RI em Java disponibilizada pela Apache Software Foundation que oferece elevada performance e escalabilidade, consumindo poucos recursos [20].

Esta biblioteca possibilita variadas formas de querying, permite configurar o mo-delo ordena¸c˜ao e apresenta tempos de resposta muito baixos e sendo muito mais poderoso no que toca a pesquisa do que o PostgreSQL, visto ser uma ferramenta especializada.

No entanto, não é uma ferramenta trivial de trabalhar, existindo ferramentas de mais alto n´ıvel que constroem sobre o Lucene que serão expostas de seguida.

2.5.3 Apache Solr

O Solr ´e uma plataforma de pesquisa que constr´oi sobre o Apache Lucene, que foi descrito anteriormente.

Como é desenvolvida sobre o Lucene, o Solr permite fazer pesquisas extremamente avan¸cadas e disponibiliza imensas funcionalidades como por exemplo sugestões au-tomáticas ou agrupar resultados pelo valor de determinado campo, que pode ser útil para casos como e-commerce em que o utilizador pode querer filtrar os resultados por intervalo de pre¸co ou pela categoria do produto [21].

(48)

2.6. Aprendizagem Computacional

O Solr permite também que o motor de pesquisa possa escalar com a aplica¸cão, através de clustering de servidores. Desta forma é poss´ıvel aumentar a disponi-bilidade da aplica¸cão (pois existe redundância), a velocidade de pesquisa (pois o ´ındice fica dividido por vários servidores, cada um ficando responsável apenas por

pesquisar uma pequena parte) e balancear a carga dos servidores.

Além disso, das solu¸cões apresentadas, é a única que disponibiliza uma interface de administra¸cão a partir da qual é poss´ıvel configurar o servidor e realizar debugging se necessário.

Esta ferramenta acabou por ser a utilizada na implementa¸cão pois, como se verá, apresentou resultados bastante satisfatórios na fase de testes. Outro fator que aju-dou a decisão foi o facto de na IPBRICK já terem explorado esta solu¸cão breve-mente.

2.5.4 Elasticsearch

Outra ferramenta que foi considerada foi o Elasticsearch. À semelhan¸ca do Solr, o núcleo desta plataforma é também o Apache Lucene.

Como são constru´ıdas com base na mesma ferramenta, o Elasticsearch apresenta, no geral, funcionalidades semelhantes ao Solr, focando-se também em ser uma solu¸cão mais orientada para a cloud [22].

O Elasticsearch aparenta ser uma solu¸cão mais ’chave na mão’ do que o Solr pois quase não necessita de configura¸cão e permite um funcionamento schema-less, ou seja, sem definir a estrutura dos dados a indexar. No entanto não oferece uma forma trivial de indexar os documentos a partir de bases de dados como o PostgreSQL, pelo que por esta razão e também por mostrarem performances semelhantes [23] decidiu-se implementar o motor de pesquisa com o Solr.

2.6 Aprendizagem Computacional

As primeiras tentativas de integrar capacidades de aprendizagem nos computado-res deram-se no in´ıcio da segunda metade do s´eculo XX, com o desenvolvimento de sistemas que iniciavam com um conhecimento pr´oximo de inexistente mas que aumentava com o que era ’experienciado’ pelo sistema [24].

De uma dessas tentativas surgiu o perceptron, um algoritmo para aprendizagem supervisionada de classificadores binários, ou seja, decide se uma entrada pertence a uma classe ou à outra [25]. Come¸caram também a surgir sistemas que aprendiam, por exemplo, a jogar xadrex ou damas [24].

Nos anos 60 o campo de aprendizagem separou-se do de inteligência artificial pois os investigador de aprendizagem computacional come¸caram a dar mais enfâse a métodos númericos enquanto que os investigadores de IA trabalhavam mais com

(49)

2.6. Aprendizagem Computacional

métodos simbólicos [26]. Já nos anos 70 come¸cou a surgir novamente o interesse de explorar aprendizagem computacional dentro do campo de inteligência artificial. Surgiu interesse em automatizar tarefas de extra¸cão de conhecimentos em dominios especificos e também em modelar a aprendizagem humana. Houve também o apa-recimento de diversos novos métodos assim como o reaparecimento de outros que haviam sido abandonados anos antes [26].

Durante os anos 80, o campo de aprendizagem computacional continuou a crescer e os investigadores come¸caram a aperceber-se que os sistemas com capacidade de aprendizagem revelavam muito potêncial e poderiam ter um impacto no mercado. Este campo também se assentou em bases metodológicas mais firmes, dando lugar a experiências sistemáticas e analises teóricas mais precisas do que havia acontecido até à altura [26]. Nos anos 90 o computador Deep Blue, projeto da IBM, conseguiu vencer o então campeão mundial de xadrez, Garry Kasparov [27].

Claramente esta área cresceu bastante desde o seu aparecimento, sendo que hoje a aprendizagem computacional está presente no dia-a-dia das pessoas, sendo poss´ıvel encontrar algoritmos a funcionar por detrás dos motores de pesquisa (como o Go-ogle), nas redes sociais ou até nos smartphones através de assistentes pessoais, por exemplo. Este campo não dá sinais de paragem, dando lugar a projetos inovadores como carros auto-guiados [28].

2.6.1 Introdu¸

c˜

ao `

a Aprendizagem Computacional

A aprendizagem computacional pode ser definida como a área que desenvolve siste-mas que através de informa¸cão externa alteram a sua ’estrutura’ de forma a melhorar a performance no futuro [29]. Pode-se também descrever um sistema de aprendi-zagem como tendo a capacidade de aprender a teoria a partir dos dados que trata, através de processos de inferência, sendo portanto adequado para aplica¸cões onde existem bastantes dados mas sem um padrão reconhec´ıvel [29, 30].

Os sistemas que apresentam capacidade de aprendizagem são geralmente sistemas de inteligência artificial, sendo que a aprendizagem serve para alterar o sistema ou então para sintetizar ou gerar o seu estado inicial [29]. Os computadores apenas executam as instru¸cões que lhes são dadas, sendo que para tal é necessário definir e implementar algoritmos, o que é uma tarefa que consome bastante tempo de pessoal especialmente treinado para isso. Os computadores não possuem a capacidade de aprender a desempenhar uma tarefa a partir de exemplos nem conseguem executar melhor as suas tarefas aprendendo com experiências passadas ou até por observa¸cão. A aprendizagem computacional surge para dar ferramentas aos programadores que permitam criar solu¸cões que tirem partido do cada vez maior volume de informa¸cão e possibilitar aos computadores adaptarem-se e evolu´ırem com a experiência das tarefas que executam [30].

O campo de aprendizagem computacional encontram-se dividido em trˆes grandes focos de investiga¸c˜ao [31]: