Etat de l’art des méthodes d’estimation de mouvement

O vetor dos pesos, ~w, do hiperplano ´e constru´ıdo a partir de uma combina¸c˜ao linear de amostras de treino [35].

Enquanto este algoritmo apresenta bons resultados e ´e mais complexo e poderoso que o naive Bayes e do que o k-nearest neighours, apresenta complexidade adicional e piores resultados no tempo que demora a ser treinado o classificador, para grandes volumes de dados [33].

2.8

Bibliotecas de IA

Nesta sec¸c˜ao encontram-se enumeradas algumas bibliotecas de aprendizagem com- putacional que foram consideradas para o desenvolvimento da inteligˆencia artificial do iPortalDoc.

2.8.1

PyBrain

O PyBrain ´e uma biblioteca de aprendizagem computacional para a linguagem Python. Tem como objetivo oferecer aos utilizadores algoritmos flex´ıveis e pode- rosos para machine learning.

Esta biblioteca cont´em algoritmos que permitem desenvolver redes neuronais, apren- dizagem supervisionada e n˜ao supervisionada [36].

Sendo inteiramente desenvolvida em Python apresenta uma API simples e f´acil de usar, no entanto esta biblioteca j´a n˜ao se encontra a ser desenvolvida ativamente pelo que n˜ao ´e a melhor op¸c˜ao para este projeto.

2.8.2

TensorFlow

O TensorFlow ´e uma biblioteca de aprendizagem computacional muito recente que permite computa¸c˜ao num´erica atrav´es de grafos de fluxo de dados.

Estes grafos descrevem as computa¸c˜oes atrav´es da liga¸c˜ao direcionada de n´os. Os n´os implementam tipicamente opera¸c˜oes matem´aticas, mas podem representar tamb´em pontos de entrada de dados, sa´ıda de resultados ou leitura e escrita de vari´aveis. As liga¸c˜oes entre os n´os descrevem as rela¸c˜oes de entrada/sa´ıda entre eles. Es- tas liga¸c˜oes transportam vetores de dados multi dimensionais com um tamanho dinˆamico [37].

Esta biblioteca apresenta uma API para Python o que a torna acess´ıvel, mas sendo desenvolvida em C++ apresenta uma elevada performace.

O grande ponto favor´avel desta ferramenta ´e que ´e desenvolvida pela Google que ´e atualmente das maiores, sen˜ao a maior empresa especializada em pesquisa e inte-

2.8. Bibliotecas de IA

ligˆencia artificial.

No entanto esta biblioteca ´e muito focada no desenvolvimento de redes neuronais enquanto que se procura uma biblioteca que disponibilize algoritmos de aprendi- zagem computacional que permitam o desenvolvimento de um classificador para o iPortalDoc.

2.8.3

scikit-learn

O scikit-learn ´e um biblioteca em Python que integra variad´ıssimos algoritmos de aprendizagem computacional para problemas supervisionados e n˜ao supervisionados [38].

O principal objetivo desta biblioteca ´e fornecer aos programadores uma camada de abstra¸c˜ao para implementarem solu¸c˜oes que utilizam algoritmos de aprendizagem computacional que possam facilmente ser integradas com outras aplica¸c˜oes, utili- zando uma API em Python com uma boa performance e f´acil de utilizar [38]. A biblioteca ´e desenvolvida em Python mas tamb´em cont´em m´odulos em C++ que fornecem implementa¸c˜oes de referˆencia de certos algoritmos. As implementa¸c˜oes dos algoritmos utilizam estruturas de dados da biblioteca numpy que ´e conhecida pela sua eficiˆencia [38].

Esta biblioteca acabou por ser a escolha para a implementa¸c˜ao da inteligˆencia ar- tificial no motor de pesquisa do iPortalDoc por ser a mais completa e pela camada de abstra¸c˜ao que fornece, diminuindo o custo de manuten¸c˜ao no futuro.

Cap´ıtulo 3

Caracteriza¸c˜ao do Problema

3.1

Defini¸c˜ao do Problema

Como foi poss´ıvel ver no primeiro cap´ıtulo deste texto, o problema reside no facto de que atualmente o motor de pesquisa existente no iPortalDoc apresentar resultados que por vezes n˜ao s˜ao ´otimos, com um tempo de resposta elevado.

Sendo o iPortalDoc uma solu¸c˜ao focada no mercado empresarial, onde cada vez mais se abandona o formato em papel em prol do formato digital, as bases de dados contˆem cada vez um maior n´umero de documentos, o que leva inevitavelmente a uma degrada¸c˜ao do desempenho do motor de pesquisa existente. No caso da IPBrick, a base de dados do seu iPortalDoc interno cont´em cerca de cinco milh˜oes de documentos, o que mostra que a quantidade de informa¸c˜ao a ser pesquisada ´e de facto bastante.

Uma forma de aumentar a precis˜ao dos resultados obtidos ´e utilizar a op¸c˜ao de pes- quisa avan¸cada presente no iPortalDoc, que d´a aos utilizadores a possibilidade de pesquisar os documentos pelo seu c´odigo ´unico (retornando aquele documento espe- cificamente) ou atrav´es da aplica¸c˜ao de filtros como tipo de documento, as datas de inser¸c˜ao ou elabora¸c˜ao, entidade associada, entre outros. Embora esta solu¸c˜ao apre- sente resultados melhores que a pesquisa simples, ´e necess´ario um esfor¸co adicional por parte do utilizador para configurar a pesquisa, al´em de que continua a continua a ser necess´ario esperar um tempo consider´avel para obter os resultados.

3.2

Testes realizados

Para melhor compreender o problema existente no motor de pesquisa do iPortalDoc foram realizados alguns testes que s˜ao apresentados nesta sec¸c˜ao.

Durante a realiza¸c˜ao destes testes reparou-se que embora o iPortalDoc tivesse pre- parado para realizar pesquisas com as fun¸c˜oes de full text search, estas estavam a

3.2. Testes realizados

ser realizadas com o operador ILIKE, que apresenta resultados muito piores.

3.2.1

Tempo de Resposta

Como j´a foi referido anteriormente, o grande ponto negativo do motor de pesquisa do iPortalDoc ´e o tempo que este demora a retornar os resultados. Para ser poss´ıvel compreender a dimens˜ao deste problema foi necess´ario realizar algumas pesquisas na aplica¸c˜ao.

Para efeitos de estat´ısticas, o iPortalDoc guarda os registos de todas as pesqui- sas efetuadas numa tabela da BD. Dessa tabela extra´ıram-se os dez termos mais pesquisados, que podem ser observados na tabela 3.1.

Pesquisa Ocorrˆencias

sodecia 22 contact center 19 vdi 16 jap 14 phc 14 mecofarma 13 manual 12 hotspot 12 callmanager 11 iportaldoc 11

Tabela 3.1: Termos mais pesquisados

Com estes dados, foram realizadas pesquisas para cada um dos termos, com o ob- jetivo de obter o tempo de resposta para cada um, sendo s´o nessa altura poss´ıvel perceber realmente a lacuna que existe no iPortalDoc relativamente `a pesquisa de documentos. Os testes que s˜ao apresentados na tabela 3.2 foram realizados numa m´aquina acabada de arrancar, sem qualquer tipo de caches.

Pesquisa Tempo (minutos)

sodecia 9,94 contact center 3,53 vdi 4,03 jap 3,97 phc 3,92 mecofarma 3,34 manual 6,40 hotspot 3,48 callmanager 3,36 iportaldoc 5,25

3.2. Testes realizados

´

E poss´ıvel verificar, pelos resultados obtidos, que os tempos de resposta do iPortal- Doc s˜ao absurdamente elevados, verificando-se uma m´edia de 4,74 minutos. Isto leva a uma quebra da produtividade dos utilizadores do software, pelo que se torna imperativo resolver este problema.

Para perceber o que leva a estes tempos de resposta t˜ao elevados foi analisado o planeamento de uma query, que procura pelo termo ’manual iportaldoc’, obtido atrav´es de um EXPLAIN.

Na Figura 3.1 podemos ver a opera¸c˜ao mais lenta e com maior custo da query.

Figura 3.1: Opera¸c˜ao mais demorada da pesquisa com ILIKE

Atrav´es da an´alise dos v´arios passos da query, ´e poss´ıvel perceber que grande parte do tempo ´e gasto com as opera¸c˜oes ILIKE, sendo que juntas consomem no total 4,56 minutos dos 5.2 minutos que demorou a correr a query. Isto porque nessas opera¸c˜oes s˜ao realizados scans sequenciais na tabela documento, ou seja, a tabela ´

e percorrida inteiramente, para se encontrar todos os documentos que satisfa¸cam a pesquisa.

Fazendo a mesma query, mas desta vez utilizando as fun¸c˜oes de full text search, a opera¸c˜ao mais demorada ´e a que se pode observar na Figura 3.2, gastando 36,3 se- gundos num total de 52,94 segundos. Esta enorme diferen¸ca nos tempos de execu¸c˜ao deve-se a neste caso j´a serem usados os ´ındices para realizar a pesquisa de texto. Tamb´em foram realizados os mesmos testes que com o ILIKE, fazendo pesquisas com os 10 termos mais populares. Os resultados s˜ao apresentados na tabela 3.3.

Observando a tabela, verifica-se um tempo de resposta m´edio `a volta dos 1,40 minutos. Embora sejam tempos de resposta mais de 3 vezes melhor que os que se obtˆem com o ILIKE, continuam a ser resultados muito acima do aceit´avel, o que ´e

3.2. Testes realizados

Figura 3.2: Opera¸c˜ao mais demorada da pesquisa com to_tsquery()

Pesquisa Tempo (segundos)

sodecia 204,49 contact center 84,63 vdi 87,40 jap 86,86 phc 62,35 mecofarma 47,71 manual 129,75 hotspot 40,89 callmanager 40,35 iportaldoc 59,21

Tabela 3.3: Tempos de resposta para os termos mais pesquisados (full text search)

agravado pelo facto do utilizador n˜ao ter qualquer tipo de feedback relativamente ao progresso da pesquisa [39].

Conv´em sublinhar que estes tempos foram obtidos em ambiente de teste, ou seja, cada pesquisa correu isoladamente, pelo que em ambiente de produ¸c˜ao, com m´ultiplos utilizadores a utilizarem a aplica¸c˜ao concorrentemente, poder´a levar a uma de- grada¸c˜ao da performance ainda maior.