sistema de recomendaciÓn turÍstica basado en rbr y cbr

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY

SISTEMA DE RECOMENDACIÓN TURÍSTICA BASADO EN RBR Y CBR

TESIS QUE PARA OPTAR EL GRADO DE MAESTRO EN CIENCIAS COMPUTACIONALES

PRESENTA

JOSÉ ARTURO TEJEDA GÓMEZ

Asesor:

Co-Asesor:

Dra. MA. DE LOS ÁNGELES JUNCO REY

Dr. JORGE ADOLFO RAMÍREZ URESTI

Comité de tesis:

Dr. STEVEN WILMOTT

Dr. ISAAC JUAN RUDOMIN GOLDBERG

Jurado:

Dr. ISAAC JUAN RUDOMIN GOLDBERG,

Dr. JORGE ADOLFO RAMÍREZ URESTI,

Dr. STEVEN WILMOTT,

Dr. MA. DE LOS ÁNGELES JUNCO REY

Presidente

Secretario

Vocal

Vocal

Atizapán de Zaragoza, Edo. Méx., Agosto de 2006.

DEDICATORIA

A Dios, a mis padres y a mi padrino (q.e.p.d)

AGRADECIMIENTOS A Dios por permitirme alcanzar un logro más en mi vida profesional. A mis padres, sería difícil imaginar mi vida sin su apoyo, comprensión y su inmenso amor. Ha sido difícil no convivir con ustedes durante estos tres años pero éste también es un logro para ustedes. A mi padrino (q.e.p.d.), este logro también es tuyo, fuiste y serás mi gran ejemplo a seguir. A mi directora de tesis, Dra. Angeles Junco, por su generosidad al brindarme la oportunidad de recurrir a su capacidad y experiencia científica en un marco de confianza, afecto y amistad, fundamentales para la concreción de este trabajo de tesis. Además por haberme dado la oportunidad de trabajar de la misma manera con usted para el proyecto @lisTechNet. A mi co-director de tesis, Dr. Jorge Uresti, por su apoyo y valiosa colaboración para la realización de este trabajo. Al Dr. Isaac Rudomin, por haber revisado con paciencia este trabajo. Al Dr. Steven Wilmott, por haber aceptado ser miembro del jurado y revisar con paciencia este trabajo. Su confianza depositada en mi trabajo realizado para el proyecto @lisTechNet ha sido fundamental. Al Dr. Neil Hernández, por su comprensión y apoyo a lo largo de todo el postgrado. Al Dr. Ricardo Swain, por su apoyo, estímulo y confianza; los cuales han sido invaluables. Al M.Sc. Steven Bogaerts de la Universidad de Indiana, EEUU, por permitirme utilizar la herramienta IUCBRF para implementar el razonamiento basado en casos. Al proyecto @lisTechNet y a sus miembros por los conocimientos aportados, ya que en el marco de este proyecto surgió éste trabajo de tesis. A todos mis profesores del programa de la maestría en ciencias de la computación que de alguna manera contribuyeron en mi formación profesional. A mi mejor amigo, Zeus Andrade, por soportarme durante estos tres años en los que su amistad incondicional ha sido un pilar para que la cotidianidad de la vida sea más llevadera. Al ITESM, Campus Estado de México y al CONACYT por haberme apoyado en el estudio de éste postgrado.

RESUMEN

El turismo representa una fuente de ingresos para todos los países del mundo. Hoy en día, los turistas prefieren utilizar la Internet para reservar una fórmula de vacaciones combinadas. Por lo tanto, los sistemas de recomendación turística son fundamentales para que los turistas cuenten con los recursos o servicios turísticos que mejor concuerden con sus preferencias.

Los sistemas de recomendación proveen sugerencias específicas con base en las

preferencias del usuario y representan un medio eficaz de filtrado cuando existe demasiada información significativa. En el ámbito del turismo, un sistema de recomendación es una herramienta que debe presentar al usuario un subconjunto de la información total acerca de servicios turísticos que representa y satisface en un cierto grado las preferencias del usuario. No obstante, proveer de mecanismos que incrementen la precisión del sistema es indispensable para mejorar el grado de satisfacción del usuario.

En esta tesis, se ha planteado el problema de integrar los mecanismos de razonamiento basado en reglas (RBR) y razonamiento basado en casos (CBR), en el desarrollo de un sistema de recomendación turística que sea capaz de proveer recomendaciones de recursos e itinerarios turísticos de manera personalizada. Además se propone una metodología para el desarrollo de un sistema de recomendación turística que combina ambos tipos de razonamiento. Con base en dicha metodología se ha desarrollado un prototipo llamado SyRec, que tiene el objetivo de evaluar un sistema provisto de ambos mecanismos de razonamiento y con base en la metodología propuesta. El RBR es utilizado para la recomendación de ítems turísticos en donde se lleva acabo procesos tales como: filtración, clasificación e inferencia de ítems turísticos para la planeación y modificación de un itinerario. El CBR es utilizado para la recomendación de itinerarios tiene el objetivo de recomendar al usuario los cinco principales itinerarios que satisfagan las preferencias del usuario en mayor grado con opción de modificarlos.

La principal contribución de este trabajo de tesis es un sistema de recomendación turística desarrollado con la metodología propuesta que integra el RBR y el CBR para solucionar el proceso de planeación de un itinerario turístico con base en las recomendaciones de ítems e itinerarios turísticos.

Este trabajo, ha sido desarrollado dentro del ámbito del proyecto @lisTechnet, el cual tiene como uno de sus objetivos demostrar que el empleo de tecnologías como la de los sistemas multiagente y el razonamiento basado en reglas, pueden ayudar a solucionar de manera distribuida la planeación de un itinerario turístico para varios países. El sistema SyRec es presentado como una aportación para el proyecto @lisTechnet, como un sistema demostrativo que ayuda a la explotación de los recursos culturales y de turismo.

9

CONTENIDO

ÍNDICE DE FIGURAS ..........................................................................................................13

INDICE DE TABLAS ............................................................................................................15

1. INTRODUCCIÓN..............................................................................................................17

1.1 GENERALIDADES .............................................................................................................17 1.2 PROYECTO @LIS-TECHNET .............................................................................................19

1.2.1 Programa @lis ........................................................................................................19 1.2.2 Proyecto @lis TechNET ..........................................................................................21

1.3 DESCRIPCIÓN DEL PROBLEMA..........................................................................................23 1.4 OBJETIVOS.......................................................................................................................24 1.5 JUSTIFICACIÓN.................................................................................................................25 1.6 HIPÓTESIS........................................................................................................................25 1.7 ALCANCES Y LIMITACIONES.............................................................................................26 1.8 METODOLOGÍA ................................................................................................................26 1.9 ORGANIZACIÓN DEL DOCUMENTO....................................................................................27

2. SISTEMAS DE RECOMENDACIÓN TURÍSTICA......................................................29

2.1 EL COMERCIO ELECTRÓNICO Y EL TURISMO: PROBLEMÁTICA Y RETOS............................29 2.2 LA TOMA DE DECISIÓN EN LA PLANEACIÓN DE VIAJES TURÍSTICOS ..................................32 2.3 SISTEMAS DE RECOMENDACIÓN.......................................................................................33

2.3.1 La recuperación de información preferencial......................................................34 2.3.2 Tipos de sistemas de recomendación ...................................................................34 2.3.4 Objetivos de un sistema de recomendación..........................................................35 2.3.5 Evaluación de sistemas de recomendación ..........................................................36

2.4 SISTEMAS DE RECOMENDACIÓN TURÍSTICA......................................................................39 2.5 RESUMEN.........................................................................................................................41

3. RAZONAMIENTO BASADO EN REGLAS ..................................................................43

3.1 SISTEMAS DE PRODUCCIÓN..............................................................................................44 3.2 ELEMENTOS DE UN SISTEMA DE PRODUCCIÓN..................................................................46

3.2.1 Producción de reglas...............................................................................................46 3.2.2 La memoria de trabajo ............................................................................................47 3.2.3 La unidad de control ...............................................................................................47

3.3 PROPIEDADES DE UN SISTEMA DE PRODUCCIÓN...............................................................49 3.4 TIPOS DE SISTEMAS DE PRODUCCIÓN................................................................................51

3.4.1 Sistemas conmutativos.............................................................................................51 3.4.2 Sistemas particionados............................................................................................51

3.5 RESUMEN.........................................................................................................................52

10

4. RAZONAMIENTO BASADO EN CASOS......................................................................53

4.1 INTRODUCCIÓN................................................................................................................53 4.2 EL CICLO DEL RAZONAMIENTO BASADO EN CASOS...........................................................55 4.3 MÉTODOS DEL RAZONAMIENTO BASADO EN CASOS.........................................................58

4.3.1 Representación de casos..........................................................................................58 4.3.2 Recuperación...........................................................................................................59 4.3.3 Reutilización ............................................................................................................62 4.3.4 Revisión ...................................................................................................................63 4.3.5 Almacenamiento ......................................................................................................63

4.4 COMPARATIVA DEL RAZONAMIENTO BASADOS EN CASOS VS. OTRAS TÉCNICAS..............64 4.4.1 CBR y la recuperación de información ...................................................................64 4.4.2 CBR vs. Técnicas estadísticas .................................................................................64 4.4.3 CBR vs. Sistemas de producción .............................................................................65 4.4.4 CBR vs. Máquinas de aprendizaje...........................................................................66 4.4.5 CBR vs. Redes neuronales.......................................................................................66

4.5 APLICACIONES DEL RAZONAMIENTO BASADO EN CASOS..................................................67 4.6 RESUMEN.........................................................................................................................69

5. TRABAJO RELACIONADO............................................................................................71

5.1 SISTEMAS DE RECOMENDACIÓN TURÍSTICA BASADOS EN CBR ........................................72 5.1.1 Metodología Trip@dvice.........................................................................................73 5.1.2 ITR: Un sistema de recomendación inteligente de viajes .......................................81

5.2 SISTEMA DE RECOMENDACIÓN Y PLANEACIÓN DEL PROYECTO @LISTECHNET................86 5.2.1 Descripción del sistema demostrativo @lisTechNet ...............................................87 5.2.2 Arquitectura del sistema..........................................................................................92 5.2.3 Razonamiento dentro del sistema demostrativo de @lisTechnet ............................94

5.3 OTROS SISTEMAS...........................................................................................................102 5.3.1 Sistemas de recomendación turística basados en MAS.........................................102 5.3.2 Sistemas de recomendación turística comerciales ................................................106 5.3.3 Sistemas que combinan el RBR y CBR ..................................................................107

5.4 COMPARATIVA DE SISTEMAS.........................................................................................108 5.5 RESUMEN.......................................................................................................................111

6. SISTEMA DE RECOMENDACIÓN TURÍSTICA PROPUESTO: SY REC.............113

6.1 INTRODUCCIÓN..............................................................................................................113 6.2 METODOLOGÍA ..............................................................................................................114

6.2.1 Modelación de plan-itinerario ..............................................................................115 6.2.2 Modelación de reglas para la recomendación de ítems turísticos........................116 6.2.3 Modelación de casos para la recomendación de itinerarios turísticos ................118 6.2.4 Recomendación de ítems turísticos .......................................................................120 6.2.5 Recomendación de itinerarios turísticos ...............................................................122

6.3 EL SISTEMA SYREC........................................................................................................123 6.3.1 Arquitectura del sistema........................................................................................125 6.3.2 Interfaz de usuario.................................................................................................127 6.3.3 El RBR y la recomendación de ítems turísticos.....................................................137

11

6.3.4 El CBR y la recomendación de un itinerario turístico ..........................................145 6.3.5 Software de desarrollo ..........................................................................................149

6.4 EXPERIMENTACIÓN........................................................................................................149 6.4.1 RECOMENDACIÓN DE ÍTEMS TURÍSTICOS.....................................................................149 6.4.2 RECOMENDACIÓN DE ITINERARIOS TURÍSTICOS..........................................................155 6.5 COMPARATIVA ENTRE NUTKING, @LISTECHNET Y SYREC...........................................160

7. RESULTADOS, CONCLUSIONES Y TRABAJO FUTURO .....................................163

7.1 RESULTADOS.................................................................................................................163 7.2 CONCLUSIONES..............................................................................................................165 7.3 TRABAJO FUTURO..........................................................................................................166

REFERENCIAS ...................................................................................................................167

13

ÍNDICE DE FIGURAS FIGURA 1. DIAGRAMA DE BLOQUES DE LAS FASES DEL DESARROLLO DEL PROYECTO DE TESIS.26 FIGURA 2. DIAGRAMA DE CONSUMO DE LOS PRODUCTOS TURÍSTICOS ANTES DE INTERNET.......30 FIGURA 3. DIAGRAMA DE CONSUMO DE LOS PRODUCTOS TURÍSTICOS DESPUÉS DE INTERNET. ..31 FIGURA 4. ARQUITECTURA DE UN SISTEMA DE PRODUCCIÓN. ....................................................49 FIGURA 5. CICLO DEL RAZONAMIENTO BASADO EN CASOS. .......................................................55 FIGURA 6. ESQUEMA DE DESCOMPOSICIÓN TAREA MÉTODO DEL CBR ......................................57 FIGURA 7. ESPACIOS DE PROBLEMA Y SOLUCIÓN. ......................................................................59 FIGURA 8. GRÁFICA REPRESENTATIVA DE LAS DISTANCIAS DEL VECINO MÁS CERCANO............60 FIGURA 9. EJEMPLO DE UN CASO BAJO LA METODOLOGÍA TRIP@DVICE ....................................75 FIGURA 10. RECOMENDACIÓN DE UN SOLO ÍTEM EN LA METODOLOGÍA TRIP@DVICE ...............76 FIGURA 11. BÚSQUEDA DE INSPIRACIÓN DE LA METODOLOGÍA TRIP@DVICE ............................78 FIGURA 12. INTRODUCCIÓN DE LAS PREFERENCIAS DEL USUARIO EN LA INTERFAZ DE USUARIO

DE NUTKING. ......................................................................................................................82 FIGURA 13. CASO EJEMPLO EN EL SISTEMA NUTKING ................................................................82 FIGURA 14. OPCIONES PARA SELECCIONAR ÍTEMS EN NUTKING. ...............................................83 FIGURA 15. SELECCIÓN DE LUGARES TURÍSTICOS EN LA REGIÓN DE TRENTINO, ITALIA EN

NUTKING............................................................................................................................83 FIGURA 16. RECOMENDACIONES DE ITINERARIOS TURÍSTICOS EN NUTKING ..............................84 FIGURA 17. MANIPULACIÓN DE UN ITINERARIO RECOMENDADO EN NUTKING ...........................85 FIGURA 18. ARQUITECTURA DEL SISTEMA NUTKING..................................................................85 FIGURA 19. INTERFAZ DE USUARIO DEL DEMOSTRADOR @LISTECHNET (A) ..............................90 FIGURA 20. INTERFAZ DE USUARIO DEL DEMOSTRADOR @LISTECHNET (B) ..............................91 FIGURA 21. PLANEACIÓN DE UN ITINERARIO EN @LISTECHNET................................................92 FIGURA 22. ARQUITECTURA DEL SISTEMA DEMOSTRATIVO @LISTECHNET ..............................93 FIGURA 23. NÚCLEO DE RAZONAMIENTO DEL SISTEMA DEMOSTRATIVO @LISTECHNET...........95 FIGURA 24. NIVELES DE DESCOMPOSICIÓN DEL SISTEMA DEMOSTRATIVO @LISTECHNET ........97 FIGURA 25. AGENTES INMERSOS EN LA DESCOMPOSICIÓN DE UN ITINERARIO............................98 FIGURA 26. OBJETIVOS DE LAS REGLAS INMERSAS EN LOS AGENTES.........................................99 FIGURA 27. TIPOS DE REGLAS INMERSAS EN EL AGENTE LPA..................................................100 FIGURA 28. ITINERARIO TURÍSTICO CONFORMADO EN EL SISTEMA DEMOSTRATIVO

@LISTECHNET. ...............................................................................................................101 FIGURA 29. ARQUITECTURA DEL MAS1..................................................................................103 FIGURA 30. ARQUITECTURA DEL PTM ....................................................................................104 FIGURA 31. ARQUITECTURA DEL SISTEMA TRAVELPLAN ........................................................105 FIGURA 32. UN EJEMPLO DE PLAN-ITINERARIO ........................................................................116 FIGURA 33. MAPEO DE LAS PREFERENCIAS..............................................................................118 FIGURA 34. EJEMPLO DE MODELACIÓN DE UN CASO................................................................119 FIGURA 35. RECOMENDACIÓN DE ÍTEMS TURÍSTICOS (A). .......................................................121 FIGURA 36. RECOMENDACIÓN DE ÍTEMS TURÍSTICOS (B). .......................................................122

14

FIGURA 37. RECOMENDACIÓN DE ITINERARIOS TURÍSTICOS. ...................................................123 FIGURA 38. ARQUITECTURA LÓGICA DE SYREC ......................................................................126 FIGURA 39. ARQUITECTURA DE COMPONENTES.......................................................................127 FIGURA 40. ESTRUCTURA JERÁRQUICA DE PREFERENCIAS DEL USUARIO.................................128 FIGURA 41. PREFERENCIAS DE VIAJE EN LA INTERFAZ DE USUARIO.........................................129 FIGURA 42. ESPECIFICACIÓN DEL TIPO DE ALOJAMIENTO. .......................................................129 FIGURA 43. PREFERENCIAS DE ALOJAMIENTO..........................................................................130 FIGURA 44. PREFERENCIAS DE TRANSPORTE Y RESTAURANTES...............................................131 FIGURA 45. PREFERENCIAS DE LUGARES DE INTERÉS...............................................................132 FIGURA 46. PREFERENCIAS DE ACTIVIDADES...........................................................................133 FIGURA 47. ESTRUCTURA DE HORARIOS PARA UN ITINERARIO TURÍSTICO EN SYREC. .............135 FIGURA 48. RECOMENDACIÓN DE ÍTEMS TURÍSTICOS EN SYREC..............................................138 FIGURA 49. INFERENCIA DE SYREC PARA TRANSPORTES..........................................................151 FIGURA 50. RECOMENDACIONES DE ALOJAMIENTO. ................................................................152 FIGURA 51. FILTRADO E INFERENCIA DE ALOJAMIENTOS.........................................................153 FIGURA 52. FILTRADO Y ORDENAMIENTO DE RESTAURANTES. ................................................153 FIGURA 53. FILTRADO Y ORDENAMIENTO DE LUGARES. ..........................................................154 FIGURA 54. FILTRADO Y ORDENAMIENTO DE TIPOS DE ACTIVIDADES. .....................................154 FIGURA 55. ITINERARIO EN PROCESO DE PLANEACIÓN. ............................................................155 FIGURA 56. PREFERENCIAS DE VIAJE.......................................................................................157 FIGURA 57. PREFERENCIAS DE ALOJAMIENTO..........................................................................157 FIGURA 58. RECOMENDACIÓN DE ITINERARIOS. ......................................................................158 FIGURA 59. CASOS PROPUESTOS PARA LA RECOMENDACIÓN DE ITINERARIOS .........................159 FIGURA 60. ITINERARIO SUGERIDO EN MODO EDICIÓN. ............................................................160

15

ÍNDICE DE TABLAS

TABLA 1. ALGORITMOS DE FILTRADO PARA TIPOS DE INFORMACIÓN.........................................39 TABLA 2. COMPARATIVA ENTRE EL RBR Y EL CBR..................................................................65 TABLA 3. COMPARATIVA DE TÉCNICAS DE RAZONAMIENTO......................................................67 TABLA 4. PONDERACIÓN DE PESOS EN LA METODOLOGÍA TRIP@DVICE ....................................80 TABLA 5. COMPARATIVA DE STR COMERCIALES. ...................................................................106 TABLA 6. COMPARATIVA ENTRE LOS DIFERENTES SISTEMAS DESCRITOS EN ESTE CAPÍTULO. ..110 TABLA 7. EJEMPLOS DE REGLAS DE EVALUACIÓN DE FACTORES EXTERNO..............................117 TABLA 8. EJEMPLO DE REGLAS DE FILTRADO...........................................................................117 TABLA 9. EJEMPLOS DE INSTANCIAS INFERIDAS. .....................................................................118 TABLA 10. EJEMPLO DE LA MODELACIÓN DE LAS CARACTERÍSTICAS DISCRIMINANTES DE UN

PLAN-ITINERARIO. ...........................................................................................................134 TABLA 11. EJEMPLO DE MODELACIÓN DE UN CASO EN SYREC ................................................136 TABLA 12. MAPEO...................................................................................................................137 TABLA 13. ENCAPSULAMIENTO DEL GRADO DE PREFERENCIA POR TIPO DE ACTIVIDAD ...........137 TABLA 14. REGLAS DE INFERENCIA PARA TRANSPORTES EN SYREC........................................139 TABLA 15. REGLAS DE FILTRADO PARA LAS INSTANCIAS DE TRANSPORTE EN SYREC. ............140 TABLA 16. REGLAS DE ALOJAMIENTO EN SYREC ....................................................................141 TABLA 17. REGLAS DE RESTAURANTES EN SYREC..................................................................142 TABLA 18. REGLAS DE INFERENCIA DE RESTAURANTES EN SYREC..........................................142 TABLA 19. REGLAS DE LUGARES EN SYREC ............................................................................143 TABLA 20. REGLAS DE ACTIVIDADES EN SYREC......................................................................144 TABLA 21. ESPECIFICACIÓN DE PESOS EN SYREC....................................................................148 TABLA 22. CASO DE PRUEBA PARA LA RECOMENDACIÓN DE ÍTEMS.........................................150 TABLA 23. CASO DE PRUEBA PARA LA RECOMENDACIÓN DE ITINERARIOS...............................156 TABLA 24. COMPARATIVA ENTRE NUTKING, @LISTECHNET Y SYREC...................................161

17

1. INTRODUCCIÓN

1.1 Generalidades

El acceso a la información a través de medios electrónicos es una realidad que demanda avances tecnológicos que faciliten dicha tarea. El Internet es el medio electrónico más utilizado en la actualidad en la búsqueda de información. Sin embargo, éste medio ha sido además una herramienta capaz de transformar la forma de realizar negocios en la sociedad actual. El comercio electrónico es ahora un término empleado normalmente para denominar las transacciones comerciales hechas a través de Internet. El principal factor que ha impulsado la proliferación del comercio electrónico es la comodidad y el bajo costo que representa este medio para la adquisición de productos o servicios.

La industria del turismo es uno de los sectores que han visto en los medios electrónicos – principalmente el Internet – la forma de verter la información de sus ofertas de manera global. El primer sistema de información electrónica en este rubro fue el sistema de reservación para las aerolíneas en la década de los 60s [23]. Hoy en día, los sistemas de información turística representan una de las aplicaciones más importante en el comercio electrónico.

Los sistemas de información turística además de permitir la reserva de los productos y servicios turísticos han proliferado de tal manera que en la actualidad existe una gran cantidad en el mercado electrónico que utiliza como medio al Internet [19, 20, 41, 53]. En la actualidad, existen sistemas de recomendación turística en la Internet que proveen recursos o paquetes de viaje hacia ciertos destinos turísticos, como por ejemplo: expedia.com, travelocity.com, priceline.com, y eurovacations.com. Todos estos sitios orientan al usuario a buscar recursos de viaje (transportes, alojamientos y paquetes) en los

18

catálogos de ofertas ya sea con base en sus preferencias o bien, de manera libre. Para aquellos usuarios que únicamente necesitan recursos aislados, estos sitios pueden ser de gran utilidad. Sin embargo, para realizar la planeación de un itinerario de viaje (conjunto ordenado de recursos turísticos) existen factores que pueden incrementar el tiempo para obtener un itinerario al gusto del usuario, estos factores pueden ser: buscar recurso por recurso, verificar los horarios disponibles, adaptar cada recurso al presupuesto, etc.

El modelado de un sistema de recomendación debe capturar las preferencias del usuario y ser capaz de realizar procesos de inferencia para buscar y proveer las mejores opciones que se adapten a dichas preferencias. Actualmente, existen sistemas de recomendación turística no-comerciales [16, 47] provistos por el mecanismo de razonamiento basado en casos: CBR (Case-Based Reasoning) y por el mecanismo de razonamiento basado en reglas: RBR (Rule-Based Reasoning) que recomiendan tanto ítems como itinerarios turísticos [4].

En los sistemas que implementan el CBR, se enfocan principalmente en la recomendación de ítems e itinerarios turísticos basados en la experiencia del sistema y en la retroalimentación de los usuarios. Básicamente, se utiliza un proceso de búsqueda y reutilización de lo previamente aprendido por el sistema. Por otra parte los sistemas que implementan el RBR, evalúan las preferencias del usuario para recomendar tanto los ítems como los itinerarios turísticos.

Los sistemas multiagentes (MAS – MultiAgent Systems) por su parte han servido como paradigma de sistemas de recomendación turística por la propiedad que tienen estos sistemas de trabajar en ambientes distribuidos. Su principal característica es la definición de roles y tareas de sus entidades distribuyendo así una tarea compleja [57]. Cada entidad del sistema (agente) tiene la capacidad de percibir su ambiente y actuar de manera autónoma. Los sistemas de recomendación turística que se basan en este paradigma para su desarrollo asumen que las fuentes de información se encuentran dispersas geográficamente y que nuevas fuentes de información pueden ser introducidas al sistema a través de agentes encargados de registrar sus servicios para poder ser accedidos. Un sistema de recomendación turística basado en un MAS también puede implementar mecanismos de razonamiento como el CBR o RBR para mejorar el proceso de recomendación. Tal es el caso del sistema demostrativo del proyecto @lisTechNet [2, 4], el cual es un MAS provisto del RBR para la planeación de un itinerario turístico.

En el dominio del problema de la planeación de un itinerario de viaje, no solamente se identifica la necesidad de dotar al sistema de un mecanismo de razonamiento sino que además el proceso de búsqueda en un cierto ámbito de recursos de viaje evite ser lento. La libertad con la que el usuario pueda seleccionar o rechazar recursos, así como una interfaz que le permita realizar cambios de manera transparente es determinante para obtener una calificación satisfactoria por parte del usuario.

En este trabajo de tesis, se presenta un sistema híbrido de recomendación turística llamado SyRec que combina el razonamiento basado en casos (CBR) y el razonamiento

19

basado en reglas (RBR). Se propone una metodología como guía para el desarrollo de un sistema de recomendación híbrido, así como una arquitectura siendo ambas las principales aportaciones de este trabajo. Además se presenta el análisis del comportamiento del sistema, así como una comparativa con otros sistemas similares. Es necesario señalar que este trabajo de tesis se encuentra inmerso dentro del proyecto @lisTechNet [3], y se origina como una derivación del enfoque propuesto para el desarrollo de un sistema de recomendación turística concretado en la aplicación demostrativa del mismo proyecto.

1.2 Proyecto @lis-TechNet

Este trabajo de tesis es una contribución por parte de la cátedra de Ambientes Virtuales del Instituto Tecnológico y de Estudios Superiores de Monterrey (ITESM), Campus Estado de México; para el proyecto @lisTechnet. Los objetivos y tareas de este proyecto serán descritos en los siguientes párrafos, así como la participación del ITESM en éste proyecto.

1.2.1 Programa @lis

El programa de cooperación @lis (Alliance for the Information Society) - Alianza

para la Sociedad de la Información – nace del dialogo político establecido en junio de1999, en Río de Janeiro, entre los jefes de estado y de gobierno de la Unión Europea y de América Latina. Mediante @lis, la Comisión Europea aspira extender las ventajas de la Sociedad de la Información al conjunto de ciudadanos de América Latina, reduciendo así la brecha digital que divide a los que disponen de acceso a las nuevas tecnologías de la información, de aquellos excluidos de ellas. @lis fue creado por decisión de la Comisión Europea el 6 de diciembre de 2001[1].

Los objetivos del programa @lis son los siguientes [1]:

• Estimular la cooperación entre los socios europeos y los socios latinoamericanos;

• Responder a las necesidades de las colectividades locales y los ciudadanos con vistas a un desarrollo sostenible;

• Fomentar el diálogo entre todos los protagonistas y usuarios de la sociedad de la

información;

• Acrecentar la capacidad de interconexión entre comunidades de investigadores de las dos regiones;

20

• Poner en práctica aplicaciones derivadas de los proyectos de demostración.

@lis consta de cinco líneas de acción que corresponden a otros tantos proyectos a realizar entre 2002 y 2005. Cada uno de estos proyectos contribuirá a acercar a los agentes y usuarios de las dos regiones y a favorecer la integración de los países latinoamericanos en la sociedad de la información global.

• Un primer capítulo titulado “Diálogo político y reglamentación” tiene por objeto reforzar la integración regional y subregional en América Latina y consolidar las relaciones entre las dos regiones fomentando el diálogo en cuanto a políticas, reglamentación y la e-gobierno (buena gestión por medios electrónicos).

• Un segundo capítulo se propone favorecer una mejor integración de los países

latinoamericanos en la sociedad de la información global fomentando normas globales y abiertas y alentando las colaboraciones en materia tecnológica.

• Un tercer capítulo intensificará la interconexión del colectivo europeo y

latinoamericano de investigadores gracias a la instalación de una red informática de alta velocidad.

• Además se han constituido dos asociaciones birregionales entre redes de

intermediarios y usuarios. La primera procurará estimular la transferencia de conocimientos técnicos entre regiones gracias, en particular, a la creación de comunidades virtuales, a la organización de conferencias anuales o también al desarrollo de hermanamientos a través de Internet. La segunda será una plataforma de apoyo y de intercambio entre organismos reguladores de las telecomunicaciones de América Latina.

• En paralelo a estas acciones, permitirán realizar aproximadamente veinte proyectos

de demostración distribuidos en cuatro ámbitos temáticos que son la gobernanza local, la educación y la diversidad cultural, la salud pública y la inserción social.

El programa @lis tiene por objeto contribuir a la elaboración y aplicación de un

enfoque regional de e-Estrategias (estrategias electrónicas) a cargo de los socios latinoamericanos y reforzar sus capacidades políticas y de reglamentación. La acción que acompañará a la transformación hacia la sociedad de la información se realizará en dos frentes: a nivel regional y a nivel nacional o subregional. Cada una de las partes incluirá foros de debate político, talleres, redes, intercambios de información, programas de formación y estudios específicos que abordarán las cuestiones más convenientes. Estas actividades se desarrollarán a lo largo de 36 meses [1].

@lis se propone llevar a cabo unos veinte proyectos de demostración en América Latina que ilustren al ciudadano sobre las ventajas que pueden derivarse de la sociedad de la información en distintos ámbitos temáticos.

21

Los cuatro ámbitos son los siguientes [1]:

• la gobierno local; • la educación y la diversidad cultural; • la salud pública; • la inserción social (o e-inclusión).

1.2.2 Proyecto @lis TechNET

Dentro de los proyectos aprobados por el programa @lis dentro del ámbito de la

educación diversidad cultural, se encuentra el proyecto: @lis TechNET (Advanced Technology Demonstration Network for Education and Cultural Applications in Europe and Latin America). Siendo el solicitante del proyecto la Universidad Politécnica de Catalunya, España. El proyecto @lis TechNet está diseñado para crear un entorno innovador de experimentación y enseñanza en Europa y América Latina. Las funcionalidades del entorno permitirán la conexión continua de todos los socios del consorcio en una red conformada de componentes de software autónomos y capaces de interactuar de forma dinámica entre ellos para proveer servicios a los usuarios [3].

Los socios que componen al proyecto @lis TechNET son los siguientes:

Europa • Universidad Politécnica de Catalunya (España). • University of Bath (Gran Bretaña). • Università degli Studi di Parma (Italia).

Latinoamérica • Instituto Superior Politécnico José Antonio Echeverría (Cuba). • Universidad de Costa Rica (Costa Rica). • Universidad Tecnológica Metropolitana (Chile). • Instituto Politécnico Nacional (México). • Instituto Tecnológico y de Estudios Superiores de Monterrey, Campus Estado de

México (México).

Este proyecto tiene como base de desarrollo la plataforma experimental Agentcities para utilizar las más modernas tecnologías de agentes autónomos, Web Internet. Entre los resultados más importantes se espera obtener los siguientes [3]:

• Disponer de una infraestructura tecnológica de agentes autónomos, Web Internet

– basada en Agentcities—que conecte Chile, Costa Rica, Cuba, México, España, Italia e Inglaterra así como otras partes del mundo que permita que cualquier tipo de software incluido por cualquier socio sea capaz de comunicarse y ser usado por otras piezas incluidas por otros socios.

22

• Disponer de un entorno virtual de enseñanza extendiendo la infraestructura que

permita a estudiantes, profesionales de la educación e investigadores a adquirir experiencia al trabajar con tecnologías de punta en las áreas de los agentes autónomos, Web Internet para crear aplicaciones complejas, dinámicas y disponibles en línea.

• Disponer de un demostrador capaz de crear servicios personalizados de carácter

cultural o turístico que sean accesibles en línea desde un PC y/o dispositivos inalámbricos (teléfonos móviles, PDAs con servicio de roaming u otros dispositivos) a través de la composición dinámica de los servicios instalados por los distintos socios en los diferentes países de los socios del consorcio.

Ahora bien, dentro de los resultados esperados, se pueden concentrar en tres ámbitos: despliegue, creación y demostración, cada uno de los cuales han especificados algunas tareas como lo son [3]:

• Despliegue o Una plataforma de prueba funcionando 24/7 y que integre tecnologías de

agentes, web services y redes semánticas, ligando a todos los participantes del proyecto y que permita conexiones de otros participantes.

o Permitir a cada participante la creación y despliegue de servicios basados en agentes que puedan comunicarse con la red y con servicios desarrollados por terceros.

• Creación

o Un ambiente de educación que incluya tutoriales, ejemplos de código, modelos de ejercicios y soporte en línea para estudiantes de modo que puedan experimentar el desarrollo y despliegue de aplicaciones basadas en agentes, web services y redes semánticas.

o Organizar un conjunto de clases distribuidas que permitan a los estudiantes de diferentes universidades desarrollar sistemas que puedan comunicarse con aquellos desarrollados por cualquier otro estudiante.

• Demostración

o Una aplicación innovadora de turismo/herencia cultural usando la plataforma de prueba que es capaz de integrar dinámicamente datos de turismo/culturales de diferentes países de modo que se facilite al usuario la planeación de viajes y actividades.

o Hacer que la aplicación sea accesible utilizando tecnologías de red inalámbricas y alámbricas.

La plataforma experimental, o bien de prueba, sugerida por @lis es Agentcities, la

cual es una ciudad virtual que esta conformada por usuarios, agentes y servicios. Sus objetivos principales son [3, 9]:

23

• Crear y proveer un ambiente a gran escala, abierto y heterogéneo de entidades autónomas (agentes) y permitir a estas entidades interactuar unas con otras. Por lo que el ambiente debe ser público y abierto a cualquier agente.

• Actuar como una plataforma experimental y de pruebas de interoperatividad para

agentes.

• Permitir la composición dinámica, inteligente y autónoma de servicios, para satisfacer las distintas necesidades comerciales, así como las de los posibles usuarios.

1.3 Descripción del problema

La industria del turismo ha utilizado al comercio electrónico fundamentalmente para ofertar sus productos y servicios, dado que la información que describe a estos recursos turísticos es el fundamento de su oferta y demanda y el medio propicio para esto ha sido Internet.

Debido a que en la actualidad, el principal problema al que se enfrentan los consumidores es la gran dimensión que tiene el volumen de la información turística, lo que ha derivado en la necesidad de filtrar todo ese volumen de información con base en parámetros como las preferencias del consumidor. Hoy en día, las necesidades de los consumidores han evolucionado por lo que ya no es suficiente proveerles recursos turísticos de acorde a sus necesidades sino que han buscado también que se les provea de paquetes o itinerarios turísticos de manera personalizada ocasionando un problema complejo de planeación turística aunado a un problema de satisfacción de las necesidades de los consumidores.

Los sistemas de recomendación turística han solucionado estos problemas utilizando mecanismos de razonamiento, como el razonamiento basado en reglas y el razonamiento basado en casos, dentro del área de la inteligencia artificial para filtrar y recomendar soluciones que concuerden con las necesidades o deseos del usuario.

El mecanismo de razonamiento basado en casos (CBR) explota la experiencia en solucionar problemas utilizando precedentes. El mecanismo de razonamiento basado en reglas (RBR) explota la representación del conocimiento a través de reglas que evalúan hechos, para llegar a una solución o conclusión. El uso de un único mecanismo de razonamiento lo hace iterativo tanto para la recomendación de ítems como de itinerarios turísticos. En el caso del CBR la definición de métricas y en el caso del RBR la producción de reglas, se vuelven procesos complejos.

24

El problema abordado en este trabajo de tesis es la integración de los mecanismos RBR y CBR, en el desarrollo de un sistema de recomendación turística que sea capaz de proveer recomendaciones de recursos e itinerarios turísticos de manera personalizada.

1.4 Objetivos

Los objetivos generales en este trabajo de tesis son los siguientes:

1. Establecer un enfoque general en sistemas híbridos de recomendación integrando explotando las fortalezas del RBR y del CBR, ya que hasta la fecha no se ha establecido.

2. Proveer una metodología para el desarrollo de un sistema híbrido de recomendación

turística que integre RBR y CBR. 3. Proveer un sistema híbrido de recomendación turística que integre el RBR y el CBR

que sea capaz de proveer recomendaciones de recursos e itinerarios turísticos de manera personalizada.

Los objetivos particulares de este trabajo de tesis son:

1. Identificar las necesidades actuales en el ámbito de los sistemas de recomendación turística.

2. Analizar y comparar los trabajos relacionados.

3. Analizar las técnicas y métodos del RBR y CBR para identificar sus fortalezas.

4. Establecer el dominio de aplicación del RBR y CBR en el proceso de

recomendación turística.

5. Proponer una metodología simplificada para el desarrollo de un sistema híbrido de recomendación turística que integre los mecanismos de razonamiento RBR y CBR.

6. La metodología debe abordar los principales modelos del RBR y CBR los cuales

son la producción de reglas y los casos de manera respectiva.

7. Desarrollar un prototipo basado en la metodología propuesta que demuestre las fortalezas e integración del RBR y CBR en los procesos de recomendación.

25

1.5 Justificación

En este trabajo de tesis, se tienen los siguientes puntos que constituyen la justificación de este trabajo:

• El sector turismo es quizás el principal sector de servicios en el que cualquier país que ofrece oportunidades concretas y cuantificadas a cualquier país del mundo sin importar el grado de desarrollo y representa en mucho de los casos la primer fuente de ingresos económicos. Por lo que es importante proveer una metodología para dar a conocer una forma de desarrollo de sistemas de recomendación turística como un medio para dar a conocer los recursos turísticos de un país.

• Satisfacer la necesidad de los turistas de encontrar un sistema de recomendación que

les permita realizar la planeación personalizada de un itinerario turístico organizado en el tiempo sin tener que adaptarse a los itinerarios previamente establecidos.

1.6 Hipótesis

• Un sistema híbrido de recomendación turística – híbrido en el sentido de combinar tanto el RBR como el CBR – simplifica las tareas de filtración, ordenamiento, inferencia y recomendar recursos o ítems turísticos sin que el costo del proceso sea mayor que su beneficio.

• El RBR simplifica la recomendación de ítems turísticos a través de la filtración,

ordenamiento e inferencia de ítems turísticos en lugar del CBR, a través de la producción de reglas. Ya que en el CBR se tiene que recurrir a su ciclo de razonamiento para establecer todas estas tareas, además del establecimiento de métricas de similaridad.

• El CBR simplifica el proceso de recomendación de itinerario turístico. Un itinerario

turístico es una estructura compleja en donde se encuentran las preferencias del usuario y un conjunto de recursos turísticos ordenados. Entonces con base en la propiedad del CBR de manejar características complejas de un problema, en esta caso un itinerario turístico, se puede explotar sus métodos para encontrar y recomendar itinerarios similares que son justificados por precedentes para un usuario en particular.

26

1.7 Alcances y limitaciones

• La metodología propuesta para el desarrollo de sistemas híbridos de recomendación turística basados en CBR y RBR

• El sistema desarrollado SyRec es un prototipo demostrativo de la metodología

propuesta y por lo tanto no debe ser considerado como un producto final.

• Las métricas aplicadas al sistema SyRec tienen el objetivo de analizar la funcionalidad y coherencia de las recomendaciones generadas bajo casos específicos de prueba. El uso de métricas robustas representa un costo en recursos y tiempo para la realización de este trabajo y son consideradas como trabajo futuro.

1.8 Metodología

La metodología considerada para el desarrollo de este trabajo de tesis comprende las siguientes fases:

Figura 1. Diagrama de bloques de las fases del desarrollo del proyecto de tesis

• Fase 1. Inicio del proyecto de Tesis. Se identifica el problema existente en el

desarrollo de sistemas de recomendación dentro del proyecto @lisTechNet.

27

Posteriormente se recupera la información para analizar los sistemas de recomendación actuales e identificar las necesidades actuales de los consumidores de productos y servicios turísticos.

• Fase 2. Definición y desarrollo de la propuesta. En esta fase se analizan e

identifican las características de los sistemas de recomendación. Se establece que prototipos experimentales han utilizado el razonamiento basado en casos para resolver el problema de la recomendación de itinerarios turísticos. A razón del proyecto @lisTechNet el cual ha generado un sistema de planeación y recomendación turística basado en RBR se origina el problema de integrar las principales características de ambos tipos de razonamiento.

Finalmente, se identifica la metodología Trip@dvice para el desarrollo de sistemas de recomendación turística basados en CBR. Posteriormente, se establecen los criterios para proveer una metodología híbrida. La fase de requerimientos del sistema se establece para producir un prototipo demostrativo llamado SyRec, para la recomendación de ítems e itinerarios turísticos. La etapa de diseño se basa en la metodología propuesta que posteriormente da origen a la implementación del sistema.

• Fase 3: Finalización del proyecto. En esta última fase se realizan pruebas al

sistema Syrec para verificar la coherencia de la recomendación de ítems e itinerarios turísticos implementados con base en la metodología.

1.9 Organización del documento

Este documento esta organizado en ocho capítulos y un anexo. En este capítulo se ha dado una introducción al trabajo realizado, se establece el problema abordado, así como los objetivos, alcances y limitaciones, así como la metodología del propio trabajo.

En el capítulo 2, se establece el origen de los sistemas de recomendación turística. La primera sección de este capítulo se enmarca la problemática y retos del turismo y comercio electrónico. En la segunda sección, se define a los sistemas de recomendación, se describen la taxonomía y características de éstos sistemas y se presentan las principales métricas de evaluación de un sistema de recomendación. Finalmente, se describen a los sistemas de recomendación turística.

En el capítulo 3, se describe al razonamiento basado en reglas. La primera sección se define a un sistema de producción, ya que éste tipo de sistema constituye el fundamento del razonamiento basado en reglas. En la segunda sección se describe la producción de reglas, memoria de trabajo y la unidad de control respectivamente; todos estos elementos constituyen un sistema de producción. En la tercera sección se describen las principales

28

propiedades de un sistema de producción. En la cuarta sección, se define la taxonomía de los sistemas de producción.

En el capítulo 4, se describe al razonamiento basado en casos. En la primera sección se presentan las motivaciones y antecedentes de este tipo de razonamiento. En la segunda sección se describe y define el ciclo del CBR. En la tercera sección se describen los métodos o técnicas utilizadas en el ciclo del CBR. En la cuarta sección, se presenta una comparativa de los mecanismos de razonamiento contra otras técnicas o mecanismos de razonamiento para analizar sus propiedades y dominios de aplicación. En la quinta sección se describen las principales aplicaciones del CBR.

En el capítulo 5, se presentan los trabajos relacionados con los sistemas de recomendación turística. En la primera sección, se describe la principal metodología de desarrollo para los sistemas de recomendación turística basados en CBR y el análisis del prototipo desarrollado con base en dicha metodología. En la segunda sección se describe y analiza el sistema de recomendación turística del proyecto @lisTechNet. En la tercera sección, se describen y analizan brevemente otros sistemas de recomendación turísticos basados en sistemas multiagente, sistemas comerciales y sistemas fuera del ámbito del turismo que han combinado tanto al RBR como al CBR. En la cuarta sección se presenta un análisis comparativo de los sistemas contemplados en éste capítulo.

En el capítulo 6, se describe la metodología propuesta para el desarrollo de un sistema de recomendación híbrido que integra el RBR y el CBR para establecer las tareas de recomendación de ítems e itinerarios turísticos. En la primera sección, se identifican los principales problemas de los sistemas de recomendación turística en la actualidad .En la segunda sección, se describe la metodología, abordando la modelación de las reglas y casos para la recomendación de ítems e itinerarios turísticos. En la tercera sección, se describe al sistema SyRec describiendo su arquitectura desde el punto de vista lógico y de componentes. En la cuarta sección, se describen los principales casos de prueba realizados a SyRec en donde se verifica la coherencia de las recomendaciones sugeridas.

En el capítulo 7, se presenta de manera general los resultados, conclusiones y el trabajo futuro soportado por este trabajo de tesis.

29

2. Sistemas de recomendación turística

La industria del turismo fue una de las primeras en utilizar el comercio electrónico, a través de Internet, para difundir sus productos y servicios; con la aparición de los sistemas de reservación en línea [35]. Aunque en un principio los sistemas de reservación fueron acogidos por las empresas de aerolíneas, actualmente son concebidos como sistemas de información turística y no solamente son una herramienta de reserva y contratación de un único servicio sino que ahora se incluyen: alojamientos, medios de transportes, restaurantes, paquetes turísticos, etc.

Los sistemas de información turística ahora han tratado de evolucionar hacia un

sistema de recomendación turística incluyendo inherentemente la reservación de los productos y servicios turísticos y dotando de resultados personalizados. La razón principal de esta evolución es la gran cantidad de proveedores turísticos que han diseminado la información de sus ofertas a través del mercado electrónico. Por lo que es necesario un sistema que englobe y filtre de alguna manera dicha información de acuerdo a criterios establecidos por el usuario, resultando así los sistemas de recomendación turística.

2.1 El comercio electrónico y el turismo: problemática y retos

Dentro del comercio electrónico se pueden encontrar diferentes tipos de relaciones de negocio, como lo son [34]:

30

a) Business-to-Business (B2B): definen transacciones entre empresas. b) Business-to-Consumers (B2C): definen transacciones entre empresas y

consumidores finales. c) Consumers-to-Consumers (C2C): definen transacciones entre consumidores

finales.

La industria del turismo se encuentra clasificada como B2C y es el principal motor de éste tipo de comercio electrónico tanto en Estados Unidos como en Europa [34].

Los productos y servicios turísticos tienen una característica particularmente

importante que los coloca en un primer plano del comercio electrónico: la información es el fundamento de su oferta y consumo. Ésta característica se debe a la propiedad de intangibilidad que tienen en si mismos los productos y servicios turísticos.

Por lo tanto, el principal problema de esta propiedad es que tiene un producto o

servicio basado en la confianza. Entonces hasta que se consume el producto, el consumidor debe tener plena confianza en la calidad de la información con la que se describió el producto o servicio, asumiendo así que cumplirá con sus expectativas. De tal modo que cualquier proveedor turístico que no utilice las tecnologías de comunicación de la información como es el caso del comercio electrónico esta destinado a desaparecer.

Debido al hecho de que la difusión de la información de los productos turísticos es

la parte fundamental en este sector, el medio eficaz para realizar esta diseminación ha sido hasta el momento Internet siendo éste la base del comercio electrónico [29]. La apertura del mercado de productos y servicios turísticos se le debe a Internet, que permite llegar a millones de clientes potenciales. Antes de la aparición del Internet, se tenía una estructura descentralizada en el consumo de los productos turísticos como se muestra en la figura 2.

Figura 2. Diagrama de consumo de los productos turísticos antes de Internet.

Tan pronto como el Internet aparece, como se puede apreciar en la figura 3, los

intermediarios tienden a convertirse en infomediarios, los cuales no desaparecen pero ven minimizadas las consultas y transacciones que antes tenían totalmente a su cargo. Es necesario señalar que el comercio electrónico en el sector turismo ha disminuido significativamente el costo de los productos turísticos [34, 35].

31

Figura 3. Diagrama de consumo de los productos turísticos después de Internet.

Más que cualquier otro medio, hoy en día Internet permite encontrar cualquier tipo

de información sobre cualquier actividad o destino turístico. Sin embargo, al existir una gran cantidad de información es necesario clasificarla y presentarla al consumidor de tal manera que le sea cómodo identificar la información de su interés.

Los sistemas de información turística surgen, aunados a la necesidad de difundir la

información de los productos y servicios turísticos de manera electrónica, con la finalidad de presentar ordenada y detalladamente la información, además de establecer un contacto directo con el consumidor. Las principales características que definen a los sistemas de información turística son: la calidad de la información presentada y la calidad de acceso.

La calidad de contenido provee de comprensión, precisión, consistencia y temática a

la información presentada. La calidad de acceso esta orientada a desarrollar aplicaciones electrónicas que puedan ser accedidas a través de cualquier medio electrónico, en cualquier momento y desde cualquier sitio. Aunque, esto puede ser acotado a medios electrónicos con soporte de Internet. De esta manera, los servicios ofrecidos pueden ser independientes de dispositivos, localización del usuario y personalizados.

Los sistemas de información turística se han venido desarrollando como

aplicaciones web en donde se incluye información y material visual acerca de los productos turísticos ofertados. Este tipo de sistemas en línea se les ha denominado con el nombre de “portales” y representan puntos centrales de acceso que contienen la información de productos y servicios turísticos de una cierta región geográfica que incluso puede ser un país [23].

El turista en la actualidad también demanda los beneficios que el Internet ha traído

consigo. La interactividad, característica soportada en Internet, permite al turista un rol más activo en la selección de productos turísticos. Básicamente, los usuarios eligen su destino

32

turístico, así como los servicios que necesitan comparando las ofertas disponibles. Puesto que cada turista tiene un estilo de vida particular e intereses específicos es necesario proveer productos que se adapten a sus preferencias.

A fin de satisfacer a los turistas en sus necesidades y deseos, los cuales pueden tener

una compleja estructura multi-nivel con un cierto grado de flexibilidad, las ofertas proporcionadas deben ser multi-opcional y de alta calidad [13].

La proliferación de los sistemas de información turística ha permitido introducir al

usuario a un escenario interactivo y con un rol activo en la selección y comparación de productos turísticos. Además de permitir incluso la planeación detallada de un itinerario turístico. Sin embargo, el proceso de búsqueda de información y planeación turística es dinámico y complejo. No obstante, se han convertido en medios de soporte para la toma de decisiones [13, 34].

2.2 La toma de decisión en la planeación de viajes turísticos

Un gran número de investigadores se han dado a la tarea de desarrollar teorías o bien a definir conceptos acerca de la influencia de la toma de decisiones en el ámbito turístico [29]. Sin embargo, estas teorías han estado limitadas en la discusión de los componentes de la toma de decisión.

Una topología que define las influencias en el proceso de toma de decisión además

de englobar características determinantes, se divide en tres categorías [29]:

a) Inter-personal: se basa en la influencia social que involucran la interacción de personas o grupos sociales las cuales pueden modificar las características psicológicas y comportamientos de un individuo.

b) Intra-personal: se basa en la influencia de los aspectos individuales característicos,

v. gr. Estilo de vida, intereses y gustos personales, etc.

c) Cicunstancial: se basa en la influencia externa no-social v.gr. objetos, agentes, factores ambientales, etc.

Ahora bien, la planeación de un viaje turístico es un proceso multifacético que

consiste en la elección de un destino (o conjunto de destinos) y de productos y servicios turísticos asociados [44].

El manejo conceptual en el proceso de toma de decisión en la planeación de un viaje

turístico trae consigo retos de diseño para la utilización y efectividad del sistema turístico. Puede ser el caso de que para un turista el concepto destino pueda ser un país y para otro

33

sea una ciudad. Entonces se dice que los términos “destino” y “planeación” son conceptos difusos que carecen de una definición universal.

Dado que la planeación de un viaje turístico puede variar en cuanto a su estructura y

contenido pueden utilizarse diferentes estrategias para su construcción. Mientras que existen usuarios que prefieren obtener paquetes turísticos, hay otros más que desean seleccionar componente a componente turístico e incluso hay quienes desean un paquete turístico y modificar algunos componentes.

El proceso de toma de decisión no solamente se enfoca en ayudar al usuario a

seleccionar productos turísticos sino que también esta inmerso en el sistema de información turística. Dado que el sistema debe tener la capacidad de poder inferir o predecir los resultados que mejor se adapten a las preferencias del usuario tomando en cuenta los diferentes tipos de influencias mencionadas anteriormente. En general, un sistema de información turística que tenga la capacidad de clasificar, ordenar e inferir información puede denominarse como un sistema de recomendación turística.

2.3 Sistemas de recomendación

Los sistemas de recomendación han proliferado en el interés del público durante la última década y se han convertido en una gran oportunidad de negocio en el comercio electrónico [13, 44]. Algunas empresas en éste rubro, han implantado diferentes tipos de sistemas de recomendación como lo son: BookPool.com (libros), Amazon.com (multiples artículos) y vacations-explorer (turismo). En el ámbito del turismo, las recomendaciones se han convertido en un medio para la selección y planeación de recursos turísticos (alojamientos, transportes, etc.) de manera significativa.

Un sistema de recomendación tiene por objetivo ayudar al usuario en la toma de decisiones cuando no existe la suficiente experiencia personal en un cierto tópico o ámbito de interés; además de optimizar la compensación de la relación costo-beneficio.

Algunos factores que un sistema de recomendación toma en cuenta para la

simplificación de la toma de decisiones pueden ser: simplificar el proceso de búsqueda y comparación de productos, reportar reseñas de otros usuarios o incluso explotar un historial de experiencias pasadas de otros usuarios para sugerir productos.

Un sistema de recomendación es un intento de modelar matemáticamente y reproducir técnicamente el proceso de recomendación en el mundo real [13]. En estos sistemas se aplican técnicas de recomendación que están basadas en el supuesto que las preferencias y necesidades del usuario puedan ser mapeadas a selecciones determinadas de productos, empleando algoritmos apropiados y explotando el conocimiento embebido en el

34

sistema. Por lo tanto es necesario identificar las preferencias del usuario así como la valoración que el usuario determine para cada una.

2.3.1 La recuperación de información preferencial

Para generar recomendaciones personalizadas es necesario entonces recuperar las

preferencias del usuario, dichas preferencias dependerán del ámbito del problema. Para cada una de las preferencias se debe reflejar el grado de interés o necesidad del usuario, a lo que se le llama rating (valoración o tasación) de la preferencia. Existen dos tipos principales de rating [58]:

a. Explicitas. El usuario especifica su preferencia hacia un ítem en particular indicando el grado de interés o necesidad en una escala determinada, por ejemplo: escala de 5 puntos, escala semántica, etc. Las escalas son mapeadas a valores numéricos que indican el grado de preferencia.

b. Implícitas. Los usuarios frecuentemente tienden a dirigir la carga de sus

preferencias al sistema y confiarle la generación de un resultado. Sin embargo, recuperar información acerca de las propias preferencias del usuario puede ayudar a obtener mayor información en el contexto de las necesidades del usuario y generar un resultado optimizado. Mientras más fácil sea de recuperar la información implícita de las preferencias del usuario, el rating implícito reflejará implicaciones discriminantes.

Debido a la dificultad que muchas veces representa adquirir ratings explícitos, se

pueden adoptar ambos enfoques de manera suplementaria.

2.3.2 Tipos de sistemas de recomendación

Hasta ahora se tienen cuatro diferentes enfoques acerca de los sistemas de

recomendación. Cada uno de estos enfoques no solo difiere en las técnicas o métodos empleados sino que en la interpretación real del algoritmo esencial de recomendación. De acuerdo al objetivo de la aplicación del sistema de recomendación se puede optar por alguno de los siguientes enfoques [13, 44, 58]: Basados en Contenido

También llamado filtrado cognitivo. En este tipo de sistemas el usuario expresa sus preferencias hacia un conjunto definido de productos. Por lo que el sistema recupera de un catalogo de ítems, aquellos que comparten características comunes con los productos que

35

han sido calificados como preferenciales por el usuario. Los resultados son mostrados de acuerdo al grado de concordancia hacia las preferencias del usuario [44]. Filtrado Colaborativo

El sistema almacena las valoraciones de los usuarios hacia productos sugeridos o aceptados, con el objetivo de inferir alguna posible similaridad entre los usuarios. Este enfoque es efectivo en la sugerencia de ítems. Ahora bien, la calidad de la recomendación tiende a mejorar a medida que se vayan acumulando nuevas valoraciones [13, 44]. Por lo tanto, los métodos colaborativos requieren una gran cantidad de valoraciones para producir recomendaciones satisfactorias y no pueden realizar adaptaciones con base en nuevos requerimientos ya que solo se basan en los comportamientos de experiencias pasadas. Filtrado Basado en Conocimiento

Los sistemas dependen de la representación del conocimiento que usualmente son conjuntos de declaraciones, ontologías u otras formas de sistemas basados en reglas [13]. Este tipo de sistemas es apropiado cuando se requiere un alto rendimiento y flexibilidad en aplicaciones que se enfoquen tanto en las semánticas de contenido y social. Además de contemplar a la inferencia y razonamiento como parte del sistema, el enfoque basado en conocimiento permite beneficiarse de las diferentes representaciones del conocimiento. Híbridos

Este tipo de sistemas pueden emerger de cualquier combinación de los enfoques anteriores que generalmente tratan de minimizar las deficiencias de cada enfoque. De hecho, existen diferentes métodos de hibridación como se menciona en [13, 44, 58].

2.3.4 Objetivos de un sistema de recomendación

Es importante entender los objetivos y tareas para las cuales se ha construido un

sistema de recomendación para poder evaluarlo posteriormente. A pesar de enunciar estas tareas, no todas son necesariamente significativas dentro del contexto en el cual se sitúa un sistema de recomendación. Entre las tareas más importantes se encuentran [28]:

a) Encontrar ítems de interés. Esta tarea es el núcleo de cualquier sistema de recomendación. Se trata de encontrar los ítems específicos que van de acuerdo a las preferencias del usuario.

36

b) Encontrar todos los ítems de interés. La mayoría de los sistemas de recomendación solo encuentra algunos ítems de interés. Pero pueden existir casos en los que se desea invertir una mayor cantidad de tiempo para encontrar el mejor ítem; entonces es importante ampliar la cobertura de recomendación de los ítems de interés.

c) Solo búsqueda. Los sistemas de recomendación se evalúan generalmente por que

tan bien ayudan se acercan a lo que el usuario desea. Pero en ocasiones el usuario centra la importancia en: la interfaz, la facilidad de uso y en el nivel y naturaleza de la información provista que en los algoritmos de recomendación.

d) Proveer credibilidad. Un usuario no confiará automáticamente en un sistema de

recomendación. Muchas veces el usuario lo utiliza para darse cuenta si el sistema encuentra las opciones que el desea.

e) Expresar calificaciones. Algunos usuarios no les interesa tanto las reservaciones

sino que les parece más importante contribuir con calificar los productos recomendados y esto puede contribuir a ayudar a otros usuarios a formularse una opinión acerca del producto.

Para poder llevar a cabo la evaluación de los sistemas de recomendación se debe

haber definido cuales son las tareas que el sistema soporta. Una vez que se identifican las tareas, se debe seleccionar el conjunto de datos para el cual se aplicarán los métodos de evaluación.

2.3.5 Evaluación de sistemas de recomendación

La evaluación de los sistemas de recomendación es fundamental para cuantificar el

grado de utilidad de las recomendaciones hechas por un sistema comparadas con el de otro sistema sobre un conjunto definido de usuarios [58]. Las evaluaciones online vs offline

Las evaluaciones online (en línea) son consideradas más representativas ya que están orientadas a determinar la reacción del usuario respecto a los sistemas de recomendación. La cantidad de personas que pueden necesitarse para la evaluación es significativa, además que el tiempo de las evaluaciones pueden superar el tiempo de la realización del proyecto [58]. Se pueden encontrar un conjunto de dimensiones de evaluación que describen las evaluaciones en línea como a continuación se enuncian [28]:

a) Explicita (preguntar) e implícita (observar). La diferencia entre ambas radica en que en la primera se pregunta directamente al usuario acerca de su reacción con

37

respecto al sistema v.gr. una encuesta; la segunda se observa y registra el comportamiento del usuario.

b) Estudios de laboratorio y de campo. Los estudios de laboratorio se enfocan a

investigar problemas específicos (hipótesis bien definidas) bajo condiciones controladas. Los estudios de campo revelan la situación de los usuarios en escenarios reales mostrando los patrones de uso así como problemas o cuestiones que el estudio de laboratorio puede no mostrar.

c) Resultados y procesos. Para cualquier tarea se deben tener métricas apropiadas que

definan cuando un resultado es exitoso. Por lo que la precisión puede ser una métrica fundamental. Los factores de un proceso: el tiempo y el esfuerzo para realizar una tarea deben ser medidos para asegurar que el costo de un resultado exitoso no sobrepase el beneficio.

La evaluación offline (fuera de línea) es aplicable a un conjunto de datos que

contiene ratings y tiene dos principales debilidades [28]:

a) El escaso rating de los datos, lo que representa un limite en la cardinalidad del conjunto de datos que pueda ser evaluado.

b) Limitantes de resultado, esto significa que los resultados están limitados a proveer una evaluación objetiva.

Por lo tanto una evaluación offline no puede ser determinante para calificar sistemas

de recomendación. Conjuntos de datos naturales vs. Sintetizados

Los conjuntos de datos naturales representan tal cual la realidad. Sin embargo, pueden ser difíciles de obtener principalmente por el tiempo que implica. El uso de conjuntos de datos sintetizados facilita la manipulación de la dispersión de los datos y puede ser requerido para un cierto numero de casos pero únicamente debe ser considera como un primer paso en la recuperación de conjuntos de datos. Establecer conclusiones acerca de los conjuntos de datos sintetizados es riesgoso, debido a que los datos pueden comportarse de mejor forma con ciertos algoritmos. Propiedades de los conjuntos de datos

Con la finalidad de establecer que propiedades debe tener un conjunto de datos para que el modelo de tareas pueda ser evaluado, se establecen tres categorías [28]:

• Características de Dominio. Manifiestan la naturaleza del contenido que esta siendo recomendado.

38

• Características inherentes. Reflejan la naturaleza del sistema de recomendación al cual pertenecen

• Características ejemplo. Reflejan la distribución de los datos. Métricas de precisión

Las métricas de precisión evalúan el grado con el que el sistema puede predecir el rating para un ítem específico además de evaluar la efectividad con la que el sistema ayuda al usuario a seleccionar ítems de mayor interés del conjunto de todos los productos [58]. Las métricas de precisión están clasificadas de la siguiente manera [28, 58]:

a) Métricas de precisión predictiva. Es la medida en la que se cuantifica que tan cercanos se encuentran los ratings pronosticados de los que el usuario ha establecido. La métrica más utilizada en este tipo es el error absoluto medio (MAE – mean absolute error) aunque no es apropiada para tareas como: encontrar los ítems de interés. Otras métricas del mismo tipo son: media del error al cuadrado, media de la raíz del error al cuadrado y media normalizada del error absoluto. Las primeras dos elevan al cuadrado el error antes de sumarlo y la última normaliza el error respecto al rango de valores del rating.

b) Métricas de precisión en clasificación y soporte de decisión. Esta métrica esta

orientada a cuantificar la relevancia del conjunto de recomendaciones, en otras palabras esta orientada a medir la frecuencia con la que un sistema de recomendación realiza correcta o incorrectamente la decisión si un ítem puede ser de interés. Las métricas más utilizadas en este tipo son: Precisión y Retiro [28, 58].

o La precisión se define como la proporción de los ítems destacados respecto

del número de ítems seleccionados, en otras palabras representa la probabilidad que un ítem seleccionado sea relevante.

o Retiro se define como la proporción de los ítems destacados con respecto al número total de ítems destacados disponibles.

c) Métricas de precisión en ordenamiento. Mide la habilidad de un algoritmo para

producir el ordenamiento de los ítems que concuerdan con respecto de cómo el usuario podría realizarlo por él mismo. Esta métrica es propicia cuando el dominio del problema presenta valores de preferencias no binarios.

Algo más que precisión

Los sistemas de recomendación no solo deben proveer de precisión sino también de utilidad, a fin de incorporar respuestas ante posibles valores de ratings que exceden el umbral de lo idóneo. Entre las métricas de utilidad se encuentran [28, 58]:

39

a) Métrica de cobertura. Se basa en el porcentaje de elementos del dominio del problema para los cuales las predicciones pueden realizarse.

b) Métricas de novedad y serendipia. Son aquellas métricas que miden la forma en la

que las recomendaciones son abiertas hacia los intereses del usuario en el tiempo.

2.4 Sistemas de recomendación turística

Aún cuando los sistemas de recomendación turística son difíciles de construir, han proliferado en el área de la investigación como en el comercio electrónico. La dificultad radica en considerar el amplio grado de heterogeneidad de la información disponible en el ámbito del turismo además de las propias dificultadas que implica el proceso de toma de decisión orientado a la planeación de un itinerario turístico.

En el ámbito del turismo, los atributos de las entidades turísticas son esenciales para el desarrollo de un sistema de recomendación turística (preferencias del usuario, destino, alojamientos, restaurantes, actividades, etc) [13]:

a) Información espacio-temporal b) Costo y aspectos económicos de los ítems c) Archivos multimedia (texto, imágenes, audio y video) d) Clasificación de la información e) Modelos ontológicos de las propiedades especificas del objeto (bases de datos,

ontologías, etc).

Con base en estas consideraciones acerca de los tipos de datos e información, se pueden describir enfoques iniciales acerca de las técnicas que son apropiadas para un cierto tipo de información, como se describe en la siguiente tabla [13]:

Tipo de Información Técnica de filtrado Espacio-temporal Selección en la base de datos, filtrado y razonamiento

basado en conocimiento Económica Selección en la base de datos, filtrado y razonamiento

basado en conocimiento Clasificación Multimedia

Filtrado basado en contenido y modelos ontológicos

Modelos ontológicos Diseño y selección en la base de datos, Construcción y razonamiento ontológico

Usuarios Filtrado colaborativo

Tabla 1. Algoritmos de filtrado para tipos de información.

40

Existen diferentes enfoques establecidos en [13] para abordar el problema de la

recomendación en los sistemas de recomendación turística, tomando como base se deben los aspectos de los objetos del mundo real – anteriormente mencionados – que son importantes para un sistema de recomendación turística, se enuncian a continuación:

• Diseño y selección en la base de datos. La selección de ítems en una petición (query) puede ser un primer paso para el filtrado de los datos y reducción de ítems. Aunque, no representa un método flexible y óptimo si se agregan más condiciones en la petición, en algunos casos implica un constante acceso a la base de datos.

• Modelos ontológicos. Para proyectos de gran magnitud, las ontologías proveen un

medio eficiente de representación y almacenamiento de objetos y proveen una base para el razonamiento. No obstante, el desarrollo de un modelo ontológico requiere de un gran esfuerzo en comparación con el diseño de una base de datos.

• Filtrado y razonamiento basado en conocimiento. Esta técnica permite incorporar el

conocimiento dentro de un dominio y es un medio eficaz para incrementar el rendimiento del sistema de recomendación sin la necesidad de recurrir a algoritmos sumamente más complejos. El razonamiento basado en reglas (RBR), así como el razonamiento basado en casos (CBR) representan un enfoque plausible en la construcción de sistemas de recomendación. Por un lado, el razonamiento basado en reglas, dependiendo del número de éstas y de la complejidad de la lógica establecida, el proceso de construcción de reglas puede ser simple o complejo. Las reglas pueden incorporar la clasificación, ordenamiento e inferencia de ítems de manera dinámica. Por el otro, el razonamiento basado en casos, explota la capacidad de encontrar ítems similares aprovechando la re-utilización de los mismos y provee técnicas de clasificación y ordenamiento basadas en la similaridad de los ítems.

• Filtrado de contenido base y métodos de clasificación multimedia. Cuando el

sistema de recomendación turística incorpora multimedia, en especial audio y video no así con archivos de texto e imágenes, implica un requerimiento de un alto poder computacional.

• Filtrado colaborativo. Requiere de un esfuerzo en el desarrollo integral para

recuperar y conjuntar votos o ratings sobre los ítems. Generalmente, se tiene una gran cantidad de ítems de interés y una menor cantidad de votos sobre los items, por lo que el filtrado colaborativo requiere de modificaciones para ser utilizado en el dominio del turismo.

• Sistemas híbridos. La combinación de las anteriores técnicas para abordar el tema

de la heterogeneidad pueden constituir una buena opción.

La elección del enfoque para el desarrollo de un sistema de recomendación depende de las fuentes de información y de los ítems de interés que serán utilizados en el sistema. La

41

precisión y utilidad de un sistema de recomendación turística debe considerar de manera jerárquica: el filtrado, la clasificación, ordenamiento e inferencia, así como un modelo de conocimiento que permita persuadir al usuario de los beneficios del sistema.

2.5 Resumen

En este capítulo se describe un punto relevante para esta tesis, como lo es la conceptualización de un sistema de recomendación turística. Se han analizado los problemas y retos del sector turismo y como los sistemas de recomendación dentro del comercio electrónico han proliferado por los beneficios que representan, siendo el más destacable la personalización de productos turísticos con base en las preferencias del usuario.

Se han señalado los elementos importantes en la toma de decisión en la planeación de un viaje turístico, los tipos de influencias que el usuario toma en cuenta en el momento de su decisión (inter-personal, intra-personal y circunstancial), además que el sistema de recomendación debe tomar en cuenta estos aspectos para inferir mejores resultados.

La funcionalidad de un sistema de recomendación turística se centra en el manejo de la heterogeneidad de la información dentro del dominio del problema, en la definición de las tareas que realizará y en las preferencias del usuario. Se describieron los enfoques más importantes en el desarrollo de este tipo de sistemas, siendo el más importante para este trabajo: el filtrado y razonamiento basado en el conocimiento. La evaluación de los sistemas de recomendación debe basarse en las tareas definidas del sistema y para ello se han descrito diferentes técnicas que miden la precisión y la utilidad del sistema.

Finalmente, se han mencionado las técnicas que pueden ser utilizadas para el filtrado de la información en el ámbito turístico, siendo el enfoque central de esta tesis el filtrado y razonamiento basado en conocimiento.

En el siguiente dos capítulos se describen los mecanismos de razonamiento basado en reglas y basado en casos respectivamente, y que constituyen el núcleo de razonamiento paraa el sistema de recomendación turística propuesto en este trabajo.

43

3. Razonamiento basado en reglas

El razonamiento es la habilidad de realizar inferencias para llegar a una conclusión. El razonamiento automatizado esta orientado a la construcción de sistemas de cómputo que realicen dicho proceso. En un problema de razonamiento, se trata de llegar a una meta u objetivo partiendo de uno o más estados iniciales, a menor número de transiciones que ocurran para llegar a la meta el sistema de razonamiento tendrá una mejor eficiencia. La eficiencia dependerá si la base de conocimiento es completa y organizada de manera que no requiera una búsqueda extenuante e identificación del conocimiento que el sistema requiera para resolver el problema [50].

En la ingeniera del conocimiento es el proceso por el cual se lleva a cabo la construcción de una base de conocimiento, por lo que es importante contemplar la organización de dicho conocimiento [30].

Existen una gran variedad de técnicas de representación de conocimiento dentro de la inteligencia artificial como lo son: producción de reglas, redes semánticas y lógica de predicados por mencionar algunas.

El razonamiento basado en reglas (RBR – Rule-Based Reasoning) se encuentra enmarcado dentro de un sistema de producción por lo que en la sección 3.1 se definirá esta representación de conocimiento.

44

3.1 Sistemas de producción

Para poder comprender los sistemas de producción, de donde parte el razonamiento basado en reglas, es necesario definir lo que es el conocimiento. Una pieza de conocimiento es una función que mapea un dominio de cláusulas hacia un rango de cláusulas, no obstante la función puede ser del tipo algebraico o relacional dependiendo del problema [30]. Como un ejemplo podemos considerar la siguiente producción de regla PR1, que mapea la relación padre-hijo entre (p, q) a la relación edad-mayor entre el mismo par.

PR1: Padre (m, c) � Mayor (m, c) donde la cláusula Padre (m, c) describe que “m” es el padre del hijo “c”; la cláusula Mayor (m,c) denota que “m” tiene mayor edad que “c”, finalmente la flecha denota la condición si-entonces. Entonces, la regla implica que:

Si “m” es padre de “c” entonces “m” tiene mayor edad que “c”

En el razonamiento basado en reglas, se establecen dos elementos: los hechos y el conocimiento. El sistema de producción utiliza tanto los hechos como el conocimiento para llegar a las conclusiones. La simplicidad en un sistema basado en reglas puede volverse compleja cuando existen problemas donde más de una regla puede ser aplicada a un mismo tiempo. En consideración a esto último, es necesaria una unidad de control para decidir cual regla debe ser disparada y el orden de disparo de las reglas, además de los algoritmos utilizados para llegar a la meta, algunos ejemplos de estos últimos son: encadenamiento progresivo (Depth-First Forward Chaining) y encadenamiento en retroceso (Backward Chaining) [30].

Se debe tener un control sobre la coherencia del conocimiento durante la construcción de la base de conocimiento así como con los procesos de adquisición de datos y razonamiento. Si la base de conocimiento contiene información inconsistente es posible que el sistema se comporte de manera poco satisfactoria y obtenga conclusiones absurdas. Por lo que debe considerarse que se debe orientar al usuario para no introducir hechos inconsistentes y evitar que entre en la base de conocimiento cualquier tipo de conocimiento contradictorio.

Los sistemas basados en un razonamiento basado en reglas, como los sistemas de producción, tratan de solucionar un problema sin dividirlo en partes, en otras palabras como un todo. Sin embargo, para definir las reglas a utilizar, se debe conocer como resolver el problema y ésta tarea puede ser muy compleja y consume tiempo [54].

El sistema de producción es una de las técnicas más antiguas para la representación del conocimiento dentro de la inteligencia artificial (1943). Un sistema de producción consiste de tres elementos [15, 30]:

45

i. Un conjunto de reglas que representa la base de conocimiento.

ii. Una o más bases de datos dinámicas, donde se almacenan los hechos, llamadas

memorias de trabajo iii. Una estructura de control o intérprete, la cual traduce la base de datos utilizando el

conjunto de producción de reglas, y es donde se decide que reglas aplicar.

Podría decirse que los sistemas expertos basados en reglas son uno de los productos más éxitos de la inteligencia artificial. Los factores que contribuyeron principalmente se enuncian a continuación [54]:

• La estructura de control intenta imitar las estrategias humanas de problema-solución.

• La estructura de control es relativamente simple, lo que facilita el entendimiento no

solo de científicos de la computación.

• Las reglas intrínsecamente son parte de cada día de la vida humana y con las que las personas se relacionan habitualmente.

• Existencia y uso de herramientas disponibles comercialmente para desarrollar

sistemas basados en reglas, comúnmente conocidos como sistemas expertos.

Sin embargo, los sistemas basados en reglas tienen limitaciones. Aunque es difícil obtener un conjunto correcto de reglas, éste problema ha sido solucionado con el desarrollo de sistemas expertos basados en reglas y es referenciado como conocimiento adquirido por cuello-de-botella. El concepto de cuello de botella se refiere a que difícilmente se puede obtener conocimiento de dominios diferentes [54]:

• Un experto puede estar muy ocupado para invertir un poco de tiempo en la ingeniería del conocimiento que se requiere para obtener su conocimiento y codificarlo.

• El experto ciertamente tiene un alto grado de conocimiento pero puede no ser

locuaz.

• La ingeniería del conocimiento podría no proveer una comprensión total del problema, debido a su naturaleza sumamente especializada, y por lo tanto sería difícil producir un modelo correcto.

La representación del conocimiento entonces puede no abstraer realmente al

conocimiento obtenido.

46

3.2 Elementos de un sistema de producción

3.2.1 Producción de reglas

La relación entre los datos que representan información, en términos de la lógica de

primer orden, puede ser referida como un predicado [54]. En la lógica de primer orden, el grado de expresividad aumenta con el uso de variables (como argumentos de los predicados) así como los operadores lógicos: AND, OR, NOT y declaraciones IF-THEN. Lo cual permite definir reglas cuyo principal objetivo es la evaluación de las instancias de las variables en un predicado, además de la inferencia como consecuencia de su aplicación.

Por regla puede entenderse como una proposición lógica que relaciona dos objetos y

consta de dos partes: un antecedente (condición) y un consecuente (conclusión). Una regla puede ser transformada en una sentencia IF-THEN, por ejemplo: “Si antecedente, Entonces consecuente”. Este tipo de reglas determinísticas constituyen la metodología más utilizada en los sistemas expertos y el razonamiento basado en reglas (RBR). De manera formal la producción de reglas puede ser representada como [30]:

PR: P1 (x) ^ P2 (y) ^ … Pn (X,Z) � Q1(Y) v Q2(Z) v… Qm (Y,X) en donde Pi y Qi son predicados y X, Y, Z, son variables; además de los operadores lógicos AND (^) y OR (v) y finalmente la denotación IF-THEN representado por “�”.

Aunque debe señalarse que tanto los antecedentes como los consecuentes no deben ser necesariamente predicados. Otra notación puede ser una tripleta: objeto-atributo-valor [30]. Para describir esta notación se tiene el siguiente ejemplo:

PR2: Si ( (persona gana más-de-$4,000) & (persona tiene-esposa nulo) & (persona tiene-coche nulo)) Entonces (persona elegible para un préstamo)

En este ejemplo una tripleta objeto-atributo-valor esta representada (persona-gana-

valor) y se han utilizado variables. El uso de variables implica el apareamiento de patrones, es decir que existen objetos de tipo persona – que contienen atributos y valores especificados en la tripleta – en los hechos obtenidos y que una regla como PR2 instancia las variables con los hechos con la finalidad de obtener una conclusión.

47

3.2.2 La memoria de trabajo

En la memoria de trabajo es una estructura donde se guarda y mantiene las clausulas

o tripletas objeto-atributo-valor (OAV) que representan hechos, de manera temporal. Ésta estructura es manipulada por las reglas, en las cuales se pueden agregar o eliminar hechos [30].

Los hechos que se encuentran en la memoria de trabajo son los que se instancian en las variables de las condiciones de las reglas y permiten dispararlas, si se cumplen las condiciones. El consecuente de la regla disparada puede entonces manipular la memoria de trabajo [15, 30].

3.2.3 La unidad de control

La unidad de control o intérprete puede ser concebido de manera simple como un

ciclo de selección-ejecución o bien, reconocer-actuar y esta compuesto de los siguientes pasos [15, 30]:

i. Instanciar las variables de los antecedentes de la regla con el conocimiento almacenado en la memoria de trabajo (hechos). Este paso es realizado con base en el algoritmo RETE.

ii. Si existe más de una regla que pueda dispararse debe decidir que regla debe

dispararse, un conjunto de técnicas para la resolución de conflictos pueden utilizarse para resolver esta situación. Este paso es realizado a través de las técnicas de resolución de conflictos.

iii. Después de disparar una regla, se podrá manipular la memoria de trabajo,

dependiendo si la consecuencia así lo indica.

El ciclo es terminado si no existen más reglas que activar o si el consecuente de una de ellas así lo indicara. Resolución de conflictos

En la construcción de un conjunto de reglas, es difícil tener una regla que se dispare en cualquier instante de tiempo (determinismo). La resolución de conflictos ayuda a identificar que regla deberá ser disparada en caso de que se cumplan todas las condiciones de dos o más reglas al mismo tiempo (no-determinismo).

Es necesario señalar la diferencia entre activar una regla y disparar una regla, en un sistema de producción se dice que se activan las reglas cuando se ha encontrado que los

48

hechos satisfacen las condiciones de una regla (antecedentes), la activación implica en poner en cola las reglas correspondientes que posteriormente la unidad de control se encargara de disparar.

Algunas técnicas importantes para la resolución de conflictos son [15, 18, 30]:

• Jerarquía. Cada regla tiene un atributo que contiene un valor entero por el cual se da prioridad a las reglas que tienen valores más altos cuando se ordena la cola de activación.

• Reciente. Esta estrategia requiere que los elementos más recientes de la memoria de

trabajo sean utilizados en la instanciación de los antecedentes de las reglas.

• Primacía. A diferencia de la anterior, en ésta estrategia los elementos a tomar en cuenta son los que se introdujeron primeramente en la memoria de trabajo.

• Complejidad. Una estrategia basada en que la regla que se debe dispararse es la

que tenga mayor número de condiciones para ser evaluada.

• Simplicidad. De manera contraria a la anterior, la regla a dispararse es la que tenga el menor número de condiciones.

• FIFO (First-In-First-Out). Estrategia de profundidad basada en el orden de

activación. Las nuevas activaciones son consideras para dispararse primero.

• LIFO ( Last-In-First-Out). Estrategia de amplitud basada en el orden de activación. Las nuevas activaciones son consideradas para dispararse a lo último.

• Orden. Se respeta el orden en la que el conjunto de reglas fueron establecidas.

• Aleatorio. Las activaciones son introducidas de manera aleatoria a la cola reglas a

dispararse. El algoritmo RETE

El algoritmo RETE crea un árbol de decisión o red de nodos, en donde cada nodo (excepto la raíz) corresponde a un antecedente (patrón) de una regla. El camino del nodo raíz al nodo hoja presenta todas las condiciones de una regla. Cuando se modifican o agregan hechos, esto se propaga en toda la red. En el momento en que un hecho o conjunto de hechos satisfacen las condiciones de una regla, esto significa que se ha llegado a una hoja y la regla en turno es activada [30]. Este algoritmo constituye el primer paso del ciclo de la unidad de control.

49

El ciclo reconocer-actuar mencionado en la sección 3.4 es lo que consume mayor tiempo, debido al apareamiento de patrones lo cual se lleva acabo en la implementación del algoritmo RETE.

3.3 Propiedades de un sistema de producción

La funcionalidad de un sistema de producción, mencionada anteriormente, puede ser descrita de igual manera a través de su arquitectura como se muestra en la figura 4 [30].

El empleo de los sistemas de producción en la modelación de problemas puede resultar más conveniente en ciertos dominios, de manera que es necesario identificar los dominios apropiados e inapropiados para su implantación. Primeramente se debe analizar la complejidad del algoritmo de control, ya que se pueden tener procesos los cuales se pueden realizar de forma paralela y encontrar subprocesos dependientes. En una segunda distinción, se debe conocer si el conocimiento que será embebido del sistema puede separarse de la manera en la cual será utilizado [15].

Figura 4. Arquitectura de un sistema de producción.

50

Entonces, un proceso compuesto de acciones independientes que requieren mínima

o nula comunicación entre las acciones, son una característica fundamental de un sistema de producción. Además, en un sistema de producción se especifican descripciones procedurales en las que se describe como llegar a una meta, separando el conocimiento de la manera en que se utiliza.

En los sistemas de producción existen ciertas propiedades que han hecho que este tipo de representación de conocimiento siga siendo utilizado [18, 30]:

• Aislamiento del conocimiento y de la estrategia de control. La arquitectura de un sistema de producción presentada en la figura 1, demuestre la separación de la base de conocimiento y de la unidad de control. Por un lado la ingeniería del conocimiento recoge información experta codificada en reglas. Entonces, puede agregarse nuevo conocimiento o modificarlo, ya sea por agregar o eliminar reglas. Teniendo en cuenta la separación mencionada, posibles cambios en el código de la unidad de control no alterará el conocimiento base.

• Mapeo directo estado-espacio. Los módulos de un sistema de producción pueden

ser mapeados a estados. Los hechos contenidos en la memoria de trabajo representan estados, la producción de reglas causan una transición de estados y las estrategias de resolución de conflictos realizan la selección de los estados que dispararán una regla de un posible conjunto de reglas que puedan ser disparadas. El mapeo a estados permite encontrar fallas en la base de conocimiento y facilitan su modificación.

Un sistema de producción puede ser visto como un solucionador de problemas que parte de un estado inicial que busca llegar a una meta a través de pasar por varias transiciones hacia uno o más estados. Los algoritmos de búsqueda utilizados para la consecución de la meta son encadenamiento progresivo y encadenamiento en retroceso. El encadenamiento progresivo es empleado cuando dado un estado inicial y un estado final (meta) se puede expandir el número de estados entre el inicial y final a través de la base de conocimiento. El encadenamiento en retroceso es empleado cuando dada un estado final (meta) se trata de encontrar la evidencia para sustentarlo. Entonces los antecedentes de las reglas son llamadas submetas, las cuales son buscadas a través de las partes consecuentes de las reglas.

• Estructura modular de reglas de producción. El espacio de instanciación

utilizado en la producción de reglas puede traer consigo la instanciación de otras reglas en la memoria de trabajo a lo que se conoce como encadenamiento de reglas.

51

En otras palabras una regla disparada puede causar que otra regla sea disparada constituyendo una cadena de secuencia de reglas disparadas.

3.4 Tipos de sistemas de producción

Los sistemas de producción pueden clasificarse de acuerdo a [30] en: sistemas conmutativos y sistemas particionados, las principales características se definen a continuación.

3.4.1 Sistemas conmutativos

Se define a un sistema de producción como un sistema conmutativo si dado un

conjunto de reglas y una memoria de trabajo, se cumplen las siguientes condiciones [30]:

i. Libertad en el orden de disparo de las reglas. Establecer un orden arbitrario para el disparo de reglas no constituye diferencia alguna con el contenido de la memoria de trabajo.

ii. Invariante de pre-condición para alcanzar una meta. Si la pre-condición de una meta es satisfecha antes de disparar una regla, aún disparando dicha regla permanecerá en el mismo estado.

iii. Independencia de reglas. La condición de disparo de una regla no-disparada con respecto a la memoria de trabajo permanece sin alterarse, aún después de disparar otras reglas.

Por lo consiguiente la principal ventaja de estos sistemas es la independencia del

orden de las reglas sin el riesgo de no llegar a la meta.

3.4.2 Sistemas particionados

Un sistema de producción es particionado, si la meta G y la memoria de trabajo WM

pueden ser particionados en otros mismos Gi y WMi a su vez, como se describe a continuación:

G = ANDi (Gi)

WM = ∪ { WM i }

52

Por lo que el conjunto de reglas es aplicado en cada WMi, independientemente o concurrentemente para llegar a Gi. La búsqueda de la meta termina cuando todas las metas Gi para cada i han sido identificadas.

La ventaja más significativa de un sistema de producción particionado es permitir el disparo paralelo de reglas, sin causar una diferencia en el contenido de la memoria de trabajo.

3.5 Resumen

En este capitulo se ha definido y descrito una técnica para la representación de conocimiento que es un sistema de producción, que es además la base del razonamiento basado en reglas. Un sistema de producción permite el razonamiento basado en la producción reglas, contando con un motor de inferencia y una memoria de trabajo, que evalúan hechos para llegar a una meta o conclusión. Se han identificado las características y tipos de un sistema de producción.

Es importante señalar que los sistemas de producción tienen la característica de separar el conocimiento base de la unidad de control, de esta manera la modificación del conocimiento solo constituye un cambio en la manera de llegar a la meta.

El razonamiento inherente de un sistema de producción es utilizado en este trabajo de tesis con la meta de filtrar, ordenar e inferir de recursos turísticos. Siendo los recursos turísticos los hechos de la memoria de trabajo y el conocimiento base son la producción de reglas que permitan realizar procesos como el filtrado. Los conceptos de un sistema de producción, visto como un sistema que soporte el razonamiento basado en reglas serán utilizados en el diseño del sistema de recomendación turística propuesto en este trabajo de tesis.

En el siguiente capítulo, se describirá el razonamiento basado en casos que fundamentara a los sistemas de recomendación que utilizan este mecanismo de razonamiento para proponer itinerarios o recursos turísticos personalizados.

53

4. Razonamiento basado en casos

El razonamiento puede ser modelado como un proceso que obtiene conclusiones por encadenar reglas. El razonamiento basado en casos (CBR – Case-Based Reasoning) toma una percepción diferente, ya que la fuente de conocimiento base no es concebida como una producción de reglas pero existe una memoria que almacena casos (problema-solución) y que graba episodios específicos. Las nuevas soluciones no son generadas a través de reglas, sino que se recuperan los casos similares de la memoria y se adaptan a la nueva situación o problema; es por esto que en el CBR el razonamiento se basa en el recuerdo. Básicamente este tipo de razonamiento se basa en el razonamiento humano de recordar experiencias pasadas para solucionar problemas presentes [31].

4.1 Introducción

El razonamiento basado en casos tiene dos principales motivaciones: el primero se basa en el deseo de modelar el comportamiento humano y el segundo, el deseo de desarrollar tecnologías dentro de la inteligencia artificial (IA) que sean más efectivas. Los seres humanos, desde un punto de vista cognitivo, son solucionadores de problemas que muchas veces a pesar de su limitado e incierto conocimiento, su rendimiento mejora con la experiencia. En los sistemas desarrollados dentro de la inteligencia artificial se han identificado problemas que a través del CBR pueden ser solucionados, a continuación se enuncian [31]:

54

1. Adquisición de conocimiento. En la representación de conocimiento clásica y descrita en el capitulo anterior, la producción de reglas puede significar un proceso laborioso y poco confiable lo que implica que difícilmente pueden obtenerse un conjunto de reglas, además de no asegurar que éstas reglas sean suficiente para caracterizar el conocimiento.

En el caso del CBR, tiene un bajo costo la adquisición de conocimiento. Los razonadores basados en casos toman el conocimiento de episodios específicos para descomponer experiencias pasadas y los almacenan como parte de su procedimiento de solucionador de problemas.

2. Mantenimiento del conocimiento. La definición inicial del conocimiento base es solo el principio de una aplicación de IA. En principio, la comprensión de un problema puede no ser perfecta y requiere que el conocimiento sea refinado. Cualquier cambio en la comprensión del problema implica que la representación del conocimiento sea obsoleta.

El beneficio del CBR en este aspecto, se enfoca en el aprendizaje incremental, solo es necesario un conjunto limitado de casos base como un ejemplo para la solución de problemas y este conjunto puede ser incrementado con nuevos casos si la librería de casos no contempla el nuevo problema-solución.

3. Incrementar la eficiencia de solución de problemas. La reutilización de

soluciones previas incrementan la eficiencia ya que se basa en el razonamiento pasado más que en repetir el esfuerzo que llevo a solucionar un problema. En el CBR, pueden almacenarse tanto soluciones fallidas como exitosas, entonces se tiene el potencial de prevenir y evitar problemas potenciales.

4. Incrementar la calidad de las soluciones. Cuando los principio de un dominio no

pueden ser bien entendidos, las reglas pueden ser imperfectas. Si se utilizan casos, éstos representan lo que realmente esta pasando dadas las características del problema entonces la solución dada será adecuada.

5. Aceptación del usuario. El principal problema en sistemas desarrollados con base

en la inteligencia artificial es la aceptación del usuario, ningún sistema es útil a menos que el usuario acepte los resultados. En muchos de los casos, el usuario necesita convencerse que las soluciones dadas por el sistema realmente son derivadas de un razonamiento. Los resultados del CBR están basados en experiencias pasadas y proveen de fundamentos a las conclusiones del sistema.

El éxito de un sistema CBR depende de cómo se dirija temas como la adquisición,

representación, indexación y adaptación de los casos.

55

4.2 El ciclo del razonamiento basado en casos

El razonamiento basado casos es un mecanismo de razonamiento que se basa en explotar las experiencias pasadas para encontrar la solución a un problema idéntico o similar [54]. Un caso puede verse como una 2-tupla (p,s) donde p (llamado problema) es un elemento del conjunto P (espacio del problema) y s (llamado solución) es un elemento del conjunto S (espacio de solución). Si se tiene una descripción general P(x1,...,xn) de problemas, entonces cada problema individual es una instancia P(a1,...,an). Si se tiene una descripción general de una solución S(y1,...,ym) entonces cada solución individual al problema P(b1,...,bm) es una instancia (donde no todas las variables tienen certeza de ocurrir). Los elementos xi son las variables del problema y las yi son las soluciones a las variables. La solución al problema es encontrar las instancias correctas para las variables del problema.

El razonamiento basado en casos esta definido por un ciclo de aprendizaje que tiene por objetivo mejorar el comportamiento del sistema con base en la experiencia pasada [54], como se muestra en la figura 5. El ciclo inicia con la descripción de un problema que define un nuevo caso. El nuevo caso es utilizado para recuperar un caso del conjunto de casos pasados. El caso recuperado es reutilizado como una propuesta de solución al problema inicial. A través del proceso de revisión la solución es probada para comprobar el grado de éxito, si falla ésta puede ser adaptada. En el almacenamiento de la nueva solución, se basa en guardar la experiencia útil para ser reutilizada posteriormente y el caso base es actualizado convirtiéndose en un nuevo caso aprendido o bien modificando casos existentes [8].

Figura 5. Ciclo del razonamiento basado en casos.

56

Este ciclo de aprendizaje, ilustrado en la figura 5, define cuatro pasos [31, 54]:

1) Recuperar los casos más similares, para un problema dado. 2) Reutilizar los casos para intentar solucionar el problema. 3) Revisar la solución propuesta, si es necesario. 4) Almacenar la nueva solución como parte de un nuevo caso.

El ciclo raramente ocurre sin la intervención humana, el paso en el que comúnmente

existe la intervención humana es la revisión en donde se lleva a cabo la adaptación [54]. Este ciclo que es descrito como un conjunto secuencial de pasos, tiene tareas asociadas en cada uno de estos pasos que el razonador CBR debe llevar a cabo.

A nivel conocimiento, un sistema es visto como un agente que tiene metas, las

cuales deben ser alcanzadas. La descripción de un sistema puede ser construido con base en tres perspectivas: tareas, métodos y modelos acerca del conocimiento de un dominio. Las tareas son establecidas por las metas del sistema y una tarea es realizada aplicando uno o más métodos. Para que un método sea aplicado es necesario tener conocimiento acerca del dominio de aplicación así como de la información acerca del problema en cuestión y de su contexto.

El esquema tareas-métodos, ilustrado en la figura 6, tiene nodos que representan tareas y las ligas entre los nodos son la descomposición de tareas. En la parte superior se tiene el problema a solucionar y el aprendizaje de la experiencia pasada, además del método para completar la tarea el cual en este caso es el razonamiento basado en casos.

Las tareas del CBR corresponden a los cuatro pasos o procesos mencionados en el

ciclo CBR. La tarea de recuperación particionada de manera similar en tareas como: identificar características (descriptores relevantes), búsqueda (encontrar un conjunto de casos previos), match inicial (descriptores relevantes de casos previos) y selección (el caso más similar). Si bien, en el esquema no se observa una estructura de control sobre las subtareas, la secuencia que se siguen éstas es rígida.

La relación entre tareas y métodos, indicada a través de líneas punteadas, representa

métodos alternativos para la solución de la tarea. Un método es concebido como un algoritmo que identifica y controla la ejecución de subtareas; además utiliza el conocimiento e información necesaria para ello. Es posible que un único método no sea suficiente para solucionar una tarea, entonces es necesario combinar más de un método. Los métodos mostrados en el esquema son descomposición de tareas y métodos de control. En el más bajo nivel del esquema se encuentra una tarea resuelta (no mostradas) [8].

57

Figura 6. E

squema de descom

posición tarea método del C

BR

58

4.3 Métodos del razonamiento basado en casos

El ciclo del CBR esta soportado sobre métodos o técnicas de implementación que soportan la realización de cada proceso del ciclo CBR [54]. No existen métodos universales en el CBR convenientes o adecuados para cualquier dominio de aplicación. De acuerdo con el modelo de tareas, mencionados en la anterior sección, se tienen problemas centrales que dirigen la investigación del razonamiento basado en casos, soluciones para estos problemas constituyen un método CBR [8, 54]:

i. Representación del conocimiento ii. Métodos de recuperación

iii. Métodos de reutilización iv. Métodos de revisión v. Métodos de almacenamiento

En las secciones posteriores se detallaran en los problemas relacionadas a estas

áreas y se describirán los métodos existentes que los han solucionado.

4.3.1 Representación de casos

Un caso representa una pieza de conocimiento que representa experiencia. En

términos del CBR, un caso usualmente denota un problema-solución. Contiene una lección de aprendizaje pasado en donde se incluye el problema que fue resuelto y el contexto en el que se empleo la solución asociada. Esto puede ser visualizado en términos de un espacio de problemas y un espacio de soluciones. La descripción de un nuevo problema, que debe ser solucionado, es posicionada en el espacio de problemas. La recuperación identifica el caso con la descripción más similar al nuevo problema y la solución asociada al caso es encontrada. Si es necesaria la adaptación, ésta ocurre y se crea una nueva solución. Este modelo conceptual asume que hay un mapeo directo uno-a-uno entre un problema y una solución, como se puede apreciar en la figura 7 [54].

Un razonador CBR es altamente dependiente de la estructura y contenido de la colección de casos, que puede ser referida como memoria de casos. Debido a que un problema es resuelto con base en la experiencia pasada, los procesos de búsqueda y concordancia (matching) del caso necesitan ser efectivos y eficientes. Ya que la experiencia pasada es fundamental, el problema-solución obtenido debe almacenarlo de alguna manera así como integrar el nuevo caso a la memoria. En consideración a lo anterior, la representación de un problema en el CBR implica decidir que debe contener un caso y encontrar una estructura apropiada que defina los contenidos que se establezcan, así como decidir la manera en la que la memoria de casos deberá organizarse para una recuperación y reutilización efectiva [8].

59

Figura 7. Espacios de problema y solución.

4.3.2 Recuperación

La recuperación de casos es relativamente cercana y dependiente del método de

indexación utilizado. Un índice es una estructura computacional de datos que es almacenada en memoria y ayuda a realizar una búsqueda eficiente de datos. La información inmersa en la definición de un caso puede ser de dos tipos [8, 54]:

1. Información indexada. La cual es utilizada para la recuperación. 2. Información no-indexada. La cual puede proveer información contextual del

problema que no es utilizada directamente en la recuperación.

Ahora bien las características de los índices son determinantes para llevar a cabo la indexación, algunas de estas características pueden ser [54]:

1. Ser predictivo 2. Dirigir los propósitos de uso para el caso base 3. Ser suficientemente abstracto para permitir la ampliación del uso futuro del caso

base 4. Ser suficientemente concreto para ser reconocido en el futuro

El establecimiento de los índices puede ser tanto manual como automatizado, la

elección manual de los índices involucra decidir el propósito del caso respecto a la dirección que tome el sistema, además de establecer las circunstancias en las que el caso será útil. Algunas técnicas automatizadas que han sido utilizadas son:

60

• Indexación de casos por características y dimensiones que tienden a ser predictivos en todo el dominio.

• Indexación basada en diferencias, las cuales seleccionan índices que diferencias a

un caso de otro.

• Métodos de aprendizaje inductivo, los cuales identifican características que son

utilizadas como índices.

En la recuperación de casos, de manera general, las técnicas o métodos más utilizados son: recuperación basada en el vecino más cercano y recuperación inductiva [54]. Recuperación del vecino más cercano

A nivel conceptual, la técnica de recuperación del vecino más cercano se basa en encontrar la distancia más cercana entre dos puntos, siendo un primer punto la referencia.

En un caso del CBR, el problema inmerso tiene características fundamentales las cuales pueden ser vistas como índices, éstos índices pueden ser utilizados como ejes de una gráfica. Esta conceptualización puede ser entendida de la siguiente manera: sean dos características X y Y de un problema P, entonces X y Y serán los ejes de la gráfica. Los valores asociados a X y Y constituyen un punto dentro de la gráfica. De manera similar, casos previos pueden ser señalados como puntos de dicha gráfica. Entonces cuando un nuevo caso es establecido, éste se señala como un punto dentro de la gráfica y se calcula la distancia relativa entre el nuevo caso (caso objetivo) y los casos previos [54]. Todo lo anterior puede observarse en la figura 8.

Eje X

YB

XA

XB

Caso B

Caso A

Caso N

Figura 8. Gráfica representativa de las distancias del vecino más cercano.

61

En la figura 8, el caso N representa un nuevo caso, los casos A y B representan

casos previos. Entonces la distancia entre el caso N con respecto a los casos A y B esta dada por los siguientes cálculos:

Distancia de N hacia A : dA = XA + YA Distancia de N hacia B : dB = XB + YB

Entonces la decisión para resolver el problema N, es sencilla se toma la distancia

más corta para encontrar al vecino más cercano y así encontrar la solución.

Sin embargo, en un escenario más realista en un CBR cada característica o atributo de un problema tiene un cierto peso con respecto a otra, entonces esto se vería reflejado de la siguiente manera:

Distancia de N hacia A : dA = (XA * WX) + (YA * WY) Distancia de N hacia B : dB = (XB * WX) + (YB * WY)

donde WX es el peso del atributo X y WY es el peso del atributo Y.

Aunque esta conceptualización ha sido referencia con base en dos características por lo que es un espacio bidimensional, esto puede también llevarse a cabo de manera n-dimensional tomando en consideración n-características. Ahora bien, las características no están restringidas a comparaciones numéricas de similaridad, sino que pueden contener valores simbólicos, valores boléanos y valores de cadenas.

El cálculo de similaridad entre un caso y otro, se puede definir formalmente de la siguiente manera [54]:

∑ =×= n

i iii wSTfSTdSimilarida1

),(),(

donde, T es el caso objetivo o nuevo caso S es el caso fuente n es el numero de atributos en cada caso i es un atributo individual desde 1 hasta n F es una función de similaridad por atributo i en los casos T y S w es el peso (importancia) del atributo i

La principal debilidad de éste algoritmo radica en la eficiencia de la recuperación. Mientras más atributos definan a un problema y se agreguen más casos a la memoria de casos, el número de cálculos crece a razón de n x m, donde n es el número de características

62

del problema y m el número de casos. Aunque es menos sensitivo si se da el caso de tener valores desconocidos en las características del problema.

El algoritmo del vecino más cercano es el más utilizado en las aplicaciones CBR en la recuperación de casos. Generalmente la similaridad es normalizada a un rango entre 0 y 1, siendo 0 lo totalmente diferente y 1 un match exacto, es decir concordancia exacta. Recuperación inductiva

Una técnica alternativa para la recuperación involucra un proceso de inducción. La técnica de inducción se basa en extraer reglas o construir un árbol de decisión de información pasada. En los sistemas CBR, el caso base es analizado por un algoritmo inductivo produciendo un árbol de decisión que clasifica los casos previos. El algoritmo más utilizado en este ámbito es el ID3 [54].

Básicamente, el algoritmo ID3, se basa en la existencia de un atributo totalmente discriminante para clasificar los casos “buenos” de los casos “malos”. Con base en el atributo inicial se crea un árbol donde cada nodo subyacente representará los demás atributos del problema.

La principal debilidad de este algoritmo radica en la dependencia de la información del caso, si algún dato es desconocido no podría ser posible la recuperación de un caso. Aunque la indexación para este caso aumenta la rapidez de respuesta.

4.3.3 Reutilización

Una vez que un caso es recuperado, un sistema CBR tratará de utilizar la solución

sugerida por la recuperación. En ocasiones esta sugerencia puede ser suficientemente adecuada y en otras ocasiones solamente cercana. Es tarea del sistema CBR adaptar la solución para que ésta satisfaga totalmente al problema en cuestión. En general existen dos tipos de adaptación en un CBR [54]:

• Adaptación estructural. Se aplican reglas de adaptación o directamente fórmulas a la solución sugerida.

• Adaptación derivacional. Se reutilizan las reglas o formulas que generaron la solución original produciendo una nueva solución, lo que involucra almacenar la secuencia que construyó la solución original.

Además se han establecido diferentes técnicas que han sido usadas para la

adaptación en un sistema CBR, a continuación se describen algunas de ellas [54]:

63

• Adaptación Nula. No se utiliza ningún tipo de adaptación. Por lo que se aplica cualquier solución recuperada al problema actual.

• Ajuste de parámetros. Se comparan parámetros especificados de la recuperación y el caso actual para modificar la solución de alguna manera.

• Reinstanciación repetida. Es utilizada para instanciar características de una solución anterior con nuevas características.

Aunque la adaptación es útil en algunas circunstancias no es esencial. En las

herramientas CBR en general no se utiliza un método de adaptación (adaptación nula) o permiten que el usuario haga ésta tarea.

4.3.4 Revisión

Cuando una solución generada por la reutilización no es del todo correcta, se

necesario aprender de la falla. En la fase de revisión se evalúa la solución generada por la reutilización si no es exitosa se repara el caso solución usando un dominio especifico de conocimiento [31].

En la evaluación de la solución puede determinar también la calidad de la solución generada. La calidad puede ser referenciada a través de los valores que tomen las características de los casos previos con respecto a un valor determinado que represente una solución aceptable.

La reparación de casos lleva consigo un mayor conocimiento del dominio del problema. De esta manera se conoce la manera en la que se puede modificar o reparar la solución sugerida.

4.3.5 Almacenamiento

El almacenamiento de los casos es un aspecto importante en el diseño de un sistema

CBR eficiente. El caso base debe organizarse en una estructura manipulable que soporte la búsqueda eficiente y los métodos de recuperación.

Algunos métodos que establecen alternativas para la representación y organización para el almacenamiento de casos son: el modelo de memoria dinámica y el modelo de categoría ejemplar [8], aunque estás técnicas no son utilizadas en herramientas comerciales sino que almacenan los casos como simples archivos de estructuras de datos o dentro de estructuras relacionales de bases de datos usando índices como referencias a los casos [54].

64

4.4 Comparativa del razonamiento basados en casos vs. otras técnicas

En esta sección se provee una comparación entre el CBR y otras técnicas computacionales de razonamiento como: recuperación de información, técnicas estadísticas, sistemas de producción, máquinas de aprendizaje y redes neuronales con la finalidad de presentar fortalezas y debilidades de cada una [54].

4.4.1 CBR y la recuperación de información

El razonamiento basado en casos y la recuperación de información tienen varias

características en común. La recuperación de información usa diferentes técnicas como las peticiones estándar a una base de datos cuando se trata de recuperar información de un conjunto de fuentes informáticas. La técnica más popular es la recuperación basada en conceptos, la cual usa un catálogo para encontrar palabras semejantes en una query para ampliar su alcance. En este contexto el CBR y la recuperación de información soportan la flexibilidad en la query y ambas recuperan un conjunto potencialmente relevante de elementos concordantes.

Sin embargo, los métodos de la recuperación de información se enfocan en recuperar texto de fuentes informáticas mientras que el CBR puede tratar con diferentes tipos de datos (v. gr. números, símbolos, etc). Además en la recuperación de información no se usa conocimiento acerca de la información que esta siendo recupera mientras que el CBR la usa para dar un peso a los valores de los atributos de un problema.

4.4.2 CBR vs. Técnicas estadísticas

Existen estudios que comparan el CBR contra las técnicas estadísticas. Un ejemplo

es la comparación entre el algoritmo de vecino más cercano y el análisis discriminante lineal, para sistemas de clasificación. En un sistema de tratamiento en medicina, el CBR tuvo un 87% de los tratamientos clasificados de manera correcta mientras que el análisis discriminante solo el 67%. Esto puede sugerir que el CBR tiene un rendimiento mejor que el análisis discriminante pero no se puede hacer a un lado el éxito de las técnicas estadísticas para probar una hipótesis en un conjunto de datos bien comprendidos.

65

4.4.3 CBR vs. Sistemas de producción

Un sistema de producción descrito en el capitulo anterior, representan el

conocimiento a través de la producción de reglas las cuales resuelven partes de un problema, por eso es que a través de un sistema de producción se define el razonamiento basado en reglas (RBR). Las reglas son combinadas para solucionar el problema, la solución es vista como una meta.

Mientras los sistemas de producción se enfocan en como solucionar un problema, el CBR trata de reconocer el problema utilizando su experiencia pasada en resolver problemas similares. Sin embargo, tampoco es factible al igual que las técnicas estadísticas subestimar su utilidad de los sistemas de producción, en los que los sistemas expertos han dado grandes resultados.

Ambas técnicas han sido utilizadas para proveer diagnósticos. Sin embargo las diferencias fundamentales entre el CBR y un sistema de producción son presentadas a continuación:

• Los sistemas de producción requieren de conocer a fondo el dominio del problema y entender como se soluciona un problema. Mientras que el CBR utiliza la experiencia pasada para resolver un problema similar.

• El CBR tiene la habilidad de incrementar su aprendizaje sin la necesidad de

modificar o agregar nuevas reglas.

• El CBR provee justificación ofreciendo casos previos como precedentes de una solución aceptada.

Características RBR CBR Área del problema Limitado y especifico, bien

entendido, teoría de dominio bien especificada, estable

Amplio, pobremente entendido

Representación del conocimiento

Hechos y reglas IF-THEN Casos

Resultados del sistema

Respuestas Precedentes

Justificación del resultado

Trazado o seguimiento de las reglas disparadas

Precedentes

Capacidad de aprendizaje

No, usualmente requiere la modificación manual o agregación de nuevas reglas

Si, por adquisición de casos

Tabla 2. Comparativa entre el RBR y el CBR.

66

En la tabla 2, se presentan las diferencias entre las técnicas CBR y los sistemas de producción [54]. Se puede entender entonces que para aplicar el RBR un problema debe estar bien entendido y limitado sin posibilidad de cambiar en el tiempo. Cuando el problema no es bien comprendido o es dinámico en el tiempo el CBR es aplicado adecuadamente.

4.4.4 CBR vs. Máquinas de aprendizaje

Una máquina de aprendizaje involucra el análisis de casos previos para derivar

reglas que se aplican a un conjunto de casos. Estas reglas pueden entonces aplicarse a nuevos problemas. La máquina de aprendizaje claramente separa los procesos de aprendizaje de reglas y solución de problemas. El algoritmo de inducción utilizado potencialmente en un sistema CBR deriva de la máquina de aprendizaje. La distinción más importante es que la máquina de aprendizaje justifica su respuesta con base en las reglas que fueron inducidas del entrenamiento y en el CBR utiliza los casos recuperados como precedentes.

4.4.5 CBR vs. Redes neuronales

A grandes rasgos una red neuronal y el CBR tienen la similaridad de basarse en

casos previos con conocimiento de los resultados para informar sus decisiones. Sin embargo, los sistemas neuronales tienen un mejor rendimiento en dominios donde los datos no pueden ser representados de manera simbólica sino puramente numérica; caso contrario con el CBR que tiene un mejor rendimiento para estructuras simbólicas.

La mayor desventaja de una red neuronal radica en que es concebida como una caja negra. La respuesta dada esta en función de vectores con pesos, característicos de sus neuronas.

Finalmente, en la tabla 3 se muestra en resumen las diferencias entre el CBR y otras técnicas de razonamiento [54].

67

Tecnología Es utilizable cuando No es utilizable cuando Recuperación de información

Grandes volúmenes de datos en textos

Tipos de datos complejos no textuales, se requiere un conocimiento de fondo

Técnicas estadísticas

Grandes volúmenes de información bien comprendida con una hipótesis bien formada

Análisis exploratorio de datos con dependencia de variables

Razonamiento basado en reglas

Problema bien entendido y limitado, teoría del dominio robusta y justificación por seguimiento de reglas

Problema pobremente entendido con constantes cambios en el tiempo

Máquina de aprendizaje

Reglas generalizables que son requeridas para entrenamiento y justificación por seguimiento de reglas

Reglas no requeridas y la justificación por seguimiento de reglas no es aceptable

Redes neuronales

Información numérica con entropía, reconocimiento de patrones o procesamiento de señales

Información simbólica compleja o cuando la justificación es requerida

Razonamiento basado en casos

Problema pobremente entendido con estructura compleja, que cambia lentamente en el tiempo y justificación por precedentes

Cuando información de casos no está disponible, una adaptación requerida es requerida o si una respuesta óptima es requerida

Tabla 3. Comparativa de técnicas de razonamiento

4.5 Aplicaciones del razonamiento basado en casos

Para la aplicación del CBR, se debe establecer cuales son las características de los dominios en donde puede tener un mejor rendimiento. Algunas características se definen a continuación [54]:

• Una persona que sepa resolver problemas (experto) puede definir un caso. • Un experto en el dominio del problema compara habitualmente un problema con la

experiencia pasada. • Expertos adaptan casos para solucionar nuevos problemas. • Los casos pueden estar disponibles en fuentes informáticas o por establecimiento de

los expertos y pueden ser guardados como soluciones. • Existen elementos en el dominio para saber si una solución es exitosa o fallida. • Las características de un problema pueden ser abstraídas. • El dominio puede tener o no tener un modelo robusto.

68

La aplicación del razonamiento basado en casos esta dirigida hacia dos tipos de problemas: clasificación y síntesis de tareas [54]. La clasificación de tareas utiliza casos como punto de referencia para determinar el tipo, o la clase de un caso e involucran problemas tales como: diagnóstico, predicción, evaluación, control de procesos, planeación y recomendación. La síntesis de tareas utiliza los casos para crear una nueva solución haciendo uso de las partes de las soluciones anteriores e involucran problemas tales como: diseño, planeación y configuración.

El CBR ha sido aplicado a una amplia gama de tareas de la inteligencia artificial, a continuación se enuncias las principales áreas de aplicación del CBR [31, 54]:

• Razonamiento creativo. El CBR tiene un conjunto de tareas que pueden ser refinadas o mejoradas a través de nuevas técnicas que involucran algoritmos. La creatividad radica en mejorar la precisión de un sistema CBR.

• Búsqueda de conocimiento. El problema de encontrar información en un tópico de

interés es abordado por el CBR y juega un papel importante en el desarrollo de librerías digitales de información en línea. Las lecciones aprendidas acerca de la indexación y recuperación de información en el CBR son de utilidad para ayudar a caracterizar la información y la búsqueda guiada.

• Demostradores académicos. Dentro del ámbito académico, se han realizado

esfuerzo para aplicar lecciones de un modelo cognitivo del razonamiento basado en casos para el entrenamiento y enseñanza. Un campo importante es el de la medicina, en donde se tienen casos médicos y tratamientos asociados en donde la complejidad de los episodios y el tiempo para realizar el diagnóstico son de vital importancia.

• Sistemas integrados. La investigación de las combinaciones del CBR con otras

técnicas de razonamiento, se han centrado en mejorar la precisión del sistema en el que intervienen dichas técnicas. Algunos ejemplos muestran la combinación del CBR con: técnicas inductivas de aprendizaje, razonamiento basado en reglas [8, 24, 26].

• Soporte de otros sistemas. Ya que los sistemas CBR recuperan soluciones, pueden

ofrecer en cualquier momento la habilidad de producir como primer paso una solución y entonces refinarla. Un sistema que no tenga restricciones en tiempo puede utilizar al CBR para llegar a soluciones razonadas. Tal es el caso de los sistemas de recomendación turística [16, 21, 36, 37, 45].

• Memorias corporativas. Los casos base son un medio para capturar las

experiencias pasadas. Las librerías de casos entonces son una fuente de conocimiento en sistemas para soporte de sistemas informáticos (help-desk) como un ejemplo de memorias corporativas y son un ejemplo de conocimiento compartido.

69

Para fines de este trabajo, se detallaran las aplicaciones del CBR en el ámbito del

turismo como lo son los sistemas de recomendación turística, en el siguiente capítulo.

4.6 Resumen

Este capítulo y el capitulo anterior son de vital importancia para éste trabajo de tesis. Ya que son las bases para el desarrollo de un sistema de recomendación turísticas basado en el razonamiento basado en reglas y casos.

En este capítulo se ha definido al CBR, los problemas que puede solucionar. Además se han identificado los procesos y tareas que sigue el ciclo de aprendizaje basado en casos. Estos fundamentos serán utilizados para el diseño del sistema de recomendación basado en el CBR. En el sistema que se propone en este trabajo de tesis el CBR es utilizado para proponer itinerarios turísticos basados en las preferencias del usuario.

Se establecen los criterios para definir un dominio de aplicación del CBR, las capacidades y debilidades de este tipo de razonamiento y de otras técnicas de razonamiento detallando en el razonamiento basado en reglas que servirá como sustento de este trabajo.

El siguiente capítulo se abordará y describirá los trabajos relacionados a los sistemas de recomendación turística en donde se identificarán las capacidades y debilidades de los mismos. Lo cual servirá como base para el sistema propuesto.

71

5. Trabajo relacionado

Durante los últimos años, los sistemas de recomendación turística (SRT) se han desarrollado dentro del ámbito del comercio electrónico tratando de ayudar a los consumidores a seleccionar productos que concuerdan con sus necesidades. Las investigaciones hacia el desarrollo de los SRT, así como técnicas que ayuden a soportarlos han proliferado gracias a la investigación en este tópico [12, 13, 16, 25, 32, 37, 45]. El objetivo fundamental de estos sistemas es aprender los comportamientos de los usuarios para sugerirles productos de interés.

El paradigma de razonamiento que se han tomado como base en el desarrollo de los SRT turística ha sido principalmente el razonamiento basado en casos (CBR), siendo el de mayor explotación el CBR, el motivo principal es la representación del dominio de aplicación. Como se ha descrito en el capitulo 4, la metodología del CBR se base en encontrar un caso similar que resuelva un nuevo problema basándose en sus experiencias pasadas. El enfoque general del CBR en este contexto se dirige hacia la recomendación o sugerencias de productos, los cuales se recuperan de un conjunto de casos base, que representan productos similares a los requeridos por el usuario [36, 44, 45, 47]. En dicho enfoque, el producto requerido es descrito a través de los valores que el usuario establezca para las características que definen a dicho producto. En dado caso, si el producto no satisface al usuario, el usuario puede modificar sus preferencias hasta encontrar otro producto de interés.

Aunque se han propuesto algunos enfoques sobre el desarrollo de SRT basados en CBR, hasta el momento solo se ha desarrollado una metodología formal en el desarrollo de estos sistemas Trip@dvice [45], además de sistemas demostrativos de esta metodología. Por lo cual éste trabajo de tesis se ha basado en dicha metodología para proveer un nuevo enfoque acerca de la construcción de un STR basado en CBR. Esta metodología se describirá en la sección 5.1.

72

El razonamiento basado en reglas (RBR) también se ha utilizado para la

recomendación de productos turísticos hasta el momento el principal enfoque se ha establecido en el proyecto @lis-Technet [3]. El sistema de recomendación y planeación turística que se ha desarrollado en este proyecto ha dotado a un sistema multiagente de un mecanismo de razonamiento como el RBR [4, 6, 7]. Básicamente el sistema es visto como un sistema experto que divide el problema en división de tareas para la recomendación de paquetes y productos turísticos geográficamente dispersos. Este sistema se detallará en la sección 5.1.1.

Otros enfoques, como el desarrollo de STR bajo el paradigma de los sistemas multiagente [57], han sido desarrollados en trabajos como [12, 16, 37, 40]. La idea principal es la división del problema en tareas, donde cada una puede estar a cargo de uno o más agentes. Además, existen los STR comerciales [19, 20, 41, 53] que también serán analizados en este capítulo

Todos estos enfoques intentan dar solución tanto al problema de recomendación de productos turísticos [19, 20, 38, 41, 47, 53] como a la planeación de un itinerario turístico [2, 38, 47]. En las siguientes secciones se analizarán los enfoques mencionados anteriormente, además de otros sistemas de recomendación que combinan el RBR y CBR con la finalidad de analizar en que medida la combinación de ambos mecanismos de razonamiento pueden beneficiar el comportamiento de un sistema.

5.1 Sistemas de recomendación turística basados en CBR

Dentro de la investigación acerca de los sistemas de recomendación basados en CBR, se han producido prototipos que ha probado la eficiencia de la metodología del CBR [16, 21, 27, 32]. Sin embargo, en este documento solo se analizarán los sistemas de recomendación turística basados en CBR como un preámbulo al trabajo propuesto en esta tesis.

Debido a la naturaleza del problema de planificación de un viaje – el cual contiene un conjunto de productos como: transporte, alojamiento, restaurantes y actividades turísticas que pueden tener diferentes proveedores – existe la necesidad de realizar la búsqueda de información en línea para conformar un plan adecuado para el usuario. En sitios comerciales como [], existen paquetes turísticos predefinidos que son sugeridos al usuario, pero es claro que un problema y la solución asociada no pueden ser productos predefinidos en un catalogo.

Un primer intento en aplicar el razonamiento basado en casos en el ámbito del turismo fue el sistema CABATA descrito en [47] puede clasificarse como un sistema de recomendación basado en contenido y propone la utilización del CBR como una

73

herramienta para realizar peticiones (queries) basadas en similaridad hacia un catalogo. El usuario define los parámetros de las peticiones y el sistema recuperara los recursos que satisfagan las condiciones o aquellos que pueden no cumplir las condiciones, pero que son similares. La limitación en este sistema es que la metodología del CBR esta orientada hacia la selección de una petición adecuada (query) y no guarda la solución al problema una vez seleccionada por el usuario. La modelación de los casos presentada en este sistema propone a un caso como un producto, donde los usuarios hacen peticiones de productos especificando las características del producto de su interés, siendo ésta una limitante que perjudica la eficiencia del sistema al considerar una gran cantidad de productos. Existen más enfoques similares [32] a CABATA que no necesariamente especifican la metodología de diseño por lo que no constituyen una modelación formal del problema y no serán tomados en cuenta en este trabajo.

Se ha desarrollado dentro de la investigación de los STR basados en CBR, una metodología formal para la construcción de este tipo de sistemas llamada Trip@dvice [45], que modela a un sistema de recomendación turística, hasta el momento es la única que se conoce en su tipo. Dicha metodología tuvo como motivación principal de abordar el problema de proveer a un STR de la capacidad para conformar itinerarios basándose en la experiencia adquirida. Existen dos sistemas prototipos que han implementado esta metodología: el sistema recomendador DieToRecs [21] y Nutking [38, 47]. En el caso de DieToRecs, solo extiende algunas funcionalidades de Nutking. Y dado que DieToRecs no se encuentra disponible actualmente (en línea), se tomará a Nutking para posteriores análisis.

5.1.1 Metodología Trip@dvice

Dentro del proyecto DieToRecs [17], se originó la metodología Trip@dvice. Este proyecto se estableció para desarrollar y validar un sistema de recomendación de destinos turísticos basado en filtrado de contenido y filtrado colaborativo o CBR. Siendo su principal orientación la recomendación personalizada basada en la información obtenida de un perfil del usuario.

La metodología Trip@dvice [45], se define como una metodología de recomendación híbrida que integra: el CBR, un manejador de peticiones interactivas y un filtrado colaborativo. Los principales requerimiento que han fundamentado el desarrollo de esta metodología son:

• Los productos y servicios turísticos tienen estructuras complejas, donde cada uno de ellos consta de uno o más ítems complejos. Un itinerario turístico puede constar de un transporte, alojamiento y actividades.

• Los sistemas de recomendación basados en Trip@dvice deben permitir al usuario

generar un itinerario de diferentes productos turísticos (lugares a visitar,

74

alojamientos, atracciones y servicios) y tener la capacidad de proveerle de paquetes turísticos ya conformados.

• La metodología de recomendación debe soportar la implementación de funciones de

búsqueda avanzada que sean percibidas por el usuario como convencionales y que sean fáciles de utilizar. Las peticiones generadas por el sistema de recomendación deben ser especificadas a través de rangos de búsqueda para productos y servicios y para paquetes turísticos.

• El sistema debe ser autosuficiente, aún cuando no existan los casos para resolver su

petición. Si el sistema no ha aprendido lo suficiente, entonces funciones de búsqueda más sencillas deben estar disponibles.

• El sistema debe permitir la misma funcionalidad para usuarios registrados y no

registrados. Lo que involucra únicamente proveer la experiencia adquirida del sistema en la sesión actual de recomendación.

• La metodología debe soportar un gran número de tipos de usuario definidos por sus

decisiones de estilos. De esta manera, se soporta a los usuarios que tienen conocimiento de lo que necesitas y los que tienen ideas vagas de lo que necesitan.

• El sistema no debe asumir que los productos y las necesidades del usuario se

traslapan en su definición. La caracterización de las preferencias del usuario, las cuales son conocidas, debe ser utilizada para influir o determinar una elección.

Modelación de casos

En la metodología Trip@dvice, un caso representa la interacción del usuario con el sistema y es construida incrementalmente durante la sesión de recomendación, como se puede apreciar en la figura 9. Un caso esta conformado por los siguientes componentes [45]:

• Características colaborativas. Estas características capturan las preferencias relevantes del usuario para el proceso de toma de decisión, por lo que no pueden ser mapeadas a características de productos en catálogos electrónicos. A través de estas características se mide la similaridad de los casos.

• Peticiones contenidas. Estas peticiones están dirigidas hacia los catálogos de

productos, son construidas con base en las características restrictivas del usuario.

• Contenedor (cart). En esta estructura se almacena un conjunto de productos seleccionados por el usuario durante la sesión de recomendación. Los productos dentro del contenedor pueden ser calificados por el usuario una vez que el viaje termine.

75

Figura 9. Ejemplo de un caso bajo la metodología Trip@dvice

En la figura 9, se presenta un ejemplo de un caso. Un usuario, quien viaja solo, tiene

un presupuesto entre $2,000 y $5,000 y esta buscando un viaje turístico (destinos y alojamientos) donde practicar algunos deportes (montaña y caminata), todas estas preferencias constituyen las preferencias colaborativas. Entonces se establecen dos peticiones sobre los catálogos de productos lo que representan las restricciones de contenido en las características de los productos. Además, el usuario desea alojarse en un hotel de tres estrellas que tenga alberca y que cueste menos de $1,000 por noche. Dadas estas preferencias, el usuario selecciono y agregó a su carro, el hotel abrevadero y al Ajusco y Malintzi como lugares para vacacionar. Recomendación de productos

La metodología soporta diferentes estilos de decisión como lo son [45]: selección iterativa de un solo ítem de viaje, la búsqueda por inspiración y selección de un itinerario de viaje completo. Selección iterativa de un solo item de viaje

El proceso de selección iterativa de un solo ítem se da cuando el usuario interactúa con el sistema recomendador para solicitarle recomendaciones acerca de un tipo de producto, este proceso es mostrado en la figura 10. Sea q la query del usuario para un catálogo de productos del tipo especificado, entonces la solicitud esta dada por la función pedirRecomendacion(q). El sistema contesta a la query q con algunos productos recomendados y si falla en encontrarlos, entonces se inicia un refinamiento de la query, en donde se puede intensificar o relajar una query. El proceso de relajación de query consiste

76

en quitar restricciones de la query o bien agregar restricciones en el caso de intensificarla. El modulo RecEngine administra la solicitud. Primero, se invoca a la función de EvaluarQuery(q) del manejador inteligente de una query (IQM) pasando la query correspondiente.

Figura 10. Recomendación de un solo ítem en la metodología Trip@dvice

La función EvaluarQuery(q) busca los productos que satisfagan a la query, si

existen demasiados productos como resultado se produce un refinamiento de la query llamando a la función PrecisarQuery(q) donde el sistema busca en el catálogo del producto un conjunto de tres características importantes, las cuales son presentadas al usuario para que las manipule y realizar una nueva búsqueda [45]. Si no existen productos se llama a la función RelajarQuery(q), donde se busca un conjunto de tres características importantes que puedan ser eliminadas de la misma manera que el caso anterior. Si se da nuevamente el caso de que no existan nuevamente resultados luego del proceso de refinamiento el sistema provee de una explicación al usuario enunciando los motivos por los cuales no existen resultados.

Cuando existe un conjunto de ítems recuperados entonces los productos son clasificados llamando a la función Clasificar. Ésta función recibe el caso actual y el conjunto de productos sugeridos seleccionados por la función EvaluarQuery(q). El caso actual es utilizado para recuperar un conjunto de n casos similares y los productos contenidos en dichos casos son utilizados para clasificar los productos seleccionados. Finalmente, los productos clasificados son presentados al usuario.

77

La puntuación del producto final se calcula multiplicando los casos y los productos similares imitando el enfoque de un filtrado colaborativo:

Similaridad(caso, caso_recuperadoi)*Similaridad(productoi, producto_recuperadoi)

Las diferencias señalizadas con respecto al enfoque clásico del filtrado colaborativo son en primer lugar que el enfoque clásico solo utiliza un único vecino más cercano y en este caso se usan un conjunto de casos similares para explicar el valor de la puntuación al usuario. Si se utilizara el enfoque clásico tendría que establecer una puntuación de acuerdo al promedio de pesos de los casos. Tampoco se han considerado utilizar los votos de otros usuarios, sino que se utiliza la similaridad del producto a ser ponderado con respecto a los productos seleccionados en un caso similar visto como una clasificación de votos implícita. Búsqueda de inspiración

Un segundo estilo de decisión soportado por la metodología Trip@dvice es la búsqueda de inspiración. Este caso esta dirigido a los usuarios que buscan opciones para identificar sus preferencias a través de ciertas alternativas antes de tomar una decisión de enfocarse en algunos productos en particular. La recomendación de búsqueda de inspiración considera los siguientes procesos [45]:

• Recuperación primaria. Este proceso se inicia con un caso “semilla”, el cual puede ser el caso actual o un caso seleccionado de manera aleatoria de la librería de casos base. En el primer caso, el usuario ha introducido sus preferencias por lo que el sistema tiene conocimiento del usuario y en el segundo caso su conocimiento es nulo porque el usuario inicia directamente en este proceso. Entonces, el módulo de recuperación busca los m casos similares en la librería de casos base respecto del caso objetivo y envía el conjunto de casos resultado al módulo de selección.

• Selección de casos. En un segundo paso, el conjunto de m casos recuperados son

analizados para seleccionar un subconjunto de casos relevantes para ser presentados al usuario. Cada caso minimiza su similaridad con respecto al anterior.

• Explicación. Este módulo esta dirigido a analizar los casos seleccionados

acentuando sus diferencias. Esto se realiza analizan las tres características que son más diferentes en todos los casos y tanto los casos seleccionados como las características son pasadas al modulo de presentación.

• Presentación. El objetivo de este modulo es presentar los casos seleccionados

agregando una explicación de la particularidad de cada caso, la explicación consiste básicamente en argumentar que un itinerario es más interesante que otra con base en las características relevantes obtenidas.

78

• Recuperación. La segunda vez que se lleva a cabo la recuperación se llama al procedimiento descrito en la recuperación primaria pero ahora el caso inicial o “semilla” es el que el usuario ha otorgado su interés.

Todos los procesos anteriores son descritos de manera visual en la figura 11.

Figura 11. Búsqueda de inspiración de la metodología Trip@dvice

Selección de un itinerario de viaje completo

El proceso de selección de itinerario de viaje completo provee al usuario la capacidad de agregar un conjunto de ítems turísticos previamente elegidos. El usuario debe el conjunto de características colaborativas (preferencias del viaje y preferencias de los ítems turísticos). Entonces el sistema generará al usuario un conjunto referencia de casos, como el descrito en el proceso de selección de un solo ítem de viaje pero en el actual proceso el conjunto de casos es mostrado al usuario como una plantilla de itinerario. Los casos del conjunto referencia son utilizados para generar un conjunto de ítems apropiados hacia el usuario. Cuando el usuario muestra un interés en algún itinerario de viaje y desea eliminar o agregar algún ítem entonces el sistema buscara ítems similares a los que se encuentran en la plantilla o itinerario conformado y adapta el itinerario de recomendación [11]. Métricas de similaridad

Las funciones de recomendación descritas en esta sección explotan la recuperación y cómputo basados en la similaridad [45]. La primera se refiere a la similaridad entre dos casos y la segunda a la similaridad de un caso base con respecto a un conjunto de casos. Dentro de la metodología Trip@dvice un caso puede ser visto como un vector de

79

características colaborativas (cnf), características de contenido (cnq), el contenedor de ítems (cart) y el rating del caso (r), entonces se tiene la representación de dos casos de la siguiente manera:

c = (clf, cnq, cart, r) y c’ = (clf’, cnq’, cart’, r’)

Tanto para la similaridad de casos como de productos se ha utilizado una versión de la distancia euclidiana llamada Métrica de traslape euclidiana [10]. Si x y y son dos vectores característicos de un producto o caso, entonces se tiene que [45, 46]:

− ∑∑

==

=

2

1

1

)),((1

),(

iii

n

iin

ii

yxdw

w

eyxSim

(1)

Los vectores característicos pueden ser por ejemplo: x = (x1, x2,..., xn) un ítem de

alojamiento que se encuentra en el conjunto de referencia (casos recuperados similares a un caso c), y y = (y1, y2,…, yn) es un ítem de alojamiento que se encuentra en el catálogo que puede satisfacer las restricciones del usuario. Donde di(xi,yi), (1 ≤ i ≤ n) es una versión adaptada de la Métrica de traslape euclideana heterogénea, y es definida como sigue [45, 46]:

( )

−=

i

ii

iiiyx

yxd

σ4

0

1

,

Si la i-ésima característica es simbólica y xi ≠ yi

Si la i-ésima característica es simbólica y xi = yi

Si la i-ésima característica es numérica

(2)

La distancia euclideana, si la característica es numérica, es normalizada a través de dividir dicha distancia entre 4 veces la desviación estándar (σ).

Para este cálculo de similaridad se toman en cuenta tanto las características que el usuario ha definido explícitamente como las que no definió y es descrito como sigue:

re FFF ∪=

Donde F representa el conjunto de las características que ha especificado en

conjunto con las demás características que se establecieron para el producto. Por ejemplo, un usuario define requiere facilidades f = (precio, aire-acondicionado, t.v.) para un ítem alojamiento, siendo que un alojamiento puede estar definido como a = (lugar, precio, aire-acondicionado, t.v., frigo-bar, jacuzzi, internet). Entonces se tendría:

80

{ }{ }ernetjacuzzibarfrigolugarF

vtadoacondicionaireprecioF

r

e

int,,,

.,,

−=−=

Entonces, si el conjunto de referencia contiene n-casos, se tomará en cuenta la

frecuencia con que cada característica aparece en el conjunto de referencia. Proporcionalmente a su frecuencia, se asignan los valores de los pesos de manera simple [45]:

R

ffreqw i

i

)(= (3)

donde freq(f i) es la frecuencia de la característica fi y |R| es el valor absoluto de la cardinalidad del conjunto referencia R.

De esta manera, se ponderan las características de los ítems. Para dejar en claro este concepto, se retoma el ejemplo de los ítems de alojamiento, suponiendo que el conjunto referencia tiene 5 elementos, entonces esta relación puede verse de la siguiente manera [45]:

Característica Frecuencia Peso Lugar 3 0.6 Precio - 1.0 Aire acondicionado - 1.0 Televisión - 1.0 Frigo-bar 4 0.8 Jacuzzi 2 0.4 Internet 5 1.0

Tabla 4. Ponderación de pesos en la metodología Trip@dvice

Dentro del proyecto DieToRecs [17], se desarrollaron dos prototipos que

ejemplificaban el uso de la metodología Trip@dvice: Nutking (o ITR) y el sistema recomendador DieToRecs como una extensión de Nutking. Sin embargo, el único que continúa disponible en línea es el primero.

81

5.1.2 ITR: Un sistema de recomendación inteligente de viajes

El sistema Nutking o ITR (Intelligent Travel Recommender) [38, 47] incorpora un modelo de selección humana extraído de análisis del comportamiento de los turistas y extiende los enfoques de sistemas de recomendación de [45]. El objetivo en el desarrollo de ITR fue crear un sistema que entienda las peticiones del usuario para sugerirle o responder sus cuestionamientos así como inferir una respuesta de un conjunto de datos conocidos para proveerle una respuesta aproximada a lo que requiere.

El ámbito de destinos turístico en donde se desarrolla ITR es la región de Trentino, Italia; [38, 47] en otras palabras, es un sistema de recomendación turística para dicha ciudad. Los deseos de viaje de acuerdo a este ámbito, son las preferencias del viaje que se enuncian a continuación:

• Acompañantes de viaje = {solo, con acompañante, con amigos, con familia, con un grupo turístico}

• Transporte = {automóvil, camper van, bicicleta, motocicleta, tren, autobús} • Clase de alojamiento = {hotel, departamento, cuarto privado} • Presupuesto diario para alojamiento = {menos de 20€, entre 20€ y 40€, entre 40€ y

80€, más de 80€}

• Lugar de origen = {Italia, Europa, África, Asia, Norteamérica, Sudamérica, Oceanía}

• Mes para asistir = {Enero, Febrero, Marzo, Abril, Mayo, Junio, Julio, Agosto,

Septiembre, Octubre, Noviembre, Diciembre}

• Tiempo de estadía ={un día, de 2 a 3 días, una semana, dos semanas, más de dos semanas}

• Actividades turísticas ={Deporte, Aventura, Relajación, Arte y Cultura, Vino y

Comida, Naturaleza, Ejercicio y Bienestar}

• Visitas a Trentino = {ninguna, en algunas ocasiones, frecuentemente}

Todo este conjunto de características que representan los deseos de viaje son tomadas de la interfaz de usuario del sistema Nutking [38], como se aprecia en la figura 12.

82

Figura 12. Introducción de las preferencias del usuario en la interfaz de usuario de Nutking.

ITR soporta la selección de productos de viaje, construye un portafolio de viaje con

base en los ítems seleccionados por el usuario. El portafolio de viaje solo almacena ítems sin un horario o planeación temporal, desde el punto de vista de los desarrolladores no están de acuerdo con estos últimos dos tipos de planteamientos. El sistema explota estos portafolios de viaje como casos base, cada caso se implementado como una estructura jerárquica en XML.

La modelación de un caso en ITR, c = (twc, tb, u, r) como se aprecia en la figura5, tiene las siguientes características: deseos de viaje (twc), portafolio de viaje (tb), usuario (u) y recompensa (r). El ejemplo de la figura 13, ha sido tomado de la introducción de datos al sistema.

Figura 13. Caso ejemplo en el sistema Nutking

Una vez que se establecen las preferencias del usuario, el sistema divide el itinerario de viaje en [38, 47]: Lugáres de interés en Trentino, alojamientos, actividades deportivas, eventos y cultura; como se puede apreciar en la figura 14.

83

Figura 14. Opciones para seleccionar ítems en Nutking.

La búsqueda de lugares en Trentino, esta en función de las actividades turísticas que

se desean realizar (museos, paracaidismo, folklore, música, etc) y de la altitud de la ciudad respecto del nivel del mar [38], esto puede apreciarse en la figura 15. De manera similar ocurre con las demás opciones como: alojamientos, actividades deportivas, eventos y cultura.

Figura 15. Selección de lugares turísticos en la región de Trentino, Italia en Nutking

84

Cuando ocurre que el usuario desea ver las sugerencias que el sistema pueda darle

acerca de planes anteriormente conformados (casos previos), el sistema toma las preferencias del usuario y le proporciona los 5 casos similares [38].

Figura 16. Recomendaciones de itinerarios turísticos en Nutking

Una vez que el usuario agrega el plan a su perfil de usuario, entonces puede manipularlo de manera que ahora puede agregar o eliminar ítems turísticos, además de modificar las preferencias para el itinerario de viaje, lo anterior puede ser apreciado en la figura 17 [38].

85

Figura 17. Manipulación de un itinerario recomendado en Nutking

El sistema nutking es un sistema en línea (web) que permite a un usuario que desea viajar a la región de Trentino, Italia recursos turísticos unitarios como (alojamientos, actividades turísticas, lugares de interés, eventos y cultura) además de itinerarios ya conformados con base en las preferencias del usuario. En cada una de estas recomendaciones se utiliza el beneficio de la metodología CBR que es la experiencia en resolver-problemas con base en precedentes.

La arquitectura implementada por el sistema Nutking, mostrada en la figura 18, se compone de los siguientes módulos [47]:

Figura 18. Arquitectura del sistema Nutking.

86

• Web GUI. Constituye la interfaz del usuario a través de la cual se interactúa con el sistema. La interacción con el sistema involucra la interpretación de los comandos del usuario.

• Objetos de negocio. En este modulo se incluye el manejador del portafolio de viaje,

el cual tiene como propósito almacenar, recuperar y actualizar los portafolios de viaje. El manejador de ítems de viaje permite manipular los ítems turísticos para ser mostrados. El razonador administra al manejador inteligente de query y el proceso de categorizar los ítems (ranking).

• Medidador Inteligente. Incluye un servicio de query estándar y el servicio de

query inteligente. El primero provee la funcionalidad básica para la recuperación y almacenamiento hacia y desde el repositorio como documentos XML. El segundo extiende al servicio estándar de query soportando diferentes formas de querying y categorización de documentos (ranking).

• Repositorio de datos. Una base de datos relacional, donde se encuentran

aproximadamente 100 tablas.

5.2 Sistema de recomendación y planeación del proyecto @lisTechnet

El proyecto @lisTechnet ya ha sido previamente introducido en el capítulo 1. Como se describió en la sección 1.2.2, dentro de los objetivos del proyecto se encuentra la disposición de un demostrador capaz de crear servicios personalizados de carácter cultural o turístico que sean accesibles por Internet (en línea) desde un PC y/o dispositivos inalámbricos (teléfonos móviles, PDAs1, etc) a través de la composición dinámica de los servicios instalados por los distintos socios en los diferentes países de los socios del consorcio.

La tarea principal de este objetivo es entonces proveer una aplicación innovadora de turismo y herencia cultural usando la plataforma de prueba Agentcities2 que es capaz de integrar dinámicamente datos de turismo/culturales de diferentes países de modo que se facilite al usuario la planeación de viajes y actividades. Esta tarea involucra el desarrollo de una aplicación con base en el paradigma de los sistemas multiagente (MAS). Por lo que en los párrafos subsecuentes se abordara brevemente el marco teórico de los sistemas multiagentes [57].

Un sistema multiagente es un sistema compuesto de múltiples elementos de cómputo, conocidos como agentes. En un sistema multiagente, se pueden simular cierta

1 Personal Digital Assistant o ayudante personal digital 2 Puede ser vista como una ciudad virtual que está conformada por usuarios, agentes y servicios.

87

clase de actividades sociales humanas, por lo que también se les puede conocer a los sistemas multiagente como sistemas sociales artificiales. La entidad fundamental dentro de un sistema multiagente son los agentes. La Inteligencia Artificial Distribuida (Distributed Artificial Intelligence - IAD) es un subcampo de la AI que intenta construir un modelo del mundo poblado por entidades autónomas, inteligentes que interactúan por medio de la cooperación, la coexistencia o por la competición; entonces es ahí donde nace el concepto de un sistema multiagente.

Un agente, de manera general, puede definirse como todo aquello que puede percibir su ambiente mediante sensores y que puede responder por medio de efectores. Un ejemplo básico de un agente es un sistema de control. Otra definición más enfocada en el ámbito de la computación, se basa en que un agente es un sistema computacional situado en algún ambiente y que tiene la capacidad de realizar acciones autónomas en ese ambiente para cumplir con sus objetivos de diseño.

Sin embargo, las características principales de un agente son: la autonomía y la interacción con otros agentes (actividades sociales). La autonomía esta definida por la capacidad de tomar decisiones con base en la experiencia obtenida por él mismo y/o aportada por el diseñador. En el caso de la interacción con otros agentes, ésta no solo abarca el concepto de intercambiar información sino que también debe concebir conceptos como: cooperación, coordinación y negociación, entre otras cosas; es por ello que se dice que se simulan actividades sociales humanas, aunque la interacción se da a través de la comunicación entre los agentes.

En la comunicación entre agentes es necesaria una ontología, la cual es una definición formal de un dominio de conocimiento, que permita una comunicación semántica correcta. La construcción de una ontología involucra una estructura de componentes, que esencialmente es una taxonomía de relación entre clases y subclases relacionadas entre sí.

5.2.1 Descripción del sistema demostrativo @lisTechNet

El sistema demostrativo desarrollado en @lisTechnet puede ser concebido como un

sistema multiagente creado con la finalidad de recomendar y realizar la planeación de itinerarios turísticos a múltiples destinos a nivel país, en donde los recursos turísticos (alojamientos, transportes, actividades) están dispersamente distribuidos de manera geográfica.

El sistema demostrativo esta orientado a realizar las actividades de una agencia de viajes, realizando para ello las siguientes tareas [4, 6, 7]:

• Capturar y estructurar las preferencias del usuario. Encapsulamiento de las preferencias del usuario.

88

• Planificar un itinerario de viaje de manera jerárquica por país, identificando

niveles de planeación a tres niveles: País (primera división), Estado (segunda división) y Ciudad (tercera división). Un itinerario está completo cuando en él se encuentran transportes que conecten las ciudades del itinerario, el alojamiento para todas o algunas ciudades dependiendo de la definición de los paquetes turísticos (se detallará en párrafos posteriores).

• Recomendar recursos turísticos. El sistema sugiere al usuario los ítems que

pueden conformar al itinerario y que se encuentran en el rango de sus preferencias. Por cada ítem o recurso turístico se provee información detallada para que el usuario tenga una mejor idea del tipo y calidad del recurso.

• Permitir la re-planificación , si es el caso. Un usuario puede no estar de acuerdo

con las recomendaciones que el sistema le ha generado entonces puede requerir que se vuelvan a recomendar nuevos recursos turísticos que van desde un estado, una ciudad o bien, alojamiento, transporte, actividades.

• Reservar, comprar y cancelar itinerarios turísticos. Una vez que el usuario esta

de acuerdo con el itinerario turístico puede reservarlo, lo que involucra que todos los recursos dentro del itinerario serán reservados al igual que si desea cancelarlo o comprarlo.

• Responder a contingencias. El sistema es capaz de monitorear el clima en los

destinos a los cuales los usuarios han reservado o comprado un itinerario turístico, en caso de haber alguna contingencia el sistema envía información acerca de la contingencia para que el usuario pueda modificar su itinerario.

• Guardar la sesión del usuario. Un usuario debe registrarse en el sistema para

poder acceder a sus funcionalidades. Por lo que un usuario puede almacenar su itinerario una vez satisfecho sus preferencias.

• Incorporación dinámica de proveedores de servicios. El sistema tiene la

capacidad de agregar a más proveedores de servicios de cualquier país, basándose en las especificaciones de la arquitectura del sistema.

La aplicación contempla las siguientes preferencias a ser especificadas por el

usuario [2]:

• Origen. Ciudad de donde parte el usuario • Destino. País o conjunto de países a donde desea realizar un itinerario turístico

• Fecha de salida. Fecha en el cual inicia el itinerario

89

• Fecha de regreso. Fecha en la cual regresa a la ciudad de origen

• Máximo costo: Precio o costo máximo deseado para el itinerario turístico

• Lugares de interés. Los lugares son clasificados de acuerdo a los siguientes tipos:

o Lugares relativos a agua o Sitios arquitectónicos o Zoológico o Playa o Bosque lluvioso tropical o Ingenio azucarero o Fabrica de artesanías o Granjas o Tienda de artesanías o Plantaciones de café o Museos o Centros de Ski o Bosque húmedo tropical o Area de preservación o Muros artificiales o Montaña

o Jardín Botánico o Volcán o Ciudad o Puente o Serpentario o Sitios de arquitectura

colonial o Sitios de arquitectura

prehispánica o Cascadas o Océano o Río o Cataratas o Lago o Mar

• Calidad de alojamiento. Debe entenderse que existen alojamiento que

indistintamente del precio son catalogados con una cierta categoría con base en la calidad del servicio proporcionado.

• Calidad de transporte. Se refiere a la calidad del servicio de transporte.

• Calidad de actividades. Se refiere a la calidad de las actividades turísticas.

• Actividades. Las actividades turísticas se han clasificado de manera tipificada

conteniendo así instancias de actividades asociadas al tipo, además una actividad puede pertenecer a más de un tipo. Las categorías de actividad son:

o Agroturismo o Aventura aérea o Aventura acuática o Aventura terrestre o Cultural o Deportes acuáticos o Deportes aéreos o Deportes terrestres o Ecoturismo o Familiar

o Folklore o Gastronómicas o Religiosas o Turismo urbano o Turismo rural

90

Como se puede observar en la figura 19, el sistema demostrativo presenta al usuario

las preferencias a las cuales debe manipular para conseguir un itinerario [2]. De manera inicial, se han considerado solo dos países: México y Costa Rica; para los cuales se pueden proveer itinerarios de para uno o para ambos.

En cualquier sistema de recomendación, los datos que son presentados en la interfaz de usuario constituyen parte del conocimiento que el sistema contiene y del que puede hacer uso para proveer recomendaciones. En este caso, el sistema demostrativo presenta a un mismo tiempo características generales del viaje como son las ciudades origen y destino, costo máximo del viaje y número de viajeros; y características de los ítems de viaje: calidad de alojamiento, calidad de transporte, calidad de actividades, etc.

Figura 19. Interfaz de usuario del demostrador @lisTechnet (a)

91

Dentro de la misma interfaz de usuario [2] se presentan también las características para los recursos turísticos, esto se puede apreciar en las figuras 20 y 21.

Figura 20. Interfaz de usuario del demostrador @lisTechnet (b)

A través de la interfaz de usuario un itinerario es presentado [2], para que el usuario

lo analice y verifique si los recursos o ítems turísticos satisfaces sus gustos o necesidades.Como se puede apreciar en la figura 21.

92

Figura 21. Planeación de un itinerario en @lisTechNet

5.2.2 Arquitectura del sistema

En el diseño del sistema demostrativo, se contempla una jerarquía de agentes

encargados de las diferentes tareas que se han señalado en la sección 5.2.1, como se apreciaen la figura 22.

93

Figura 22. Arquitectura del sistema demostrativo @lisTechNet

Los agentes involucrados en la arquitectura son [4, 7]:

• Personal Agent (PA). Agente que se encarga de estructurar las preferencias del

usuario para proceder a la solicitud de recomendación de un itinerario.

• Global Planner Agent (GPA). Agente que se encarga de interpretar que países están involucrados en el itinerario turístico dividiendo así el itinerario global en itinerarios locales para cada país. Además está involucrado en la tarea de dividir el tiempo de planeación y el presupuesto para cada país, otra tarea de este agente es solicitar el transporte de la última ciudad destino a la ciudad de origen.

• Local Planner Agent (LPA). Este agente se encarga de procesar las preferencias

del usuario para descomponer el itinerario hasta llegar a itinerarios por ciudad, en los que se solicitan los recursos turísticos.

• Service Broker Agent (SBA). Agente intermediario entre el LPA y los finders y

providers. La tarea de este agente es hacer peticiones acerca de los recursos turísticos especificados y almacenar los resultados en una memoria caché.

• Finder. Agente encargado de buscar ofertas turísticas en una ciudad en un lugar

especifico. Se establecen tres categorías para este tipo de agente: Accommodation Finder (buscador de alojamientos), Transport Finder (buscador de transportes) y Activity Finder (buscador de actividades turísticas).

• Provider. Agente que es el encargo de realizar las operaciones de reserva, compra y

cancelación de un itineario turístico. Se establecen tres categorías para este tipo de

94

agente: Accommodation Provider (proveedor de alojamientos), Activity Provider (proveedor de actividades) y Transport Provider (proveedor de transportes).

• Contigence Agent. Este agente se encarga de monitorear si existe algún disturbio

en algún destino o recurso turístico y se lo notifica indirectamente al usuario a través del agente Finder.

Esta arquitectura esta diseñada para dos modos de operación: la búsqueda de

recursos turísticos de uno-ha-uno y para recomendar un itinerario turístico (conjunto de recursos).

Para la realización de estos modos de operación están involucrados tanto protocolos de comunicación que definen la interacción de los agentes pero para fines de este trabajo no es necesario señalar estos comportamientos. La parte fundamental que se analizará es el mecanismo de razonamiento que se ha introducido en el sistema demostrativo con el objetivo de identificar la orientación y aplicación del mismo.

5.2.3 Razonamiento dentro del sistema demostrativo de @lisTechnet

La representación del conocimiento aplicado en este sistema demostrativo es un

sistema de producción. Lo cual involucra un razonamiento basado en reglas (RBR) [4, 5, 6].

El problema de la planeación es considerado como un proceso de toma decisión con un alto grado de complejidad. Existen factores que deben considerarse para la construcción de un itinerario turístico por lo que se deben considerar diversas decisiones apropiadamente.

Las decisiones en este sistema son tomadas utilizando reglas a un bajo nivel para decidir las decisiones apropiadas. La complejidad radica en la interdependencia de las decisiones tomadas.

La realización de una acción producida en la consecuencia de una regla puede afectar la activación de otra regla en tiempo posterior, por lo que este conocimiento es considerado en la producción de las reglas [6].

95

PA

LPA

SBA

Finder Provider

Base de

datos

GPA

CA

Núcleo de

razonamiento

Figura 23. Núcleo de razonamiento del sistema demostrativo @lisTechNet

De manera general, los agentes que están provistos por el RBR son los agentes GPA y LPA (véase figura 23). El sistema de producción se encuentra particionado en ambos agentes, por lo que cada uno cuenta con un conjunto de reglas y una memoria de trabajo con el objetivo en común de conformar un itinerario turístico. Representación del conocimiento

Una ontología es considerada dentro de los sistemas multiagente como la representación del conocimiento y constituye una herramienta semántica en la comunicación de estos sistemas. Ya que existen diferentes conceptos dentro de un itinerario turístico, se han creado una macro ontología llamada AlisTechNetOntology y que contiene las siguientes ontologías [5]:

1. Alojamiento. Modela la información para diferentes tipos de alojamientos. • Actividad . Modela información acerca de las diferentes actividades ofertadas al

usuario. • Aeropuerto. Modela la información acerca de los aeropuertos.

• Contingencia. Modela las posibles contigencias que pueden ocurrir durante el viaje.

Lo que significa que una actividad programada, una reserva de transporte o alojamiento puede ser cancelados debido a factores externos.

• Dirección. Modela la información acerca de la dirección de un recurso turístico.

96

• Búsqueda de ofertas. Modela la información acerca de las ofertas existentes de

recursos turísticos.

• Itinerario : Modela a un itinerario completo que será construido para el usuario de acuerdo a sus preferencias.

• Lugar geográfico. Modela la información acerca de los lugares geográficos como:

continentes, países y divisiones políticas.

• Precio. Modela la información acerca de precio en términos de divisas.

• Proveedor de recursos turísticos. Modela la información acerca de los proveedores de servicio.

• Reservación. Modela la información acerca de las reservaciones incluyendo:

alojamientos, actividades y transporte.

• Transporte. Modela la información acerca de las diferentes opciones de transporte las cuales pueden conectar a dos lugares geográficos.

Existen dos dominios de conocimiento para este sistema:

• Dominio primario . Conocimiento general de planeación lo cual implica [4]:

o La selección de un orden para visitar un conjunto de paises con base en:

� Las distancias entre ellos � Los costos de transporte � Orden aleatorio

o La selección de una estrategia para la división del tiempo a visitar los

diferentes países con base en:

� La cantidad de actividades preferidas por el usuario en aquel país � Costo general de las actividades a realizar en ese país � El tiempo que se toma en realizar las actividades en ese país � Tiempos iguales por cada país.

• Dominio Secundario. Este dominio es especificado por un experto de un país

específico. Ya que cuando se requiere la planeación de un viaje, se debe identificar que primeras y segundas divisiones de un país deben ser visitadas, de acuerdo a:

o Un paquete turístico definido, donde se tienen un conjunto establecido de primeras y segundas divisiones dado a un conjunto de factores como: preferencias del usuario, presupuesto y tiempo de planeación.

97

o Sugerir diferentes primeras divisiones de manera individual Planeación a través del razonamiento basado en reglas

Las preferencias del usuario son explícitamente expresadas a través de la interfaz del usuario y forman parte de su perfil personal. Las preferencias entonces son encapsuladas en un objeto itinerario el cual es introducido a la memoria de trabajo del GPA y posteriormente en el LPA, como ya se menciono anteriormente el GPA y el LPA conforman el núcleo del razonamiento del sistema. Ahora bien, existe la posibilidad de encontrar más de un plan que satisfaga las preferencias del usuario por lo que las reglas son lo que determinan que plan satisface en mayor grado las preferencias del usuario. El orden en el cual las reglas son disparadas determina este objetivo [6].

Para entender el proceso de planeación, es necesario definir los niveles de descomposición (véase figura 24) que sigue un itinerario para su conformación [4]:

Event

CountryVisitingEvent

FirstDivisionVisitingEvent

SecondDivisionVisitingEvent

1 … *

1 … *

1 … *

TransportEvent

1 … *

1 … *

ConcreteEvent

1 … *

Figura 24. Niveles de descomposición del sistema demostrativo @lisTechNet

1. Event: Este nivel de descomposición crea eventos del siguiente nivel para la visita

de paises. 2. CountryVisitingEvent: Este nivel de descomposición crea eventos del siguiente

nivel para la visita de primeras divisiones de un país.

3. FirstDivisionEvent: Este nivel de descomposición crea eventos del siguiente nivel para la visita de primeras segundas divisiones de un país, además de crear eventos de transporte para comunicar a las segundas divisiones.

98

4. SecondDivisionEvent: Este nivel de descomposición crea eventos del siguiente

nivel para concretar el tipo de recursos turísticos (alojamientos y actividades).

5. Concrete Event: Este nivel se instancias los recursos turísticos.

Estos niveles de descomposición en su conjunto constituyen una planeación basada en una red jerárquica de tareas, en donde cada nodo de la red es definido por cada nivel mencionado.

Figura 25. Agentes inmersos en la descomposición de un itinerario.

En el proceso de planeación, es claro que se siguen los diferentes niveles de

descomposición. Sin embargo, las reglas que se establecen en los agentes GPA y LPA, como se puede apreciar en la figura 25, son las que llevan a cabo los niveles del 2 al 5.

De igual manera, las reglas tienen el conocimiento de cómo resolver el problema con base en los dominios de conocimiento del sistema.

Dentro del dominio primario, se considero la implementación de las siguientes estrategias: un orden de visita aleatorio para cada y la división del tiempo a visitar los diferentes países con base en tiempos promedio iguales por cada país.

Dentro del dominio secundario, proveer paquetes turísticos definido, donde se tienen un conjunto establecido de primeras y segundas divisiones dado a un conjunto de factores como: preferencias del usuario, presupuesto y tiempo de planeación.

Para estos dominios de conocimiento se definieron conjuntos de reglas tipificadas que identifican las preferencias del usuario para sugerirle un itinerario turístico. Los objetivos de las reglas son descritas en las figura 26.

99

Figura 26. Objetivos de las reglas inmersas en los agentes

Las estrategias de resolución de conflicto, definidas en la sección 3.5, utilizadas en

este sistema son: Jerarquía y Complejidad [4, 6]. La primera estable un orden secuencial de reglas y la segunda establece que mientras mayor numero de condiciones se cumplan en la regla mayor grado de satisfacción se producirá en la consecución de la meta.

Aún cuando se implementaron dichas estrategias, existen estructuras de control en la memoria que son determinantes para identificar que regla debe ejecutarse o si hay que detener la ejecución de las reglas. Además a través de estas estructuras se controla el paso de mensajes entre los agentes en el proceso de planificación y re-planificación de un itinerario.

Debido a que el proceso de planeación de los paquetes turísticos se centra en las reglas inmersas en el LPA, se procederá a definirlas [4, 7]:

• Reglas _UP_. Están orientadas para agregar FDs (primeras divisiones) y SDs (segundas divisiones). Estas reglas identifican los tipos de lugares de interés y el grado de preferencia el usuario ha expresado, lo que constituye el fundamento de la planeación de un itinerario turístico basado en los lugares de interés.

• Reglas _AR_. Están orientadas para agregar aeropuertos. Estas reglas identifican

los FDs y los SDs agregados y con base en esto agregan los aeropuertos correspondientes a cada SD si es que existen.

• Reglas _CD_. Están orientadas a la selección y descomposición de paquetes

turísticos. Un paquete turístico para un país es descompuesto de acuerdo a los niveles de descomposición 2-5. Estas reglas identifican los FDs y SDs agregados,

100

evalúan las preferencias del usuario (número de personas, días de planeación, presupuesto y actividades) y recomiendan un paquete turístico definido por éstas reglas, distribuyen el presupuesto de acuerdo al paquete para cada FD y crean eventos FirstDivisitionEvent respecto de los FDs contenidos en el paquete.

• Reglas _FDD_. Están orientadas a la descomposición de FDs. Estas reglas verifican

los aeropuertos origen y destino, la ciudad destino y si la FD asociada a la regla se encuentra en el paquete turístico a través del numero de identificador del paquete. Se distribuye el presupuesto por cada SD contenida en el FD y se crean eventos SecondDivisionEvent respecto de los SDs contenidos en la FD.

• Reglas _SDD_. Están orientadas a la descomposición de SDs. Estas reglas verifican

los SDs agregados y el identificador del paquete. Se distribuye el presupuesto a las actividades y alojamiento (si éste es definido en el paquete), se crean eventos ConcreteEvent pora cada recurso turístico y en caso de que el presupuesto no satisfaga el número de actividades se crean espacios de tiempo libres llamados Do_Nothings.

Cuando se disparan las reglas _SDD_ entonces el LPA interactúa con el SBA para

obtener las instancias de los recursos turísticos, los cuales se encuentran en una memoria caché que previamente fue llenada con las instancias realizadas por una query del provider hacia la base de datos.

En la figura 27, se describen tanto los antecedentes como consecuentes de las reglas mencionadas [4, 7].

Figura 27. Tipos de reglas inmersas en el agente LPA.

101

Figura 28. Itinerario turístico conform

ado en el sistema dem

ostrativo @lisT

echNet.

102

Con base en las reglas descritas en la figura 27, se lleva a cabo el proceso de planeación dando como resultado un itinerario turístico como el que se muestra en la figura 28, en donde un usuario ha expresado su preferencias, donde las de mayor peso son los lugares de interés mostradas en el primer bloque de la figura. Además, se muestra un itinerario el cual puede ser visto como un árbol de nodos, en donde cada nodo tiene un identificador de plan (plan ID), esto sirve para identificar tanto al padre como a sus hijos. Entonces, el proceso de descomposición va creando los nodos del árbol hasta llegar al nivel 5 en donde se instancias los recursos turísticos. Re-planificación a través del razonamiento basado en reglas

El proceso de re-planificación se lleva a cabo cuando el usuario rechaza un nivel de descomposición o bien un recurso turístico (alojamiento, actividad o transporte). Esto involucra una iteración de la regla que produjo al nodo en cuestión, a través del proceso de backtracking en donde se identifica tanto al nodo objetivo (discordante) y a su nodo padre respectivo, para identificar la regla a disparar.

Cuando una regla se vuelve a disparar, los recursos turísticos son re-instanciados con nuevos valores. Dando así nuevas recomendaciones de recursos turísticos. Cuando la memoria caché del SBA ha recorrido todas las posibles opciones entonces el sistema falla en la recomendación de un itinerario por lo que el usuario debe modificar sus preferencias.

5.3 Otros sistemas

Además de los sistemas descritos en las secciones 5.1 y 5.2, se han realizado varios prototipos de sistemas de recomendación basados en los sistemas multiagentes (MAS). Por lo que se presentarán los más significativos desde punto de vista conceptual.

5.3.1 Sistemas de recomendación turística basados en MAS

Los sistemas de recomendación basados en la conceptualización de un sistema multiagente han tratado de probar que la distribución de tareas y las propias características de los agentes: movilidad, autonomía y negociación entre otras; pueden ser una solución para la recomendación turística desde el punto de vista de la dispersión de la información en este ámbito. Existen algunas propuestas en este ámbito que se enfocan principalmente en la búsqueda y reservación de recursos de viaje sin que esto implique necesariamente utilizar algún mecanismo de razonamiento automatizado. En los siguientes parrafos se mencionaran

103

El sistema descrito en [12], al cual se identificará como MAS1, presenta una aplicación basada en la tecnología de agentes enfocada al turismo, la cual tiene como objetivo permitir a un usuario planificar su estancia en una ciudad para poder visitar distintos lugares de interés.

En la aplicación desarrollada se contempla un arquitectura (véase figura 29) conformado por tres agentes: UserAgent, BrokerAgent y el SigthAgent. Su funcionamiento se basa en la información que el usuario introduzca a la aplicación, la cual será tomada por el UserAgent.

El BrokerAgent recibirá de los UserAgents las preguntas o acciones a realizar y él se las trasmitirá a los SightAgents correspondientes. Los SightAgents comparan la información recibida con sus propios datos y en el caso de que tanto de la información recibida, así como sus datos coincidan, enviarán al BrokerAgent un paquete de datos, y el BrokerAgent será el encargado de hacérsela llegar al UserAgent correspondiente.

Figura 29. Arquitectura del MAS1.

Los servicios proporcionados por la aplicación son: la búsqueda de recursos, reserva de recursos y la planificación del día. La arquitectura propuesta es una arquitectura cooperativa y no negociante, los escenarios posibles se basan en la razón de aceptar el precio sugerido por el recurso encontrado según los parámetros introducidos por el usuario. La principal limitante del sistema es no tratar de encontrar sitios que provean los mismos servicios a un menor costo ni mucho menos negociar con el proveedor de servicios una tarifa atractiva para el usuario.

La búsqueda involucra una simple query basándose en restricciones generales.

Además en el proceso de planificación del día el usuario escoge los ítems turísticos pero el sistema se encarga de presentar al usuario una tabla de horarios en donde un ítem puede ser

104

cambiado por otro en el mismo horario, sin permitir una libre modificación de la planeación por el usuario.

En la aplicación Personal Travel Market (PTM) en [37], se presenta el desarrollo de una aplicación de viaje personal basado en el estándar FIPA (Foundation for Intelligent Physical Agents). El sistema multiagente propuesto está conformado por tres agentes: Personal Travel Assistant (PTA), Travel Broker Agent (TBA) y Travel Service Agent (TSA), esto puede ser apreciado en la figura 30.

Figura 30. Arquitectura del PTM

De manera general el PTA esta provisto de un tipo de mecanismo de CBR que le

provee de la capacidad de aprender acerca de las preferencias del usuario; el TBA tiene la capacidad de conectar al usuario con los proveedores de servicios y la habilidad de planificar en donde los TSAs tienen la capacidad de obtener información de viaje. Una posible limitante de una aplicación como la descrita en este artículo es la orientación dada al CBR ya que el PTA solo aprende a flexibilizar las preferencias para encontrar un posible itinerario cuando no existe uno disponible. Por lo tanto, no se contempla la capacidad de adaptar parcialmente un itinerario ya conformado con la retroalimentación del usuario.

Finalmente, se tiene la aplicación TravelPlan [16], la cual es diseñada como un sistema multiagente de manera distribuida y cooperativa enfocándose a resolver el problema de recomendación de ítems turísticos en ambiéntes dinámicos. La arquitectura mostrada en la figura 31, contiene tres tipos de agentes: UserAgent, PlannerAgent y WebBot.

105

Figura 31. Arquitectura del sistema TravelPlan

El UserAgent se encarga de interpretar las solicitudes del usuario y mostrarle la

solución. Tiene la habilidad de comunicarse con los PlannerAgents y aprender de perfiles previos de los usuarios para construir la respuesta del sistema. El PlannerAgent tiene el objetivo es el razonamiento acerca de los problemas obtenidos del UserAgent y aprender de las soluciones dadas a través de mecanismo del CBR para la indexación y clasificación de cada plan almacenado. El WebBot se encarga de completar en detalle las solicitudes de los PlannerAgents obteniendo información requerida de Internet.

Este sistema se caracteriza por acceder a información turística en el Internet sin considerar proveedores de servicio dentro del núcleo de su arquitectura. Sin embargo, se debe considerar que los proveedores de recursos turísticos provean interfaces para poder acceder a su información y esto puede ser difícil de encontrar basado en aspectos de confiabilidad.

Finalmente, el razonamiento esta enfocado en el perfil del usuario aprendiendo de las soluciones que solucionaron problemas similares hacia un cierto conjunto de perfiles de usuario.

Todos estos tipos de sistemas de recomendación consideran diversos factores que pueden afectar la funcionalidad del sistema, que por su naturaleza es complejo. La complejidad radica en saber definir los roles y responsabilidades de cada agente en un cierto escenario, definir una ontología común en el dominio del problema, aplicar los protocolos que mejor se adapten al comportamiento y objetivos del sistema, además de los mecanismos de filtrado y/o razonamiento que puedan ayudar en la precisión de la solución propuesta [10, 11, 22, 33, 43, 48, 52, 56].

106

5.3.2 Sistemas de recomendación turística comerciales

Los sistemas de recomendación turística comerciales encontrados en Internet, como: expedia.com, travelocity.com, travelweb.com y eurovation.com; se enfocan en proveer sugerencias acerca de los principales ítems considerados en un viaje o itinerario turístico:

• Hoteles • Vuelos • Cruceros • Renta de automóviles • Actividades turísticas • Paquetes turísticos por ciudad • Alguna combinación de las anteriores

Aunque de manera general estos recursos son filtrados básicamente por parámetros

como: localización geográfica (ciudades origen y destino), disponibilidad del recurso turístico en un rango de tiempo, numero y tipo de acompañantes, más populares por ser utilizados por sus usuarios y precio. En la tabla 5, se aborda una comparativa basada en losrecursos y facilidades que proveen los sistemas comerciales anteriormente mencionados.

Características/Sitios expedia travelocity priceline eurovacations Hoteles Si Si Si Si Vuelos Si Si Si Si Cruceros Si Si No No Renta de automóviles

Si Si Si Si

Paquetes turísticos Si, por ciudad destino

Si, por ciudad destino



Actividades turísticas

Si Si No No

Personalización de paquetes turísticos

Hoteles, avión y automóvil

Hotel y avión

Hoteles y actividades turísticas

Hotel y avión

Provee búsquedas avanzadas

Si Si Si No

Provee recomendación ítems

Si Si No Si

Tabla 5. Comparativa de STR comerciales.

107

El resultado de esta comparación es la identificación de las características que son más comunes en estos sistemas [19, 20, 41, 53]. Los señalamientos importantes en esta comparativa son:

• Se encuentran funcionalidades minimizadas en la personalización de paquetes turísticos, es decir no se incluyen en estos el universo de los recursos turísticos: hoteles, aviones, renta de automóviles, etc.

• El concepto de paquete turístico se ve bifurcado de esta manera:

o Paquetes globales que incluyen: hotel, avión, actividades en una ciudad destino.

o Paquetes parciales que se construyen por el usuario para alguna combinación de recursos, como por ejemplo: hotel + avión.

• Los paquetes turísticos globales son preestablecidos por los proveedores y no

permiten su manipulación para modificarlos. En estos paquetes solo se considera una única ciudad destino, a menos que haya una oferta especial para un paquete multi-destino.

5.3.3 Sistemas que combinan el RBR y CBR

Existen algunos trabajos [24, 26] en donde se ha concebido un sistema hibrido basado en RBR y CBR para la solución de problemas en distinto ámbito que el de un sistema de recomendación turística. Por lo que solo se mencionará la manera en la que ambos mecanismos han ayudado a resolver los problemas planteados.

En [24] se plantea el problema de clasificar a las personas para identificar si son potencialmente beneficiadas en el aseguramiento de su automóvil. El RBR provee un primer diagnóstico o clasificación de los usuario y el CBR trata de contradecir el resultado de las reglas para saber si existen casos en los que dadas las características que clasifican al usuario éste pueda ser catalogado de manera diferente de acuerdo a la experiencia dada en un conjunto de clientes.

En [26] se plantea el diagnóstico de la falla de servicios de red dentro de una organización. A través del RBR, se evalúan las condiciones dadas en la red para considerar si se encuentra en un problema crítico dentro de la misma. Si existiera un problema, el CBR basándose en la experiencia de resolución de problemas lo resolverá.

El principal enfoque en estos trabajos respecto al RBR involucra un diagnóstico previo de la situación actual para identificar las características importantes que el CBR debe considerar para poder solucionar el problema.

108

5.4 Comparativa de sistemas

Una vez descritos los principales enfoques para la aplicación de los mecanismos de razonamiento en los sistemas de recomendación mencionados a lo largo del capitulo, se compararán los sistemas con base en sus características funcionales de cada uno de estos sistemas para analizarlos, esto se puede apreciar en la tabla 6.

Las características analizadas son:

• Tipo de destinos turísticos. Numero de destinos para los que permite planificar en una única ejecución.

• Número de preferencias de usuario: La cantidad de datos que debe especificar el

usuario acerca de sus preferencias de viaje (fechas, ciudades, sexo, etc).

• Número de preferencias promedio por recurso: Cantidad de datos que debe especificar el usuario por cada recurso o ítem turístico.

• Recursos turísticos abordados. Tipos de recursos turísticos considerados en la

planeación.

• Representación de conocimiento. Abstracción del dominio del problema.

• Metodología de razonamiento. Tipos de mecanismos de razonamiento implementados.

• Tipos de recomendación. Con base en ítems o en conjuntos de ítems (paquetes).

• Permite modificar itinerarios . Una vez planeado un paquete permite manipularlo.

• Provee planeación a través de una tabla de horarios. Contiene algún mecanismo

para manipular los horarios asociados a recursos turísticos dentro de la planeación.

• Tipo de usuarios. Se pueden considerar tres tipos:

o Principiantes. No tienen una idea clara de lo que quieren de un itinerario turístico y buscan información o una ayuda guiada de manera simple.

o Intermedios. Visualizan los posibles destinos turísticos y los recursos

turísticos que pueden encontrar en ellos.

o Avanzados. Ya conocen los destinos a los que desean ir e identifican totalmente los recursos turísticos que pueden encontrar en ellos.

109

El resultado de la comparativa muestra los siguientes resultados:

• La necesidad de una metodología de razonamiento dirigida a proveer recomendaciones precisas con respecto a las preferencias del usuario, siendo la más común del CBR.

• En general a mayor número de preferencias personales e ítems turísticos involucra

un usuario que identifique claramente lo que desea (intermedio o avanzado).

• Aunque la mayoría de los sistemas proveen recomendaciones de paquetes turísticos, no permiten modificarlos libremente por el usuario.

• En dos sistemas, @lisTechnet y MAS1, se ha considerado que los usuario también

pueden requerir un horario en el cual se les indique que actividades realizarán.

110

Comerciales

Un destino a nivel país

5

2

Alojamiento, transporte, cruceros, actividades

Query de datos

Desconocido

Ítems turísticos y paquetes turísticos

Algunos

No

Principiantes e intermedios

TravelPlan

Una destino a nivel país

9

3.66

Alojamiento y Transporte

Query de datos

--

Ítems turísticos

N/A

No

Principiantes e intermedios

s s

Tabla 6. C

omparativa entre los diferentes sistem

as descritos en este capítulo.

PTM

Un destino anivel país

21

4

Alojamiento, Transporte, restaurantes

Ontología

CBR

Ítems turísticos

N/A

No

Principiantee intermedio

MAS1

Una destino a nivel país

--

10

Alojamiento, Lugares de interés y restaurantes

Ontología

--

Ítems turísticos

Si, permutación de ítems turísticos

Si, en un rango de horario

Intermedios

@lisTechNet

Multi destino a nivel país

7

11.75

Alojamiento, transporte, lugares de interés y actividades

Ontologías y reglas

RBR


Si, como recomendación iterativa Si, aunque es el sistema quien lo manipula

Principiantes

Nutking

Multidestino a nivel región

15

12.2

Alojamiento, lugares de interés, actividades deportivas, eventos y cultura

Casos

CBR


Si

No

Principiantes , intermedios y avanzados

Tipo de destinos turísticos

Número de preferencias de usuario

Número de preferencias promedio por recurso

Recursos turísticos abordados

Representación de conocimiento

Metodología de razonamiento

Tipos de recomendación

Permite modificar itinerarios

Provee planeación a través de una tabla de horarios

Tipo de usuarios

111

5.5 Resumen

A lo largo del capítulo se han descrito principales sistemas en los que el RBR y el CBR son el núcleo de razonamiento: el sistema demostrativo de @lisTechNet y Nutking basado en la metodología Trip@dvice para la solución de problemas en el ámbito de la recomendación turística.

Se ha señalado enfoques del resultado de desarrollar sistemas híbridos RBR y CBR siendo su principal aportación el diagnóstico de un problema dado con RBR, para que con base en dicho diagnóstico se recupere una solución a dicho problema con CBR.

Se han descrito las funcionalidades de todo un conjunto de sistemas de recomendación considerando tantos prototipos, sistemas demostrativos, así como sistemas comerciales de recomendación turística con la finalidad de comparar dichas funcionalidad y el enfoque de cada uno de ellos, lo que será utilizado en el siguiente capítulo en el análisis del problema de un sistema de recomendación.

113

6. Sistema de recomendación turística propuesto: SyRec

6.1 Introducción

Los sistemas de recomendación turística (STR) han tenido la tarea de solucionar los problemas de filtrar el gran volumen de información que se ha provisto respecto de los recursos turísticos además de proveer sugerencias o recomendaciones personalizadas de ítems e itinerarios de recursos turísticos [2, 19, 20, 21, 38]. En la mayoría, los itinerarios turísticos se encuentran ya establecidos y difícilmente pueden ser modificados u ordenados en el tiempo por el usuario [2, 12, 25, 38].

La planeación de un viaje o itinerario turístico es un proceso multifacético. Un usuario debe de buscar múltiples recursos (ciudades destino, alojamientos, transportes, actividades, restaurantes, etc.) que deben satisfacer múltiples restricciones (las fechas disponibles, los grados de preferencia hacia los diferentes tipos de hoteles, transportes, actividades y restaurantes; el presupuesto, etc.). El grado de satisfacción del usuario es determinado principalmente por: el tiempo de búsqueda de los recursos de viaje, la selección de las mejores opciones con base en las restricciones o preferencias del usuario, así como la libertad para que el usuario modifique los criterios para la obtención de un nuevo espacio de resultados.

Con base en la descripción de los STR del capitulo 5, se han identificado los siguientes problemas:

1. Los recursos turísticos y un itinerario turístico tienen una estructura compleja de características que es difícil de manejar.

114

2. La recomendación de recursos e itinerarios turísticos implica una modelación de las preferencias del usuario obteniendo una correcta definición de los datos característicos del usuario.

3. La realización de una recomendación debe estar justificada por un proceso de

razonamiento y que le permita al usuario tener conocimiento de ello, ya sea de manera explicita o implícita.

4. En general los STR solo proveen paquetes turísticos, sin que esto represente un

orden minucioso de las actividades turísticas.

5. Los STR se han preocupado de proveer en la mayoría de los casos paquetes turísticos para una única ciudad y en algunos casos paquetes donde se involucran más de una ciudad.

6. El usuario y el STR deben interactuar con el objetivo de contribuir a una mejor

eficiencia del proceso de recomendación y planeación.

7. La interfaz de los sistemas no permiten una libre manipulación de los recursos turísticos en el proceso de la planeación de un itinerario turístico al usuario.

Todos esos problemas han sido la motivación para desarrollar una metodología para

el desarrollo de un STR que divida el proceso de recomendación de ítems turísticos del proceso de planificación de un itinerario turístico. Para fines prácticos de este documento un recurso es también considerado como un ítem. La separación de ambos procesos esta orientado a definir criterios específicos en cada una de estas áreas. Aunque esto no considera que el proceso de recomendación de ítems no tenga relación en el proceso de planificación, sino más bien hay que identificar que ambos procesos tienen tareas diferentes pero comparten un mismo objetivo, lo anterior se detallará en la sección 6.2.

6.2 Metodología

La metodología para el desarrollo de un sistema híbrido para la recomendación de sistemas turísticos, tiene el objetivo principalmente de dividir la tarea de recomendación de ítems de la recomendación de itinerarios turísticos. El principal motivo de esta separación se encuentra en la cantidad de factores que intervienen en una de los que intervienen en la otra.

Por un lado, la recomendación de ítems turísticos está en función de las preferencias del usuario respecto a las características concretas del ítem en cuestión. En el caso de un alojamiento, las posibles características pueden ser: numero de habitaciones, facilidades, precios, etc.

115

Por el otro lado, la recomendación de itinerarios turísticos está también en función

de las preferencias del usuario pero el conjunto de características de un itinerario contiene al conjunto de características de todos los ítems turísticos.

La metodología propuesta contempla las siguientes fases de modelado:

1. Modelación de un plan-itinerario 2. Modelación de reglas 3. Modelado de casos

Además la metodología soporta dos tipos de recomendaciones:

1. Recomendación de ítems turísticos 2. Recomendación de itinerarios turísticos

6.2.1 Modelación de plan-itinerario

El plan del un itinerario turístico describe la interacción del usuario con el sistema y

es construido de manera incremental durante la sesión de recomendación. Los componentes de un plan del itinerario turístico se describen a continuación:

1. Características discriminantes. Son las características que describen específicamente las preferencias del usuario sobre el viaje y los recursos turísticos para la conformación de un itinerario turístico.

2. Contenedor de recursos turísticos. En esta estructura se almacenan y clasifican

los recursos seleccionados y agregados por el usuario de acuerdo al conjunto de ciudades destino y al número de días de planeación del itinerario, con un orden estricto en el tiempo.

116

Figura 32. Un ejemplo de plan-itinerario

La figura 32, muestra un ejemplo de un plan itinerario en donde se puede apreciar el

conjunto de características discriminantes que son referidas como las preferencias que el usuario debe especificar para poder conformar un itinerario turístico. El contenedor de recursos refleja la estructura con respecto al número de ciudades y días de planeación para el almacenamiento ordenado de los recursos turísticos.

6.2.2 Modelación de reglas para la recomendación de ítems turísticos

La producción de reglas describe el conocimiento sobre las características de los

recursos turísticos. A través de las reglas se realizan los procesos de filtrado, ordenamiento, inferencia y almacenamiento de los recursos turísticos que serán recomendados al usuario.

El conjunto de reglas requieren de un contenedor llamado contenedor de recomendaciones en donde se almacenan y clasifican las recomendaciones del sistema para cada usuario sobre cada uno de los tipos de recursos turísticos considerados.

A continuación se describen los tipos de reglas que son considerados:

• Reglas de inferencia. Este tipo de reglas esta orientado a evaluar posibles factores externos que pueden incidir en las preferencias del usuario para activar las reglas de inferencia. Por ejemplo: el usuario ha expresado en sus preferencias que desea viajar de su ciudad de origen: México, D.F. a la ciudad destino: Cancún en un autobús y cuenta con 3 días de planeación, entonces este tipo de reglas evalúa que la distancia entre México, D.F. y Cancún es mayor a 6 horas entonces establece agrega un estado para activar las reglas de instancias inferidas. En la tabla 7, se muestra un ejemplo de las reglas de inferencia.

117

Condiciones heurísticas R1 R2 ¿El transporte es de tipo autobús? Si N/A

¿El tiempo de duración >= 6.0 hrs.? Si N/A

¿El transporte es de tipo avión? N/A Si

¿El tiempo de duración <= 3.0 hrs.? N/A Si

Tabla 7. Ejemplos de reglas de evaluación de factores externo

• Reglas de filtrado y ordenamiento. Este tipo de reglas tienen la finalidad de

evaluar las características de los recursos turísticos en términos de las preferencias del usuario, para identificar las instancias que cumplan el mayor número de condiciones expresadas por el usuario. El orden de disparo de estas reglas se establece a través de una estructura de control y de la heurística que refleja el conocimiento sobre las recomendaciones de recursos. En la tabla 8, se muestra un ejemplo de las reglas de filtrado y ordenamiento.

Condiciones heurísticas R3 R4 R5 R6 R7 R8 R9 ¿El transporte contiene la ciudad destino? Si Si Si Si Si Si Si

¿El transporte esta disponible en el tipo de horario preferido? Si No Si Si Si No No

¿El transporte contiene la clase de asiento en la que se desea viajar? Si Si No Si No Si No

¿El tipo del transporte es el preferido por el usuario? Si Si Si No No No No

Tabla 8. Ejemplo de reglas de filtrado

El orden de disparado de las reglas es controlado a través de la evaluación de estados y es obtenido de manera heurística, de acuerdo a la tablas 1 y 2, el orden de disparo sería el siguiente:

o Si las reglas de inferencia R1 y R2 se activan, las reglas de instancias

inferidas R9 y R10 (véase tabla 3) se activaran respectivamente. o Si la regla 3 se activa termina, ya que existen instancias de recursos que

cumplen exactamente las condiciones. o Si la regla 3 no se activa, entonces las reglas 4 y 5 se activarán. o Si las reglas 3 y 4 no se activan, entonces las reglas 5 y 6 se activarán. o Si las reglas 3, 4, 5 y 6 no se activan, entonces las reglas 7 y 8 se activan.

• Reglas de instancias inferidas. Este tipo de reglas tienen el objetivo introducir

instancias que pueden no ser consideradas de manera directa por el usuario pero que con base en las reglas de evaluación de factores externos podrían ser consideradas por el usuario, con base en el ejemplo establecido anteriormente la tabla 9 muestra un ejemplo de este tipo de reglas.

118

Condiciones heurísticas R9 R10 El transporte es de tipo autobús? Si No

El transporte es de tipo avión? No Si

El transporte contiene la ciudad destino? Si Si

El transporte contiene el horario? Si Si

Tabla 9. Ejemplos de instancias inferidas.

6.2.3 Modelación de casos para la recomendación de itinerarios turísticos

Un caso representa una síntesis abstracta de las características discriminantes del

plan del itinerario, que serán utilizadas para establecer las métricas de similaridad entre los itinerarios turísticos. El caso es una dupla problema-solución, por lo que las preferencias del usuario deben estar contenidas en el problema para poder establecer la similaridad entre los perfiles de usuario en la recomendación de itinerarios turísticos y sugerir una solución.

Un caso esta conformado por los siguientes módulos:

• Características dominantes de las preferencias del usuario. Estas características se establecen con base en las características discriminantes de un plan-itinerario, identificando las características que puedan ser generalizadas. En el CBR, mientras mayor grado de especificad exista en las características del problema disminuye el posible número de casos similares. Sin embargo, existen características que deben no deben generalizarse para no perder la precisión en el proceso de recomendación, tal es el caso de la ciudad origen.

Figura 33. Mapeo de las preferencias

En la figura 33, se describe que un usuario ha expresado su deseo de planear un viaje de 2 días en donde se visite: Puebla y Veracruz entonces esto puede

119

generalizarse como la preferencia de un usuario para visitar 2 ciudades en donde por lo menos una tenga playa, ya que geográficamente solo existen ciudades con/sin playa.

• Característica referenciada. Esta característica constituye la primera directriz en la recuperación de los casos similares. El presupuesto del itinerario de las preferencias del usuario (problema a resolver) puede ser considerada como la característica referenciada para obtener la calidad de la solución obtenida.

• Itinerario turístico. En esta estructura se encuentran clasificados y almacenados

los recursos turísticos que han sido previamente seleccionado, agregados y ordenados por algún usuario de acuerdo a las ciudades destino y al número de días de planeación del itinerario que estableció para la planeación de su itinerario, con un orden estricto en el tiempo. Este componente puede ser referenciado como el contenedor de recursos de la modelación de un plan-itinerario.

En la figura 34, se presenta un ejemplo de un caso. Ahí se describe a un usuario que

parte de la ciudad de México a Veracruz con un presupuesto de $3,000.00 por autobús en primera clase, etc.

Figura 34. Ejemplo de modelación de un caso

120

6.2.4 Recomendación de ítems turísticos

El proceso de recomendación de ítems se da ante dos posibles escenarios:

1. Cuando usuario desea conformar o llevar a cabo la planeación de un itinerario

turístico partiendo con itinerario vacío. 2. Cuando un usuario desea modificar un itinerario que le fue sugerido por el proceso

de recomendación de itinerarios definido en la sección 6.2.5.

En el primer escenario, el usuario requiere llevar a cabo la planeación de un itinerario, todo este proceso puede observarse en la figura 35. Por lo que se invoca a la función IniciarPlaneación(p), del verificador de datos de las preferencias del usuario donde p son las preferencias del usuario actual, si no existe algún error éste invoca la función DistribuirDías(cs) del Divisor de tiempo, donde cs es el conjunto de ciudades destino. El divisor de tiempo invoca la función Obtener actividades(cs) del manejador de recursos a través de la cual se accede a la base de datos para encontrar el número de actividades preferidas por el usuario en las ciudades destino y la información correspondiente es enviada al divisor de tiempo para que obtenga los días de planeación por ciudad.

Una vez que se establecen los días, se notifica si el número de días que el especifico

es válido o ha sido modificado. El usuario entonces puede iniciar la planeación del itinerario invocando la función PlanearItinerario(p,r,c) del razonador RBR, donde p son las preferencias del usuario actual, r es el tipo de recurso turístico y c es la ciudad donde llevará a cabo el proceso de planeación.

El razonador RBR invoca la función ObtenerRecursos(r,c) al manejador de

recursos, el cual accederá a la base de datos para obtener las instancias del tipo de recurso r en la ciudad c para enviar el conjunto de instancias al razonador RBR. En este momento se inicia el proceso de RBR en este componente con base en las reglas producidas y en las preferencias p, los resultados son almacenados en un contenedor de recursos recomendados y el usuario podrá acceder a una instancia de algún tipo de recursos para introducirlo al itinerario turístico a través de la función ManipularRecurso(r,c).

121

Recomendación de ítems turísticos (A)

Verificador de

datos de las

preferencias del

usuario

Divisor de tiempo

Razonador RBR

Manejador de

recursos Base de

datos

Usuario

1. IniciarPlaneación(p)

Contenedor de

recursos

recomendados

4. PlanearItinerario(p,r,c)

Datos no válidos

2. Obtener

actividades(cs)

ObtenerRecursos(r,c)

5. AlmacenarRecursos(r)

7. ManipularRecurso(r,c)

Informe de días de planeación

2. DistribuirDías(cs)

Figura 35. Recomendación de ítems turísticos (A).

El segundo escenario ocurre cuando un usuario ha requerido la recomendación de

un itinerario, todo el proceso puede observarse en la figura 36. El usuario entonces invoca la función PedirItinerarios(p) del recomendador de itinerarios, donde p son las preferencias del usuario actual. El recomendador de itinerarios básicamente implementa el ciclo CBR con base en las preferencias del usuario para encontrar casos previos y de manera inherente un itinerario que pueda satisfacer al usuario.

Una vez que le presenta un conjunto de n casos similares, el usuario puede observar

las características de los casos a través de la función AnalizarItinerario(i) además esta función permite la selección de un caso, donde i es el itinerario seleccionado. Si el usuario desea modificar el itinerario del caso seleccionado, entonces se invoca la función ModificarItinerario(p,r,c) del razonador RBR, a través de la cual se toma en cuenta las preferencias p del usuario actual para filtrar las instancias del tipo de recurso r y en la ciudad c a la cual se modificará su itinerario.

El razonador RBR accede al manejador de recursos por la función

ObtenerRecursos(r,c), el manejador obtiene las instancias del tipo de recurso r en la ciudad c y se las envía al razonador para que este lleve a cabo el proceso de RBR con base en las preferencias p del usuario actual.

122

Recomendación de ítems turísticos (B)

Recomendación de

itinerarios Manejador de

recursos Base de

datos

Usuario

1. PedirItinerario(p)

3. ModificarItinerario(p,r,c)

Datos no válidos

4. ObtenerRecursos(r,c)

2. AnalizarItinerario(i)

Razonador RBR

Contenedor de

recursos

recomendados

5. AlmacenarRecursos(r)

6. Planear(r,c)

Figura 36. Recomendación de ítems turísticos (B).

6.2.5 Recomendación de itinerarios turísticos

El proceso de recomendación de itinerarios turísticos ocurre cuando el usuario desea

obtener itinerarios turísticos que han sido conformados o planeados con base en preferencias similares a dicho usuario.

El proceso de recomendación de itinerarios turísticos puede ser observado en la figura 37. Un usuario puede requerir la recomendación de itinerarios turísticos para lo cual invoca la función PedirItinerarios(p), del verificador de datos donde p son las preferencias del usuario actual. Si el conjunto de datos es válido entonces se invoca a la función IniciarRecomendación(p) del razonador CBR. El razonador CBR entonces sintetiza las preferencias p del usuario actual e inicia el ciclo del CBR como se describe en la sección 4.2.

Es necesario señalar que para que el ciclo CBR pueda llevarse a cabo se deben establecer las métricas de similaridad adecuadas para que los procesos de recuperación, reutilización y almacenamiento no se vean afectados.

El almacenamiento ocurre siempre y cuando el itinerario turístico sea modificado y analizado con base en las métricas de similaridad. La modificación de un itinerario turístico es descrita en la sección 6.2.4.

123

Figura 37. Recomendación de itinerarios turísticos.

6.3 El sistema SyRec

El sistema híbrido de recomendación turística SyRec es un prototipo que fue desarrollado con la metodología propuesta en la sección 6.2 y esta orientado a soportar la planeación de un itinerario turístico. El sistema SyRec tiene los siguientes requerimientos:

• El sistema debe tener como entrada las preferencias del usuario y como salida un itinerario de viaje.

• El sistema debe dirigir al usuario para que delimite el proceso de planeación de un

itinerario turístico a través de datos significativos y coherentes que permitan discriminar la información y que sean contemplados como los atributos del proceso de planeación.

• El sistema debe proveer los siguientes recursos turísticos representativos:

alojamientos, transporte, restaurantes, lugares de interés y actividades para la planeación de un itinerario de viaje, ya que generalmente son estos tipos los contemplados en los recomendadotes turísticos analizados en el capítulo 5.

• El sistema debe proveer una comparativa que pueda influir en la toma de decisiones

del usuario respecto a los recursos recomendados.

• El sistema debe ser capaz de simplificar y minimizar el proceso de búsqueda, así como facilitar la comparación entre los recursos de viaje e inferir las mejores opciones en el caso de que no existan recursos disponibles.

124

• El sistema debe tener la habilidad de permitir seleccionar un itinerario ya conformado o bien, conformar un nuevo itinerario seleccionando recurso por recurso.

• El sistema debe proveer libertad al usuario para adaptar un itinerario que no cumpla

totalmente con las preferencias que ha establecido, de forma que pueda modificarlo ya sea agregando o eliminando recursos turísticos.

• El sistema debe proveer una justificación explícita o implícita de las

recomendaciones que provea.

• Un itinerario de viaje debe generarse con un cierto grado de especificación y orden en el tiempo. En otras palabras, es necesario contemplar un horario por día en el que el usuario organice el número de actividades a realizar dentro del proceso de planeación.

El sistema SyRec está orientado a trabajar con información de servicios turísticos

disponibles en cualquier país, sin embargo para fines prácticos solo se ha trabajado con información de México.

A través del sistema SyRec se establece una sesión de recomendación la cual esta dividida en tres fases:

1. Fase de adquisición de preferencias del usuario. El sistema le requiere al usuario información específica acerca de sus necesidades, deseos y restricciones que definirán la planeación de un itinerario turístico.

2. Fase de búsqueda de ítems e itinerarios turísticos. El usuario inicia el proceso de

búsqueda en dos diferentes modalidades:

a. Búsqueda de ítems turísticos. El usuario requiere de planear un itinerario por agregar libremente ítems turísticos, pudiendo modificar sus decisiones acerca de su elección. La recomendación de ítems toma como base las preferencias del usuario, una búsqueda siempre será exitosa desde el punto de vista que el sistema siempre le proveerá resultados.

Sin embargo, si no se encuentran resultados que satisfacen totalmente las restricciones del usuario entonces se proveerá un conjunto de recursos que las satisfagan en menor grado. El principal objetivo de proveer siempre un conjunto de resultados que en mayor o menor medida cumplan con sus preferencias es por tomar en cuenta que la comparativa de recursos permite que el usuario pueda cambiar de decisión sin tener que modificar sus preferencias.

125

b. Búsqueda de itinerarios turísticos. El usuario requiere un itinerario que sea similar a lo que ha expresado en sus preferencias. La búsqueda es exitosa si la calidad de la solución es aceptable, esto se detallará en la sección 6.3.1.

3. Fase de selección y adaptación. El conjunto de resultados de la búsqueda son

clasificados y ordenados. El usuario puede examinar el conjunto de características que tengan tanto los ítems como los itinerarios y tomar su decisión para elegir alguno. La adaptación ocurre cuando se ha requerido previamente una búsqueda de itinerarios, entonces el itinerario seleccionado puede ser llevado a un modo de edición a través del cual el usuario puede agregar o eliminar los ítems turísticos. En esta fase se encuentra inmersa a un mismo tiempo la búsqueda de ítems turísticos, ya que es necesario proveer un conjunto de ítems para que pueda adaptarse o modificarse el itinerario previamente conformado.

En el desarrollo del sistema se han utilizado las características discriminantes para

proveer la búsqueda de ítems turísticos y las características dominantes para proveer la búsqueda de itinerarios turísticos.

6.3.1 Arquitectura del sistema

El sistema SyRec tiene el objetivo de resolver el problema de conformar o planear

un itinerario a través de una sesión de recomendación, definida en la sección 6.3, a través de la cual se da solución a este problema.

El problema es modelado con base en las preferencias del usuario, obteniendo características discriminantes que son utilizadas en el proceso de buscar ítems turísticos. Si el usuario requiere buscar itinerarios previamente conformados las características discriminantes se mapean a características dominantes para recuperar los casos previos en donde se contienen a los itinerarios ya conformados. Una vez obtenidas estas características entonces se puede continuar hacia la búsqueda de ítems o itinerarios turísticos.

En el caso de buscar ítems turísticos, el RBR se encarga de evaluar las preferencias del usuario contra las características de los ítems para encontrar un conjunto de resultados que satisfagan las preferencias del usuario. En el caso de buscar ítems turísticos el CBR recupera, adapta y lleva acabo un proceso de revisión respecto a la característica de referencia para obtener la calidad de los resultados.

126

Figura 38. Arquitectura lógica de SyRec

Si se lleva acabo la modificación del itinerario, entonces se lleva a una fase de edición en donde el RBR le provee al usuario el conjunto de ítems necesarios para poder modificar el itinerario sugerido por el CBR. Finalmente, se puede obtener un itinerario conformado, si se ha pasado por el RBR o un itinerario aceptado si únicamente se ha pasado por el CBR. Todo este proceso puede observarse en la figura 38.

Ya que se ha descrito la arquitectura de SyRec en términos de su funcionalidad, es también necesario identificar los componentes del sistema que se encargarán de realizar el proceso descrito en los párrafos anteriores.

La arquitectura de SyRec, descrita en la figura 39, tiene cuatro componentes de software que se describirán brevemente:

1. Interfaz de usuario. Se encarga de dirigir la interacción del usuario con el sistema en y presentar la información producida del proceso de planeación. En este componente se incluye un validador de preferencias que tiene el objetivo de verificar la coherencia de los datos, manejadores gráficos que permiten manipular la información y un pre-planificador que se encarga de realizar la división de días de planeación.

2. Núcleo de razonamiento. Contiene tanto un razonador basado en casos como un

razonador basado en reglas, los cuales tienen como objetivo la búsqueda de ítems e itinerarios turísticos respectivamente.

3. Manejador de recursos. Contiene un manejador de instancias de recursos que tiene

el objetivo de mapear objetos a la estructura de una base de datos relacional y viceversa, así como recuperar un conjunto de instancias de algún recurso turístico. Se incluye también un manejador de casos que permite mapear de igual manera

127

objetos a la estructura de una base de datos relacional y viceversa, así como recuperar transparentemente la librería de casos base.

4. Repositorio de datos. Contiene una base de datos relacional en donde se

encuentran al macenados tanto los recursos turísticos como los casos base.

Figura 39. Arquitectura de componentes

En las siguientes secciones se detalla la implementación de cada uno de estos

componentes.

6.3.2 Interfaz de usuario

El usuario podrá interactuar con el sistema a través de la interfaz, la cual esta

orientada a realizar las siguientes tareas:

• Modelar al usuario a través de las preferencias expresadas • Presentar información acerca de los ítems e itinerarios • Proveer la capacidad de manipular los ítems e itinerarios turísticos con el fin de

conformar un itinerario.

La modelación del usuario crea una estructura que contiene las preferencias del usuario. El conjunto de preferencias consideradas dentro de la interfaz son las siguientes:

1. Preferencias de viaje 2. Preferencias de alojamiento 3. Preferencias de transporte inter-ciudad 4. Preferencias de restaurantes 5. Preferencias de lugares 6. Preferencias de actividades

128

Dado que el sistema tiene la tarea de producir recomendaciones coherentes, las preferencias de viaje tienen una dependencia jerárquica de las preferencias de viaje, como se observa en la figura 40.

Alojamientos

Preferencias del Viaje

Transportes Restaurantes Lugares Actividades

Figura 40. Estructura jerárquica de preferencias del usuario

La dependencia de las demás preferencias con respecto a las preferencias de viaje

radica en que las preferencias de viaje presentan entre otras cosas la ciudad origen y las ciudad destino a las que el usuario desea visitar. Entonces una vez que se definen las ciudades destino el sistema verifica los tipos de recursos que existen en dicha ciudad para que el usuario exprese sus preferencias con respecto a éstos. Por ejemplo: Un usuario tiene como ciudad origen México, D.F. y desea planear un itinerario en las ciudades destino: Puebla y Veracruz, entonces el sistema identifica que tipos de transportes, restaurantes, lugares y actividades existen en estos lugares con el objetivo de que las preferencias produzcan resultados existentes. De esta manera, no es posible que el usuario pueda seleccionar una actividad de playa en un lugar donde no existe la playa.

Las preferencias del viaje, apreciadas en la figura 41, delimitan globalmente el itinerario de viaje y presentan la siguiente información a definir por el usuario:

• Fechas de salida y regreso • Ciudad Origen • Ciudad(es) Destino • Numero de personas • Presupuesto Total

Una vez que las preferencias de viaje han sido introducidas, el sistema infiere que

datos debe de mostrar para los grupos de preferencia: Alojamientos, Lugares y Actividades. Para fines prácticos se asume que todas las ciudades cuentan con todos los tipos de recursos definidos para transporte, restaurantes. Ya que la planeación de viajes se centra principalmente en los lugares de interés así como en las actividades turísticas.

129

Figura 41. Preferencias de viaje en la interfaz de usuario

En el caso de las preferencias de los alojamientos, el sistema analiza que tipo de

ciudades han sido seleccionadas. Los tipos de ciudades consideradas son:

• Ciudades con playa • Ciudades sin playa.

Entonces si el usuario ha seleccionado ciudades que contienen playas y ciudades sin

playa, el sistema ofrece la opción de establecer un tipo de alojamiento para cada tipo de ciudad, como se puede apreciar en la figura 42. Es claro que si selecciona ciudades destino de un solo tipo entonces solo estarán disponibles los tipos de alojamientos asociados. Se hace esta distinción ya que en México existen tipos característicos de alojamiento en ciudades con playa en contraste con las ciudades que no tienen playa.

Figura 42. Especificación del tipo de alojamiento.

130

Las preferencias de los alojamientos, apreciadas en la figura 43 son definidas a través de los siguientes datos:

• Tipos de ciudad = {con playa, sin playa} • Tipo de alojamiento con playa = {hoteles, bungalows, cabañas, casa} • Tipo de alojamiento sin playa = {hoteles, hostales, casas} • Habitaciones = {sencilla, doble, triple y cuádruple} • Precio de la habitación por noche = {precio mínimo y precio máximo} • Facilidades del alojamiento = {alberca, bar, clima, cocina, estacionamiento,

gimnasio, internet, jacuzzi, restaurante, spa, teléfono, televisión vía satélite}.

Figura 43. Preferencias de alojamiento.

Las facilidades del alojamiento pueden ser vistas como preferencias avanzadas del

alojamiento. Si el usuario no desea especificar las preferencias avanzadas el sistema debe tratar esto como indiferencia hacia las facilidades ofrecidas por el alojamiento. El objetivo de esta consideración es minimizar el número de preferencias que deben ser especificadas por el usuario.

Las preferencias de transporte, como se aprecia en la figura 14 se definen a través de datos como:

• Tipo de transporte inter-ciudad = {Autobús, Avión} • Clase = {2ª clase, 1ª clase, Ejecutiva}

131

Los tipos de transporte Inter-Ciudad corresponden a uno de tipo terrestre (autobús) y uno de tipo aéreo (avión) y establece por cual medio de transporte será utilizado para viajar de una ciudad a otra en un itinerario con múltiples ciudades destino. Cuando se selecciona algún tipo se debe establecer la clase preferente del transporte. Todo esto puede ser apreciado en la figura 44.

Figura 44. Preferencias de transporte y restaurantes

Las preferencias de restaurantes, como se aprecia en la figura 15, se ven reflejadas

en las opciones de:

• Comida rápida = {requerido, no-requerido} • Comida italiana = {requerido, no-requerido} • Comida vegetariana = {requerido, no-requerido} • Comida mexicana = {requerido, no-requerido} • Pescados y mariscos = {requerido, no-requerido} • Precio promedio por menú = {precio mínimo y precio máximo}

Este tipo de preferencias no son indispensables por lo que el usuario puede no

especificarlas a excepción del rango de precio promedio por menú y el sistema infiere que al no tener preferencia todas las opciones de restaurantes son requeridas. El objetivo de esta consideración es minimizar el número de preferencias que deben ser especificadas por el usuario.

132

El tipo de lugares de interés, como se puede apreciar en la figura 45, que se han contemplado son:

• Artesanías • Bosques • Cascadas • Galerías de arte • Museos

• Parques Nacionales • Pirámides • Playas • Sitios Coloniales • Zoológicos

Para este tipo de preferencias, el sistema analiza que ciudades cuentan con este tipo

de lugares de interés y habilita solo los tipos de lugares disponibles de la ciudad. En el caso de un itinerario con múltiples ciudades destino se realiza una operación de unión de los lugares de cada una de las ciudades. Para este conjunto de preferencias el usuario deberá seleccionar el grado de interés de cada sitio entre valores como: {Soy Fanático, Me Gusta, Podría ser interesante, Indiferente, No interesado}.

Figura 45. Preferencias de lugares de interés.

Finalmente, las preferencias para el tipo de actividades turísticas, como se puede apreciar en la figura 46, se definen con las siguientes opciones:

• Agroturismo • Aventura acuática • Aventura aérea • Aventura terrestre

• Cultural • Deporte acuático • Deporte aéreo • Deporte terrestre

133

• Ecoturismo • Familiar • Folklore

• Turismo rural • Turismo urbano

Cada uno de estos tipos contiene actividades asociadas las cuales pueden pertenecer

a más de un tipo de la clasificación mostrada. De igual manera que con los sitios de interés el usuario debe de seleccionar el grado de interés por cada tipo-actividad que desee agregar a su itinerario, los posibles valores son: {Soy Fanático, Me Gusta, Podría ser interesante, Indiferente, No interesado}.

Figura 46. Preferencias de actividades

La interfaz del usuario es fundamental en el proceso de la modelación del usuario y

en la retroalimentación del sistema. A través de la interfaz el sistema evita una posible inconsistencia en las preferencias del usuario realizando la validación de los datos de entrada, se presentan y manipulan los recursos de viaje para conformar itinerarios y se capturan las métricas de similaridad utilizadas para recuperar itinerarios que han sido previamente conformados.

134

Modelación de un plan-itinerario

Con base en el conjunto de preferencias y en lo definido en la sección 6.2.1. Las características dominantes de un plan-itinerario son descritas en la tabla 10.

Plan-Itinerario / Características discriminantes

Viaje Lugares

Ciudad Origen Ciudad de México Artesanias 0.00

Ciudad Destino Veracruz Bosques 0.75

Numero de Viajeros 1 Cascadas 0.50

Presupuesto $5,000.00 Galerias Arte 0.75

Dias de Planeacion 3 Museos 1.00

Alojamiento Parques Nacionales 0.00

Tipo Hotel Piramides 0.00

Habitaciones Sencilla(1), Doble(0),

Triple(0), Cuádruple(0) Playas

1.00

Precio Minimo $100.00 Sitios Coloniales 1.00

Precio Máxico $600.00 Zoologicos 0.25

Facilidades Alojamiento Actividades Requeridas

Alberca false Aventura Acuática-Hidrospeed 1.00

Bar false Aventura Acuática-Kayak 1.00

Clima false Aventura Acuática-Rafting 1.00

Cocina false Aventura Acuática-Ski 1.00

Estacionamiento false Aventura Acuática-Snorkel 1.00

Gym false Aventura Acuática-Surfing 1.00

Internet false Aventura Aérea-Paracaidismo 0.75

Jacuzzi false Aventura Aérea-Salto del Bungee 0.75

Restaurant false Aventura Terrestre-Escalada 0.50

SPA false Aventura Terrestre-MotoX 0.50

Telefono true Deporte Acuatico-Snorkel 1.00

T.V.Cable true Deporte Acuatico-Veleo 1.00

Transporte Ecoturismo-Liberacion de Tortuga 0.75

Tipo Autobús Ecoturismo-Observacion Sideral 0.75

Clase Económica Ecoturismo-Observacion de flora y fauna 0.75

Restaurantes Ecoturismo-Visita a los Arrecifes 0.75

Comida Italiana true Turismo Urbano-Edificios Importantes 0.50

Comida Mexicana true Turismo Rural-Ranchos 0.25

Comida Pesc&Marisc true Actividades NO Requeridas

Comida Rapida true Cultural-Cine 0.00

Comida Vegetariana true Cultural-Concierto de Orquesta 0.00

Precio Min $30.00 Cultural-Danza 0.00

Precio Max $120.00 Cultural-Escultura 0.00

Tabla 10. Ejemplo de la modelación de las características discriminantes de un plan-itinerario.

135

En la modelación de un caso en SyRec, no se consideran como características

discriminante explicitas todo el conjunto universo de las actividades asociadas a un tipo de actividad sino que únicamente se consideran las especificaciones del usuario, todas las demás actividades serán consideradas de manera implícita con un grado de preferencia <<indiferente>> (0.25). Esta consideración se basa en la minimización de especificidad de las preferencias del usuario para proveer un mayor conjunto de datos resultado

El modelado del contenedor de los recursos turísticos no se definirá en este documento ya que no representa un factor trascendente en la demostración del funcionamiento del sistema. Hay que señalar que esta estructura tiene el objetivo de almacenar los recursos turísticos con un cierto orden del tiempo, este orden ha sido especificado en lapsos de horas y puede ser vista como una tabla de horarios en donde se especifican las actividades, los restaurantes, lugares y transportes. En el caso del alojamiento este no se encuentra inmerso de un horario sino que solo es considerado dentro de la estructura como un ítem temporal por el número de noches que pernoctará el usuario en una ciudad. Sin embargo, es implementada la funcionalidad de este contenedor en SyRec, como se puede apreciar en la figura 47.

Figura 47. Estructura de horarios para un itinerario turístico en SyRec.

136

Modelación de un caso

Con base en el conjunto de preferencias y en lo definido en la sección 6.2.3, se describe la modelación de un caso en SyRec en la tabla 11.

Caso A

Viaje Lugares

Presupuesto $4,000 Lugar Artesanias 0.00

Días Totales de Planeación 3 Lugar Bosques 0.75

Número de ciudades destino 4 Lugar Cascadas 0.50

Porcentaje de ciudades con playa 50% Lugar Galerias de Arte 0.75

Porcentaje de ciudades sin playa 50% Lugar Museos 1.00

Transporte Lugar Paques Nacionales 0.00

Tipo transporte inter-ciudad Autobús Lugar Pirámides 0.00

Clase transporte inter-ciudad 1a clase Lugar Playas 1.00

Alojamiento Lugar Sitios Coloniales 1.00

Alojamiento Facilidad-Alberca si Lugar Zoológicos 0.25

Alojamiento Facilidad-Bar si Actividades

Alojamiento Facilidad-Clima si Actividades de Agroturismo 0.75

Alojamiento Facilidad-Cocina no Actividades de Aventura acuática 0.50

Alojamiento Facilidad-Estacionamiento no Actividades de Aventura aérea 0.33

Alojamiento Facilidad-Gimnasio no Actividades de Aventura terrestre 0.25

Alojamiento Facilidad-Internet si Actividades de Cultural 1.00

Alojamiento Facilidad-Jacuzzi no Actividades de Deporte acuático 0.75

Alojamiento Facilidad-Restaurante si Actividades de Deporte aéreo 0.50

Alojamiento Facilidad-SPA no Actividades de Deporte terrestre 1.00

Alojamiento Facilidad-Telefono si Actividades de Ecoturismo 0.50

Alojamiento Facilidad-TV Cable si Actividades de Familiar 0.25

Restaurantes Actividades de Folklore 0.00

Comida Italiana no Actividades de Turismo rural 0.00

Comida Mexicana no Actividades de Turismo urbano 0.00

Comida Pescados & Mariscos no

Comida Rápida no

Comida Vegetariana si

Tabla 11. Ejemplo de modelación de un caso en SyRec

Dentro de las preferencias de viaje las características como: número de viajeros y

ciudad origen; debido a la invariabilidad de las características y no pueden ser generalizadas ya que es claro que un usuario desearía obtener itinerarios que parten de su ciudad de origen, un caso similar es el número de viajeros. En el caso del número de ciudades, se ha generalizado esta característica como se ha mencionado en la sección 6.2.3.

137

Para el caso de las preferencias de alojamiento, no se han considerado características como: tipo, habitaciones y el rango de precios, en el sentido que de manera heurística un usuario puede darle más peso a las facilidades de un alojamiento que al propio tipo de alojamiento. De la misma manera el tipo de habitaciones no tiene un alto grado de dispersión para un cierto número de viajeros (un viajero que viaja solo no considerará pagar una habitación triple). Finalmente, en el presupuesto general del itinerario involucra un tipo de alojamiento que va de acorde con el costo global del itinerario.

Con la finalidad de evitar características simbólicas que puedan afectar la evaluación de estas preferencias en el CBR, se mapean los calificativos tanto de los lugares de interés como de las actividades a valores reales, como se muestra en la tabla 12.

Valor simbólico Valor real Soy Fanático 1.00

Me gusta 0.75

Podría ser interesante 0.50

Indiferente 0.25

No interesado 0.00

Tabla 12. Mapeo

Dentro de las preferencias de actividades, no se han considerado un mayor grado de

especificidad que el valor preferencial del tipo de actividad. En otras palabras, se toma el valor promedio para un tipo de actividad con base en las preferencias expresadas por el usuario para actividades asociadas a este tipo, como se muestra en la tabla 13.

Tipo de actividad Actividad 1 Actividad 2 Actividad 3 Promedio Ecoturismo 1 0 0 0.33

Cultural 1 0.75 0.5 0.75

Deporte aéreo 0.25 0.25 0.25 0.25

Aventura acuática 0.75 0.25 0.5 0.5

Tabla 13. Encapsulamiento del grado de preferencia por tipo de actividad

La característica referenciada del caso depende de la especificación del presupuesto

por parte del usuario para la planeación del itinerario.

6.3.3 El RBR y la recomendación de ítems turísticos

El mecanismo de razonamiento basado en reglas (RBR) es utilizado en SyRec en la

recomendación de ítems e itinerarios turísticos, de acuerdo a lo definido en la sección 6.2.4, por lo que en esta sección se definirán las reglas utilizadas en SyRec para la recomendación de ítems turísticos.

138

En esta parte del sistema, el usuario interactúa con el sistema de recomendación

para pedir instancias de tipos de recursos turísticos denotados como ítems, para planificar o modificar los recursos de un itinerario. La modificación de un itinerario ocurre cuando éste es recuperado por el mecanismo de razonamiento basado en casos en SyRec se definirá en la sección 6.3.4.

De acuerdo a cada ámbito de los recursos de viaje contemplados por SyRec (alojamientos, transportes, restaurantes, lugares y actividades) se definen un conjunto de reglas. Cada regla toma como antecedentes los valores de ciertas preferencias que el usuario ha establecido, así como las características de los recursos turísticos que posteriormente se evaluarán para identificar las instancias que satisfacen en un cierto grado al usuario. La evaluación trae consigo la filtración, ordenamiento e inferencia del conjunto de instancias evaluadas. Finalmente, se presenta el resultado de la ejecución de las reglas que son las instancias que tienen mayor probabilidad de ser seleccionadas, de esta manera el usuario tiene a la vista los recursos y puede realizar la comparación entre cada uno de ellos, como se puede apreciar en figura 48.

Figura 48. Recomendación de ítems turísticos en SyRec.

Sin embargo, para que las reglas puedan llevar a cabo su tarea es necesario

identificar las preferencias y características de los recursos turísticos que deberán ser evaluadas para encontrar ítems turísticos que puedan ser de interés para el usuario. Con la finalidad de detallar la utilidad del uso de las reglas se procederá a dar un ejemplo (véase figura 48) para mostrar el seguimiento que se tiene en la ejecución de reglas así como la inferencia que se deriva. Se toma como ejemplo el ámbito de los transportes inter-ciudad.

Resultados inferidos

Resultados

139

Un usuario con un “presupuesto = $15,000” desea viajar a un conjunto de ciudades destino = {Cancún, Acapulco, Puebla, Ciudad de México} partiendo de la ciudad de Monterrey, con una duración de 15 días. El usuario ha definido que desea viajar en la mañana y que el transporte preferido es el autobús. Antes de iniciar la recomendación de recursos de viaje el sistema calcula el número de días para cada ciudad destino verificando el número de actividades por tipo de actividad. Es preciso señalar que las actividades son comúnmente la parte principal de un itinerario turístico. Analizando estas preferencias se sabe que el transporte entre Monterrey y Cancún dura más de 12 horas lo que implica que el usuario llegará exhausto y tendrá poco tiempo para realizar actividades si es que así lo desea. También se sabe que el costo de viajar en el autobús puede ser menor o similar a viajar en avión. Entonces las reglas a definirse deben tomar en cuenta que, además de proveer de instancias de autobuses puede ser que el usuario le interese viajar en avión y así proveerle de ambos opciones de transporte. Una vez presentados los resultados de la ejecución de las reglas, el sistema tiene la opción de mostrar los posibles horarios en los que puede hacer la reservación.

En los siguientes párrafos se detallarán la producción de reglas en SyRec para cada uno de los tipos de recursos turísticos. Producción de reglas de transporte

La producción de reglas que se han definido para la recomendación de ítems de transportes inter-ciudad se encuentran descritas en las tablas 14 y 15, y están orientadas a evaluar únicamente a instancias de recursos de transporte en ciudad definida.

Las primeras dos reglas para transporte, mostradas en la tabla 14, son consideradas como reglas de inferencia, ya que evalúan factores externos como el posible costo en tiempo y dinero de acuerdo a las horas de viaje y el tipo de transporte preferido entre una ciudad y otra. Las últimas reglas tienen como objetivo identificar si existe un estado de inferencia producido por las primeras dos reglas, de ser así almacenan las instancias de transporte para ser presentadas al usuario. Las demás reglas tienen como finalidad seleccionar y presentar las instancias que cumplen total o parcialmente con las preferencias del usuario.

Antecedentes R1 R2 El tipo de transporte preferido es autobús Si N/E

El tiempo de recorrdio del transporte entre las ciudades >= 6 hrs Si N/E

El tipo de transporte preferido es avión N/E Si

El tiempo de recorrdio del transporte entre las ciudades <= 4 hrs N/E Si

Consecuente Activa R10 Activa R11

Tabla 14. Reglas de inferencia para transportes en SyRec

140

La producción de las reglas de mostradas en la tabla 15, es el resultado de identificar las condiciones que determinan que recursos puedan satisfacer al usuario de manera heurística.

Estas condiciones son asumidas bajo la consideración que el usuario debe conectar todas las ciudades con un transporte iniciando por la ciudad origen y terminando en la ciudad origen. Las condiciones se encuentran establecidas de manera jerárquica con el objetivo de establecer un cierto grado de satisfacción de las instancias del recurso con respecto de las preferencias del usuario.

Antecedentes R3 R4 R5 R6 R7 R8 R9 R10 R11 La instancia de transporte contiene a la ciudad destino

Si Si Si Si Si Si Si Si Si

La instancia de transporte esta disponible en el tipo de horario preferido

Si No Si Si Si No No Si Si

La instancia de transporte contiene la clase de asiento en la que se desea viajar

Si Si No Si No Si No Si Si

El tipo de transporte es el mismo que el preferido por el usuario

Si Si Si No No No No No No

Consecuente MT MH MC MO MO MO MO MO MO

Tabla 15. Reglas de filtrado para las instancias de transporte en SyRec.

El orden de activación se lleva a cabo de la siguiente manera:

• Si las reglas 1 o 2 se activan, las reglas 10 y 11 se activaran respectivamente. • Si la regla 3 se activa termina. • Si la regla 3 no se activa, entonces las reglas 4 y 5 se activarán. • Si las reglas 3 y 4 no se activan, entonces las reglas 5 y 6 se activarán. • Si las reglas 3, 4, 5 y 6 no se activan, entonces las reglas 7 y 8 se activan. • Si las reglas 3, 4, 5, 6, 7 y 8 no se activan, entonces las regla 9 se activa. • Si las regla 6 se activa entonces ya no se activa ni 10 ni 11.

Los consecuentes representan conjuntos de instancias similares de acuerdo a la

siguiente notación:

• MT – Concordancia total. • MH – Concordancia en horario. • MC – Concordancia en la clase del transporte.

141

• MO – Otras concordancias.

El orden de activación establece el filtro e inferencia respecto de los transportes que deberán ser presentados al usuario. Este mismo orden es respetado en la presentación de las instancias hacia el usuario. Producción de reglas de alojamiento

En la producción de reglas de alojamiento, se han utilizado únicamente reglas de filtrado y ordenamiento con base en las características del alojamiento, se asume que la heurística utilizada para establecer las reglas de filtrado son suficientes para proveer un conjunto de ítems razonable, como se puede observar en la tabla 16.

Antecedentes R1 R2 R3 R4 R5 R6 R7 El instancia de alojamiento tiene las facilidades preferidas

Si Si No Si Si No No

El tipo de habitación preferida es individual

Si Si Si Si Si Si Si

El instancia de alojamiento contiene el tipo de habitación preferido

Si Si Si Si Si Si Si

El instancia de alojamiento tiene un precio accesible para el número y tipo de habitaciones

Si No Si Si No Si No

El instancia del alojamiento es del tipo preferido

Si Si Si No No No No

Consecuentes MT MF MP MO MO MO MO

Tabla 16. Reglas de alojamiento en SyRec

Como se puede apreciar en la tabla 16, son 7 reglas principales que son replicadas

para cada tipo de habitación (sencilla, doble, triple y cuádruple).

El orden de activación se lleva a cabo de la siguiente manera:

• Si las reglas 1 se activa, termina. • Si la regla 1 no se activa, se activan las reglas 2 y 3. • Si las reglas 1, 2 y 3 no se activan, se activa la regla 4. • Si las reglas 1, 2, 3 y 4 no se activan, se activa la regla5 y 6. • Si las reglas 1, 2, 3, 4, 5 y 6 no se activan, se activa la regla 7.

Los consecuentes representan conjuntos de instancias similares de acuerdo a la

siguiente notación:

142

• MT – Concordancia total. • MF – Concordancia con las facilidades. • MP – Concordancia con el precio. • MO – Otras concordancias.

El orden de activación establece el filtro e inferencia respecto de los alojamientos

que deberán ser presentados al usuario. Este mismo orden es respetado en la presentación de las instancias hacia el usuario. Producción de reglas de restaurantes

En la producción de reglas de restaurantes, se han utilizado reglas de filtrado y ordenamiento, así como de inferencia. Se asume que la heurística utilizada para establecer las reglas de filtrado son suficientes para proveer un conjunto de ítems razonable, como se puede observar en la tablas 17 y 18.

Antecedentes R1 R2 La preferencia para el tipo de restaurante T fue seleccionada Si Si

La instancia del restaurante es del tipo T Si Si

La instancia del restaurante tiene un precio accesible Si No

Consecuente MP MT

Tabla 17. Reglas de restaurantes en SyRec

En la tabla 17, se muestra la evaluación de un tipo de restaurante el cual ha sido especificado por el usuario. Si el restaurante tiene un precio accesible, es decir que se encuentra dentro del rango de precios establecidos por el usuario, se agrega como una concordancia en precio (MP) en su defecto se agrega como una concordancia de tipo (MT). Estas dos reglas son replicadas para cada tipo de restaurante (comida italiana, comida mexicana, etc). El orden de activación establecido se secuencial y excluyente.

Antecedente RA RB La preferencia por restaurantes de comida italiana no ha sido especificada No No

La preferencia por restaurantes de comida mexicana no ha sido especificada No No

La preferencia por restaurantes de comida pescados y mariscos no ha sido especificada No No

La preferencia por restaurantes de comida rápida no ha sido especificada No No

La instancia del restaurante tiene un precio accesible Si No

Consecuente MP MC

Tabla 18. Reglas de inferencia de restaurantes en SyRec

143

En la tabla 18, se muestra la evaluación de un tipo de restaurante en donde el usuario no especifico ninguna preferencia por lo que se asume que es indiferente el tipo de restaurante. Estas reglas clasifican a los restaurantes de acuerdo a si concuerdan con el precio, si no estan dentro del rango preferido entonces tienen concordancia sugerida (MC), en su defecto tendrán concordancia en precio (MP). El orden de activación es secuencial excluyente. Producción de reglas de lugares de interés

En la producción de reglas de lugares de interés, se han utilizado únicamente reglas de filtrado y ordenamiento con base en las preferencias del usuario y en las características del lugar de interés, se asume que la heurística utilizada para establecer las reglas de filtrado son suficientes para proveer un conjunto de ítems razonable, como se puede observar en la tabla 19.

Antecedentes R1 R2 R3 R4 La preferencia para el tipo de lugar T es "Fanático" Si – – –

La preferencia para el tipo de lugar T es "Me gusta" – Si – –

La preferencia para el tipo de lugar T es "Puede ser Interesante" – – Si –

La preferencia para el tipo de lugar T es "Indiferente" – – – Si

La instancia del lugar es del tipo T Si Si Si Si

Consecuente LF LM LP LI

Tabla 19. Reglas de lugares en SyRec

En la tabla 19, se muestra la evaluación de un lugar de interés con base en el grado

de preferencia expresado por el usuario y el orden de activación es secuencial y tiene la finalidad de ordenar los lugares de acuerdo al grado de preferencia del usuario. Producción de reglas de actividades

En la producción de reglas de actividades, se han utilizado únicamente reglas de filtrado y ordenamiento, se asume que la heurística utilizada para establecer las reglas de filtrado son suficientes para proveer un conjunto de ítems razonable, como se puede observar en la tabla 20.

144

Antecedentes R1 R2 R3 R4 La instancia de la actividad es del tipo T preferido Si Si Si –

La instancia de la actividad es del subtipo ST preferido Si Si Si –

La preferencia para la actividad (T,ST) es "Fanático" Si – – –

La preferencia para la actividad (T,ST) es "Me Gusta" – Si – –

La preferencia para la actividad (T,ST) es "Puede ser interesante"

– – Si –

El tipo de actividad T de la instancia de la actividad no se encuentra en las actividades preferidas

– – – Si

El tipo de actividad T de la instancia de la actividad no se encuentra en las actividades no-preferidas

– – – Si

Consecuente MF MG MP MI

Tabla 20. Reglas de actividades en SyRec.

En la tabla 20, muestra la evaluación de una actividad respecto del grado de

preferencia del usuario, lo que produce un ordenamiento de las instancias de las actividades. El orden de activación es secuencial.

De esta manera, se presentan consecutivamente los diferentes tipos de recursos de viaje en la interfaz de usuario. Lo siguiente es agregar al itinerario cada uno de los recursos que el usuario ha identificado con un mayor grado de preferencia. En la interfaz del usuario se provee de un contenedor donde se van introduciendo los recursos y el sistema se encarga de validar los tiempos para los cuales se desean reservar cada uno de los recursos seleccionados. En consecuencia se evita tener actividades traslapadas y el usuario puede identificar la cantidad de horas que puede llevarle la acción de seleccionar un tipo de transporte o una cierta actividad. En la interfaz, se le dirige al usuario para que llene su itinerario de manera que visite todas las ciudades destino evitando posibles “huecos” no satisfechos.

El principal factor que implica la existencia de un “hueco” en el itinerario – por hueco debe entenderse espacios de tiempo sin actividades turísticas – es el costo de proveer al usuario de una cierta libertad en la selección de los recursos de viaje. Pero aún dándose el caso de un “hueco” el sistema identifica los huecos y advierte al usuario, antes de almacenarlo. Sin embargo, solo almacenará itinerarios con este tipo de huecos, cualquier otro tipo de hueco evitara un posible almacenamiento del itinerario conformado; como pueden ser los huecos por falta de selección de transportes, alojamiento y cualquier otro tipo de recurso de viaje diferente de actividades turísticas. Para la implementación del RBR se ha utilizado la herramienta DRools [18].

145

6.3.4 El CBR y la recomendación de un itinerario turístico

El mecanismo de razonamiento basado en casos (CBR) es utilizado en SyRec en la

recomendación de itinerarios turísticos, de acuerdo a lo definido en la sección 6.2.5, por lo que en esta sección se definirán las métricas de similaridad, así como los algoritmos utilizados en la implementación del ciclo CBR utilizados para llegar a dicho fin.

En esta parte del sistema, el usuario interactúa con el sistema de recomendación para pedir itinerarios turísticos, siendo un caso dentro del CBR un problema-solución se tomará como base el modelado de casos descrito en la tabla 11 de la sección 6.3.2 para describir el funcionamiento de la recomendación de un itinerario turístico en SyRec.

De acuerdo al ciclo del CBR, descrito en la sección 4.2 se describirán en los siguientes párrafos los métodos que en cada paso del ciclo ayudaran a la recomendación de itinerarios. Recuperación de itinerarios

El objetivo de la recuperación de itinerario es definir un número k de itinerarios los cuales tengan perfiles de usuario similares, en otras palabras características dominantes similares. El algoritmo que esta orientado a encontrar un conjunto de casos con una cardinalidad es el algoritmo de vecinos más cercanos. En términos del CBR, un caso en SyRec es definido como una tupla (preferencias del usuario, itinerario solución).

El algoritmo de vecinos más cercanos obtiene los k mejores casos del conjunto de casos CR disponibles en la librería de casos. La distancia métrica utilizada en dicho algoritmo Métrica Heterogénea Euclidiana de Traslape (HEOM - Heterogeneous Euclidean-Overlap Metric) [56]. Sean x y y, un par de casos; xi y yi las características que definen los problemas de los casos respectivamente, entonces se tiene la siguiente fórmula:

( ) ( )∑∑ =

=

⋅=n

iiiiin

i i

yxdww

yxHEOM1

2

1

,1

, (4)

donde,

( )

−=

i

ii

iiiii

rango

yxyxoverlapyxd ),(

1

, (5)

146

y overlap(xi, yi) = 1 si xi ≠ yi y 0 de otra manera. El factor de normalización ∑ =

n

i iw1

en la

definición (11) es necesario cuando se comparan distancias que contienen ítems de diferentes espacios [46].

Entonces la similaridad es definida como la inversa de la distancia [46]:

( ) ( ) ( )( )yxdyxd

yxSim ,exp,

1, −== (6)

La HEOM fue considerada en lugar de la distancia euclidiana con el objetivo de

eliminar los posibles resultados contradictorios ésta métrica [46] y se asume que todas las características tienen el mismo grado de preferencia. El motivo principal de utilizar este algoritmo radica en total relevancia de cada una de las características de las preferencias del usuario. De esta manera, se ponderan los vecinos más cercanos de acuerdo al grado de preferencia sobre las características de un itinerario turístico dadas las preferencias del usuario. Reutilizar itinerarios

En el proceso de reutilización del CBR se considera la adaptación de la solución propuesta por el conjunto de casos recuperados. A través del adaptador de peso promedio (WeightedAverageAdapter) se encuentra una solución al problema tomando el valor promedio de las soluciones sugeridas con base a pesos obtenidos de las distancias entre el problema actual y los casos [14]. La principal razón de tomar este adaptador es que la principal característica que tiene mayor jerarquía en un itinerario es el precio el cual es tomado como el valor para la solución de referencia.

Sea c un nuevo caso, w el peso asociado a un caso recuperado y s la solución de este último caso; la solución mejor adaptada se calcula de acuerdo a (4)

∑∑ =

=

⋅=n

iiiin

ii

sww

psolucion

0

1)(

(7)

donde,

( ) ( )( ) )( 0cdiffcdiffcdiffw ini +−= (8)

y diff(c) es la diferencia o bien la distancia del caso c al caso objetivo.

147

Revisión de la solución

En el paso de revisión del CBR, se evalúa la calidad de la solución propuesta por el sistema. El valor de la calidad se encuentra entre 0 y 1, y se ha establecido que para una solución aceptable el valor mínimo aceptable sea 0.85. Entonces, si el valor de la solución propuesta es igual al valor igual de la solución referida (presupuesto establecido por el usuario), se dice que es una solución aceptable, si no es el caso de que suceda lo anterior el rating de la solución propuesta se obtiene de la siguiente manera:

22 )'()(

)'()(0.1)(

pSolucionpSolucion

pSolucionpSolucionsrating

+

−−= (9)

donde, la solución referida es Solucion(p) y la solución propuesta es Solucion (p’). Este proceso de revisión es tomado con base en [14]. Almacenamiento

El almacenamiento de un caso se lleva acabo si la distancia entre el caso a almacenar el caso más cercano sobrepasa un umbral especificado. Aunque para fines prácticos de la experimentación del comportamiento del sistema, se considero que siempre guarde el nuevo caso. Jerarquía de pesos

El valor de los pesos asociados a cada característica dominante de un caso, se muestra en la tabla 21.

148

Caso A

Viaje Pesos Lugares Pesos Presupuesto 3.00 Lugar Artesanias 30.00

Días Totales de Planeación 5.00 Lugar Bosques 30.00

Número de ciudades destino 8.00 Lugar Cascadas 30.00

Porcentaje de ciudades con playa 10.00 Lugar Galerias de Arte 30.00

Porcentaje de ciudades sin playa 10.00 Lugar Museos 30.00


Tipo transporte inter-ciudad 50.00 Lugar Pirámides 30.00

Clase transporte inter-ciudad 40.00 Lugar Playas 30.00


Alojamiento Facilidad-Alberca 100.00 Lugar Zoológicos 30.00

Alojamiento Facilidad-Bar 100.00 Actividades Alojamiento Facilidad-Clima 90.00 Actividades de Agroturismo 10.00

Alojamiento Facilidad-Cocina 100.00 Actividades de Aventura acuática 10.00

Alojamiento Facilidad-Estacionamiento 100.00 Actividades de Aventura aérea 10.00

Alojamiento Facilidad-Gimnasio 100.00 Actividades de Aventura terrestre 10.00

Alojamiento Facilidad-Internet 80.00 Actividades de Cultural 10.00

Alojamiento Facilidad-Jacuzzi 100.00 Actividades de Deporte acuático 10.00

Alojamiento Facilidad-Restaurante 100.00 Actividades de Deporte aéreo 10.00

Alojamiento Facilidad-SPA 100.00 Actividades de Deporte terrestre 10.00

Alojamiento Facilidad-Telefono 30.00 Actividades de Ecoturismo 10.00

Alojamiento Facilidad-TV Cable 50.00 Actividades de Familiar 10.00


Comida Italiana 50.00 Actividades de Turismo rural 10.00

Comida Mexicana 50.00 Actividades de Turismo urbano 10.00

Comida Pescados & Mariscos 50.00

Comida Rápida 50.00

Comida Vegetariana 50.00

Tabla 21. Especificación de pesos en SyRec

La heurística que se siguen estos valores se basa en las necesidades generales de un

usuario hacia un itinerario de viaje. La jerarquía se encuentra en los valores de los pesos asociados a cada característica de las preferencias de viaje. Básicamente los principales factores que de alguna manera afectan un itinerario son:

1. Precio 2. Días de planeación 3. Número de ciudades destino 4. El tipo de ciudades contempladas y las actividades a realizar.

149

En la tabla 21, los valores más pequeños dan más importancia a las características que los valores más grandes.

6.3.5 Software de desarrollo

Las herramientas de software que se utilizaron para la implementación del RBR y

CBR son las siguientes:

• DRools. Es un motor de inferencia basado en el algoritmo RETE adaptado al lenguaje Java. Se provee una adaptación para el paradigma orientado a objetos y permite la construcción de reglas de manera natural [18].

• Indiana University Case-Based Reasoning Framework (IUCBRF) para el CBR. Es

un herramienta de propósito general para la implementación del CBR, que implementa diversas técnicas para el ciclo CBR, las cuales contienen a las técnicas mencionadas en esta sección [14].

6.4 Experimentación

El sistema SyRec es un prototipo experimental que demuestra la integración del RBR y CBR para resolver la recomendación de ítems e itinerarios turísticos. Para la fase de experimentación no se han considerado métricas off-line y online, ya que éstas métricas se basan en la comparación de dos sistemas de recomendación bajo el mismo conjunto de datos. Los casos de prueba y la experimentación referida en este capítulo tienen la finalidad de mostrar el funcionamiento coherente del sistema.

La experimentación de SyRec se basa en los siguientes puntos:

1. Dadas las preferencias del usuario, analizar las recomendaciones sugeridas de ítems turísticos para conformar un itinerario.

2. Dadas las preferencias del usuario, analizar las recomendaciones sugeridas de

itinerarios turísticos.

6.4.1 Recomendación de ítems turísticos

Para la experimentación de la recomendación de ítems turísticos se tienen el siguiente caso de prueba, definido en la tabla 22.

150

Preferencias del usuario

Viaje Lugares

Ciudad Origen Ciudad de México Artesanias 0.00

Ciudad Destino Veracruz Bosques 0.75

Numero de Viajeros 1 Cascadas 0.50

Presupuesto $5,000.00 Galerias Arte 0.75

Dias de Planeacion 3 Museos 1.00

Alojamiento en ciudad con playa Parques Nacionales 0.00

Tipo Hotel Piramides 0.00

Habitaciones

Sencilla(1), Doble(0),

Triple(0), Cuádruple(0) Playas 1.00

Precio Minimo $100.00 Sitios Coloniales 1.00

Precio Máxico $600.00 Zoologicos 0.25

Facilidades Alojamiento Actividades Requeridas

Alberca false Aventura Acuática-Hidrospeed 1.00

Bar false Aventura Acuática-Kayak 1.00

Clima false Aventura Acuática-Rafting 1.00

Cocina false Aventura Acuática-Ski 1.00

Estacionamiento false Aventura Acuática-Snorkel 1.00

Gym false Aventura Acuática-Surfing 1.00

Internet false Aventura Aérea-Paracaidismo 0.75

Jacuzzi false Aventura Aérea-Salto del Bungee 0.75

Restaurant false Aventura Terrestre-Escalada 0.50

SPA false Aventura Terrestre-MotoX 0.50

Telefono true Deporte Acuatico-Snorkel 1.00

T.V.Cable true Deporte Acuatico-Veleo 1.00

Transporte Ecoturismo-Liberacion de Tortuga 0.75

Tipo Autobús Ecoturismo-Observacion Sideral 0.75

Clase Económica

Ecoturismo-Observacion de flora y

fauna 0.75

Restaurantes Ecoturismo-Visita a los Arrecifes 0.75

Comida Italiana true Turismo Urbano-Edificios Importantes 0.50

Comida Mexicana true Turismo Rural-Ranchos 0.50

Comida

Pescados&Mariscos true Actividades NO Requeridas

Comida Rapida true Cultural-Cine 0.00

Comida Vegetariana true Cultural-Concierto de Orquesta 0.00

Precio Min $30.00 Cultural-Danza 0.00

Precio Max $120.00 Cultural-Teatro 0.00

Tabla 22. Caso de prueba para la recomendación de ítems

151

Se probará la coherencia e inferencia de las recomendaciones, de acuerdo a las preferencias del usuario. De manera general, los ítems que cumplen con el total de preferencias del usuario con respecto al tipo de recurso se presentarán en primer lugar (identificados por el color amarillo) y posteriormente si existe inferencia del sistema se mostrará un conjunto de ítems que pueden ser de interés para el usuario (identificados por otros colores).

Una premisa del sistema es el ordenamiento de recursos por precio, independientemente de otras características, ya que el costo es considerado como el principal discriminante en la selección de ítems turísticos.

De acuerdo a la tabla 22, que describe las preferencias del usuario. El sistema realiza la inferencia que viajará de México D.F. a Veracruz sabiendo que el viaje tiene una duración >= 6 horas, el sistema le propone las instancias de transporte aéreo, como se puede apreciar en la figura 49.

Los transportes encontrados para la recomendación del usuario son encontrados respecto a la clase económica. La inferencia de los transportes aéreos se toma la misma clase que la especificada para los transportes terrestres.

Figura 49. Inferencia de Syrec para transportes

El usuario especifica alojamientos con dos facilidades requeridas: teléfono y t.v.

cable. El sistema ha encontrado alojamientos del tipo preferido y le hace saber al usuario a

152

través de la interfaz que encontró hoteles que tienen más facilidades, como se puede observar en la figura 50.

Figura 50. Recomendaciones de alojamiento.

En la figura 50, se puede observar que los alojamientos encontrados cumplen con

todas las características que ha requerido entonces no infiere otras opciones. Sin embargo si el usuario, hubiera especificado que requeriría de un alojamiento de tipo “hostal” con las siguientes facilidades: bar, Internet, teléfono y t.v. cable; el sistema encuentra que no hay hostales en ese rango de precio con todas las facilidades y muestra alojamientos que pasan del precio pero que son de tipo hostal pero que no tienen las facilidades requeridas, de la misma manera le propone al usuario alojamientos que tienen las facilidades que ha especificado el usuario. Todo lo anteriormente descrito puede ser observado en la figura51.

153

Figura 51. Filtrado e inferencia de alojamientos

En el ámbito de los restaurantes, el usuario ha especificado que requiere restaurantes de todos los tipos definidos en la interfaz. Entonces el sistema clasifica los restaurantes y presenta los que se encuentran en el rango de precio, como se puede observar en la figura 52. De la misma manera, sería recomendado el mismo conjunto de restaurantes si el usuario no hubiera especificado algún tipo.

Figura 52. Filtrado y ordenamiento de restaurantes.

En el ámbito de los lugares de interés, el sistema evalúa las preferencias del usuario y clasifica el tipo de recursos, como se puede apreciar en la figura 53. Los tipos de lugares a

154

los que el usuario es fanático son presentados en primer lugar y posteriormente se van presentando los de menor grado de preferencia.

Figura 53. Filtrado y ordenamiento de lugares.

De manera similar ocurre con los recursos turísticos de actividades, como se puede ver en la figura 54. El sistema en este caso filtra y ordena los ítems que son requeridos no considerando aquellos que han sido calificados como no interesado.

Figura 54. Filtrado y ordenamiento de tipos de actividades.

155

Cuando un usuario desea agregar un ítem a su itinerario e iniciar el proceso de

planeación puede agregarlo a través de la interfaz y así libremente ir modificando su itinerario hasta que éste sea de su agrado.

Figura 55. Itinerario en proceso de planeación.

En la figura 55, se muestra un itinerario parcialmente conformado. La interfaz le

permite al usuario identificar de manera ordenada en el tiempo las actividades que realizará, además del transporte que se ve reflejado en el tiempo de viaje que le llevará trasladarse de una ciudad a otra.

6.4.2 Recomendación de itinerarios turísticos

El proceso de recomendación inicia cuando el usuario requiere que el sistema le sugiera algunos posibles itinerarios de su interés. Para mostrar la experimentación en este ámbito se propone el siguiente caso de prueba que es descrito en la tabla 23.

156

Caso A

Viaje Lugares Presupuesto $4,000 Lugar Artesanias 0.00

Días Totales de Planeación 3 Lugar Bosques 0.75

Número de ciudades destino 1 Lugar Cascadas 0.50

Porcentaje de ciudades con playa 100% Lugar Galerias de Arte 0.75

Porcentaje de ciudades sin playa 0% Lugar Museos 1.00


Tipo transporte inter-ciudad Autobús Lugar Pirámides 0.00

Clase transporte inter-ciudad 1a clase Lugar Playas 1.00


Alojamiento Facilidad-Alberca Si Lugar Zoológicos 0.25

Alojamiento Facilidad-Bar Si Actividades Alojamiento Facilidad-Clima Si Actividades de Agroturismo 0.75

Alojamiento Facilidad-Cocina No Actividades de Aventura acuática 0.50

Alojamiento Facilidad-Estacionamiento No Actividades de Aventura aérea 0.33

Alojamiento Facilidad-Gimnasio No Actividades de Aventura terrestre 0.25

Alojamiento Facilidad-Internet Si Actividades de Cultural 1.00

Alojamiento Facilidad-Jacuzzi No Actividades de Deporte acuático 0.75

Alojamiento Facilidad-Restaurante Si Actividades de Deporte aéreo 0.50

Alojamiento Facilidad-SPA No Actividades de Deporte terrestre 1.00

Alojamiento Facilidad-Telefono Si Actividades de Ecoturismo 0.50

Alojamiento Facilidad-TV Cable Si Actividades de Familiar 0.50


Comida Italiana No Actividades de Turismo rural 0.00

Comida Mexicana Si Actividades de Turismo urbano 0.00

Comida Pescados & Mariscos Si

Comida Rápida No

Comida Vegetariana No

Tabla 23. Caso de prueba para la recomendación de itinerarios.

En la modelación de un caso existen características generalizadas, tal es el caso de

las ciudades destino y del alojamiento. Para este caso de prueba el usuario establece su ciudad de origen: México, D.F. y desea visitar Veracruz (ciudad con playa) y requiere de un alojamiento de tipo hotel con las facilidades especificadas en el caso de prueba, como se puede apreciar en la figura 56.

157

Figura 56. Preferencias de Viaje

Los precios por habitación fueron establecidos en un rango entre $100 y $600 como

se puede apreciar en la figura 57.

Figura 57. Preferencias de alojamiento.

158

La otra característica que fue generalizada es el rango de precio de los restaurantes, por lo que se debe especificar que el rango establecido por el usuario para este tipo de recurso se encuentra entre $30 y $120.

Una vez que el sistema modela las preferencias del usuario para ser tratado como un caso, el proceso de recomendación por CBR se inicia.

Figura 58. Recomendación de itinerarios.

Como se puede apreciar en la figura 58, el sistema busca los 5 casos más cercanos o

similares a las preferencias del usuario. La solución de referencia se basa en el presupuestodel usuario, el cual fue establecido en $4,000. La recomendación del sistema con base en el CBR propone al usuario el caso 14, el cual tiene un precio cercano a su presupuesto.

Si bien el presupuesto es el principal discriminante, el sistema no solamente debe guiarse por este hecho, sino que tratar de adecuarse a las preferencias del usuario. Esto se puede ver como si el usuario quiera gastar el monto de dinero que ha especificado, entonces un itinerario de menor costo puede constituir recursos turísticos de menor calidad. Para probar esta aseveración se muestra el caso 1 y puede ser apreciado en la figura 59.

159

Figura 59. Casos propuestos para la recomendación de itinerarios

Tanto en la figura 58 como en la figura 59, el sistema provee la justificación

explicita que la solución que se propone tiene una aceptación del 97% respecto de las preferencias del usuario.

Puesto que el sistema ha recomendado un itinerario turístico calificado con alto rating, se procede puede guardarlo o bien modificarlo.

Para la modificación del itinerario, el sistema envía el itinerario a modo de edición (véase figura 60) para que el usuario pueda acceder a la información de los recursos turísticos contenidos en dicho itinerario.

En principio, se puede comprobar que la generalización de la ciudad destino puede ser un primer obstáculo en la satisfacción del usuario, como se aprecia en la figura, la ciudad destino del itinerario recomendado no fue Veracruz sino Acapulco. Sin embargo, puede no existir ningún paquete para la ciudad de Acapulco que concuerde con las características del usuario entonces de esta manera se le puede ofrecer una opción de su interés.

160

Figura 60. Itinerario sugerido en modo edición.

En itinerarios donde existen pocos días de planeación, es posible que el número de

actividades a realizar no reflejen las preferencias del usuario ya que el conjunto de preferencias puede abarcar más tipos de recursos de los que realmente se establecen en el itinerario.

Sin embargo, esto puede ser un motivo para modificar el itinerario tomando el itinerario sugerido como una recomendación “en busca de inspiración” [45].

6.5 Comparativa entre Nutking, @lisTechNet y SyRec

En esta sección se describirán principalmente las características de cada uno de los enfoques propuestos por los sistemas Nutking, @lisTechnet y Syrec.

La división de los procesos de recomendación en Syrec, diferencía tanto a los ítems como a los itinerarios turísticos. Cuando se requiere planear un itinerario se necesitan un conjunto de opciones de interés y las cuales puedan ser comparadas. En el caso de Nutking y @lisTechNet, solo se dan las mejores 5 opciones o bien opción por opción respectivamente.

161

La necesidad de ocupar ratings ha sido abordada en Nutking, los cuales son utilizados para filtrar y seleccionar (CBR) tanto los itinerarios como los ítems turísticos. En el caso de @lisTechNet, se elimina el uso de ratings realizando una evaluación de las preferencias del usuario para seleccionar un paquete turístico como plantilla de un itinerario turístico evitando la necesidad de ratings; el filtrado y selección la lleva cabo el sistema (RBR) ofreciendo recursos turísticos que pueden ser de interés. SyRec de la misma manera, no utiliza ratings, sino que evalúa las características de los ítems respecto a las preferencias del usuario (RBR), además de tomar en consideración factores externos que pueden impactar en la toma de decisión del usuario. Cuando ocurre una solicitud para la recomendación de itinerarios, se le ofrece al usuario un conjunto de 5 itinerario en los que las preferencias de los usuarios pueden ser similares al usuario actual. La planeación de un itinerario en SyRec, se beneficia de los dos mecanismos de razonamiento: RBR y CBR. Principalmente, aporta un conjunto de recursos que son preferentes del usuario (RBR) para poder modificar algún itinerario sugerido (CBR). El conjunto de recursos filtrados, se agregan recursos inferidos por el sistema lo que significa un mayor grado de confianza en el conocimiento del sistema. En comparación con el uso de ratings, el usuario debe confiar en otros usuarios que pueden no tener los mismos intereses o no se encuentran bajo las mismas circunstancias. En la tabla 24, se sintetizan los enfoques de cada uno de estos sistemas.

Nutking @lisTechNet Syrec

Técnica de razonamiento CBR RBR RBR y CBR en distintos dominios

Representación del conocimiento

Casos Ontologías y reglas

Reglas y Casos

Necesidad de ratings Si No No Recomendación de ítems CBR RBR RBR Recomendación de itinerarios

CBR RBR CBR

Conformación de itinerarios dinámicos

CBR iterativo RBR iterativo RBR, CBR+RBR

Soporte de múltiples ciudades

Si Si Si

Tipos de usuarios Principiantes, Intermedios, Avanzados

Principiantes Principiantes, Intermedios, Avanzados

Debilidad Ratings Tiempo Contenido Itinerario

Fortaleza Contenido Itinerario

Replicación dinámica

Modificación de itinerarios

Filtrado basado en CBR(kNN) Query Query, Reglas, CBR(kNN)

Ordenamiento basado en Caracteristas y ratings

Query Características y precios

Inferencia basado en Casos Reglas Reglas y Casos

Itinerarios Permutación de recursos

Iterativos en recursos

Dinámicos

Tabla 24. Comparativa entre Nutking, @lisTechNet y SyRec

163

7. Resultados, conclusiones y trabajo futuro

El desarrollo de este trabajo de tesis estuvo enfocado en los mecanismos de razonamiento basado en casos (RBR) y razonamiento basado en reglas (RBR) para el desarrollo de un sistema de recomendación turística como una aportación al proyecto @lisTechNet.

7.1 Resultados

Los resultados obtenidos con base en este trabajo de tesis son:

• El enfoque en el desarrollo de una metodología y un sistema híbrido de recomendación turística permite innovar dentro del ámbito de los sistemas de recomendación.

• Una metodología que provee un conjunto de modelos para llevar a cabo los

procesos de recomendación de recursos e itinerarios turísticos, en donde se establece la abstracción de las preferencias del usuario para ser manipuladas por los mecanismos de razonamiento.

• El empleo del RBR y CBR justifican la recomendación de los ítems e itinerarios

sugeridos con base en la representación del conocimiento de la producción de reglas y del método de revisión implementado por el CBR.

164

• La fortaleza explotada del RBR es la representación del conocimiento soportada por la producción de reglas. A través de las reglas se produce la evaluación de las características de los recursos turísticos y las preferencias del usuario lo que produce como resultado un conjunto de recursos personalizados.

• En el ámbito del RBR, el correcto orden de disparo de las reglas, permite proveer el

filtrado, ordenamiento e inferencia de recursos turísticos. Sin embargo, es necesaria la manipulación a través de estructuras de control.

• La fortaleza del CBR radica en encontrar problemas similares. A través del CBR se

encuentran perfiles similares de usuarios con base en los cuales se encuentran itinerarios para ser sugeridos o recomendados al usuario.

• En el ámbito del CBR, se identificó la necesidad de establecer métricas de

similaridad adecuadas para los tipos de características de los casos. Tal es el caso de la distancia euclidiana que da el mismo peso a un conjunto de características, lo cual no aplica en las características de las preferencias del usuario. Por tal motivo se utilizo la Métrica Heterogénea Euclidiana de Traslape que normaliza la distancia y pondera las distancias entre los casos.

• Las preferencias del usuario proveen métricas para la evaluación de los recursos

turísticos. Sin embargo, el usuario puede sesgar la elección de recursos turísticos y si en un momento pensaba realizar varias actividades, solo puede enfocarse en algunas. Por lo que este patrón hace que el itinerario turístico pueda no satisfacer a otro usuario.

• El sistema Syrec, el cual es un sistema prototipo que fue desarrollado con la

metodología propuesta y que sustenta el enfoque de este trabajo.

Las principales aportaciones de este trabajo de tesis son:

• Una metodología que define y establece el enfoque para desarrollar un sistema de recomendación turística basado en RBR y CBR. Se han definido modelos que permiten abstraer estructuras complejas que se encuentran inmersas en el ámbito de la recomendación turística como lo son las características de los recursos turísticos y preferencias del usuario. El modelado de dichas estructuras permite aplicar el RBR y CBR en los procesos de recomendación de ítems e itinerarios turísticos.

• La arquitectura de un sistema de recomendación turística basado en RBR y CBR

desarrollado con la metodología propuesta. La arquitectura define la funcionalidad y los componentes que debe contemplar un sistema de este tipo.

165

7.2 Conclusiones

El proceso de planeación de un itinerario turístico es sumamente complejo ya que un usuario busca múltiples recursos que deben satisfacer igual o mayor número de restricciones. Un sistema que trate de satisfacer todas las restricciones del usuario puede llegar recomendar un conjunto mínimo de recursos o ninguno. Entonces, se deben considerar las características más importantes tanto del usuario como de los recursos turísticos para proveer un conjunto que pueda satisfacer en un cierto grado del usuario.

Un sistema de recomendación turística debe tener la habilidad de influir en la toma de decisión de un usuario. Es claro, que los usuarios muchas veces no tienen una idea clara de lo que desean o requieren dado que un sistema de recomendación tiene un conocimiento implícito de la información que maneja debe estar dotado de capacidades para inferir lo que un momento dado le conviene más a un usuario de acuerdo a sus preferencias.

En el área de la inteligencia artificial, los mecanismos de RBR y CBR han probado su eficacia en la solución de problemas y ambos tienen la característica de replicar parcialmente el razonamiento humano. Sin embargo los dominios de problema que pueden abarcar están delimitados. Dentro del proceso de planeación turística tanto el RBR y CBR, solucionan dos problemas que se encuentran en su dominio: diagnosticar los recursos turísticos respecto de las preferencias del usuario en el caso del RBR y utilizar la experiencia pasada en la solución de problema para el caso de encontrar itinerarios similares.

Un sistema de recomendación turística basado puramente en CBR, itera la metodología del CBR para sugerir tanto ítems e itinerarios turísticos. El RBR elimina la iteración del CBR en donde para cada ítem turístico se deben establecer métricas de similaridad que pueden ser difíciles de modelar o entender. El principal beneficio del RBR en éste ámbito es poder modificar las reglas de recomendación y así la lógica de negocio sin la necesidad de modificar el código del sistema. Además, un sistema de recomendación colaborativo es dependiente de una retroalimentación del usuario acerca del grado de satisfacción para los ítems que son de su interés. El uso del RBR no requiere del rating de un recurso, sino que se filtran los ítems de mayor interés para el usuario e infieren otros que pueden ser potencialmente la elección del usuario, finalmente un rating no necesariamente refleja que el recurso turístico vaya a ser totalmente de su agrado.

Un factor de suma trascendencia en el proceso de recomendación es la interfaz del usuario y el tipo de interacción que provea. Es claro que el desarrollo de una interfaz altamente interactiva es altamente costoso por el modelado lógico que esto requiere. Sin embargo, la planeación turística no puede ser concebida sobre interfaces que no permiten establecer un orden en el tiempo de planeación, como el provisto por SyRec.

Finalmente, este trabajo de tesis sitúa un nuevo enfoque a través de la metodología propuesta y del sistema desarrollado, en la construcción de sistemas de recomendación

166

turística, tanto en la interacción del usuario a través de la interfaz como en los procesos de recomendación basados en mecanismos de razonamiento confiables.

7.3 Trabajo futuro

Dentro del desarrollo de este trabajo de tesis se han identificado las siguientes áreas de continuidad:

• El desarrollo comercial de un sistema de recomendación turística basado en RBR y CBR con base en la metodología propuesta y en el enfoque de la interfaz del prototipo desarrollado puede ser benéfico para la difusión de recursos turísticos de un país o ciudad.

• Extender la metodología propuesta para modelar un sistema de recomendación

turística de manera distribuida. En donde el paradigma de los sistemas multiagente pueda abordarse.

• Aplicar métricas on-line que permitan identificar los beneficios reales de un sistema

híbrido de recomendación turística. Esto es importante para revelar la situación de un sistema de este tipo para identificar los patrones de uso que una experimentación de comportamiento no muestra.

• Incorporar el modelado del itinerario turístico al conjunto de modelos propuestos en

la metodología. Dado que las preferencias del usuario pueden no reflejar totalmente lo que contenga el itinerario turístico.

167

REFERENCIAS

[1] @lis. Aliance for Information Society. http://europa.eu.int/comm/europeaid/projects/alis/index_en.htm (Agosto 16, 2006).

[2] @lis TechNet Project. Cultural Application Demonstrator.

http://alis.cs.bath.ac.uk/personal-agent-drools/browser/www/template/TPA.jsp (Agosto 16, 2006).

[3] @lis TechNet Project. European Commission EuropeAid Sponsored Project. http://www.alis-technet.org/index.php (Agosto 16, 2006).

[4] @lis TechNet Project. Knowledge capture in @lis Technet. Technical report: tr-alis-technet-wp4-006-v02.

[5] @lis TechNet Project. Ontologies Documentation. Technical report: tr-alis-

technet-wp4-OntologiesDocumentation-v01.

[6] @lis TechNet Project. Reasoning engines for planning. Technical report: tr-alis-technet-wp4-011-v01.

[7] @lis TechNet Project. Rule conceptualisation in @lis TechNET. Technical report:

tr-alis-technet-wp4-003-v03. [8] AAMODT, A.; PLAZA, E. Case-Based Reasoning: Foundational Issues,

Methodological Variations, and System Approaches. AICom - Artificial Intelligence Communications, IOS Press, 1994, Vol. 7: 1, pp. 39-59.

[9] Agentcities. Agent Network Services forum.

http://www.agentcities.net (Agosto 14, 2006)

[10] ARSLAN, B. et al. A dynamic approach to feature weighting. Proceedings of

Data Mining 2002 Conference, Bologna, Italy. [11] ARSLAN, B.; RICCI, F. Case Based Session Modeling and Personalization in a

Travel Advisory System. Workshop on Recommendation and Personalization in eCommerce. 2nd International Conference on Adaptive Hypermedia and Adaptive Web Based Systems, AH 2002.

[12] BÄTZOLD, M. et al. Desarrollo de servicios turísticos a usuarios. Conferencia

de la Asociación Española para la Inteligencia Artificial (CAEPIA 2003)

168

[13] BERKA, T.; PLÖßNIG, M. Designing Recommender Systems for Tourism. The International Federation for IT and Travel & Tourism’s (IFITT) ENTER 2004 Conference, Cairo, Egypt.

[14] BOGAERTS, S. Indiana University Case-Based Reasoning Framework.

http://www.cs.indiana.edu/~sbogaert/CBR (Agosto 3, 2006)

[15] BUCHANAN, B. G.; SHORTLIFFE, E. H. Rule-based expert systems: The MYCIN experiments of the Stanford heuristic programming project. United States of America: Addison-Wesley, 1985. 748p.

[16] CAMACHO, D et al. Electronic Tourism in the Web: An artificial intelligence

approach. Congreso Turismo y Tecnologías de la Información y las Comunicaciones (TURITEC), 2000.

[17] DIETORECS Project. Intelligent Recommendation for Tourist Destination

Decision Making. http://dietorecs.itc.it/Index.html (Agosto 16, 2006)

[18] Drools. Rules engine implementation.

http://legacy.drools.codehaus.org/ (Agosto 3, 2006)

[19] Eurovacations. Sistema de información y recomendación turística. http://www.eurovacations.com (Agosto 16, 2006)

[20] Expedia Travel. Sistema de información y recomendación turística.

http://www.expedia.com/ (Agosto 16, 2006)

[21] FESENMAIER, D. R. et al. DIETORECS: Travel Advisory for Multiple Decision Styles. Proceedings of Enter conference, Helsinki, Finland, January 29 - 31, 2003.

[22] GRABLER, K; ZINS, A. H. Vacation Trip Decision Styles as Basis for an

Automated Recommendation System: Lessons from observational Studies. ENTER 2002 Conference, Innsbruck, Austria.

[23] GARZOTTO, F. et al. Ubiquitous access to cultural tourism portals. Database

and Expert Systems Applications, 2004. 15th International Workshop on Publication IEEE. 30 Aug.-3 Sept. 2004. pp. 67- 72

[24] GOLDING, A. R.; ROSENBLOOM P. S. Improving rule-based systems through

case-based reasoning. Readings in Knowledge Acquisition and Learning: Automating the Construction and Improvement of Expert Systems. 1993, pp. 759-764.

169

[25] GOY, A.; MAGRO, D. STAR: a Smart Tourist Agenda Recommender. Proceedings of the 16th European Conference on Artificial Intelligence, 2004.Valencia, España.

[26] HANEMANN, A. A Hybrid Rule-Based/Case-Based Reasoning Approach for

Service Fault Diagnosis. 20th International Conference on Advanced Information Networking and Applications (AINA 2006), April 2006, Vienna, Austria. IEEE Computer Society 2006, Vol. 2, pp. 734-740.

[27] HAYES, C. et al. A Case-Based Reasoning View of Automatic Collaborative

Filtering. Case-Based Reasoning Research and Development: 4th International Conference on Case-Based Reasoning, ICCBR 2001, Vancouver, , Canada. Springer Berlin / Heidelberg, Volume 2080/2001, pp. 234-248.

[28] HERLOCKER, J. L. et al. Evaluating collaborative filtering recommender

systems. ACM Transactions on Information Systems (TOIS), Volume 22, Issue 1, 2004. pp. 5 – 53.

[29] KIM, C. E-Tourism: An Innovative Approach for the Small and Medium-Sized

Tourism Enterprises (SMTEs) in Korea. Conference on Innovation and Growth in Tourism, 2003. Organization for Economic Co-operation and Development (OECD). Lugano, Switzerland.

[30] KONAR, A. Artificial Intelligence and soft computing: behavioral and cognitive

modeling of the human brain. United States of America: CRC Press, 2000. 786p.

[31] LEAKE, D. B. Case-Based Reasoning: Experiences, Lessons and Future Directions. AAAI Press / MIT Press, 1996. 525 p.

[32] LORENZI, F.; RICCI, F. Case-Based Recommender Systems: a Unifying View.

Intelligent Techniques for Web Personalization. Springer Verlag, 2005. pp. 89-113.

[33] MITSCHE, N. Understanding the Information Search Process within a Tourism

Domain-specific Search Engine. The International Federation for IT and Travel & Tourism’s (IFITT) ENTER 2005 Conference, Innsbruck, Austria.

[34] MOLINA, M.; FÉLIZ M. Comercio electrónico aplicado al turismo. Agosto,

2005. http://www.tid.es/html_eng/sostenibilidad/articulos_sostenibilidad.html. (Julio 24, 2006)

[35] ORGANIZACIÓN DE LAS NACIONES UNIDAS, El comercio electrónico y el

turismo: nuevas perspectivas y retos para los países en desarrollo. Conferencia de las naciones unidas sobre comercio y desarrollo. http://www.unctad.org/Templates/meeting.asp?intItemID=1942&lang=3&m=4338&info=doc (Agosto 16, 2006)

170

[36] NIKNAFS, A. A. et al. A Case-Based Reasoning Approach in E-Tourism: Tour Itinerary Planning. Proceedings. 14th International Workshop on Database and Expert Systems Applications (DEXA), 2003. pp. 818-822.

[37] NÚÑEZ-SUÁREZ, J. et al. Experiences in the use of FIPA agent Technologies

for the development of a personal travel application. Proceedings of the fourth international conference on Autonomous agents. Barcelona, Spain. ACM Press, 2000. pp. 357-364.

[38] Nutking. The intelligent travel recommendation.

http://itr.itc.it:8080/dev/jsp/index.jsp (Agosto 14, 2006)

[39] O’DONOVAN, J.; SMYTH, B. Trust in recommender systems. Proceedings of

the 10th international conference on Intelligent user interfaces. San Diego, California, USA 2005. 167-174p.

[40] PANG-FEI, T. A Multi-Agent Based Tourism Kiosk on Internet. Proceedings of

the Thirty-First Annual Hawaii International Conference on System Sciences-Volume 4. IEEE Computer Society, 1998. p. 452.

[41] Priceline. Sistema de información y recomendación turística.

http://www.priceline.com (Agosto 16, 2006)

[42] PÜHRETMAIR, F. et al. Extended Decision Making in Tourism Information

System. Proceedings of the 3rd International Conference on Electronic Commerce and Web Technologies - EC-Web 2002, Aix-en-Provence, 2-6 September, 2002.

[43] RICCI, F.; DEL MISSIER, F. Personalized Product Recommendation through

Interactive Query Management and Case-Based Reasoning. Proceedings of CHI'03 Workshop on Designing Personalized User Experiences for eCommerce, Fort Lauderdale, USA, 2003.

[44] RICCI, F.; DEL MISSIER, F. Supporting Travel Decision Making through

Personalized Recommendation. Designing Personalized User Experiences for eCommerce. Kluwer Academic Publisher, 2004. pp. 221-251.

[45] RICCI, F. et al. Case-Based Travel Recommendations. Travel Destination

Recommendation Systems: Behavioral Foundations and Applications. CAB Publishing, 2006.

[46] RICCI, F. et al. Detailed Descriptions of CBR Methodologies.

http://dietorecs.itc.it/PubDeliverables/D4.1-V1.pdf (Agosto 3, 2006)

[47] RICCI, F. et al. ITR: a case-based travel advisory system. Proceeding of ECCBR, 6th European Conference on Case Based Reasoning, Aberdeen, Scotland, 2002.

171

[48] RICCI, F. et al. Product Recommendation with Interactive Query Management and Twofold Similarity. Proceedings of ICCBR 2003, the 5th Internatinal Conference on Case-Based Reasoning, Trondheim, Norway, 2003.

[49] RICHINS, H.; PHILIP, P. Influences on Tourism Development Decision Making:

Coastal Local Government Areas in Eastern Australia. Journal of sustainable tourism. Vol. 8, N° 3, 2000. pp. 207–231.

[50] RUSSELL, N. y NORVIG, P. Inteligencia artificial: Un enfoque moderno.

Prentice Hall, México, 1996.

[51] STABB, S. et al. Intelligent system for tourism. Intelligent Systems, IEEE Vol. 17, Issue 6, 2002. pp. 53 – 66.

[52] STAHL, A. Combining Case-Based and Similarity-Based Product

Recommendation. Proceedings of the 8th European Conference on Case-Based Reasoning (ECCBR 2006).

[53] Travelocity. Sistema de información y recomendación turística.

http://travelocity.com/ (Agosto 16, 2006).

[54] WATSON, I. Applying case-based reasoning: techniques for enterprise systems.

United States of America: Morgan Kaufmann Publishers, 1997. p. 289. [55] WATSON, I. et al. A Comparison of Case-Based Reasoning Approches to Web

Hypermedia Project Cost Estimation. The eleventh international World wide web conference, 2002.

[56] WILSON, R.; MARTINEZ T.R. Improved Heterogenous Distance Functions.

Journal of Artificial Intelligente Research, 1997. pp. 1-34.

[57] WOOLDRIDGE, M. An Introduction to multiagent systems. John Wiley and Sons, England, 2002.

[58] ZIEGLER, C. N. Towards decentralized recommender systems. Dissertation zur

erlangung des doktorgrades (Juni 2005). Albert-Ludwigs-Universität Freiburg. Fakultät für Angewandte Wissenschaften, Institut für Informatik

[59] ZINS, A. H. et al. Prototype testing for a destination recommender system: steps,

procedures and implications. The International Federation for IT and Travel & Tourism’s (IFITT) ENTER 2004 Conference, Cairo, Egypt, January 2004.

sistema de recomendaciÓn turÍstica basado en rbr y cbr

Documents