Sistema de recomendação de TV

F

E

U

P

Sistema de recomendação TV

João Pereira

Programa de Mestrado integrado em Engenharia Electrotécnica e de Computadores Orientador: Maria Teresa Andrade (PhD)

Co-orientador: Telma Mota (MSc)

c

Resumo

Domínios como a televisão alteram-se todos os dias, torna-se difícil para um utilizador estar actualizado com tudo o que se passa. A tendência é muitas vezes ignorar esse crescimento e ficar pelo que se conhece, os mesmos canais e os mesmos programas. Nos piores casos há quem recorra apenas aos domínios Web para fazer download dos programas que gosta.

Neste documento será apresentada uma implementação de um sistema de recomendação para televisão a partir de informação recolhida pelas STB (Set-top-box) Meo. A recomendação é tecni-camente filtragem de informação, neste caso de conteúdo, com o objectivo de ajudar utilizadores a descobrir novos programas que gostem.

A informação recolhida das STB permite detectar as preferências dos utilizadores e construir sobre eles um perfil. Conhecendo os gostos é então possível inferir e recomendar todo leque de produtos que a televisão tem para oferecer. Aqui o trabalho realizado cobre apenas programas, inferindo sobre o seu tipo, géneros e ainda os canais em que costumam passar.

O conteúdo visualizado é extraído das STB em formato XML. Este conteúdo contém infor-mação sobre a data e hora de visualização, título, sinopse, canal e duração total. Caso se detecte uma visualização, o algoritmo classificá-la-á sob determinados géneros que dependem do tipo de programa e análise da sinopse, se tal não for possível e se o programa for filme ou série o al-goritmo irá tentar extrair informação sobre os géneros ao Website IMDB. Com as visualizações actualiza-se então o perfil do utilizador/histórico.

Por outro lado, tem-se a informação recolhida dos EPG que inclui informação alargada sobre a lista de candidatos a classificação. Esta lista de candidatos é classificada do mesmo modo que as visualizações. Na presença da lista de candidatos prossegue-se então à filtragem (classificação) de conteúdo que origina a lista final para recomendação.

O trabalho realizado nesta dissertação será apenas um ponto de partida para um motor bem mais robusto possivelmente integrando filtragem colaborativa. As suas aplicações poder-se-ão es-tender além dos programas normais, como na publicidade direccionada ou reforçando um serviço pay-per-view.

Abstract

Domains like the television suffer changes every day, it becomes difficult for a user to be up to date with everything that is happening. The trend most of the times is ignoring that growth and simply watch what’s familiar, the same channels and the same programs. In the worst cases, some turn solely to Web domains in order to download the programs they like.

In this document will be presented an implementation of a television recommender based on information retrieved from the Meo STB (Set-top-box). Recommendation is technically informa-tion filtering, content-based in this case, whose main goal is helping the users to discover new programs they might like.

The information extracted from the STB allows the detection of the preferences of the users and build upon them a profile. Knowing their tastes it is then possible to infere and recommend all the products that the television has to offer. The work developed covers only programs, infering about their type, genres and even channels.

The watched content is extracted from the STB in XML format. This content contains infor-mation about the time and date of the visualization, title, synopsis, channel and total duration. If a visualization is detected, the algorithm will classify it according to certain genres which depend on the type of the program and its synopsis, in case that fails and if the type of the program is film or serie the algorithm will then try to extract the information required to the Website IMDB.

On the other hand, there’s the information available in the EPG which include more informa-tion about the list of the candidates to the classificainforma-tion. This list of candidates is classified the same way as the visualizations. Having the list of candidates it is then possible to filter it according to it’s content. The result is a final list for recommendation.

The work developed on this dissertation is only the beginning for a more complex recommen-dation system which most likely will integrate collaborative filtering. This work can be useful also for possible extensions beyond normal programs, like targeted publicity or to reinforce a pay-per-view service

Agradecimentos

Em primeiro lugar gostaria de agradecer à minha orientadora Maria Teresa Andrade pelas oportunidades que me disponibilizou. Foi graças a ela que obtive a minha experiência como colaborador do INESC e a junção do projecto à PT Inovação, para além disso gostaria também de agradecer o seu aconselhamento que me guiou durante a os últimos meses.

Em seguida, gostaria de agradecer aos meus pais e especialmente a minha mãe que sempre me apoiou e me deu confiança para ultrapassar as barreiras, não só agora mas sempre durante todo o curso.

Finalmente, a todos os meus colegas que tal como eu, encontram-se nesta etapa final do curso e ajudaram a manter um bom espírito no decorrer dele.

João Pereira

"We are leaving the Age of Information and entering the Age of Recommendation"

Chris Anderson - Editor chefe da revista Wired

Conteúdo

2 Levantamento do Estado da Arte 5 2.1 Metadados em Televisão . . . 5 2.1.1 MPEG-7 . . . 5 2.1.2 DVB-SI . . . 6 2.2 Sistemas de recomendação . . . 7 2.2.1 Content-based . . . 8 2.2.2 Collaborative-based . . . 10 2.2.3 Hybrid-based . . . 14

2.2.4 Capacidade de expansão/melhoramento dos recomendadores . . . 14

2.3 Análise e escolha . . . 16

3 Descrição do Sistema 17 3.1 Introdução . . . 17

3.2 Visão geral . . . 17

3.3 Descrição . . . 18

3.3.1 Classificação das visualizações . . . 18

3.3.2 Extracção de candidatos . . . 20

3.3.3 Perfil de utilizador . . . 23

3.3.4 Motor de recomendação . . . 24

3.3.5 Gestão da lista final . . . 25

3.4 Sumário . . . 26

4 Análise e trabalho futuro 27 4.1 Introdução . . . 27 4.2 Casos de utilização . . . 27 4.2.1 Descrição . . . 28 4.2.2 Simulação . . . 30 4.3 Comportamento . . . 34 4.4 Trabalho futuro . . . 34 5 Conclusão 37 5.1 Conclusão . . . 37 xi

xii CONTEÚDO

A Descrição das técnicas 39

A.1 Família Bayes . . . 39

A.1.1 Naïve Bayes . . . 39

A.1.2 Redes de Bayes . . . 40

A.2 Clustering . . . 40

A.3 Árvores de decisão . . . 41

A.3.1 Algoritmo de Hunt . . . 41

A.4 Redes neuronais . . . 41

A.4.1 Redes planares . . . 42

A.4.2 Redes por camadas . . . 42

A.5 Regressao linear . . . 43

A.5.1 Método dos mínimos quadrados . . . 43

A.6 K Vizinho mais próximo . . . 44

A.7 Teoria de grafos . . . 44

A.8 TF-IDF . . . 44 B Listas de géneros 47 B.1 Filme e série . . . 47 B.1.1 Drama . . . 47 B.1.2 Horror . . . 47 B.1.3 Fiction . . . 47 B.1.4 Comedy . . . 47 B.1.5 Action . . . 48 B.2 Desporto . . . 48 B.2.1 Tennis . . . 48 B.2.2 Football . . . 48 B.2.3 Motor . . . 48 B.2.4 Basketball . . . 48 B.2.5 Handball . . . 48 B.2.6 Athletics . . . 48 B.2.7 Hipismo . . . 48 B.3 Informativo . . . 48 B.3.1 News . . . 48 B.3.2 Documentary . . . 48 B.3.3 Weather . . . 49

C Imagens de execução do programa 51 C.1 Actualização dos EPGs . . . 51

C.2 Classificação dos candidatos . . . 52

Lista de Figuras

3.1 Arquitectura de nível superior - Serviços de valor acrescentado PT Inovação . . . 18

3.2 Modelo geral do sistema de recomendação . . . 19

3.3 Extracção de candidatos . . . 21

3.4 XML exemplo de um programa . . . 22

3.5 Excerto exemplo de formatação do perfil para data e géneros . . . 24

3.6 Motor de classificação . . . 25

3.7 Gestão da lista final . . . 26

4.1 Casos de utilização . . . 28

4.2 Diagrama de classes . . . 29

4.3 Perfil de teste utilizado . . . 31

4.4 Excerto de programas formatados pré-recomendação . . . 32

4.5 Resultado de recomendação . . . 33

A.1 Modelo de neurónio básico extraído de (Moreira,1997) . . . 42

C.1 Actualização dos EPG em decurso . . . 51

C.2 Classificação dos candidatos e geração de recomendação . . . 52

Abreviaturas e Símbolos

AI Artificial intelligence

DM Data Mining

DVB-SI Digital Video Broadcasting - Service Information EPG Electronic Programming Guide

GPS Global Positioning System HCI Human-Computer interaction IA Inteligência Artificial

IMDB Internet Movie Database IR Information Retrieval

ML Machine Learning

MPEG Moving Picture Experts Group NBC Naïve Bayes Classifier

STB Set-top-box

SMIL Synchronized Multimedia Integration Language TF-IDF Técnica de classificação de texto

TV Televisão

Web ou WWW World Wide Web

XML Extended Markup Language

XMPP Extensible Messaging and Presence Protocol

Capítulo 1

Introdução

Neste capítulo introduz-se a dissertação começando por um breve texto de motivação seguido da relevância no contexto. Os objectivos são estabelecidos em terceiro lugar e finalmente será apresentada a estrutura do documento.

1.1

Motivação

A personalização é uma palavra cada vez mais comum no dia-a-dia. Todos gostam que bem os sirvam e compreendam, seja em que contexto for. Ainda assim, é complicado não falar em componente humana aquando se fala de personalização, sem ela dificilmente se compreendem os desejos dos utilizadores. Adicionalmente tirar conclusões sobre a personalidade humana do ponto de vista da máquina é sempre arriscado por diversas razões. Os seres humanos são imprevisíveis muitas vezes e mudam as suas preferências de acordo com o estado de espírito actual, ou mesmo, porque alguns conceitos podem estar fora de moda (ou não!). Ainda para além disso, quer-se que uma única máquina seja capaz de reconhecer os diversos utilizadores que a utilizam, que poderão ser de idades ou mentalidades bem diferentes.

Como se pode ver inputs é que não faltam num sistema em que se pretende modelizar os utilizadores. Por isso hoje em dia muito esforço é dedicado a áreas como ML e AI. O cérebro humano é ainda uma "máquina"incompreensível para um computador, no entanto espera-se que ao repartir e classificar todo o tipo de tarefas por diferentes unidades de processamento especializadas e correctamente interligadas, um dia talvez possa ser possível que um computador compreenda o ser humano como que um velho amigo.

1.2

Contexto

Um domínio bem popular como a TV alarga o seu conteúdo quase dia-a-dia, os canais tentam acompanhar celeremente a actualidade e novos serviços são criados com objectivo de criar valor.

2 Introdução

O problema é que para os utilizadores já é stressante o suficiente o trabalho que levam no do dia-a-dia e não há tempo para acompanhar o que se passa no domínio da TV. Uma solução óbvia é recorrer a outros para recomendação ou ficar pelo que se conhece. Para alguns até, a TV deixou de ser a principal fonte de entretenimento pós-laboral ou então é vista como "frustrante"que mais vale recorrer à Web para atingir o que se quer. Felizmente, na presença de evoluções tecnológi-cas que fornecem metadados úteis e a fim de recolher mais informação sobre as preferências dos utilizadores e de direccionar a informação certa até às pessoas certas, existem métodos que per-mitem às máquinas utilizar a sua capacidade de processamento e filtrar a imensa quantidade de informação, de modo a atingirem resultados satisfatórios no cumprimento de tal objectivo.

Neste trabalho no entanto, os gostos não serão directamente questionados mas sim inferidos através da observação do comportamento do utilizador, tal se denomina como construção de um perfil implícito. As STB permitem a transferência de metadados periodicamente sobre o programa visualizado na hora. Se se estabelecerem algumas regras eficientes quanto à classificação do que é visto e do que não é, é então possível extrair o conteúdo relevante através dos metadados e proceder-se a uma selecção de candidatos que possam satisfazer as preferências do utilizador. A este tipo de abordagem chama-se recomendação baseada em filtragem de conteúdo.

1.3

Objectivos

O objectivo principal é o desenvolvimento de um sistema de recomendação que integre fil-tragem de conteúdo, aplicado no domínio da TV. Começar-se-á por escolher e treinar um clas-sificador para conteúdo baseado num perfil de teste. A razão para o uso de dados de teste de utilizador deve-se principalmente a limitações iniciais quanto à disponibilização imediata dos da-dos das STB. Todo o trabalho desenvolvido terá então maior foco nos restantes requisitos.

Em paralelo ter-se-á como requisito a versatilidade do código que permita a sua fácil adap-tação a outro contexto que não a TV, como por exemplo viagens, restauração ou outro qualquer que inclua informação possível de classificar quanto às suas características. Dado que se de-sconhece a princípio a estrutura dos dados a serem tratados, criar-se-ão formatações "internas"ao algoritmo que necessitarão posteriormente de adaptação para que seja possível a integração com a informação fornecida.

Dada a informação limitada disponibilizada nos EPG sobre os programas será também necessário desenvolver um módulo para classificá-los quanto aos géneros, visto que estes baseiam-se mais nas sinopses disponibilizadas que muitas vezes não permitem a sua correcta classificação.

Finalmente após a estipulação dos formatos sobre o qual o motor de classificação irá operar e na presença dos programas candidatos correctamente classificados, proceder-se-á então ao desen-volvimento dos módulos de classificação baseados no teorema de Bayes, para géneros e data, tipo e canal. A razão de tal escolha será discutida adiante no capítulo2.

Desenvolvido este trabalho proceder-se-á à integração no context broker da PT que gere toda a informação. Mais informação sobre o enquadramento será discutida no capítulo3.

1.4 Estrutura da Dissertação 3

1.4

Estrutura da Dissertação

Para além da introdução, esta dissertação contém mais 4 capítulos:

• No capítulo 2, é descrito o estado da arte e são apresentados trabalhos relacionados, bem como explicada a razão de algumas escolhas tomadas.

• No capítulo3, tem-se o desenho do sistema, começando com uma visão geral e enquadra-mento seguida pela descrição da implementação.

• No capítulo4, é feita uma pequena análise sobre o que se encontra feito e é discutido tópicos de trabalho futuro.

Capítulo 2

Levantamento do Estado da Arte

Neste capítulo é apresentada a actualidade no que toca a sistemas de recomendação. Mas antes de entrar concretamente nesse mundo é feita uma breve apresentação dos sistemas que possibil-itarão a aplicação das técnicas de recomendação. Finalmente é feito um sumário de justificação das escolhas tomadas.

2.1

Metadados em Televisão

2.1.1 MPEG-7

Este standard tem como principal objectivo a descrição do conteúdo multimédia. Isto é pos-sível graças aos diversos elementos que o constituem (Li e Drew,2004) que são essencialmente os seguintes:

• Um descritor que especifica a representação de características multimédia de conteúdo que vão desde o baixo nível audiovisual até características semânticas de alto nível.

• Esquemas de descrição que permitem a combinação de descritores individuais. Estes esque-mas definem o desenho e a semântica das relações entre os componentes.

• A linguagem de descrição baseada em XML que facilita a especificação dos descritores e dos seus esquemas.

O MPEG-7 disponibiliza ferramentas que permitem criar, descrever, indexar, procurar, usar, guardar e gerir conteúdo multimédia. Para além disso permite ainda incluir informação extra tal como perfis de utilizador, acesso de dados ou direitos de consumo.

2.1.1.1 TV-Anytime

É uma aplicação que engloba diversos cenários de utilização do MPEG-7. Tem como objectivo o desenvolvimento de um conjunto de especificações que satisfazem as necessidades dos actores

6 Levantamento do Estado da Arte

do domínio TV tais como produtores, provedores de conteúdo, consumidores e publicitadores. TV-Anytimeinclui definições direccionadas às áreas dos metadados e referenciamento do conteúdo e é desenhada em duas fases. A primeira fase tem em vista a criação de metadados, procura baseada em características para programas, acesso aos horários da TV, adição de informação de segmentação para conteúdo gravado e agregação de metadados. A segunda fase então focar-se-ia em target advertising, distribuição de conteúdo e inclusão de outro tipo de medfocar-se-ia tal como websites, música ou jogos.

São definidos os seguintes tipos de metadados:

• Descritor de conteúdo: cobre atributos como título, descrição e géneros.

• Descritor de instâncias: inclui informação quanto a localização, condições de utilização e formato do conteúdo audiovisual.

• Descritor de consumidor: contém informação quanto às preferências do utilizador e histórico de utilização.

Há também suporte de exploração de características mais avançadas tal como gravação de conteúdo, através da segmentação de programas e funções de referenciação.

Infelizmente ferramentas como MPEG-7 ou TV-Anytime ainda não estão disponíveis nos equipamentos, ou pelo menos como o desejado. Encontram-se portanto ainda em fase de in-vestigação (Rui J. Lopes e Hutchison,2003) e ainda não atingiram a TV Digital completamente. Apesar disto já há desenvolvimento na transmissão de metadados MPEG-7 em stream MPEG-2 (A. Lopez e Fernandez,2003).

Finalmente só nos foi disponibilizado realmente os EPG, pelo que nesta dissertação só se explorou essa alternativa.

2.1.2 DVB-SI

A passagem para TV digital na Europa seguiu um conjunto de normas e standards aos quais normalmente se refere pelo nome de DVB. É constituídos por vários protocolos que incluem el-ementos bem conhecidos e patentados como MPEG-2, por exemplo. Um desses protocolos é o SI que tem como objectivos fornecer informação sobre os serviços disponíveis, frequências que os transportam, eventos que irão ocorrer e faz agregação dos próprios em diferentes categorias. Para além dessa informação inclui ainda informação utilizada pelos operadores da rede, permite decisões de compra e ajuda a gerir o fluxo de receitas pelos provedores de serviços (Publisher, 1997).

A importância do DVB-SI no contexto desta dissertação é porque é graças a ele que é possível criar os EPG.

2.1.2.1 EPG

Os EPG são uma característica única da TV digital. De um modo simples, é como que um jornal da TV e é criado pelo provedor do serviço. Para os broadcasters, um EPG bem desenhado

2.2 Sistemas de recomendação 7

e sem erros é uma mais-valia pois abre caminho para melhor anunciar os seus novos produtos, como por exemplo o bem conhecido pay-per-view. Para além disso também tem como objectivo a facilitação do uso da STB para o utilizador. Muito tempo e esforço é despendido (Publisher,1997) com o objectivo de alcançar vantagem competitiva.

Tem-se várias ferramentas que permitem recolher toda a informação necessária:

• Descritor de conteúdo: é o mais importante do ponto de vista de filtragem de conteúdo. Permite obter-se informação como géneros e subgéneros. Os géneros possíveis encontram-se encontram-secção de descritores de conteúdo em (Zoicas,1997).

• Descritor de componente: este contém dados sobre a linguagem, tipo de componente, tipo de vídeo e áudio.

Os restantes descritores foram omitidos dada a irrelevância, pelo que podem ser consultados em (Zoicas,1997).

2.2

Sistemas de recomendação

A origem dos recomendadores é algo difícil de definir ao certo, as suas raízes estão associ-adas a ciência cognitiva, teoria de aproximação, teoria de previsão e até mesmo gestão científica (Adomavicius e Tuzhilin,2005). Mas foi em meados dos anos 1990 que realmente emergiu como ciência ou área de investigação com as primeiras publicações sobre Collaborative filtering (Hill et al.,1995). As primeiras abordagens baseavam-se em sistemas de votação, os itens eram classifi-cados "relevantes"ou "não relevantes"para o utilizador baseado na estimativa de votação de outros utilizadores.

Um outro conceito a ter em conta quando se fala em sistemas de recomendação é a confiança. Este conceito é importante no desenho de um recomendador e deverá estar presente em cada decisão tomada que implique o utilizador directamente. O que se quer dizer com isto é que se um utilizador perde a confiança no sistema ou acha o sistema pouco fiável, dificilmente voltará a utilizá-lo, o que tornará o sistema obsoleto.

Em geral um problema de recomendação é formulado da seguinte maneira: Digamos que temos dois grandes grupos, um de utilizadores (C) e outro de itens para recomendação (I), estes podem ser livros, filmes, restaurantes, etc. Considere-se a função de avaliação de utilidade u e e o cerne do motor de recomendação.

O nosso objectivo é então para cada

c ∈ C

seleccionar o item

i0_c∈ I que maximiza a função de utilidade, formalmente:

8 Levantamento do Estado da Arte

∀c ∈ C, i0c= argmaxi∈Iu(c, i) (2.1)

Existem três grandes famílias (de conteúdo, colaborativos e híbridos) e duas categorias (mod-elo ou heurísticos) de recomendadores que serão analisados de seguida. Todas as técnicas men-cionadas serão detalhadas no anexoA.

2.2.1 Content-based

Este tipo de recomendadores são baseados nos conteúdos do contexto, isto é, a função de util-idade baseia-se nas preferências do utilizador e votações dele próprio sobre itens que conhece e irá classificar outros itens desconhecidos através das suas características. Por outras palavras, a função calcula o nível de semelhança entre o perfil do utilizador e os itens candidatos a recomen-dação, o resultado para recomendação são os itens que maximizam a função.

Os perfis podem ser baseados em dados inseridos pelo utilizador (perfil explícito) ou em dados inferidos pelo algoritmo tendo em conta as acções do utilizador (perfil implícito).

2.2.1.1 Heurísticos

Nesta família de recomendadores, os heurísticos (ou de memória) são aqueles que se baseiam mais em técnicas de IR e são bastante utilizados em aplicações baseadas em muitas linhas de texto, recomendando itens com informação textual semelhante. É comum encontrá-los na recomendação de websites, notícias e afins.

Como geralmente lidam com imensos textos e descrições, tipicamente os algoritmos extraem informação através de palavras-chave, diga-se 100 de um texto por exemplo, em seguida estas palavras-chave são comparadas às palavras-chave do perfil utilizador. Se atribuir-se um peso às palavras-chave (TF-IDF bastante popular na atribuição de pesos (Adomavicius e Tuzhilin,2005) (Joachims,1997) (Enza Messina e Archetti, 2006)) podemos definir dois vectores, um com os pesos atribuídos às palavras-chave do documento e outro de pesos atribuídos às palavras-chave das preferências do utilizador. Com estes vectores podemos calcular a bem conhecida diferença angular:

cos(θ ) = hu, vi

kuk.kvk (2.2)

Em que u é o vector de pesos das palavras-chave do documento e v o vector de pesos atribuídos às palavras-chave das preferências do utilizador. A expressão do numerador simboliza o produto interno entre os dois vectores e a do denominador o produto das normas dos vectores.

Com esta diferença temos uma boa medida de avaliação do que é "relevante"e do que é "não relevante".

2.2 Sistemas de recomendação 9

• TF-IDF • Clustering

2.2.1.2 De modelo

Recomendadores de conteúdo desta categoria utilizam uma abordagem diferente. Aqui, através dos dados (históricos de utilizador ou logs) constrói-se um modelo do utilizador a partir dos dados subjacentes. Em seguida aplicam-se métodos estatísticos para o cálculo das diferentes classes de classificação. Considere-se o exemplo: Um conjunto de itens é considerado "relavante"ou "não-relevante"pelo/para o utilizador (modelo de treino). Aplica-se um método estatístico como Naïve Bayes classifier(Joachims,1997) (Hölbling et al.,2010) (Srinivas Gutta e Zimmerman,2000) à lista de candidatos, tendo em conta o modelo de treino e serão estimados probabilisticamente a que classes pertencem os candidatos. O resultado embora muitas vezes um pouco "desviado"quanto às proporções estatísticas, proporciona uma classificação binária com alta taxa de sucesso.

Técnicas normalmente associadas a esta categoria:

• Classificadores Bayes • Clustering • Árvores de decisão • Redes neuronais 2.2.1.3 Limitações e dificuldades Sobre-especialização

A recomendação gira sempre em torno do perfil de utilizador. Com o passar do tempo o sistema torna-se sobre-especializado e irá recomendar apenas o que o utilizador gosta, o problema é: gostos mudam ou então há o risco de a sobre-especialização ocorrer em torno de um tópico específico.

Normalmente este aspecto é abordado tentando introduzir algum critério de aleatoriedade na escolha de recomendações, por exemplo, se se recomenda um conjunto máximo de x itens, desses x pode-se atribuir um sub-conjunto y (y<x) em que em y recomendam-se outros itens de géneros diferentes ou simplesmente de modo aleatório.

Adicionalmente, por vezes o problema até nem é o conteúdo de qualidade que fica fora do campo de visão do recomendador mas os itens que são recomendados e não deviam por serem demasiado semelhantes àquilo que o utilizador já conhece (Adomavicius e Tuzhilin,2005), isto é, acabam por não ter interesse algum. Um exemplo deste caso pode ser dois artigos de jornais diferentes sobre o mesmo acontecimento, é sugerido nestes casos que a filtragem também exclua itens demasiado semelhantes. Esta solução no entanto deverá ser abordada de uma maneira bem ponderada, pois pode não ser fácil a exclusão automática de itens aparentemente "semelhantes".

10 Levantamento do Estado da Arte

Procura de características apropriadas

Num contexto amplo, por exemplo Multimédia, pode não ser tão fácil estabelecer recomen-dações sobre conteúdos de naturezas completamente diferentes (imagens, filmes, música, etc). Isto porque neste tipo de recomendadores a forte ligação às características dos itens pode ser problemática caso não seja possível a extracção automática de características de "boa quali-dade" (Pechenizkiy,2009). Desenhar um recomendador que trabalhe de maneira precisa em con-textos amplos ou pouco/mal documentados não é trivial.

Novos utilizadores

Caso não haja nenhum perfil explícito pelo utilizador estamos perante o famoso Cold Stard Problem, o sistema não saberá como lidar com os novos utilizadores pois não tem qualquer fonte de referência quanto às suas preferências. Existem várias abordagens para contornar este problema mas não há uma solução óbvia para esta questão controversa. Há quem defenda o uso de itens Blockbustercomo ponto de partida (ligação híbrida de recomendação apresentada em2.2.3), no entanto nem todos os utilizadores podem gostar dessa solução, o resultado pode ser a perda de confiança (!) no sistema.

Outra solução será simplesmente deixar o algoritmo correr, criando um perfil implícito, até atingir um certo valor de confiança e a partir daí começar a recomendação. Tal solução também não é perfeita e depende do contexto. Do ponto de vista do utilizador até poderá levar ao esquecimento, por exemplo.

2.2.1.4 Vantagens

Para contextos em que os candidatos de recomendação incluem ou são documentos de texto, o resultado é bastante preciso. Técnicas estatísticas de Bayes ainda apresentam performances muito satisfatórias com custos computacionais baixos (lightweight). Para além disso, a combinação de um ou vários classificadores lightweight são boa solução (Hölbling et al.,2010) para ambientes em que os recursos são escassos, por exemplo se a aplicação for a correr numa STB.

A simplicidade é muitas vezes uma vantagem e embora os modelos colaborativos sejam (nor-malmente) mais complexos conseguindo relacionar os itens de mais variada natureza, precisam também de um poder computacional maior.

2.2.2 Collaborative-based

Esta família ao contrário dos anteriores de conteúdo, prevêem a utilidade dos itens para um utilizador a partir de itens previamente cotados/avaliados por outros utilizadores. A expressão-chave é "se os outros utilizadores gostaram do item i então é provável que o utilizador c também goste".

2.2 Sistemas de recomendação 11

2.2.2.1 Heurísticos

Tipicamente funcionam percorrendo todos os itens avaliados pelos utilizadores, isto é, o valor de utilidade u para um utilizador c e item i é calculado através do agregado de avaliações atribuídas pelos N utilizadores mais semelhantes a c. No caso mais simples, o caso de agregação pode ser apenas uma soma de médias ponderadas e quanto à semelhança de utilizadores poder-se-á utilizar outra vez a diferença angular ou outro tipo de diferenciação heurística (N vizinhos mais próximos). Note-se que a diferença angular aplicada no contexto colaborativo é diferente da do contexto de conteúdo. Aqui os vectores de pesos são mesmo especificados pelo/para o utilizador e não pelo cálculo de TF-IDF, ou seja comparam-se preferências entre utilizadores e não entre utilizadores e os itens.

Técnicas normalmente associadas a esta categoria:

• K vizinho mais próximo • Clustering

• Teoria de grafos 2.2.2.2 De modelo

Novamente a ideia é criar um modelo, desta feita, não a partir das características do conteúdo mas a partir das avaliações de outros utilizadores. Esta categoria sugere então a identificação de "estereótipos", obviamente uma técnica normalmente encontrada será a de clustering e a estrutura é normalmente associada a técnicas de Bayes ou quaisquer outras que lidem com redes/grupos de utilizadores.

Técnicas normalmente associadas a esta categoria:

• Redes de Bayes • Clustering

• Redes neuronais • Regressão linear

• Modelos probabilísticos variados 2.2.2.3 Limitações e dificuldades

Novos utilizadores

Do mesmo modo que um novo utilizador afecta um sistema de recomendação de conteúdo, aqui o efeito é semelhante. É necessário que o sistema aprenda as preferências dos novos uti-lizadores através de votações por eles efectuadas. Novamente as soluções para contornar o prob-lema são baseadas em dois tipos (Adomavicius e Tuzhilin,2005) (Al Mamunur Rashid e Riedl,

12 Levantamento do Estado da Arte

2002): Ou utilizam-se abordagens híbridas (com recomendadores de conteúdo) ou exploram-se aspectos como popularidade dos itens (blockbusters), entropia do item e personalização de uti-lizadores.

Novos itens

Como seria de esperar, neste tipo de recomendadores que dependem somente de avaliações de utilizadores, um novo item não avaliado dificilmente será integrado no processo de recomendação. Normalmente este tipo de problema é corrigido ao integrar recomendação de conteúdo (sistema híbrido).

Escalabilidade

Outro problema óbvio é a escalibilidade. Se em recomendadores de conteúdo já há possibil-idade de haver imensos itens, aqui para além disso existem imensos utilizadores e dependendo dos contextos, imensas acções a acontecer por segundo no sistema. Uma das soluções é limitar o espaço de avaliação de acordo com o poder computacional (Pechenizkiy,2009).

Esparsidade

A esparsidade e um problema presente em vários casos. Uma questão-chave nos recomen-dadores colaborativos é a massa crítica de utilizadores. Se existem alguns itens de grande qual-idade que são avaliados por poucos utilizadores então nunca esses itens nunca atingirão a massa crítica necessária para "entrar"no sistema.

Outro exemplo é a semelhança de itens que é ignorada, tratam-se como se fossem diferentes, o resultado é o aumento da esparsidade, perda de transitividade e fraca qualidade de recomendação (Pechenizkiy,2009).

Finalmente há a possibilidade de utilizadores serem "únicos"e o sistema é incapaz de relacioná-los com outros. Este facto depende do contexto e se a abrangência dos itens for elevada.

A unicidade poderá ocorrer de maneira semelhante com os itens, muitos não são relacionáveis.

Fraude

Um aspecto importantíssimo e sempre relacionado com a componente social destes recomen-dadores é a possibilidade de fraude. O caso típico é o denominado "ataque de injecção de perfis". Os objectivos são simples e normalmente das duas uma: ou realçar/desfalcar opiniões de outros utilizadores ou realçar/desfalcar avaliações de determinados itens. O efeito de realce é também conhecido como chilling. Este tipo de ataque só é possível caso o mesmo utilizador tenha facil-idade em subscrever vários perfis simulando diferentes utilizadores, pior ainda caso o utilizador malicioso crie um programa para efectuar a mesma operação muito mais depressa. O ataque pode seguir várias estratégias, as mais conhecidas são: "aleatório", "média", "segmentação", "love-hate", "bandwagon".

2.2 Sistemas de recomendação 13

Existem diversas propostas para solução (Pechenizkiy,2009) (Paul-Alexandru Chirita e Zam-fir, 2005). Recomendadores baseados em modelos são normalmente mais resistentes a ataques visto que são baseados em técnicas de clustering. O uso de recomendadores híbridos também atenua o efeito. Uma solução interessante também discutida abaixo em Grupos, é desafiar o uti-lizador a definir explicitamente algumas relações de confiança.

Existem também métodos de detecção e resposta. Estes métodos passam por dois tipos: classi-ficação de perfis e detecção de anomalias. A ideia da primeira é desenvolver um módulo inteligente que identifica e aprende "perfis de ataque", eventualmente o custo dos ataques crescerá ao ponto de torná-los pouco interessantes para os utilizadores maliciosos. Em detecção de anomalias a abordagem é classificar os itens (sob ataque ou não) e podem-se identificar itens que estão mais propensos a ataques e monitorizá-los mais frequentemente. Na prática este tipo de métodos de segurança requer um desenho de sistema muito sofisticado.

Grupos

Pode-se considerar um problema a recomendação de filmes, por exemplo, visto que são muitas vezes vistos em grupo. Para um sistema colaborativo não há tratamento de grupos de utilizadores, são todos vistos como indivíduos independentes.

A solução seria criar um recomendador específico para grupos mas isso também traz proble-mas associados tais como: reconhecimento de grupos, regras, composição, algoritmos para gru-pos, interface, etc. No entanto (Bonhard) sugere que a identificação explícita de "amigos"ajuda imenso no processo de recomendação (atribui-se maior peso caso os utilizadores que suportam o item sejam "amigos").

Confiança

Note-se que este tipo de confiança não se refere à abordada no início do subcapítulo de sistemas de recomendação, mas refere-se sim a confiança entre utilizadores.

Este factor é normalmente questionado mais no aspecto colaborativo do que em conteúdo. Nat-uralmente em conteúdo as recomendações são baseadas no que foi visto pelo próprio utilizador, en-quanto que num sistema colaborativo é normal que os utilizadores se questionem en-quanto à opinião dos outros (Pechenizkiy,2009). Uma boa prática é a explicação de alguma maneira (simples) das recomendações. Considerando o exemplo do Youtube, as recomendações são suportadas por uma pequena frase que representa a razão da recomendação.

Uma solução um pouco mais difícil de implementar é dar a oportunidade para outros uti-lizadores corrigirem dados não correctos, como em wikis.

2.2.2.4 Vantagens

Mesmo havendo mais critérios a ter em conta no desenho de um filtro colaborativo, este é reconhecido como o método de recomendação preferido (Systems e Zeng). O espaco de re-comendacão é mais vasto e pode ser aplicado em mais contextos com os mais variados produtos.

14 Levantamento do Estado da Arte

Para além disso é psicologicamente reconhecido que as decisões são muitas vezes partilhadas e influenciadas por outros, daí fazer todo o sentido uma filtragem colaborativa bem desenhada.

2.2.3 Hybrid-based

A combinação de métodos colaborativos com de conteúdo pode ser muito vantajoso, muitas dificuldades podem ser ultrapassadas. No entanto na maior parte dos casos não é um processo trivial, pelo que analisar-se-á agora de seguida os principais passos a seguir para tal.

2.2.3.1 Implementação colaborativa e de conteúdo separada com combinação final de predições

Podem haver dois cenários a considerar nesta abordagem. Uma maneira será combinar os outputs, em forma de rácios, num só valor através de combinação linear ou esquema de votação. Outra opção é escolher o recomendador através de um processo de decisão que decide qual dos dois a utilizar, um bom exemplo é escolher o recomendador com maior nível de confiança e reen-caminhar esse como output.

2.2.3.2 Construção de um modelo unificador que incorpora filtragem de conteúdo e colab-orativa

É um domínio emergente que combina características de ambas as abordagens num único clas-sificador baseado em regras. Existem implementações que criam modelos estatísticos baseados no teorema de Bayes, combinando um perfil construído a partir da informação de vários utilizadores e informação de itens num só, o output é uma avaliação ri,j para o utilizador i e item j. Um

caso particular utiliza os atributos do perfil de utilizador, os do perfil do item e ainda atributos de interacção entre os dois perfis para o calculo final de avaliação (Adomavicius e Tuzhilin,2005).

Sistemas híbridos podem também ser melhorados através de técnicas de conhecimento, em-bora estas constituam um dos actuais bottlenecks dos sistemas de IA. Em todo o caso existem recomendadores baseados em conhecimento onde o conhecimento já vem "digerido"numa estru-tura aceitável para o processamento das máquinas.

2.2.4 Capacidade de expansão/melhoramento dos recomendadores

Construir um sistema de recomendação sofisticado não é fácil. Normalmente começa-se por desenvolver um sistema simples que satisfaça parcialmente o que se quer e depois então parte-se para melhoramentos focados nos verdadeiros objectivos. Estes objectivos podem ser variados e serão agora brevemente discutidos os mais relevantes no contexto TV.

2.2.4.1 Melhoramento na compreensão dos utilizadores

Os perfis dos itens e dos utilizadores muitas vezes são limitados e como consequência não se tira o máximo proveito da informação.

2.2 Sistemas de recomendação 15

Os esquemas clássicos de recomendação colaborativa (Hill et al., 1995) nem usam perfis de utilizador ou item e baseiam todas as conclusões apenas nas votações disponíveis. Existem claro melhoramentos desde aí mas mesmo assim, os perfis tendem a ser compostos por simples palavras-chave ou referências demográficas.

O uso de técnicas avançadas de profiling de DM será uma opção a ponderar caso se pretenda expandir um sistema de recomendação neste sentido.

Para sistemas que operam em Web ou outro contexto em que haja alguma acção de navegação, será também interessante a exploração dos comportamentos dos utilizadores. Podem-se descobrir padrões interessantes ou sequências de navegação sempre comuns que permitirão recomendações melhores.

2.2.4.2 Recomendações multidimensionais

A maior parte dos recomendadores trabalha nas duas dimensões do espaço: utilizador x item. No entanto em alguns contextos pode ser benéfico explorar outra informação. Existem itens cuja utilidade depende de factores temporais, locais, acontecimentos extraordinários. Um utilizador pode preferir géneros de filmes diferentes ao fim de semana quando vai ao cinema do que quando assiste em casa a meio da semana. Programas vistos durante o dia são diferentes dos vistos à noite. Enfim existem muitos exemplos semelhantes que merecem ser explorados.

Uma maneira para explorar este conceito multidimensional é dimensionar um recomendador com várias hierarquias ou múltiplos classificadores, que facilite a integração de outros módulos facilmente.

2.2.4.3 Votações multicritério

Ainda no seguimento do tópico anterior, pode-se ainda extender os tipos de votações overall dos itens e criar mais critérios para avaliação por parte do utilizador. Por exemplo em restauração interessa, não só saber se um local é bom ou não, mas se o serviço, a comida ou a decoração são bons.

Para atingir votações multicritério existem 4 típicas soluções para tal (Adomavicius e Tuzhilin, 2005):

• Combinação linear dos múltiplos critérios e reduzir o problema a optimização de um único critério

• Optimizar o critério mais importante e converter os restantes a constantes

• Optimizar consecutivamente um critério de cada vez, converter solução final a constante(s) e repetir o processo para os restantes critérios

• Descobrir soluções óptimas de Pareto1

16 Levantamento do Estado da Arte

2.2.4.4 Intrusividade

Este termo refere-se ao facto de pedir feedback explícito ao utilizador. Pode não ser prático pedir sempre votações aos utilizadores sobre tudo. Por exemplo se um utilizador visualiza 80% de um programa será normal assumir que houve interesse por parte dele e que, pelo menos em termos de votação, o programa é "razoável"a "bom". São inferências deste género que poderão tornar o sistema mais agradável para o utilizador.

Outra maneira de explorar este problema poderá ser definir à partida um número de votações máximo que um sistema poderá fazer ao utilizador. Tal acontece em (MovieLens), em que se pede ao utilizador inicial que preencha um número pré-definido de filmes, antes de recomendar.

2.3

Análise e escolha

O uso das STB individuais neste trabalho sugere a partida uma abordagem de recomendação de conteúdo, dado que a "ligação"entre utilizadores é limitada. No entanto o uso de classifi-cadores baseados no teorema de Bayes, mais propriamente Naïve Bayes, não se deveu a tal facto. Dados os recursos escassos disponíveis: sinopse, data e hora de visualização, duração, título, tipo e canal; não houve muita escolha quanto ao método de classificação de texto, optou-se por classi-ficadores "leves". Ainda quanto ao conteúdo, ir-se-á explorar a opção de extracção de informação ao domínio web. Para além disso, tal como foi dito nos objectivos, é esperado que o classificador na presença de outro contexto ou mesmo correndo sob outra plataforma, seja capaz de ainda assim produzir resultados satisfatórios.

Em (Rish,2001) (Jason D. M. Rennie e Karger,2003), estudos empíricos comprovam que o classificador acima referido produz resultados quase-óptimos em contextos em que as carac-terísticas seguem uma distribuição de baixa entropia. Note-se que o termo entropia é utilizado meramente como denominação de espaço de características limitado.

Finalmente esperam-se resultados binários em termos de classificação, isto é o mínimo número de classes. No entanto ver-se-á que algumas variações existem quanto ao número de classes, na descrição do sistema.

Para já ficaram aqui apresentadas as principais extensões híbridas que serão discutidas como possíveis extensões da actual implementação. Estas decisões estão mais dependentes do contexto da expansão.

Capítulo 3

Descrição do Sistema

3.1

Introdução

Aqui far-se-á a descrição da actual do sistema, de acordo com a implementação. Começar-se-á por uma visão geral e em seguida uma descrição mais detalhada.

Para todas as figuras esquemáticas presentes neste capítulo o código é o seguinte:

• Losangos - Decisões

• Rectângulos - Módulos, processos ou sistemas.

• Paralelogramos diagonais - Módulos, processos ou sistemas externos.

3.2

Visão geral

É no bloco que gere serviços de valor acrescentado da PT que o trabalho desta dissertação se insere. Este módulo será uma das muitas partes ligadas ao broker de contexto que manipula informação recolhida, desde redes sociais, sensores, GPS, comunicação(XMPP), etc. Na figura 3.1temos a arquitectura de nível superior onde tem-se assinalado a posição do recomendador TV. Como se pode constatar a informação das STB encontra-se disponível a este broker através do nível de consumidor, mediante o servidor ou broker de contexto.

O esquema que descreve o modelo geral do sistema é exposto na figura3.2. A decisão é por-tanto,definida através de três classificadores NBC: um para o tipo de programa, um para géneros e data/hora e um terceiro para os canais visualizados.

Há facilidade para expansão com novos módulos, a maior dificuldade será em atribuir pesos aos diferentes classificadores. O paralelogramo a laranja é o módulo mais provável a implementar no futuro, com objectivo de melhorar a filtragem da lista final de candidatos.

Os itens assinalados com contornos a cores serão detalhados em maior pormenor, os restantes como ainda encontram-se em desenvolvimento serão discutidos.

18 Descrição do Sistema

Broker de contexto

Histórico Repositório de

contexto

Proximidade Localizador Redes sociais Perfis de utilizador

Recomendador TV

Presença Caps terminal Sensores

Nível de gestão de contexto

Nível fornecedores de contexto

Gestor de grupos Selecção de conteúdos Apps

Sapo Meo Dino

Nível de fornecedores de conteúdo Nível de consumidor e decisor Nível de consumidor

Figura 3.1: Arquitectura de nível superior - Serviços de valor acrescentado PT Inovação

3.3

Descrição

3.3.1 Classificação das visualizações

Dado que a informação das STB ainda não se encontra disponível como pretendido (ajustes ainda estão a ser feitos para que transmitam correctamente a informação para o servidor), este processo ainda se encontra em desenvolvimento, pelo que far-se-á aqui uma análise para a sua abordagem. Os restantes processos foram mais focados por esta razão.

O conceito-chave aqui é reduzir de uma maneira eficaz o número de falsos positivos de classi-ficação, isto é reduzir o número programas classificados como "visualizados"mas que na realidade não o foram.

O perfil de utilizador é construído de acordo com a maneira em como se classificam as visu-alizações. Recorde-se que uma STB muitas vezes está ligada todos os dias. Os utilizadores, na

3.3 Descrição 19

Classificação das visualizações

Classificador Naïve Bayes para

géneros e data

Classificador Naïve Bayes para

o canal Decisão conjunta Extracção de candidatos Perfil de utilizador Classificador Naïve Bayes para

o tipo Processamento final Serviço WEB da SAPO Módulo de filtragem colaborativa Broker

Figura 3.2: Modelo geral do sistema de recomendação

maior parte dos casos, preferem desligar a sua TV, deixando as STB ligadas. O resultado implica dificuldades em decidir implicitamente o que é visto e o que não é. Intuitivamente, será de es-perar que caso haja interesse no programa visualizado, ou simplesmente em ver televisão, haverá alguma acção de zapping por parte do utilizador num futuro próximo, mesmo que seja por uma curta duração. Em (Geng Yu e Oedling,2009), embora num contexto com objectivos diferentes, os autores constatam que resultados empíricos demonstram sessões (acção de visualização de TV, activamente) sem zapping superiores a uma hora para cerca de 4% a 5% dos utilizadores, tanto para períodos matinais como para períodos de final de dia/nocturnos. Tendo em conta estes resul-tados é proposto que sejam considerados períodos "activos"de no máximo 90 a 120 minutos sem acção por parte dos utilizadores, acima destes valores é considerado período "inactivo"e todos os programas subsequentes são ignorados até nova acção por parte do utilizador.

Consequentemente, dada a limitação temporária, sugere-se que os programas sejam classi-ficados como "visualizados", se efectivamente forem visualizados em cerca de 70%-90% da sua duração em período "activo". Assim resolve-se também o problema de zapping causado por

publi-20 Descrição do Sistema

cidade1e será seguro admitir que houve interesse por parte do utilizador. Se se baixar essa margem haverá tendência de adicionar ao histórico mais itens com probabilidade de serem "parasitas"em transacções "activo"para "inactivo". Mesmo que alguns desses itens não sejam realmente "para-sitas", a longo prazo, não serão relevantes pois o algoritmo tenderá a especializar-se. Uma maneira mais sofisticada seria o ajuste automático do tempo do timeout para as transições activo/passivo, combinando o perfil de utilizador: caso o utilizador inclua no seu perfil uma grande quantidade de filmes em comparação com os restantes tipos, poder-se-ia alargar o tempo de transição. O contrário também seria válido, se o utilizador tivesse no seu perfil uma quantidade significativa de programas cuja duração é inferior a uma hora então encurtava-se o tempo de transição. A primeira vista até poderá parecer sensato proceder desta maneira, mas só com experiência se poderia evi-dentemente comparar e decidir sobre como evitar melhor a geração de "lixo".

Se um programa é então classificado como "visualizado", em seguida o processo de atribuição de géneros e tipo será efectuado da mesma maneira que será explicada no subcapítulo3.3.2sobre a extracção de candidatos.

Outra solução original proposta em (Hölbling et al.,2010) é: considerar uma TV como um sistema de e-mail. A ideia baseia-se na utilização de filtros SPAM, tais como os utilizados em e-mail muito eficazmente. No entanto o que normalmente seria considerado SPAM em e-mail, no contexto TV seria HAM e o recíproco SPAM. A razão para tal é simples, os filtros SPAM são eficazes no contexto em que a maior parte dos documentos são HAM, em TV a quantidade de programas a serem transmitidos na hora são imensos, é imensamente improvável que um utilizador esteja interessado em tudo (aliás é impossível estar actualizado com tudo ao mesmo tempo), daí considerar-se que em TV a maior parte dos "documentos"são SPAM. O que leva à conclusão: utilizadores estão interessados em programas "particulares"e não na "generalidade"do que se passa na TV. Na prática esta solução até é muito parecida a actual implementação no que toca ao uso de classificadores combinados Naïve Bayes. No entanto a sua aplicação seria diferente. Seria necessário estar consciente em qualquer hora com tudo o que se está a passar em todos os canais, isto geraria um fluxo de informação bem superior. O processamento da informação do perfil seria também mais complexa dada a extensa quantidade de informação.

Finalmente mas ainda muito importante é o facto que os autores também partem do princípio que tem-se toda a informação disponibilizada pelo MPEG-7 e TV-Anytime, o que os permite inferir de maneira diferente tendo em conta que tem metadados em maior quantidade e de melhor quali-dade, inclusive até um perfil de utilizador gerado automaticamente, que ultrapassa o problema de Cold Start.

3.3.2 Extracção de candidatos

Pode-se ver a arquitectura deste módulo na figura3.3. A lista de candidatos a recomendação é extraída automaticamente com uma janela de selecção a partir do dia corrente até ao dia seguinte. O provedor é o website SAPO que disponibiliza diversos serviços, entre eles os EPG semelhantes

3.3 Descrição 21

Actualização das listas de candidatos de acordo com a data

Candidatos guardados em ficheiros diferentes, por canal Serviço WEB da SAPO Processamento do ficheiro de canal Classificação do programa Final de ficheiro? SIM Final de processamento ? NÃO NÃO SIM Dados guardados em diferentes ficheiros

Data e géneros dos programas

Tipos dos programas

Canais dos programas

Classificador Naïve Bayes para géneros e data Classificador Naïve Bayes para o tipo Classificador Naïve Bayes para o canal Extracção de candidatos IMDB Bem sucedida? NÃO SIM

Figura 3.3: Extracção de candidatos

aos presentes nas STB Meo. Os candidatos são seleccionados por canal e a lista de canais pode ser ajustada com mais ou menos canais consoante a população que se pretende avaliar. A informação encontra-se em formato XML e é guardada num ficheiro temporário onde então se procede à classificação do programa quanto ao tipo, géneros, canal e data.

Como se pode reparar na figura3.4não existe muita informação que permita inferências muito sofisticadas, pelo que se se falhar na classificação do programa quanto a géneros, para os tipos "filme"e "série", recorrer-se-á ao website IMDB (Database) para a sua classificação.

A utilização do website IMDB é seguramente a melhor fonte primária para classificação de filmes e séries, com a excepção das séries Portuguesas que não retornam resultados, torna-se então necessário que ainda assim haja uma análise da sinopse por parte desses tipos caso a procura no Websitenão retorne resultados. Note-se que as sinopses estão assinaladas como <Description> na figura3.4.

3.3.2.1 Géneros e tipo

Este e o cerne de um recomendador baseado em filtragem de conteúdo. Infelizmente, dado que a informação dos EPG era limitada tomaram-se algumas decisões de modo a simplificar/contornar o problema.

Neste momento existem 5 tipos de programas: desporto, jornal/informativo, filme, série e outro. Se o candidato não pertence a nenhum dos primeiros 4 tipos então é classificado como

22 Descrição do Sistema

Figura 3.4: XML exemplo de um programa

"outro". Para cada tipo existe uma lista de géneros admissíveis e caso o programa seja do tipo "outro"então as listas dos géneros são combinadas de modo a tentar, ainda assim, classificá-lo quanto a géneros.

Os tipos actualmente identificados são:

• Série: Nos EPG, as séries contêm no seu título dois números correspondentes à temporada e ao número do episódio. É portanto o tipo mais evidente de se classificar e é feita logo a distinção entre o que é série e o que não é.

• Filme: Os filmes contêm uma lista de géneros equivalente ao das séries e são detectados através da duração do programa. Se forem detectados géneros de filme e se a duração for superior a 80 minutos então o programa será classificado como "filme".

• Desporto: No tipo "desporto"a duração não é tão fixa como em "filme", pelo que é feito o teste de pesquisa de géneros em toda a gama de duração.

• Jornal/informativo: Os programas informativos são tipicamente de duração inferior a 80 minutos. Caso sejam detectados géneros correspondentes a este tipo então o programa será classificado como "jornal".

• Outro: Se nenhum dos tipos acima indicados forem detectados então o programa será clas-sificado como "outro"e será feita pesquisa de géneros recorrendo a todas as listas de géneros combinadas.

As actuais listas de géneros estão detalhadas no anexoB. A geração dessas listas será analisada no próximo capítulo.

3.3 Descrição 23

3.3.2.2 Data

A ideia da data é simples: para além de fornecer filtragem de conteúdo baseada em géneros, filtrar também tendo em conta as alturas do dia e da semana. Esta ideia para já, simples, vai de encontro com o estudo de capacidade de expansão em recomendadores apresentado em2.2.4.2.

Na prática é tido em conta dois parâmetros: a data e a hora. Com a data do programa guarda-se a altura da semana, se "fim-de-semana"ou não e com a hora pretende-se fazer a separação "manhã e "noite". Serão de esperar algumas mudanças de hábitos nestas ocasiões, isto porque dependendo da altura da semana e da hora o utilizador pode ser diferente ou preferir diferentes conteúdos. Por exemplo, um utilizador poderá estar mais interessado em ver notícias durante o período matinal e visualizar filmes ao fim do dia, ou então ter hábitos de visualização nos dias úteis diferentes dos dias de fim-de-semana.

Este tipo de pressupostos é um ponto de partida no que toca a tentativa de diferenciação de utilizadores numa mesma STB.

Este componente para já está apenas associado aos géneros, mas nada impede o uso combinado com os restantes classificadores de canal e tipo.

3.3.2.3 Canal

O canal é imediatamente guardado aquando a abertura do ficheiro EPG correspondente.

3.3.3 Perfil de utilizador

O perfil de utilizador não e mais do que o histórico construído a partir da classificação das visualizações. Neste momento os perfis criados (fictícios) com objectivo de testar o algoritmo seguem três tipos de formatação (um para cada classificador). Na figura 3.5 encontra-se uma amostra exemplo do perfil para o caso de data e géneros. O significado de cada linha é semelhante nos três casos. As linhas ímpares são as classificações das visualizações das linhas pares seguintes. Os valores das linhas ímpares simbolizam o seguinte:

• 0: rejeição de recomendação/não visualização da recomendação. • 1: aceitação da recomendação/visualização da recomendação. • 2: visualização normal

Para as formatações de canal ou tipo nas linhas pares temos simplesmente o próprio canal ou o tipo. Neste caso dos géneros e data, nas linhas pares temos então pelo menos 3 parâmetros e no máximo 5. Os primeiros dois referem-se à componente temporal descrita em3.3.2.2 e cor-respondem a duas variáveis binárias que simbolizam "fim-de-semana"ou "não-fim-de-semana"e "manhã"ou "noite", respectivamente. Os restantes parâmetros de são os géneros detectados aquando a classificação das visualizações.

24 Descrição do Sistema

Figura 3.5: Excerto exemplo de formatação do perfil para data e géneros

3.3.4 Motor de recomendação

O modo de funcionamento é equivalente nos três classificadores. O peso multiplicativo é atribuído a cada decisão, é esta que pode ser alterada consoante o que se pretende focar. Os can-didatos que não foram possíveis de classificar quanto a géneros não são considerados no processo de geração da lista final.

Considere-se o funcionamento ilustrado na figura3.6. Começa-se então por extrair o perfil do utilizador respectivo ao classificador. Em seguida calculam-se as probabilidades totais de "visu-alização normal", "rejeição de recomendação"e "aceitação de recomendação". Note-se que estes termos agora serão utilizados para avaliação dos candidatos pelo que poder-se-á referir a eles como probabilidades "relevante", "não-relevante"e "recomendação relevante"respectivamente.

Será de esperar que qualquer perfil de utilizador seja composto maioritariamente por "visual-izações normais", isto poderá gerar problemas dentro do algoritmo Naïve Bayes. Alguns estudos ( (Tommi Jaakkola,2001) (Mladenic e Grobelnik,1999)) alertam o facto de se criar um biasing natural dentro do algoritmo caso uma das classes predomine sobre as outras, é provado que na pre-sença de classes com poucas ocorrências (em comparação com as outras) essas terão uma variância muito superior às restantes, o resultado é normalmente avaliações erráticas na classificação.

3.3 Descrição 25 Extracção de candidatos Leitura do candidato Leitura do perfil do utilizador Cálculo das probabilidades “relavante” ou “não-relevante” Cálculo das probabilidades condicionadas SIM Decisão global Avaliação do candidato Descarte NÃO Classificador Naïve Bayes genérico

Figura 3.6: Motor de classificação

modo a tentar balancear as classes menos dominantes. As classes "rejeição de recomendação"e "aceitação recomendação"aplicam portanto diferentes pesos no processo de avaliação. Estes pesos para já são estáticos mas podem ser alterados também no futuro de modo a melhor modelar o perfil do utilizador caso tal seja necessário.

Adicionalmente é também fácil adicionar novas classes, tais como "gravação de programa"ou "não visualização normal", (esta embora muito difícil de detectar por razões previamente discuti-das) com o propósito de melhorar ainda mais o processo de classificação no futuro.

Um pequeno pormenor incluído neste módulo é o funcionamento do algoritmo mesmo na presença de novos parâmetros de classificação até ali desconhecidos. O que acontece é que é atribuída uma probabilidade de relevância de 50% a esse novo parâmetro, a razão para tal foi mero senso comum. Assim é permitida a aprendizagem automática do classificador e fica apenas a cargo do extractor de candidatos e classificação de visualizações a quantidade de parâmetros presente no sistema.

3.3.5 Gestão da lista final

A lista final é o produto dos classificadores de conteúdo. Após o cálculo das probabilidades "relevante"e "não-relevante"(ou "sim"e "não"), os que tiverem valores de "relevante"superior às do "não-relevante"serão seleccionados para a lista final.

Assinalado na figura 3.7 (ou 3.2) a laranja, tem-se ilustrado o ponto de junção com outros módulos, possivelmente filtragem colaborativa ou outro qualquer módulo auxiliar para filtragem

26 Descrição do Sistema Decisão conjunta (Naïve Bayes) Broker Processamento final Módulo de filtragem colaborativa Avaliação global dos candidatos Construção da lista final Selecção variada de diferentes recomendações Envio

Figura 3.7: Gestão da lista final

das recomendações, que não foi objectivo desta dissertação mas que poderá ser um objectivo futuro do projecto.

A lista final poderá ser muito extensa pelo que haverá, ainda a definir, um processo de se-lecção e de disponibilização ao utilizador. Esta disponibilização pode ter várias abordagens. Uma poderá ser o feedback do Broker para as STB em que no EPG é assinalado, com alguma imagem marcadora, todas recomendações relevantes. Outra opção poderá ser desenvolver uma interface tipo "grelha"que selecciona um número X de recomendações de cariz diferente. Neste caso seria preciso realizar uma filtragem cuidada da lista final, de modo a seleccionar os mais relevantes ou então de géneros diferentes de modo a evitar sobre-especialização.

3.4

Sumário

Viu-se aqui como foi abordado o problema de recomendação. No próximo capítulo será estu-dado o resultado e a performance da actual implementação, bem como o trabalho futuro.

Capítulo 4

Análise e trabalho futuro

4.1

Introdução

Agora que o sistema foi apresentado e detalhado, resta então analisar o caso de utilização para geração das recomendações, o seu comportamento bem como os actuais pressupostos e conse-quências.

4.2

Casos de utilização

Aqui serão apresentados os casos de utilização bem como a execução de um deles. Considere-se os actores:

1. Aplicação cliente - é aquela que satisfará o pedido para gerar recomendações ou actualizar o perfil do utilizador.

2. Set-top-box - é aquele que gera pedidos de listas de recomendações actualizadas

Na figura4.1tem-se os casos de utilização identificados inicialmente.

O caso de utilização de recomendação acontecerá sempre que for requisitado uma lista ac-tualizada de recomendações. Este processo poderá acontecer no acesso ao EPG local da STB ou no desencadear de um pedido directo por parte do utilizador. Como a "Classificação de visualizações"encontra-se em desenvolvimento, pelos motivos já mencionados, será agora expli-cada a execução do caso de utilização "Geração de classificações".

28 Análise e trabalho futuro Publicação de evento Set-top-Box Geração de recomendações Sistema de Recomendação TV Client Application Actualização de perfil Sistema PubSub (Publish-subscribe) Broker de contexto Pedido de recomendações Nova actividade Classificação de visualizações Extracção e geração de recomendações

Figura 4.1: Casos de utilização

4.2.1 Descrição

4.2.1.1 Diagrama de classes

O diagrama de classes associado a este caso de utilização encontra-se figurado na figura4.2.

Class Client

Esta é a classe de implementação que irá fazer o tratamento de todos os pedidos, neste caso de utilização é inicializada e irá instanciar a classe de recomendação (NBC), extracção de direc-tório(GetDir) e extracção de candidatos(Readcand). Finalmente cria a lista final ao atribuir os diferentes pesos às decisões da classe de recomendação.

Class GetDir

Esta é a classe para extracção de ficheiros em directórios e é instanciada tanto na inicialização do "Cliente"como na "Extracção de candidatos". O primeiro com objectivo de extrair todos os utilizadores da base de dados e a segunda para extracção de todos os ficheiros EPG após a sua actualização.

Class Readcand

Esta é a classe que trata do processo de extracção de candidatos, começa por actualizar os EPG (instancia Websc para pesquisa SAPO) e em seguida irá fazer o tratamento de cada um deles, programa a programa. No decorrer do processo aquando o tratamento das sinopses (handledesc()) é instanciada uma pesquisa de géneros (GenreSearch).

4.2 Casos de utilização 29 +C->Client() : void +C->start() : void +r->readcandstart() : wchar_t +N->NBCcalcG() : double +N->NBCcalcT() : double +N->NBCcalcC() : double +N->getNBCT() : double +N->getNBCC() : double +N->getNBCT() : float +N->getNBCT() : float +Decide() : bool +r->~readcand() : void +N->~NBC() : void +C->~Client() : void

-dir1 : wchar_t = "Historicals/"+user+"/recomlist.txt" -dir2 : wchar_t = "Historicals/"+user+"/candidates.txt" -dir3 : wchar_t = "Historicals/"+user+"/candnames.txt" -CalcNBC : float = NULL

-CalcNBC2 : float = NULL -CalcNBC3 : float = NULL -CalcS : double = 0 -CalcN : double = 0 -allcands : wchar_t = NULL -allcandsna : wchar_t = NULL -users : wchar_t = NULL -result : wchar_t = NULL -gd : GetDir = new GetDir() -r : Readcand = new Readcand() -N : NBC = new NBC() +Client() : void +~Client() : void «implementation class» Client +getUsers() : wchar_t +getEPG() : wchar_t -Users : wchar_t = NULL -EPGFiles : wchar_t = NULL +getUsersFiles() : void +getEPGFiles() : void +GetDir() : void +~GetDir() : void GetDir +readcandstart() : void +refreshEPGfiles->DownloadPage() : Websc +getEPGfiles() : void +handlefile() : candidates +handleprogram() : void +handletitle() : wchar_t +handledesc() : void +GS->handlefeatures() : GenreSearch +handletime() : void +normalizeclassification() : void +format() : void -type : tipos -timestring : wchar_t -handlefilecandidate : candidates -result : product +readcand() : void +~readcand() : void Readcand +getNBCG() : float +getNBCC() : float +getNBCT() : float -NBCG : float -NBCC : float -NBCT : float +NBC() : void +~NBC() : void +NBCcalcG() : void +NBCcalcT() : void +NBCcalcC() : void NBC +SearchWEBP() : Info +DownloadPage() : void +ExtractSearchResults() : void +ExtractCode() : void +verifyTitle() : void +ExtractInfo() : void +GetGen() : void -SRS : wchar_t -CS : wchar_t -VTS : wchar_t -GGS : wchar_t -ExI : Info +Websc : void +~Websc : void Websc +releaseDate : wchar_t +genres : wchar_t +creators : wchar_t +cast : wchar_t «struct»Info +type : wchar_t +ep : wchar_t +se : wchar_t +name : wchar_t +genres : wchar_t «struct»tipos +titles : wchar_t +type : wchar_t +description : wchar_t +time : wchar_t «struct»candidates +channel : wchar_t +list : candidates «struct»product «uses» «uses» «uses» «uses» +handlefeatures()() : candidates +token() : wchar_t +Search->SearchWEBP() : Info +GenreSearch() : void +~GenreSearch : void GenreSearch 1..* 1 1 1..* 1 1..* 1 1 1 1 1 1 1 1

Figura 4.2: Diagrama de classes

Class GenreSearch

É a classe irá tratar da classificação quanto a géneros recorrendo primeiramente a uma análise de palavras-chave das sinopses e em seguida se necessário uma pesquisa Web.

30 Análise e trabalho futuro

Class Websc

É a classe que trata das navegações Web, é utilizada duas vezes. Primeiramente na "Extracção de candidatos"para actualização dos EPG e também sempre que é necessária uma busca no Website IMDB.

Class NBC

Após a "Extracção de candidatos", é esta a classe que irá classificá-los sequencialmente de acordo com o perfil de teste. Esta classe resolve os três processos de recomendação através de três métodos específicos para tal.

4.2.2 Simulação

4.2.2.1 Dados de entrada

Nesta simulação utilizaram-se os seguintes elementos:

• Perfil de teste figurado em4.3.

• Lista de canais a procurar informação: "TVI","SIC","SPTV1","RTP1","AXN","FOX","TVC1".

• Hora de simulação 14:25 de uma Terça-feira. Estes parâmetro influenciam a extracção dos EPG pois irá considerar um período de 24 horas desde essa hora até ao dia seguinte.

• As listas de palavras-chave para análise das sinopses são as mesmas que se encontram no anexoB.

Note-se: O Perfil de teste é composto por três partes, uma para cada entrada (método) do motor de recomendação (Class NBC).

4.2 Casos de utilização 31

Figura 4.3: Perfil de teste utilizado

4.2.2.2 Execução

Quanto à execução as imagens que melhor a ilustram encontram-se no anexoC. Pode-se con-statar na figuraC.1o acto de actualização dos EPG dos canais teste automaticamente. Na figura C.2 temos o restante tratamento que formata os programas pré-recomendação da figura 4.4 e "alimenta-os"ao motor de recomendação. Termina finalmente com atribuição de pesos e gera a

32 Análise e trabalho futuro

lista final ilustrada na figura4.5.