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,

Presentación del tema: "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,"— Transcripción de la presentación:

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ón ferroviaria en Español. SLPLT-2 Septiembre 14-15, Jaén, Spain 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. 5.- Diseño por Mejora Iterativa. Mecanismos de Confirmación. Recuperación de Errores. Modelado de Usuario.

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

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

5 Diseño por OBSERVACIÓN (I) SLPLT-2 Septiembre 14-15, Jaén, Spain B) What information does the operator give to satisfy a goal ? 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? Se analizan conversaciones entre usuarios y operadores (100). Horarios Horarios Ida y Vuelta Precios Reserva Frecuencia de trenes Itinerario Otros % Posición 1º2º3º4º5º 5761--64 -1451-20 63010--46 14423326 2----2 8411-14 82-2-12

6 SLPLT-2 Septiembre 14-15, Jaén, Spain 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.

7 SLPLT-2 Septiembre 14-15, Jaén, Spain 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 Hora salida Hora llegada Est. De Salida Precios Tipo de tren -- 41 14 3 8 13 Criterio % Nº de Enlaces 3 3 Enlace Clase Duración 10 5 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.

8 SLPLT-2 Septiembre 14-15, Jaén, Spain Diseño por SIMULACIÓN (I) Se evalúan alternativas de diseño (15 usuarios 6 escenarios). Análisis de Objetivos Mago de Oz 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.

9 SLPLT-2 Septiembre 14-15, Jaén, Spain 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. 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. 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

10 SLPLT-2 Septiembre 14-15, Jaén, Spain Diseño por SIMULACIÓN (III) Análisis de la Negociación Evaluación del nº de opciones a presentar y la información para caracterizarlas. En nuestro caso presentamos varias opciones de viaje a la vez. 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. 1 en 1 Análisis de la negociación (Cuestionarios) 21,4% 2 en 23 en 3 21,4%57,2% Criterio de Negociación T. TrenHora Sal.Hora Lleg.PreciosDuración 15,6%37,5%25,0%15,6%6,2%

11 SLPLT-2 Septiembre 14-15, Jaén, Spain 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"). 4321 Muy alta confianza Alta confianza Muy baja confianza Baja confianza

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

13 SLPLT-2 Septiembre 14-15, Jaén, Spain 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: 1 er 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."). 2 do 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."). 3 do nivel. Sólo se incluye el dato requerido ("Diga el período del día."). 4 to nivel. El usuario conoce toda la información y podemos relajar la pregunta ("¿Cuándo desea salir?").

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

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

16 SLPLT-2 Septiembre 14-15, Jaén, Spain 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.