Diseño e integración con VXML de un sistema de diálogo para la consulta de correo electrónico en lenguaje natural

Leandro Rodríguez Liñares, David Pérez-Piñar López, Carmen García Mateo

Departamento de Tecnoloxías da Sinal e Comunicacións Universidade de Vigo

{leandro,dperez,carmen}@gts.tsc.uvigo.es

Resumen En los últimos años ha surgido un nuevo tipo de interfaces hombre-máquina que combina varias tecnologías de habla, con el fin de permitir a las personas la interacción vocal con los ordenadores. En este artículo presentamos un sistema de diá-logo práctico orientado a la consulta, mediante lenguaje natu-ral, del correo electrónico. El desarrollo de sistemas de diálogo prácticos como éste, orientados a aplicaciones específicas, requiere un esfuerzo de diseño muy elevado. Una de las razo-nes de este problema es la interdependencia entre las fuentes de conocimiento lingüístico, que requieren coherencia en to-dos sus niveles. Para solucionar este problema sin afectar a la calidad del sistema, presentamos una arquitectura específica que permite la integración automática de todas las fuentes de conocimiento lingüístico a partir de la especificación formal de la aplicación utilizando el estándar VXML. Esta arquitectu-ra se caracteriza por su modularidad y su independencia com-pleta de la aplicación. Presentamos también la aplicación de esta metodología a nuestro sistema de diálogo.

1. Introducción Cada vez es más habitual encontrar sistemas que proporcionan diversos tipos de información utilizando el habla [2] [8]. Mu-chos de estos sistemas disponen de interfaces que pueden ser considerados conversacionales, en el sentido de que permiten una conversación real entre el usuario y el sistema. El grado de participación activa en la conversación de cada una de las partes permite clasificar estos sistemas en tres grupos básicos: sistemas de iniciativa en el sistema, en los cuales el diálogo es dirigido; sistemas de iniciativa en el usuario, en los que el sistema es pasivo, y el usuario tiene libertad para expresarse de modo natural; y sistemas de iniciativa mixta, en los que tanto el sistema como el usuario participan activamente para llevar a buen término la interacción.

Por otra parte, uno de los obstáculos más problemáticos en el desarrollo de sistemas de diálogo consiste en la especifica-ción del mismo, desde las tareas que puede realizar hasta la interfaz con el usuario. Durante los últimos años se han des-arrollado numerosos estudios dirigidos a dotar a estos sistemas de naturalidad en la interacción [1], y resumidamente puede extraerse la conclusión de que los sistemas que funcionan son aquellos que implementan diálogos prácticos, es decir, diálo-gos centrados en temas específicos.

En este artículo presentamos un sistema de diálogo prácti-co de iniciativa en el usuario, orientado a la consulta mediante lenguaje natural del correo electrónico. El sistema emplea un reconocedor de voz y un conversor texto-voz previamente disponibles, y fue originalmente desarrollado para funcionar en PC bajo Linux. La versión actual emplea una arquitectura

modular basada en VXML, que permite independizar comple-tamente la gestión lingüística de la aplicación y automatizar la integración de las fuentes de conocimiento lingüístico en todos sus niveles. Pensamos que esta integración y automatización son claves, tanto para facilitar el desarrollo de sistemas prácti-cos de diálogo como para permitir una interacción en lenguaje natural sin errores en la interacción.

2. Arquitectura clásica de un sistema de diálogo

En la Figura 1 se muestra un esquema simplificado de un sistema de diálogo que sigue la arquitectura clásica. Desde el punto de vista de la implementación, esta arquitectura es mo-dular, en el sentido de que los diferentes elementos que la componen pueden desarrollarse de manera independiente.

Figura 1: Arquitectura clásica

Las fuentes de conocimiento que se reflejan en el esque-ma son las básicas en cualquier sistema de diálogo, aunque su formato, su arquitectura o su número pueden variar según la implementación: •= Base de datos de unidades de reconocimiento. Contiene

las unidades fonéticas que emplea el reconocedor.

•= Vocabulario. Palabras que se pueden reconocer.

•= Modelos de lenguaje del reconocedor. Establecen una relación estadística entre las palabras del vocabulario.

•= Gramática del analizador. Establece unas reglas sintácti-cas y semánticas mediante las que se obtiene una repre-sentación semántica de lo que el usuario ha dicho.

•= Árbol de conocimiento. Contiene toda la información formalizada de la interacción con el usuario y su relación con las acciones que el sistema debe llevar a cabo.

•= Bases de datos externas. En la práctica totalidad de los sistemas de diálogo se encuentran datos externos que forman parte del conocimiento lingüístico del sistema.

•= Gramática del generador de lenguaje. Establece las reglas de construcción de las frases de salida del sistema.

•= Gramáticas del conversor texto-voz. Son gramáticas pro-pias de los conversores que expanden ciertos elementos (fechas, números, direcciones de correo electrónico...)

•= Base de datos de alófonos del conversor texto-voz. En es-te elemento se incluyen las muestras sonoras para sinteti-zar la voz y las reglas de formación de la prosodia.

La relación entre estos elementos se hace más compleja de arriba abajo. Así, las bases de datos de unidades de reconoci-miento y de alófonos dependen, fundamentalmente, del idio-ma, pero son prácticamente independientes de la aplicación y del resto de las fuentes de conocimiento. Sin embargo, los elementos de orden superior (vocabulario, modelos de lengua-je, gramáticas y árbol de conocimiento) están íntimamente relacionados, y van perdiendo esa relación con el idioma.

Así se ha puesto de manifiesto en numerosos estudios orientados a mejorar las prestaciones de los sistemas de diálo-go, tanto desde el punto de vista de la entrada de información como de la salida [7]. Sin embargo, esa relación entre las diferentes fuentes de conocimiento es difícil de implementar en sistemas que sigan esta arquitectura tradicional. La razón, desde nuestro punto de vista, está en la falta de un elemento aglutinador de la información, capaz de plasmar esas relacio-nes entre los diferentes elementos de conocimiento.

Efectivamente, cada módulo utiliza la información que le corresponde, y conoce el modo de comunicarse con los demás módulos para que éstos lleven a cabo su tarea. Pero no hay ningún módulo que establezca restricciones a esa comunica-ción, o lo que es lo mismo, no hay ningún elemento inteligen-te capaz de asociar entre sí los diversos elementos propios de la comunicación lingüística.

3. Arquitectura centralizada con módulo de gestión lingüística

Para resolver el problema de la coordinación de las fuentes de conocimiento, proponemos una nueva arquitectura que ya se está implantando en algunos sistemas, aunque con otros obje-tivos. La Figura 2 muestra un esquema de esta arquitectura.

Figura 2: Arquitectura centralizada

El conocimiento formal de la aplicación que reside en el gestor de diálogo debe estar disponible no sólo durante su funcionamiento, sino también en la fase de desarrollo, en la que se determinan las fuentes de conocimiento de niveles inferiores. La relación existente entre los conceptos que maneja la aplicación y los formalismos lingüísticos que permiten dialogar sobre ellos puede derivarse de ese conocimiento formal superior, y por tanto desarrollar toda una aplicación a partir de una especificación única.

Esto impone una serie de condiciones en la arquitectura del sistema. Por un lado, todos los módulos deben exponer sus fuentes de conocimiento de forma que se puedan modifi-car desde fuera, y a ser posible dinámicamente. Por otro lado, es necesario un módulo independiente de generación de esas fuentes de conocimiento. Este nuevo módulo toma como base la información del árbol de conocimiento, y a partir de ella y de fuentes lingüísticas genéricas de conocimiento construye las fuentes de conocimiento de cada módulo.

El acceso dinámico a las fuentes de conocimiento de cualquier nivel es imprescindible en la mayoría de los casos [7], porque en muchas aplicaciones los datos externos cam-bian a lo largo de la ejecución. Por eso, el nuevo módulo propuesto debe ser capaz de acceder también a estos datos e incluirlos en los módulos cuando sea preciso en tiempo de ejecución. De aquí se deriva la necesidad de estandarizar el acceso a los datos externos. En general, puede especificarse una interfaz estándar entre el sistema y los módulos de acceso a dicha información, así como a cualquier recurso externo relacionado con la aplicación.

4. Desarrollo práctico del sistema de diálogo: integración con VXML

El objetivo del sistema presentado en este artículo consiste en permitir la consulta del correo electrónico empleando lengua-je natural. Como se muestra en el esquema de la Figura 3, el sistema recibe una señal de entrada con la voz del usuario, la procesa mediante el reconocedor de habla y obtiene el texto que se analiza en el módulo de control de diálogo. Una vez obtenida una respuesta, ésta se sintetiza en el conversor texto-voz para enviar al usuario la información.

Figura 3: Implementación de la arquitectura propues-ta mediante VXML

Como base de pruebas para llevar a cabo los objetivos presentados hasta aquí, el sistema se está desarrollando de modo que se cumplan todas las condiciones para permitir una definición automática de aplicaciones, siendo al mismo tiem-po completamente independiente de la aplicación y soportan-do una interacción natural con el usuario.

El sistema es una modificación de un servicio vocal tele-fónico de correo electrónico, denominado TelCorreo [13], en el que se han implementado las funciones básicas de un clien-te de correo electrónico para el acceso por voz al buzón de correo de cada usuario. Entre las características propias del sistema de diálogo pueden destacarse la introducción de la verificación de usuarios por voz y el soporte de interacción natural, tanto en reconocimiento como en síntesis de habla.

La modificación del sistema, siguiendo las líneas de desa-

rrollo descritas anteriormente, se ha realizado buscando si-multáneamente una estandarización de la especificación for-mal del diálogo y un soporte modular para la entrada en len-guaje natural. Dado el auge del lenguaje VXML y su cada vez

mayor aceptación, se ha escogido este estándar, también por la relativa facilidad de manejo de las gramáticas que ofrece y por la posibilidad de desarrollar un intérprete completamente independiente, tanto de la plataforma hardware como de la aplicación a que se destina.

En la selección de VXML como formalismo de represen-tación conceptual se han tenido en cuenta los siguientes as-pectos:

•= Su estandarización y aceptación global da acceso a múlti-ples herramientas de análisis, verificación y desarrollo de código VXML.

•= La posibilidad de crear intérpretes de VXML completa-mente independientes de la aplicación y del hardware.

•= La capacidad para soportar gramáticas, tanto de análisis como de síntesis, que permitan definir una interacción na-tural con el sistema.

•= La posibilidad de desarrollar aplicaciones complejas, y en concreto la capacidad de VXML para formalizar interac-ciones de iniciativa mixta.

•= La facilidad de integración con el intérprete de módulos externos de diversos tipos, que serán dependientes de la aplicación e independientes del intérprete.

•= La posibilidad de utilizar el intérprete como servicio de un módulo de gestión superior.

•= La capacidad para introducir módulos inteligentes de procesado del diálogo sin salir del estándar.

5. Descripción general de la aplicación Como ya se ha indicado, el servicio que ofrece el sistema es el acceso al correo electrónico mediante lenguaje natural. El usuario, después de identificarse mediante un número y una clave personales, solicita la acción que desea realizar. Estas acciones generales son las siguientes: •= Consultar si se ha recibido algún mensaje y contar los

mismos.

•= Consultar características de los mensajes tales como la fecha, el remitente o el asunto.

•= Leer alguno de los mensajes existentes.

•= Borrar mensajes del buzón.

Cada una de estas acciones puede realizarse sobre un men-saje concreto o sobre un grupo de mensajes. El mecanismo de selección de los mensajes es independiente de la acción, y permite restringir la consulta siguiendo diversos criterios de filtrado: •= Indicando la posición del mensaje dentro de la lista com-

pleta.

•= Solicitando los N primeros o los N últimos.

•= Indicando el remitente.

•= Especificando la fecha de envío. En este caso, se pueden solicitar los mensajes de una fecha concreta o los que sean anteriores o posteriores a la misma.

•= Indicando si se buscan mensajes nuevos o mensajes que ya han sido leídos.

Consulta Accion Indicador Num Remite Fecha

“Borra los dos primeros mensajes de Manolo” borrar remite+primeros 2 Manolo null

“Lee los mensajes de Manolo recibidos el viernes” leer remite+fecha null Manolo viernes

“Dime el asunto del primero mensaje nuevo” consultar_tema posición+noleidos 1 null null

Tabla 1: Ejemplos de análisis de consultas

Estos criterios pueden combinarse en una misma consulta. Así, por ejemplo, es posible solicitar el último mensaje recibi-do de un remitente concreto, o el primer mensaje recibido en una fecha determinada.

El usuario puede, como ya se ha indicado, expresar su consulta de modo natural. Por tanto, el sistema no impone restricciones teóricas al habla del usuario. Sin embargo, en la práctica sí hay restricciones. Por ello, es de especial importan-cia el diseño de las fuentes de conocimiento lingüístico y el de los módulos de procesado de lenguaje, porque de ellos depen-de el grado de naturalidad en el habla.

6. Estructura del sistema El desarrollo del sistema completo sigue la arquitectura cen-tralizada de la Figura 2, partiendo de una base simple a partir de la que se desarrollarán paulatinamente los diferentes mó-dulos. En la Figura 3 se muestra la arquitectura actualmente desarrollada.

6.1. Gestor del diálogo: Intérprete VXML

El intérprete VXML constituye el núcleo principal de la apli-cación. Sus funciones incluyen la interacción con las herra-mientas de habla (el reconocedor y el conversor texto-voz) y la comunicación con el servidor de acciones externas, a través del que se comunica con el servidor de correo electrónico y con el gestor de usuarios. En nuestra implementación inicial, como puede verse en la Figura 3, el gestor de diálogo se limita al intérprete VXML, descargando toda la inteligencia en la especificación VXML del diálogo.

Los ficheros VXML constituyen lo que se denomina apli-cación VXML, y en ella quedan definidas las tareas de inter-acción con los distintos elementos del sistema. Así, la aplica-ción obtendrá en primer lugar la consulta del usuario, solici-tándola al reconocedor de voz. Esta consulta será enviada al analizador para obtener una representación semántica, y con los datos obtenidos accederá al servidor de correo a través del servidor de acciones. La respuesta (un mensaje de correo, un remitente, un mensaje de error...) será enviada en formato texto al conversor texto-voz.

El intérprete VXML está desarrollado en lenguaje C++, e incorpora una interfaz de comunicación con un intérprete Prolog [5], lenguaje en que ha sido desarrollado el Analizador de Consultas.

6.2. Analizador de Consultas

Este módulo recibe la frase a analizar como una lista Prolog. La comunicación se lleva a cabo a través de un predicado consulta/6, que tiene un término de entrada y cinco de salida:

consulta(+A,-Accion,-Indicador,-Num,-Remite,-Fecha)

En A se introduce la frase a analizar, y el resto de las va-riables son instanciadas en el módulo según el resultado del análisis: •= Accion: Indica la acción a realizar (contar, leer, borrar,

consultar_remite, consultar_fecha, consultar_tema)

•= Indicador: Sirve para establecer el criterio de selección de los mensajes de la consulta. Algunos de sus posibles valores son todos, numero, leidos, remite, fecha_desde, fecha_antes... Además, estos criterios pueden ser combi-nados mediante el signo + (por ejemplo, remite+fecha).

•= Num: Contiene el número del mensaje a leer o la posición de un mensaje determinado.

•= Remite: El remitente cuyos mensajes se deseen seleccio-nar.

•= Fecha: Contiene el valor de la fecha si se ha seleccionado el criterio de fecha. En esta primera versión, los valores posibles se han limitado a hoy, ayer, anteayer y a los nombres de los días de la semana (lunes a domingo).

Como ya se ha indicado, los criterios de selección de mensajes son combinables: en estos casos, los valores de los parámetros se combinan de acuerdo con el criterio de selec-ción para realizar la consulta. La Tabla 1 muestra algunos ejemplos de combinaciones de este tipo.

6.3. Reconocedor de Voz

El Reconocedor de Habla utilizado en este sistema se encuen-tra descrito en [4] [3]. Está basado en un motor de reconoci-miento que utiliza 25 modelos preentrenados de fonemas. Dichos modelos consisten en HMM's (Modelos Ocultos de Markov) que fueron entrenados utilizando una base de datos de voz telefónica, aunque posteriormente fueron adaptados para ser usados para reconocer voz obtenida directamente de la tarjeta de sonido de un PC. Los modelos son de los deno-minados de izquierda a derecha con 3 estados y 16 mezclas por estado.

La voz obtenida es muestreada a 8 KHz. A partir de la misma, se obtienen la energía y 12 coeficientes mel-cepstra utilizando una ventana de análisis de longitud 20 mseg. con un desplazamiento de 10 mseg. Se aplica un liftering con factor 22 y se añaden las primeras y segundas derivadas de los parámetros, obteniendo así vectores de 39 coeficientes por trama. Para lograr cierta ecualización, a los vectores de pará-metros se les suprime su media.

6.4. Generación del modelo de lenguaje

El Reconocedor de Habla utiliza un modelo de lenguaje pro-babilístico basado en el formato ARPA, similar al que utilizan el conjunto de herramientas de reconocimiento HTK. Dicho modelo consiste en un léxico y un conjunto de probabilidades de unigramas, bigramas y trigramas a partir de los cuales se construye una red de reconocimiento. Esta red es utilizada por el motor de reconocimiento, que aplica el algoritmo de Viter-bi para obtener la cadena reconocida con mayor probabilidad.

Se puede ver, por tanto, que el modelo de lenguaje es un modelo probabilístico, por lo que, para su obtención, es nece-sario un corpus de texto suficientemente grande a partir del cual se obtienen tanto el léxico como el conjunto de probabi-lidades de los n-gramas. Lo ideal es utilizar un corpus adapta-do a la tarea de reconocimiento, esto es, que sea representati-vo del posible conjunto de frases que a las que va a tener que enfrentarse el reconocedor. Para obtener este corpus se ha explotado el hecho de que un analizador Prolog puede ser utilizado de forma sencilla como generador de frases correctas de acuerdo a la gramática que define.

Unidades dereconocimiento

lenguajeModelo de

Gramaticade analisis

Corpus defrases

Interfaz deComunicacion

Analizador

VocabularioReconocedor

de Voz

USUARIO

Figura 4: Interfaz de reconocimiento del sistema

En resumen, para obtener el modelo de lenguaje se han llevado a cabo los siguientes pasos (ver Figura 4): 1. Definición informal de una gramática para las consultas.

Se ha elegido un posible conjunto de estructuras de frase que permitan la obtención de información sobre correo electrónico. Por ejemplo: “léeme los mensajes...”, “¿po-drías decirme...?”, “quiero que me digas el número de...”

2. Implementación de un analizador de la gramática en Pro-log. Para ello se ha utilizado un predicado raíz frase. A partir de éste, mediante dos reglas, se consideran dos tipos de frases: verbal (“quiero leer...”) e interrogativa (“¿po-drías decirme...?”). Se ha tenido en cuenta la concordan-cia entre género y número para evitar la proliferación de frases gramaticalmente incorrectas.

3. Transformación del analizador en un generador de frases correctas. Generación del corpus de frases correctas.

4. Estimación del modelo de lenguaje. Para ello se ha utili-zado el conjunto de herramientas software presentado en [14].

El vocabulario de la aplicación está compuesto de un total

de 144 palabras, y el corpus de frases al que da lugar está compuesto de unos cuantos millones de frases. El número de apariciones por palabra oscila entre las aproximadamente 20.000 veces que aparecen palabras como nuevo, viejo, etc., y los siete millones que aparece la palabra el. La media del número de apariciones para cada palabra es de algo más de medio millón de veces. El modelo de lenguaje estimado cons-ta de 144 palabras, 1637 bigramas y 11801 trigramas. Para la estimación de estas cifras se ha utilizado una agenda de remi-tentes en la cual había tres personas cuyos nombres constaban de una sola palabra.

6.5. Conversor Texto-Voz Cotovía

El Conversor Texto-Voz utilizado es el denominado Co-tovía [6] [11]. Cotovía es un Conversor Texto-Voz bilingüe castellano/gallego basado en concatenación de unidades. Es capaz de generar voz masculina o femenina de banda ancha (8 KHz). La frecuencia fundamental y la velocidad de articula-ción son parámetros configurables por el usuario.

Cotovía actúa como un módulo completamente indepen-diente del resto del sistema, e integra todas las funciones ne-cesarias para trabajar como aplicación aislada. Entre estas destacan sus capacidades para realizar preprocesado de texto.

6.6. Módulos externos e independencia de la aplicación

Uno de los aspectos más complejos en la independencia de la aplicación consiste en la conexión entre los módulos externos y el gestor de diálogo. La independencia se ha implementado a través del elemento <OBJECT> especificado en el estándar VXML. Este elemento permite realizar tareas no especifica-das en el lenguaje, a la vez que permite utilizar variables y contenidos de la aplicación.

Su conexión con los módulos externos se realiza mediante sockets. El intérprete se conecta a un servidor de acciones genérico, que a su vez es el encargado de realizar las acciones externas. Para mantener la independencia de la aplicación, este servidor genérico externo se configura mediante un fiche-ro que indica los módulos que están disponibles y el meca-nismo de comunicación con cada uno, así como las funciones que ofrecen.

De esta manera, el servidor de acciones es también inde-pendiente de la aplicación, y al mismo tiempo su configura-ción se hace accesible al módulo de control lingüístico, permitiendo así un acceso centralizado para el diseño de la aplicación, y sobre todo para el mantenimiento de las dependencias dinámicas.

La interfaz entre el intérprete y los demás módulos se ha

desarrollado siguiendo el mismo esquema de comunicación mediante sockets. Esto permite, por ejemplo, sustituir el reconocedor de voz o el conversor texto-voz por herramientas de línea de comandos sin modificar el intérprete, lo cual facilita mucho las tareas de depuración y desarrollo de las aplicaciones. El formato de los mensajes entre los distintos módulos y el intérprete se ha diseñado de forma que mantenga la independencia de la aplicación, y al mismo tiempo no reduzca las prestaciones del sistema.

7. Conclusiones y posibles mejoras En esta comunicación se ha desarrollado una aplicación de consulta de correo electrónico con iniciativa en el usuario utilizando el lenguaje Prolog para el análisis de las consultas. Esto demuestra que es posible la extensión de esta arquitectu-ra a otras aplicaciones de consulta remota. Por otra parte, la integración con el estándar VXML permite independizar la gestión del diálogo de la aplicación y exponer las fuentes de conocimiento, tanto estáticas como dinámicas, para permitir su integración y mejorar así la coherencia entre ellas.

Las aplicaciones son ampliables, ya que el diseño del Analizador de Consultas permite la extensión de éste, pudien-do tanto añadir palabras al léxico de la aplicación como crear nuevas estructuras sintácticas o nuevas combinaciones de las ya existentes. Sin embargo, el procedimiento para crear los modelos de lenguaje dista de ser cómodo. La generación del modelo de lenguaje a partir de la gramática es un aspecto en el que se está trabajando en el momento en que se escribe este artículo. El analizador Prolog hace uso del formalismo de las DCG's (Definite Clause Grammars), a partir del cual es fácil construir algún tipo de script que extraiga tanto el vocabulario como el fichero de gramática en formato HTK, muy similar al formato de especificación de gramáticas ABNF. La ventaja de utilizar un modelo de lenguaje basado en una gramática de estados frente a un modelo probabilístico es que se evita la necesidad de la construcción de un corpus de frases, lo que redunda en un aumento de flexibilidad y comodidad en el procedimiento de generación de modelos de lenguaje.

Otras modificaciones irán encaminadas al aumento de la inteligencia y la naturalidad del diálogo. Entre estas podemos citar: •= El sistema original es sin memoria, es decir, cada consul-

ta se considera completa de forma individual. En la nueva versión se contempla la posibilidad de aprovechar la po-tencialidad de VXML para dotar al sistema de memoria y obtener así un diálogo más natural.

•= Esta misma falta de memoria hace que el sistema original sea rígido, en el sentido de que la incorrección de la en-trada (por ejemplo, por la ausencia de un parámetro) no permite estrategias de recuperación: el sistema simple-mente invalida toda la interacción con un mensaje de error. Aprovechando la capacidad de VXML es posible integrar mecanismos de recuperación de errores.

Tal como se ha comentado, el sistema presentado está en continua revisión. Por tanto, a falta de una versión estable y definitiva, no se ha realizado una evaluación exhaustiva de las prestaciones del mismo. Las pruebas de funcionamiento se han realizado de una manera más o menos informal, por lo que no han sido incluidas en este artículo.

8. Referencias [1] Allen, J., D. Byron, M. Dzikovska, G. Ferguson, L. Ga-

lescu, y A. Stent. 2000. An Architecture for a Generic Dialogue Shell. Natural Language Engineering. To ap-pear.

[2] Bernsen, N., Dybkjaer, H. and Dybkjaer, L. Designing Interactive Speech Systems. 1998. Springer-Verlag, ISBN 3-540-76048-2.

[3] Cardenal, A., Diéguez, J., García-Mateo, C., Fast LM Look-Ahead for Large Vocabulary Continuous Speech

Recognition using Perfect Hashing. 2002. Proceedings of the IEEE International Conference on Acoustic, Speech and Signal Processing (ICASSP 2002), pág. 705-708. Or-lando, USA.

[4] Cardenal López, Antonio, Realización de un Reconoce-dor de Voz en Tiempo Real para Habla Continua y Gran-des Vocabularios. 2001. Ph.D. tesis, Departamento de Tecnoloxías das Comunicacións, ETSE Telecomuni-cación, Universidade de Vigo.

[5] Convington, Michael A., Natural Language Processing for Prolog Programmers. 1994. Prentice-Hall.

[6] Fernández, X y Rodríguez, E. Segmental Duration Mod-elling in a Text-To_Speech System for the Galician Lan-guage. 1999. Proceedings of Eurospeech.

[7] Constantinides, P., Hansma, S., Tchou, C. and Rudnicky, A. A Schema-based Approach to Dialog Control. 1998. Proceedings of ICSLP, Paper 637.

[8] Hacioglu, K. and Ward, W. Dialog-Context Dependent Language Modeling Using N-Grams and Stochastic Con-text-Free Grammars. 2001. Proceedings of ICASSP, Salt Lake City.

[9] Pellom, B., Ward, W., Pradhan, S., The CU Communica-tor: An Architecture for Dialogue Systems. 2000. Interna-tional Conference on Spoken Language Processing (ICSLP). Beijing, China.

[10] Pérez-Piñar, D. Y García-Mateo, C. Integración Automá-tica de Fuentes de Conocimiento Lingüístico en el Desa-rrollo de Sistemas de Diálogo. 2002. XVIII Congreso de la Sociedad Española para el Procesado del Lenguaje Na-tural (SEPLN). Valladolidad, España.

[11] Rodríguez, E., Campillo, F., Fernández, E., Méndez, F., Sistema de Conversión Texto-Voz en Lengua Gallega Ba-sado en la Selección Combinada de Unidades Acústicas y Prosódicas. 2002. XVIII Congreso de la Sociedad Es-pañola para el Procesado del Lenguaje Natural (SEPLN). Valladolid, España.

[12] Rodríguez-Liñares, L. Un Sistema de Diálogo para la Consulta de Correo Electrónico en Lenguaje Natural. 2002. XVIII Congreso de la Sociedad Española para el Procesado del Lenguaje Natural (SEPLN). Valladolid, España.

[13] Rodríguez-Liñares, L., Cardenal, A., García-Mateo, C., Perez-Piñar, D., Rodríguez, E., Fernández, X., TelCo-rreo: A Bilingual E-mail Client over the Telephone. 2000. Proceedings of the Third International Workshop on Text, Speech and Dialogue (TSD 2000), pág. 381-386. Brno, Czech Republic.

[14] Rosenfeld, Ronald y Clarkson, Philip, CMU-Cambridge Statistical Language Modelling Toolkit v2. 1996.

[15] Rudnicky, A. and Xu, W. An Agenda-based Dialog Man-agement Architecture for Spoken Language Systems. 1999. IEEE Automatic Speech Recognition and Unders-tanding Workshop, pág. I-337.

[16] Xu, W. and Rudnicky, A. Language Modeling for Dialog System? 2000. Proceedings of ICSLP. Paper B1-0