UNIVERSIDADE FEDERAL DO RIO GRANDE DO SULINSTITUTO DE INFORMÁTICA

CURSO DE BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO

DIEGO PEREIRA

Uma Aplicação em Sistemas deRecomendação: Sistema de Recomendação

para Pacotes GNU/Linux

Trabalho de Conclusão apresentado comorequisito parcial para a obtenção do grau deBacharel em Informática

Profa. Dra. Mara AbelOrientadora

Porto Alegre, junho de 2007

CIP – CATALOGAÇÃO NA PUBLICAÇÃO

Pereira, Diego

Uma Aplicação em Sistemas de Recomendação: Sistemade Recomendação para Pacotes GNU/Linux / Diego Pereira. –Porto Alegre: PPGC da UFRGS, 2007.

43 f.: il.

Trabalho de Conclusão – Universidade Federal do Rio Grandedo Sul. Curso de Bacharelado em Ciência da Computação,Porto Alegre, BR–RS, 2007. Orientadora: Mara Abel.

1. Sistemas de recomendação. 2. Sistemas híbridos. 3. Linux.4. Pacotes. 5. Distribuição de software. I. Abel, Mara. II. Título.

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SULReitor: Prof. José Carlos Ferraz HennemannPró-Reitor de Coordenação Acadêmica: Prof. Pedro Cezar Dutra FonsecaPró-Reitora de Pós-Graduação: Profa. Valquíria Linck BassaniDiretor do Instituto de Informática: Prof. Philippe Olivier Alexandre NavauxCoordenador do PPGC: Prof. Carlos Alberto HeuserBibliotecária-chefe do Instituto de Informática: Beatriz Regina Bastos Haro

teste123 — TESTE123

AGRADECIMENTOS

Agradeço ao LATEX por não ter vírus de macro. . .

SUMÁRIO

LISTA DE ABREVIATURAS E SIGLAS . . . . . . . . . . . . . . . . . . . . 6

LISTA DE FIGURAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

RESUMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 TÉCNICAS PARA SISTEMAS DE RECOMENDAÇÃO . . . . . . . . . 122.1 Filtragem Baseada em Conteúdo (FBC) . . . . . . . . . . . . . . . . . . 132.2 Filtragem Colaborativa (FC) . . . . . . . . . . . . . . . . . . . . . . . . 142.3 Mineração de dados (MD) . . . . . . . . . . . . . . . . . . . . . . . . . . 162.4 Raciocínio Baseado em Casos (RBC) . . . . . . . . . . . . . . . . . . . . 172.5 Sistemas Híbridos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.6 Avaliação de Sistemas de Recomendação . . . . . . . . . . . . . . . . . . 20

3 GERENCIAMENTO E RECOMENDAÇÃO DE PACOTES DEBIAN . . 233.1 Dpkg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2 APT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.3 Popularity Contest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.4 Debtags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.5 Popsuggest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4 DEBOMMENDER: UM SISTEMA DE RECOMENDAÇÃO DE PACOTES 294.1 Subsistema de Recomendação . . . . . . . . . . . . . . . . . . . . . . . . 304.2 Subsistema de Monitoramento. . . . . . . . . . . . . . . . . . . . . . . . 31

5 AVALIAÇÃO DO SISTEMA COM DADOS DE USUÁRIOS . . . . . . . 335.1 Descrição do Experimento . . . . . . . . . . . . . . . . . . . . . . . . . . 335.2 Resultados e Análise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

LISTA DE ABREVIATURAS E SIGLAS

FBC Filtragem Baseada em Conteúdo

FC Filtragem Colaborativa

GNU GNU’s Not Unix

LISTA DE FIGURAS

Figura 2.1: Ciclo de um sistema de RBC . . . . . . . . . . . . . . . . . . . . . . 17

Figura 3.1: Entrada do pacote python na base de dados de pacotes de um sistemaDebian. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Figura 3.2: Exemplo de entradas de um arquivo de fontes de pacotes (repositórios) 25Figura 3.3: Exemplo de expressão de busca usando marcas do vocabulário debtags 26

Figura 4.1: Visão geral do sistema de recomendação de pacotes Debian . . . . . 30Figura 4.2: Entrada de um pacote recomendado na lista gerada pelo servidor de

recomendações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Figura 4.3: Apresentação da recomendação representada pelos dados mostrados

na figura 4.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Figura 5.1: Resultados para o componente baseado em conteúdo . . . . . . . . . 34Figura 5.2: Resultados para o componente colaborativo . . . . . . . . . . . . . . 35Figura 5.3: Resultados para o algoritmo híbrido . . . . . . . . . . . . . . . . . . 35Figura 5.4: Resultados para filtragem baseada em conteúdo usando marcas do

projeto debtags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Figura 5.5: Resultados para filtragem baseada em conteúdo usando marcas com-

binada a filtragem colaborativa . . . . . . . . . . . . . . . . . . . . . 37Figura 5.6: Cobertura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

RESUMO

Com o aumento em popularidade da Internet, o acesso aos meios de comunicação eàs informações disseminadas por eles tornou-se cada vez mais fácil. No entanto, issotrouxe como conseqüência a sobrecarga de informação que notamos hoje em dia. Pode-mos identificar este fenômeno em muitos dos segmentos da sociedade, tais como a mídia,na forma de notícias, no meio acadêmico, na forma de publicações e no comércio, naforma de oferta de produtos e serviços, por exemplo.

Com o crescimento dos movimentos de software livre e aberto, identificamos uma ten-dência similar em relação às distribuições GNU/Linux, que vêem cada vez mais o númerode pacotes de software disponíveis em ascendência. Isto torna cada vez mais difícil, e, nofuturo, impraticável, que o usuários desses sistemas tenham um conhecimento amplo detodo software disponível, sem que pelo menos gastem um esforço considerável.

Uma forma de minimizar este esforço seria a criação de um sistema de recomendaçãode pacotes GNU/Linux. O objetivo de um sistema de recomendação é identificar e sugeriraos usuários itens que sejam de seu interesse, dentre uma vasta gama de itens disponíveis.

Assim, o objetivo deste trabalho é aplicar técnicas já exploradas anteriormente emsistemas de recomendação ao contexto de recomendações de pacotes de distribuiçõesGNU/Linux. Além disso, utilizamos dados de usários reais de forma a medir o quanto osistema desenvolvido foi capaz de atingir o objetivo proposto.

Palavras-chave: Sistemas de recomendação, sistemas híbridos, Linux, pacotes, distribui-ção de software.

ABSTRACT

An Application in Recommender Systems: Recommender System for GNU/LinuxPackages

Coming soon ...

Keywords: recommender systems, hybrid systems, Linux, packages, software distribu-tion.

10

1 INTRODUÇÃO

Com o avanço dos sistemas de comunicação e, principalmente, com o surgimento daInternet, a quantidade de informações a que temos acesso vem aumentando cada vez mais.Como resultado, acabamos nos confrontando com o problema de selecionar dentre essasinformações quais realmente são de nosso interesse e de valia para nosso dia-a-dia.

Nas últimas duas décadas vimos também o surgimento e crescente adoção de umanova filosofia de desenvolvimento de software, que se apóia firmemente nessa nova redede comunicação: o software livre. O software livre é uma resposta à tentativa de algumasinstituições e empresas de restringir o acesso ao código fonte dos programas, geralmentemotivadas por razões de mercado, suprimindo a prática, antes comum, do compartilha-mento desses códigos fonte (UNESCO, 2006). O software livre traça sua origem e semistura com o surgimento dos sistemas Unix, passando pelo sistema operacional GNU,pelo surgimento subseqüente do Linux e, mais recentemente, das distribuições GNU/Li-nux (FSF, 2006).

Distribuições GNU/Linux (ou, simplesmente, distribuições) são sistemas operacio-nais completos, compostos sempre no mínimo pelo kernel Linux mais as bibliotecas eaplicativos GNU, que rodam sobre este kernel. Uma das contribuições das distribuiçõesfoi a criação de sistemas que facilitam a instalação e gerenciamento dos softwares quecompõem o sistema operacional: os chamados sistemas de gerenciamento de pacotes.Através destes sistemas as distribuições organizam e disponibilizam todo o software queas compõem: desde o kernel do sistema operacional, passando pelas bibliotecas e aplica-tivos básicos que caracterizam um sistema padrão Unix a sistemas de gerenciamento dejanelas, aplicativos de processamento de texto, browsers, e outros.

Com o crescimento da chamada comunidade de software livre como um todo, e, maisespecificamente, da comunidade Linux, houve também o crescimento da quantidade depacotes de software disponível nas distribuições. Um exemplo é a distribuição Debian(DEBIAN, 2006), cujo número de pacotes em sua primeira liberação oficial (1.1), emjunho de 1996, foi de 474 pacotes, enquanto que a última liberação oficial (4.0), em abrilde 2007, incluiu mais de 18200 pacotes. Comparada à liberação anterior (3.1), de junhode 2005, houve uma inclusão de 6500 pacotes.

Assim, torna-se cada vez mais difícil para os usuários terem conhecimento de todosos softwares inclusos em uma distribuição que lhes poderiam ser úteis. Desta forma, osusuários não são capazes de facilmente usufruir do potencial pleno das distribuições. Parafacilitar o uso e aumentar ainda mais o benefício que usuários das distribuições derivamdas mesmas, propomos aqui o uso de um sistema de recomendação de pacotes.

Sistemas de recomendação são quaisquer sistemas que têm por objetivo sugerir a usuá-rios itens de seu interesse em meio a uma gama consideravelmente grande de itens (TOR-RES, 2004). Esses itens podem variar desde informações na Internet, como notícias em

11

newsgroups ou paginas web, passando por bens de consumo, como DVD’s ou livros, aaté mesmo, software.

O objetivo deste trabalho é o desenvolvimento de um sistema de recomendação depacotes para distribuições Linux, usando abordagens já disponíveis para sistemas de re-comendação. Esperamos que o sistema ajude tanto usuários intermediários a encontrarpacotes de software de que não têm conhecimento quanto a usuários que se encontrammigrando para Linux, neste caso diminuindo a curva de aprendizado.

O sistema tem como foco a distribuição Debian. São duas as razões para a esco-lha desta distribuição: i) a distribuição Debian é bastante difundida e representativa nomundo Linux e ii) existem várias distribuições derivadas desta, usando o mesmo sistemade gerenciamento de pacotes, e assim, tornando fácil o porte do sistema de recomendaçãoresultante para essas distribuições derivadas.

Para a implementação do sistema, foram usadas bibliotecas e componentes que têmlicenças livres ou abertas, tais como a biblioteca Taste, para recomendações baseadas emfiltragem colaborativa e o pacote popularity-contest (POPCON, 2006), que foi modificadopara o monitoramento da utilização de pacotes no sistema do usuário.

No próximo capítulo será apresentado um breve histórico dos sistemas de recomenda-ção e feita uma revisão das abordagens mais tradicionalmente encontradas na literatura.Analisamos as ferramentas atualmente disponíveis para a busca e instalação de pacotesem sistemas Debian e derivados no capítulo 3. No capítulo 4 é proposta uma soluçãopara a recomendação de pacotes Linux, baseada em um método híbrido. No capítulo 5são documentados os experimentos realizados e a avaliação dos resultados. No capítulo6 são apresentadas considerações sobre sitemas de recomendação no contexto de pacotesde software e a conclusão.

12

2 TÉCNICAS PARA SISTEMAS DE RECOMENDAÇÃO

Sistemas de recomendação vêm sendo aplicados desde a década passada em diversosdomínios, usando técnicas variadas para a geração das recomendações. Muitas dessastécnicas são herdadas ou evoluíram a partir das existentes nos sistemas de recuperação deinformação. Neste capítulo, apresentaremos um histórico dos sistemas de recomendação,seguido de uma abordagem das principais técnicas usadas no desenvolvimento destessistemas.

Um dos primeiros sistemas de recomendação foi o Tapestry (GOLDBERG et al.,1992), da Xerox Palo Alto. O propósito do Tapestry é a seleção de documentos de e-mail.Nele, os usuários podem criar regras (filtros), que modelam suas preferências pessoais.Essas regras são então comparadas com o conteúdo dos documentos, e aqueles que asatenderem são então enviados aos respectivos usuários. Em sistemas de recomendação,abordagens como essa são conhecidas como Filtragem Baseada em Conteúdo (FBC).

Além disso, o Tapestry possibilita aos usuários associar anotações aos documentos,expressando se gostaram ou não dos mesmos. Isso possibilita que usuários que tenhamgostos parecidos acessem os documentos anotados positivamente uns dos outros, colabo-rando na filtragem das mensagens. Essa técnica, nomeada Filtragem Colaborativa (FC),é muito usada até hoje. Por basear-se em mais de uma técnica diferente (FC e FBC), oTapestry pertence ao grupo de sistemas de recomendação ditos híbridos.

O GroupLens (RESNICK et al., 1994), da Universidade de Minnesota tem por ob-jetivo a recomendação de notícias a usuários da rede Usenet, usando apenas FiltragemColaborativa. Uma diferença crucial em relação à Filtragem Colaborativa implementadano Tapestry, é que neste os usuários precisam explicitar de quais outros gostariam dereceber recomendações, manualmente criando "vizinhanças". Já no GroupLens essas vi-zinhanças são criadas automaticamente através de algoritmos de correlação, baseando-seem avaliações numéricas das notícias fornecidas por cada um dos usuários do sistema.

O Krakatoa (KAMBA; BHARAT; ALBERS, 1995) é um jornal online, que tem comocaracterística a seleção de notícias personalizadas para seus usuários/leitores. A perso-nalização é feita principalmente através da criação de um perfil do usuário, contendo umvetor dos termos presentes nas notícias lidas e avaliadas por ele. Termos pertencentesa notícias avaliadas positivamente ganham pesos maiores em relação aos outros termos.A recomendação é feita através da comparação entre os termos do perfil do usuário comos termos componentes da notícia. Portanto, Krakatoa usa uma abordagem tipicamentebaseada em conteúdo.

Muitas outras técnicas já foram usadas no contexto dos sistemas de recomendação,com destaque para a mineração de dados (MD). Nela, as regras associativas (AGRAWAL;IMIELINSKI; SWAMI, 1993) extraídas de bases de dados existentes são usadas paraa geração das recomendações (LIN; ALVAREZ; RUIZ, 2000). Raciocínio baseado em

13

casos também pode ser usado para recomendar itens (AKTAS et al., 2004). Podemostambém citar outras abordagens menos convencionais, como ontologias (MIDDLETON;ROURE; SHADBOLT, 2001) e lógica fuzzy (SURYAVANSH; SHIRI; MUDUR, 2005),por exemplo. A seguir, detalharemos as abordagens mais tradicionais, e, no final destecapítulo, apresentaremos algums métodos para a avaliação de sistemas de recomendação.

2.1 Filtragem Baseada em Conteúdo (FBC)

A filtragem baseada em conteúdo emprega a comparação entre o conteúdo dos itens,de forma a recomendar itens parecidos aos que o usuário gostou no passado. Essa aborda-gem tem suas origens nas técnicas empregadas em sistemas de recuperação de informação(TORRES, 2003).

Um algoritmo bastante usado na implementação da FBC é conhecido como TF-IDF(inglês para Term Frequency – Inverse Document Frequency). Proposto como forma deavaliar similaridade entre textos, o que o TF-IDF mede é a importância de um certo termode um documento levando em consideração uma coleção ou corpo de documentos. Paratanto, o algoritmo se vale de dois coeficientes, um sendo a freqüência de aparições dotermo no documento específico (TF), ou seja, uma medida do quão importante o termo épara o documento em questão, e o outro uma medida da raridade do termo no corpo detodos os documentos (IDF), ou seja, o quão característico o termo é para os documen-tos nos quais aparece. O peso TF-IDF de um termo de um documento é obtido entãomultiplicando-se estes dois coeficientes.

Podemos então avaliar o grau de similaridade entre dois documentos a partir da se-melhança entre os coeficientes TF-IDF dos termos que os compõem. Uma forma de ava-liar tal similaridade é considerar cada documento como um vetor, sendo cada termo umcomponente nesses vetores. Poderíamos então usar a chamada similaridade pelo cossenocomo nossa medida de similaridade entre dois documentos (2.1).

cos(�u,�v) =�u ◦ �v

‖ �u ‖‖ �v ‖(2.1)

Um valor de 0 indicaria total dissimilaridade (i.e. vetores ortogonais), enquanto queum valor 1 implica em similaridade alta (não necessariamente a igualdade entre os do-cumentos). Esta abordagem é conhecida como vector space model (modelo do espaçovetorial) e foi introduzida em (BUCKLEY, 1985).

A medida de similaridade entre pacotes pode ser usada como peso da avaliação dopacote feita pelo usuário. Obteríamos uma predição, ou estimativa, do valor que o usuáriodaria ao documento candidato à recomendação.

A princípio, a FBC pode ser aplicada a qualquer domínio no qual se deseja gerarrecomendações, mas na prática ela costuma ser usada em domínios cujos itens tenhamquantidade considerável de informação armazenada em forma textual. Isso pois em al-guns domínios a comparação de conteúdo dos itens é difícil ou até mesmo inviável.

Além desta limitação, a FBC também sofre com outros problemas, como a super-especialização, ou seja, itens que podem ser do interesse do usuário mas não são similaresaos que ele já consumiu provavelmente nunca serão recomendados, limitando a abrangên-cia das recomendações.

Outro problema da FBC é que ela não tem como avaliar aspectos como a qualidade dositens a serem recomendados: um pacote que apresente muitos bugs teria tanta chance deser recomendado quanto um ostensivamente testado, se suas descrições forem parecidas.

14

A FBC também aparece em sistemas híbridos, muitas vezes associada a uma técnicade Filtragem Colaborativa, uma vez que essas duas técnicas quando combinadas tendema compensar as desvantagens uma da outra, como podemos ver em (BALABANOVI;SHOHAM, 1997).

2.2 Filtragem Colaborativa (FC)

A filtragem colaborativa se baseia em correlação entre usuários para gerar recomenda-ções. Assim, podemos dizer que um sistema que usa FC leva em consideração o compor-tamento dos usuários. Por levar em conta o fator humano, a FC incorpora característicasinteressantes, que de outra forma não seriam facilmente implementadas em um sistemacomputacional. Atualmente, o desenvolvimento e a aplicação de técnicas de FC ocupamum espaço de destaque na pesquisa na área de sistemas de recomendação.

Existem muitos métodos já usados para a implementação da filtragem colaborativa,mas os mais proeminentes são os baseados na formação de uma vizinhança entre os usuá-rios (SARWAR et al., 2001).

Nestas abordagens, faz-se primeiro uma correlação entre usuários, ou seja, a constru-ção da vizinhança propriamente dita. Em seguida, é feita uma predição do valor que ousuário alvo da recomendação daria a cada item candidato a recomendação. Esta prediçãobaseia-se nos valores das avaliações que os usuários vizinhos do usuário alvo deram aorespectivo item. Predições são então usadas para fazer a recomendação dos itens propria-mente dita.

Existem também sistemas colaborativos que fazem correlação item a item, ao invésde usuário a usuário, como vimos acima. Nestes sistemas, a proposta é que se dois itenstêm distribuições semelhantes de avaliações sobre a dimensão de usuários, isto indicauma similaridade entre estes dois itens. Se um usuário possuir um item que seja bastantesimilar a outro com base nesta medida, este segundo item possivelmente representariauma boa recomendação. Por questão de simplicidade, manteremos o enfoque em sistemasque usam correlação entre usuários. Entretanto, muitos dos métodos aplicados para acorrelação entre usuários também se aplicam a correlação entre itens.

Uma forma de fazer correlações entre os usuários (i.e. formar a vizinhança) é atravésda correlação de Pearson (RESNICK et al., 1994).

rx,y =cov( �ux, �uy)

σxσy

(2.2)

Este método baseia-se em medidas de covariância entre os valores das avaliações decada usuário. Além disso, a correlação de Pearson atenua as diferenças entre usuáriosque tendem a usar mais as extremidades da escala de avaliação dos que tendem a avaliarmais “moderadamente” os itens. A correlação de Pearson retorna valores entre -1 e 1,indicando correlação inversa com valores perto de -1 (i.e. usuários tendem a discordarnas avaliações), correlação fraca com valores perto de 0, e alta correlação direta comvalores perto de 1, indicando que os usuários costumam concordar nas avaliações.

Uma variação do algoritmo de Pearson é o chamado algoritmo de Pearson restrito.Nesta variação, ao invés de sempre calcular as médias das avaliações dos usuários, que sãonecessárias tanto no cálculo da covariância quanto dos desvios-padrão, é usado o pontomédio da escala das avaliações, que é constante. Assim, poupa-se o trabalho de semprese calcular esta média, o que melhora a performance, mas potencialmente prejudica aqualidade das recomendações.

15

Outra forma de fazermos a correlação entre usuários seria considerar a representaçãode suas avaliações no sistema como vetores (as colunas da matriz apresentada no capítuloanterior). Teríamos assim, uma situação similar à apresentada na avaliação de similari-dade entre os descrições dos pacotes, mas ao invés dos vetores terem como componen-tes termos, as componentes seriam os valores das avaliações para cada pacote. Assim,poderíamos lançar mão da similaridade pelo cosseno como forma de medir semelhançatambém entre usuários.

A geração das predições pode ser feita através de uma média ponderada entre todas asavaliações feitas pelos usuários vizinhos, independente de qual método tenha sido usadopara a geração das vizinhanças. O peso de cada avaliação na média seria o fator decorrelação do usuário que a fez com o usuário alvo. Assim, o valor da predição seria dadopela seguinte equação (RESNICK et al., 1994):

pa,i = r̄a +

∑n

u=1(ru,i − r̄u) · wa,u∑n

u=1wa,u

(2.3)

Quanto às vantagens da FC especificamente em relação à FBC, temos que a FC nãoapresenta restrições práticas quanto aos tipos de dados que compõem o conteúdo dos itens,uma vez que a FC não leva em consideração o conteúdo dos mesmos. Outra vantagem é aausência do problema de super-especialização das recomendações: itens que não estejamdiretamente relacionados com os do perfil do usuário alvo das recomendações podemainda assim ser recomendados. Também temos que a FC leva em conta fatores comoqualidade dos itens e o gosto do usuário, por basear-se na avaliação dos itens por partedos usuários mais próximos ao usuário alvo.

Segundo (TORRES, 2004) as limitações da FC são identificadas em três itens, conhe-cidos na literatura como first-rater problem, startup problem e sparcity problem.

O first-rater problem, ou problema do primeiro avaliador, consiste no fato de queenquanto um item não receber avaliações por nenhum usuário, ele não pode ser recomen-dado, pois não estará relacionado a nenhum perfil.

O startup problem diz respeito ao estado inicial do sistema, quando existem aindapoucos usuários. Com menos usuários, a dificuldade em encontrar similaridades entre osperfis é bemmaior e, conseqüentemente, a geração de recomendações perde em qualidadeou é até mesmo inviabilizada.

O sparcity problem consiste na dispersão dos itens avaliados pelo usuário em relaçãoa todos os itens pertencentes ao domínio do sistema de recomendação. A proporção deitens avaliados por um usuário específico em relação a itens não avaliados por ele tende aser muito pequena. Isso é devido à própria natureza dos sistemas de recomendação, queleva sua aplicação a ser feita em domínios com quantidade de informação muito grande,ou seja, grande número de itens, o que torna impraticável a avaliação de uma parcelasignificativa de itens por parte dos usuários.

Uma questão prática que surge em muitas das implementações que fazem uso da FCé a escalabilidade dos sistemas resultantes. Quanto mais usuários e itens são adicionadosao sistema, cresce o consumo de recursos utilizados, sejam estes tempo de processamentoou espaço em memória usados na geração das recomendações, dependendo da imple-mentação. Assim, encontramos trabalhos na área abordando este problema, como em(MILLER; KONSTAN; RIEDL, 2004) e (SARWAR et al., 2001), por exemplo.

16

2.3 Mineração de dados (MD)

A mineração de dados (MD) é uma etapa particular de um processo maior conhecidocomo descoberta de conhecimento em bancos de dados (DCBD). A DCBD é definidacomo um processo de identificação de padrões não-triviais, previamente desconhecidos epotencialmente úteis a partir dos dados armazenados em um banco de dados (FAYYAD,1997).

O papel da MD dentro do processo de DCBD é a descoberta dos padrões propria-mente dita. Estes geralmente são expressos na forma de regras associativas (AGRAWAL;IMIELINSKI; SWAMI, 1993).

Em termos práticos, podemos ilustrar estes padrões, ou as regras que os representam,na forma de afirmações como: “20 % dos consumidores que compram fraldas tambémcompram cerveja” ou “90% dos consumidores que compram fraldas e cerveja são dosexo masculino” ou até mesmo “80% dos consumidores que compram fraldas e cervejaem uma compra, voltam para comprar carne e carvão na sexta-feira”, por exemplo.

Com base neste tipo de informação, é possível a tomada de várias decisões relaci-onadas a um negócio. Uma possibilidade seria a disposição de prateleiras baseada naassociação entre produtos (e.g. fraldas e cerveja), divulgação direcionada de uma promo-ção (e.g. quando o cliente comprar fraldas e cerveja, informar-lhe de uma promoção decarnes que ocorrerá na próxima sexta-feira), e assim por diante. Desta forma, é possívelatingir um certo nível de personalização no atendimento que pode ser vantajoso tanto parao cliente quanto para o comerciante.

No contexto da mineração de dados, o domínio é modelado como um conjunto I, deitens, e um conjunto D, denominado base de dados de transações. Cada transação T deD é um subconjunto de I, representando quais itens se encontram presentes na transação.A partir deste modelo são construídas as regras associativas que representam os padrõesidentificados na base de transações.

As regras associativas são compostas por uma implicação, uma confiança, e um su-porte. A implicação associa um conjunto de itens X a um conjunto de itens Y, tal que X eY são disjuntos e ambos contidos em I. Uma regra X→ Y indica que a presença dos itensde X em uma transação T tende a implicar na presença dos itens pertencentes a Y nestatransação.

O suporte de uma regra é a proporção de transações que contêm todos os elementos,tanto de X quanto de Y, em relação ao universo de transações, dando uma medida de rele-vância estatística da regra. Já a confiança de uma regra mede a quantidade de transaçõesque contêm X e Y em relação a todas que contêm X, dando assim uma medida do quãoprecisa é a regra (AGRAWAL; IMIELINSKI; SWAMI, 1993).

No contexto dos sistemas de recomendação, as regras associativas podem ser usadaspara expressar tanto as pré-condições que devem ser identificadas nos perfis dos usuários,através dos antecedentes das regras, quanto os itens que devem ser recomendados, atravésdos conseqüentes. Além disso, através da medida de confiança da regra, é possível ordenaras regras que têm mais chance de ter importância para o usuário.

Os métodos mais tradicionais para a geração de regras associativas com base nas tran-sações geralmente consideram apenas as regras que têm um suporte e um nível de con-fiança maiores que certos limiares mínimos, desprezando as demais (AGRAWAL; IMIE-LINSKI; SWAMI, 1993). Estes limiares são geralmente escolhidos pelo desenvolvedordo sistema.

Um dos problemas com a MD torna-se então a avaliação de limiares mínimos adequa-dos para o suporte e a confiança das regras, de forma a gerar regras que sejam aplicáveis

17

a um bom número de casos e ao mesmo tempo sejam interessantes no domínio em que atécnica está sendo aplicada . Em certos casos, podemos ter que para valores relativamenteelevados para o suporte mínimo, tenhamos um número adequado de regras, mas com umvalor de confiança resultante baixo. Desta forma, possivelmente sejam perdidas muitasregras que teriam um valor mais significativo para certos nichos de usuários, com valoresde confiança mais elevados, mas com um suporte menor.

De maneira inversa, se forem usados limiares baixos, podem ser geradas, juntamentea regras úteis, muitas regras que tenham pouca relevância para a aplicação em questão.Alguns trabalhos abordam estes problemas de formas diferentes, como propondo novasmedidas para a geração de regras (AGGARWAL; YU, 1998) (BAYARDO; AGRAWAL;GUNOPULOS, 1999) ou métodos automatizados para a avaliação do suporte e confiançamínimos (LIN; TSENG, 2006), por exemplo.

2.4 Raciocínio Baseado em Casos (RBC)

Raciocínio baseado em casos é uma metodologia de solução de problemas que baseia-se em conhecimento adquirido anteriormente e armazenado na forma de casos (LO-RENZI; RICCI, 2005). Um caso é composto por uma descrição de um problema associadaà solução correspondente. Desta forma, é possível para um sistema de RBC comparar adescrição de um novo problema com os já existentes na sua base de casos, propondo umasolução já existente, ou adaptando uma das soluções existentes ao novo caso. Além disso,é possível ao sistema reter uma solução adaptada em um novo caso na base, fazendo comque o sistema aprenda com o tempo.

Devido à capacidade de memorizar novos casos, derivados dos novos problemas edas soluções adaptadas, o funcionamento dos sistemas de RBC é cíclico, e dividido ti-picamente em quatro etapas principais: recuperação, reutilização, adaptação e retenção(AAMODT; PLAZA, 1994), como ilustrado na figura 2.1.

Figura 2.1: Ciclo de um sistema de RBC

A etapa de recuperação ocorre logo após um problema é apresentado ao sistema. Nestaetapa, o sistema busca na base de casos os casos cujas descrições do problema são simi-lares à do problema apresentado como entrada.

O segundo passo, a reutilização, avalia se as soluções dos casos recuperados podem

18

ser aplicadas ao novo problema, integralmente, ou se partes das soluções se aplicam.A reutilização pode ser uma simples cópia das soluções dos casos presentes na base, ouestas podem ser adaptadas com base nas propriedades do novo problema apresentado pelousuário.

Na etapa de revisão, a solução proposta é testada, e reparada em caso de falha. Tantoa avaliação e o reparo de uma solução insatisfatória podem requerer intervenção humanadireta, dependendo do domínio do sistema de RBC.

Na etapa de retenção, o novo problema pode ser associado à solução encontrada, ge-rando assim um novo caso, que pode ser armazenado na base de casos para uso posterior.

Por ser ummodelo bastante genérico, o raciocínio baseado em casos pode ser aplicadoa uma vasta gama de problemas, desde que a implementação de cada uma das etapas sejamodelada para atender a aplicação em particular de forma eficaz.

Por exemplo, em um sistema hospitalar que recupera casos em uma base de dados con-tendo todos atendimentos médicos feitos no hospital, a recuperação poderia ser feita combase na similaridade de sintomas e dados do paciente. Uma abordagem mais sofisticadase faria necessária em um sistema que auxilia na distribuição de pessoas em um ambientede trabalho, por exemplo, onde uma árvore representando a hierarquia da empresa e umarepresentação do espaço físico disponível serviriam como a entrada.

Assim, os métodos usados em cada uma das etapas devem se adaptar ao contextoda aplicação à qual pertencem. Um estudo detalhado sobre alternativas encontradas naliteratura para recuperação, reutilização, revisão e retenção de casos pode ser encontradaem (DE MANTARAS et al., 2005).

Outro aspecto importante de um sistema baseado em RBC é o modelo usado para re-presentar os casos, incluindo a descrição tanto do problema quanto da solução associada.Se o domínio do sistema for muito complexo, também será o modelo e a representação deitens ou problemas na base da casos, o que pode limitar o uso de RBC em certas situações.

No contexto dos sistemas de recomendação, os itens a serem recomendados são tra-tados da mesma forma como são os problemas, na abordagem tradicional de sistemas deRBC. Por exemplo, quando requerendo uma recomendação, o usuário pode especificaralguns atributos que ele deseja que os itens tenham, e o sistema busca então os itens (i.e.casos) de que tem conhecimento em sua base para sugerir ao usuário. No passo de revisão,o sistema aceita modificações aos atributos do item recomendado, e em seguida realizauma nova busca. O sistema Entree (BURKE, 2000) é um exemplo desta abordagem.

Sistemas de recomendação que fazem o uso de de técnicas de RBC são ditos sistemasde recomendação baseados em conhecimento, pois guardam informações sobre como ositens a serem recomendados se adequam às necessidades dos usuários (BURKE, 2002).

2.5 Sistemas Híbridos

Sistemas de recomendação híbridos denotam quaisquer sistemas que usam mais deuma técnica para gerar recomendações. A motivação principal da criação de sistemashíbridos é o aumento da qualidade de recomendações, ao mesmo tempo em que torna-seo sistema resultante menos suscetível às desvantagens de uma das técnicas componentes.

Além da combinação de diferentes técnicas de recomendação, é possível ainda a com-binação de um mesmo conjunto de técnicas de várias formas diferentes, levando a sis-temas resultantes com propriedades variadas. Devido a estas muitas possibilidades, al-gumas combinações ainda não chegaram a ser exploradas, como vemos em (BURKE,2002).

19

Apresentaremos agora as técnicas mais comumente usadas em algoritmos híbridos, eem seguida, mostraremos algumas das formas mais comuns de combinação possíveis.

Em relação ao tipo de técnica usada para recomendação, Burke classifica os sistemasde recomendação dentro das seguintes classes (BURKE, 2002):

• Baseados em Conteúdo

• Colaborativos

• Demográficos

• Baseados em Conhecimento

• Baseados em Utilidade

Sistemas baseados em conteúdo, como vimos, utilizam o conteúdo dos itens, ou umarepresentação do conteúdo, como uma descrição textual, como dado base para o processode recomendação. No caso de sistemas colaborativos, é feita a comparação entre usuáriosou itens, sempre com base nas preferências indicadas pelos usuários em relação aos itensa serem recomendados.

Sistemas de recomendação demográficos usam informações explícitas do usuário, taiscomo idade, sexo, estado civil, etc., além das avaliações dos itens. Usuários são compa-rados com base nesses dados, e recebem recomendações de itens avaliados positivamentepor usuários semelhantes.

Sistemas baseados em conhecimento geram recomendações baseados nas necessida-des e preferências dos usuários e no conhecimento que têm armazenado sobre os itens,inferindo como cada item pode satisfazer tais necessidades e preferências.

De uma maneira um tanto similar, sistemas baseados em utilidade derivam funções deutilidade para cada usuário, que determinam o quanto um dado item é útil para o usuárioao qual se encontram associadas. Desta forma, as funções de utilidade são usadas para aelaboração de uma lista de itens recomendados.

Em relação às formas como as diferentes técnicas podem ser combinadas, (BURKE,2002) identifica as seguintes possibilidades:

• Pesos (Weighted)

• Combinação de Itens (Mixed)

• Estágios (Cascade)

• Alternância (Switching)

• Combinação de Dados (Feature Combination)

• Complementação de Dados (Feature Augmentation)

• Meta-Nível (Meta-Level)

Sistemas combinados por pesos, usam coeficientes para as predições geradas por cadaum dos sistemas componentes, somando-as em seguida. Em alguns casos, como o P-Tango (CLAYPOOL et al., 1999), um híbrido FC/FBC que usa avaliações explicitas dosusuários, os pesos são ajustados de acordo com o erro entre a predição dos componentese os valores fornecidos como avaliações.

20

A combinação de itens é uma forma bastante simples de criação de sistemas híbridos,apresentando as recomendações feitas pelos sistemas separados de maneira intercaladapara o usuário, como no algoritmo Fusion (TORRES et al., 2004).

A combinação por estágios usa as diferentes técnicas de recomendação em passos dis-tintos. Em cada passo, a lista de itens gerada por uma das técnicas é usada como entradapara a técnica subseqüente, que irá por sua vez filtrar ainda mais o conjunto de itens, atéque todas as técnicas componentes do sistema sejam usadas e finalmente se obtenha ositens a serem recomendados ao usuário. Esta técnica é usada no sistema Entree, usandono primeiro passo raciocínio baseado em casos e no segundo uma técnica colaborativa.(BURKE, 2002).

Sistemas combinados por alternância usam algum critério para a escolha de uma dastécnicas componentes. Essa escolha pode ser feita de várias formas. Poderia ser baseadano histórico que um dos componentes apresenta em relação às avaliações feitas por umusuário, sendo escolhido o que apresenta uma precisão maior nas predições já feitas.Alternativamente, a recomendação feita por um componente inicial poderia ser avaliada,e se esta não atender a um certo critério, gerar uma nova recomendação para o usuáriousando uma técnica alternativa.

No casos de sistemas que usam combinação de dados, uma técnica é empregada paraadicionar dados à representação de um item, de forma que estas novas característicassejam levadas em consideração por uma outra técnica aplicada em seguida. Por exemplo,em um sistema que use coeficientes TF-IDF para a correlação de documentos através deseus conteúdos, além do vetor de termos, cada documento poderia ter associado um vetorcontendo as avaliações que cada um dos usuários fizeram desse documento. Assim, asimilaridade de dois documentos poderia ser feita não só com base no conteúdo textual,mas também em relação às avaliações, seguindo o raciocínio de que dois documentosavaliados de maneira similar pelos usuários estejam relacionados de alguma forma.

A combinação por complementação de dados usa uma técnica para adicionar infor-mações a algum dado já conhecido do item, complementando a informação anteriormentepresente. No exemplo anterior, de recomendação de documentos, poderiam ser adiciona-dos dados como autores e bibliografia relacionada no texto do documento, gerados a partirde uma outra técnica, para que sejam levados em consideração pelo algoritmo baseado emconteúdo.

Finalmente, a combinação meta-nível é caracterizada pelo uso de um modelo geradopor uma técnica como passo inicial, ao invés da geração de recomendações diretamente.Esse modelo serve então como entrada para a próxima técnica, e assim por diante, atéque sejam geradas as recomendações de fato ao usuário final. Um detalhamento melhorde cada um dos tipos de técnicas e suas combinações pode ser encontrado em (BURKE,2002).

Na seção seguinte são apresentadas formas de avaliação de sistemas de recomenda-ção, bem como métricas para medir a qualidade de um determinado sistema, aplicáveis asistemas que usam quaisquer das técnicas apresentadas até agora.

2.6 Avaliação de Sistemas de Recomendação

Uma forma inegavelmente eficaz para a avaliação de sistemas de recomendação éatravés de avaliações de usuários reais, de maneira subjetiva. Infelizmente, é muito difícilou custosa a realização de tais testes, pois tanto a quantidade quanto a seleção correta deindivíduos para a criação de uma amostragem significativa são bastante difíceis de serem

21

alcançadas.Mesmo assim, é importante a obtenção de métricas em relação ao desempenho do

sistema antes que este seja amplamente usado, de forma a estimar qual será seu provávelcomportamento, e avaliar-se se, para o caso em questão, as recomendações geradas sãoadequadas.

Estes fatos levaram ao surgimento de abordagens para testes de sistemas de recomen-dação através de simulações, que conseguem, até certo ponto, estimar o comportamentodos sistemas em relação a certos aspectos. Antes de abordarmos as técnicas disponíveispara avaliação, introduzimos as seguintes métricas, que são amplamente empregadas paraa avaliação de sistemas de recomendação. Esta lista representa apenas algumas das mé-tricas mais usadas na literatura. Uma referência mais completa pode ser encontrada em(MONTANER, 2003) e (SALTON; MCGILL, 1986).

• Precisão (Precision)

• Recuperação (Recall)

• Cobertura (Coverage)

A precisão de um sistema indica a quantidade de itens recomendados que são de inte-resse ao usuário, em relação ao conjunto de todos os itens que lhe são recomendados. Oíndice de recuperação indica a quantidade de itens de interesse do usuário que aparecemna lista de recomendações (MONTANER, 2003). Já cobertura é a proporção de paco-tes que são passíveis de serem recomendados, em relação ao conjunto de todos os itensconhecidos pelo sistema de recomendação (TORRES, 2004).

Uma forma de simulação bastante difundida é a separação dos perfis em conjuntos deteste e de treinamento, de acordo com uma certa proporção pré-determinada (BREESE;HECKERMAN; KADIE, 1998). Dos usuários escolhidos para teste, então, é removidoum certo número de itens, que passam então a serem considerados como itens de interessedo usuário. Assim, podemos calcular então as métricas, da forma que segue. A precisãodo sistema será dada pela seguinte equação 2.4.

P =s

nr

(2.4)

Onde s é a quantidade de itens de interesse do usuário, ou seja, no caso da simulação,os itens removidos que foram de fato recomendados, e nr o número total de itens reco-mendados. Podemos assim obter uma idéia da probabilidade de o sistema recomendar umitem que seja pertinente.

A taxa de recuperação é expressa pela equação 2.5, sendo ni o número de itens deinteresse do usuário que foram de fato recomendados, e t o número total dos itens deinteresse do usuário, i.e. os itens removidos do perfil. A taxa de recuperação fornece aimportante medida do quão bem as necessidades ou interesses dos usuários são atendidaspelo sistema de recomendação.

R =ni

t(2.5)

Finalmente, a cobertura do sistema de recomendação é a proporção de itens para osquais ele é capaz de gerar recomendação, em relação ao número total de itens. Estaproporção é expressa na equação 2.6, sendo ri o número de itens que o sistema é capazde recomendar e nt o número de itens disponíveis. Esta medida é importante pois um

22

sistema com baixa cobertura provavelmente ignora itens que poderiam ser justamente osque satisfariam o usuário.

C =a

nt

(2.6)

Uma variação deste método de remoção de itens do perfil é a remoção de um únicoitem por teste, facilitando a classificação dos resultados do sistema de acordo com a posi-ção em que o item removido aparece na lista de recomendações. Esta distinção é bastanteimportante em sistemas que usam listas ordenadas de itens como forma de apresentaçãodos itens recomendados (MCNEE et al., 2002) (TORRES et al., 2004). Entretanto, limita-se a avaliação do sistema à taxa de recuperação, sendo esta sempre 0 ou 1, e cobertura,devido à restrição dos itens no conjunto de interesse.

No próximo capítulo veremos como funcionam os sistemas de gerenciamento de pa-cotes Linux, analisando em especial o caso da distribuição Debian. Mostramos comosistemas de recomendação podem facilmente usar os dados a partir do sistema de geren-ciamento de pacotes, agregando uma funcionalidade ainda não presente neste sistema,e também analisamos uma tentativa inicial de incorporar recomendação ao sistema degerenciamento.

23

3 GERENCIAMENTO E RECOMENDAÇÃO DE PACOTESDEBIAN

Neste capítulo iremos mostrar as soluções disponíveis tradicionalmente para a distri-buição e gerenciamento de software em sistemas Debian, além de mostrar alguns sistemasrecentes que têm por objetivo a incorporação de funcionalidades mais sofisticadas, inclu-sive de recomendação.

Mantemos nosso foco nas ferramentas componentes do sistema de gerenciamento depacotes da distribuição Debian, e as relacionadas a estas, por questão de simplicidade.Entretanto, pelo fato de outros sistemas de gerenciamento incluirem ferramentas equiva-lentes, ou até mesmo portes dessas ferramentas, as descrições a seguir se aplicam, emmaior ou menor grau, aos componentes desses outros sistemas.

Sistemas de gerenciamento de pacotes são os conjuntos de ferramentas dentro de umadistribuição Linux que possibilitam operações como busca, instalação e desinstalaçãode software e documentação através de unidades usualmente denominadas pacotes. Umpacote é um arquivo, geralmente comprimido, que contém os arquivos que compõe oprograma, biblioteca, documentação, entre outros, que está sendo distribuído.

Além disso, dependendo do sistema de gerenciamento ao qual pertencem, pacotespodem conter meta-dados sobre o que distribuem: autor, versão, dependências de outrospacotes, etc. Esta informação facilita muito a criação de outras ferramentas de mais altonível, disponibilizando funções de busca usando informações de campos diferentes, porexemplo.

Apesar da existência dos sistemas de gerenciamento de pacotes há quase tanto tempoquanto o próprio Linux, esses sistemas nunca deixaram de evoluir. A ferramenta maisbásica do sistema de gerenciamento da distribuição Debian, conhecida como dpkg porexemplo, apareceu por volta de 1995, sendo que antes disso já havia um sistema maisprimitivo em seu lugar (GARBEE et al., 2006). Ela centraliza as operações de instalação,desinstalação e configuração de pacotes, além de possuir capacidade de busca, emboraum tanto limitada.

Uma extensão do sistema básico de gerenciamento de pacotes do Debian veio com ainclusão da ferramenta APT (Advanced Packaging Tool) na liberação oficial 2.1 do De-bian(GARBEE et al., 2006). Essa ferramenta possibilita o uso de repositórios remotos,disponíveis via Internet, como fontes de pacotes para instalação, permitindo a atualiza-ção constante do sistema. Subseqüentemente foram introduzidos os chamados frontends

para o APT, disponibilizando interfaces gráficas para a manipulação de pacotes, como oSynaptic e o Adept, para citar alguns.

Um dos desenvolvimentos mais importantes, e relativamente recente, em relação aosistema de gerenciamento foi a introdução de tags, ou marcas, para a classificação de pa-

24

cotes, pelo projeto debtags (DEBTAGS, 2006). A classificação usando marcas é bastantepoderosa, como veremos, pois adiciona várias informações úteis em relação ao conteúdodos pacotes que apenas com os meta-dados tradicionais não era possível de ser expressa.Juntamente com o surgimento de um sistema para a análise do uso de pacotes instaladosem um sistema, o popularity-contest (POPCON, 2006), as marcas podem ser úteis na re-comendação de pacotes. Um sistema experimental usando esta abordagem é o popsuggest

(POPSUGGEST, 2006).A seguir, cada um desses sistemas será apresentado em maiores detalhes.

3.1 Dpkg

O bloco mais essencial no sistema de gerenciamento de pacotes do Debian é o dpkg.Através do dpkg é possível a instalação, atualização, remoção, busca, listagem e confi-guração de pacotes. Para efetuar essas operações, é mantido um arquivo texto contendoentradas de todos os pacotes conhecidos pelo sistema gerenciamento, bem como meta-dados de cada um desses pacotes. Na figura 3.1, vemos o exemplo das informações en-capsuladas no pacote python, que contém o interpretador da linguagem de mesmo nome:

Package: python

Status: install ok installed

Priority: standard

Section: python

Installed-Size: 532

Maintainer: Matthias Klose <doko@debian.org>

Architecture: all

Source: python-defaults

Version: 2.4.3-11

Replaces: python2.3 (<= 2.3.2-6), python-xmlbase, python-base

Provides: python-email, python-xmlbase

Depends: python2.4 (>= 2.4.3-7), python-minimal (= 2.4.3-11)

Suggests: python-doc, python-tk, python-profiler

Conflicts: python2.3 (<< 2.3.5-14), python2.1 (<= 2.1.2), python-xmlbase, python-csv, python-bz2, python-base, python-central (<< 0.5.5)

Description: An interactive high-level object-oriented language (default version)

Python, the high-level, interactive object oriented language,

includes an extensive class library with lots of goodies for

network programming, system administration, sounds and graphics.

.

This package is a dependency package, which depends on Debian’s default

Python version (currently v2.4).

Figura 3.1: Entrada do pacote python na base de dados de pacotes de um sistema Debian.

Aqui, podemos ver os meta-dados disponíveis, tais como o status do pacote no sis-tema, o tamanho que a instalação do pacote ocupa, o relacionamento com outros pacotes(campos Replaces, Provides, Depends, Suggests e Conflicts), etc.

Um campo que merece nossa atenção especial é a descrição do pacote. Praticamentetodos pacotes que compõe a distribuição Debian, e a vasta maioria dos que não fazemparte da distribuição oficial, contém o campo de descrição. O propósito desse campo éconter uma apresentação do pacote e quaisquer outras informações adicionais que o autorjulgar úteis, de forma legível por humanos. Como veremos depois, este campo tambémé útil para a aplicação de técnicas de filtragem baseada em conteúdo, apresentada nocapítulo anterior.

Outro campo interessante é o campo Suggests. O objetivo desse campo é listar pacotescujo uso seja relacionado ao do pacote em questão, mas cuja instalação conjunta não éestritamente necessária para a disponibilização de toda a funcionalidade do pacote. As-

25

sim, desde o sistema básico de gerenciamento, vemos que existe uma espécie de suporteà recomendação de pacotes, ainda que não condiza com um sistema de recomendaçãocompleto, e não possua nenhum fator de personalização.

3.2 APT

O conjunto de ferramentas APT, ou Advanced Packaging Tool, situa-se sobre o sistemabásico de gerenciamento disponibilizado pelo dpkg, adicionando o importante conceito derepositórios de pacotes. Um repositório, a grosso modo, nada mais é do que uma estruturade diretórios contendo pacotes e arquivos que descrevem os pacotes, disponibilizadosatravés de um servidor HTTP ou FTP.

As operações essenciais disponibilizadas pelo APT são efetuadas pelo comando apt-

get. Através dele é feita a atualização da informação de quais pacotes se encontram dis-poníveis para instalação ou atualização, a instalação de pacotes a partir de repositóriosremotos, a remoção de pacotes, e até mesmo a atualização completa de uma versão an-tiga da distribuição para uma mais nova, através da atualização de cada um dos pacotesafetados.

A escolha de quais repositórios devem ser usados fica a cargo do usuário, e é feitaatravés de um arquivo texto, geralmente localizado em /etc/apt/sources.list. Vemos umexemplo na figura 3.2.

deb http://ftp.debian.org/debian/ etch main non-free contrib

deb http://wintermute.sytes.net:8080/apt debommender main

Figura 3.2: Exemplo de entradas de um arquivo de fontes de pacotes (repositórios)

Cada entrada “deb” denota um repositório, via uma URL. Cada repositório tem suaprópria organização interna, podendo conter pacotes para mais de uma distribuição. Deforma análoga, cada distribuição é subdividida em seções. Assim, nosso exemplo contémdois repositórios. O primeiro é o repositório oficial de pacotes Debian para a distribuiçãodenominada “Etch”, com as seções “main”, “non-free” e “contrib” sendo usadas comofontes de pacotes. O segundo é o repositório que foi criado apenas para conter o pacoteda aplicação cliente resultante deste trabalho, denominado “debommender”, contido nadistribuição de mesmo nome. A distribuição, por sua vez, contém apenas uma seção,denominada “main”.

Um dos arquivos mais importantes em um repositório é denominado Packages, e con-tém a informação de todos os pacotes presentes no repositório. Seu formato é pratica-mente idêntico à base de dados do dpkg, exceto pela ausência de algumas informaçõesque não são pertinentes ao repositório (o status do pacote sendo uma delas).

Traçando um paralelo com sistemas de recuperação ou recomendação de documen-tos, podemos considerar que o arquivo Packages corresponde ao corpus, e que a descri-ção de cada pacote contido no arquivo corresponde a um documento pertencente a essecorpus. Isso nos fornece então um suporte inicial para efetuarmos a recomendação depacotes usando técnicas baseadas em conteúdo, nos faltando ainda as informações de pre-ferências, os perfis, dos usuários. Como veremos na seção a seguir, porém, um outrosistema presente na distribuição Debian será capaz de nos fornecer essas informações, opopularity-contest

26

3.3 Popularity Contest

O popularity-contest é um esforço para mapear o uso dos pacotes da distribuiçãoDebian (POPCON, 2006). O cliente do sistema é distribuído na forma de um pacote, demesmo nome, e é composto por scripts, que são executados periodicamente na máquinaem que são instalados via o sistema cron de agendamento de tarefas presente na maioriadas instalações do Linux.

Estes scripts criam uma lista dos últimos pacotes acessados, ordenados do mais re-centemente usado ao menos. Esta lista então é enviada a um servidor, que a armazena. Apartir deste ponto, a informação pode ser usada de várias maneiras diferentes: na páginado projeto encontram-se estatísticas globais, tais como quais são os pacotes mais instala-dos e usados, entre outras. No entanto, se mantivermos a diferenciação entre os usuários,podemos construir perfis baseados na informação gerada por este sistema, periodicamenteatualizados, e de forma automática, bastando que os usuários tenham o pacote contendoos scripts necessários instalado.

3.4 Debtags

O sistema debtags surgiu da necessidade de se organizar o crescente conjunto de pa-cotes na distribuição Debian. O sistema original de classificação usa seções simples, oque o torna um tanto inadequado para o número atual de pacotes da distribuição. Alémdisso, debtags possibilita funcionalidades avançadas sobre o sistema de gerenciamentobase, tanto para busca quanto para recomendação de pacotes, e por isso é usado em al-guns softwares de gerenciamento de pacotes mais recentes e sofisticados, como o Adept.

O sistema de marcas usadas para pacotes no projeto debtags são exemplos de classi-ficação por facetas, uma técnica que existe pelo menos há 70 anos (ZINI, 2005). Umafaceta é um aspecto presente nos itens classificados, e várias facetas diferentes podem serusadas para indexar um mesmo item. Isso contrasta com sistemas de classificação base-ados em uma hierarquia única, tais como o Dewey (MARKEY; DEMEYER, 1985), porexemplo.

Assim, é possível fazermos buscas usando combinações de facetas para atingirmosresultados que de outra forma requereriam muito mais esforço, ou tornariam-se até im-possíveis de serem alcançados. Por exemplo, para buscarmos por pacotes que contenhamapenas programas com interfaces gráficas usando o vocabulário do debtags, podemos usaruma expressão booleana composta pelas seguintes marcas:

role :: program&&(interface :: x11||interface :: 3d)

Figura 3.3: Exemplo de expressão de busca usando marcas do vocabulário debtags

Usamos duas facetas, role, ou “papel” e interface. A primeira especifica qual o papelque o pacote desempenha no sistema, e valores aceitáveis além do demonstrado seriam“biblioteca” e “documentação”, por exemplo. Já a segunda sinaliza o tipo de interfacecom o usuário que é empregada. Assim, o que a nossa expressão indica é que queremosapenas pacotes que contenham programas cujas interfaces façam uso do ambiente gráficoX11 ou de ambientes 3-D, que na prática correspondem aos sistemas gráficos mais usadosno Linux.

27

Marcas têm bastante potencial para serem usadas em um sistema de recomendação,principalmente como forma de medir a similaridade entre pacotes. Um exemplo simplesde uma medida deste tipo seria considerar cada uma das marcas presentes no vocabuláriocomo uma componente em um vetor que representa o pacote, sendo o valor da compo-nente 1 se a marca se encontra presente no pacote ou 0, caso contrário. Calculando o valordo cosseno entre os ângulos dos vetores de marcas de dois pacotes distintos nos propor-cionaria uma medida entre 0 e 1 da similaridade entre estes dois pacotes. Em seguidaveremos um sistema que utiliza as marcas, embora de uma forma diferente, mas com oobjetivo de gerar recomendações.

3.5 Popsuggest

Popsuggest é um sistema que usa as informações disponibilizadas pelos sistemas deb-

tags e popularity-contest, com o intuito de gerar recomendações de pacotes. Em seuobjetivo, popsuggest pode ser considerado bastante similar ao sistema proposto neste tra-balho, e ambos também apresentam aspectos semelhantes na implementação, como o usode informações geradas pelo popularity-contest como uma de suas fontes de dados, man-tendo diferenças significativas.

Apesar de ambos serem sistemas híbridos FC/FBC, como será visto, pertencem aclasses diferentes, e os algoritmos e fontes de dados internos que são usados por um, ounão são usados pelo outro, ou são usados de maneira diferente. Um exemplo é o usode coeficientes TF-IDF no componente colaborativo do popsuggest, em contraste comsimilaridade pelo cosseno usado em nosso sistema.

O popsuggest usa as informações geradas pelo popularity-contest como perfil dosusuários. Essas informações, como vimos, encontram-se no formato de uma lista depacotes ordenadas do mais recentemente usado ao menos. Para gerar as recomendações,o sistema compara a similaridade dessas listas, ou perfis, e calcula o coeficiente TF-IDFde cada pacote presente no perfil.

Também são levadas em consideração as marcas do vocabulário debtags associadasaos pacotes. A partir da lista de pacotes que compõem o perfil do usuário são extraídas asmarcas associadas a cada pacote. Também são calculados os coeficientes TF-IDF de cadamarca, considerando-se cada marca como se fosse um termo, e a lista de marcas de umpacote como se fosse um documento. Assim, obtém-se uma lista ordenada das marcasmais representativas pertencentes aos pacotes presentes no perfil do usuário.

Esta lista de marcas é então percorrida a partir da ordem da mais relevante à menos.Os pacotes recomendados que possuem a marca ativa são então ordenados em uma su-blista e é calculada a relevância do pacote com base na sua posição na lista de pacotesrecomendados. Este passo é mais ou menos equivalente ao de geração de predição usadaem sistemas de recomendação mais tradicionais.

O resultado final é uma lista de pacotes com medidas de relevância associadas, orde-nada por marcas, tendo no topo da lista os pacotes que são sinalizados pela marca maiscaracterística encontrada no sistema do usuário.

Podemos identificar dois componentes neste sistema: um colaborativo, baseado nasimilaridade de perfis, ou listas de pacotes, de usuários diferentes e outro, baseado noconteúdo das listas de marcas associadas a cada um dos pacotes. Podemos também notarque o componente baseado em conteúdo simplesmente reordena as recomendações ge-radas pelo componente colaborativo, colocando as recomendações de pacotes associadosà marca mais representativa em evidência. Isso caracteriza o sistema híbrido resultante

28

em um sistema FC/FBC combinado por estágios, sendo a saída do algoritmo colaborativoservindo como entrada do baseado em conteúdo.

Uma peculiaridade interessante é o uso de coeficientes TF-IDF para a medida de si-milaridade. Como o TF-IDF penaliza termos bastante difundidos pelo conjunto de itens,tanto pacotes quanto marcas com freqüências altas são penalizados. Na prática isso sig-nifica que o popsuggest prioriza itens que se encontram em uso por um grupo de usuáriosmais particular em relação aos que se encontram bastante difundidos. De forma similar,as marcas mais genéricas no vocabulário tendem a não aparecer nas primeiras posições dalistagem de pacotes. Isso é desejável pois geralmente marcas bastante usadas represen-tam conceitos mais genéricos, com caráter mais abstrato, ou até mesmo com semânticaambígua.

Um exemplo é a marca use:viewing, que pode ser usada desde a pacotes para visua-lização de sistemas moleculares (e.g. xmakemol), a visualizadores de apresentações (e.g.pptview) e até extensões de browsers (e.g. firefox-webdeveloper).

No próximo capitulo apresentamos a arquitetura e os detalhes de implementação maisimportantes da solução que foi desenvolvida para a recomendação de pacotes no contextodeste trabalho.

29

4 DEBOMMENDER: UM SISTEMADERECOMENDAÇÃODE PACOTES

Com o que expusemos até agora, podemos considerar uma arquitetura para um sistemade recomendação de pacotes para a distribuição Debian. Nosso sistema usa como ponto departida um estudo feito sobre sistemas híbridos criados a partir de componentes baseadosem conteúdo e colaborativos (TORRES et al., 2004). Das técnicas apresentadas no artigo,decidimos fazer a implementação inicial baseada no algoritmo Fusion, pela simplicidadena implementação e pelos resultados que o algoritmo apresentou nos testes realizados.

A idéia principal por trás do Fusion é a combinação intercalada de recomendações daslistas resultantes de cada um das técnicas de recomendação que o compõe. Isso permiteque as técnicas usadas sejam implementadas separadamente, e até mesmo executadas deforma concorrente ou paralela. Segundo a taxonomia usada em (BURKE, 2002), issocaracteriza o Fusion como uma técnica de combinação de itens (mixed).

Em nossa implementação, entretanto, resolvemos fazer uma pequena modificação emrelação à forma como as recomendações dos componentes FC e FBC são combinadas,usando pesos para as predições geradas pelos algoritmos, como foi feito em (CLAYPOOLet al., 1999). Assim, a implementação feita neste trabalho é caracterizada como umatécnica baseada em pesos (weighted), segundo a taxonomia de Burke (BURKE, 2002).Inicialmente usamos pesos iguais para ambos os componentes.

O uso de pesos em detrimento da intercalação foi feito tendo em vista a possível incor-poração de um mecanismo para receber feedback explícito por parte dos usuários quandorecebessem as recomendações. Para tanto, o uso do valor das predições geradas para ositens facilitaria muito a implementação, informação esta que se perde se usarmos umatécnica de combinação. Este mecanismo ainda não foi incorporado no sistema quando daescrita deste texto, entretanto.

Para a geração dos perfis dos usuários, usada tanto pelo componente de FBC quantode FC, usamos os scripts pertencentes ao popularity-contest, apresentado no capítulo an-terior. Fizemos algumas modificações no lado do servidor para atingirmos o objetivo demantermos a distinção entre os diferentes usuários do sistema e subseqüentemente mon-tarmos seus perfis.

Desta forma, identificamos dois componentes principais no sistema. O primeiro, osistema de recomendação propriamente dito, é responsável pela carga dos perfis a partirda base onde são armazenados e pela geração das recomendações de pacotes aos usuá-rios. Iremos chamar este componente de Subsistema de Recomendação. Nos valemosna implementação deste, de uma arquitetura cliente/servidor, sendo o cliente usado pelousuário quando quiser requisitar as recomendações e o servidor responsável por gerá-las.

O segundo componente, modelado a partir da mesma arquitetura, é responsável pelo

30

monitoramento do uso de pacotes nas máquinas dos usuários do sistema e pelo armazena-mento dessas informações. Isso se dá através dos scripts derivados do popularity-contest

no lado do cliente e pelo armazenamento desses dados em uma base, via um script CGI,também derivado do pacote popularity-contest, no servidor. A figura 4 mostra uma visãogeral do sistema resultante.

Figura 4.1: Visão geral do sistema de recomendação de pacotes Debian

Nas seções seguintes mostraremos os detalhes de cada um destes sistemas.

4.1 Subsistema de Recomendação

O subsistema de recomendação, visto no lado esquerdo da figura 4, é composto pelabase de dados contendo os perfis dos usuários, o servidor de recomendação, que imple-menta o algoritmo de recomendação híbrido, e o cliente, responsável por requisitar a listade pacotes recomendados ao servidor e disponibilizá-la ao usuário.

Podemos considerar o servidor de recomendação como o núcleo do nosso sistema,pois é nele que as etapas mais importantes são executadas. Este componente tem duas

31

partes principais, a primeira que gerencia a comunicação com os clientes e a criação dethreads para a geração da recomendação de pacotes e a segunda que é a implementaçãodo algoritmo de recomendação propriamente dita, que roda dentro destas threads. Destaforma, podemos gerar recomendações para clientes diferentes de maneira concorrente.

Em relação aos algoritmos usados nos componentes de FBC e FC, escolhemos umalgoritmo usando similaridade entre coeficientes TF-IDF para o primeiro, e o k-Nearest

Neighbor para o segundo, de maneira similar a (TORRES et al., 2004). Entretanto, comona implementação do sistema de recomendação usamos a linguagem Java, e não C++, foiusada uma implementação própria do algoritmo TF-IDF para o componente baseado emconteúdo, e para o componente colaborativo foi usada a biblioteca Taste.

No lado do cliente, usamos uma aplicação bastante simples, escrita na linguagem C++e fazendo uso da biblioteca Qt, que contém componentes de interface gráfica, de mani-pulação de arquivos XML e de transferências de dados via o protocolo HTTP. Esses doisúltimos aspectos também podem ser facilmente manipulados por componentes disponí-veis para a linguagem Java, fato este que nos fez escolher o HTTP como protocolo decomunicação entre o cliente e servidor e XML como a sintaxe usada na transferência dasinformações. Na figura 4.2 vemos um exemplo da informação enviada pelo servidor paraa recomendação de um pacote e o que é gerado na interface pelo cliente na figura 4.3. As-sim, o servidor envia as informações de nome do pacote, valor da predição e a descriçãousando o tag “package”, e o cliente apenas disponibiliza esta informação de uma formamais amigável para o usuário.

<recommendations>

...

<package name="ntp" prediction="2.7840661073169275">

<![CDATA[ Network Time Protocol daemon and utility programs

NTP, the Network Time Protocol, is used to keep computer clocks

accurate by synchronizing them over the Internet or a local network,

or by following an accurate hardware receiver that interprets GPS,

DCF-77, NIST or similar time signals.

.

This package contains the NTP daemon and utility programs. An NTP

daemon needs to be running on each host that is to have its clock

accuracy controlled by NTP. The same NTP daemon is also used to

provide NTP service to other hosts.

.

For more information about the NTP protocol and NTP server

configuration and operation, install the package "ntp-doc".

.

Web sites: http://ntp.isc.org/ and http://www.ntp.org/]]></package>

...

</recommendations>

Figura 4.2: Entrada de um pacote recomendado na lista gerada pelo servidor de recomen-dações

4.2 Subsistema de Monitoramento.

O subsistema de monitoramento é composto inteiramente por scripts do pacote popularity-

contest modificados, tanto para permitir o uso das informações geradas de uma formamais conveniente quanto para permitir a instalação destes scripts lado a lado com os ori-ginais. Estes scripts encontram-se codificados na linguagem Perl.

Da mesma forma que com o subsistema de recomendação, aqui fazemos uso do pro-tocolo HTTP, com a particularidade de que é usado um servidor web para lidar com a

32

Figura 4.3: Apresentação da recomendação representada pelos dados mostrados na figura4.2

comunicação do lado do servidor. O cliente conecta-se a este servidor via um socket

comum. O servidor, por sua vez, quando recebe uma requisição de um cliente delegaessa requisição ao script de armazenamento via interface CGI. Finalmente, o script dearmazenamento atualiza as entradas nas tabelas necessárias na base de dados, provendo ainformação atualizada para o subsistema de recomendação.

Assim, temos todos os elementos necessários para a criação de um sistema de reco-mendação de pacotes. No próximo capítulo, apresentamos experimentos realizados deforma a avaliar o grau de sucesso da abordagem aqui apresentada.

33

5 AVALIAÇÃODOSISTEMACOMDADOSDEUSUÁRIOS

Neste capítulo, mostramos experimentos que foram realizados de forma a avaliarmoso quanto o sistema foi capaz de alcançar os objetivos aos quais se propõe. Inicialmente,disponibilizamos a parte cliente do sistema para uso de usuários via um pacote presenteem um repositório APT, tornando assim o sistema de fácil instalação e atualização.

Foi criada uma página no site sourceforge, um repositório bem conhecido para proje-tos de software livre, que pode ser acessada via http://debommender.sourceforge.net. Apágina contém instruções para a instalação e utilização do sistema, bem como atualiza-ções como notícias, reportes e correções de bugs, etc.

Como forma de divulgação, foram utilizados diversos canais disponíveis: usuáriosparticipantes na comunidade de software livre, sites de agregação de notícias relacionadasa software livre e listas de discussão relevantes.

No período de duas semanas entre 21/05/07 e 03/06/07, por volta de 30 usuários dasdistribuições Debian e Ubuntu, contatados principalmente através de listas de discussãodedicadas a essas distribuições, fizeram a instalação do sistema. Com isso pudemos le-vantar dados em relação ao uso de pacotes feito nas máquinas, bem como fazer algumasmedições de como o sistema se comportou.

O método que usamos para os testes consiste na medição da taxa de recuperação dosistema, ou seja, a proporção dos itens de interesse do usuário que o sistema é capazde recomendar, como descrito no capitulo 2. Devido à falta de informações disponíveisantes da existência do sistema com a qual pudéssemos fazer testes, optamos aqui por usara informação recolhida pelo próprio sistema, ou seja, os dados reais dos usuários queinstalaram o cliente.

5.1 Descrição do Experimento

Dividimos os perfis dos usuários em conjuntos de treinamento e testes, de forma alea-tória, em uma proporção de 2:1, ou seja, a cada dois usuários no conjunto de treinamentotemos 1 no conjunto de testes. Para os usuários do conjunto de testes, escolhemos um pa-cote qualquer do perfil, com uma avaliação com valor relativamente alto, e a removemosdo seu conjunto de avaliações. O objetivo do teste é medir qual a proporção de execu-ções em que o sistema é capaz de recomendar o pacote removido com sucesso, e em quecolocação o pacote aparece na lista de recomendações. Essa diferenciação é importantedevido à forma como o sistema apresenta seus resultados, que é uma lista ordenada depacotes recomendados: um pacote recomendado que aparece na trigésima posição tembem menos chance de ser notado do que um que apareça na quinta, por exemplo.

Após a remoção do pacote do perfil de cada usuário do grupo de testes, o sistema érodado e extraímos as métricas relacionadas, ou seja, a percentagem de vezes em que o

34

pacote removido é recomendado, e em que intervalo ele se encontra posicionado. O expe-rimento então é repetido, até um total de dez vezes, para que tenhamos uma distribuiçãomais uniforme dos resultados: é possível que em uma das execuções o teste escolha ape-nas usuários ainda com poucas avaliações no sistema (usuários recentes), fazendo comque os resultados sejam deturpados. De maneira contrária, também seria possível queapenas os usuários com mais avaliações fossem escolhidos, provavelmente favorecendo ofuncionamento do sistema para essa execução.

5.2 Resultados e Análise

Nas figuras seguintes é apresentado o resultado dos testes. Rodamos os testes comtrês mecanismos de recomendação diferentes: primeiramente, apenas o componente queimplementa a filtragem baseada em conteúdo, depois apenas o componente que imple-menta a filtragem colaborativa, e finalmente, a implementação híbrida, combinando oscomponentes via pesos.

Figura 5.1: Resultados para o componente baseado em conteúdo

Observamos que apesar de, isoladamente, o componente baseado em conteúdo apre-sentar um resultado bastante ruim, quando combinado ao componente colaborativo, osistema híbrido resultante apresenta um ganho significativo, quando comparado ao com-ponente colaborativo isoladamente. Também é interessante notar que o ganho maior nataxa de recuperação se dá justamente nos intervalos mais importantes. Para a primeiraposição o componente colaborativo foi capaz de recomendar apenas 3% dos pacotes re-movidos, comparada a 13% do sistema híbrido. De maneira similar, notamos um aumentode 53% para 63% na proporção de sucessos do sistema híbrido para itens recomendadosaté a décima posição.

Resolvemos também testar um componente baseado em conteúdo que usa as marcasdo projeto debtags para a comparação entre pacotes. Os resultados estão na figura 5.2.

35

Figura 5.2: Resultados para o componente colaborativo

Figura 5.3: Resultados para o algoritmo híbrido

36

Figura 5.4: Resultados para filtragem baseada em conteúdo usando marcas do projetodebtags

Também combinamos este componente com o colaborativo, obtendo os resultados dafigura 5.2.

Notamos que, da mesma forma, apesar do componente baseado em conteúdo por sisó apresentar resultados ruins, quando combinado ao componente colaborativo nota-seum ganho significativo no algoritmo resultante. Ao contrário do que acreditávamos, en-tretanto, o componente baseado em conteúdo usando marcas apresentou um resultadoinferior ao algoritmo FBC que usa as descrições dos pacotes. Isso pode se dar devidoao fato de muitos pacotes ainda não haverem sido classificados usando marcas, ou clas-sificados usando apenas uma ou outra faceta, sem que hajam descrições completas paratodos os pacotes através de marcas. Um estudo mais aprofundado se faria necessário paraaveriguar se é esse o caso, entretanto.

Medimos também a cobertura de cada um dos sistemas, ou seja, qual a proporção depacotes que o sistema é capaz de recomendar em relação a todos os pacotes disponíveis.Os resultados são apresentados na figura 5.2.

Aqui, notamos que os sistemas que possuem componentes baseados em conteúdo pre-valecem sobre o que só usa um componente colaborativo. Isso se dá pois o sistema base-ado somente em filtragem colaborativa não é capaz de recomendar itens que não tenhamsido avaliados por nenhum usuário. Estes itens somam uma quantidade considerável dositens nos dados que compõem o perfil dos usuários no caso do nosso sistema.

Avaliando as medições assim feitas, notamos que a nossa escolha de combinação detécnicas parece ter sido adequada, pois cada uma das técnicas é capaz de colaborar comaspectos importantes, e quando unificadas em um sistema híbrido temos um resultadosatisfatório sem que haja o comprometimento do sistema tanto em relação à taxa de recu-peração quanto à cobertura.

Para uma avaliação mais eficaz do sistema, se faria necessária a avaliação por parte

37

Figura 5.5: Resultados para filtragem baseada em conteúdo usando marcas combinada afiltragem colaborativa

Figura 5.6: Cobertura

de usuários reais, avaliação que não fomos capazes de incluir quando da escrita destetexto. Entretanto, vários outros trabalhos se valem de métricas como as que foram apre-sentadas. Portanto, consideramos estes resultados como indício de que o sistema quedesenvolvemos atingiu, pelo menos em parte, os objetivos a que se propõe, sendo capaz

38

de recomendar pacotes importantes aos usuários, e de maneira ampla o suficiente, semque se restrinja a um nicho de pacotes específicos.

Pelo fato de termos explorado apenas uma técnica, embora com algumas pequenas va-riações, acreditamos que estes resultados servem apenas como um exemplo inicial do quesistemas de recomendação podem atingir quando aplicados a recomendação de pacotesde software: a quantidade de técnicas disponíveis, bem como as formas de combiná-las,e as fontes de dados disponíveis sobre os pacotes de software ainda são muitas, e prova-velmente existam combinações que levem a resultados significativamente melhores.

39

6 CONCLUSÃO

O desenvolvimento e crescente adoção de sistemas abertos e livres, entre outros, criamuma coleção cada vez maior de software disponível, software este que se destina a auxi-liar as pessoas em suas tarefas cotidianas. Com este crescimento, entretanto, cria-se umproblema relacionado: como encontrar as aplicações de que os usuários necessitam demaneira eficiente, sem que este tenha que despender um esforço que cresce proporcional-mente com o aumento da oferta de aplicações.

Este é um problema recorrente e tem sido atacado criando-se novas gerações de fer-ramentas cada vez mais sofisticadas, que possam encontrar na gama crescente de pacotesde software os que o usuário necessita, de maneira cada vez mais fácil. Atualmente, en-tretanto, as ferramentas consideradas tradicionais já não são mais capazes, por si só, delidar de maneira eficiente com este problema. Se faz portanto necessária a criação deferramentas baseadas em técnicas ainda não exploradas neste contexto, e que ofereçampelo menos uma forma de minimizar o problema de distribuição e busca de software demaneira aceitável.

Neste trabalho foi exposta uma proposta inicial de como o problema pode ser atacado,e uma prova de conceito foi desenvolvida e testada. Foram expostas as técnicas que foramusadas no desenvolvimento da prova de conceito, bem como outras que possam servir paraoutros sistemas que porventura também se proponham a auxiliar na busca e instalação depacotes de software usando técnicas de recomendação.

Usando como base trabalhos desenvolvidos anteriormente, implementamos uma solu-ção híbrida, combinando técnicas de filtragem colaborativa e baseada em conteúdo. Apli-camos experimentos que indicaram que o uso de técnicas baseadas em conteúdo, tantousando marcas quanto as descrições dos pacotes, apresentam um resultado fraco, mas,quando combinadas à filtragem colaborativa, são capazes de melhorar o desempenho dosistema resultante.

Além dos experimentos descritos no capítulo 5, disponibilizamos, via uma páginaweb, um questionário simples para que os usuários expressassem suas opiniões quantoà qualidade das recomendações recebidas. Entretanto, recebemos pouco retorno, e oque recebemos distribuiu-se entre as respostas possíveis, de maneira mais ou menos uni-forme. Este fato nos levou a não incluir esses dados neste trabalho, mas continuare-mos a disponibilizar tal pesquisa, caso o uso do sistema cresça no futuro. Esta avalia-ção, bem como os resultados, pode ser acessada através da página criada para o projeto(http://debommender.sourceforge.net), pelo link “Poll”.

Apesar de acreditarmos que os resultados obtidos foram bastante satisfatórios, existemainda uma gama de técnicas que ainda podem ser exploradas neste contexto. Portanto,somos também levados a crer que um sistema de recomendação de pacotes de softwarepossa obter resultados ainda superiores aos da prova de conceito apresentada.

40

Acreditamos que sistemas como o que foi desenvolvido e apresentado aqui tendamfuturamente a mesclar-se com as ferramentas atualmente consideradas tradicionais, comotem sido a tendência para cada nova geração de ferramentas de gerenciamento e buscade pacotes de software. Em outras palavras, acreditamos que o uso de sistemas de reco-mendação neste âmbito venha como um complemento aos sistemas já existentes, e nãoos substitua. Finalmente, consideramos que a existência de outras iniciativas para a in-corporação de funcionalidades mais avançadas e com fator de personalização, como opopsuggest, é um indício de que sistemas de recomendação são um dos complementosmais promissores às ferramentas disponíveis atualmente.

41

REFERÊNCIAS

AAMODT, A.; PLAZA, E. Case-based reasoning: foundational issues, methodologicalvariations, and system approaches. AI Communications, [S.l.], v.7, n.1, p.39 – 59, 1994.Case based reasoning;Foundational issues;Methodological variations;.

AGGARWAL, C. C.; YU, P. S. New framework for itemset generation. In: 1998, Seattle,WA, USA. Anais. . . [S.l.: s.n.], 1998. p.18 – 24. Association rules;Strongly collectiveitemsets;.

AGRAWAL, R.; IMIELINSKI, T.; SWAMI, A. N. Mining Association Rules betweenSets of Items in Large Databases. In: ACM SIGMOD INTERNATIONAL CONFE-RENCEONMANAGEMENTOFDATA, 1993., 1993, Washington, D.C. Proceedings. . .[S.l.: s.n.], 1993. p.207–216.

AKTAS, M. S.; PIERCE, M.; FOX, G. C.; LEAKE, D. A Web based ConversationalCase-Based Recommender System for Ontology aided Metadata Discovery. In: GRID’04: PROCEEDINGS OF THE FIFTH IEEE/ACM INTERNATIONAL WORKSHOPON GRID COMPUTING, 2004, Washington, DC, USA. Anais. . . IEEE Computer Soci-ety, 2004. p.69–75.

BALABANOVI, M.; SHOHAM, Y. Fab: content-based, collaborative recommendation.Commun. ACM, New York, NY, USA, v.40, n.3, p.66–72, 1997.

BAYARDO, R. J. J.; AGRAWAL, R.; GUNOPULOS, D. Constraint-based rule mining inlarge, dense databases. Proceedings - International Conference on Data Engineering,Sydney, NSW, AUS, p.188 – 197, 1999. Constraint based rule mining;User specified cons-traint;.

BREESE, J. S.; HECKERMAN, D.; KADIE, C. Empirical Analysis of Predictive Al-gorithms for Collaborative Filtering. In: IEEE COMPUTER SOCIETY, 1998. Anais. . .[S.l.: s.n.], 1998. p.43–52.

BUCKLEY, C. Implementation of the SMART Information Retrieval System. Ithaca,NY, USA: [s.n.], 1985.

BURKE, R. Knowledge-based Recommender Systems. 2000.

BURKE, R. Hybrid Recommender Systems: survey and experiments. User Modelingand User-Adapted Interaction, Hingham, MA, USA, v.12, n.4, p.331–370, 2002.

42

CLAYPOOL, M.; GOKHALE, A.; MIRANDA, T.; MURNIKOV, P.; NETES, D.; SAR-TIN, M. Combining Content-Based and Collaborative Filters in an Online Newspa-per. 1999.

DE MANTARAS, R. L.; MCSHERRY, D.; BRIDGE, D.; LEAKE, D.; SMYTH, B.;CRAW, S.; FALTINGS, B.; MAHER, M. L.; COX, M. T.; FORBUS, K.; KEANE, M.;AAMODT, A.; WATSONI, I. Retrieval, reuse, revision and retention in case-based reaso-ning. Knowledge Engineering Review, [S.l.], v.20, n.3, p.215 – 240, 2005. Case-basedreasoning (CBR);Cognitive science;Analogical reasoning;.

DEBIAN. Disponível em: http://debian.org/. Acesso em: Jun. 2007.

DEBTAGS. Disponível em: http://wiki.debian.org/DebTags. Acesso em: Apr. 2007.

FAYYAD, U. Knowledge discovery in databases: an overview. Lecture Notes in Arti-ficial Intelligence (Subseries of Lecture Notes in Computer Science), Prague, CzechRepub, v.1297, p.3 –, 1997.

FSF. Overview of the GNU System. Disponível em: http://www.gnu.org/gnu/gnu-history.html. Acesso em: Nov. 2006.

GARBEE, B.; LOHNER, N.; LOWE, W.; MITCHELL, B.; MURDOCK, I.;SCHULZE, M.; SMALL, C. A Brief History of Debian. Disponível em:http://www.debian.org/doc/manuals/project-history/. Acesso em: Nov. 2006.

GOLDBERG, D.; NICHOLS, D.; OKI, B. M.; TERRY, D. Using collaborative filteringto weave an information tapestry. Commun. ACM, New York, NY, USA, v.35, n.12,p.61–70, 1992.

KAMBA, T.; BHARAT, K.; ALBERS, M. C. The Krakatoa Chronicle: an interactivepersonalized newspaper on the Web. In: 1995. Anais. . . [S.l.: s.n.], 1995. p.159–170.

LIN, C.; ALVAREZ, S.; RUIZ, C. Collaborative recommendation via adaptive associ-ation rule mining. 2000.

LIN, W.-Y.; TSENG, M.-C. Automated support specification for efficient mining of inte-resting association rules. Journal of Information Science, [S.l.], v.32, n.3, p.238 – 250,2006. Association rules;Support specifications;Itemsets;Support constraints;.

LORENZI, F.; RICCI, F. Case-based recommender systems: a unifying view. LectureNotes in Computer Science (including subseries Lecture Notes in Artificial Intelli-gence and Lecture Notes in Bioinformatics), Acapulco, Mexico, v.3169 NAI, p.89 –113, 2005. Case-based reasoning;Recommendation functionalities;Complex architectu-res;.

MARKEY, K.; DEMEYER, A. SEARCHING THE DEWEY DECIMAL CLASSIFI-CATION IN AN ONLINE CATALOG. Proceedings of the ASIS Annual Meeting,Las Vegas, NV, USA, v.22, p.262 – 265, 1985. DEWEY DECIMAL CLASSIFICA-TION;ONLINE CATALOGS;.

MCNEE, S.; ALBERT, I.; COSLEY, D.; GOPALKRISHNAN, P.; LAM, S.; RASHID, A.;KONSTAN, J.; RIEDL, J. the recommending of citations for research papers. 2002.

43

MIDDLETON, S. E.; ROURE, D. C. D.; SHADBOLT, N. R. Capturing knowledge of userpreferences: ontologies in recommender systems. In: K-CAP ’01: PROCEEDINGS OFTHE 1ST INTERNATIONAL CONFERENCE ON KNOWLEDGE CAPTURE, 2001,New York, NY, USA. Anais. . . ACM Press, 2001. p.100–107.

MILLER, B. N.; KONSTAN, J. A.; RIEDL, J. PocketLens: toward a personal recommen-der system. ACM Trans. Inf. Syst., New York, NY, USA, v.22, n.3, p.437–476, 2004.

MONTANER, M. Collaborative Recommender Agents Based on Case-Based Reaso-ning and Trust. 2003.

POPCON. Disponível em: http://popcon.debian.org/. Acesso em: Jun. 2007.

RESNICK, P.; IACOVOU, N.; SUCHAK, M.; BERGSTORM, P.; RIEDL, J. GroupLens:an open architecture for collaborative filtering of netnews. In: Proceedings of ACM 1994Conference on Computer Supported Cooperative Work, 1994, Chapel Hill, North Caro-lina. Anais. . . ACM, 1994. p.175–186.

SALTON, G.; MCGILL, M. J. Introduction to Modern Information Retrieval. NewYork, NY, USA: McGraw-Hill, Inc., 1986.

SARWAR, B. M.; KARYPIS, G.; KONSTAN, J. A.; REIDL, J. Item-based collabo-rative filtering recommendation algorithms. In: WORLD WIDE WEB, 2001. Anais. . .[S.l.: s.n.], 2001. p.285–295.

SURYAVANSH, B. S.; SHIRI, N.; MUDUR, S. P. Improving the Effectiveness of ModelBased Recommender Systems for Highly Sparse and Noisy Web Usage Data. In: WI ’05:PROCEEDINGS OF THE 2005 IEEE/WIC/ACM INTERNATIONAL CONFERENCEON WEB INTELLIGENCE, 2005, Washington, DC, USA. Anais. . . IEEE ComputerSociety, 2005. p.618–621.

TORRES, R. Técnicas para Desenvolver Sistemas de Recomendação na Web. [S.l.]:PPGC-UFRGS, 2003. Trabalho Individual I (Mestrado em Ciência da Computação).

TORRES, R. Combining Collaborative and Content-based Filtering to RecommendResearch Papers. 2004. Dissertação (Mestrado em Ciência da Computação) — PPGC-UFRGS.

TORRES, R.; MCNEE, S. M.; ABEL,M.; KONSTAN, J. A.; RIEDL, J. Enhancing digitallibraries with TechLens+. In: JCDL ’04: PROCEEDINGS OF THE 4TH ACM/IEEE-CS JOINT CONFERENCE ON DIGITAL LIBRARIES, 2004, New York, NY, USA.Anais. . . ACM Press, 2004. p.228–236.

UNESCO. Free Software History. Disponível em:http://www.unesco.org/webworld/portal_freesoft/open_history.shtml. Acesso em:Nov. 2006.

ZINI, E. A cute introduction to Debtags. Disponível em:http://debtags.alioth.debian.org/paper-debtags.html. Acesso em: Jun. 2007.