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.
4.2 Casos de utilização 33
4.2.2.3 Resultados
Figura 4.5: Resultado de recomendação
4.2.2.4 Discussão
O resultado como podemos ver é satisfatório. Os géneros escolhidos estão muito de acordo com o do perfil de teste, no entanto há a salientar vários aspectos:
1. Existem alguns erros de classificação (Ex."Televendas"com género "football"), no entanto estes erros são produto do use das listas de palavras-chave actuais, este problema será ob- jecto de melhoramento no futuro. O uso de géneros com letras todas maiúsculas em alguns dos casos foi propositado para demonstrar a diferença de atribuição de géneros através do Website IMDB (géneros com letras minúsculas) e listas de palavras-chave (géneros com letras todas maiúsculas)
2. No perfil de teste note-se que há rejeições de programas de desporto, o resultado são re- jeições de programas desportivos, daí os poucos resultados para o canal "SPTV1"que dis- tribuí essencialmente programas desportivos.
3. A simulação ocorreu durante a tarde e por mero acaso, detectou apenas programas de in- teresse durante o horário "noite"e "não-fim-de-semana"(este último como seria de esperar já).
4. Uma das limitações está também no facto que os programas recomendados são "demasi- ado"parecidos com os do perfil, quer isto dizer que novas combinações de géneros são
34 Análise e trabalho futuro
muitas vezes rejeitadas. Será isto também um detalhe a corrigir. Poder-se-á ver na figura 4.4um excerto da lista de programas antes do processo de classificação, bem como algumas das combinações de géneros referidas.
4.3
Comportamento
Quanto ao comportamento o poder computacional necessário não é nada exigente. No entanto muito ainda resta a fazer e muitas decisões a tomar. Poder-se-á por exemplo correr filtragem de conteúdo nas STB e deixar filtragem colaborativa para um servidor à parte. Se se decidir construir um módulo composto de recomendação com a junção de técnicas colaborativas e de conteúdo, aí a complexidade aumentará e o ajuste para que tudo funcione terá que ser bem ponderada, para não falar da necessidade de uma máquina de maior poder computacional.
As listas de géneros e palavras-chave a eles relacionadas foram geradas manualmente e de modo iterativo, quer isto dizer que iterativamente tentou-se adicionar às listas palavras relacionadas a certos géneros. O maior problema desta abordagem é que limita o número de géneros admis- síveis, isto porque haverão palavras que estarão relacionadas a vários géneros por serem um pouco "gerais". Para além disso por vezes as sinopses são também muito curtas o que dificulta mais o processo de atribuição de géneros, se nenhum género for atribuído ao programa o algoritmo irá ignorá-lo como candidato. Apesar disto, estas listas são importantes, pois contribuem para a detecção de tipo de programa.
4.4
Trabalho futuro
O actual objectivo é o de finalizar o processo "classificação das visualizações". As STB ainda não transmitem como pretendido, isto é, existem ainda falhas no envio para o broker o que tem vindo a dificultar avanços neste processo, este problema deve-se a factores exteriores aos objec- tivos desta dissertação.
Em contrapartida, após a análise do tipo de dados que as STB transmitem realmente foi pos- sível verificar que a informação XML da sintonização actual é completamente idêntica àquela figurada em3.4, com a excepção do campo da sinopse («description>"). Quer isto dizer essencial- mente que irá ser necessário resolver esta questão para que se possa atingir o perfil de utilizador pretendido. Para isso será necessário melhorar a classificação de géneros de uma das seguintes maneiras:
1. Desenvolver um motor de busca. Assim seria possível extrair, para qualquer tipo de con- teúdo, a sua correcta classificação através da Web. Esta é a opção também mais "pesada"e difícil de implementar. Apesar disto poder-se-ia explorar a integração com a API da Google, visto que são disponibilizados muitos serviços para tal. No entanto haveria uma limitação devido à linguagem de programação que teria de ser alterada pois não há suporte em C++.
4.4 Trabalho futuro 35
2. Com a ligação bem sucedida ao Website IMDB, poder-se-á considerar outro Website que permita ajudar a identificar os géneros dos programas de modo semelhante. Esta será uma opção intermédia quanto à dificuldade implementação dado que a maior parte dos Websites dificultam as ligações a eles feitas através de scratching1.
3. A última opção é mais simples mas a sua solução recai mais no sistema da PT. A ideia seria utilizar algum outro serviço já existente, possivelmente equivalente ao da SAPO. Então aí poucas alterações seriam necessárias.
Com estas alterações fará sentido também abandonar o uso das listas de palavras-chave que provaram ser menos eficientes na atribuição de géneros.
Antes de partir para a simulação de vários utilizadores deverá então proceder-se ao melhora- mento da performance e correcção de pequenos bugs (maior variedade na combinação de géneros, como exemplo).
O próximo objectivo será simular a presença de vários utilizadores e tentar captar itens block- buster. Considerando novamente a figura 3.7 e o processo "Selecção variada de diferentes re- comendações", pensa-se que seria uma boa adição o uso desses itens populares à grelha de apre- sentação de recomendações.
Finalizando com a junção dos dois tipos de filtragem, foram apresentadas algumas soluções no capítulo2. Na continuação do que foi descrito quanto a filtragem colaborativa, ficou assinalada a possibilidade desse módulo seguir métodos heurísticos de comparação de utilizadores baseado em históricos de conteúdo (ou perfis). Para tal criavam-se vectores correspondentes aos utilizadores em que compareciam os pesos (ocorrências em visualizações) dos géneros/data/canal/tipo e isso permitiria a comparação entre utilizadores. O processo de geração da lista final teria em conta programas visualizados por utilizadores semelhantes juntamente com filtragem de conteúdo.
1Técnica utilizada para ligação ao Website IMDB que consiste basicamente, na análise do próprio código HTML
Capítulo 5
Conclusão
Neste capítulo irá ser feita a conclusão ao documento que retratou o trabalho desenvolvido nos últimos meses. O projecto em si continuará a ser desenvolvido até se atingirem todos os objectivos.
5.1
Conclusão
Foi aqui apresentado o desenvolvimento de um sistema de recomendação para TV. Com a falta apenas do perfil de utilizador, que deveria ser construído através da classificação de visualizações. É essa portanto a prioridade para finalizar logo que a informação proveniente das STB esteja a publicar convenientemente. Refira-se no entanto que a "classificação de visualizações"não foi finalizada dado que falhou o bom funcionamento na troca de informação entre as STB e o broker que não esteve dentro do âmbito desta dissertação. Apesar disto, o actual resultado na geração da lista final é satisfatório, apesar de haver alguma dificuldade em atribuir correctamente os géneros a programas que não "séries"e "filmes", partindo apenas da sinopse.
A escolha do motor de classificação utilizado parece ser satisfatória, tendo em conta os recur- sos para já disponíveis. Para além disso, cumpriu-se o objectivo de "poli-valência"do código. O algoritmo corre rapidamente mesmo sem grande poder computacional pelo que até poderia correr em plataformas móveis por exemplo. Dos poucos pressupostos do sistema é o uso de informação de input dos candidatos em formato XML que é um dos formatos mais populares e eficientes.
Adicionalmente caso se pretenda abordar temas como targeted advertisement também e pos- sível desde que os anúncios contenham descrições sobre o conteúdo em géneros bem definidos.
Finalmente Prevêem-se também que pequenos ajustes terão que ser efectuados caso se pre- tenda a aplicação do programa noutro domínio. Especialmente quanto à extracção automática de informação na Web, pois depende muito da formatação e estrutura do website que se pretende aceder.
Anexo A
Descrição das técnicas
Todas as técnicas enumeradas nos diferentes sistemas de recomendação serão agora descritas na sua generalidade.