Sistema de información ferroviaria por teléfono: propuesta de una metodología de diseño de diálogo

1. Sistema de información ferroviaria por teléfono: propuesta de una metodología de diseño de diálogo R. San-Segundo, J.M. Montero, J. Ferreiros, J. Macías-Guarasa, J.M. Pardo Grupo de Tecnología del Habla. Universidad Politécnica de Madrid Ciudad Universitaria s/n, 28040 Madrid, Spain SLPLT-2 Septiembre 14-15, Jaén, Spain

2. INTRODUCCIÓN • Sistema de informaciónferroviaria en Español. • Metodología para el diseño de gestores de diálogo: • 1.- Análisis de la Base de Datos. • 2.- Diseño por Intuición (Braimstorming). • 3.- Diseño por Observación. • 4.- Diseño por Simulación. • Mecanismos de Confirmación. • Recuperación de Errores. • Modelado de Usuario. • 5.- Diseño por MejoraIterativa. SLPLT-2 Septiembre 14-15, Jaén, Spain

3. Nombre Teléfono USUARIO Nº Plazas Código RESERVA Clase N Estación Origen Nº Enlaces Nº Tramos VIAJE Estación Destino Nº Cambios Fecha Hora Salida Precios M Hora Llegada Duración ESTÁ COMPUESTO Hora Llegada Estación Origen N Precios: -primera -segunda -club Estación Destino TRAMO Fecha Duración M Hora Salida UTILIZA Plazas Código 1 TREN Velocidad máxima Características Análisis de la BASE DE DATOS Diagrama Entidad-Interrelación • Conjuntos Entidad. • Atributos. • Claves. • Conjuntos Asociación. SLPLT-2 Septiembre 14-15, Jaén, Spain

4. Diseño por INTUICIÓN Objetivo:parte de un servicio como Reservas, Precios, etc.. Definiciones Dato:información que el sistema necesita del usuario para satisfacer un objetivo. ¿Posibles objetivos que puede satisfacer el sistema? ¿Secuencia de objetivos para formar el servicio? ¿Datos necesarios para satisfacer cada objetivo? ¿Formas de especificar un dato por parte del usuario? • Los Conjuntos Entidad y Asociación serán los objetivos posibles. • Las Claves serán los datos necesarios para satisfacer cada objetivo. RESULTADO Tabla con alternativas de diseño que se evaluarán en la siguiente etapa. SLPLT-2 Septiembre 14-15, Jaén, Spain

5. Posición % 1º 2º 3º 4º 5º Horarios 64 57 6 1 - - Horarios Ida y Vuelta 20 - 14 5 1 - Precios 46 6 30 10 - - Reserva 26 14 4 2 3 3 Frecuencia de trenes 2 2 - - - - Itinerario 14 8 4 1 1 - Otros 12 8 2 - 2 - Diseño por OBSERVACIÓN (I) Se analizan conversaciones entre usuarios y operadores (100). Análisis de Objetivos 1. ¿Qué objetivos son los más frecuentes y su secuencia? 2. ¿Qué información ofrece el operador para cubrir un objetivo? SLPLT-2 Septiembre 14-15, Jaén, Spain B) What information does the operator give to satisfy a goal ?

6. Diseño por OBSERVACIÓN (II) Análisis de Datos 1. ¿Datos necesarios para cada objetivo y su secuencia? 2. Clasificar cada Dato como Obligatorio u Opcional Obligatorio:necesario para satisfacer un objetivo. Si el usuario no lo especifica, el sistema debe asignar un valor por defecto o parametrizar la información según este Dato. Opcional: el sistema no lo pregunta. Si el usuario lo especifica se utiliza para personalizar el servicio. 3. Análisis de las diferentes formas de especificar un dato 4. Agrupación de datos • Definición de pasos de diálogo (ritmo del diálogo). • Se pueden incorporar confirmaciones conjuntas y zonas de descanso. SLPLT-2 Septiembre 14-15, Jaén, Spain

7. Criterio % Criterio % 41 3 Hora salida Nº de Enlaces - - 14 3 Enlace Hora llegada 3 Est. De Salida Clase 10 8 Duración 5 Precios 13 Tipo de tren Diseño por OBSERVACIÓN (III) Análisis de la Negociación Negociación: el usuario debe elegir una de las opciones posibles. 1. Información que más ayuda al usuario a decidir 2. Elegir la estrategia de negociación • Presentar una opción al usuario y permitirle navegar. • Presentar varias opciones y hacer que elija una de ellas. SLPLT-2 Septiembre 14-15, Jaén, Spain

8. Diseño por SIMULACIÓN (I) Se evalúan alternativas de diseño (15 usuarios 6 escenarios). Mago de Oz Análisis de Objetivos Medidas para evaluar la secuencia de objetivos y su cobertura Sistema:nº de veces que se solicita un objetivo y el tiempo o nº de interacciones para satisfacerle. Cuestionario:sugerencias de los usuarios sobre ampliaciones del servicio. SLPLT-2 Septiembre 14-15, Jaén, Spain

9. Diseño por SIMULACIÓN (II) Análisis de Datos Medidas para evaluar la inteligibilidad de las preguntas Sistema:nº de veces que el usuario permanece callado ante la pregunta y la tasa de reconocimiento si se dispone de una primera versión del reconocedor. Medidas para evaluar la secuencia de preguntas Sistema:Se proponen varias secuencias (diferentes en cada llamada) y se calcula la Tasa de reconocimiento de cada secuencia obtenida como la multiplicación de las tasas individuales. Evaluar la gestión de datos obligatorios no especificados Cuestionario:se pregunta a los usuarios sobre su preferencia: elegir un valor por defecto (y decidir cuál) o si prefieren la información parametrizada. SLPLT-2 Septiembre 14-15, Jaén, Spain

10. Análisis de la negociación (Cuestionarios) 1 en 1 2 en 2 3 en 3 21,4% 21,4% 57,2% Criterio de Negociación T. Tren Hora Sal. Hora Lleg. Precios Duración 15,6% 37,5% 25,0% 15,6% 6,2% Diseño por SIMULACIÓN (III) Análisis de la Negociación En nuestro caso presentamos varias opciones de viaje a la vez. Evaluación del nº de opciones a presentar y la información para caracterizarlas. Se prueban varias alternativas: tanto para el nº de opciones como para la información presentada por opción. Medidas: Sistema:nº de preguntas y tiempo de negociación. Cuestionario:información que más ayuda a decidir y nº de opciones fácil de recordar. SLPLT-2 Septiembre 14-15, Jaén, Spain

11. 4 3 2 1 Muy baja confianza Muy alta confianza Baja confianza Alta confianza Diseño por Mejora Iterativa (I) Mecanismos de confirmación • Estrategias de confirmación: • Explicita. Pregunta directa (”¿Desea salir de Madrid? "). • Implicita. (”Entiendo que desea salir de Madrid.¿A dónde desea viajar?”). • Semi-implicita.(”Entiendo que desea salir de Madrid, si no es correcto diga corregir si no dígame la ciudad destino”). • No confirmación. El sistema no confirma lo reconocido. • Rechazo y repetición de la pregunta. (”Perdone no le entiendo, Diga su destino"). SLPLT-2 Septiembre 14-15, Jaén, Spain

12. Diseño por Mejora Iterativa (II) Recuperación de errores VOLVER A EMPEZAR (Comenzamos desde el principio) S:”La opción elegida es un intercity.." U: ”volver a empezar" S: ”Volvamos a empezar. ¿Desea ir de Madrid a Barcelona?" U: ”sí" S: ”¿Desea viajar el 19 de julio?" U: "No" S: ”¿Cuándo desea viajar...?" CORREGIR (Corregir el último dato introducido) S: ”¿En qué mes desea viajar?" U: ”Junio, por favor" S: ”¿Qué día de Julio?" U: ”Corregir" S: ”¿En qué mes desea viajar?" U: ”Julio" SLPLT-2 Septiembre 14-15, Jaén, Spain

13. Diseño por Mejora Iterativa (III) Modelado de usuario (I) • Basado en Niveles de destreza: el nivel activo depende del número de confirmaciones correctas/erróneas a lo largo de la interacción. • Según el nivel activo, las preguntas son más detalladas: 1er nivel. Se detalla cómo interactuar, el dato pedido, los valores y cómo especificarlos ("Hable después de escuchar la señal. Diga el período del día en el que desea viajar; por la mañana, por la tarde o por la noche."). 2do nivel. Se incluye el dato requerido, los valores aceptados y la manera de especificarlos ("Diga el período del día en el que desea viajar; por la mañana, por la tarde o por la noche."). 3do nivel. Sólo se incluye el dato requerido ("Diga el período del día."). 4to nivel. El usuario conoce toda la información y podemos relajar la pregunta ("¿Cuándo desea salir?"). SLPLT-2 Septiembre 14-15, Jaén, Spain

14. 1 acierto 2 aciertos N2 1 Error N1 N3 1 Error 1 Error N4 3 aciertos Diseño por Mejora Iterativa (IV) Modelado de usuario (II) (El sistema está en el nivel 3) S: ”¿Diga el periodo del día?" U: ”Al mediodía" S: ”¿Ha dicho por la noche?" U: ”No” (El sistema pasa al nivel 2) S: ”¿Diga el periodo del día: por la mañana, por la tarde o por la noche?" U: ”por la tarde" SLPLT-2 Septiembre 14-15, Jaén, Spain

15. Duración de consulta (seg.) 204 Número de preguntas por consulta 21.2 % consultas con “vuelta” 35.4 % de confirmaciones implícitas 61.3 % consultas con “reserva” 31.5 Nº comando “volver a empezar” 0.08 Nº comando “corregir” 0.43 Duración de negociación (seg.) 58 El sistema entiende lo que digo 3.6 Entiendo lo que dice el sistema 4.5 Obtengo rápido la información 4.0 El sistema es fácil de aprender 3.9 En caso de error, corregir fue fácil 3.1 Orden lógico de preguntas 4.6 En general, es un buen sistema 3.9 Evaluación MEDIDAS: 120 consultas (30 usuarios- 4 escenarios) Sistema Cuestionario SLPLT-2 Septiembre 14-15, Jaén, Spain

16. Conclusiones • Desarrollo de un sistema de información de tren para Español • con buena aceptabilidad (3.9 de 1 a 5) y tiempos de llamada • razonables (204 s). • Propuesta de una Metodología para el diseño de diálogos. • Establecemos una relación entre la base de datos y el diseño de diálogos. • Introducimos el diseño por observación y posibles medidas de evaluación en esta fase. • Presentamos medidas para evaluar las alternativas de diálogo con el Mago de Oz. • Presentamos propuestas para: • Diseño de mecanismos de confirmación. • Recuperación de errores. • Modelado de usuario. SLPLT-2 Septiembre 14-15, Jaén, Spain