Respuesta contextual

Siempre que el usuario proporcione toda la informaci´on necesaria en relaci´on a la realiza- ci´on o prestaci´on de un determinado conjunto de acciones o servicios, seremos capaces de completar los marcos de ejecuci´on correspondientes a los objetivos de di´alogo asociados a partir de los conceptos confirmados por la red mediante el procedimiento de Inferencia inversa. Tras este proceso de validaci´on, estos conceptos pueden incorporarse a la histo- ria o memoria de di´alogo como conocimiento consolidado. En el ´ambito de los interfaces de control dom´otico adicionalmente es preciso actualizar la informaci´on de estado de los sistemas seg´un el conjunto de acciones realizadas e informar a los usuarios acerca de la correcta ejecuci´on de las mismas.

Sin embargo, habitualmente este tipo de sistemas deben hacer frente a situaciones m´as complicadas en las que el usuario tiende a omitir cierta informaci´on, en ocasiones, informaci´on que resulta fundamental para el correcto desenlace del di´alogo. Como hemos tenido oportunidad de comprobar, la soluci´on de di´alogo propuesta basada en BNs per- mitir´ıa, a trav´es del proceso de negociaci´on orquestado en base a los procedimientos de Inferencia directa e inversa, obtener dicha informaci´on. No obstante, estas situaciones en las que el usuario proporciona una informaci´on parcial o incompleta, a menudo podr´ıan resolverse r´apidamente deduciendo la informaci´on restante a partir del contexto en el que tiene lugar el di´alogo.

Con esa intenci´on pretendemos incorporar a la gesti´on de di´alogo elementos de infor- maci´on contextual como:

• la historia de di´alogo, como una memoria a largo plazo a modo de registro de la

evoluci´on seguida por el di´alogo que almacene todos aquellos conceptos confirmados mediante inferencia inversa fruto de las diferentes acciones realizadas a lo largo del mismo. Por lo tanto, esta esla historia de todos los di´alogos pasados que han tenido lugar entre el usuario y el sistema.

• la historia del di´alogo en curso, como una memoria a corto plazo que mantenga

un registro similar al anterior pero que, a diferencia de aquel, en este caso s´olo

contenga informaci´on del di´alogo en curso. Este tipo de memoria resulta in-

teresante fundamentalmente en aquellos casos en los que el proceso de negociaci´on asociado al di´alogo requiera m´ultiples intervenciones o turnos por parte del usuario con objeto de resolverlo. Si el marco sem´antico necesario para poder satisfacer los

56 Cap´ıtulo 4. Nuevas soluciones de di´alogo basadas en BNs

objetivos de di´alogo del usuario no puede completarse, no puede darse por concluido el di´alogo en curso. En ese caso el sistema debe reaccionar en primer lugar almace- nando en este tipo de memoria toda la informaci´on ´util disponible (opcionalmente podr´ıamos prescindir de los espurios) y acto seguido solicitando al usuario los ele- mentos que se estimen oportunos seg´un la interpretaci´on realizada a partir de la informaci´on disponible. En la siguiente iteraci´on el sistema debe combinar la nueva informaci´on facilitada por el usuario con la almacenada en esta memoria y as´ı, me- diante la comparaci´on de ambas fuentes, detectar qu´e elementos han sido repetidos o incluso corregidos por parte del usuario. De este modo el sistema es capaz de interpretar la ´ultima intervenci´on del usuario a la luz de la informaci´on consolidada tras el resto de intervenciones dentro del mismo acto con objeto de facilitar una respuesta apropiada.

• la informaci´on de estado, como un registro que incluya a todas aquellas variables

o par´ametros que aporten informaci´on acerca del estado y la configuraci´on actual de los sistemas a controlar.

El conocimiento contenido en estos elementos puede resultar de gran utilidad y existen muchas otras fuentes de informaci´on que pueden ser explotadas en el mismo sentido. Para tratar de demostrar la utilidad de la informaci´on contextual vamos a centrarnos en el ´

ambito dom´otico al que la presente tesis prestar´a especial inter´es. En un contexto dom´otico en el que el usuario interacciona con un conjunto de interfaces de control, t´ıpicamente el tipo de acci´on a realizar tiene por objetivo modificar el valor de un determinado par´ametro. Por ejemplo, para un equipo Hifi la intervenci´on“pon la pista cinco”tendr´ıa por objetivo fijar el par´ametro “pista” del equipo al valor mencionado, en este caso “5”.

Una variante habitual a este tipo de acciones sucede cuando el usuario trata de modifi- car un cierto par´ametro sin hacer referencia expl´ıcita a ´este, simplemente especificando el valor deseado y omitiendo cualquier otro tipo de informaci´on. Esto ocurre habitualmente cuando, una vez modificado un cierto par´ametro, en lo sucesivo el usuario tiende a omitirlo en aquellas acciones que tengan por objetivo asignar nuevos valores a dicho par´ametro. Para el ejemplo anterior, una posible intervenci´on que tuviese lugar a continuaci´on de la mencionada podr´ıa ser“pon la tres”o incluso simplemente“tres”. Estas ´ultimas alter- nativas comparten el mismo objetivo que la intervenci´on inicial, modificar el par´ametro “pista”, sin embargo en estas circunstancias es preciso revisar la memoria de di´alogo con objeto de recuperar el tipo de par´ametro adecuado, “pista”, al que corresponden los valores especificados por el usuario.

En este caso una soluci´on sencilla pero eficaz consistir´ıa en recorrer las entradas de la historia de di´alogo eligiendo el par´ametro “compatible” m´as reciente. Cuando nos referimos a la “compatibilidad” entre par´ametros y valores nos referimos a que determinados par´a- metros s´olo pueden asumir determinados valores. Sirva el siguiente ejemplo, considerando nuevamente el equipo Hifi no podr´ıa asignarse un valor “5” al par´ametro “no de disco” si el cargador o bandeja del reproductor de discos compactos del equipo no admitiese m´as que tres.

Igualmente, en aquellas situaciones en las que los usuarios omitan la informaci´on aso- ciada al valor que tome un determinado par´ametro, tambi´en ser´ıa posible aprovechar la informaci´on contextual. Para demostrarlo utilizaremos como ejemplo la siguiente inter- venci´on“pon la pista cinco del disco”. En dicha intervenci´on el usuario ha omitido la informaci´on relativa al valor que asume el par´ametro “disco”, no obstante, resulta una

4.5 Respuesta flexible, contextual y din´amica 57

interpretaci´on razonable asumir que el usuario hace referencia al disco que actualmente se est´e reproduciendo. Este dato debe estar incluido en la informaci´on de estado del sistema a la que el gestor de di´alogo debe tener acceso.

Para ello incluiremos adem´as en el sistema una base de datos que contenga informaci´on acerca del estado de los diferentes aparatos bajo control. Se trata de utilizar en el sistema de di´alogo no s´olo la informaci´on relativa al modo de interacci´on del usuario con los dispositivos o aparatos bajo su control sino tambi´en el estado en que ´estos se encuentran. Por ejemplo, si el sistema de di´alogo indica al actuador que encienda el equipo y el equipo estaba ya encendido, el actuador no deber´ıa repetir el comando. En su lugar simplemente deber´ıa enviar un mensaje al usuario inform´andole de que el equipo ya estaba encendido. Esta es una caracter´ıstica de robustez ante frases perfectamente comprendidas pero que plantean problemas pr´acticos de ejecuci´on con peligrosas p´erdidas de control si no se tratan.

Concretamente, un escenario id´oneo ser´ıa aquel en el que cont´asemos con equipos cuyo control mediante nuestro interfaz vocal se basara en una comunicaci´on bidireccional con el sistema de manera que ´este pudiera recuperar en todo momento la informaci´on en relaci´on al estado de los diferentes dispositivos. Esto permitir´ıa al usuario incluso una interacci´on multimodal en el sentido de que ser´ıa posible llevar a cabo cualquier acci´on sobre cualquier aparato de distintas formas: a trav´es de la interfaz vocal, con el mando de control infrarrojo convencional del aparato o bien accionando manualmente los controles del propio aparato. En cualquier caso e independientemente de las posibles modalidades mediante las cuales podamos interactuar con el sistema, necesariamente debemos conservar una base de datos con el estado completo de todos los par´ametros de cada uno los aparatos a controlar. La combinaci´on de la informaci´on contenida en dicha base de datos y la proporcionada por el usuario puede provocar tres posibles situaciones:

• Informaci´onredundante: en aquel caso en el que el usuario proporcione una cierta informaci´on de la que ya dispon´ıa el sistema. Esto simplemente aumentar´ıa la fiabi- lidad de los datos obtenidos de tal forma que dicho aumento de confianza permitir´ıa eliminar turnos de confirmaci´on, agilizando la gesti´on de di´alogo.

• Informaci´on complementaria: cuando los datos obtenidos se complementan, en cuyo caso se consigue aumentar el flujo de informaci´on desde el usuario al sistema. Esta situaci´on ser´ıa la deseable puesto que con un menor n´umero de interacciones se consigue satisfacer antes las necesidades del usuario. Un caso t´ıpico lo constituyen las “elipsis” o situaciones en las que el usuario omite de forma deliberada o incons- ciente cierta informaci´on necesaria para la resoluci´on del di´alogo pero que puede ser recuperada a partir del contexto.

• Informaci´on contradictoria: cuando la informaci´on proporcionada por el usuario entra en conflicto con el estado del sistema. En este caso contemplar´ıamos las siguien- tes alternativas: rechazar todos los datos contradictorios o comenzar un subdi´alogo de desambiguaci´on.