gestor de diálogos

Ravenclaw (un DM para diálogos orientados a objetivos, basado en el comunicador de CMU) permite al autor una descripción avanzada de la estructura del diálogo de varios niveles, como por ejemplo:

• Tarea de reserva de habitación:
  • Acceso
    • Solicitar nombre de usuario
    • Solicitar contraseña al usuario
  • Selección de habitaciones
    • Selección de edificios
    • Selección del número de habitación
  • Selección de hora
  • Finalizar

El director de juego de Ravenclaw guarda una pila de módulos de diálogo y la utiliza para procesar la entrada humana.

Esta estructura fomenta la reutilización del código ; por ejemplo, el módulo de inicio de sesión se puede utilizar en otros cuadros de diálogo.

También afirman permitir la construcción dinámica de diálogos y tareas, donde la estructura no está predefinida, sino que se construye sobre la marcha, basándose en información seleccionada de un servidor. Por ejemplo, en un sistema que ayuda al personal de mantenimiento de aeronaves durante la ejecución de las tareas de mantenimiento, la estructura del diálogo depende de la estructura de la tarea de mantenimiento y se construye dinámicamente.

Los frameworks para chatbots, como ChatScript, permiten controlar la estructura de la conversación con temas . El autor puede crear reglas que capturen el tema que

• Tema: INFANCIA (niño, niña, joven)
• t: Tuve una infancia feliz.
• t: Pero terminó demasiado pronto.
• ...

Si el usuario pronuncia una de las palabras entre paréntesis, el DM recuerda que el tema es "INFANCIA". El chatbot comienza a narrar la historia bajo el título "INFANCIA", siempre y cuando el bot controle la conversación (el usuario responde pasivamente con expresiones como "OK" o "correcto"). Sin embargo, si el usuario formula preguntas, el sistema puede responder directamente o usar una línea de la historia que ya tenía prevista.

Esto también permite a los autores reutilizar temas y combinar varios temas independientes para crear un chatbot más inteligente.

Un uso común de los sistemas de diálogo es como sustituto de los formularios. Por ejemplo, un agente de reservas de vuelos debería preguntar al usuario sobre su hora y lugar de origen, y hora y lugar de destino, como si estuviera rellenando un formulario con esos cuatro campos.

Una solución sencilla es utilizar la iniciativa del sistema , donde el sistema de diálogo pregunta al usuario sobre cada dato por turno, y el usuario debe completarlos en ese orden exacto, como en este diálogo (de una presentación de David Traum ):

• Bienvenido al sistema de confirmación de vuelos. ¿Cuál es su número de vuelo?
  • United 123 el 8 de agosto desde Los Ángeles
• ¿Cuál es su ciudad de salida?
  • Te lo dije, Los Ángeles, el 8 de agosto.
• Lo siento, no entendí. ¿Cuál es su ciudad de salida?
  • Salida de Los Ángeles el 8 de agosto.
• ¿Cuál es el día de salida?
  • ¡No escuchas! ¡8 de agosto!
• ¿Podría indicarme el día de salida?
  • 8 de agosto
• Se ha confirmado que el vuelo United 123 partirá de Los Ángeles con destino a Londres a las 14:00 horas del 8 de agosto.

Lo opuesto a la iniciativa del sistema es la iniciativa del usuario , donde el usuario toma la iniciativa y el sistema responde a lo que el usuario le indique.

Una solución intermedia común entre ambos métodos es la iniciativa mixta , donde el sistema comienza formulando preguntas, pero los usuarios pueden intervenir y cambiar el rumbo del diálogo. El sistema comprende al usuario incluso cuando habla de detalles sobre los que aún no se le ha preguntado.

Sin embargo, describir un sistema de este tipo manualmente, como un diagrama de estados, resulta muy tedioso, ya que el ser humano puede mencionar primero el origen y luego el destino, o viceversa. En cada caso, también puede mencionar primero la hora y luego el lugar, o viceversa.

Por lo tanto, existen herramientas de gestión de diálogos que permiten al autor del diálogo simplemente indicar qué información se requiere, sin especificar el orden exacto. Por ejemplo, el autor puede escribir:

• VIAJE = {LUGAR-DE-ORIGEN, HORA-DE-ORIGEN, LUGAR-DE-DESTINO, HORA-DE-DESTINO}

El director de juego lleva un registro de qué espacios están ocupados y cuáles están vacíos, y gestiona la conversación para obtener la información faltante. Por ejemplo, puede preguntar primero al jugador sobre el lugar de origen, pero si este añade el destino, el director de juego conservará esa información y no volverá a preguntar al respecto.

Dichos sistemas de información se desarrollaron en el MIT , por ejemplo, Wheels (para buscar anuncios de coches usados), Jupiter (para obtener pronósticos meteorológicos) y otros.

Los DM simples manejan el llenado de ranuras de forma binaria: una ranura está "llena" o está "vacía". Los DM más avanzados también registran el grado de fundamentación : qué tan seguros estamos de que realmente entendimos lo que dijo el usuario: si fue "Introducido recientemente", "Introducido de nuevo", "reconocido", "repetido", etc. También podemos permitir que el autor especifique, para cada pieza de información, el grado en que NECESITAMOS que se entienda, por ejemplo, la información sensible requiere un grado más alto. El DM usa esta información para controlar el curso del diálogo, por ejemplo, si la persona dijo algo sobre un tema sensible y no estamos seguros de haberlo entendido, entonces el DM hará una pregunta de confirmación. Ver Roque y Traum (2008) .

TrindiKit ( archivado el 23/02/2012 en Wayback Machine DS), desarrollado durante el proyecto Trindi ( archivado el 11/05/2012 en Wayback Machine) , permite a los autores definir un estado de información complejo y escribir reglas generales que procesen dicho estado. He aquí un ejemplo de regla:

integrarRespuesta: Precondiciones: ("Si el humano dio una respuesta relevante a una pregunta que se está debatiendo actualmente...") en(SHARED.LM, respuesta (usr, A)) fst(COMPARTIDO.QUD, Q) respuesta_relevante(P, R) efectos: ("... luego retírelo de la Pregunta en Discusión y agréguelo al terreno compartido") pop(COMPARTIDO.QUD) reducir(Q, A, P) agregar(COMPARTIDO, P) 

El responsable de la toma de decisiones decide, en función de la información de entrada y del estado actual, qué reglas son aplicables y las aplica para obtener el nuevo estado.

Esto puede ayudar a los autores a reutilizar reglas generales para la gestión de diálogos, basadas en teorías del diálogo. Los sistemas de diálogo desarrollados con TrindiKit incluyen: GoDiS, MIDAS, EDIS y SRI Autorate.

El enfoque del estado de la información se desarrolló más tarde en proyectos como Siridus (archivado el 23 de marzo de 2012 en la Wayback Machine) y el conjunto de herramientas Dipper .

Otro ejemplo de gestor de diálogos basado en el estado de la información es FLoReS . Este utiliza un estado de información proposicional para codificar el estado actual y selecciona la siguiente acción mediante un proceso de decisión de Markov . Este gestor de diálogos está implementado en el software jmNL .

Una generalización de este enfoque consiste en dejar que el autor defina los objetivos del agente y que el DM elabore un plan para alcanzarlos. El plan se compone de operaciones. Cada acto de habla es una operación. Cada operación tiene precondiciones y postcondiciones (efectos), por ejemplo:

Informar(Hablante,Oyente,Predicado): Precondición: Sabe(Hablante, Predicado) Y Quiere(Hablante, Informar(Hablante, Oyente, Predicado)) Efecto: Sabe(Oyente, Predicado) Cuerpo: Cree(Oyente,Quiere(Hablante,Sabe(Oyente,Predicado))) 

La conversación puede gestionarse mediante un planificador general, como SOAR (Fortalezas, Oportunidades, Aspiraciones y Resultados). El planificador mantiene el estado actual e intenta elaborar un plan para alcanzar el objetivo, utilizando las operaciones disponibles.

^{En SASO-ST [ 1 ]} (un sistema de decisión para el entrenamiento en negociación multiagente) se adopta un enfoque similar . El uso de SOAR permite incorporar modelos emocionales y sociales complejos; por ejemplo, el agente puede decidir, basándose en las acciones humanas, si cooperar con la persona, evitarla o incluso atacarla.

^{En TRIPS [ 2 ]} (un DS para la resolución colaborativa de problemas entre múltiples agentes) se adopta un enfoque similar . Dividen la gestión del diálogo en varios módulos:

• Gestor de referencias : dada una palabra (por ejemplo, "la mujer"), decide a qué objeto del mundo se refiere (por ejemplo, "WOM1234").
• Gestor de tareas : identifica las acciones de resolución de problemas que el usuario intenta realizar (crear un nuevo objetivo, ampliar un objetivo existente, etc.).
• Gestor de interpretación : además de llamar a los dos primeros, identifique también las obligaciones discursivas, por ejemplo: "responder a la última pregunta".
• Agente de comportamiento : decide cómo lograr el objetivo que el usuario desea. El agente emplea varios agentes específicos para cada tarea que realizan la planificación propiamente dicha.

Otro tipo de planificación es la demostración de teoremas . Un diálogo puede describirse como un intento de demostrar un teorema. El sistema interactúa con el usuario para proporcionar los "axiomas faltantes" que ayudan a completar la demostración (esto se denomina " encadenamiento hacia atrás "). Este enfoque fue implementado por:

• Marco gramatical. ^{[ 3 ]}
• IPSIM (Simulador de Prolog Interrumpible), en el sistema Circuit Fixit. ^{[ 4 ]}

El gestor de diálogos puede conectarse con un sistema experto para ofrecer la capacidad de responder con conocimientos especializados.

Los módulos ASR y NLU generalmente no están 100% seguros de haber comprendido al usuario; normalmente devuelven una puntuación de confianza que refleja la calidad de la comprensión. En tales casos, el DM debe decidir si:

• Simplemente suponga que la interpretación más probable es correcta y continúe la conversación ( sin confirmación );
• Continúa la conversación, pero agrega algunas palabras que demuestren comprensión, como "De acuerdo, quieres ir a un restaurante. ¿Dónde exactamente?" ( confirmación implícita ).
• Pregúntale al usuario qué quiso decir exactamente ( confirmación explícita ): "¿Te refieres a X?" "¿Dijiste X o Y?", etc.
• Dile al usuario: "No lo entendí, por favor, repítelo".

Elegir la opción "sin confirmación" puede agilizar el diálogo, pero también puede dar lugar a errores que tardarán más en corregirse posteriormente.

Ravenclaw investigó exhaustivamente el manejo de errores , lo que permite al autor controlar manualmente la estrategia de manejo de errores en cada parte del diálogo.

Algunos sistemas de gestión de datos (SD) tienen varios modos de funcionamiento: el modo predeterminado es la iniciativa del usuario , donde el sistema simplemente pregunta "¿en qué puedo ayudarte?" y deja que el usuario guíe la conversación. Esto es útil para usuarios experimentados. Sin embargo, si hay muchos malentendidos entre el usuario y el sistema, el gestor de casos puede optar por cambiar a la iniciativa mixta o a la iniciativa del sistema : formular preguntas explícitas al usuario y aceptar una respuesta a la vez.

Las decisiones tácticas de otro tipo las toma Cordillera (un tutorial de DS para la enseñanza de la física, creado con TuTalk). En muchos momentos de la lección, el DM debe decidir:

• Si conviene contarle algún dato al alumno o intentar obtenerlo de él mediante preguntas orientadoras.
• Si pedirle al alumno que justifique su respuesta o simplemente omitir la justificación y continuar.

Estas decisiones afectan a la calidad general del aprendizaje, que puede medirse comparando los exámenes previos y posteriores al aprendizaje.

En lugar de dejar que un experto humano escriba un conjunto complejo de reglas de decisión, es más común usar el aprendizaje por refuerzo . El diálogo se representa como un Proceso de Decisión de Markov (PDM), un proceso donde, en cada estado, el responsable de la toma de decisiones debe seleccionar una acción, basándose en el estado y las posibles recompensas de cada acción. En este contexto, el autor del diálogo solo debe definir la función de recompensa; por ejemplo: en los diálogos tutoriales, la recompensa es el aumento en la calificación del estudiante; en los diálogos de búsqueda de información, la recompensa es positiva si el usuario recibe la información, pero también hay una recompensa negativa por cada paso del diálogo.

Posteriormente, se utilizan técnicas de aprendizaje por refuerzo para desarrollar una política; por ejemplo, ¿qué tipo de confirmación debemos usar en cada estado? Esta política es utilizada más adelante por el responsable de la toma de decisiones en diálogos reales.

Lemon y Rieser (2009) escribieron un tutorial sobre este tema .

Otra forma de aprender políticas de diálogo es intentar imitar a los humanos, utilizando experimentos del Mago de Oz, en los que un humano se sienta en una habitación oculta y le dice a la computadora lo que debe decir; véase, por ejemplo, Passonneau et al (2011) .