Os serviços multimédia disponibilizam uma vasta variedade de conteúdos para consumo pelos seus utilizadores. Os consumidores devem ser capazes de encontrar conteúdos adequados aos seus gostos. No entanto, esta tarefa torna-se complicada quando a oferta de conteúdos é demasiado
elevada, o que dificulta a tarefa do utilizador em encontrar conteúdos novos sem conhecimento prévio destes. Por esta razão, e de modo a garantir receitas estáveis, são necessários mecanismos que promovam uma maior interação dos utilizadores com o sistema de modo a manter um nível satisfatório de loyalty. Uma forma de introduzir estes mecanismos é através da construção de um sistema de recomendação.
Em 2015 muitas das grandes companhias já tinham um sistema de recomendação, Amazon, ebay, Yahoo!, Google News, etc. Quando os conteúdos são notícias, existem a vantagem deste conter texto, o que permite a adição de Natural Language Processing NLP para criar features que possam ser utilizadas na recomendação. Isto é uma mais valia, principalmente quando os dados sobre o comportamento dos utilizadores é esparso.
Um exemplo de uso de sistemas de recomendação é a Pandora3, que construiu um modelo de negócio sobre a ideia de criar uma estação de música personalizada, usando uma combinação de abordagens na recomendação, nomeadamente Music Genome Project e filtragem colaborativa [84]. De igual modo, a aplicação Apple’s iTunes utiliza a informação das listas de músicas dos seus utilizadores para personalizar playlists. Spotify também contém o seu sistema de recomen- dação, cuja abordagem passa pela técnica padrão que utiliza factorização de matrizes. Quando a Spotify comprou a startup app EchoNest, combinaram diferentes abordagens, tais como, filtragem colaborativa, metadata e análise de sinais de áudio nas músicas [85]. Na recomendação de mú- sica, encontram-se alguns dados que não existem em outros domínios, nomeadamente os artistas, álbuns, género musical e playlist, nos quais podem ser baseadas as recomendações.
As plataformas de redes sociais também têm seus próprios sistemas de recomendação. O Twitter tem um algoritmo de recomendação que consiste em apresentar contas que o utilizador poderá ter interesse em seguir Who to Follow, [86]. Já o LinkedIn utiliza uma abordagem chamada Survival Analysisque tenta perceber a probabilidade de um utilizador mudar de trabalho [87].
O livro Recommender Systems Handbook [88] refere aspetos de extrema importância, que em contexto académico nem sempre são muito frisados, que podem determinar se um modelo de reco- mendação deve ou não ser aplicado. Estes aspetos são: a flexibilidade do sistema, a escalabilidade, o respeito pelas métricas do negócio, e principalmente que a integração do modelo na plataforma não afete a experiência do utilizador. E, por experiência do utilizador, entende-se que a capacidade de recomendar com sucesso não deve sobrepor-se ao tempo de resposta da plataforma, diminuindo deste modo a satisfação do utilizador, por exemplo este ter de esperar que algum conteúdo seja apresentado enquanto a recomendação está a decorrer.
Netflix Challenge
Um conhecido exemplo do uso de sistemas de recomendação é a Netflix, o maior provedor de conteúdo streaming. A Netflix promoveu um concurso para obter um melhor algoritmo de previsão das classificações dos seus filmes, baseado no seu próprio algoritmo. Em 2006, o desafio Netflix Prizefoi anunciado e consistiu numa competição onde eram usados conceitos de aprendizagem
máquina e Data Mining, na plataforma Kaggle, para prever classificações de filmes numa escala de cinco estrelas. O valor do prémio foi de um milhão de dólares, se o modelo de recomendação reduzisse a métrica Root Mean Squared Error RMSE em 10%, em comparação com o algoritmo base da Netflix. Desta competição surgiram três diferentes abordagens ao problema descritas em [2]–[4], [88]. Os datasets que foram disponibilizados pela Netflix para o concurso Netflix Prize continham os seguintes dados:
• Classificações de filmes, numa escala de 1 a 5 estrelas;
• 17770 Filmes;
• 480189 Utilizadores anónimos;
• 100480507 avaliações
Os vencedores do concurso Netflix Prize combinaram vários algoritmos e técnicas de filtragem colaborativa. O sistema de recomendação da Netflix final é bastante complexo e eficiente, com- binando técnicas de filtragem colaborativa com fatorização de matrizes, e aprendizagem máquina onde são combinados os seguintes métodos [2]–[4]:
1. Automatic Parameter Tuning - APT
2. Movie KNN
3. Time Dependence Models Time
4. Restricted Boltzmann Machine - RBM
5. Global Effects - GE
6. Global Time Effects - GTE
7. Weekday Effect - WE
8. Integrated Model - IM
9. Maximum Margin Matrix Factorization - MMMF
10. NSVD
11. SBRAMF - Special Biased Regularized Asymmetric Matrix Factorization and Extensions
12. SVD with Adaptive User Factors - SVD-AUF Adaptive
13. SVD Trained with Alternating Least Squares - SVDALS
14. Rating Matrix Factorization - SVD
16. Regression on Similarity - ROS
Estes métodos foram utilizados em diferentes fases, levando à construção de múltiplos mode- los, que combinados deram origem ao modelo final, que pode ser assim coniderado um stacked ensemble4.
3.3
Conclusão
A filtragem baseada em conteúdo e a filtragem colaborativa são das técnicas mais utilizadas em sistemas de recomendação. A filtragem baseada em conteúdo não necessita da existência de outros utilizadores, nem da relação entre eles, pois toda a sua lógica se baseia na análise e profiling dos utilizadores e dos itens para posterior relação entre eles. [50]. Como recomenda sempre itens com alguma relação entre si, não é um sistema que consiga recomendar conteúdo inovador para o utilizador. Já a técnica de filtragem colaborativa conta com um histórico de avaliação dos utilizadores, não precisa de classificar nem obter informações sobre os itens. Outra vantagem das técnicas de filtragem colaborativa é a garantia de ser escalável face a uma grande quantidade de itens [89].
A filtragem colaborativa é das abordagens mais utilizadas, pois adicionalmente fornece uma abstração simples de interpretar. Isto é, os utilizadores que consomem o mesmo tipo de conteúdo estão mais próximos, sendo viável utilizar os conteúdo visualizados por uma parte deles para recomendar a outra parte. Em síntese, as técnicas de filtragem colaborativa são as abordagens mais viáveis para sistemas de recomendação em plataformas online. A prova desta afirmação são os bons resultados da recomendação que conseguimos visualizar, por exemplo, na Amazon.com
4Stacked Ensemble - Combinação de diferentes previsões de vários algoritmos de aprendizagem máquina, treinados
Sistema de Recomendação - Tratamento
de dados
O projeto J visa disponibilizar um sistema direcionado ao live streaming de vídeo jogos, onde os utilizadores podem criar o seu próprio canal com conteúdo de terceiros, tais como Twitch e Youtubee ainda moldar a apresentação do ecrã para transmitir vários vídeos num só ecrã. Assim, surge a necessidade de criar interfaces personalizadas e ajudar na seleção do conteúdo a apresentar nos ecrãs. O objetivo deste trabalho passa pela implementação de um sistema de recomendação capaz de se adaptar às alterações dos gostos dos utilizadores a quem se destina. É necessário que o sistema seja capaz de efetuar recomendações, tanto a utilizadores que gerem canais, ajudando na seleção do conteúdo a apresentar, como aos utilizadores que apenas consomem os conteúdos.
4.1
Descrição do Problema
Este projeto foca-se no desenvolvimento de um sistema de recomendação onde é fundamental obter informação sobre o comportamento de consumo de conteúdo por parte dos utilizadores de plataformas de streaming, em temas relacionados com gaming. Assim, o sistema deve ser capaz de capturar as dinâmicas de consumo do utilizador, de modo a extrair padrões comportamentais, que permitam efetuar recomendações úteis para um dado momento da vida do utilizador na pla- taforma. Surgem diversos desafios a ser superados na abordagem a escolher. Em primeiro lugar, devido ao elevado número de conteúdos que os utilizadores podem consumir, existe o problema da esparsidade, que obriga a utilizar formas mais eficientes de representação do espaço em análise. Existem várias formas de superar este obstáculo, passando pela redução da dimensão do espaço, ou pela utilização de representações mais compactas do problema. Em segundo lugar, devido à possível existência de um elevado número de utilizadores que ainda não consumiram uma quanti- dade relevante de conteúdos, existe o desafio do cold start. Para superar este problema, podem ser
utilizadas técnicas capazes de exploração de padrões em dados não relacionados com o conteúdo, nomeadamente língua, país, entre outros.
No caso específico do Projeto J foram exploradas duas plataformas de gaming: Youtube e Twitch.tv, as quais possuem conteúdo multimédia direcionado a gaming, seja em live stream ou video on demand(VOD). A quantidade de potenciais utilizadores destas plataformas é muito ele- vada, encontrando-se na ordem das centenas de milhões. A metodologia desenvolvida focou-se em otimizar a extração de um volume de dados que permitisse recomendar conteúdo próximo dos gostos dos utilizadores, mas que também apresentasse um maior grau de novidade comparativa- mente ao consumo usual do utilizador.
No caso do Projeto J as recomendações serão feitas para dois tipos de utilizadores: consumi- dores de conteúdos e editores de conteúdo, que gerem ecrãs onde podem ser combinadas várias streamse VODs em playlists. Para o primeiro tipo de utilizadores (Consumers) o sistema de reco- mendação a desenvolver deve recomendar screens. Para o segundo tipo de utilizadores (Creators), devem ser recomendados conteúdos das plataformas anteriormente referidas, de modo a auxiliar na construção das playlists de novos screens.
O Youtube e a Twitch.tv impõem limites na utilização das suas APIs, de onde se obtêm as informações de utilizadores e conteúdos, o que obriga a uma estratégia mais inteligente no pro- cesso de recolha de dados, de modo a limitar o impacto destas restrições. Para ultrapassar estas limitações, foi desenvolvido um processo de amostragem de utilizadores e canais, que faz uso de características estruturais das relações entre criadores de conteúdo e consumidores que os se- guem. Isto permite reduzir a quantidade de chamadas a realizar à API para obter uma amostra representativa dos gostos da maioria dos utilizadores da plataforma.
4.2
Proposta de solução
Devido ao estudo realizado durante o estado da arte, foi possível analisar diferentes técnicas usadas em sistemas de recomendação e escolher a mais adequada para este trabalho.
A abordagem escolhida para resolver o problema proposto e ultrapassar os desafios existentes neste domínio, está dividida em sete fases:
1. Análise das APIs e mapeamento dos dados existentes, ver secção4.3
2. Uniformização da representação dos dados independente da fonte de dados,4.3.1
3. Estratégia de amostragem, ver secção4.3.2
4. Extração dos dados, ver subsecção4.4.1.1
5. Modelação dos dados numa base de dados multidimensional, ver subsecção4.4.1.2
6. Exploração de modelos de recomendação e definição da metodologia a utilizar, ver capítulo 5
7. Definição de um critério de validação aplicável no domínio da recomendação, ver secção 5.3
8. Análise de resultados, ver secção5.4
Na fase de análise das plataformas de streaming foram consultadas as várias informações disponibilizadas pelas suas APIs públicas. Isto permitiu identificar quais os dados disponíveis em cada uma das plataformas e selecionar os atributos relevantes para o sistema de recomendação. Visto que ambas as plataformas têm representações distintas dos dados, foi necessário proceder a uma análise que permitiu mapear os dados de cada uma das fontes para uma representação uniforme e independente da plataforma.
Como referido anteriormente, um dos maiores obstáculos na obtenção dos dados é garantir que a amostra extraída é representativa dos gostos dos utilizadores das plataformas. A estratégia de amostragem implementada passa por um processo recorrente que é inicializado com o TOP-5 de criadores de conteúdos com mais seguidores. Deste conjunto inicial de utilizadores são extraídos todos os seus seguidores. Destes seguidores são selecionados, novamente, os TOP-5 criadores com mais seguidores. Este processo repete-se até ser atingindo um volume de dados que permita efetuar os desenvolvimentos necessários para este projeto. Esta estratégia foi implementada no crawler 4.4.1.1tendo em conta as restrições das APIs, assim como o mapeamento prévio e uniformização dos dados. Este desenvolvimento permite a obtenção dos dados das plataformas com um processo de limpeza prévio à inserção na área de staging do datawarehouse, e implementa uma estratégia de resiliência a falhas com um back off linear, que consiste em ir aumentando linearmente o tempo de espera entre tentativas até atingir a limitação do número de tentativas.
Os dados recolhidos têm de ser armazenados de uma forma eficiente, já uniformizados e nor- malizados, de modo a permitir o seu acesso rápido, para alimentar o sistema de recomendação, assim como outras estatísticas para o Projeto J. Para este efeito, foi modelado um datawarehouse dividido em duas áreas: staging para dados a processar e um esquema multidimensional para a representação dos dados nas dimensões que serão analisadas. O volume de dados extraído excede os 200GB em disco, pelo que foi necessário adotar técnicas usualmente utilizadas para gerir e processar elevados volumes de dados (Big Data), de modo a ser possível efetuar a preparação e manutenção dos mesmos. Nomeadamente, foi necessário efetuar o pré-processamento dos dados de modo incremental para não exceder a memória principal do servidor na fase de crawling.
Na escolhas da metodologia de recomendação a utilizar foram exploradas diversas abordagens de modelação capazes de ultrapassar os desafios anteriormente mencionados, e acrescentar valor ao Projeto J. De entre as metodologias exploradas, foi escolhida aquela que melhor se adequa às necessidade do projeto e que possui melhor desempenho quer computacional quer em termos de resultados. Para avaliar os resultados obtidos, foram pensadas duas estratégias possíveis: uma primeira estratégia consiste em apresentar as recomendações a utilizadores e verificar o seu se- guimento; uma segunda estratégia é efetuar a avaliação com base no histórico de preferências de
conteúdos dos utilizadores. Como o sistemas ainda não possui um volume de utilizadores sufi- ciente para a primeira estratégia de validação, foram obtidos dados da plataforma Twitch.tv para realizar a validação de acordo com a segunda estratégia referida.
4.2.1 Arquitetura
Após o estudo do problema e do levantamentos dos requisitos técnicos, foi realizada a mode- lação do problema e definida a arquitetura do sistema, que está representada na figura4.2. Neste processo foi adoptada uma abordagem iterativa, como já referido na secção2.2, uma vez que ao longo da descoberta dos dados houve a necessidade de ir adaptando a solução ao problema. A figura4.1ilustra o ciclo da abordagem iterativa que foi seguida.
Figura 4.1: Abordagem iterativa
A arquitetura definida responde aos requisitos de integração com o Projeto J, nomeadamente, a existência de uma API que permite realizar pedidos de recomendação para os dois tipos de utilizadores do Projeto J. O sistema desenvolvido é composto por quatro partes: Processo de crawling, Sistemas de gestão de base de dados, um middleware que expõe a API, e o sistema de recomendação.
Figura 4.2: Arquitetura geral
A lista seguinte enumera as ferramentas mais importantes usadas no desenvolvimento do sis- tema:
• Processo de Crawling: Desenvolvido em NodeJS
• Sistema de Gestão de Base de Dados: PostgreSQL, plpg/SQL para funções, utilização de chamadas ao sistema CURL, expressões regulares, e CRON para scheduling de processos de base de dados
• Middleware: NodeJs para implementação da API e Varnish para caching, por uma questão de tempos de resposta e redução de recursos necessários
• Sistema de Recomendação: Desenvolvido em Python com auxílio das ferramentas:
– Scikit-Learn: Implementação das metodologias de recomendação
– Networkx, Hypernetx e Matplotlib: Manipulação e visualização da rede de comunida- des
– Numpy e Pandas: Preparação de dados e operações algébricas com matrizes e vetores
• Alguns testes e validações foram realizados em R, no Excel e no Gephy
No sistema existem dois atores base: utilizadores que consomem conteúdos, Consumers, e aqueles que constroem ecrãs para consumo, Creators. A interação do utilizador é tratada pelo Projeto J, e este, por sua vez, efetua pedidos de recomendação à API do sistema de recomendação. Os pedidos executados pelo Projeto J devem especificar o tipo de ator para o qual se pretende a recomendação. Desta forma, o sistema de recomendação consegue mapear a recomendação para ecrãs ou vídeos. Esta interação é representada no diagrama da figura4.3.
Figura 4.3: Atores
No diagrama de sequência, presente na figura4.4, encontra-se o fluxo de toda a comunicação entre as várias entidades presentes no Projeto J. O sistema de recomendação está preparado para recomendar de um modo relativamente uniforme para ambos os tipos de atores, o que permite ilustrar os fluxos de ambos no mesmo diagrama.
Figura 4.4: Diagrama de sequência
Quando um utilizador efetua o login no Projeto J, o fluxo pode tomar dois caminhos distintos. Para o caso dos utilizadores que tenham acabado de efetuar o registo, existe a necessidade de se
obter informações sobre os conteúdos desses utilizadores nas plataformas. Neste caso, o processo de recomendação é agendado até os dados estarem disponíveis, e o utilizador tem acesso a uma user interface(UI). Esta UI será populada com recomendações quando o processo de recomen- dação for executado. Para o caso dos utilizadores para os quais já existam informações sobres os conteúdos, consumidos ou criados, o processo de recomendação pode executar imediatamente e é-lhes apresentado uma UI personalizada já com recomendações.
4.3
Dados
Em ambas as plataformas utilizadas para extração de dados (Youtube e a Twitch.tv), existe uma grande variedade de informação, mas alguma dessa informação possui acesso limitado apenas a aplicações que contenham autorização do utilizador. No trabalho atual isso não constitui um problema, pois os dados necessários para uma boa recomendação podem ser acedidos apenas com o authentication token da aplicação.
4.3.1 Normalização e Uniformização
Visto que este trabalho aceita dados de duas plataformas distintas, existe a necessidade de construir uma representação uniforme que permita a independência da implementação em relação à origem dos dados. A tabela 4.1, apresenta os atributos extraídos das duas plataformas, e a correspondência com os atributos finais já uniformizados.
Twitch YouTube RS User User User Channel Channel Channel
Collections Channel Section Relação entre vídeos e canais Videos Videos Vídeos
Games Guide Categories Categorias
Tags Tags
Chat/Descrição Comments/Descrição
Tabela 4.1: Uniformização dos dados de ambas as plataformas
Na tabela4.2encontra-se a descrição de cada atributo, e a indicação da quantidade de dados utilizados.
RS Quantidade Descrição
User 28 427 114 Utilizadores, podem tem canais ou seguir ca- nais
Channel 162 640 Canais
Relação entre vídeos e canais 254 676 Lista de vídeos de um canal
Vídeos 260 697 Vídeos pertencem a canais e têm categorias e tags associadas. As streams passam a ser ví- deos depois da transmissão
Categorias 5 856 Categorias atribuídas a canais e vídeos Tags 13 754 Tags atribuídas a canais e vídeos
Texto Texto que pode ser utilizado para text mining. Obtidos das descrições, nomes, comentários ou até mesmo do chat
Tabela 4.2: Descrição dos dados
Uma vez que as categorias extraídas da Twitch são semi-curadas, permitindo que o utilizador crie novas quando não encontra a categoria que procura, pode ocorrer causa alguma incoerência, pois podem existir categorias com o mesmo nome mas escritas de forma diferente (o mesmo acontece com as tags). Para ultrapassar este problema, foram aplicadas expressões regulares, visíveis na listagem de código4.1, que transformam as letras capitalizadas no seu equivalente sem capitalização. Também foi aplicado uma transformação para remover a acentuação dos carateres. Foram ainda eliminados espaços desnecessários, assim como símbolos e números.
1 trim( 2 regexp_replace( 3 regexp_replace( 4 unaccent( 5 lower("name")), 6 ’\W+’, ’ ’,’g’), 7 ’ +’,’ ’,’g’) 8 )
Listing 4.1: Expressão regular em SQL
4.3.2 Amostragem
A amostragem por conveniência, exposta na subsecção2.4.2, foi a estratégia de amostragem utilizada neste trabalho para efetuar a extração de dados dos utilizadores da plataforma Twitch. É efetuada uma pré-seleção dos top-n utilizadores com mais seguidores, neste caso considera- se n = 10. Para cada um destes utilizadores é obtida, através da API da plataforma, a lista de seguidores. Deste novo conjunto de utilizadores, são selecionados os top-k com mais seguidores
e colocados numa fila para processamento, tendo sido escolhido k = 5 nesta implementação. Este processo é repetido até se obter um volume de utilizadores que não ultrapassasse os recursos de espaço que foram disponibilizados para a solução a desenvolver (200GB).
A figura 4.5 exemplifica o processo de amostragem. Na fase A, são obtidos os seguidores para cada utilizador que está a ser processado. Na fase B, são selecionados os k utilizadores com