Desambiguaci´ on de la informaci´ on requerida por el sistema

La Figura5.6 presenta un completo diagrama de flujo a modo de resumen del proceso de asimilaci´on de las respuestas facilitadas por el usuario (ver bloque de proceso con nombre “ASIMILACI ´ON POSIBLE RESPUESTA” en la Figura5.5), proceso que el sistema lleva a cabo con objeto de eliminar cualquier posible ambig¨uedad en el contenido de ´estas. A continuaci´on analizaremos en detalle dicho proceso aprovechando para ello el diagrama presentado.

El proceso de asimilaci´on de posible respuesta comienza con la identificaci´on del con- junto de elementos o par´ametros que han sido solicitados (i.e. bloque “TURNO DE PE- TICI ´ON: REUNI ´ON PAR ´AMETROS SOLICITADOS” en diagrama5.6). La solicitud de dichos elementos debe ser determinada por el gestor de di´alogo en puntos m´as avanzados del diagrama que explicaremos m´as adelante (ver bloque de proceso con nombre “TURNO DE PETICI ´ON” en la Figura 5.5). Previsiblemente, el usuario debe haber generado una respuesta mediante la cual facilite total o parcialmente la informaci´on requerida. Para ca- da uno de los par´ametros solicitados se consulta el resultado de la comprensi´on con objeto de comprobar si la respuesta correspondiente a dicho par´ametro aparece expl´ıcitamente o si por el contrario precisa del contexto de di´alogo para ser correctamente interpretada (i.e. bloque “COMPRUEBA POSIBLE RESPUESTA” en diagrama 5.6). Naturalmente, s´olo en este ´ultimo caso tiene sentido el proceso de desambiguaci´on por lo que apunta- remos el par´ametro como elemento a recuperar (i.e. bloque “A ˜NADE PAR ´AMETRO A RECUPERAR” en diagrama 5.6) y pasaremos a procesar el siguiente par´ametro.

84 Cap´ıtulo 5. La Gesti´on del Di´alogo

5.3 La estrategia de gesti´on de di´alogo 85

Si el usuario responde de manera expl´ıcita (i.e. facilitando el valor espec´ıfico requerido y repitiendo la informaci´on relativa al par´ametro solicitado), entonces no cabe llevar a cabo m´as acci´on que almacenar en la historia del di´alogo en curso el par formado por el par´ametro solicitado y el correspondiente valor facilitado por el usuario (i.e. bloque “PROCESA RESPUESTA FACILITADA” en diagrama5.6).

Una vez identificados el conjunto de par´ametros que vamos a intentar recuperar (i.e. aquellos par´ametros solicitados para los que no ha sido posible precisar su valor corres- pondiente a partir de la respuesta facilitada por el usuario), comienza el proceso de re- cuperaci´on de los mismos (i.e. bloque “REUNI ´ON PAR ´AMETROS A RECUPERAR” en diagrama 5.6).

En este punto es preciso destacar la intenci´on, que no la certeza, de recuperar todos los elementos de dicho conjunto. Efectivamente, si por ejemplo el usuario decide no especificar valor alguno ser´a necesaria su oportuna aclaraci´on en posteriores turnos.

Este proceso comienza con la identificaci´on de todos aquellos valores para los que no ha sido posible precisar el par´ametro espec´ıfico al cual corresponden (i.e. bloque “COM- PRUEBA VALORES AMBIGUOS” en diagrama5.6). De este conjunto saldr´an los valores correspondientes a los par´ametros que deben ser recuperados. La posible ambig¨uedad de- bida a la existencia de varios par´ametros a recuperar o varios valores ambiguos entre los que decidir se resolver´a a partir del contexto de di´alogo.

Para cada uno de estos valores (anteriormente denominados “gen´ericos”), podr´ıa lle- varse a cabo un proceso de desambiguaci´on que, inicialmente, contemplase como posibles candidatos a todos los par´ametros definidos sin excepci´on (i.e. bloque “RE ´UNE POSI- BLES CANDIDATOS PARA EL VALOR” en diagrama 5.6).

Tal y como hemos podido comprobar en apartados anteriores (ver secci´on 5.2), a continuaci´on este conjunto puede irse reduciendo significativamente en la medida en que se produce la oportuna y sucesiva consulta de las distintas fuentes de informaci´on disponibles. Por ejemplo, gracias a la consulta de la historia del di´alogo en curso evitamos considerar como posibles candidatos a aquellos par´ametros que ya est´en disponibles (i.e. bloque “CONSULTA HISTORIA DEL DI ´ALOGO EN CURSO” en diagrama 5.6).

A su vez el conocimiento espec´ıfico del dominio permite eliminar como posibles can- didatos aquellos par´ametros cuyo tipo y rango no resulten compatibles con los del valor gen´erico que es objeto del proceso de desambiguaci´on (i.e. bloque “CONSULTA CONO- CIMIENTO ESPEC´IFICO DEL DOMINIO” en diagrama 5.6).

En definitiva, la oportuna consulta de la historia del di´alogo en curso y del conocimiento espec´ıfico del dominio de aplicaci´on permite ordenar la lista de posibles candidatos seg´un la probabilidad de que cada uno de estos par´ametros candidatos pueda corresponder al valor ambiguo en cuesti´on. Igualmente, permite eliminar de dicha lista aquellos candidatos que no resulten coherentes con el contexto actual de di´alogo.

Una vez disponible la lista ordenada de posibles par´ametros candidatos que puedan corresponder al valor ambiguo en cuesti´on, se seleccionar´a el primer candidato compatible con dicho valor (i.e. bloque “SELECCI ´ON PRIMER CANDIDATO COMPATIBLE” en diagrama 5.6). A continuaci´on se asociar´a el valor gen´erico al par´ametro candidato, asi- mil´andolo como tal y por tanto reconsider´andolo como un valor del mismo tipo espec´ıfico que el correspondiente al par´ametro (i.e. bloque “ASIMILACI ´ON VALOR GEN ´ERICO” en diagrama 5.6). Finalmente, el proceso concluir´a a˜nadiendo ambas observaciones, la

86 Cap´ıtulo 5. La Gesti´on del Di´alogo

correspondiente al par´ametro cuyo valor ha sido recuperado y el propio valor, al conjunto de evidencias disponible (i.e. bloque “ACTUALIZACI ´ON EVIDENCIAS DISPONIBLES” en diagrama 5.6).

En cualquier caso, e independientemente de la mayor o menor complejidad del proceso de desambiguaci´on, el conjunto de posibles candidatos a considerar para una respuesta ambigua (i.e. bloque “RE ´UNE POSIBLES CANDIDATOS PARA EL VALOR” en dia- grama5.6), puede definirse directamente a ra´ız de la interpretaci´on realizada por el gestor de di´alogo durante la ´ultima intervenci´on del usuario. Dicha interpretaci´on delimita, entre otros aspectos, la necesidad de preguntar al usuario acerca de un conjunto de par´ametros. Este conjunto de par´ametros para los que el sistema ha desencadenado un proceso de solicitud y para los que a´un no ha sido recuperada respuesta alguna son los que autom´ati- camente pueden ser considerados como candidatos coherentes con el contexto de di´alogo. De hecho, forman parte del contexto del di´alogo, ya que el sistema est´a preguntando al usuario espec´ıficamente por ellos. Esta es una de las diferencias importantes respecto al proceso de desambiguaci´on de informaci´on impl´ıcita no solicitada por el sistema (secci´on

5.3.6) que tendr´a lugar m´as adelante.

Anteriormente ve´ıamos la posibilidad de ordenar la lista de candidatos disponibles mediante la consulta de la historia de di´alogo (ver secci´on 5.2.5). Este ordenamiento se realizaba seg´un la “actualidad” de las ´ultimas referencias correspondientes a dichos candidatos. Como puede comprobarse en el diagrama de flujo, en este caso se ha obviado dicha consulta (i.e. en el diagrama5.6 s´olo se refleja la consulta de la historia del di´alogo en curso y del conocimiento espec´ıfico del dominio).

El motivo fundamental que lleva a prescindir de dicho paso reside en el hecho de que, bas´andonos en el mismo principio expuesto para el mencionado ordenamiento, no existen en el contexto de di´alogo referencias m´as recientes a candidato alguno que las incluidas en la propia pregunta formulada. De este modo, y teniendo en cuenta que el presente pro- ceso s´olo tiene por objetivo la correcta asimilaci´on de las respuestas correspondientes a los par´ametros solicitados (como veremos en apartados posteriores, pueden aparecer otros valores que, sin haber sido requeridos por el sistema, tambi´en requieran de un proceso de desambiguaci´on), asumiremos que el orden correspondiente a los candidatos bajo consi- deraci´on es aqu´el en que ´estos aparecen en dicha pregunta (i.e. asumimos que en caso de solicitarse varios par´ametros ´estos se contestar´an en el mismo orden). En la misma l´ınea, podemos prescindir igualmente de la consulta de la informaci´on de estado del sistema.

Veamos el siguiente ejemplo: supongamos que el usuario y el sistema se encuentran en pleno proceso de negociaci´on orientado a la reproducci´on de un determinado disco y una determinada pista empleando para ello el aparato reproductor de CD. Asumiendo que el usuario inicialmente s´olo hace referencia al disco en cuesti´on, el sistema resolver´a que debe preguntar al usuario acerca de la pista que ´este desea escuchar o reproducir. Para ello el sistema podr´ıa formular el siguiente prompt:“¿Qu´e pista desea reproducir?”.

Como puede comprobarse, el par´ametro objeto de la consulta es referido expl´ıcitamen- te por parte del sistema en la pregunta realizada. As´ı, una posible respuesta por parte del usuario podr´ıa ser:“la cinco”, frase para la que el usuario ha prescindido del par´ametro en cuesti´on (no es necesario toda vez que forma parte del contexto de di´alogo). Para seme- jante respuesta el m´odulo de comprensi´on facilitar´ıa como resultado “N ´UMERO=[cinco]”, concepto de tipo valor que, de momento, no est´a asociado a par´ametro alguno. Por otra parte podemos concluir que, habida cuenta que “V PISTA” no se encuentra entre los con-

5.3 La estrategia de gesti´on de di´alogo 87

ceptos extra´ıdos, la respuesta correspondiente al par´ametro solicitado est´a impl´ıcita, es decir, debe ser recuperada a partir del contexto de di´alogo.

Una vez reunidos todos los valores “gen´ericos” o ambiguos presentes en la frase (i.e. “N ´UMERO=[cinco]”) se define el conjunto de par´ametros candidatos a los que asimilar dichos valores. Este conjunto de candidatos est´a constituido por aquellos par´ametros que han sido objeto de solicitud por parte del sistema (i.e. “P PISTA”).

Para los candidatos disponibles se procede entonces a la debida consulta de la historia del di´alogo en curso y del conocimiento espec´ıfico del dominio de aplicaci´on con objeto de conseguir ordenar la lista de candidatos disponible. Este ordenamiento se realiza en funci´on de la probabilidad de que cada uno de estos par´ametros candidatos pueda co- rresponder al valor ambiguo en cuesti´on. En este caso el par´ametro “P PISTA”, ´unico candidato coherente con el contexto actual de di´alogo, por una parte no est´a incluido en la citada memoria y por otra resulta un par´ametro perfectamente compatible con el va- lor gen´erico considerado. Ante este resultado, la decisi´on m´as razonable pasa por asociar dicho valor al par´ametro candidato (i.e. “P PISTA”), asimil´andolo como tal y por tanto reconsider´andolo como “V PISTA=[cinco]”. El proceso finalizar´ıa a˜nadiendo ambas obser- vaciones, la correspondiente al par´ametro cuyo valor ha sido recuperado (i.e. “P PISTA”) y el propio valor (i.e. “V PISTA”), al conjunto de evidencias disponible.

5.3.4.3 Sobre la validez del proceso de asimilaci´on

A la vista de los ejemplos presentados, cabe una cierta reflexi´on acerca de la conveniencia o idoneidad del procedimiento presentado. Tal y como destacamos en el apartado 5.3.4.1, la respuesta facilitada por el usuario puede no ajustarse a lo demandado por parte del sistema. Por un lado puede suceder que el usuario no facilite respuesta alguna para ninguno de los elementos solicitados (i.e. situaci´on a la que anteriormente nos hemos referido como preguntas “sin respuesta”) o, por el contrario, que ´este incluya en su respuesta m´as informaci´on de la que ha sido estrictamente solicitada (i.e. respuestas a las que nos referimos como “inesperadas”). Ninguna de estas situaciones representa una amenaza para la correcta evoluci´on del di´alogo.

Para las que hemos denominado preguntas “sin respuesta” no se ha previsto tratamiento espec´ıfico alguno. Efectivamente, no resulta necesario. En esas circunstancias el di´alogo simplemente debe seguir su curso. De este modo hacemos posible una nueva interpretaci´on de la intenci´on o voluntad del usuario a la vista de la nueva informaci´on recogida (e.g. en caso de que a su vez tenga lugar una respuesta “inesperada”). Esta hipot´etica nueva interpretaci´on supone la identificaci´on de un conjunto de objetivos de di´alogo posiblemente diferente, objetivos para los que los elementos que fueron solicitados anteriormente y para los que no se obtuvo la respuesta esperada ya no tienen porque resultar necesarios. En su defecto, la evoluci´on del di´alogo puede llevar al sistema a solicitar nuevamente dichos elementos al usuario en la expectativa de que en esta ocasi´on s´ı obtengamos la respuesta adecuada para los mismos.

Las respuestas “inesperadas” tampoco representan por s´ı mismas un problema. Las referencias ambiguas a elementos por los que no se ha preguntado pueden resolverse gra- cias a un procedimiento adicional que permite su adecuada desambiguaci´on a partir de la informaci´on del contexto de di´alogo (como podremos comprobar en los siguientes aparta- dos).

88 Cap´ıtulo 5. La Gesti´on del Di´alogo

Sin embargo, el verdadero desaf´ıo para el procedimiento de asimilaci´on de respuesta consiste en hacer frente al posible desorden que puede afectar a la respuesta facilitada por el usuario. Si recuperamos la ´ultima frase presentada en 5.3.4.1 a modo de ejemplo, e.g.

“S´ubelo y pon la cinco”, cabe decir que en ella la ambig¨uedad alcanza su m´axima expresi´on. Esta ambig¨uedad afecta tanto a par´ametros que fueron solicitados como tambi´en a otros que no lo fueron, y no s´olo eso, tambi´en se ve afectado el orden de todos ellos. Los par´ametros solicitados y los valores correspondientes facilitados como respuesta pueden no aparecer en el mismo orden. Por otra parte, la aparici´on de elementos ambiguos adicionales aumenta la dificultad del problema al introducir una incertidumbre extra (a menos que estos elementos aparezcan a continuaci´on de los valores ambiguos correspondientes a los elementos solicitados).

Aunque la ocurrencia simult´anea de todos los fen´omenos enumerados no suele ser habitual, la ambig¨uedad inherente al orden de los distintos elementos facilitados como respuesta supone un serio problema cuya soluci´on pasa fundamentalmente por el opor- tuno aprovechamiento del conocimiento espec´ıfico del dominio de aplicaci´on. La adecuada explotaci´on de dicha fuente de informaci´on por parte del procedimiento de desambiguaci´on aqu´ı presentado es garant´ıa suficiente para la resoluci´on de dicho problema.

En ese sentido, a la vista de los ejemplos presentados (especialmente en el presente apartado, pero tambi´en en el dedicado anteriormente a la utilidad de la informaci´on contextual), podr´ıa apuntarse la posible y significativa reducci´on de la complejidad del problema que nos ocupa en la medida en que el resultado facilitado por el m´odulo de comprensi´on fuese m´as completo. Por ejemplo, los diferentes art´ıculos que aparecen en la frase podr´ıan recibir un tratamiento adecuado desde el punto de vista sem´antico, de tal modo que fuese posible facilitar la informaci´on de “g´enero” correspondiente a cada uno de los valores “gen´ericos” recogidos (e.g. mediante el oportuno an´alisis morfosint´actico de la intervenci´on del usuario).

Esta informaci´on de g´enero podr´ıa complementar la informaci´on de tipos correspon- diente a cada uno de los diferentes par´ametros definidos. Gracias a esta informaci´on de tipos resulta posible desambiguar el par´ametro correspondiente a un determinado valor gen´erico, desechando aquellos posibles candidatos cuyo tipo no coincida con el del valor en cuesti´on. Del mismo modo, tambi´en es posible eliminar como posibles candidatos a aquellos cuyo g´enero no se corresponda con el del mencionado valor. Por lo tanto, si a la informaci´on de tipos le sumamos la informaci´on de g´enero, una mejor desambiguaci´on resulta posible.

De cualquier forma, el empleo de la informaci´on de g´enero no es m´as que un ejem- plo m´as de c´omo el conocimiento espec´ıfico del dominio de aplicaci´on puede resultar de utilidad durante el proceso de desambiguaci´on. Dicha utilidad ya qued´o manifiesta al introducir la informaci´on de tipos, por lo que no insistiremos en ella.