1. REDES COMPLEXAS 2016/17PROJECTO 1
GRUPO 22
CARINA ANTUNES Nº73161
DIOGO NICOLAU Nº72935
RECOMENDAÇÃO DE APLICAÇÕES ANDROID
ANÁLISE E AVALIAÇÃO DO DATASET REAL COMO UMA REDE COMPLEXA
Introdução
Lojas online procuram cada vez mais reter os seus clientes. Seja através de atrativas
promoções ou novos e exclusivos produtos, qualquer market online acaba inevitavelmente por se
deparar com um problema amplamente conhecido: como apresentar novas ofertas a utilizadores já
saturados de informação? Muitos markets online, desde filmes a sabonetes, procuram apresentar as
suas ofertas da forma mais eficiente possível. A pequena janela de interesse dos utilizadores obriga a
um refinamento quase mágico das ofertas a apresentar e que de certa forma entenda os utilizadores,
prevendo os seus interesses e as suas tendências de compra.
A solução encontrada passa por sistemas de recomendação, um ramo de information retrievel
que muito tem crescido desde o “boom” de machine learning. Juntando diferentes técnicas de
predição e filtragem é possível apresentar resultados personalizados a cada utilizador.
Acontece que avaliar diferentes sistemas de recomendação não é imediato. Uma boa recomendação
é algo subjetivo, como tal não existe uma fórmula única que solucione este problema. Atualmente
existem diferentes métricas de avaliação, tais como: RMSE, DCG e prediction/recall[1]. Cada uma
destas métricas procura cobrir diferentes aspetos da recomendação, no entanto nenhuma avalia a
diversidade e distribuição dos resultados. É aqui que entra o estudo de Redes Complexas. Neste
relatório iremos demonstrar como as métricas utilizadas na avaliação de networks poderão também
servir os sistemas de recomendações.
Tecnologia e Dataset usados:
O dataset é descrito como 110 mil aplicações e as suas 40 aplicações mais semelhantes, obtido
da utilização de aplicações android de cerca de 11 milhões de utilizadores. São consideradas
semelhantes as aplicações utilizadas por utilizadores que partilhem os mesmo padrões de utilização
1[2]
. Consideramos assim cada aplicação como um nó. Já quanto a arcos se considerarmos a network
direcionada podemos contar com arcos para fora e arcos para dentro, sendo os arcos-fora duma
aplicação as ligações das 40 recomendadas por esta, e arcos-dentro as ligações das aplicações que
recomendam esta mesma aplicação.
Para trabalhar com este dataset tentámos inicialmente o software Gephi mas rapidamente
percebemos que este não iria suportar a dimensão dos nossos dados. Assim decidimos utilizar a
plataforma Webgraph, a qual já demonstrou ser capaz de trabalhar dados bem maiores que o nosso
sem comprometer a simplicidade de utilização. Começando por carregar o nosso dataset existiu a
necessidade de transformar os nossos dados no formato:
1,(33031,0.9854372),(53525,0.9837637),(6937,0.98257303) …
2,(91318,0.9815927),(98841,0.9811823),(22338,0.98085517) …
3,(51127,0.99526876),(79391,0.9945507),(31703,0.9943191) …

2. onde o primeiro valor é o ID da aplicação e entre parênteses as aplicações recomendadas e os
respetivos valores de similaridade, em:
108910
79 1076 6936 7608 …
53524 55778 62215 62434 …
52 87 114 609 …
Sendo a primeira linha o número total de nós, seguindo-se por linha as recomendações de
cada aplicação ordenadas por ordem crescente. De forma a gerar este formato foi preciso
implementar em java uma simples classe (em anexo) que lê o nosso ficheiro input e produz um novo
ficheiro no formato desejado. Fazendo uso da classe it.unimi.dsi.webgraph.BVGraph produzimos os
ficheiros necessários ao uso da classe ConnectedComponents seguida de it.unimi.dsi.webgraph.Stats.
Feito isto obtemos um conjunto de ficheiros com informações bastante relevantes e também as
distribuições de degree. Podemos ainda fazer uso da implementação existente do algoritmo HyperBall
que devolve estimativas das distâncias entre vizinhos, e mais tarde utilizar os resultados com a classe
ApproximateNeighbourhoodFunctionStats e assim obter ainda mais informações sobre a nossa
network.
Resultados
Começamos por analisar o ficheiro “.stats” e os seus valores. A tabela em baixo relata como podem
as métricas deste ficheiro colaborar na avaliação de um sistema de recomendações:
nodes=108910
arcs=4285308
loops=36
 Como esperado o número de nós e arcos corresponde ao nosso
dataset inicial.
 O valor de loops é consideravelmente baixo, o que pode ser traduzido
em poucos ciclos fechados de aplicações a recomendarem-se entre
elas. Do ponto de vista da qualidade de recomendação isto é algo que
se procura.
minoutdegree=0  Caso em que a recomendação falha e não apresenta qualquer
resultado.
maxoutdegree=40  Como esperado, uma vez que "obrigamos" que cada aplicação crie 40
arcos para fora.
avgoutdegree=39.347
24084106143
 Pode ser tratado como uma métrica de forma a perceber quantas
aplicação não recomendaram o número esperado de aplicações
dangling=1
terminal=1
percdangling=9.1818
9330639978E-4
 Através de dangling percebemos quantas aplicações não recomendam
nem são recomendadas. Em príncipio queremos o menor valor
possível, uma vez que procuramos a maior diversividade possível no
nosso sistema.
minindegree=0
minindegreenode=108
909
 Aplicação nunca recomendada.
maxindegree=9750
maxindegreenode=346
88
 Aplicação mais recomendada

3. avgindegree=39.3472
4084106143
 Número médio de vezes que uma aplicação é recomendada. Este valor
por ser estranhamente exactamente igual ao avgoutdegree levantou
algumas suspeitas no grupo.
sccs=1
maxsccsize=108910
minsccsize=108910
 Apenas existe 1 componente fortemente ligado, que se traduz no
dataset todo. Idealmente teriamos diversos componentes a
representar categorias diferentes.
 Esta pode ser uma boa métrica, a qual podemos procurar aumentar e
assim garantir que por exemplo: um jogo apenas recomenda jogos.
 Para testar esta métrica imediatamente podiamos reduzir de 40 mais
semelhantes para 10, reduzindo algumas recomendações residuais.
Seguindo para o cálculo aproximado das distâncias entre vizinhanças podemos fazer uso dos
resultados devolvidos pela classe ApproximateNeighbourhoodFunctionStats. Para obter estes
resultados tivemos de correr o algoritmo HyperBall[3] o qual produz iterativamente o número de pares
de nós à distância t. Devido ao elevado consumo de memória, este algoritmo faz uso de técnicas
modernas como HyperLogLog que obriga ao uso de valores aproximados. Por este motivo
computamos o algoritmo HyperBall 5 vezes, minimizando o erro no cálculo das distâncias.
Dito isto recolhemos os seguintes resultados:
average distance: 3.7955519291892466 (+/- 0.006159179123813056)
effective diameter: 3.982939947577784 (+/- 0.004990141224530469)
harmonic diameter: 3.9956615731924154 (+/- 0.024043508889339964)
shortest-paths index of dispersion: 0.10258390989262252
Estes resultados demonstram que o utilizador estaria à distância de 4 recomendações para
chegar a qualquer aplicação presente no dataset. Este valor pode ser determinante nas decisões de
quem cria a user experience dum sistema de recomendações.
Ainda podemos classificar a nossa rede através do SPID como properly social[3], visto que este
valor é menor que 1. Estas redes favorecem ligações curtas, ao contrário de redes web-like onde
ligações longas não são incomuns. Uma experiência interessante seria calcular esta mesma métrica
para recomendações geradas por motores baseados em conteúdo, uma vez que estas
recomendações seguem um modelo baseado em padrões de utilização.

4. Fazendo plot com R dos ficheiros out e indegree(s) obtemos os gráficos que nos permitiram
tirar as seguintes conclusões:
 Do ficheiro outdegree obtemos a distribuição que nos permite visualizar que apesar
da maior parte das aplicações ter 40 ligações para fora, nem todas têm. Do ficheiro
outdegrees obtemos a densidade, que confirma este mesmo facto. Vem confirmar o
valor apresentado anteriormente para o average out degree perto de 40.
 Do ficheiro indegrees obtemos também a densidade para as ligações para uma
aplicação. Visualizamos que a maioria das aplicações são recomendadas poucas vezes,
existindo no entanto alguns outliers claramente visíveis. Em especial 6 aplicações
recomendadas perto de 10000 vezes. Estes dados seriam interessantes para o
refinamento do sistema de recomendação, possibilitando a remoção de aplicações
presente em quase todos os padrões de utilização.
 Por fim, do ficheiro indegree obtemos o gráfico de distribuição, ao qual aplicamos um
logaritmo em cada eixo, permitindo complementar as conclusões anteriores com a
visualização de uma aproximação a uma power law. Este facto permite-nos concluir
que a nossa rede se aproxima de uma rede scale free[4], em que existem poucos nós
com muitas ligações, tendo a maior parte deles poucas.
A intuição por trás destes valores diz-nos que sendo recomendações com base em
padrões de utilização, iriam existir poucas aplicações usadas pela maior das pessoas
(redes sociais, utilidades, tendências, etc), comum à maior parte dos padrões,
complementadas por aplicações outliers comum a poucos padrões. Previa-se assim
uma rede scale free, visto que quase todos os outliers terão incluídos nos seus nós de
recomendações estas aplicações padrão.

5. 
Referências
1. Avazpour, Iman; Pitakrat, Teerat; Grunske, Lars ; Grundy, John (2014), “Dimensions and Metrics for
Evaluating Recommendation Systems” in Recommendation Systems in Software Engineering, pp 245-
273. – http://www.ict.swin.edu.au/personal/jgrundy/papers/rsse2014.pdf
2. Ekstrand, Michael; Riedl, John; Konstan, Joseph. (2011), "Collaborative Filtering Recommender
Systems", Foundations and Trends® in Human–Computer Interaction: Vol. 4: No. 2, pp 81-173. –
http://dx.doi.org/10.1561/1100000009
3. Boldi, Paolo; Rosa, Marco; Vigna, Sebastiano (2010), “HyperANF: Approximating the Neighbourhood
Function of Very Large Graphs on a Budget” – arXiv:1011.5599 [cs.DS]
4. Barabási, Albert-László; Bonabeau, Eric (May 2003), “Scale Free Networks” –
http://barabasi.com/f/124.pdf