Un gestor de diálogo (DM) es un componente de un sistema de diálogo (DS), responsable del estado y el flujo de la conversación. Normalmente:
Existen muchos DM diferentes que cumplen funciones muy diferentes. Incluso puede haber varios componentes de DM en un solo DS.
Lo único que tienen en común todos los DM es que son funciones con estado , a diferencia de otras partes del DS (como los componentes NLU y NLG), que son simplemente funciones sin estado. Las funciones de los DM se pueden dividir aproximadamente en estos grupos:
La información aportada por el usuario tiene distintos significados según el contexto. Por ejemplo, en un DS de planificación de viajes:
El significado del nombre de la ciudad depende de la pregunta formulada anteriormente. Un DM puede guardar esa pregunta en una variable de estado y usarla para convertir "Tel Aviv" en "Quiero salir de Tel Aviv" y convertir "Gaza" en "Quiero llegar a Gaza".
Esta función está en el límite entre NLU y DM: en algunos sistemas está incluida en la NLU, como las reglas dependientes del contexto de Milward (2000); mientras que en otros sistemas está incluida en el DM, como el módulo de resolución NP de Mirkovic y Cavedon (2005).
Otra función entre la NLU y la DM es determinar qué enunciados de entrada forman parte de un único enunciado. A continuación, se muestra un ejemplo de un diálogo de negociación de trabajo:
Las tres expresiones son en realidad una única oferta. En el caso de la segunda expresión, la palabra "y" es una pista, pero en el caso de la tercera, la única pista posible es que se dijo inmediatamente después de la segunda. Para entender esto, el DM probablemente debería mantener una marca de tiempo de cada expresión.
La salida de la computadora puede hacerse más natural si se recuerda el historial de diálogos. Por ejemplo, NPCEditor (un marco para crear personajes que responden preguntas humanas) permite al autor definir pares de preguntas y respuestas, de modo que para cada pregunta haya varias respuestas posibles. El DM selecciona la mejor respuesta para la pregunta, a menos que ya se haya usado, en cuyo caso selecciona la segunda mejor respuesta, etc.
Existe una característica similar en ChatScript (un marco para crear chatbots): cada vez que el DS usa una determinada regla, el DM marca esa regla como "usada" para que no vuelva a usarse.
Un DS reciente para asistencia técnica [ cita requerida ] utiliza reglas avanzadas aprendidas por máquina para seleccionar los mejores términos para describir elementos. Por ejemplo, si el DM nota que está hablando con un adulto, utilizará términos como "la mano izquierda"; si nota que está hablando con un niño, utilizará términos menos técnicos como "la mano donde se lleva el reloj".
Esta función está en el límite entre DM y NLG.
El papel principal de un DM es decidir qué acción debe realizar el agente de diálogo en cada punto del diálogo.
Una forma sencilla de hacerlo es dejar que el autor especifique por completo la estructura del diálogo. Por ejemplo, una especificación de la estructura del diálogo de un tutorial podría ser así:
El DM mantiene un puntero a nuestra posición actual en el script. La posición se actualiza según la entrada humana.
Hay muchos lenguajes y marcos que permiten a los autores especificar estructuras de diálogo, como: VoiceXML (optimizado para diálogos de voz), AIML, Facade y ChatScript (optimizado para chatbots), CDM (basado en Java, optimizado para diálogos de control de dispositivos) y TuTalk (optimizado para diálogos de tutoriales).
Además, la estructura del diálogo se puede describir como un diagrama de estados, utilizando un lenguaje estándar como SCXML . Esto se hace en DomainEditor (un marco para interrogar tácticamente a los personajes).
Es bastante tedioso para los autores escribir una estructura de diálogo completa. Hay muchas mejoras que permiten a los autores describir un diálogo con un nivel de abstracción más alto, al tiempo que suponen una mayor carga para el DM.
Ravenclaw (un DM para diálogos orientados a objetivos, basado en el comunicador CMU) permite al autor una descripción avanzada de la estructura del diálogo de múltiples niveles, como:
El DM de Ravenclaw mantiene una pila de módulos de diálogo y la utiliza para procesar la entrada humana.
Esta estructura fomenta la reutilización de código, por ejemplo, el módulo de inicio de sesión se puede utilizar en otros cuadros de diálogo.
También afirman que permiten la construcción dinámica de tareas de diálogo, donde la estructura no está fijada de antemano, sino que se construye sobre la marcha, en función de la información seleccionada desde un backend. Por ejemplo, en un sistema que ayuda al personal de mantenimiento de aeronaves durante la ejecución de tareas de mantenimiento, la estructura del diálogo depende de la estructura de la tarea de mantenimiento y se construye de forma dinámica.
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 se está discutiendo.
Si el humano dice una de las palabras entre paréntesis, el DM recuerda que el tema es "INFANCIA". El chatbot comienza a contar la historia bajo el título "INFANCIA", siempre y cuando el bot controle la conversación (el usuario responde pasivamente diciendo cosas como "OK" o "correcto"). Sin embargo, si el usuario hace preguntas, el sistema puede responder directamente o utilizar una línea de la historia que iba a decir de todos modos.
Esto también permite a los autores reutilizar temas y combinar varios temas independientes para crear un bot de chat más inteligente.
Un uso común de los sistemas de diálogo es como reemplazo de formularios. Por ejemplo, un agente de reservas de vuelos debería preguntarle al humano sobre su hora y lugar de origen y hora y lugar de destino, tal como si el humano estuviera llenando un formulario con estos 4 espacios.
Una solución sencilla es utilizar system-initiative , donde el sistema de diálogo pregunta al usuario sobre cada pieza de información por turno, y el usuario debe completarlas en ese orden exacto, como en este diálogo (de una presentación de David Traum):
Lo opuesto a la iniciativa del sistema es la iniciativa del usuario , donde el usuario toma el liderazgo y el sistema responde a lo que el usuario ordena.
Un compromiso común entre los dos métodos es la iniciativa mixta , en la que el sistema comienza formulando preguntas, pero los usuarios pueden intervenir y cambiar la dirección del diálogo. El sistema entiende al usuario incluso cuando habla sobre detalles que aún no se le han preguntado.
Sin embargo, describir un sistema de este tipo de forma manual, como un diagrama de estados, es muy tedioso, ya que el ser humano puede decir primero el origen y luego el destino, o viceversa. En cada uno de ellos, el ser humano puede decir primero la hora y luego el lugar, o viceversa.
Por lo tanto, existen mensajes directos 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:
El DM lleva un registro de los espacios que ya están ocupados y los que aún están vacíos, y navega por la conversación para recopilar la información que falta. Por ejemplo, el DM puede preguntarle al humano sobre el lugar de origen primero, pero si el humano agrega el lugar de destino, el DM conservará la información y no volverá a preguntar sobre ella.
Este tipo de DSs se desarrollaron en el MIT , por ejemplo, Wheels (para buscar anuncios de autos usados), Jupiter (para recuperar pronósticos del tiempo) y más.
Los DM simples manejan el llenado de espacios de forma binaria: o un espacio está "lleno" o está "vacío". Los DM más avanzados también llevan un registro del grado de fundamento : cuán seguros estamos de que realmente entendimos lo que dijo el usuario: si fue "Recientemente presentado", "Introducido nuevamente", "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 necesita un grado más alto. El DM usa esta información para controlar el curso del diálogo, por ejemplo, si el humano dijo algo sobre un tema sensible y no estamos seguros de haberlo entendido, entonces el DM emitirá una pregunta de confirmación. Ver Roque y Traum (2008).
El DS TrindiKit , desarrollado durante el proyecto Trindi , permite a los autores definir un estado de información complejo y escribir reglas generales que procesen este estado. A continuación se muestra una regla de ejemplo:
integrarRespuesta: condiciones previas: ("Si el humano dio una respuesta relevante a una pregunta actualmente en discusión...") en(SHARED.LM, respuesta (usr, A)) fst(COMPARTIDO.QUD, Q) respuesta_relevante(P, A) efectos: ("... luego elimínelo de la Pregunta en Discusión y agréguelo al terreno compartido") pop(COMPARTIDO.QUD) reducir(Q, A, P) agregar(SHARED.COM, P)El DM decide, según la entrada y el estado, qué reglas son aplicables, y las aplica para obtener el nuevo estado.
Esto puede ayudar a los autores a reutilizar reglas generales para las reglas de gestión de diálogos, basadas en teorías de diálogos. Los DS 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 y el kit de herramientas Dipper. Archivado el 23 de marzo de 2012 en Wayback Machine .
Otro ejemplo de un gestor de diálogo basado en el estado de la información es FLoReS. 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álogo 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 construya un plan para alcanzarlos. El plan está formado por operaciones. Cada acto de habla es una operación. Cada operación tiene condiciones previas y posteriores (efectos), por ejemplo:
Informar (Hablante, Oyente, Predicado): Precondición: Sabe(Hablante,Predicado) Y Quiere(Hablante,Informa(Hablante,Oyente,Predicado)) Efecto: Sabe(Oyente, Predicado) Cuerpo: Cree(Oyente,Quiere(Hablante,Sabe(Oyente,Predicado)))La conversación se puede llevar a cabo utilizando un planificador general, como SOAR (Strengths, Opportunities, Aspirations & Results). El planificador mantiene el estado actual e intenta elaborar un plan para alcanzar el objetivo utilizando las operaciones dadas.
Un enfoque similar se adopta en SASO-ST [1] (un DS para el entrenamiento de negociación entre múltiples agentes). El uso de SOAR permite la incorporación de modelos emocionales y sociales complejos, por ejemplo: el agente puede decidir, en función de las acciones humanas, si quiere cooperar con él, evitarlo o incluso atacarlo.
En TRIPS [2] (un DS para la resolución de problemas colaborativos entre múltiples agentes) se adopta un enfoque similar , que divide la gestión del diálogo en varios módulos:
Un tipo diferente 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 "axiomas faltantes" que ayuden a completar la demostración (esto se denomina "encadenamiento hacia atrás"). Este enfoque fue implementado por:
El administrador de diálogo se puede conectar con un sistema experto , para brindar la capacidad de responder con experiencia específica.
Además de seguir la estructura general y los objetivos del diálogo, algunos DM también toman algunas decisiones conversacionales tácticas: decisiones locales que afectan la calidad de la conversación.
Los módulos ASR y NLU no suelen estar 100% seguros de haber entendido al usuario; normalmente devuelven un puntaje de confianza que refleja la calidad de la comprensión. En tales casos, el DM debe decidir si:
Elegir "sin confirmación" puede hacer que el diálogo avance más rápido, pero también puede introducir errores que tomarán más tiempo corregir más adelante.
Ravenclaw investigó ampliamente el manejo de errores, lo que permite al autor controlar manualmente la estrategia de manejo de errores en cada parte del diálogo.
Algunos DS tienen varios modos de funcionamiento: el modo predeterminado es iniciativa del usuario , donde el sistema simplemente pregunta "¿qué puedo hacer por usted?" y permite al usuario navegar por la conversación. Esto es bueno para usuarios experimentados. Sin embargo, si hay muchos malentendidos entre el usuario y el sistema, el DM puede decidir cambiar a iniciativa mixta o iniciativa del sistema : hacer preguntas explícitas al usuario y aceptar una respuesta a la vez.
Las decisiones tácticas de otro tipo las toma Cordillera (un tutorial DS para enseñar física, creado con TuTalk). En muchos puntos de la lección, el DM debe decidir:
Estas decisiones afectan 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 utilizar el aprendizaje por refuerzo . El diálogo se representa como un proceso de decisión de Markov (MDP), un proceso en el que, en cada estado, el DM tiene que seleccionar una acción, en función del 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 de 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 humano recibe la información, pero también hay una recompensa negativa para cada paso del diálogo.
Luego se utilizan técnicas de RL para aprender una política, por ejemplo, ¿qué tipo de confirmación debemos usar en cada estado?, etc. Esta política es utilizada posteriormente por el DM en diálogos reales.
Lemon y Rieser (2009) escribieron un tutorial sobre este tema.
Una forma diferente de aprender políticas de diálogo es tratar de 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 qué decir; véase por ejemplo Passonneau et al (2011).