Treball final de grau

GRAU D’ENGINYERIAINFORMATICA

Facultat de MatematiquesUniversitat de Barcelona

MILLORA DELS PROCESSOSDE RECOMANACIO A TRAVES

D’ALGORISMES DEEXPERIENCE-BASED

Autor: Francesc Bosch Florit

Directora: Dra. Maria Salamo Llorente

Realitzat a: Departament de Matematica

Aplicada i Analisi

Barcelona, 28 de gener de 2016

Abstract

With the recent increase in Internet use (among other data sources) there is acorresponding growth of the total information available to users. An importantproblem associated to this overload problem is that it is becoming more and moredifficult for users to locate specific pieces of information. Therefore it is necessaryto have some kind of help to guide users in finding exactly what they seek amongthis large volume of information. Recommender systems manage large volumesof data and information to support users in the search for relevant and specificsearch outcomes. There are many types of recommender systems, which can bebroadly classified into two main categories, each used for a different purpose. Theseare content-based and collaborative filtering recommender systems. This projectfocuses on the first group of systems, those based on content. Specifically, wefocus on conversational recommender systems concentrating on user critique-basedfeedback.

The main objectives of the project are to develop a study of the different recom-mender systems; to implement, on the library’s recommendation research group Vo-lume Visualization and Artificial Intelligence (WAI) developed in Java, experinced-based algorithms such as History-Aware Critiquing (HAC), Experience-based Criti-quing (EBC) and Graph-based algorithms; and to perform a comparative analysisof every approach implemented in order to evaluate the improvement over the stan-dard critiquing algorithms (IC and Std). The results obtained form this comparisonshow that experience-based algorithms performance is the best within current re-commendation algorithms and they have remarkably improved upon the standardcritiquing-based approaches.

i

Resum

Degut al creixement d’Internet, entre altres grans fonts de dades, tenim que cadavegada hi ha mes informacio disponible. El problema es que cada vegada es moltmes difıcil pels usuaris poder trobar informacio concreta, i per tant es necessaritenir algun tipus d’ajuda per guiar l’usuari a trobar el que busquen entre tot aquestvolum d’informacio. Els sistemes recomanadors s’ocupen de gestionar grans volumsde dades i informacio, per donar suport a l’usuari en la cerca d’informacio concreta.Existeixen molts de tipus de sistemes recomanadors, es poden classificar en 2 catego-ries, els basats en contingut o els de filtrat col·laboratiu, cada sistema recomanadors’utilitza per una finalitat diferent. Aquest projecte se centra en el primer grup: elsbasats en contingut, i en concret en els sistemes recomanadors conversacionals quees basen en una retroalimentacio basada en crıtiques de l’usuari.

En aquest projecte els objectius principals son: realitzar un estudi dels diferentssistemes recomanadors; implementar, sobre la llibreria de recomanacio del grup derecerca Volume Visualization and Artificial Intelligence (WAI) desenvolupada enJava, algorismes d’Experince-based com son el History-Aware Critiquing (HAC), elExperience-based Critiquing (EBC) i el Graph-based; i realitzar la comparativa delsalgorismes implementats per tal de veure quina es la millora respecte als algorismesestandard de critiquing (IC, Std). El resultat d’aquesta comparativa demostraque els algorismes en experience-based son mes acurats en la recomanacio que elsalgorismes estandard de critiquing.

ii

Resumen

Debido al crecimiento de Internet, entre otras grandes fuentes de datos, cada vezexiste mas informacion disponible. El problema esta en que cada vez es muchomas difıcil para los usuarios que puedan encontrar informacion concreta, por tantoes necesario disponer de algun modo de ayuda para guiar al usuario, entre todoeste volumen de informacion, a encontrar lo que esta buscando. Los sistemas derecomendacion se encargan de gestionar grandes volumenes de datos e informa-cion, para dar soporte al usuario en la busqueda de informacion precisa. Existenmuchos tipos de sistemas de recomendacion, se pueden clasificar en 2 grandes cate-gorıas, los basados en contenido o los de filtrado colaborativo, cada sistema usadoen propositos distintos. Este proyecto se centra en el primer grupo: los basados encontenido, y mas concretamente en los sistemas recomendadores conversacionalescon retroalimentacion basada en crıticas de usuario.

En este proyecto los objetivos principales son: realizar un estudio de los dife-rentes sistemas de recomendacion; implementar sobre la librerıa de recomendaciondel grupo de investigacion Volume Visualization and Artificial Intelligence (WAI),desarrollada en Java, algoritmos d’Experince-based como son el History-Aware Cri-tiquing (HAC), el Experience-based Critiquing (EBC) y el Graph-based; y compararlos algoritmos implementados para ver cual es la mejora respecto a los algoritmosestandares de critiquing (IC, Std). El resultado de esta comparativa demuestraque los algoritmos basados en experience-based mejoran las recomendaciones encomparacion a los algoritmos estandar de critiquing.

iii

Agraıments

Aquest projecte no hauria estat possible sense la dedicacio i esforc que requereix,pero tampoc sense el suport que m’han estat donant en tot moment. Per aixom’agradaria agrair a Maria Salamo, tutora del Treball, pel seu constant suporti ajuda, aixı com a David Contreras, que esta realitzant el seu doctorat sobreaquest mateix tema, per donar-me suport tambe sobretot en alguns aspectes mesrelacionats amb l’entorn de programacio

iv

Index

1 Introduccio 11.1 Marc del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Motivacio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Objectiu general del projecte . . . . . . . . . . . . . . . . . . . . . . 21.4 Objectius especıfics del projecte . . . . . . . . . . . . . . . . . . . . 21.5 Organitzacio de la memoria . . . . . . . . . . . . . . . . . . . . . . 3

2 Estat de l’art 42.1 Sistemes de recomanacio . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1 Filtrat col·laboratiu: . . . . . . . . . . . . . . . . . . . . . . 52.1.2 Basat en contingut: . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Sistema de recomanacio conversacional . . . . . . . . . . . . . . . . 82.2.1 Retroalimentacio (Feedback): . . . . . . . . . . . . . . . . . 82.2.2 Cicle del proces de recomanacio: . . . . . . . . . . . . . . . . 92.2.3 Recomanadors basats en crıtiques: . . . . . . . . . . . . . . . 10

3 Critiquing 113.1 Incremental Critiquing . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1.1 Algorisme d’incremental critiquing . . . . . . . . . . . . . . 123.1.2 Reinforcement Learning (RL) . . . . . . . . . . . . . . . . . 153.1.3 Highest compatibility (HCS) . . . . . . . . . . . . . . . . . . 16

3.2 Experience-based critiquing (EBC) . . . . . . . . . . . . . . . . . . 163.2.1 Algorisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3 History-Aware Critiquing . . . . . . . . . . . . . . . . . . . . . . . . 183.3.1 Algorisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.4 History-Guided Conversational Recommendation . . . . . . . . . . 203.4.1 Algorisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.5 History Opinion Recommendations . . . . . . . . . . . . . . . . . . 223.5.1 Algorisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.6 Graph-based . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.6.1 Algorisme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4 Analisi de l’entorn, disseny i implementacio 284.1 Analisi de l’entorn . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.1.1 Paquets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.1.2 Simulador . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.1.3 XML: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2 Interaccio basica entre classes . . . . . . . . . . . . . . . . . . . . . 334.2.1 QueryEngine . . . . . . . . . . . . . . . . . . . . . . . . . . 334.2.2 RecStrategy . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.2.3 CaseRec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.2.4 QueryRec . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.3 Graph-based . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.3.1 Implementacio . . . . . . . . . . . . . . . . . . . . . . . . . . 43

v

5 Avaluacio 445.1 Query . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.2 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.3 Analisi dels Resultats . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.3.1 Crıtiques unitaries . . . . . . . . . . . . . . . . . . . . . . . 455.3.2 Compound Critique . . . . . . . . . . . . . . . . . . . . . . . 485.3.3 Resum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6 Valoracio economica 506.1 Temps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.2 Cost economic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7 Conclusions 52

vi

Index de figures

1 Classificacio dels sistemes recomanadors segons iteracions . . . . . . 42 Classificacio dels sistemes recomanadors segons especificacions . . . 53 Taula de valoracions dels usuaris, en un recomanador de pel·lıcules . 64 Taula de resultats de la similitud basada en la funcio del cosinus . . 75 Cicle dels sistemes recomanadors conversacionals estandards . . . . 106 Cicle dels sistemes recomanadors incremental critiquing . . . . . . . 117 Graf de sessio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 Diagrama de classes del funcionament del simulador. . . . . . . . . 319 Diagrama general d’interaccions entre classes . . . . . . . . . . . . . 3410 Diagrama query estandard . . . . . . . . . . . . . . . . . . . . . . . 3411 Diagrama preCaseRec per a IC . . . . . . . . . . . . . . . . . . . . 3512 Diagrama recCases per a l’algorisme Incremental Critiquing . . . . 3613 Diagrama recCases per a l’algorisme EBC . . . . . . . . . . . . . . 3814 Diagrama recCases per a l’algorisme HAC . . . . . . . . . . . . . . 3915 Diagrama recCases per a l’algorisme HGR . . . . . . . . . . . . . . 4116 Diagrama recCases per a Compound Critiques, basat amb Grafs . . 4217 Diagrama recQueries per a l’algorisme IC . . . . . . . . . . . . . . . 4218 Mitja de session length per a Smartphone . . . . . . . . . . . . . . . 4619 Session length Q1 per a Smartphone . . . . . . . . . . . . . . . . . 4620 Session length Q3 per a Smartphone . . . . . . . . . . . . . . . . . 4721 Session length Q5 per a Smartphone . . . . . . . . . . . . . . . . . 4722 Compound critique, comparacio per algorismes . . . . . . . . . . . . 4823 Session lenght segons threshold per a LS . . . . . . . . . . . . . . . 4924 Desglossament de les tasques segons el temps invertit . . . . . . . . 5025 Desglossament del preu segons tasques . . . . . . . . . . . . . . . . 51

vii

Index d’Equacions2.1 Similitud de Pearson . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Similitud de cosinus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Satisfy estandard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4 Argmax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.1 User Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2 Calcul compatibilitat IC . . . . . . . . . . . . . . . . . . . . . . . . . . 143.3 Quality per a IC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.4 Quality millorat per a IC . . . . . . . . . . . . . . . . . . . . . . . . . 143.5 Compatibility positiu RL . . . . . . . . . . . . . . . . . . . . . . . . . 153.6 Compatibility negatiu RL . . . . . . . . . . . . . . . . . . . . . . . . . 153.9 Format de sessio basat en crıtiques . . . . . . . . . . . . . . . . . . . . 173.10 OverlapScore per a EBC . . . . . . . . . . . . . . . . . . . . . . . . . . 183.11 RelevantSessions per a EBC . . . . . . . . . . . . . . . . . . . . . . . . 183.12 Recommend per a EBC . . . . . . . . . . . . . . . . . . . . . . . . . . 183.13 Format dades per a HAC . . . . . . . . . . . . . . . . . . . . . . . . . 193.14 Similarity per a HAC . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.15 Quality per a HAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.17 RelevantSessions per a HAC . . . . . . . . . . . . . . . . . . . . . . . . 203.17 Recommend per a HAC . . . . . . . . . . . . . . . . . . . . . . . . . . 203.20 RelevantSessions per a HGR . . . . . . . . . . . . . . . . . . . . . . . 213.20 OverlapScore per a HGR . . . . . . . . . . . . . . . . . . . . . . . . . 213.20 OverlapScore2 per a HGR . . . . . . . . . . . . . . . . . . . . . . . . . 213.21 RecScore per a HGR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.22 RecScore per a HOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.23 Compatibilitat per a HOR . . . . . . . . . . . . . . . . . . . . . . . . . 243.24 Similitud LW per a HOR . . . . . . . . . . . . . . . . . . . . . . . . . 243.25 Similitud LW detalla per a HGR . . . . . . . . . . . . . . . . . . . . . 243.26 Format sessions amb crıtiques compostes . . . . . . . . . . . . . . . . . 263.27 RSim similitud entre grafs . . . . . . . . . . . . . . . . . . . . . . . . . 27

viii

1 Introduccio

En aquest capıtol es descriu el problema a solucionar sobre la qual es realitza aquestprojecte, aixı com els objectius tant generals com especıfics on s’exposa el que esvol assolir i el que es fa al llarg del projecte, la motivacio personal que m’ha dut afer-lo, i l’organitzacio que es segueix en aquesta memoria.

1.1 Marc del problema

Cada vegada es mes frequent realitzar compres a traves de serveis automatitzats,com els de comerc electronic (e-commerce), o realitzar cerques online sobre produc-tes o informacio.

El problema que un usuari es troba es que hi ha una gran quantitat d’informacioi productes a Internet, fet que fa quasi impossible a un usuari poder gestionar tantainformacio i trobar el que esta buscant, o requereix de molt de temps per fer-ho.Per tant es important tenir un bon sistema de recomanacio per ajudar a l’usuari atrobar el producte o la informacio que esta buscant.

Un sistema recomanador es l’encarregat de recomanar a un usuari productesconcrets que segons la seva configuracio i/o segons les preferencies. Existeixendiferents tipus de sistemes recomanadors, segons la finalitat d’us es millor utilitzar-ne un enfront de l’altre. Els podem diferenciar en dos grans grups:

1. Basats en Filtrat col·laboratiu (Collaborative Filtering): Aquest tipus de reco-manador es basa amb les valoracions d’altres usuaris, per filtrar els productes.Dins del filtrat col·laboratiu, un recomanador pot ser del tipus User-based, ones recomanen els productes que a un usuari amb preferencies similar els hihan interessat, o pot ser de tipus Item-based, on es recomanen els productessimilars als que aquest usuari ha mostrat interes.

2. Basats en contingut (Content-based): Els sistemes de recomanacio basatsamb el contingut, realitzen les seves recomanacions a partir de la descripcio icaracterıstiques del producte. Tambe es poden dividir en varis sistemes mesespecıfics com: el Rating-based o collaborative, el primer com el nom indicaesta basat en el puntuacio, el segon amb les preferencies dels usuaris.

En aquest treball s’estudia el segon grup, els basats en contingut, que son els quese centren mes amb les caracterıstiques. Dins dels algorismes de recomanacio basatsen contingut, es treballara concretament en els algorismes conversacionals basatsen crıtiques, els quals interactuen amb els usuaris obtenint una retroalimentaciomitjancant l’us de crıtiques a un producte, per tal de recomanar el millor producte.

Els Critiquing-based Recommender son els sistemes on es recomana segons lacrıtica 1 d’un usuari sobre la caracterıstica d’un producte. L’avantatge d’utilitzaraquest sistema es que l’usuari no necessita saber molt sobre un producte o sobre el

1Una crıtica es una preferencia direccional sobre una caracterıstica del producte.

1

que esta buscant exactament, nomes necessita unes nocions basiques, es a dir si elproducte recomanat es del seu gust o no, si prefereix un producte modificant algunacaracterıstica, com per exemple si esta buscant un PC, una crıtica pot ser baixar elpreu o mes memoria, o si esta buscant un cotxe, una crıtica pot ser menys cilindrada.Aquests sistemes permeten una gran personalitzacio segons les necessitats de cadausuari.

1.2 Motivacio

La motivacio principal per la qual m’ha dut a fer aquest projecte es que esta en unade les arees dins de la informatica que mes m’atreuen, la intel·ligencia artificial, aixıcom el fet d’haver d’implementar alguns algorismes tambe hem fa possible progra-mar codi. Concretament, hem permet millorar les meves habilitats de programacioen Java.

A mes es combina amb la gestio de grans dades, Big data, i l’analisi d’aques-tes, cada vegada mes estesos i que en un futur sera inevitable haver de treballarconstantment sobre aquests sistemes.

El fet que es treballi sobre un sistema ja implementat tambe em pot ajudar a tenirmes facilitat a l’hora de treballar en empreses, on s’ha d’estar treballant constant-ment sobre projectes ja implementats, o en col·laboracio amb altres treballadors, iper tant s’ha de fer una lectura previa del sistema, i entendre com funciona.

1.3 Objectiu general del projecte

L’objectiu general es l’estudi, implementacio i comparativa dels algorismes de reco-manacio conversacionals basats en crıtiques de la famılia dels experience-based, pertal de veure quina es la millora respecte als algorismes estandard de critiquing (IC,Std).

Concretament, s’estudien i es comparen els algorismes d’Experience-based Cri-tiquing (EBC), History-Aware Critiquing (HAC), History-Guided ConversationalRecommendation (HGR), History Opinion Recommendations (HOR) i graph-basedrespecte al estandard critiquing (STD) i a l’Incremental Critiquing (IC).

1.4 Objectius especıfics del projecte

El primer dels objectius especıfics es fer un estudi de la literatura en l’area de recercadels algorismes de recomanacio basats en crıtiques.

El segon objectiu especıfic es realitzar un estudi previ dels algorismes dels siste-mes recomanadors basats en crıtiques en general, i dels casos amb crıtiques unitariesi compostes, i amb mes detall s’estudien els algorismes d’experience-based, per aixıpoder implementar-los.

Com a tercer objectiu especıfic es planteja la implementacio dels algorismesd’experience-based, basant-nos en l’estudi previ realitzat, i amb la informacio so-

2

bre aquests algorismes, implementar en concret els algorismes HAC, HGR, EBC igraph-based, introduint-los a la llibreria de recomanacio del grup de recerca VolumeVisualization and Artificial Intelligence (WAI) amb algorismes de critiquing.

Addicionalment, com a objectiu especıfic es vol analitzar i comparar els algoris-mes experience-based implementats anteriorment, utilitzant un simulador, respectea Incremental Critiquing (IC), i l’algorisme estandard de critiquing (Std) que noutilitzen l’experiencia d’altres usuaris per a recomanar productes.

1.5 Organitzacio de la memoria

Aquesta memoria esta organitzada en set capıtols.

En el primer capıtol s’ha introduıt el projecte en general, on s’han descrits elsproblemes a solucionar i els objectius que es volen aconseguir en aquest projecte.

En el segon capıtol es descriu l’estat de l’art, on s’expliquen i es comparen elsdiferents tipus de sistemes de recomanacio.

Al tercer capıtol es detallen els sistemes de Critiquing, i s’expliquen els algorismesbasats en crıtiques i les diferents formules i equacions que s’utilitzen per recomanarproductes.

Al capıtol 4, l’analisi de l’entorn, disseny i implementacio, es pot veure la plata-forma que s’utilitza per implementar els algorismes, i el simulador d’usuaris amb elseu funcionament. Tambe es mostren els diferents diagrames per ajudar a entendreel funcionament, i s’explica com s’han implementat cadascun dels algorismes.

Al capıtol 5, es veuen els resultats de la comparativa aplicant els diferents al-gorismes, en un conjunt de dades de mobils. Tambe s’explica el conjunt de dadesutilitzat, la metodologia seguida i com s’extreuen els resultats.

Al capıtol 6, es detalla la valoracio economica que es fa sobre el projecte presen-tat, i el desglossament del treball.

En el capıtol 7, a les conclusions, es presenta una valoracio personal sobre elprojecte i una valoracio sobre els resultats, s’exposen les conclusions a les quals s’haarribat, i s’expliquen els objectius que s’han assolit.

3

2 Estat de l’art

En aquest capıtol, es defineix el sistema de recomanacio, s’expliquen i es comparenels diferents tipus de sistemes, explicant de manera mes detallada els sistemes con-versacionals, que son i per que s’utilitzen. Es defineixen les bases del projecte, perajudar a entendre el que s’implementara en els proxims capıtols.

2.1 Sistemes de recomanacio

Un sistema recomanador [6] es un sistema que basant-se amb les caracterıstiquesde cada usuari, proporciona una o varies recomanacions.

Els sistemes recomanadors es poden dividir de moltes maneres [2]. Una d’ellesson les iteracions que realitza l’usuari dins el sistema recomanador, per aixo podemdividir en dos grups, com es mostra en la Figura 1. Single-shot Recommender : l’u-suari realitza unes preferencies previes i s’identifica a dins del recomanador, el qualrealitzara una serie de recomanacions, l’usuari ja no interactua mes amb el sistemaperque recomani nous ıtems, per tant nomes fa una iteracio. El ConversationalRecommender en canvi, realitza una serie de recomanacions per l’usuari en base ales seves preferencies, pero amb la diferencia que recomana ıtems recursivament i onen cada iteracio l’usuari aporta una retroalimentacio (feedback) per tal de millorarla proxima recomanacio, aquest sistema no finalitza fins que l’usuari troba algunarecomanacio apta per a les seves necessitats.

Figura 1: Classificacio dels sistemes recomanadors segons iteracions

A la Figura 1 es veuen els dos tipus, on el marcat de color blau son els sistemesque s’utilitzaran en aquest projecte. Aquests sistemes conversacionals es podendividir tambe en diferents grups, entre altres, pel tipus de retroalimentacio que dona

4

l’usuari en cada cicle o iteracio, tenim: value elicitation, rating-based, preference-based i critiquing-based.

Un altre punt de vista pel que fa a la classificacio de sistemes recomanadors, sondividint segons les especificacions, o el que es te en compte d’un usuari o ıtem perrecomanar. Es a dir, si es tenen en compte nomes el nom d’ıtem i la valoracio, o sitambe es tenen en compte altres atributs mes especıfics. Tal i com mostra la Figura2, aquı trobem tambe dos grups, Collaborative Filtering o Content-based :

Figura 2: Classificacio dels sistemes recomanadors segons especificacions

2.1.1 Filtrat col·laboratiu:

Els algorismes de recomanacio basats en filtrat col·laboratiu [6] es basen en lesvaloracions d’altres usuaris per filtrar els productes. Dins del filtrat col·laboratiu,un sistema pot ser User-based, on es recomanen els productes que a un usuari ambpreferencies similars els hi han interessat, o pot ser Item-based, on es recomanen elsproductes similars als productes sobre el que aquest usuari ha mostrat interes.

L’usuari que esta interactuant amb el sistema recomanador ha realitzat una seriede valoracions (normalment un rating o valor entre 1 i 5) sobre diferents ıtems,indicant les seves preferencies i gustos. Despres al recomanar nous ıtems, el sistemate en compte els gustos de l’usuari, i busca similituds amb altres usuaris que hanutilitzat el sistema. I finalment recomana ıtems, que els usuaris mes similars (tenenels gustos i preferencies mes iguals), han valorat millor.

Alguns exemples on s’utilitzen aquests sistemes, i funcionen be son els recoma-nadors de pel·lıcules, ja que els usuaris poden puntuar les pel·lıcules i el sistema derecomanacio, en base a usuaris similars, recomana facilment ıtems ben puntuats. I

5

pel que fa a webs o empreses que l’utilitzen, trobem a Amazon2 tot i que utilitzatambe algun hıbrid entre aquest i content-based o Netflix3 i IMDB4 per recomanarpel·lıcules.

A l’hora de calcular la similitud, sigui per trobar l’usuari mes semblant en el casde User-based, o per trobar ıtems similars per Item-based, es pot fer mitjancant elsmetodes de correlacio de Pearson o de cosinus.

-Similitud de Pearson:

Aquest metode segueix la correlacio de Pearson, utilitzada en molts ambits, i enaquest cas per trobar la similitud entre dos ıtems o dos usuaris, tal i com es veu enl’Equacio 2.1.

Sim(x, y) =

∑i∈Ixy

(rx,i − rx)(ry,i − ry)√ ∑i∈Ixy

(rx,i − rx)2∑i∈Ixy

(ry,i − ry)2(2.1)

-Similitud de cosinus:

Pel que fa a aquesta similitud, es segueix la formula descrita en l’Equacio 2.2.Per explicar-la amb mes detall es mostrara la seva utilitat mitjancant un exempled’us, amb un conjunt de dades molt reduıt.

Sim(x, y) = cos(~x, ~y) =~x · ~y

||~x||2 × ||~y||2=

∑i∈Ixy

rx,iry,i√∑i∈Ix

r2x,i

√∑i∈Iy

r2y,i

(2.2)

A la taula de la Figura 3 hi ha definida les valoracions (sabent que 1 es lavaloracio mınima i 5 la maxima) que s’han realitzat en un sistema recomanador depel·lıcules, col·laboratiu i basat en ratings.

Figura 3: Taula de valoracions dels usuaris, en un recomanador de pel·lıcules

Tenim definida una serie d’usuaris que ja han interactuat amb aquest sistema, ihan deixat les seves valoracions sobre els ıtems recomanats. Despres tenim l’usuari,Usuari Actual, que esta interactuant actualment amb el sistema, i al qual se li volrecomanar un producte.

2http://www.amazon.com3http://www.netflix.com4http://www.imdb.com

6

Per tal de poder recomanar una pel·lıcula, s’utilitzara el sistema User-based, elqual ha de comprovar la similitud entre els usuaris. I per calcular la similitud s’hautilitzat el metode de Cosine Similarity, definit a l’Equacio 2.2.

El primer que es fa es la suma de les multiplicacions dels ratings de cada ıtem,producte(x, y) =

∑i∈Ixy

rx,iry,i. Es a dir que, d’un usuari, es multiplica el valor de cada

ıtem, amb el mateix ıtem de l’usuari de referencia, i es sumen. Per l’usuari Joan,tenim que ha fet el seguent vector de valoracions 4,5,3,0,1, es fa el producte d’aquestamb el de l’usuari actual 0,5,0,1,0, i obtenim com a resultat 25. Els resultats delsproductes es poden veure a la segona columna de la Figura 4.

Per altre banda, es calcula l’arrel de la suma dels quadrats de les valoracio, per

cada usuari, arrelx =√∑

i∈Ixr2x,i. Per fer aixo primer obtenim la suma del quadrats

de les valoracions, 42 + 52 + 32 + 0 + 1 = 51 en el cas del Joan, i despres es fa l’arreld’aquests resultats, recollits en les columnes 3 i 4 de la Figura 4.

Per acabar es fa la divisio entre el producte de vectors i la multiplicacio entre elresultat obtingut anteriorment per cada usuari, i el resultat obtingut per l’usuaride referencia o actual.

Figura 4: Taula de resultats de la similitud basada en la funcio del cosinus

Com es veu a la Figura 4, l’usuari amb mes similitud al actual es el que obte unvalor de 0.769, per tant es tindra mes en compte les valoracions positives d’aquestrespecte a algun ıtem a l’hora de recomanar la proxima pel·lıcula a l’usuari actual.

2.1.2 Basat en contingut:

Els sistemes basats en contingut realitzen les seves recomanacions a partir de ladescripcio i caracterıstiques del producte. Tot i aixı, dins aquest grup tambe espoden tenir sistemes col·laboratius basats en contingut, on es tenen en comptealtres usuaris similars a aquest per tal de millorar la recomanacio. La diferencia esque el Filtrat Col·laboratiu no te en compte les caracterıstiques dels ıtems, i aquestsı, ja que la similitud de l’usuari es calculara en base tant als ıtems en sı, comamb les seves caracterıstiques, a mes el punt on mes difereix es amb el metode deretroalimentacio dels usuaris.

Pel que fa a aquest projecte, s’utilitzara els sistemes conversacionals [2] i basatsen contingut, aquests ofereixen una gran qualitat de recomanacions, permeten a

7

l’usuari interactuar amb el sistema ja que son conversacionals aplicant una retroa-limentacio sobre les recomanacions, i permet personalitzar bastant la cerca, ja quees basat en contingut i per tant es poden aplicar les retroalimentacions anteriorssobre atributs especıfics.

2.2 Sistema de recomanacio conversacional

Els sistemes conversacionals (Conversational Recommender)[9] son els que realitzenuna o varies recomanacions a l’usuari en base a les seves preferencies i de manerarecursiva, es a dir que si l’usuari no esta conforme amb els ıtems recomanats, escalculen noves recomanacions.

Aquests sistemes permeten a l’usuari dialogar amb el recomanador, de maneraque es pugui fer una aproximacio mes exacta en cada recomanacio. La manerad’interactuar de l’usuari es mitjancant retroalimentacio en forma de crıtiques, i nofinalitza fins que el sistema troba alguna recomanacio apta per a les seves necessitats.

Es segueix el metode d’iteracio o cicle, que consisteix en un proces que es repeteixcıclicament i canviant alguns parametres en cada repeticio, fins arribar a l’objectiufinal, en aquest cas que l’usuari accepti un ıtem recomanat.

En aquest projecte ens centrarem mes amb els sistemes basats en crıtiques, esa dir que son conversacionals, on l’usuari aporta una retroalimentacio sobre cadarecomanacio, i aquesta retroalimentacio es en forma de crıtica sobre algun atributo caracterıstica del producte o ıtem.

2.2.1 Retroalimentacio (Feedback):

La part mes important dels sistemes de recomanacio conversacionals es la retroali-mentacio. El feedback es la retroalimentacio que un usuari dona sobre un fet, en elcas dels recomanadors es la valoracio que en fa un usuari sobre un producte, la ma-nera que te l’usuari d’interactuar amb el sistema, i pel qual el sistema pot coneixerquin tipus de producte prefereix, i per tant millorar la recomanacio. Existeixenvaris metodes de retroalimentacio, i cada sistema conversacional es mes util en uncas o en l’altre. En l’entorn dels recomanadors conversacionals els mes importantsson:

1. Value elicitation: Es el metode mes especıfic i el que mes informacio aportasobre el producte que s’esta cercant pero per contra requereix un nivell alt deconeixement del producte en questio per part de l’usuari. Per exemple, si elsproducte son televisors, el sistema preguntaria de quantes polsades desitja eltelevisor. Aquest tipus de retroalimentacio es util en el cas que l’usuari sapigaexactament el que busca i tingui un bon coneixement de les caracterıstiquesd’aquest.

2. Ratings-based : Aquest metode es basa amb la valoracio d’un usuari sobreel producte. Es possiblement el mes facil per part de l’usuari, ja que sim-

8

plement ha de donar una valoracio al producte recomanat, per exemple do-nar un numero de 1 a 5. Es mes tıpic utilitzar-lo en els sistemes de filtratcol·laboratiu, en el qual es te una valoracio d’usuaris anteriors sobre el pro-ducte, sense tenir en compte les seves caracterıstiques.

3. Preference-based : Tambe es un metode que no requereix molt de coneixementper part de l’usuari, similar a l’anterior que valora el producte recomanat,pero en aquest cas selecciona el que millor s’adapta a les seves caracterıstiquesd’entre una llista de pocs productes. Nomes es necessita que l’usuari sapigaquin dels productes recomanats es millor.

4. Critiquing-based : Es el metode utilitzat en aquest projecte i que s’explicaraamb mes detall en el Capıtol 3. Es basa en la informacio sobre caracterıstiquesdel producte, com en el cas del Value elicitation pero amb la diferencia queen les crıtiques no es necessita tant de coneixement per part de l’usuari. Elsistema recomana un producte i proveeix a l’usuari una serie de crıtiques quel’usuari pot escollir quines s’adapten a les seves necessitats. Mentre que en elValue elicitation l’usuari ha de dir el valor de la caracterıstica que demana elrecomanador, en aquest cas es l’usuari que pot canviar el valor a una carac-terıstica o dir simplement que no li agrada aquesta. Per exemple, si es te unproducte amb una serie de caracterıstiques, l’usuari pot fer una crıtica sobreel preu, el qual vol un producte amb un preu inferior (<), o d’igual forma sies vol un producte amb mes memoria RAM (>), o el producte d’una altremarca (<>).

2.2.2 Cicle del proces de recomanacio:

Tots els sistemes conversacionals [9] [2] segueixen un cicle basic de recomanacio.Aquest cicle es repeteix fins que l’usuari troba el producte final o decideix deixar elsistema perque no troba cap producte que satisfaci les necessitats. Es pot diferenciaren tres passos o fases, dibuixat en la Figura 5.

L’entrada de tot sistema recomanador son les preferencies d’entrada de l’usuari(query). Aquestes dades el sistema les gestiona en el pas de Recuperar, on es recu-pera un producte, en base a que siguin similars i satisfacin aquestes preferencies dela query, de manera que ja es descarten tots els casos que l’usuari no esta interessatsegons la query d’entrada.

La seguent fase mostra una recomanacio a l’usuari i es procedeix a realitzar laretroalimentacio. L’usuari pot aplicar una retroalimentacio sobre aquest producteen cas que no sigui el buscat, i que modificara la query inicial en cada iteracio. Enaquesta fase s’obte i es guarda una retroalimentacio de l’usuari, a mes d’eliminarel producte recomanat de la base de dades per aquest usuari per no tornar-lo arecomanar en un futur.

A l’ultima fase del cicle, es revisa la retroalimentacio proporcionada per l’usuaria partir del producte recomanat i es genera una nova query.

9

Figura 5: Cicle dels sistemes recomanadors conversacionals estandards

2.2.3 Recomanadors basats en crıtiques:

El sistema de recomanacio estandard basat en crıtiques, segueix un algorisme bas-tant basic, el qual simplement es basa en l’ultima crıtica realitzada per l’usuari.

En els sistemes basats en crıtiques, quan l’usuari realitza una retroalimentacioen forma de crıtica ci sobre un producte ri, el sistema respon recomanant un nouproducte, rT , el qual es compatible amb ci, es a dir compleix la crıtica anterior,vegeu l’Equacio (2.3), i es el mes similar possible al producte anterior, ri com esmostra a l’Equacio (2.4)

satisfies(ci, rj)↔ apply(typei, rj.fi, ri.fi) (2.3)

rT = argmax(sim(ri, rj)) (2.4)

En un sistema de recomanacio estandard obtenim resultats, pero generalmentno son bons. Per exemple no te en compte que un usuari es pot equivocar, es adir fallar en una crıtica, el que suposaria recomanar un producte totalment diferenti el que es mes important, que tampoc te en compte les crıtiques realitzades encicles anteriors del proces de recomanacio, nomes l’ultima. Aixo fa que sigui difıcilrecomanar un producte que coincideixi amb totes les especificacions de l’usuari i,per tant, el cicle de recomanacio s’allarga molt i arriba a frustrar o desesperar al’usuari que ha de realitzar moltes crıtiques sobre productes diferents, inclus repetintcrıtiques anteriors per poder obtenir un producte apte.

10

3 Critiquing

Els sistemes de recomanacio conversacionals basats en crıtiques estan dissenyatsper guiar a l’usuari a traves dels productes, oferint diferents productes basats enla retroalimentacio en forma de crıtiques donades per l’usuari. Una de les maneresmes habituals de realitzar aquesta retroalimentacio amb l’usuari es mitjancant lescrıtiques.

Aquests sistemes s’anomenen Conversational Critiquing [9], i son els usuarisqui ajuden al sistema recomanador a traves d’una retroalimentacio en forma decrıtica limitada a unes caracterıstiques concretes del producte actual juntamentamb el valor associat. Per exemple, es pot realitzar una crıtica sobre el producterecomanat, on troba que el preu es massa car i per tant l’usuari fa la crıtica sobrede la caracterıstica del preu i com a valor ’<’ menor que l’actual, per tant el sistemaretornara un producte de caracterıstiques similars a l’anterior, pero amb un preuinferior.

D’entre els sistemes recomanadors basats en crıtiques, es poden trobar diferentsalgorismes per tractar les crıtiques de l’usuari i despres recomanar el proxim pro-ducte. El mes conegut i usat a la literatura es el Incremental Critiquing que esdescriu a continuacio.

3.1 Incremental Critiquing

L’algorisme d’Incremental Critiquing [10] [12] es basa en crıtiques. Es un algorismeincremental, com el seu nom indica, per tant es tenen en compte tant l’ultimacrıtica, com les crıtiques anteriors de l’usuari que s’afegeix a un model de l’usuariper tal de mostrar el millor producte en cada cas. El seu cicle es mostra a la Figura6.

Figura 6: Cicle dels sistemes recomanadors incremental critiquing

Durant cada cicle, en la sessio de recomanacio, es mostra a l’usuari una novarecomanacio, i permet fer-li una retroalimentacio sobre aquest ıtem. Segueix uncicle bastant similar al model estandard de sistemes conversacionals pero el fet quesigui incremental fa que vagin guardant i gestionant les dades de la sessio. Per aixoes crea una nova fase, Model d’Usuari, la qual te la funcio de gestionar el UserModel U , afegint en cada iteracio tant el producte recomanat anteriorment, com la

11

crıtica realitzada sobre aquest, a mes s’han d’eliminar aquelles inconsistencies ambl’ultima crıtica realitzada.

Altres tecniques com value elicitation requereixen que l’usuari conegui amb moltde detall totes les caracterıstiques del producte, mentre que preference-based feed-back tot el contrari, no es necessari tenir un gran coneixement del domini per partde l’usuari, ja que aquest nomes ha de dir quin dels productes mostrats prefereix.

Seguint aquesta ultima tecnica ens trobem amb la d’incremental critiquing, queconsisteix en guardar les diferents crıtiques que l’usuari ha anat donant dins lasessio de recomanacio en un model de l’usuari. Amb aquesta tecnica es te encompte l’historial de crıtiques del propi usuari en la mateixa sessio.

Incremental critiquing (IC) es un sistema senzill d’implementar i es mes facilpels usuaris d’entendre i utilitzar-lo, ja que no requereix d’uns coneixements moltespecıfics del producte o saber exactament el que es vol, sino que el propi sistemarecomanador guia l’usuari de manera facil. A mes aquest es pot millorar amb elHighest Compatibility Selection - Reinforcement Learning (HCS-RL) [12], on no fafalta mantenir tot el model d’usuari, eliminant aixı el sobrecost computacional.

3.1.1 Algorisme d’incremental critiquing

Per poder tenir un historial de les crıtiques de l’usuari s’ha d’anar actualitzant unmodel d’usuari U , veure l’Equacio 3.1 (On cada Ui es una unica crıtica), que contetotes les crıtiques realitzades per l’usuari fins al moment. Aquest model sera utilit-zat en l’algorisme de recomanacio per seleccionar el nou producte. Al final de cadacicle, quan l’usuari fa una nova crıtica sobre l’ultim producte recomanat, aquestacrıtica Ui s’afegeix al final del model U .

U = {U1, ..., Un} (3.1)

- Algorisme a alt nivell:

1. Es mostra un ıtem recomanat,

2. Usuari realitza una crıtica sobre alguna caracterıstica de l’ıtem,

3. S’afegeix al User Model la crıtica, eliminant totes les crıtiques anteriors queson inconsistents,

4. Torna al pas 1 mentre l’usuari no accepti el producte

- Pseudocodi:

A l’Algorisme 1, estan definides les passes que segueix l’incremental critiquingen pseudocodi, per realitzar recomanacions a l’usuari. El sistema obte com a valord’entrada la query inicial q, a mes de tenir la llista de productes per recomanar enla base de casos, CB.

12

Tant el model d’usuari U , on es guarden les crıtiques de manera incrementalen cada iteracio, com la crıtica actual Ucq, s’inicialitzen a 0 en la primera iteracio,ja que encara no s’ha fet cap crıtica. El cicle es repeteix fins que l’usuari acceptiel producte recomanat, i esta format per 4 passos, seguint el model estandard desistemes conversacionals basats en crıtiques incrementals, definit a la Figura 6: Re-commend Item, User Review, Query Revise i Update Model.

Input: q: query, CB: case base, Ucq : User current critique, pr current product recommendation, U : user model1 define IncrementalCritiquing (q, CB)2 begin3 Ucq := null4 U := null5 repeat6 pr ← ItemRecommend(q, CB, Ucq , U)7 Ucq , CB ← UserReview(pr,CB)8 q ← QueryRevise(q, pr)9 U ← UpdateModel(U , Ucq , pr)

10 until UserAccepts(pr)

11 end12 define ItemRecommend (q, CB, Ucq , U)13 begin14 CB′ ← {p ∈ CB|δ(p, Ucq)}15 CB′ ← sort all pi ∈ CB′ in decreasing Quality(pi, q, U)16 pr ← most quality product in CB′ // see eq. (3.3)17 return pr18 end19 define UserReview (pr, CB)20 begin21 Ucq ← user critique for some f ∈ pr22 CB ← CB − pr23 return Ucq , CB

24 end25 define QueryRevise (q, pr)26 begin27 q ← pr28 return q

29 end30 define UpdateModel(U , Ucq , pr)31 begin32 U ← U− contradict (U , Ucq , pr)33 U ← U− refine (U , Ucq , pr)34 U ← U+ (< Ucq , pr >)35 return U

36 end

Algorithm 1: Algorisme d’Incremental Critiquing

13

- Seleccionar recomanacions:

La principal utilitat del model d’usuari es que es pugui utilitzar per determinarla proxima recomanacio. Aixo es fa en tres passos, agafant com a llista principalde candidats tots els possibles productes existents:

1. Eliminar de la llista tots els que no compleixin la crıtica actual

2. Calcular la puntuacio de compatibilitat per cada candidat, vegeu l’Equacio3.2. El Satisfies es 0 o 1, segons si es satisfa la crıtica per aquest cas, o no.

Compatibility(c′, U) =Σ∀iSatisfies(Ui, c

′)

|U |(3.2)

3. Ordenar en una llista de possibles recomanacions, segons la Quality, vegeul’Equacio 3.3, que ve determinada per la compatibilitat trobada en el punt2 i la similitud de cada producte amb el producte anterior, com mes similares el producte i mes compatible amb les crıtiques realitzades mes qualitat(Quality) te, i per tant mes possibilitats de ser el producte escollit.

Quality(c′, c, U) = Compatibility(c′, U) ∗ Similarity(c′, c) (3.3)

Per tant, es pot veure com la principal prioritat es que satisfaci l’ultima crıticade l’usuari, a mes de que sigui similar amb l’actual recomanacio, i que satisfacicrıtiques anteriors que conte en el model d’usuari (U).

Aquest ultim pas d’obtenir la Quality de cada candidat i ordenar la llista, es potmillorar afegint una constant β, per tal de aixı donar mes importancia (sempre quesigui > 0.5) als ıtems que siguin mes compatibles amb el model d’usuari (compleixinmes crıtiques del User Model), que no als que son mes similars nomes a l’ultimarecomanacio. La Quality esta representada a l’Equacio 3.4, on β es la variable ques’ha de definir, i que determina la importancia que es dona en cada component perpoder ser recomanat.

IQuality(c′, c, U) = β ∗ Compatibility(c′, U) ∗ (1− β) ∗ Similarity(c′, c) (3.4)

- Model d’Usuari:

El model de l’usuari U o User Model, com es pot veure en la Figura 6, es l’ultimpas abans de comencar a fer una nova recomanacio. Esta definit en el pseudocodi(Algorisme 1, lınies 30-35) com a UpdateModel(U,Ucq, pr). Aquest obte l’ultimproducte recomanat pr i la crıtica realitzada per l’usuari sobre aquest producte Ucq,per afegir-los en el U .

En el model d’usuari, hi pot haver algunes crıtiques anteriors que siguin incom-patibles o es contradiguin amb la nova. Per mantenir i actualitzar el model d’usuari

14

es necessari tenir en compte aquest problema, i abans d’afegir la nova crıtica po-dar les anteriors comprovant si existeix alguna en el model que sigui incompatible,eliminant aquests tipus d’inconsistencies (lınies 32-33).

A mes, la crıtica en cada cicle, podria ser unica o composta (formada per variescrıtiques alhora), en cas de ser composta, es separarien cada una, i es guardariencom a crıtiques individuals en el model d’usuari.

3.1.2 Reinforcement Learning (RL)

Com s’ha vist anteriorment, en l’algorisme d’Incremental Critiquing es construeixun model d’usuari amb les anteriors crıtiques per millorar les futures recomanacions.Per tal de millorar aquesta estrategia, es pot utilitzar una nova tecnica per mesurarla compatibilitat basada en Reinforcement Learning (RL).

Aquesta tecnica intenta solucionar els dos principals problemes de l’algorismebasic d’incremental critiquing (IC): (1) el fet de que per mesurar la compatibilitat,totes les crıtiques guardades al model d’usuari son equitatives, es a dir una crıticarealitzada al principi de la sessio val el mateix que l’ultima, per calcular la compa-tibilitat dels casos, i (2) els valors de compatibilitat depenen massa de la mida delmodel d’usuari, si tenim un sessio llarga el model creix, i el valor de compatibilitattambe incrementa al haver de comprovar mes crıtiques.

Reinforcement Learning Problem intenta solucionar aquests problemes, guardantun conjunts d’estats on es guarden les sumes de les futures recomanacions. Cada cases tractat com un estat on el seu valor de compatibilitat es actualitzat en cada ciclesegons un valor d’α que pot variar si es vol que es doni mes o menys importancia al’ultima crıtica.

1. Si en el producte c′ es compleix l’ultima crıtica, incrementa el valor de com-patibilitat, vegeu l’Equacio 3.5

2. Si en el cas c′ no es compleix l’ultima crıtica, es penalitza aquest valor restant,tal i com es mostra a l’Equacio 3.6

Compatibility(c′, Uf ) = comp(c′) + α ∗ (1− comp(c′)) (3.5)

Compatibility(c′, Uf ) = comp(c′) + α ∗ (0− comp(c′)) (3.6)

Al principi de la sessio, s’ha d’inicialitzar a un valor arbitrari entre l’interval [0..1],la compatibilitat de tots els casos. Normalment el valor inicial es 0.5.

15

3.1.3 Highest compatibility (HCS)

Una altra forma de millorar l’Incremental Critiquing es a l’hora d’ordenar la llistade casos per recomanar [10]. Com hem vist es pot modificar el valor de β, on elscasos amb mes similitud amb la recomanacio actual tenen mes o menys prioritatsobre els casos que tinguin mes compatibilitat amb les crıtiques realitzades. Elcalcul de la Quality amb aquests 2 components fa que es necessiti un gran tempsde processat havent de comprovar per cada producte tant la compatibilitat com lasimilitud.

L’algorisme de Highest compatibility Selection (HCS) [12] millora aquest petitproblema, a la vegada que dona mes prioritat a les millors compatibilitats enfronta la similitud, seguint els seguent passos:

1. Ordenar la llista pels casos mes compatibles amb les crıtiques de la sessio

2. Seleccionar els que tenguin mes compatibilitat

3. Ordenar la nova llista per similitud amb la recomanacio actual

D’aquesta manera no s’ha de comprovar la similitud amb tots els casos, produintuna gran perdua de temps i de calcul, nomes es calculen aquells casos mes possiblesper ser el proxim producte recomanat, o sigui amb els que hi hagi mes compatibilitat.

3.2 Experience-based critiquing (EBC)

En aquest apartat, el Experience-based critiquing [8] s’intenta millorar l’eficienciadels sistemes recomanadors sense afegir complexitat als algorismes. S’aprofiten del’historial de crıtiques per triar una millor opcio de recomanacio.

Igual que IC, en amb sistema basat amb rating i preference feedback, no requereixd’un detallat coneixement previ per part de l’usuari, sobre el producte, simplementens dona una qualificacio general, i per tant nomes ha de distingir si es una bonarecomanacio o dolenta.

Un aspecte important d’aquests sistemes de recomanacio, ve determinat per lesCompound critiques [1] [7] [15] [5], que es una col·leccio de crıtiques unitaries, quepermet a l’usuari realitzar varies crıtiques al mateix temps, i per tant reduir lesiteracions o cicles per arribar a l’objectiu. Les crıtiques compostes son generadesde forma dinamica durant cada cicle de recomanacio.

La principal caracterıstica de l’algorisme EBC, enfront al vist anteriorment (IC),es que utilitza una nova font d’informacio en el proces de recomanacio, que estabasat en l’experiencia de sessions anteriors d’altres usuaris.

16

3.2.1 Algorisme

- Sessions de recomanacio:

L’usuari pot comencar amb un nivell global sobre el que necessita (com podriaser el preu maxim), que posteriorment s’anira concretant mes segons la necessitatde cada usuari.

Durant una sessio, l’usuari donara una serie de crıtiques sobre diferents carac-terıstiques d’igual forma que ho fa IC, fins que la sessio acabi quan aquest acceptiuna recomanacio, o deixi de buscar perque no troba el que necessita (en aquestalgorisme nomes es tindra en compte que al final de cada sessio l’usuari ha acceptatla recomanacio).

(1) Cada sessio de recomanacio Si esta formada per una sequencia de parelles pide recomanacio ri, crıtiques ci, vegeu les Equacions 3.7, 3.8 i 3.9.

(2) Cada crıtica ci, esta representada per la caracterıstica del producte fi, el valorde la crıtica vi i el tipus vi de crıtica. Per exemple, la crıtica a un producte recomanatamb un preu de 450, per tal de que sigui mes barat seria: c1 = (′preu′,′ 450′,′<′)

pi = (ri, ci) (3.7)

Si = {(r1, c1), ..., pn} (3.8)

ci = (fi, vi, type) (3.9)

- Experiencia d’altres usuaris:

Per poder trobar el millor ıtem per recomanar, una bona manera de fer-ho estenint en compte anteriors sessions d’usuaris, de manera que si trobem un usuario sessio bastant similar a l’actual es possible que el producte que finalment s’haacceptat en aquesta sessio tambe pugui ser el producte que busca l’usuari actual.EBC te en compte aixo, i per arribar a la sessio mes similar, i per tant al millorproducte a recomanar, segueix els seguents tres passos:

1. Construir els Experiencial-Cases.

Es similar al Model d’usuari vist anteriorment en l’algorisme IC pero amb lapeculiaritat que esta format per les parelles de crıtiques i recomanacions, nonomes amb les crıtiques, i que es construeix a partir de les sessions passadesd’altres usuaris. El problema es que els usuaris poden haver canviat d’opi-nio o equivocar-se en alguna crıtica, per tant s’ha de canviar aquest model,d’igual forma que ho fa IC, eliminar aquelles crıtiques d’aquest model que escontradiuen amb les mes recents. I a l’acabar aquest proces ens quedem ambel producte final que s’ha recomanat en cada una de les sessions anteriors,com a possible candidat.

2. Identificar sessions rellevants.

Quan la sessio actual aplica alguna crıtica ci sobre el producte recomanatrm, cadascuna d’aquestes crıtiques es guarda com una llista de crıtiques a la

17

query qT i s’utilitza per poder identificar les sessions mes rellevants. Les mesrellevants son aquelles que tenen mes coincidencies de crıtiques, es fa mirantentre les diferents sessions la que te mes capes superposades amb l’actualsessio, o overlapScore, vegeu l’Equacio 3.10.

OverlapScore(qT , si) = [∑ci∈qT

∑cj∈si

match(ci, cj)]2 (3.10)

A l’Equacio 3.11 OverlapScore retorna el numero de crıtiques que coincidei-xen entre la sessio passada si, i la query actual. qT . t es una constant perdeterminar a partir de quantes coincidencies es te en compte les sessions.

RelevantSessions(qT , S) = {si ∈ S : OverlapScore(qT , si)>t} (3.11)

3. Ordenar els candidats.

Un cop es te la llista de sessions rellevants, s’han d’ordenar de tal manera quees selecciona la que mes puntuacio obte. El proxim producte recomanat rTsera el producte que ha acceptat l’usuari en la sessio amb major OverlapScore,mireu l’Equacio 3.12.

rT = Recommend(SREL) = argmax(si ∈ SREL : OverlapScore(qT , si))(3.12)

Es a dir, que quan l’usuari fa una crıtica sobre un ıtem, la proxima recomanaciotindra en compte, a part de que compleixi aquesta crıtica i sigui similar a l’ıtemanterior, un ıtem que ha estat acceptat en anteriors sessions que es considerinrellevant o prou similars a l’actual.

En cas de no trobar cap sessio prou rellevant, be sigui perque tenim un thresholdelevat, o perque no hi ha coincidencies entre sessions, no tindrıem cap candidat perrecomanar, llavors s’ha de tornar al metode estandard de recomanacio on el nouproducte es el mes similar possible al actual i compatible amb la crıtica de l’usuari.

Els sistemes EBC representen una gran millora respecte al sistema de recoma-nacio d’estandard critiquing, pel simple fet de que busca sessions rellevants i en elpitjor dels casos, no trobant cap sessio prou rellevant, s’utilitza el mateix sistemade ordenacio que l’estandard Pero els resultats no son prou bons, ja que no milloraa l’algorisme anterior, el de IC.

3.3 History-Aware Critiquing

En aquest algorisme de History-Aware Critiquing (HAC) [14], a diferencia de l’IC onnomes es guardava un historial de crıtiques passades dins la mateixa sessio, continuapel mateix camı de l’algorisme EBC, on es tenen en compte sessions rellevants delpassat d’altres usuaris, per obtenir una millor recomanacio.

18

HAC vol millorar a EBC, ja que aquest en molts de casos fa recomanacionserronies nomes tenint en compte altres sessions, i no millora al IC com es podra veurea l’apartat d’avaluacio Tot i que l’EBC te un resultat una mica dolent en comparacioa IC, la idea que segueix es bona i es important comptar amb l’historic de sessions.Per tant, HAC millora els problemes d’EBC realitzant les recomanacions utilitzantles sessions anteriors, pero comprovant tambe les recomanacions de les sessions, nonomes les crıtiques.

3.3.1 Algorisme

Es segueixen guardant les sessions de la mateixa manera, cada sessio s es represen-tada per una col·leccio de parelles pi de crıtiques i recomanacions:

s = (p1..pn); pi = (ri, ci); ci = (fi, vi, typei) (3.13)

D’igual forma la manera de realitzar els passos per aconseguir la recomanacioidonia es similar a l’EBC, primer es busca les sessions rellevants i a partir d’aquı s’a-consegueix el producte. Canviant alguns aspectes en la cerca de sessions rellevants,es pot aconseguir una gran millora en el resultat final. Es segueixen els seguentspassos:

1. Similitud:

Per calcular la similitud entre la sessio actual i les sessions del passat, escalcula la mitja de similitud de cada una de les recomanacions en l’actualsessio o query qT amb una altra sessio historica si:

averageSimilarity(qT , s) =Σri∈qT Σrj∈sSim(ri, rj)

|U | ∗ |s|(3.14)

2. Qualitat de cada sessio:

Un cop tenim la mitja de la similitud de cada sessio respecte a l’actual, s’hade calcular la qualitat de la sessio.

Per calcular la qualitat de cada sessio, o la puntuacio que obte per poderser rellevant o no, es combina la mitja anterior i la superposicio de crıtiquesutilitzada en l’EBC.

Aquı tambe es defineix la constant α, que es pot variar segons el cas per trobarun millor equilibri entre la mitja de recomanacions i la de crıtiques similars, amajor α mes importancia es dona a les recomanacions iguals, i a menor, mesimportancia a les crıtiques iguals. Un bon valor per α podria ser mes o menys0.75 (si hem vist per exemple que aplicant amb EBC els resultats son moltdolents), ja que aixı es dona mes importancia a les millores afegides a l’HACenfront al que ja tenia a EBC, tot i que pot canviar molt depenent de les dadesi els productes, pero pot ser un bon punt de partida. En l’Equacio 3.15 es

19

pot veure reflectit com s’obte el Quality a partir de la mitja de recomanacions(avgSimilarity) i de la superposicio de crıtiques (OverlapScore).

Quality(qT , s) = α ∗ avgSimilarity(qT , s) + (1− α) ∗OverlapScore(qT , s)(3.15)

3. Ordenacio

Un cop tenim una puntuacio per cada sessio, d’igual forma que EBC, s’obteuna llista de sessions rellevants, eliminant totes aquelles que no arribin almınim marcat pel threshold t, mireu l’Equacio 3.16. Finalment, i tambe comhem anat fent als algorismes anteriors, s’ordenen les sessions rellevants en3.17, i es recomana el producte final rT que s’ha acceptat en la primera sessiode la llista ordenada.

SREL = RelevantSessions(qT , S) = {si ∈ S : Quality(qT , si)>t} (3.16)

rT = Recommend(SREL) = argmax(si ∈ SREL : OverlapScore(qT , si))(3.17)

Amb aquest metode hem vist que es poden definir tant α per tenir mes o menysen compte les coincidencies de sessions segons recomanacions o crıtiques, i el t,per podar totes aquelles que no tenguin una qualitat de similaritat suficient. Ambsimulacions vistes al ”History-Aware Critiquing-Based”[14] s’ha determinat que lesmillors opcions, en els seus productes i bases de dades, son similars a t = 0.8, α =0.75

L’HAC es una continuacio o millora del EBC, ja que aquest no millorava al ICtot i tenir en compte tot un historial de sessions anteriors. L’HAC utilitza tantla similitud de les crıtiques per trobar sessions similars, com els ıtems recomanats,a diferencia de EBC que nomes utilitza el primer. I els resultats, que tambe espodran comprovar a l’apartat d’avaluacio son que no nomes milloren molt el tempsi iteracions d’EBC, sino que inclus milloren bastant a l’IC.

3.4 History-Guided Conversational Recommendation

Els sistemes HGR, o History-Guided Conversational Recommendation [13], seguintla mateixa lınia que els sistemes anteriors fa servir la retroalimentacio dels usuaris atraves de crıtiques, pero amb la diferencia de que tambe es capac tant de recomanarproductes utilitzant les parelles ıtem/crıtica, com nomes utilitzar les crıtiques en lasessio actual.

Segueix millorant els algorismes vistos anteriorment, en concret EBC i HAC, quetambe utilitzen les sessions de l’historial, per buscar sessions rellevants que ajudina l’hora de recomanar el producte. HGR representa una petita millora en algunscasos enfront d’HAC, i en altres casos resultats bastant similars a aquest, per tantmillora bastant comparat amb IC i EBC.

20

3.4.1 Algorisme

El punt de partida, com en EBC i HAC, es amb un historial de crıtiques de sessionsd’usuaris anteriors. Per tal de poder construir aquest historial, es necessari guardarper cada sessio, si, la sequencia de les diferents parelles (ıtem, crıtica), pi = (ri, ci),en cada una de les recomanacions de ıtem/producte. D’igual forma que es fa en elsaltres sistemes explicats anteriorment.

Els passos que segueix aquest algorisme son: (1) identificar les sessions rellevantsdel passat, es a dir les que siguin mes similars a la actual; (2) ordenar els productespossibles a recomanar de les sessions rellevants; (3) filtrar els anteriors productesper eliminar els que no compleixin les crıtiques de l’usuari actual.

1. Identificar sessions rellevants:

Una sessio rellevant es aquella que te mes coincidencies entre les parelles(crıtica, ıtem) de la sessio actual i de l’historial, vegeu l’Equacio 3.18. Lescoincidencies de les parelles, o OverlapScore, ve definida en l’Equacio 3.19, ontenim que per cada parella en la sessio actual qT es comprova si coincideixamb alguna parella de cada una de les sessions si ∈ S. Al final obtenim percada sessio si un score que correspon a les parelles que coincideixen.

Es pot donar el cas que no trobem coincidencies per parelles, en aquest cases fa servir nomes les crıtiques enlloc de les parelles, Equacio 3.20. Si tot iaixı no tenim coincidencies, el score es 0 en totes les sessions, hem d’utilitzarl’ultima solucio que es recomanar el producte mes similar i que compleixi ambla crıtica, tal i com ho fa IC.

SREL = RelevantSessions(qT , S) = {si ∈ S : OverlapScore(qT , si > t)}(3.18)

OverlapScore(qT , si) =∑

(ri,ci)∈qT

∑(rj ,cj)∈si

match((ri, ci), (rj, cj)) (3.19)

OverlapScore(qT , si) =∑ci∈qT

∑cj∈si

match((ci, cj)) (3.20)

2. Ordenar candidats:

Les sessions de l’historial acaben amb producte acceptat rF , per tant tenimque tots els rF de les sessions rellevants SREL passen a ser candidats per a lasessio actual. Aquests candidats s’ordenen segons el score obtingut anterior-ment en la sessio.

RecScore(rF , qT , SREL) =

∑∀si∈SREL:rF =terminal(si)

OverlapScore(qT , si) (3.21)

21

3. Filtrar compatibles:

Aquests candidats ordenats no tenen perque ser productes compatibles per al’usuari actual, per tant, l’unic que queda es eliminar els incompatibles. Per feraixo, s’eliminen aquells productes que no satisfacin les crıtiques mes recentsi ens quedem amb el primer d’aquesta llista que sera el proxim producterecomanat.

3.5 History Opinion Recommendations

El History Opinion Recommendations o HOR [4], es nou sistema de recomanacioen crıtiques, basat sobre l’algorisme de HGR. La peculiaritat o les noves ideesque aporta aquest algorisme, es que a mes de les crıtiques de l’experiencia d’altresusuaris com es venia fent amb els algorismes anteriors, tambe s’utilitzen les opinionsdels usuaris a l’entorn del e-commerce. Aquest sistema combina tant l’entrada deretroalimentacio en base a les crıtiques, part que funciona igual que el HGR, a meste en compte les valoracions dels productes com podria ser amb la retroalimentaciode rating-based que els usuaris han fet a webs d’opinio.

3.5.1 Algorisme

En l’Algorisme 2 es detalla el proces de recomanacio utilitzant HOR. El sistemaobte com a valors d’entrada la query inicial pq i tenint en compte els valors extretsde l’experiencia dels usuaris anteriors, la llista de sessions si definida com SB i lallista de opinions oi definida com OB, recomana un producte de la base de dadesCB. Tant el model d’usuari U , on es guarden les parelles de crıtiques i ıtems de lasessio actual, com la crıtica actual s’inicialitzen a 0, ja que encara no s’ha fet capcrıtica. El cicle que es repeteix en aquest algorisme, i fins que l’usuari accepti el pro-ducte recomanat, esta format per 4 passos, seguint el model estandard de sistemesconversacionals basats en crıtiques incrementals, definit a la Figura 6: RecommendItem, User Review, Query Revise i Update Model.

Input: pq : product query, CB: case base, SB: session base, OB: opinion base1 define HistoryOpinionRecommender (pq , CB, SB, OB)2 begin3 Ucq ← null // current critique4 U ← null // user model5 repeat6 // pr: product recommendation7 pr ← RecommendItem(pq , CB, U , SB, OB)8 Ucq , CB ← UserReview(pr, CB)9 pq ← QueryRevise(pr)

10 U ← UpdateModel(U , Ucq , pr)

11 until UserAccepts(pr)

12 end

Algorithm 2: History Opinion Recommender (HOR) Algorithm

1. Recommend Item:

La primera fase la de recomanacio del producte, definida en l’algorisme 3, es

22

seleccionen les sessions rellevants per ser utilitzades i ajudar a recomanar unproducte.

Per obtenir les sessions rellevants (lınies 16-23), el procediment es similar al’HGR, s’obtenen les capes superposades entre la sessio actual definida al mo-del d’usuari U , i les sessions anteriors si ∈ SB. Per les capes superposades escomprova primer si hi ha sessions amb parelles crıtica-ıtem OverlapPair(U, si)suficients com per ser declarades com a rellevants, aquest es calcula amb l’E-quacio 3.19 del apartat de HGR, en cas contrari es tindran en compte aquellessessions on nomes coincideixin amb crıtiques, OverlapCritique(U, si), utilit-zant l’Equacio 3.20 tambe de l’apartat de HGR.

1 define RecommendItem(pq , CB, U , SB, OB)2 begin3 SREL ← RelevantSessions(U , SB)

4 if SREL <> null then5 rF ← sort si ∈SREL in decreasing RecScore(U, si, oj) and store pj = term(si) // see Eq. 3.226 rF ← FilteringCandidates(rF , U)7 pr ← getTopRanked(rF )

8 else9 Ucq ← getLastCritique(U)

10 CB′ ← {p ∈ CB|δ(p, Ucq)}11 CB′ ← sort all pi ∈ CB′ in decreasing Q(pi, pq , U) = β · Cpi (U) + (1− β) · S(pi, pq)12 pr ← most quality product in CB′

13 end14 return pr15 end16 define RelevantSessions (U , SB)17 begin18 SREL ← null

19 SREL ← {si ∈ SB : OverlapPair(U , si)>0}20 if SREL == null then21 SREL ← {si ∈ SB : OverlapCritique(U , si)>0}22 end

23 return SREL

24 end

Algorithm 3: Fase de recomanacio amb HOR

Amb la llista de sessions rellevants SREL, obtenim l’ultim producte recomanaten cada una de les sessions rellevants, aquests productes pj = term(si), sonels que els usuaris similars han acceptat com a producte final, i que per tantl’usuari actual podria trobar com a bon producte recomanat. Ordenem la llistasegons la puntuacio obtinguda en cada sessio en base a les capes superposades,definida en l’Equacio 3.22.

La puntuacio, RecScore(U, si, oj) combina tant el numero de les parelles decrıtica-ıtem (o nomes crıtiques) iguals entre la sessio si i l’usuari actual U , comla valoracio que ha fet l’usuari de la sessio si sobre el producte final pj. Aquestscore pot esta condicionat per la constant α per tal de donar mes importanciaa l’OverlapScore. I per tant, comptar mes en sumar la puntuacio final de lasessio, en cas que sigui major que 0.5, o mes importancia a la valoracio final ojde l’usuari si es menor que 0.5. Com mes proxim el α a 1, mes es semblaran lesrecomanacions resultants, a les que ofereix l’algorisme de HGR, ja que aquestno utilitza les valoracions finals OB.

23

RecScore(U, si, oj) = α ·OverlapScore(U, si) + (1− α) · oj (3.22)

Aquests productes de les sessions rellevants rF , ordenats segons la puntua-cio anterior, es passen per filtrar-los (lınia 6 a l’Algorisme 3), eliminant totsaquells productes que no son compatibles o no satisfan els requisits o pre-ferencies de l’usuari actual, definits en el model d’usuari U . Amb la llista jafiltrada i ordenada, s’obte en primer producte per recomanar pr.

En cas que no es tengui cap sessio considerada lo suficient rellevant o simi-lar amb aquest usuari (lınia 8), es deixara l’experiencia d’altres usuaris, i esrealitzara la recomanacio basant amb l’algorisme incremental de critiquing(IC).

El primer que es fa es obtenir l’ultima crıtica Ucq realitzada per l’usuarigetLastCritique(U). Despres es filtren els productes de la base de dadesCB que no compleixen aquesta crıtica (en cas que no hi hagi cap crıtica enca-ra, es considerara tota la base de dades). Amb la base de dades ja amb menysproductes s’ordenen els productes pi en funcio de la Quality, com es fa en eltradicional IC.

El Quality es calcula de manera similar a l’IC vist en l’Equacio 3.4, en quant ala forma de mesurar la relacio entre compatibilitat i similaritat per obtenir lapuntuacio final, pero difereix en el metode d’obtenir la compatibilitat i segueixel procediment explicat en l’apartat d’IC, el de Reinforcement Learning percalcular la compatibilitat. S’utilitzen a mes l’Exponential Hit-Loss technique(EHL) per avaluar la compatibilitat Cpi(U), que segueix l’Equacio 3.23, i elLocal User Preference Weighting (LW) per calcular la similaritat S(pi, pq), enl’Equacions 3.24 i 3.25. Definides amb mes detall a [11].

Per acabar, el producte recomanat pr, es aquell que obte mes puntuacio oquality de la base de dades filtrada.

Cpit =

{Cpit−1 · (1 + α)(ht+t)k, if Rpi

t = 1Cpit−1 · (1− α)(`t+t)k, if Rpi

t = 0(3.23)

S(pi, q) =

|F |∑s=1

ω(pfsi ) · d(pfsi , qfs) (3.24)

ω(pfsi ) = 1− 1

2

(∑|Ufs |j=1 δ(pi, U

fsj )

|U fs|

)(3.25)

2. UserReview:

En la segona fase, que correspondria a la de Reutilitzar de la Figura 6, i de-finida en l’Algorisme 4, el sistema simplement obte la crıtica de l’usuari Ucqsobre alguna caracterıstica f del producte recomanat anteriorment pr. Peraltre banda elimina de la base de casos CB el producte ja recomanat, perque

24

en un futur no recomani de manera recursiva el mateix producte.

1 define UserReview (pr, CB)2 begin3 Ucq ← user critique for some f ∈ pr4 CB ← CB − pr5 return Ucq , CB

6 end

Algorithm 4: Fase de feedback o retroalimentacio de l’usuari

3. QueryRevise:

Aquesta fase, de QueryRevise (de Revisar en la Figura 6), es basa en revisarla query pr, com el nom indica, pel seguent cicle, per aixo es posa el producterecomanat com a nova query pq.

1 define QueryRevise (pr)2 begin3 pq ← pr4 return pq5 end

Algorithm 5: Fase de revisio de la query

4. UpdateModel:

Per ultim tenim el UpdateModel, aquesta fase es la que actualitza el modeld’usuari U . Per actualitzar i afegir la nova crıtica Ucq amb el producte re-comanat, primer es necessari eliminar del model totes aquelles crıtiques quecontradiuen amb l’actual (lınia 3), i tambe eliminar aquelles crıtiques quel’actual la perfecciona o refina (lınia 4).

1 define UpdateModel (U , Ucq , pr)2 begin3 U ← U− contradict (U , Ucq , pr)4 U ← U− refine (U , Ucq , pr)5 U ← U+ (< Ucq , pr >)6 return U

7 end

Algorithm 6: Fase d’actualitzacio del model d’Usuari U

3.6 Graph-based

El sistemes basats crıtiques compostes, o Collaborative Compound Critiques [15][1], son tambe de Experience-based, es a dir que estan basat en les sessions d’altresusuaris, a mes per cada producte recomanat l’usuari pot realitzar varies crıtiques.Per poder identificar les sessions similars s’utilitza l’ajuda dels grafs.

Aquest algorisme graph-based es similar als anteriors a l’hora de recomanar unproducte tenint en compte alguna sessio similar pero varia en escollir quines de lessessions son similars, o rellevants. En EBC les sessions rellevants, com hem vistanteriorment, son aquelles on els usuaris de sessions historiques i l’actual tenen mescrıtiques en comu, i en l’HAC, la similitud dels ıtems recomanats.

En aquest cas es vol solucionar el problema o les limitacions que tenen els al-gorismes anteriors, que nomes es tenen en compte les crıtiques unitaries i no les

25

compostes, i que tampoc es tenen en compte la sequencia que ha seguit l’usuari, esa dir, nomes es compara les crıtiques o ıtems que coincideixen en qualsevol punt dela sessio i no una crıtica sobre un ıtem concret o altre. Aquest nou sistema soluci-ona aquests dos aspectes utilitzant els grafs per tenir en compte tant les crıtiques iıtems, com la relacio que tenen cada un d’ells, i els punts en el que s’han fet.

3.6.1 Algorisme

En aquest algorisme son necessaries les relacions entre ıtems i crıtiques en cadasessio, per despres poder trobar les sessions mes rellevants, aixı que es construeixenuns grafs per controlar aquest aspecte.

D’igual forma que amb els sistemes basats en crıtiques unitaries, el producterecomanat en cada iteracio sera aquell que obtengui una millor puntuacio o scoreal final del algorisme. I s’acabara el proces quan l’usuari accepti un producte o bedeixi el sistema.

-Sessions:

Les sessions venen definides com una sequencia de crıtiques i ıtems. En cadacicle la sessio guarda l’ıtem ix juntament amb la crıtica composta sobre aquest ıtem{c1, ..., cm}, on m representa el numero de crıtiques unitaries que esta formada lacrıtica composta. En l’ultim ıtem, que es el producte final que l’usuari agafa com abo, les crıtiques es guarden com a 0, de manera que se sap que la sessio ha finalitzat.

sk =< i1, {c1,1, ..., c1,m}; i2, {c2,1, ..., c2,m}; ...; in, 0 > (3.26)

-Construccio del graf:

Donada la definicio de sessio en 3.26, que es la manera en que es guarda cadasessio amb crıtiques compostes, podem construir el graf, com es veu en la Figura7. Tenim que cada un dels ıtems enllaca amb una o varies crıtiques, que son lesque l’usuari ha fet sobre aquest producte. D’igual manera existeix l’enllac de cadacrıtica amb el proxim producte recomanat, que el sistema ha recomanat tenint encompte amb aquestes crıtiques, entre altres factors.

Cada graf tambe es pot representar com un conjunt de vertexs que corresponenals conjunts de crıtiques i ıtems, i un conjunt de enllacos, que son les relacionsıtem→crıtica o viceversa.

-Sessions similars:

Per poder trobar aquelles sessions que siguin mes similars amb l’usuari actual,cal definir una equacio que tengui en compte tambe els enllacos vistos en el graf.

A l’Equacio 3.27 es pot veure com s’obte la puntuacio de cada graf, o el que esel mateix la puntuacio que obte cada sessio, respecte a la similitud que te amb lasessio actual. Per a poder aplicar aquesta formula, tambe es necessari tenir un grafparcial de la sessio actual, per tant a cada iteracio s’ha de generar un graf nou, oafegir-hi el nou producte i les noves crıtiques al graf.

26

Figura 7: Graf de sessio

RSim(Gx, Gy) =|Ix ∩ Iy||Ix ∪ Iy|

· |Cx ∩ Cy||Cx ∪ Cy|

·∣∣Ei→c

x ∩ Ei→cy

∣∣∣∣Ei→cx ∪ Ei→c

y

∣∣ ·∣∣Ei←c

x ∩ Ei←cy

∣∣∣∣Ei←cx ∪ Ei←c

y

∣∣ (3.27)

Els conjunts d’ıtems estan definits com a Ix i Iy, Cx representen totes les crıtiquesde la sessio. Mentre que Ei→c

x i Ei←cx representen els enllacos entre ıtem i crıtica.

Per que fa a la interseccio: |Ix ∩ Iy| obte el numero d’ıtems (crıtiques o enllacos)que coincideixen entre les dues sessions. I la unio entre aquests: |Ix ∪ Iy| obte elnumero total d’ıtems que hi ha entre les dues sessions, eliminant aquelles que formenpart de la interseccio.

Per tant tenim que l’Equacio comprova quants ıtems, crıtiques i arestes coinci-deixen, segons el numero total d’aquests, entre la sessio actual Gx i la sessio quevolem obtenir el score, Gy. Nomes que una de les quatre iteracions obtinguem0 coincidencies, per exemple no existeixi la mateixa aresta item→crıtica entre lesdues sessions, la funcio ja retorna 0. Per tant, d’aquesta manera ja es descartenmoltes sessions. Pero per evitar tenir resultats a 0, es passa aquest a eRSimGx,Gy , id’aquesta manera el mınim score sera de 1 en lloc de 0.

-Ordenar Resultats:

Un cop amb els resultats en cada sessio, i amb les sessions mes rellevants, eli-minant aquelles que no tenen el score mınim, podem procedir a ordenar-los. Si esdona el cas que cap sessio arriba al mınim, i que no tinguem sessions rellevants, espassa a ordenar i a recomanar el producte amb el metode tradicional d’IC, si peraltre banda obtenim unes sessions rellevants es passa a ordenar segons el score. Iper ultim obtenim aquell producte que ha sortit com a ıtem final de la sessio ambmes puntuacio, sempre i quan sigui compatible amb la query de l’usuari.

27

4 Analisi de l’entorn, disseny i implementacio

En aquest capıtol s’explica la plataforma que s’utilitza per implementar els algoris-mes i el simulador d’usuaris amb el seu funcionament. Es detallen els paquets ques’utilitzen i les relacions entre ells. Tambe es mostra i s’explica el funcionament d’a-quest entorn, com es criden i configuren els diferents algorismes, i com es seleccionenles bases de dades, queries, etc. Per detallar i explicar els algorismes es mostren elsdiferents diagrames de sequencies per ajudar a entendre el seu funcionament, i coms’han implementat.

4.1 Analisi de l’entorn

4.1.1 Paquets

L’entorn el qual s’estudia i sobre el qual s’implementen els algorismes de recoma-nacio basats en critiques es divideix en dos programes basats amb el llenguatgeJAVA. El primer d’ells es el CritiqueRecommender, que es el programa principal,on es realitza tota la simulacio d’usuaris i les recomanacions, aquest obte com asortida un fitxer log amb les dades de les sessions provades. L’altre programa esel Reporter, aquest es limita a analitzar els resultats del programa principal, comentrada es passa el fitxer log resultant i com a sortides els dos fitxers de report, enels quals s’exposa l’analisi dels resultats, com la longitud mitjana de les sessions(session length) per cada algorisme (cada log) o la session length per cada query.

-CritiqueRecommender :

Aquest programa esta dividit en varis paquets, que serveixen per separar lesclasses que tenen un objectiu comu o que estan relacionades. Els principals paquetsson: test per iniciar el programa, rec on es defineixen tots els objectes i es realitzenles recomanacions. A dins del rec trobem rec.sim per les classes per la simulacio,rec.impl pels algorismes estandards, rec.incremental per tots els algorismes incre-mentals.

-Paquet de test :

1. TestMain.class: Classe principal amb la funcio de main() on s’inicia el pro-grama.

-Paquet de rec:

A continuacio es pot veure la distribucio de les diferents classes, i l’organitzaciodels paquets. No es mostren totes les classes, nomes aquelles que son necessariesper entendre el funcionament de l’entorn i per ajudar a explicar els seguents punts.El rec es pot dividir en cinc paquets principals: cbf que es el pare de tots elsalgorismes, a partir d’aquest paquet es creen tots els algorismes; impl es l’algorismeestandard de recomanacio; incremental es l’algorisme estandard de recomanacioincremental (IC), a partir d’aquest es creen els demes algorismes incrementals. Laclasse principal es el Recommender ; compound es l’algorisme basat en critiques

28

compostes, a partir d’aquest es creen els algorismes basats en crıtiques compostescom el Graph-based ; i finalment sim implementa el simulador d’usuaris.

1. rec.cbf

CBFQueryRec.class

CBFRec.class

CBFRecBuilder.class

CritiqueQuery.class

2. rec.impl

Recommender.class

StdCaseRec.class

StdQueryEngine.class

AbstractRecBuilder.class

StdRecStrategy.class

3. rec.incremental

IncrementalCaseRec.class

IncrementalModel.class

IncrementalModelSimilarityComputer.class

IncrementalStrategy.class

rec.incremental.HAC

HACCaseRec.class

HACModel.class

HACModelSimilarityComputer.class

HACStrategy.class

rec.incremental.HGR

HGRCaseRec.class

HGRModel.class

HGRModelSimilarityComputer.class

HGRStrategy.class

rec.incremental.HOR

HORCaseRec.class

HORModel.class

HORModelSimilarityComputer.class

HORStrategy.class

rec.incremental.EBC

29

EBCCaseRec.class

EBCModel.class

EBCModelSimilarityComputer.class

EBCStrategy.class

4. rec.compound

CompoundCritique.class

CompoundQuery.class

LowSupportFilter.class

rec.compound.graph

Edge.class

Graph.class

CompoundCaseRec.class

CompoundModel.class

CompoundModelSimilarityComputer.class

CompoundStrategy.class

5. rec.sim

Setup.class

Simulation.class

SimulationFactory.class

rec.sim.user

StdQuerySelector.class

StdRecSelector.class

StdSimUser.class

4.1.2 Simulador

El simulador es la part del programa que simula als usuaris, per tal de poder realitzarles proves necessaries mentre es fa la implementacio dels algorismes i no haver d’usarconstantment usuaris reals provant cada sistema. Aixo ens permet realitzar unnumero molt gran d’iteracions en cada prova i per tant tenir una aproximacio mesreal del que es trobara el programa amb usuaris reals a llarg termini.

A la Figura 8 es mostra el diagrama corresponent al funcionament general, in-dependentment de l’algorisme que se li apliqui mes tard.

El sistema comenca amb la classe TestMain, aquest es el que obte totes les dadesinicials de configuracio del sistema, anomenades Beans i que es troben definidesen el fitxer XML en aquest cas experiments.xml. Aquest fitxer, on mes endavants’explicara l’estructura que ha de seguir, es pot canviar modificant el parametre de

30

Figura 8: Diagrama de classes del funcionament del simulador.

dins el TestMain.java:FileSystemResource res = new FileSystemResource(”experimentsHistory.xml”);

A continuacio s’extreuen aquestes dades Beans i es guarden com a variables delsistema. Aquestes dades contenen la base de dades que s’utilitzara, les queriesd’usuaris, l’algorisme que ha de seguir, etc. Aixo es fa al crear la classe Simulation-Factory. Dins aquesta mateixa classe tenim el metode de nextSimulation(), el qualcrea una nova simulacio d’usuari (de classe Simulation) amb les dades indicades.Aquesta simulacio creada es retorna al main() i s’utilitza per iniciar l’execucio dela simulacio en la classe LocalExecutionContainer. Aquest proces es realitzara demanera cıclica tantes vegades com queries es tinguin, on cada query representa unusuari diferent fent servir el recomanador.

Un cop inicialitzada la simulacio d’un usuari en l’execute() del Simulation, aquestinicia una nova sessio d’usuar, i en tot moment del proces guarda en un fitxer extern.log les dades resultants d’aquest, per poder analitzar-les en un futur, o utilitzar-lesen algorismes experience-based. Per tal de poder tenir unes dades mes correctes, calrealitzar aquest proces un cert numero d’iteracions definides al principi, en el fitxerexperiments.xml. D’aquesta manera es te que un mateix usuari simulat (query) fa elproces mes d’un cop i evitar aixı si per casualitat ha trobat el producte que buscavao mes rapid o mes lent del que realment hauria. Com mes iteracions es realitzin enaquest punt, mes s’aproximara el resultat als valors amb usuaris reals.

Al Setup es llanca l’execucio de la query. En aquest punt es pot trobar diferentstipus d’usuari. Per exemple que realitza crıtiques compostes o unitaries, que puguicometre errors o no, etc, segons el que s’hagi definit en el fitxer XML. En la Figura 8es mostra el cas que l’usuari sigui estandard (StdUser), es a dir, realitzant crıtiquesunitaries i que sempre realitzi les crıtiques de manera que no contradiguin el pro-ducte final que esta buscant (no cometi errors). Per aixo en la classe StdSimUser,s’agafen les dades de la query per crear aquest usuari, es te per tant un producteinicial on comencar a recomanar (query.getBaseCase()) i el producte final, el qual esel que l’usuari esta buscant (query.getTargetCase()). Al finalitzar la recomanacio,tambe s’obte la crıtica de l’usuari sobre el producte, i es guarda per la proxima

31

query.

Per ultim, quan ja s’ha creat el simulador i la sessio, s’ha definit l’usuari i elsproductes amb els quals comencar i finalitzar aquesta sessio, es passa a aplicar elsalgorismes vistos en aquests projecte. Per aplicar l’algorisme definit en el sistema,es fa mitjancant el metode makeRec(session) de la classe Recommender, on es passacom a parametre la sessio creada abans, aquesta classe es passara a explicar ambmes detall a continuacio.

4.1.3 XML:

En l’entorn definit anteriorment hi ha una part important a l’hora de definir laconfiguracio inicials, en la qual el sistema inicialitzara, i son els Beans.

El fet d’utilitzar aquest fitxer XML, ens aporta poder fer tota la configuracio delsistema que s’utilitzara aquı, ens permet definir tant la base de dades que s’utilit-zara, l’algorisme com els seus parametres interns, o les queries que es simularan.

Per exemple, com s’ha explicat abans sobre la Figura 8, el Setup que era elque llencava l’execucio de la query es poden configurar diferents usuaris, diferentsalgorismes, etc. Aquests valors que estan a dins de la classe Setup s’han d’haverdefinit en el fitxer xml.<bean c l a s s=” rec . sim . Setup”><property name=” l a b e l ”><value>nom f i t x e r l o g</ value></ property><property name=”simUser”><r e f bean=” stdUser ”/></ property><property name=”recommender”><r e f bean=” incrementalCbf ”/></ property></bean>

En el codi anterior s’observa un exemple de com es configuren aquestes dades. Elprimer que es fa al declarar el bean es dir classe que volem configurar. En aquestcas el Setup del paquet rec.sim. Cada variable de dins la classe se li pot assignarun valor, aixı que si es te la variable label de tipus String, se li pot assignar elnom fitxer log. De manera similar es fa si en lloc d’un String es un objecte, llavorsse li pot passar la referencia a una altre Bean.

-Usuari:

Per seleccionar el tipus d’usuaris a simular, i com hem vist estan en el paquetde rec.sim.user, en el fitxer xml s’ha d’assignar les classes que es volen aplicarper cada funcio. Per exemple, si volem simular un usuari estandard cal assignar-lia la classe principal de l’usuari estandard (StdSimUser) les diferents classes queutilitzara per realitzar cada una de les funcions que es poden fer, com per exempleacceptar un producte recomanat recAcceptor o seleccionar la query a realitzar perl’usuari simulat querySelector. En el seguent bean es crearan de la mateixa manera,com a classe principal el StdSimUser i com a propietats totes aquelles classes querealitzaran les funcions especıfiques. Es un exemple per fer els usuaris estandard,amb el nom de id=stdUser, que ha de ser el mateix al que assignem al simUser dela classe Setup.<bean id=” stdUser ” c l a s s=” rec . sim . user . impl . StdSimUser”>recAcceptor=” rec . sim . user . impl . StdRecAcceptor ”r e c S e l e c t o r=” rec . sim . user . impl . StdRecSe lector ”que rySe l e c to r=” rec . sim . user . impl . StdQuerySe lector ”

32

-Algorisme:

Per configurar l’algorisme que s’utilitzara durant la recomanacio, funciona demanera similar a la seleccio del tipus d’usuari. Es crea un bean sobre la clas-se rec.impl.Recommender, el qual se li assignar aquelles classes que pertanyen al’algorisme que volem utilitzar. En el seguent exemple es veu la configuracio del’algorisme estandard de recomanacio basat en crıtiques, anomenat cbf.

queryEngine=rec . impl . StdQueryEngine”caseRec=” rec . impl . StdCaseRec”queryRec=” rec . cb f . CBFQueryRec”r e cBu i l d e r=” rec . cb f . CBFRecBuilder”r e cS t ra t egy=rec . impl . StdRecStrategy ”

-Base de dades i query d’entrada:

Tambe es pot configurar des del fitxer XML, la base de casos amb tots els pro-ductes a utilitzar en el sistema i les queries amb les quals els usuaris simulats esbasaran a l’hora de fer les crıtiques. On els valors .txt son la query i la base dedades a utilitzar.<bean id=” smartphoneQueriesFactory ” c l a s s=” rec . sim . SimQueryReader”><const ructor−arg index=”0” type=” java . i o . F i l e ”><value>quer i e s −5. txt</ value></ const ructor−arg><const ructor−arg index=”1”><r e f bean=”smartphoneCasebase”/></ const ructor−arg></bean>

<bean id=” smartphoneCasebaseFactory ” c l a s s=” rec . casebase . CasebaseReader ”><const ructor−arg index=”0”><value>Smartphone−Casebase</ value></ const ructor−arg><const ructor−arg index=”1”><value>datase t / smartphone/newCB. txt</ value></ const ructor−arg><const ructor−arg index=”2”><value>t rue</ value></ const ructor−arg></bean>

4.2 Interaccio basica entre classes

Les interaccions principals entre classes per aquests algorismes segueixen el mateixpatro i de forma iterativa en cada cicle. La classe principal per realitzar la seguentrecomanacio i des d’on es fan les diferents crides a classes es el Recommender.javacom es pot veure a Figura 9.

La Figura 9 mostra les interaccions generals que realitzen tots els algorismes,pero com s’ha explicat en aquest projecte, cada algorisme segueix un procedimentdiferent de recomanacio, i que estan definides les classes a utilitzar en el XML. Peraixo el XML permet configurar, segons l’algorisme que hem implementat, o quevolem aplicar: queryEngine, caseRec, queryRec, recBuilder i recStrategy.

4.2.1 QueryEngine

Els dos primers metodes no s’utilitzen pero estan preparats per si s’han de fer calculsprevis en algun algorisme. Per tant el primer que tenim es el query(session). Aquestmetode fa una crida a la classe de QueryEngine que es l’encarregada de trobarels ıtems que compleixin els requisits de la nova query, es a dir guarda al Contextnomes aquells casos que compleixin les ultimes crıtiques realitzades per l’usuari. A laFigura 10 tenim les interaccions per obtenir la query, trobar els ıtems que compleixinels requisits i finalment assignar-los com a RelevantCases al RecContext. Tant elsalgorismes estandards de critiquing, com els algorismes experience-based explicats

33

Figura 9: Diagrama general d’interaccions entre classes

en aquest projecte, segueixen aquesta mateixa estructura, i per tant utilitzen lamateixa classe definida en l’algorisme estandard cbf.

Figura 10: Diagrama query estandard

4.2.2 RecStrategy

Aquesta es la classe principal de cadascun dels algorismes, permet definir l’estrategiaque segueix l’algorisme i com gestionar els resultats. Com es veu a la Figura 9,

34

aquesta classe conte la majoria dels metodes definits, tots aquells que fan referenciaal tractament de les dades abans de realitzar qualsevol proces.

En el nostre cas ens centrarem amb el de preCaseRec(), en aquest metode, queesta dins la fase del cicle de recomanacio de Model d’usuari de la Figura 6. La sevafuncio es gestionar el User Model de la sessio en cas dels algorismes incrementals,afegint els productes, crıtiques, a mes d’eliminar les inconsistencies i incompatibili-tats entre crıtiques.

A la Figura 11 es mostra el procediment que es segueix per tal de gestionar elmodel d’usuari. Aquest procediment correspon a l’algorisme d’Incremental Criti-quing [10], pero que tambe es segueix pels algorismes incrementals, amb el seu propimodel d’usuari. Quan es tenen tots els casos o ıtems que satisfan l’ultima crıtica (ocrıtiques en cas que siguin compound), s’afegeix al User Model del IncrementalMo-del amb el metode addCritique(), per aixo abans s’ha de que mirar si hi ha algunacrıtica anterior que contradiu l’actual i eliminar-la, metode pruneToSatisfy().

Figura 11: Diagrama preCaseRec per a IC

4.2.3 CaseRec

La classe de caseRec es la mes complexa de totes, en aquesta classe es on s’aplicael procediment de recomanacio explicat per cada algorisme, es a dir, que correspona la fase de Recuperar del cicle de recomanacio de la Figura 6. Aquesta classe estainicialitzada pel metode de recCases() que es pot veure a la Figura 9.

En aquest punt cal diferenciar clarament els diferents algorismes aplicats, per talde poder explicar-los millor.

-Incremental Critiquing:

En el cas del IC, vegeu la Figura 12, es el mes senzill de tots, ja que no es te encompte l’experiencia d’altres usuaris, i nomes depen de la sessio actual. El primerque cal fer es obtenir les dades de la sessio, com la query actual, el model d’usuarii la llista de casos rellevants seleccionats en la classe de QueryEngine vista. Uncop tenim les dades, es crea la classe OrderedSimilarity, entre altres, i s’obtenen lasimilitud i la compatibilitat de cada producte de la llista dels casos rellevants. Apartir d’aquestes dades, es fa l’ordenacio de la llista de productes, aplicant un 25%

35

Figura 12: Diagrama recCases per a l’algorisme Incremental Critiquing

36

i 75% del valor obtinguts de la similitud i la compatibilitat respectivament.

-Experience-Based Critiquing:

Per a l’Experience-based Critiquing (EBC) [8], definit a la Figura 13, ja s’utilitzenles sessions d’altres usuaris per tal de escollir el proxim producte recomanat en lasessio actual. Per tant, es necessari trobar les sessions rellevants. El proces comencade forma similar a l’IC, obtenint les dades de la sessio actual.

Per obtenir les sessions rellevants, es fan dos passos, el primer es tracta de puntu-ar cada una d’aquestes sessions segons la similitud amb la sessio actual en la funciosetScoreSessionEBC, aquesta funcio suma el numero de crıtiques d’usuari que coin-cideixen en la sessio a puntuar i l’actual, seguint l’Equacio d’OverlapScore 3.10 delcapıtol 3. Al segon pas es passa la llista de sessions cada una amb la corresponentpuntuacio al metode de getRelevantSessionCrit, on es filtren totes aquelles sessionsque no obtenen un mınim de puntuacio.

Amb la llista de sessions rellevants es realitza una ordenacio segons la puntuacioobtinguda en cada cas, i s’agafen tots els productes terminals de les sessions, esa dir el producte final que ha escollit l’usuari de cada sessio. S’eliminen tots elsproductes terminals que no estiguin dins la llista de casos rellevants obtinguts en lafase de QueryEngine, i es recomana el primer de la llista resultant.

Si per altre banda no es troben sessions suficientment rellevants com per tenir-lesen compte, es realitzara la recomanacio seguint l’algorisme estandard de critiquing.Es passen a ordenar els productes rellevants segons la similitud i el que mes similitudobtengui es el proxim producte recomanat.

-History-Aware Critiquing:

Amb l’algorisme de History-Aware Critiquing (HAC) [14], definit a la Figura 14,es segueix com a idea principal la mateixa implementacio definida per l’algorismeEBC, obtenir les sessions rellevants per aconseguir el millor producte a recomanar.

En el cas d’HAC tambe es fa una puntuacio amb el metode setQualitySessions-HAC, a cada sessio per poder escollir les mes rellevants pero a diferencia de l’EBC,aquest algorisme segueix l’Equacio 3.15 del capıtol 3 per tal de trobar la qualitatde cada sessio, on es tenen en compte tant les crıtiques en comu com la similitudentre els casos recomanats en cada sessio.

A partir de la puntuacio de qualitat getRelevantSessionsQuality, i d’igual maneraque ho fa EBC es filtren totes aquelles sessions que no obtenen una puntuaciomınima.

Les sessions restants s’ordenen segons la qualitat, s’eliminen els productes queno apareixen en la llista de casos rellevants de la fase de QueryEngine i s’agafa elprimer producte d’aquesta llista com el cas a recomanar.

En cas de no tenir sessions rellevants es passa a fer la recomanacio aixı com hofaria l’Incremental Critiquing i explicat a la Figura 12.

-History-Guided Conversational Recommendation:

El History-Guided Conversational Recommendation (HGR) [13], es una nova

37

Figura 13: Diagrama recCases per a l’algorisme EBC

38

Figura 14: Diagrama recCases per a l’algorisme HAC

39

versio millorada de l’EBC i es pot veure el seu diagrama a la Figura 15.

S’ha de comprovar quina sessio de l’historial es mes similar a l’actual, aixo hoobtenim mitjancant el listRelevantSessions(). En aquest cas les sessions rellevantsseran aquelles que compleixin un requisits mes estrictes. La funcio setScoreSessi-onsHGR assigna a cada sessio un valor de similitud, obtingut a traves de l’Equacio3.14. Aquest valor es calculat amb el numero de parelles de crıtica i producte quecoincideixen. En cas de no trobar sessions rellevants amb aquest metode es segueixl’algorisme EBC amb setScoreSessionsEBC per assignar la similitud entre sessions.

Amb la llista de sessions rellevants, obtinguda tant a traves de setScoreSessi-onsHGR com setScoreSessionsEBC es passa a ordenar i escollir el producte reco-manat de la mateixa manera que amb l’algorisme HAC.

-Graph-based:

El Graph-based o Compound Critiquing esta basat amb les crıtiques compostes.Per tant, s’haura tractar de manera diferent i tenir en compte aquestes a l’hora derecomanar el proper producte. Les iteracions entre classes per obtenir les dadesde la sessio son similars als vistos en els casos anteriors, amb la diferencia que enaquest cas tenim tambe guardada la sessio actual en un graf amb les relacions entrecrıtiques compostes i productes.

Per trobar les sessions similars, tambe s’assigna una puntuacio de similitud acada una de les sessions d’altres usuaris. Per calcular aquesta puntuacio es segueixl’Equacio 3.27 (RSim), la qual retorna la similitud entre grafs. Aixı que abansde poder assignar una puntuacio, es recorren totes les sessions del loggedSessions(llista de sessions obtingudes a traves del LogReader), per cada sessio es crea el grafcorresponent i juntament amb el graf de la sessio actual es passen a la funcio deRSim que calcula la similitud mitjancant l’equacio abans mencionada. Sempre quela puntuacio sigui mes gran que el threshold predefinit es guarda aquesta sessio ala llista de sessions rellevants listSessionsSimilars.

Amb la llista de sessions similars, com s’ha explicat en els altres algorismesd’experience-based, s’ordenen segons puntuacio i s’agafa el primer producte semprei quan estigui dins la llista de casos rellevants tambe, mitjancant la funcio getRF.En cas de no tenir cap sessio rellevant o similar es passa a ordenar i obtenir elproducte de la forma estandard pels sistemes incrementals, de la mateixa maneraque IC (getOrderedListIC ).

4.2.4 QueryRec

En les classes de queryRec es generen les queries a partir de les dades obtingudes.Aquesta etapa es la corresponent a la fase de Reutilitzar del cicle definit en la Figura6. Es tracte de generar la retroalimentacio que faria un usuari real. Aquest proceses mostra a la Figura 17. A partir dels casos o productes recomanats en la fasede caseRec on es guardaven en el RecContext, es genera una query amb una crıticaper cada atribut dels productes i es guarden en el RecContext. Aquest proces esel mateix pels algorismes d’IC, EBC, HAC i HGR. En canvi pels algorismes decrıtiques compostes utilitzen un algorisme apriori [15] per generar aquestes queries.

40

Figura 15: Diagrama recCases per a l’algorisme HGR

41

Figura 16: Diagrama recCases per a Compound Critiques, basat amb Grafs

Figura 17: Diagrama recQueries per a l’algorisme IC

4.3 Graph-based

Per tal d’entrar mes amb detall de l’algorisme que s’ha implementat basat en Co-llaborative Compound Critiques [15] [1], s’explicaran les classes implementades dife-rents als algorismes basats en crıtiques unitaries. En aquest algorisme s’utilitzen lescrıtiques compostes, es a dir que per cada producte recomanat l’usuari pot realitzarvaries crıtiques.

42

4.3.1 Implementacio

En aquest algorisme son necessaries les relacions entre ıtems i crıtiques en cadasessio, per despres poder trobar les sessions mes rellevants. Aixı que es construeixenuns grafs per controlar aquest aspecte. Per aixo s’han creat dues classes anomenadesGraph i Edge, el primer per guardar cada sessio convertida a graf i el segon la relacioıtem-crıtica, es a dir l’aresta del graf.

1. Graph.class: Aquesta classe esta formada per la llista d’ıtems, llista de crıtiques,la llista d’arestes de item→crıtica i la llista de crıtica→item. Cada sessio esguardara com a Graph de manera que despres sera mes senzill aplicar laformula per trobar les sessions similars.

2. Edge.class: Aquesta classe simplement guarda un ıtem i una crıtica, i esutilitzada per a guardar totes les arestes en la classe Graph.

-Guardar graf:

Tambe es necessari anar guardant el graf parcial en cada iteracio de la sessioactual, per cada crıtica i producte recomanat anar afegint al graf aquestes dades.La classe del model es qui fa aquesta feina, quan obtenim una query per part del’usuari, es a dir que ha fet una o varies crıtiques sobre un producte. Aquesta querypassa al model que amb el metode addGraph(query) afegeix les noves dades al grafde la sessio. Aquest metode afegeix tantes crıtiques al graf com hagi fet l’usuari,el producte, i totes les relacions entre producte i crıtica que s’han fet. Per poderrealitzar les arestes item→crıtica es senzill, simplement es guarda un nou Edgeamb valors de crıtica actual i ıtem actual, a la llista del Graph. En canvi, per feruna aresta crıtica→item, es necessari tenir guardat temporalment les crıtiques del’anterior iteracio, ja que la query del usuari nomes retorna els valors actuals.

43

5 Avaluacio

L’avaluacio es una part molt important dins la programacio i implementacio d’algo-rismes de recomanacio, ja que et permet saber l’eficiencia d’aquests i quins resultatss’esperen en un entorn real. Per comprovar el funcionament dels diferents algoris-mes, provar la eficiencia de cada un d’ells i poder millorar-los, s’utilitza una Basesde dades on recullen els productes amb les seves caracterıstiques, a mes de queriesque simulen als usuaris reals i permet testejar de manera molt mes rapida.

S’ha fet l’avaluacio del projecte a sobre d’una base de dades de productes SMARTP-HONE. Aquesta base de dades esta formada per 1722 productes diferents, cada undels quals esta format per 9 caracterıstiques sobre les quals els usuaris poden rea-litzar les crıtiques.

Les caracterıstiques o atributs dels smartphones son: Model, Weight, Size, Sto-rage, Ram, Resolution, SO, CPU i Price. Tots aquests atributs son numerics, i pertant es poden realitzar sobre ells crıtiques del tipus major que (>) o menor que (<),a excepcio del Model i de la CPU, els quals simplement es poden fer una crıtica dediferent Model o diferent CPU (<>).

5.1 Query

En l’avaluacio tambe es distingeixen diferents tipus de nivells de dificultat, o nivellsde coneixement dels usuaris. Per aconseguir aquest efecte es poden dividir lesproves amb queries de 1, 3 o 5 caracterıstiques inicials que es corresponen ambqueries (textithard, textitmoderate i easy).

Aquests numeros es refereixen als atributs inicials que es donen en la queryd’entrada, es a dir, que si es fa el test amb query-5 significa que totes les queriesque es provaran en aquest test estaran iniciades amb 5 caracterıstiques del productefinal, d’aquesta manera es mes senzill arribar al producte final, i per tant simulariaun usuari amb alts coneixements del producte. D’altra banda, si es fan les provesamb query-1 es simulen usuaris amb baix coneixement del producte, i que per tantnomes aporta un atribut sobre el producte final que esta buscant.

Per exemple, si es vol posar un nivell de coneixement per part de l’usuari moltbaix, aquest nomes aportara una caracterıstica del producte final (query-1). Enla seguent query, tenim el cas inicial, el cas final, i totes les caracterıstiques delproducte final separades per &, aquelles que estan amb * son les que l’usuari noconeix en el moment d’iniciar el sistema:

CASE612|CASE610| ∗& ∗& ∗& ∗& ∗& ∗&8.0& ∗& ∗& ∗&

La seguent query correspon a un exemple per query-5:

CASE113|CASE87|∗&C5−03&∗&∗&40.0&∗&∗&SymbianOSv9.4, Series60rel.5&600MHzARM11&100.0&

44

5.2 Metodologia

La metodologia utilitzada es l’anomenada Leave-one-out [3], que consisteix en aga-far de la base de dades original de tots els productes, una mostra de productesescollits de manera aleatoria que es faran servir com test. En el nostre cas, s’agafen300 productes aleatoris de SMARTPHONE. Per cada un dels productes es testejal’algorisme, eliminant aquest de la base de dades original mentre es realitza el testsobre el producte.

Els resultats es comparen segons la longitud de la sessio (session length). Aquestaes una bona forma de comprovar l’eficiencia de cada sistema recomanador, cadaiteracio on es recomana un nou producte, la sessio s’incrementa en 1. De maneraque al final tenim que la session length es el numero de productes recomanats finsque l’usuari ha acceptat el producte.

5.3 Analisi dels Resultats

En l’analisi de resultats es convenient dividir clarament els algorismes de crıtiquesunitaries amb els de crıtiques compostes, ja que d’altre manera no es te una re-ferencia real al comparar algorismes que utilitzin diferent mode de crıtiques. Perles crıtiques unitaries es comparen els algorismes estudiats de Incremental Criti-quing (IC), Experience-Based Critiquing (EBC), History-Aware Critiquing (HAC),History-Guided Recommendation (HGR), History Opinion Recommendations (HOR)i Graph-Based, amb les diferents queries (easy, moderate i hard) per separat, i com-provant la longitud mitjana de realitzar 10 iteracions amb les 300 queries en cadacas. Per les crıtiques compostes es comparen els algorismes d’Incremental Critiquingamb crıtiques compostes (IC CC) i el Graph-Based, a mes de l’algorisme estandardper a crıtiques compostes, tambe amb les diferents queries (easy, moderate i hard)per separat, i comprovant la longitud mitjana de realitzar 10 iteracions amb les 300queries en cada cas (en total 3000 proves per cada algorisme). Per a les compostess’ha realitzat una comparativa amb diferent threshold (50-80), per tal de comprovarquin es el mes adequat en el nostre cas, i utilitzar-lo amb les crıtiques compostesper al graph-based.

Una de les millors maneres d’analitzar el rendiment es comparar la longitud desessio mitjana que realitzen els usuaris durant les proves. La longitud de la sessio decada usuari que correspon amb el numero d’iteracions que realitza l’usuari des deque inicia la sessio amb el primer producte, fins que troba el producte final, teninten compte que cada iteracio es cada un dels productes recomanats intermitjos.

5.3.1 Crıtiques unitaries

Les crıtiques unitaries en general aconsegueixen una longitud de sessio mes elevadaque les crıtiques compostes pel simple fet de que en cada producte nomes es permet

45

fer una crıtica, i per tant requereix de mes cicles per fer mes crıtiques abans d’arribaral producte recomanat.

Figura 18: Mitja de session length per a Smartphone

A la Figura 18 es mostra la longitud mitjana de sessions i s’ha fet el promig detotes les queries (hard, moderate i easy), en cadascun dels algorismes. El STDrepresenta la longitud mitjana si es fa una recomanacio estandard, es a dir senseaplicar cap dels algorismes explicats en aquest projecte. Podem comprovar com elfet d’aplicar l’algorisme estandard d’experience-based (EBC) ja redueix en mes dela meitat el STD. Si ens fixem amb l’algorisme incremental d’IC, que no esta basatamb l’experiencia del usuari, simplement es te en compte la sessio actual, passa de90.89 a 14.45 la longitud de sessio enfront a l’estandard, nomes tenint en compte elmodel d’usuari, la similitud i compatibilitat, millorant fins i tot l’algorisme d’EBC.

Si entrem mes en detall, i obviant el cas STD, podem analitzar amb les queriesde q1 (hard) a la Figura 19, q3 (moderate) a la Figura 20 i q5 (easy) a la Figura21, per separat.

Figura 19: Session length Q1 per a Smartphone

En el cas de Q1, es a dir que el valor inicial de l’usuari simulat nomes tingui unacaracterıstica sobre el producte final. Per tant es mes difıcil pel sistema arribar a

46

recomanar el producte final i requereix de mes iteracions o cicles. En aquest cas elgraph-based millora a l’incremental critiquing (IC), tot i que com hem vist amb lamitjana de les queries de (q1,q3,q5) de la Figura 18 aquest no millorava, aixo ensindica que com mes difıcil sigui el sistema i menys dades inicials aporti l’usuari, meseficient es graph-based enfront a l’IC.

Figura 20: Session length Q3 per a Smartphone

A l’analitzar els altres algorismes que utilitzen l’experiencia d’usuari, l’HOR esel millor de tots els algorismes, seguit pel HAC i HGR. Si ens mirem la Figura 18,tot i que estan molt igualats, l’HAC millora l’HGR. Per altre banda, si ens fixem enla Figura 19, en la qual tenim nomes la mitjana de les sessions per a les queries deQ1 (hard), l’HGR millora en mes d’un cicle l’HAC i esta al nivell d’HOR. Per tantpodem deduir que l’HGR (de forma similar al que passa amb el Graph-based enfronta IC) seria millor algorisme en un sistema on els usuaris no tenen un coneixementprevi sobre els atributs dels productes que ofereix el sistema, mentre que l’HAC esmillor en sistemes on els usuaris tenen uns coneixements mes detallats, com es potveure en els grafics de queries Q3 i Q5 (moderate i easy), Figures 20 i 21.

Figura 21: Session length Q5 per a Smartphone

47

5.3.2 Compound Critique

Per les crıtiques compostes es comparen els algorismes d’Incremental Critiquingamb crıtiques compostes (IC CC) i el Graph-Based, a mes de l’algorisme estandardper a crıtiques compostes, tambe amb les diferents queries (easy, moderate i hard)per separat. En la Figura 22 es poden veure els diferents grafics que es com-paren entre els algorismes que utilitzen crıtiques compostes. Tant els algorismesd’incremental critiquing basat en crıtiques compostes, com el basat en grafs, mi-lloren en mes del 75% a l’algorisme estandard. En tots aquests grafics es veu coml’IC CC supera a l’algorisme basat amb grafs, el qual utilitza l’experiencia d’altresusuaris i te en compta tambe les relacions entre crıtiques i ıtem en cada cicle. En elcas de la query-1 (hard), Figura 22a, es on es redueix mes la diferencia de longitudde sessio (#cicles) entre l’IC i el graph-based, nomes separats per mig cicle. Mentreque en les queries mes facils arriba a quasi un cicle de diferencia.

(a) Session length Query-1 (b) Session length Query-3

(c) Session length Query-5(d) Session length

Figura 22: Compound critique, comparacio per algorismes

En l’algorisme estandard de crıtiques compostes es poden generar les crıtiquesen cada cicle de varies maneres, i depenent del threshold indicat. Existeixen 3variacions per com mostrar les critiques a l’usuari durant cada cicle. Lowest Support(LS), segons els resultats de [1] aquest es el millor dels 3, agafa les 5 crıtiques ambmenys suport. El Highest Support (HS), les 5 crıtiques amb mes suport. I el random(RAND), agafa 5 crıtiques de forma aleatoria. Aquests metodes son escollits en elfitxer XML, juntament amb el valor de threshold. Per analitzar quin es el thresholdmes optim, i que per tant s’utilitzara tambe en el graph-based i IC CC, es realitzenles proves amb l’algorisme estandard de crıtiques compostes amb diferents valorsde threshold, com es pot veure a la Figura 23 a sobre del metode Lowest Suport.

48

Figura 23: Session lenght segons threshold per a LS

S’ha realitzat les proves amb thresholds entre 50 i 80, i comparat tambe amb lesdiferents queries, Q1, Q3 i Q5. Amb els resultats mostrats en la Figura 23 podemcomprovar com el millor valor de threshold es el 60, encara que si ens fixem mes enla query-1 (hard), el millor threshold es el 50. El pitjor dels que hem comprovat esel 80.

5.3.3 Resum

Com a resum podem dir que el millor algorisme per la base de dades de SMARTP-HONE i amb crıtiques unitaries, es l’HOR, tot i que amb el HAC i HGR tambetenen uns resultats bastant optims. En el cas d’HGR es un molt bon algorismequan es tracta d’usuaris amb poc coneixement sobre el producte, i ens aporta pocainformacio del que vol.

D’altra banda, els algorismes basats en crıtiques compostes i utilitzant LowestSuport hem trobat que el millor threshold es de 60, i que per tant es el que s’hautilitzat per tots els algorismes basats en crıtiques compostes. Tant el d’incrementalcritiquing, com el basat en grafs, milloren bastant a l’algorisme estandard. Tot ique utilitza l’experiencia d’altres usuaris l’IC CC supera a l’algorisme basat ambgrafs.

49

6 Valoracio economica

En aquest capıtol es detalla la valoracio economica del projecte presentat i s’estimael cost economic. A mes a mes es fa una analisi de les hores invertides mitjancant unataula amb el desglossament del treball a traves de les diferents tasques realitzades.

6.1 Temps

El temps invertit en aquest projecte es de 450 hores, dividides en les diferentstasques:

1. Estudi bibliografic: Estudi dels sistemes recomanadors, dels tipus que existei-xen i dels diferents algorismes basats en crıtiques.

2. Analisi plataforma i algorismes: Analisi de la llibreria implementada en Java,l’entorn i la plataforma utilitzada pel grup de recerca. A mes dels algorismesja implementats d’IC i HOR.

3. Implementacio: Implementacio sobre l’entorn dels algorismes d’experience-based estudiats en la primera part del projecte.

4. Proves: Analisi dels algorismes amb un simulador i extraccio dels resultats,tant dels algorismes implementats, com els que ja venien implementats en laplataforma amb l’objectiu de comparar-los.

5. Documentacio: Realitzacio de la memoria del treball final de grau, en la ques’explica el treball realitzat anteriorment.

Figura 24: Desglossament de les tasques segons el temps invertit

50

A la Figura 24 es mostra el grafic del desglossament de les tasques i el percentatgede temps invertit en cada una de les parts. Com es pot comprovar, en aquestprojecte s’ha dedicat molt de temps a realitzar l’estudi bibliografic previ i l’analiside l’entorn i plataforma, ja que esta basat amb el treball realitzat pel grup derecerca Volume Visualization and Artificial Intelligence (WAI). Aquestes tasquesrepresenten el 31% del temps total del projecte, el 22% per l’estudi bibliografic delsarticles sobre els sistemes recomanadors i un 9% sobre l’analisi de l’entorn.

La implementacio dels algorismes estudiats es la tasca mes costosa i representaquasi la meitat del projecte un 45%. Les proves que es realitzen tant dels algorismesimplementats com els que ja hi estaven nomes representen l’11%, aquestes provesamb molts de casos es realitzen juntament amb la implementacio.

Per acabar, el temps restant, el 13% esta dedicat a la documentacio del projecte

6.2 Cost economic

Degut al tipus de projecte el cost esta completament amb la ma d’obra, no esrequereixen productes ni materials i en aquest cas tampoc es necessari la comprade cap tipus de llicencia, ja que tots els programes utilitzats son de llicencia lliure.

En la taula de la Figura 25 es mostra el cost de cada una d’aquestes tasques, enfuncio del temps dedicat i el preu per hores treballades.

Figura 25: Desglossament del preu segons tasques

El cost total del projecte es de 7.250e, dels quals el que suposa el major cost,amb mes de la meitat del total, es la part d’implementacio degut al major numerode hores i al major preu, ja que es la part mes important de tot projecte.

51

7 Conclusions

Existeixen molts de tipus de sistemes recomanadors, els basats en contingut i elsbasats en filtrat col·laboratiu. En aquest projecte s’han estudiat els sistemes reco-manadors basats en contingut i, dins d’aquest grup, s’ha centrat el projecte en elsconversacionals que utilitzen com a retroalimentacio de l’usuari les crıtiques. Enconcret, en el projecte s’ha definit com a objectiu implementar alguns d’ells (EBC,HAC i graph-based).

L’objectiu general del projecte es l’estudi, la implementacio i la comparativadels algorismes de recomanacio conversacionals basats en crıtiques de la famıliadels experience-based, per tal de veure quina es la millora respecte als algorismesestandard de critiquing (IC i Std).

Gran part de la feina s’ha centrat en l’estudi bibliografic. Per aquest motiu,s’han seguit els articles del grup de recerca Volume Visualization and ArtificialIntelligence (WAI), i s’han implementat els algorismes d’experience-based a la lli-breria desenvolupada en aquest grup. Possiblement aquesta part, la d’estudi previ,ha estat la part que m’ha resultat mes complicada, el fet de llegir diferents articlestant especıfics que s’entrellacen entre ells, m’ha costat poder-ho entendre de manerarapida.

Els algorismes s’han provat sobre una sola base de dades de smartphones. Elsresultats de la comparativa demostren que els algorismes d’experience-based sonmes acurats en la recomanacio que els algorismes estandard de critiquing. El milloralgorisme ha resultat ser l’HOR, seguit per HAC i HGR. Del graph-based m’espe-rava uns resultats millors degut a que te una millor gestio de crıtiques compostes,potser el problema esta en que l’historial de sessions hauria de ser mes gran, ja quela similitud entre sessions depen de moltes coincidencies entre caracterıstiques dediferents sessions, difıcils de trobar en petites bases de dades.

Com a conclusio general puc dir que m’ha agradat fer aquest projecte sobre untema que m’ha sorpres per la profunditat que pot tenir. Tambe haver de fer undocumentacio tant especıfica ha estat una experiencia nova, i que ha estat de lesparts que m’ha costat mes de fer. Com a treball futur plantejaria fer una analisi mesexhaustiu dels algorismes implementats amb mes bases de dades, les quals tinguinun major volum d’informacio.

52

Referencies

[1] J. Reilly K. McCarthy B. Smyth, L. McGinty. Compound critiques for conver-sational recommender systems. 2004.

[2] L. Chen and P. Pu. Critiquing-based recommenders: survey and emergingtrends. User Modeling and User-Adapted Interaction, 22(1-2):125–150, 2012.

[3] I. Rodriguez A. Puig D. Contreras, M. Salamo. Towards collaborative conver-sational recommendations within 3d virtual environments. pages 20–23, 2014.

[4] M. Salamo D. Contreras. Integrating history and user opinion for conversati-onal recommendations. 2014.

[5] L. McGinty B. Smyth J. Reilly, K. McCarthy. Explaining compound critiquing.2014.

[6] J. Konstan and J. Riedl. Recommender systems: from algorithms to user ex-perience. User Modeling and User-Adapted Interaction, 22(1-2):101–123, 2012.

[7] K. McCarthy, J. Reilly, L. McGinty, and B. Smyth. On the dynamic generationof compound critiques in conversational recommender systems. In AdaptiveHypermedia and Adaptive Web-Based Systems, volume 3137 of Lecture Notesin Computer Science, pages 176–184. Springer, 2004.

[8] K. McCarthy, Y. Salem, and B. Smyth. Experience-based critiquing: Reusingcritiquing experiences to improve conversational recommendation. In Procee-dings of the International Conference on Case Base Reasoning, pages 480–494.Springer, 2010.

[9] L. McGinty and J. Reilly. On the evolution of critiquing recommenders. InRecommender Systems Handbook, pages 419–453. Springer, 2011.

[10] J. Reilly, K. McCarthy, L. McGinty, and B. Smyth. Incremental critiquing.Knowledge-Based Systems, 18(4-5):143–151, 2005.

[11] M. Salamo and S. Escalera. Increasing retrieval quality in conversational recom-menders. Knowledge and Data Engineering, IEEE Transactions on, 24(10):1–14, 2012.

[12] M. Salamo, J. Reilly, L. McGinty, and B. Smyth. Improving Incremental Criti-quing. In Proceedings of the 16th Artificial Intelligence and Cognitive Science,pages 379–388, 2005.

[13] Y. Salem, J. Hong, and W. Liu. History-guided conversational recommendati-on. In Proceedings of the 23rd International Conference on WWW Companion,pages 999–1004, 2014.

[14] Yasser Salem and Jun Hong. History-aware critiquing-based conversational re-commendation. In Proceedings of the 22Nd International Conference on WWWCompanion, pages 63–64, Switzerland, 2013.

53

[15] H. Xie, L. Chen, and F. Wang. Collaborative compound critiquing. In User Mo-deling, Adaptation, and Personalization, volume 8538, pages 254–265. Springer,2014.

54