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. Por lo general:
- La entrada al DM es el enunciado humano, generalmente convertido a alguna representación semántica específica del sistema mediante el componente de comprensión del lenguaje natural (NLU). Por ejemplo, en un sistema de diálogo de planificación de vuelo, la entrada puede verse como "ORDER (from = TA, to = JER, date = 2012-01-01)".
- El DM generalmente mantiene algunas variables de estado , como el historial de diálogo, la última pregunta sin respuesta, etc., dependiendo del sistema.
- La salida del DM es una lista de instrucciones para otras partes del sistema de diálogo, generalmente en una representación semántica, por ejemplo "TELL (flight-num = 123, flight-time = 12:34)". Esta representación semántica generalmente se convierte a lenguaje humano mediante el componente Generación de lenguaje natural (NLG).
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 solo funciones sin estado. Los roles de DM se pueden dividir aproximadamente en estos grupos:
- DM de control de entrada, que permiten el procesamiento dependiente del contexto de las expresiones humanas.
- DM de control de salida. que permiten la generación de texto dependiente del estado.
- Control de flujo estratégico
- Control de flujo táctico
DM de control de entrada
La aportación humana tiene diferentes significados según el contexto. Por ejemplo, en un DS de planificación de viajes:
- Computadora: ¿De dónde quieres partir?
- Humano: Tel Aviv.
- Computadora: ¿A dónde quieres llegar?
- Humano: Gaza.
El significado del nombre de la ciudad depende de la pregunta anterior. 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 el módulo de resolución NP de Mirkovic y Cavedon (2005) .
Otra función entre el NLU y el DM es determinar qué enunciados de entrada forman parte de un solo enunciado. A continuación, se muestra un ejemplo de un cuadro de diálogo de negociación de trabajo:
- Ofrezco un salario de 20.000 NIS
- y un carro
- Las condiciones de la pensión se decidirán más adelante.
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 enunciado.
DM de control de salida
La salida de la computadora se puede hacer más natural recordando el historial del diálogo. Por ejemplo, NPCEditor (un marco para la creación de personajes que responden a preguntas humanas) permite al autor definir pares de preguntas y respuestas, de modo que para cada pregunta hay varias respuestas posibles. El DM selecciona la mejor respuesta para la pregunta, a menos que ya se haya utilizado, en cuyo caso selecciona la segunda mejor respuesta, etc.
Existe una característica similar en ChatScript (un marco para la creación de chatter-bots): cada vez que DS usa una cierta regla, el DM marca esta regla como "usada", para que no se vuelva a usar.
Un DS reciente para asistencia técnica [ cita requerida ] utiliza reglas avanzadas de aprendizaje automático para seleccionar los mejores términos para describir elementos. Por ejemplo, si el DM nota que está hablando con un adulto, usará términos como "la mano izquierda"; si se da cuenta de 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.
DM de control de flujo estratégico
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í:
- Computadora: "¿Qué fuerzas actúan sobre el electrón?"
- Humano: "Fuerza eléctrica".
- Computadora: "Correcto"
- [ir a la siguiente pregunta]
- Humano: "Fuerza eléctrica".
- Computadora: "¿Qué fuerzas actúan sobre la masa?"
- Humano: "Fuerza eléctrica".
- Computadora: "Incorrecto, la masa no tiene carga".
- [ir a un tutorial sobre electricidad]
- Humano: "Fuerza eléctrica".
El DM mantiene un puntero a nuestra posición actual en el script. La posición se actualiza de acuerdo con la entrada humana.
Hay muchos lenguajes y marcos que permiten a los autores especificar estructuras de diálogo, tales como: VoiceXML (optimizado para diálogos de voz), AIML, Facade y ChatScript (optimizado para chat-bots), 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 estado, utilizando un lenguaje estándar como SCXML . Esto se hace en DomainEditor (un marco para personajes de interrogatorios tácticos ).
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.
Estructura jerarquica
Ravenclaw (un DM para diálogos orientados a objetivos, basado en el comunicador CMU) permite al autor una descripción avanzada de la estructura de diálogo de varios niveles, como por ejemplo:
- Tarea de reserva de habitación:
- Acceso
- Preguntar nombre de usuario
- Preguntar contraseña de usuario
- Selección de habitación
- Selección de edificio
- Selección de número de habitación
- Selección de tiempo
- Terminar
- Acceso
El DM de Ravenclaw mantiene una pila de módulos de diálogo y los usa 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 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.
Seguimiento de temas
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
- tema: INFANCIA (niño niño niña joven)
- t: Tuve una infancia feliz.
- t: Pero terminó demasiado pronto.
- ...
Si el humano dice una de las palabras entre paréntesis, el DM recuerda que el tema es "INFANCIA". El chat-bot ahora comienza a contar la historia bajo el título "INFANCIA", siempre que el bot tenga el control de la conversación (el usuario responde pasivamente diciendo que piensa 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 chat-bot más inteligente.
El rellenado de formularios
Un uso común de los sistemas de diálogo es como reemplazo de formularios. Por ejemplo, un agente de reserva de vuelos debería preguntarle al humano sobre su hora y lugar de origen, y la 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 información 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. Cual es tu numero de vuelo?
- United 123 el 8 de agosto desde Los Ángeles
- ¿Cuál es tu ciudad de salida?
- Te lo dije, Los Ángeles, el 8 de agosto
- Lo siento, no entendí. ¿Cuál es tu ciudad de salida?
- Los Ángeles partirá el 8 de agosto.
- Cual es el dia de salida?
- ¡No escuchas! ¡8 de agosto!
- Por favor, diga el día de salida.
- 8 de agosto
- Se confirmó que el vuelo United 123 partirá de Los Ángeles hacia Londres a las 2 pm 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.
Un compromiso común entre los dos métodos es la iniciativa mixta , donde el sistema comienza con hacer preguntas, pero los usuarios pueden irrumpir y cambiar la dirección del diálogo. El sistema comprende al usuario incluso cuando habla de detalles sobre los que aún no se le preguntó.
Sin embargo, describir tal sistema manualmente, como un diagrama de estado, 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 humano puede decir primero la hora y luego el lugar, o viceversa.
Por lo tanto, hay DM 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:
- VIAJE = {ORIGIN-PLACE, ORIGIN-TIME, DESTINATION-PLACE, DESTINATION-TIME}
El DM realiza un seguimiento de los espacios que ya están llenos 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 mantendrá la información y no volverá a preguntar sobre ella.
Dichos DS 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 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 "Recientemente introducido", "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 comprenda, 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) .
Estado de la información
El TrindiKit DS, desarrollado durante el Trindi proyecto, permite a los autores definen un estado de información compleja, y escriben las reglas generales que procesan este estado. Aquí hay una regla de muestra:
integrarAnswer: condiciones previas: ("Si el ser humano dio una respuesta relevante a una pregunta actualmente en discusión ...") en (SHARED.LM, respuesta (usr, A)) fst (COMPARTIDO.QUD, Q) relevante_answer (Q, A) efectos: ("... luego elimínelo de la pregunta en discusión y agréguelo al terreno compartido") pop (COMPARTIDO.QUD) reducir (Q, A, P) añadir (SHARED.COM, P)
El DM decide, de acuerdo con 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 las reglas generales para las reglas de administración de diálogo, basadas en teorías de 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 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 .
Planificación general
Una generalización de este enfoque es dejar que el autor defina las metas del agente y dejar que el DM construya un plan para lograr esa meta. 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, informar (hablante, oyente, predicado)) Efecto: sabe (oyente, predicado) Cuerpo: Cree (Oyente, Quiere (Habla, 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 entrenamiento de negociación de múltiples agentes). El uso de SOAR permite la incorporación de modelos emocionales y sociales complejos, por ejemplo: el agente puede decidir, en base a las acciones humanas, si quiere cooperar con él, evitarlo o incluso atacarlo.
Un enfoque similar se adopta en TRIPS [2] (un DS para la resolución colaborativa de problemas con múltiples agentes). Dividieron la gestión del diálogo en varios módulos:
- Administrador de referencias : dada una palabra (por ejemplo, "la mujer"), decida a qué objeto del mundo se refiere (por ejemplo, "WOM1234").
- Administrador de tareas : identifica los actos de resolución de problemas que el usuario intenta lograr (crear un nuevo objetivo, ampliar un objetivo existente, etc.).
- Gestor de interpretación : además de llamar a los dos primeros, también identifica las obligaciones del discurso, por ejemplo: "responder a la última pregunta".
- Agente de comportamiento : decide cómo lograr el objetivo que desea el usuario. El agente emplea varios agentes de tareas específicas que realizan la planificación real.
Un tipo diferente de planificación está demostrando teoremas . Un diálogo se puede describir como un intento de demostrar un teorema. El sistema interactúa con el usuario para proporcionar "axiomas faltantes" para ayudar a completar la demostración (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.
DM de control de flujo táctico
Además de seguir la estructura general y los objetivos del diálogo, algunos DM también toman algunas decisiones tácticas de conversación, decisiones locales que afectan la calidad de la conversación.
Manejo de errores
Los módulos ASR y NLU generalmente no están 100% seguros de haber entendido al usuario; por lo general, devuelven una puntuación de confianza que refleja la calidad de la comprensión. En tales casos, el DM debe decidir si:
- Simplemente asuma que la interpretación más probable es correcta y continúe la conversación ( sin confirmación );
- Continúe la conversación, pero agregue algunas palabras que demuestren comprensión, como "Está bien, quiere ir a un restaurante. ¿Dónde exactamente?" ( confirmación implícita ).
- Pregunte al usuario qué pretendía decir exactamente ( confirmación explícita ): "¿Te refieres a X?" "¿Dijiste X o Y?", Etc.
- Dígale al usuario "No entendí, repita esto".
Si elige "sin confirmación", es posible que el cuadro de diálogo continúe más rápido, pero también puede introducir errores que tardarán más en corregir más tarde.
El manejo de errores fue investigado extensamente por Ravenclaw , lo que permite al autor controlar manualmente la estrategia de manejo de errores en cada parte del diálogo.
Control de iniciativa
Algunos DS tienen varios modos de funcionamiento: el modo predeterminado es la iniciativa del usuario , donde el sistema simplemente pregunta "¿qué puedo hacer por usted?" y permite que el usuario navegue 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 : haga preguntas explícitas al usuario y acepte una respuesta a la vez.
Decisiones pedagógicas
Cordillera toma decisiones tácticas de otro tipo (un DS tutorial para la enseñanza de la física, construido con TuTalk). En muchos puntos durante la lección, el DM debe decidir:
- Ya sea para decirle al alumno algún hecho o tratar de obtener este hecho de él haciéndole preguntas de orientación.
- Ya sea para pedirle al alumno que Justifique su respuesta o simplemente Omita la justificación y continúe.
Estas decisiones afectan la calidad general del aprendizaje, que se puede medir comparando exámenes previos y posteriores al aprendizaje.
Tácticas aprendidas
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 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 ser humano recibe la información, pero también hay una recompensa negativa por cada paso del diálogo.
Luego, las técnicas de RL se utilizan para aprender una política, por ejemplo, ¿qué tipo de confirmación deberíamos 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 las 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 tiene que decir; véase, por ejemplo, Passonneau et al (2011) .
Referencias
Otras lecturas
- Traum, 2008: Enfoques de los sistemas de diálogo y la gestión del diálogo - Notas de conferencia y bibliografía .
- Allen et al., 2001: Hacia la interacción conversacional persona-computadora . Revisión de DM por complejidad: estados finitos, basados en marcos, conjuntos de contextos, basados en planes, basados en agentes. Descripción del sistema TRIPS basado en agentes.
- Más artículos de investigación sobre gestión de diálogos