Un administrador de diálogo (DM) es un componente de un sistema de diálogo (DS), responsable del estado y el flujo de la conversación. Generalmente:
Hay muchos DM diferentes que cumplen roles muy diferentes. Incluso puede haber varios componentes DM en un solo DS.
Lo único común a todos los DM es que tienen estado , a diferencia de otras partes del DS (como los componentes NLU y NLG), que son simplemente funciones sin estado. Los roles de DM se pueden dividir aproximadamente en estos grupos:
La aportación humana tiene diferentes 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 mantener 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 la frontera 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 se incluye en el DM, como es el caso del módulo de resolución NP de Mirkovic y Cavedon (2005).
Otra función entre NLU y DM es determinar qué expresiones de entrada forman parte de una única expresión. A continuación se muestra un ejemplo de un diálogo de negociación laboral:
Las tres expresiones son en realidad una única oferta. Para el segundo enunciado, la palabra "y" es una pista, pero para el tercer enunciado la única pista posible es que se dijo inmediatamente después del segundo. 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 recordando el historial de diálogo. 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 haya sido utilizada, en cuyo caso selecciona la segunda mejor respuesta, etc.
Existe una característica similar en ChatScript (un marco para crear chatter-bots): cada vez que el DS usa una determinada regla, el DM marca esta regla como "usada", para que no se vuelva a usar.
Un DS reciente para asistencia técnica [ cita necesaria ] 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 manecilla donde llevas el reloj".
Esta función está en el límite entre DM y NLG.
La función 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 hacer esto es dejar que el autor especifique completamente la estructura del diálogo. Por ejemplo, una especificación de la estructura de un diálogo de tutorial puede verse así:
El DM mantiene un puntero a nuestra posición actual en el script. La posición se actualiza según la aportación humana.
Existen 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 gráfico de estado, utilizando un lenguaje estándar como SCXML . Esto se hace en DomainEditor (un marco para interrogar personajes tácticamente).
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 en un nivel de abstracción más alto, al tiempo que imponen más carga al 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 varios niveles, como por ejemplo:
Ravenclaw DM mantiene una pila de módulos de diálogo y los 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 que permiten la construcción dinámica de tareas de diálogo, donde la estructura no se fija de antemano sino que se construye sobre la marcha, en función de la información seleccionada de un backend. 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 marcos para chatter-bots, como ChatScript, permiten controlar la estructura de la conversación con temas . El autor puede crear reglas que capturen el tema que
Si el humano dice una de las palabras entre paréntesis, el DM recuerda que el tema es "INFANCIA". El chatbot ahora comienza a contar la historia bajo el título "INFANCIA", siempre y cuando el bot tenga el control de la conversación (el usuario responde pasivamente diciendo "piensa" o "bien"). Sin embargo, si el usuario hace preguntas, el sistema puede responder directamente o utilizar una línea de la historia que iba a contar de todos modos.
Esto también permite a los autores reutilizar temas y combinar varios temas independientes para crear un chatter-bot más inteligente.
Un uso común de los sistemas de diálogo es como reemplazo de los formularios. Por ejemplo, un agente de reservas de vuelos debería preguntarle al humano sobre su hora y lugar de origen, y su hora y lugar de destino, como si el humano estuviera llenando un formulario con estos 4 espacios.
Una solución simple es usar 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):
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.
Un compromiso común entre los dos métodos es la iniciativa mixta , donde el sistema comienza haciendo preguntas, pero los usuarios pueden intervenir y cambiar la dirección del diálogo. El sistema comprende al usuario incluso cuando habla de detalles sobre los que aún no le han preguntado.
Sin embargo, describir un sistema de este tipo manualmente, como un gráfico de estado, es muy tedioso, ya que el humano puede decir primero el origen y luego el destino, o viceversa. En cada uno de ellos, el 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 decir qué información se requiere, sin especificar el orden exacto. Por ejemplo, el autor puede escribir:
El DM realiza un seguimiento de qué espacios ya están ocupados y cuáles 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 primero al humano sobre el lugar de origen, pero si el humano agrega el lugar de destino, el DM conservará la información y no volverá a preguntar sobre ella.
Estos DS se desarrollaron en el MIT , por ejemplo, Wheels (para buscar anuncios de automóviles 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 realizan un seguimiento del grado de conexión a tierra : qué tan seguros estamos de que realmente entendimos lo que dijo el usuario: si fue "Presentado recientemente", "Presentado 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 comprenda; por ejemplo, la información sensible necesita un grado mayor. El DM utiliza esta información para controlar el curso del diálogo, por ejemplo, si el humano dijo algo sobre un tema delicado y no estamos seguros de haberlo entendido, entonces el DM emitirá una pregunta de confirmación. Véase Roque y Traum (2008).
El TrindiKit Archivado el 23 de febrero de 2012 en Wayback Machine DS, desarrollado durante el proyecto Trindi Archivado el 11 de mayo de 2012 en Wayback Machine , permite a los autores definir un estado de información complejo y escribir reglas generales que procesan este estado. Aquí hay una regla de muestra:
integrarRespuesta: condiciones previas: ("Si el humano dio una respuesta relevante a una pregunta actualmente en discusión...") en(COMPARTIDO.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(COMPARTIDO.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 del diálogo, basadas en teorías del diálogo. 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 Archivado el 23 de marzo de 2012 en Wayback Machine y el kit de herramientas Dipper.
Otro ejemplo de un administrador 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 administrador de diálogo está implementado en el software jmNL.
Una generalización de este enfoque es dejar que el autor defina los objetivos del agente y dejar que el DM construya un plan para lograr ese objetivo. El plan está hecho de operaciones. Cada acto de habla es una operación. Cada operación tiene condiciones previas y posteriores (efectos), por ejemplo:
Informar (Hablante, Oyente, Predicado): Condición previa: 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 navegar utilizando un planificador general, como SOAR (Fortalezas, Oportunidades, Aspiraciones y Resultados). El planificador mantiene el estado actual e intenta construir un plan para lograr el objetivo utilizando las operaciones dadas.
Se adopta un enfoque similar en SASO-ST [1] (un DS para capacitación en negociación de múltiples agentes). El uso de SOAR permite incorporar 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.
Se adopta un enfoque similar en TRIPS [2] (un DS para la resolución colaborativa de problemas de múltiples agentes). Dividen 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" para ayudar a completar la prueba (esto se llama "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 generalmente no están 100% seguros de haber entendido al usuario; normalmente arrojan una puntuación 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 llevará más tiempo corregir más adelante.
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 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.
Cordillera (un DS tutorial para la enseñanza de física, creado con TuTalk) toma decisiones tácticas de otro tipo. En muchos puntos durante la lección, el DM debería 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 esta configuración, el autor del diálogo solo debe definir la función de recompensa, por ejemplo: en los diálogos de tutorial, 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 por 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 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 qué decir; véase, por ejemplo, Passonneau et al (2011).