Generación de lenguas basada en conocimiento lingüístico
65
0
0
Texto completo
(2)
(3) i. AGRADECIMIENTOS A mi familia. A mis amigos. A mis profesores..
(4) ii. RESUMEN El procesado de lenguaje natural es uno de los ámbitos de la inteligencia artificial más importante de cara a la interacción entre personas y máquinas. Para que esta interacción sea posible, hace falta que nuestro sistema sea capaz de comprender el lenguaje natural en un ámbito concreto y que además pueda generar respuestas en un idioma que entienda el usuario. En esta tesis se va a tratar sobre las aproximaciones que pueden tomarse para generar texto en lenguaje natural desde cualquier fuente de información, ya sea textual, numérica o de otro tipo. Para centrar el procesado de lenguaje en un ámbito concreto se hará una revisión del estado actual de los chatbot, un área de mucha atención recientemente que cubre todos los aspectos del procesado de lenguaje. Para aplicar las técnicas estudiadas, haremos una pequeña prueba de concepto con un chatbot acotado a un ámbito especı́fico. Con esto, se dará una idea de cuáles pueden ser algunas aproximaciones tanto a la comprensión como a la generación de lenguaje para resolver un problema concreto y se verán alternativas reales a la hora de crear un sistema conversacional..
(5) iii. SUMMARY Natural language processing is one of the most important subjects in artificial intelligence when dealing with machine person interaction. To make this interaction possible we need our system to be able to understand natural language in a given domain and to answer in a language that the user comprehends. In this thesis, we will go through the techniques that can be used to generate text in natural language from any source, be it textual, numeric or other kind. We will then focus natural language processing in the area of conversational systems. This kind of systems have got many attention in recent years and they serve as a great example of the whole process in NLP. Lastly, we will apply some of this methods in the creation of a chatbot in a specific domain. This way, we will have an idea of how can natural language understanding and generation be approached..
(6) iv. Índice 1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Estado del arte: . . . . . . . . . . . . . . . . . . . . . . . . 2.1. Natural Language Generation . . . . . . . . . . . . . . . . 2.1.1. Document Planner . . . . . . . . . . . . . . . . . . 2.1.2. Microplanner . . . . . . . . . . . . . . . . . . . . . 2.1.3. Surface Realizer . . . . . . . . . . . . . . . . . . . . 2.1.4. Evaluación . . . . . . . . . . . . . . . . . . . . . . . 2.2. Linguistic Descriptions of Data . . . . . . . . . . . . . . . 2.2.1. Computational Perceptions . . . . . . . . . . . . . 2.2.2. Perception Models . . . . . . . . . . . . . . . . . . 2.2.3. Evaluación . . . . . . . . . . . . . . . . . . . . . . . 2.3. Entornos de generación de lenguaje . . . . . . . . . . . . . 2.3.1. KPML . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2. SimpleNLG . . . . . . . . . . . . . . . . . . . . . . 2.3.3. OpenCCG . . . . . . . . . . . . . . . . . . . . . . . 2.3.4. rLDCP . . . . . . . . . . . . . . . . . . . . . . . . . 2.4. Sistemas conversacionales . . . . . . . . . . . . . . . . . . 2.4.1. Sistemas de diálogo . . . . . . . . . . . . . . . . . . 2.4.2. Sistemas conversacionales orientados a una función 2.5. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Planteamiento del problema . . . . . . . . . . . . . . . . . 4. Hipótesis de trabajo . . . . . . . . . . . . . . . . . . . . . 5. Resolución . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1. Recopilación de datos . . . . . . . . . . . . . . . . . . . . . 5.2. Base de datos . . . . . . . . . . . . . . . . . . . . . . . . . 5.3. Modelo de procesado de preguntas . . . . . . . . . . . . . . 5.3.1. Gramática libre de contexto . . . . . . . . . . . . . 5.3.2. Clasificación de queries y división en entidades . . . 5.3.3. Conclusiones y elección . . . . . . . . . . . . . . . . 5.4. Preproceso . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4.1. Simplificación de cadenas . . . . . . . . . . . . . . . 5.4.2. Tokenizado . . . . . . . . . . . . . . . . . . . . . . 5.4.3. Stopwords . . . . . . . . . . . . . . . . . . . . . . . 5.5. Gramática libre de contexto . . . . . . . . . . . . . . . . . 5.5.1. Producciones . . . . . . . . . . . . . . . . . . . . . 5.5.2. Parsing . . . . . . . . . . . . . . . . . . . . . . . . 5.6. Búsqueda de viviendas . . . . . . . . . . . . . . . . . . . . 5.6.1. Recorrido del árbol de derivación . . . . . . . . . . 5.6.2. Creación de las queries . . . . . . . . . . . . . . . . 5.7. Generación de respuestas . . . . . . . . . . . . . . . . . . . 5.7.1. Gramáticas de generación . . . . . . . . . . . . . . 5.7.2. Redes de Markov . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 1 2 2 3 4 6 7 8 10 11 11 13 13 15 17 18 19 20 22 30 31 33 34 34 35 35 36 37 37 37 37 38 38 39 40 40 41 41 42 43 44 46.
(7) v. 5.8. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.9. Etapa final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 6. Conclusiones y lı́neas futuras . . . . . . . . . . . . . . . . . . . . . . . 49.
(8) vi. Índice de figuras 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.. Framework de diseño de sistemas NLG propuesto por Reiter y Dale . Arquitectura de LDCP . . . . . . . . . . . . . . . . . . . . . . . . . . GLMP para describir la superficie de Marte [53] . . . . . . . . . . . . Especificación SPL de la frase ”La vida no es tan fácil como parece” . Especificación SPL multilı́ngüe de la frase El terremoto destruyó los edificios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Elementos sintácticos de una frase que SimpleNLG permite establecer Forma lógica del verbo ”buy” y representación de la frase ”Peter buys a bike” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Esquema de la arquitectura de un sistema conversacional. Adaptado de [64] para incluir los chatbots de lenguaje escrito . . . . . . . . . . Ejemplo mostrado en [60] de una base de conocimiento y un sistema de marcos para representar puntos de interés. . . . . . . . . . . . . . Posible estructura de control en base al ejemplo de marco en la figura 9 Ejemplo de un etiquetado IOB en una frase. . . . . . . . . . . . . . . Ejemplo de la interfaz de búsqueda de una casa a la venta en Madrid en Idealista. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Estructura de control de los estados posibles del chatbot. . . . . . . . Ejemplo del procesado de una pregunta al sistema. . . . . . . . . . . Vector generado de una derivación. . . . . . . . . . . . . . . . . . . . Ejecución del sistema y obtención de una respuesta segura. . . . . . . Ejemplo de no comprensión de una pregunta. . . . . . . . . . . . . .. 3 10 12 14 15 16 18 19 23 24 27 31 36 41 42 47 48.
(9) 1 Introducción. 1.. 1. Introducción. Cuando queremos desarrollar un sistema que pueda procesar lenguaje natural, uno de los problemas más importantes a los que solemos enfrentarnos es la dependencia del dominio que sufren. Estos sistemas están estrechamente relacionados con el tipo de frases que pueden comprender y el tipo de respuestas que saben generar. Las técnicas de comprensión (NLU ) y de generación (NLG) de lenguaje requieren un ámbito bien acotado para poder realizar funciones especializadas. Esto significa que es necesario tener una idea clara de cuál va a ser el tipo de lenguaje que se va a emplear para interactuar con el sistema, cuál es el problema que se va a tratar y qué tipo de respuestas se esperan de él. Esta es la causa de que cuando se quiere crear un sistema de procesado de lenguaje aplicado a un problema concreto, este sistema tiene que ser hecho a medida para la situación. Las técnicas y estrategias usadas para el procesado y la generación de lenguaje son aproximaciones que deberán ser amoldadas a nuestro caso. La comprensión y la generación suelen formar parte de un mismo sistema si se quiere hacer el ciclo completo desde la entrada de texto hasta la salida. Las técnicas de comprensión no son las mismas que las de generación pero en sentido inverso, ya que ambas abarcan tareas de diferente naturaleza. El procesado tiene que ver más con comprender el qué me están diciendo, es una tarea de interpretación, mientras que la generación debe elegir qué información devolver en forma de texto, es una tarea de decisión. Ambas tareas pueden aparecer juntas en un mismo sistema, como en el caso de los sistemas conversacionales, o puede aparecer sólo una de ellas, como los sistemas que realizan búsquedas especializadas en un entorno en base a una pregunta o los sistemas data2text, que generan texto en lenguaje natural a partir de una entrada que no es textual. Esta tesis tratará sobre la generación de lenguaje natural, y para ejemplificar su aplicación se creará un chatbot en un ámbito acotado. Esto implica que también se tendrá que emplear la comprensión en lenguaje natural, de la cual se tratarán algunas técnicas valoradas durante la implementación, pero no se tratará este ámbito de manera extensa en el estado del arte. En la siguiente sección se tratará de dar una visión general del ámbito de la generación de lenguaje y un enfoque hacia los chatbots. Más adelante, se describirá una pequeña prueba de concepto de un chatbot para aplicar algunas de las técnicas vistas. Se trataran diferentes alternativas consideradas a la hora de su creación, cómo fue el proceso y qué resultados se pueden extraer de él. Finalmente se extraerán las conclusiones finales de la tesis y las lı́neas futuras..
(10) 2 Estado del arte:. 2.. 2. Estado del arte:. El área del procesado de textos en lenguaje natural ha sido un área muy activa desde mediados del siglo veinte. Este ámbito comprende muchas áreas populares de investigación, como la generación de textos para describir imágenes, la traducción automática entre idiomas, la generación de resúmenes a partir de unos datos numéricos o los chatbots. El procesado de lenguage natural (NLP) se divide comunmente en dos áreas [48]: Natural Language Understanding (NLU) y Natural Language Generation (NLG). NLU es la rama de NLP que se centra en los sistemas cuya entrada son textos en lenguaje natural. La aproximación que se sigue en este ámbito es más bien de gestión: al recibir una entrada, el sistema tiene que decidir cuál de las múltiples interpretaciones que se le puede dar es la más apropiada. NLG se dedica a la transformación de información en diferentes medios a textos en lenguaje natural que sean comprensibles. En este caso, el problema que se afronta es el de elegir qué información presentar y de qué manera presentarla. El área del NLG está subdividida a su vez en ámbitos más pequeños que se centran en problemas más concretos: data-2-text [49] se centra en sistemas de NLG cuya entrada son datos numéricos con origen en sensores o tablas; NLG interactivo [56] se centra en la generación de texto mediante una interacción entre el interlocutor humano y el sistema, ya sea esta por medio de texto o de datos numéricos introducidos; o NLG narrativo que se centra en la generación de textos literarios en prosa o en verso [9]. Existe también el área de Linguistic Descriptions of Data, que ha coexistido con el data-to-text NLG sin mucha interacción entre ambos hasta hace poco tiempo [29]. También existen ámbitos complejos que mezclan tanto NLU como NLG, como en el caso de los traductores automáticos y los chatbots [32]. NLG y NLU están estrechamente relacionadas, pero sus diferencias van más allá de que el objetivo de una es el inverso de la otra.. 2.1.. Natural Language Generation. A pesar de que el área del NLG lleva muchos siendo desarrollada, no hay un estándar extendido en la comunidad y cuando se presenta un problema de NLG se suele aplicar una solución hecha a medida. Aún ası́, una de las arquitecturas más extendidas y reconocidas es la presentada por Reiter y Dale [48]. Esta arquitectura establece un pipeline con las tareas que los autores consideran indispensables a la hora de crear un sistema de NLG de cualquier subtipo. El proceso se distribuye en tres fases desde la entrada de una serie de datos del tipo que sean (textuales, numéricos, gráficos, ...) hasta la creación de un texto sobre ellos de las caracterı́sticas requeridas. De este modo, las tareas iniciales están más relacionadas con qué información se va a transmitir y las finales tratan el cómo de manera directa,.
(11) 2 Estado del arte:. 3. Fig. 1: Framework de diseño de sistemas NLG propuesto por Reiter y Dale eligiendo las expresiones que se van a usar y en qué orden colocarlas. Debido a esto, los módulos que se corresponden con estas tareas iniciales suelen ser los que hay que crear a medida para cada sistema, de tal forma que se adapte la extracción de información a nuestro dominio concreto y se defina una estructura del texto acorde con nuestro corpus o con nuestras necesidades, y los módulos finales de realización del texto final se pueden hacer con métodos y técnicas que se estudian con independencia del problema a mano. 2.1.1.. Document Planner. El primer módulo de esta arquitectura es el llamado Document Planner. Este se centra en los primeros pasos de identificar cómo se van a tratar los datos de entrada, qué se va a decir sobre ellos, y qué estructura va a seguir el documento final. Determinación del contenido. Esta subtarea se corresponde con el primer paso de decidir a partir de los datos de entrada qué información es relevante mencionar. Normalmente, estos contienen mucha más información de la que podemos comunicar o información que es redundante. Como ejemplo, un sistema meteorológico que recibe de entrada una tabla con las velocidades y direcciones del viento a diferentes horas del dı́a debe decidir qué momentos tratar en el informe meteorológico: tiene más sentido hablar sobre los momentos en los que habrá cambios en la dirección y velocidad del viento que tratar sobre cuando se mantiene constante [50]. Esta subtarea está profundamente relacionada con el dominio de la aplicación, ya que el análisis que tenemos que.
(12) 2 Estado del arte:. 4. realizar viene determinado por el tipo de entrada del que disponemos. Estructuración del texto. Una vez decidido qué información se va a transmitir, hay que ver en qué orden se va a presentar esta información. En el ejemplo meteorológico anterior, probablemente sea adecuado ir desde una descripción general del tiempo a primera hora del dı́a hasta la noche, marcando si fuese necesario horas clave como el mediodı́a. Esta ordenación se ve claramente restringida dependiendo de las necesidades del dominio, y en las ocasiones en las que se disponga de un corpus de textos previos hechos por humanos este punto suele incluı́r un profundo análisis de la estructura de estos. Este proceso ha sido realizado tradicionalmente de forma manual, pero también se han probado aproximaciones desde la aplicación de la retorical structure theory (RST) [39] para generar estructuras de textos por medio de reglas basadas en el domino, que consigan objetivos concretos como la facilidad de comprensión [62], o la aplicación de técnicas de aprendizaje automático para inferir posibles estructuras [1]. 2.1.2.. Microplanner. Tras este proceso se obtiene una planificación del documento a gran escala, por lo que el siguiente paso es el de decidir cómo van a ser las frases concretas que se van a utilizar en cada párrafo para transmitir la información que se ha decidido previamente. Las subtareas que lo componen no tienen un orden fijo, y en ocasiones el resultado de una de ellas es útil para otra, por lo que se realizarán según requiera nuestro dominio o nuestra implementación. Agregación de frases. Cuando generamos el texto que tenemos planificado desde la fase anterior, no siempre es necesario generar frases diferentes para cada fragmento de información que queremos transmitir. En muchas ocasiones el resultado es más fluido y comprensible si combinamos varios mensajes en una sola frase [17]. El objetivo de esta agregación puede verse como una reducción de la redundancia final de la frase o como la reordenación estructural del texto para facilitar su lectura y comprensión. El problema es que estos objetivos son dependientes del dominio en el que nos encontremos: decir en tres oraciones seguidas la temperatura ambiente en un intervalo de tres horas cuando esta sólo ha variado unos pocos grados puede ser redundante para una previsión temporal de todo el dı́a, pero puede no serlo para una previsión temporal de un intervalo concreto de 5 horas del dı́a. Por este motivo, la creación de reglas para la agregación de frases tradicionalmente se ha hecho a medida para cada dominio o aplicación [17]. Sin embargo, se ha avanzado gradualmente hacia la generación automática de estas reglas de agregación a partir de un corpus del que sacarlas en base a la similaridad de unas frases y otras [11]. También se ha tratado el problema como uno de optimización, clasificando frases en parejas para determinar si deberı́an ser agregadas entre sı́ o no según su similaridad [2]..
(13) 2 Estado del arte:. 5. Lexicalización. Esta es la fase del proceso en la que se empieza a generar texto en lenguaje natural a partir de las estructuras que tenemos de etapas anteriores. La dificultad de esta generación está estrechamente relacionada con la cantidad de alternativas que nuestro sistema es capaz de manejar para un mismo suceso: en un sistema sencillo de plantillas se puede hacer una simple asignación de un suceso a una expresión, pero la lexicalización se complica si queremos que nuestro sistema sea capaz de generar varias frases diferentes atendiendo a matices, por ejemplo de quién lo va a leer [62] o de qué expresiones son menos ambiguas [50]. La complejidad buscada en la lexicalización viene muchas veces dada por el dominio en el que se trabaja: si se tienen ya establecidas una serie de expresiones con un significado claro, normalmente sacada de un corpus previo o de expertos en la materia, es muy probable que en un dominio donde se quiere maximizar la claridad del texto se usen estas expresiones, pero si para un mismo suceso existen varias formas aceptadas de expresarlo que sean sinónimas entre sı́ y la variedad léxica es apreciada, habrá que buscar matices que las distingan a un nivel más profundo. Generación de referencias. Esta parte del proceso se centra en la generación de expresiones para referirse a entidades o sucesos concretos y diferenciarlos del resto. Esta subtarea, conocida en la literatura como Referring Expression Generation (REG), es una de las que más pueden abstraerse para poder ser tratada por separado, una de las razones por la cual ha recibido bastante atención como subcampo dentro del NLG [34]. Un caso representativo que está siendo investigado en gran medida es la generación de textos que describan imágenes de manera automática. En estos casos, es necesario reconocer los objetos o seres que aparezcan en la imagen y diferenciarlos claramente unos de otros al describir la escena. En la mayorı́a de sistemas de NLG suele haber un módulo de REG con mayor o menor nivel de sofisticación [40]. El problema de REG suele ser abordado desde el punto de vista de qué caracterı́sticas posee una entidad que puedan diferenciarla unı́vocamente de otras entidades similares, por lo que los algoritmos clásicos consisten en búsquedas heurı́sticas en el espacio de soluciones para encontrar este conjunto de caracterı́sticas: realizando búsquedas exhaustivas del conjunto más pequeño posible (Full Brevity) [16], seleccionando incrementalmente (greedy forward) propiedades que reduzcan en mayor medida la entropı́a [16] o seleccionando incrementalmente propiedades en base a un criterio de importancia relacionado con el dominio [15]. En los últimos años se ha invertido mucho esfuerzo en desarrollar nuevos algoritmos de REG desde puntos de vista nuevos de búsquedas en grafos, satisfacción de restricciones, probabilı́stico o con representaciones del conocimiento modernas, además de sus diferentes métodos de evaluación de las alternativas generadas [34]..
(14) 2 Estado del arte:. 2.1.3.. 6. Surface Realizer. Una vez que ya hemos comletado las fases anteriores tenemos la estructura del texto que vamos a generar y las frases que vamos a utilizar, hay que generar las oraciones en lenguaje natural finales del texto. Aunque hayamos decidido ya cómo van a ser estas oraciones en el microplanner, necesitamos una serie de reglas gramaticales para generar textos que sean sintactica y morfológicamente correctos. Hay un gran número de formas diferentes de tratar esta tarea [22], de las cuales resaltaremos: Plantillas. Las plantillas son un método muy eficaz en dominios muy concretos donde la variabilidad de los textos a generar es muy baja [57]. Usar plantillas hace que los textos generados tengan una estructura muy controlada donde no se permita la generación de frases con errores gramaticales. Dependiendo de la sofisticación de estas, se pueden generar diferentes reglas para la introducción de datos en ellas o la variación de las plantillas en base a los lectores [50]. El principal problema de las plantillas tradicionalmente ha sido que su creación es un proceso costoso hecho a mano, aunque hay casos en los que se generan estas plantillas automáticamente a partir de un corpus [33]. Además, en entornos más abiertos donde las frases a generar no sean siempre iguales con diferentes datos de entrada los métodos con plantillas no escalan bien. Aún ası́, en los dominios donde son aplicables consiguen resultados muy buenos, en ocasiones equiparables con textos escritos por humanos. Sistemas basados en gramáticas. A lo largo de los años han ido apareciendo sistemas de uso general independientes del contexto que permiten la generación de lenguaje natural. Estos suelen basarse en una gramática escrita a mano donde establecen la estructura de las oraciones del lenguaje con el que se trabaja. Esta gramática es la que se usa para generar frases en base a los componentes que queremos que tenga, pero es necesario establecer reglas manuales para concretar qué frase generar en un contexto donde varias son posibles, por ejemplo, reordenando los complementos verbales. Es por esto que estos sistemas suelen requerir una entrada muy detallada en el lenguaje de programación que usen, por lo que requieren un tiempo para adaptarse a ellos. Como estos sistemas tienen su gramática hecha a medida para el idioma con el que se crearon, es necesario adaptarlos si se quieren usar en idiomas distintos [55]. Algunos ejemplos de estos sistemas que se tratarán más adelante son KMPL [3] o SimpleNLG [23]. Sistemas basados en gramáticas y métodos estadı́sticos. La base de este tipo de sistemas sigue siendo una gramática hecha a mano para generar frases a partir de la entrada proporcionada, pero en estos casos parte de las reglas que se usan para elegir entre diferentes frases posibles dada una entrada se sacan de un corpus de previo de manera automática y se usan métodos estadı́sticos para elegir entre las posibilidades disponibles. La primera aproximación que se hizo a este tipo de sistemas fue Nitrogen / HALogen [35], donde se parte de la base de una pequeña gramática hecha a mano de la que se genera una serie de frases.
(15) 2 Estado del arte:. 7. en forma de árboles de entre las que se hace un ranking basado en un corpus y n-gramas para seleccionar la más apropiada. Otra aproximación se basa en guiar la generación de frases desde la gramática hasta un candidato “óptimo” en vez de generar una gran cantidad de ellos y filtrar el más adecuado. Un ejemplo de esta aproximación es pCRU [5], donde se utiliza un corpus para derivar a partir de una gramática libre de contexto la frase más adecuada. También hay casos en los que tanto la generación de frases como el filtrado de las mismas se realiza de manera atomática, como en el caso de OpenCCG [61], un generador de texto open source que utiliza un corpus para generar una serie de reglas combinatorias para la creación de frases con la gramática y después realiza un re-ranking automático. Últimamente, la investigación se ha centrado más en estos métodos relacionados con machine learning que con las tradicionales plantillas, siendo aproximaciones como SimpleNLG también bastante populares por su facilidad de uso. Lo más común es que, en los casos de la aplicación de este framework [13], no se sigan en orden todos los pasos establecidos, se mezclen unos pasos con otros o se junte este framework con otro distinto. Su idea principal no es mostrar un camino estricto hacia la solución de problemas de NLG, sino que se adapte esta arquitectura a las necesidades de cada situación. Desde la creación de los primeros sistemas de NLG por plantillas, estos han sido aplicados a un gran número de ámbitos especializados diferentes, como en el caso de las previsiones temporales con FoG [24] o SumTime-Mousam[50], la generación de texto en casos médicos concretos como [45], sistemas de ayuda a la gestión del consumo eléctrico [13], generación de descripciones del funcionamiento de sistemas en un intervalo de tiempo [65], etc. En el caso de estos sistemas, su aplicación en ámbitos tan especı́ficos da pie a que esta arquitectura por plantillas sea muy potente. Esto ocurre porque el rango de frases a generar está bien definido y debe ceñirse a un esquema que es normalmente proporcionado por un corpus inicial de textos, aunque también hay casos en los que no se tenı́a un corpus inicial [65]. Es un tema discutido en la literatura [18, 51] el si los sistemas tradicionales de NLG son o no más eficaces que los basados en plantillas. Se discute sobre si uno de los dos es más fácil de mantener a largo plazo o si genera textos mejor estructurados y de más calidad, pero no está claro que una aproximación sea mejor que la otra. 2.1.4.. Evaluación. La creación de estos sistemas tiene en común que son proyectos de ingenierı́a del software de un tamaño considerable. Por ello, uno de los puntos que son de mayor importancia es la evaluación de los textos que resultan de ellos. Muchos investigadores dedican un gran esfuerzo a comprobar que sus textos automatizados son igual o más comprensibles que los hechos a mano. Hay bastante debate entorno a cómo realizar evaluaciones de sistemas de NLG, pero podemos distinguir dos tipos de evaluaciones en la literatura [4]: las llevadas a cabo con evaluadores humanos y.
(16) 2 Estado del arte:. 8. las realizadas por métricas automáticas. En los casos en los que se tienen evaluadores humanos [50, 65], esta evaluación de lleva a cabo con los autores originales de los textos que se está intentando automatizar (si los hubiera) y con los lectores a los que van dirigidos dichos textos con cuestionarios que buscan obtener notas numéricas sobre su facilidad de comprensión, sobre si los términos utilizados son del agrado del lector o sobre si se trata bien la ambigüedad, entre otros. Esto se conoce como evaluación intrı́nseca [27], y da una idea de la calidad de los textos que genera el sistema. La evaluación extrı́nseca se realiza para ver cómo de efectivo es el sistema, ya sea para ver el impacto de los textos generados en los lectores [52, 63], la velocidad a la que se leen los textos [62], o si los idiolectos usados por algunos autores ayudan o dificultan la comprensión final [50]. Por otro lado, la evaluación por medio de métricas se basa en la comparación de los textos generados con los textos de un corpus hecho por autores humanos antes de la implementación del sistema NLG. Tres de las métricas más conocidas son: Bleu [44], Nist MT [20] y Rouge [38]. Estas, inicialmente ideadas para comprobar la bondad de las traducciones automáticas, se basan en comparar la similitud de los textos producidos por sistemas de NLG con corpus de textos generados por humanos previos a la implementación del sistema: a mayor similaridad con el corpus, de mayor calidad son los textos generados. De entre ellos, Bleu es el que parece tener más correlación entre su ı́ndice de bondad y las evaluaciones por humanos [4], aunque no en todos los casos. Estos métodos son fáciles de aplicar y mucho más rápidos que hacer evaluaciones con humanos, pero sufren de dos problemas: su aplicación sólo es posible cuando se dispone de un corpus, lo cual no siempre ocurre, y sus métricas sólo miden la similaridad entre los textos del corpus y los generados. El consenso general es que realizar evaluaciones con expertos humanos ofrece una información de más calidad acerca de lo bueno que es el sistema, pero no siempre es fácil ni barato juntar un grupo de expertos, y su evaluación es sólo válida en el momento en el que se realiza. En contraposición, las evaluaciones automáticas ayudan a ver el progreso de un sistema en el tiempo de manera rápida y barata, pero no son un medio adecuado para medir la calidad final del sistema en comparación con otros. Finalmente, cabe destacar que los sistemas de NLG suelen ser sistemas de un dominio muy especializados y que generan textos que pueden ser intercambiados con otros hechos por humanos sin mayor problema. Sin embargo, la creación de dichos sistemas deriva en proyectos grandes en los que normalmente se parte de una base meramente teórica: la explicación de las implementaciones detrás de los sistemas de NLG de la literatura es, cuanto menos, vaga. Por tanto, si se quiere implementar un sistema de este tipo, se tendrá que partir desde cero o reusar alguno de los framework de uso general de NLG que existen, de los cuales se hablará más adelante.. 2.2.. Linguistic Descriptions of Data. Aparte de las aproximaciones mencionadas anteriormente del Surface Realizer en NLG, existe también el área de LDD como opción adicional, aunque ha convivido bastante tiempo con el NLG sin mucha interacción entre ambas a pesar de que.
(17) 2 Estado del arte:. 9. investigan temas similares. La idea inicial de LDD aparece a mediados de los 90, cuando se trata de juntar el área de la lógica borrosa con la generación de lenguaje. Esto se presenta dentro del paradigma de Computing with Words (CWW), donde la información que queremos tratar se encuentra en forma de textos y no de manera numérica. Además, el lenguaje natural acepta bien el uso de inexactitudes a la hora de presentar información, por lo que la lógica borrosa es aplicable en estos casos. Uno de los primeros y el que sentó las bases de lo que se usarı́a más adelante fue Zadeh [66]. La idea principal de su trabajo se basa en construir resúmenes ligüı́sticos a partir de unos cuantificadores borrosos que son los que contienen la información que se quiere transmitir. Por ejemplo, de la fórmula “Q of X are A”, se puede sacar la frase “Most of the days of the week are rainy”, donde el cuantificador borroso Q contiene la información extraı́da de los datos de entrada, X define el elemento del que se está hablando y A constituye la caracterı́stica que se está resumiendo en el conjunto total [13]. Este tipo de fórmula, protoform en la literatura, son una de las bases que permiten la creación de frameworks de LDD. Sin embargo, como apunta Kacprzyk [29], hay una escasez de estos protoforms y la creación de nuevos y más complejos darı́a más capacidad a los sistemas de LDD para generar textos más complejos. En LDD tampoco hay un consenso en cuanto a cómo crear sistemas para resolver problemas concretos. Sin embargo, el objetivo que hay que cumplir es el de realizar resúmenes lingüı́sticos de unos datos de entrada por medio de cuantificadores borrosos. Esta tarea es parecida a la de concretar el qué se va a decir y el cómo se va a decir de NLG. En este caso y basándonos en el ejemplo expuesto antes, necesitamos una serie de cuantificadores borrosos que se encarguen de exponer la información, como en el caso de “most”, “all of ”, “some”, y una serie de variables que se refieran al entorno en el que estamos, en nuestro ejemplo de la meteorologı́a “rainy”, “cloudy” o “sunny”. Todos estos elementos en conjunto forman sentences, que pueden ser de tipo-I como en el caso de “Most of the days of the week are rainy” o pueden ser de tipo-II si se les añade una segunda variable o una referencia temporal a información mencionada antes, como en “Most of the days of the week, as in the last one, are rainy and cold” [42]. Como la implementación de estas “quantified sentences” está basada en las técnicas de la lógica borrosa, su creación puede verse como un problema de búsqueda en un espacio de soluciones: dada la estructura de tipo-I “Q of X are A”, hay que asignar un valor a la variable A para saber qué es lo que se va a hablar en la frase y hay que dar valores concretos a Q, dentro de un conjunto cerrado borroso, y a X, de manera que generaremos una cierta cantidad de frases y nos quedaremos con las que maximicen un criterio de evaluación, teniendo en cuenta aspectos como la veracidad de la frase generada, su comprensibilidad o su redundancia con frases anteriores. Este funcionamiento hace que la aproximación de LDD esté más basada en teorı́a matemática y de machine learning que la de NLG, aunque a la hora de aplicar ambas los resultados son bastante parecidos y últimamente ambas aproximaciones se han acercado en cuestión de las técnicas y métodos empleados. La generación de frases en LDD, como apunta Kacprzyk [29], se asemeja a los sistemas de NLG que.
(18) 10. 2 Estado del arte:. emplean plantillas, aunque él alude a los protoforms como “metatemplates”, dado que tienen una capacidad de generación más grande que las plantillas tı́picas de NLG. Es importante resaltar en este punto que, aunque este esquema tiene su investigación sobre la base del inglés, es posible usarlo también en otros idiomas como el español [47]. De la misma forma que ocurre en NLG, tampoco existe un framework en LDD que sea el estándar a usar de cara a un problema. Recientemente, se ha usado el modelo de Linguistic Descriptions of Complex Phenomena (LDCP) para solucionar varios tipos de problemas diferentes, como la generación de textos para el ahorro de energı́a [13], la generación de textos describiendo la actividad de uso de un simulador de conducción[21] o la generación de informes en un entorno de Big Data en base al usuario al que va dirigido [12], por lo que esta aproximación es lo más cercano a un framework general que hay en el ámbito.. Fig. 2: Arquitectura de LDCP La arquitectura de LDCP se basa principalmente en dos componentes: el Granular Linguistic Model of Phenomena (GLMP) y la plantilla del informe. El primer paso del proceso es el que se corresponderı́a con el document planning en cuestiones de la determinación del contenido y del filtrado inicial de los datos de entrada del modelo NLG de Reiter y Dale. El módulo del GLMP es el encargado del uso de los conjuntos borrosos para la interpretación de los datos de entrada y su aplicación para completar los informes. El último paso de generación del informe coincidirı́a con la parte de microplanner y realización lingüı́stica. Ambos modelos comparten puntos en común, pero LDCP se basa más en la interpretación de los datos de entrada con el módulo de GLMP y se apoya en las plantillas de generación que hay que completar. El funcionamiento del GLMP está basado en dos componentes, las computational perceptions (CP) y los perception models (PM)[12]. 2.2.1.. Computational Perceptions. Son pequeños fragmentos lingüı́sticos que explican con diferente nivel de detalle una parte del suceso del que se habla. Están formados por la tupla (A, W, R) donde: A = (a1 , a2 , ..., an ) es un vector de n cuantificadores que representen todo el dominio del que se está hablando, en el ejemplo previo serı́a el caso de (none, some, most, all)..
(19) 2 Estado del arte:. 11. W = (w1 , w2 , ..., wn ) es un vector de los grados de validez en [0, 1] de cada uno de los cuantificadores anteriores asignado en el contexto de cada CP. La suma total de todos debe ser 1. R = (r1 , r2 , ..., rn ) es un vector que indica en nivel de relevancia en [0, 1] de cada uno de los cuantificadores. El nivel de relevancia indica, en el contexto de la CP, qué cuantificadores son más importantes a la hora de ser interpretados por el lector. En este caso, la suma total no tiene por que sumar 1. 2.2.2.. Perception Models. Son nodos que reciben una o mas CP’s y mediante una función de agregación generan CP’s de un mayor nivel. Los PM’s son los puntos donde se genera el texto que constituye las CP’s y por consiguiente el texto final del sistema. Las PM están compuestas por la tupla (U, y, g, T ) donde: U = (u1 , u2 , ..., un ) es un vector de n CPs de entrada. En las PM de primer nivel (1PM) U es un vector numérico con datos procedentes de alguna fuente, como sensores o tablas. y = (Ay , Wy , Ry ) es la CP resultante. g es la función de agregación utilizada para generar y a partir de las CP de entrada U . Para las 1PM, se usan funciones de pertenencia triangulares o trapezoidales normalmente [41]. T es un algoritmo de generación de texto. En los casos más simples, se trata de plantillas en las que se introducen los cuantificadores más adecuados según las CPs agregadas. Los trabajos que implementan este modelo son bastante precisos en cuanto a cómo están implementadas sus GLMP’s y las funciones de agregación que constituyen cada PM. Esto es uno de los puntos de mayor diferencia con respecto a NLG, donde las implementaciones del Surface Realizer son bastante vagas, centrándose más en el proceso de ingenierı́a del software y en el modelo seguido. (Otras aproximaciones a la generación de quantified sentences. Prog. evolutiva? Gramáticas?) 2.2.3.. Evaluación. Dado que la aproximación inicialmente es desde la generación de múltiples frases a partir de las variables y las protoformas disponibles en cada PM, se necesitan métricas de evaluación para ver cuál de las frases generadas es más adecuada que las demás. Estas métricas también pueden ser interpretadas como una medida de lo bien que cumplen su función los textos generados por el sistema, en contraposición a la evaluación humana llevada a cabo en NLG. Algunos de los criterios utilizados son [30] [12]:.
(20) 2 Estado del arte:. 12. Fig. 3: GLMP para describir la superficie de Marte [53] Grado de veracidad. Al elegir entre distintos cuantificadores borrosos, en base a los datos de entrada unos serán más ciertos que otros conforme a lo que dicten las funciones de pertenencia y de agregación de las PM. La veracidad viene representada explı́citamente en las CP. Grado de relevancia. Algunos cuantificadores borrosos son más relevantes para los lectores de los textos finales en determinados dominios, por lo que puede ser preferible una frase con un cuantificador que, aunque sea menos adecuado que otro en función de los datos, sea más importante para los lectores. La relevancia viene representada también de manera explı́cita en las CP. Longitud del texto. En base a lo largo que se quiere que sea el texto final, puede ser preferible meter más información en una CP de mayor nivel que dividirlo en dos CPs de menor nivel. Grado de cobertura. Conforme limitamos el tamaño de los textos a generar, limitamos también la cantidad de información que transmitimos con ellos. Si exigimos que los textos generados sean muy cortos, tendremos que dejar fuera CPs que cubran partes del texto que consideremos menos relevantes. Grado de borrosidad. Conforme se van añadiendo más cuantificadores borrosos al texto en vez de datos exactos, el resultado tiende a ser cada vez más cierto en cuanto a la veracidad de la información transmitida, pero cada vez es más difı́cil de interpretar al ser más inexacto. Por ejemplo, “Most of the days.
(21) 2 Estado del arte:. 13. during summer will be rather cold” es cierto para muchos valores distintos de dı́as y temperaturas, pero frases como “Most of the days during summer will have temperatures around 33 degrees celsius” son menos ambiguas y tienen un grado de veracidad menor. Ajustando la relevancia que le damos a cada uno de estos parámetros, o cuáles de ellos empleamos, modificaremos el funcionamiento de nuestro sistema LDD y por consiguiente los textos que obtendremos. Además, la evaluación final de los textos se está empezando a hacer con evaluación humana como en NLG [21], por medio de cuestionarios para evaluar puntos que no pueden ser medidos con métricas automáticas como lo bien que se entienden los resúmenes generados, las palabras que cambiarı́an los previos escritores de dichos resúmenes o las preferencias de los lectores entre los textos previos a la implementación del sistema y los generados después. Este tipo de evaluación, aunque más costosa, da una idea clara de la calidad de los textos del sistema y de qué elementos habrı́a que mejorar en caso de un rendimiento subóptimo.. 2.3.. Entornos de generación de lenguaje. Como comentábamos anteriormente, a la hora de llevar a cabo la tarea del surface realizer existen dos aproximaciones comunes: la creación de un generador de lenguaje a medida, como en el caso de las plantillas o de sistemas con su propio generador con gramáticas, o emplear un entorno de uso general de generación de lenguaje. Estos entornos suelen ser aplicables a gran variedad de dominios, pero también suelen tener una sintaxis estricta para poder afrontar el problema de la ambigüedad a la hora de generar frases. Esta sintaxis es diferente de un entorno a otro y se requiere de una buena documentación para poder empezar a familiarizarse con ella. 2.3.1.. KPML. Uno de los primeros entornos de generación de lenguaje que aparecieron fue KPML, desarrollado por Bateman en 1997 [3]. La idea de este entorno fue concebida en un principio como un entorno multilingüı́stico, donde fuese posible representar diferentes idiomas sin necesidad de generar textos y después traducirlos. Este entorno proporciona dos modos de uso: por una parte ofrece gramáticas de varios idiomas y un sistema de caja negra, de tal forma que es posible utilizarlo como un módulo al que se le hacen queries con las especificaciones semánticas de las frases que se van a generar, y por otra parte proporciona una herramienta con la que poder crear nuestra propia gramática y diccionario adaptado a nuestro ámbito. Esta última herramienta es útil a la hora de generar nuestros propios recursos léxicos y es necesaria si la gramática de ámbito general y el diccionario que se distribuyen con KPML no son suficientes para el sistema que queramos desarrollar. Para que KPML pueda generar texto, además de una gramática es necesario proporcionarle una entrada semántica con la especificación de dicha frase en Sentence Plan Language (SPL) [31]. Las especificaciones con SPL utilizan una jerarquı́a de tipos semánticos llamada Upper.
(22) 2 Estado del arte:. 14. Model. Estos tipos semánticos son los que permiten acotar el dominio de la gramática a un ámbito especı́fico.. Fig. 4: Especificación SPL de la frase ”La vida no es tan fácil como parece” En la especificación SPL descrita en la Fig. 4, los tipos semánticos en este caso serı́an Property-Ascription, Thing o Quality. Estos tipos tendrán unas propiedades diferentes y generarán estructuras distintas dependiendo de la gramática que se use. Ası́ mismo, los tipos que definamos los podemos adecuar al tipo de frases que queremos generar en nuestro sistema. Los elementos semánticos de la frase vienen definidos como variables, en este caso LIFE, EASY y SEEM, las cuales pertenecen a un tipo semántico y heredan sus propiedades. De estas propiedades, :lex es la que otorga una raı́z concreta a los elementos para que puedan ser conjugados o flexionados. El núcleo de generación de frases de KPML está programado en ANSI standard Common Lisp, y este funciona construyendo una red a partir de la gramática proporcionada. Moviéndose en esta red de izquierda a derecha se genera texto para cada elemento de la especificación. Los nodos de la red representan disyunciones en los elementos a generar. Estas disyunciones requieren un módulo de decisión para elegir la definición final de cada elemento gramatical. Estas decisiones sólo se toman una vez para cada elemento, sin back tracking, y la elección de un elemento puede traer consigo restricciones para el resto de elementos. Uno de los puntos que hacen a KPML diferente del resto de entornos de generación es su capacidad para la multilingualidad. Si se le proporcionan al entorno múltiples gramáticas en diferentes idiomas, este permite la generación de textos en varias lenguas. El problema es que es difı́cil que la representación SPL sea la misma para todas las gramáticas, ya que los mismos verbos en diferentes idiomas pueden.
(23) 2 Estado del arte:. 15. comportarse de manera distinta y requerir diferentes atributos en sus tipos semánticos. En estos casos, es común que las redes de las gramáticas de dos idiomas se superpongan en algunos puntos, permitiendo similitudes en la representación SPL conjunta de una frase, pero necesitando diferenciarse.. Fig. 5: Especificación SPL multilı́ngüe de la frase El terremoto destruyó los edificios En el ejemplo multilı́ngüe de la Fig. 5, en inglés el terremoto es el sujeto de la frase y el que destruye los edificios, mientras que en japonés el sujeto es el edificio y es el que es derrumbado por el terremoto. Ambos sustantivos, el terremoto y el edificio, son variables que pueden ser reutilizadas en la especificación de las frases y a las que se les pueden añadir atributos, pero ambos idiomas tienen formas no muy relacionadas entre sı́ de representar un mismo suceso. En idiomas más cercanos entre sı́, la cantidad de información común es mayor y necesita menos diferenciación. 2.3.2.. SimpleNLG. Este motor de generación de lenguaje fue creado en 2009 con el objetivo de servir como entorno de generación multipropósito especialmente para la realización de resúmenes data-to-text de grandes cantidades de datos numéricos teniendo en cuenta las necesidades del lenguaje que cada dominio concreto puede tener [23]. SimpleNLG está codificado como una librerı́a de Java, de tal forma que la creación de un módulo de generación de lenguaje pueda ser un proceso accesible a cualquier proyecto. Para crear frases con SimpleNLG, el elemento que funciona como una oración es SPhraseSpec, al cual se le van estableciendo en sus atributos los distintos elementos sintácticos que queremos que tenga la frase. Uno de los objetivos de este entorno es permitir la facilidad de generar texto “enlatado”, inmutable dentro de las frases, de manera que las partes de las frases que sean escritas siempre igual dada una entrada puedan establecerse de este modo invariablemente y aquellas otras partes que requieran más flexibilidad puedan usar la aproximación anterior. Esto implica que tanto frases enteras como complementos de estas pueden ser indicados como texto enlatado. Como en todos los entornos de NLG, para que la generación de texto funcione es necesaria una serie de recursos léxicos además de las reglas de generación. SimpleNLG tiene un diccionario por defecto para permitir la flexión de las palabras en función de las caracterı́sticas que se les den, como el número o el tiempo verbal. Este diccionario, escrito en XML, puede ser modificado o sustituido por otros, como el.
(24) 2 Estado del arte:. 16. Fig. 6: Elementos sintácticos de una frase que SimpleNLG permite establecer NIH Specialist Lexicon 1 , más orientado al dominio médico y con mayor cobertura general. Para crear una estructura sintáctica completa, hay que generar los elementos sintácticos que necesitemos, asignar sus atributos y combinar estos elementos entre sı́ con las operaciones que ofrece la interfaz. Al generar una frase, lo más probable es que haya varias especificaciones para ella dependiendo de cómo se convienen unos elementos con otros o de cómo se declaren los atributos de los mismos. Tras la declaración de la estructura sintáctica, esta se pasa al lineariser, el cual recorre los componentes de la oración generando las flexiones adecuadas, decidiendo el orden de los complementos y aplicando la puntuación necesaria. La generación de texto a partir de los componentes está pensada para que sea robusta, de tal forma que genere texto aún si hubiese problemas con la estructura sintáctica. SPhraseSpec p = n l g f a c t o r y . c r e a t e C l a u s e ( ) ; p . s e t S u b j e c t ( ”Mary” ) ; p . setVerb ( ” chase ” ) ; p . s e t O b j e c t ( ” th e monkey” ) ; // Mary c h a s e s t h e monkey p . s e t F e a t u r e ( F e a t u r e . TENSE, Tense . PAST ) ; // Mary c h a s e d t h e monkey p . s e t F e a t u r e ( F e a t u r e .NEGATED, true ) ; // Mary d i d n ’ t c h a s e t h e monkey p . addComplement ( ” very q u i c k l y ” ) ; // Mary d i d n ’ t c h a s e t h e monkey v e r y q u i c k l y S t r i n g output = r e a l i s e r . r e a l i s e S e n t e n c e ( p ) ; SimpleNLG es un generador de texto fácil de usar pero menos potente que otros generadores como KPML, sin embargo una de sus principales ventajas es que está en continuo desarrollo 2 . Su comunidad sigue sacando versiones nuevas y aplicándolo en 1 2. https://lexsrv3.nlm.nih.gov/LexSysGroup/Projects/lexicon/current/web/ https://github.com/simplenlg/simplenlg.
(25) 2 Estado del arte:. 17. nuevos proyectos. Aunque su aplicación objetivo no sean sistemas de NLG complejos, cumple su función de servir como módulo de generación de lenguaje en aplicaciones que lo requieran. Además, un último punto importante es el esfuerzo que ha puesto esta comunidad en sacar versiones de SimpleNLG en idiomas distintos del inglés, como francés, alemán, italiano y español [55]. 2.3.3.. OpenCCG. Este es otro generador implementado como un paquete de Java pero, a diferencia de SimpleNLG, utiliza un esquema basado en las Combinatory Categorial Grammars (CCG) de Steedman para la generación de lenguaje [61]. Estas gramáticas vienen definidas por un diccionario cuyas entradas son elementos léxicos pertenecientes a distintas categorı́as en los cuales se establece los atributos que pueden tener. Una representación de los elementos de la frase “A musician that Bob saw” podrı́a ser: a. b. c. d. e.. a :− np/n m u s i c i a n :− n t h a t :− ( n\n ) / ( s | np ) Bob :− np saw :− s \np/np. En el ejemplo de elementos léxicos anterior, cada elemento tiene definida una categorı́a, n o np en este caso. Las barras indican si el elemento tiene atributos a la izquierda (\) o a la derecha (/). Este diccionario en combinación con una serie de reglas de derivación que combinen las categorı́as permite emplear las CCG para realizar parsing de oraciones e identificar los componentes de los mismos. A la hora de la generación de lenguaje, para decidir la posición de los elementos de la frase si hay varias opciones utiliza una aproximación estadı́stica en base al corpus de derivaciones que tenga. OpenCCG se baso en el corpus de derivaciones sacadas del Penn Treebank [26] para crear la gramática de uso general que tiene por defecto. Si se quiere crear o modificar la gramática existente, aunque el entorno sea un paquete de Java da la opción de codificar esta con XML o con un pseudocódigo parecido a Java o C, de modo que no es necesario tener conocimientos de Java para usar OpenCCG. Con estos recursos léxicos, ofrece herramientas tanto para el parsing como para la generación de lenguaje. En el caso de la generación de lenguaje, en vez de reconocer la estructura, las frases deben ser especificadas como como formas lógicas, que son representaciones semánticas de las frases [6]. Cada categorı́a sintáctica requiere una forma lógica para describir su interacción con el resto de palabras de la frase, y después hay que generar la representación de la frase que queremos. OpenCCG es un entorno de parsing y generación potente, pero requiere un conocimiento amplio de las CCG para generar los recursos léxicos necesarios y la generación de lenguaje necesita manejar las especificaciones de frases con las formas lógicas. El diccionario y la gramática que viene por defecto son adecuados para un uso en un dominio general, pero en casos más especı́ficos serı́a necesario ampliarlos. Existen varios recursos disponibles para la creación de gramáticas [8] y el código está.
(26) 2 Estado del arte:. 18. Fig. 7: Forma lógica del verbo ”buy” y representación de la frase ”Peter buys a bike” abierto para su uso 3 , gracias a lo cual se ha mantenido el entorno y se ha empleado en varios sistemas. 2.3.4.. rLDCP. Este entorno fue desarrollado como un generador de lenguaje basado en el esquema de LDCP[14], del cual es el único entorno de uso general. Está implementado como una librerı́a de R open source 4 . Para codificar el sistema LDCP que queremos crear permite hacerlo por medio de XML y después se realiza un parsing a código en R, o se puede codificar ı́ntegramente en R5 . Este entorno facilita la creación de los dos elementos básicos en la arquitectura LDCP: el GLMP y la plantilla de generación de los informes. La mayor parte de las operaciones del entorno están relacionadas con el GLMP, ya que la estructura de datos que vamos a usar para la entrada y la plantilla de generación que necesitamos vienen dadas por el dominio en el que nos encontremos. La implementación de un sistema debe cubrir los tres aspectos de la arquitectura LDCP. Primero, a los datos de entrada se les puede hacer un preprocesado o pasarlos directamente al GLMP. De cara a la creación del módulo de GLMP, es necesario establecer una serie de elementos: los CP, los PM, los conjuntos borrosos y las reglas de inferencia en base a los datos de entrada de estos conjuntos. Los CP tienen que ser inicializados con las posibles expresiones lingüı́sticas y los vectores de validez y relevancia. Los PM se inicializan con los CP de entrada, la funcione de agregación y la plantilla de generación. Los conjuntos borrosos tienen que ser definidos con funciones triangulares o trapezoidales para establecer los valores de pertenencia de cada expresión lingüı́stica y las funciones de inferencia que se van a aplicar a los valores de entrada. La estructura de los CP y PM se define en base a cuáles entran como atributo de los PM y cuáles son producidos por ellos. Finalmente, se define la plantilla de generación que agrega el resultado de todos los nodos. 3 4 5. https://github.com/OpenCCG/openccg http://phedes.com/rLDCP/ https://cran.r-project.org/web/packages/rLDCP/rLDCP.pdf.
(27) 2 Estado del arte:. 19. Como entorno de generación, rLDCP es sencillo y permite la creación de sistemas LDCP complejos [13], pero los sistemas que se generen serán sistemas intérpretes de plantillas expertos en un sólo dominio. En este caso, la reutilización de los recursos de un sistema no es como en los sistemas que emplean gramáticas, donde los diccionarios o las reglas de generación pueden ser reutilizados. Dado que cada sistema está especializado en su propio ámbito, no es común que la estructura de los datos de entrada ni la plantilla de generación coincidan. La estructura de las GLMP se puede modificar para crear otra diferente en lugar de crearla de cero, pero los CP y PM tendrán que ser modificados internamente. Los conjuntos borrosos y las reglas de inferencia son también dependientes del dominio, aunque se podrán generar a partir de unos existentes. En definitiva, la reutilización entre sistemas no es muy elevada, pero esto es algo que afecta al esquema de LDCP como tal y no a rLDCP como generador. El entorno ofrece una buena aproximación a la generación de lenguaje si la arquitectura LDCP se adapta bien al dominio en que nos encontremos.. 2.4.. Sistemas conversacionales. Uno de sus ámbitos más populares donde se aplica la generación de lenguaje natural es en los llamados sistemas conversacionales. En estos sistemas, se recorre todo el espectro de NLP, desde la comprensión de lenguaje natural hasta la generación. Como lo que se intenta simular es una conversación en lenguaje natural, esta se va a estructurar en lo que en la literatura se conoce como “turnos”. En cada turno, el usuario o el sistema proporcionará una frase al otro que servirá como respuesta o como continuación de la frase del turno anterior. Esta frase puede ser tanto de sólo una oración como de varias. Con esta estructura, se suponen inexistentes las interrupciones de un interlocutor a otro propias de las conversaciones y el único ruido existente será el generado por el usuario cuando introduzca una frase errónea, tanto gramatical como ortográficamente.. Fig. 8: Esquema de la arquitectura de un sistema conversacional. Adaptado de [64] para incluir los chatbots de lenguaje escrito Los sistemas conversacionales pueden dividirse en dos tipos diferentes, depen-.
(28) 2 Estado del arte:. 20. diendo del tipo de función para el que están diseñados [28]: Sistemas de diálogo. Estos chatbots son aquellos que tratan de simular una conversación con el usuario. Esta conversación se entiende como una en la que se toman un número indefinido de turnos entre los interlocutores y en la que se espera obtener algún resultado, ya sea simple entretenimiento u obtener algún resultado psicológico, por ejemplo. Chatbots orientados a cumplir una función en concreto. Este es el caso de los sistemas que reciben una pregunta o una orden en lenguaje natural y realizan una tarea en concreto. Por lo general, no son capaces de seguir muchos turnos de una conversación. Este es el caso de sistemas recientes muy conocidos como Siri o Alexa. Dado que la función que intenta cumplir cada uno es de diferente naturaleza, la forma de abordar los problemas que emplean será distinta. En las siguientes secciones se tratará cada caso por separado, viendo las aproximaciones de cada uno y las diferentes arquitecturas existentes. 2.4.1.. Sistemas de diálogo. Este tipo de chatbots dirigen una conversación de múltiples turnos entre los interlocutores. De cara a su estructura interna, como ocurre en otros sistemas de procesado de texto, esta se suele englobar en dos grupos: los basados en reglas y los basados en un corpus. Basados en reglas Los primeros chatbots que aparecieron, como Eliza [58], estaban basados en reglas léxicas para analizar las frases entrantes y generar una respuesta acorde. La idea es organizar las palabras en grupos con mayor o menor valor y en tener reglas que se apliquen a las frases en las que aparezcan estas palabras y además tengan una estructura adecuada. Cuando un sistema de este tipo recibe una frase, analiza las palabras que contiene a ver si alguna de ellas pertenece a su dominio. Si hay alguna que cumpla este requisito, entonces se prueban las reglas asociadas a esa palabra con la frase para tratar de generar una respuesta. En caso de no haber palabras del dominio o de no poder aplicar ninguna de las reglas, el sistema deberá generar una respuesta sin información algo acorde al dominio en el que se mueva. Poniendo como ejemplo el caso de Eliza, si el sistema no reconoce la frase que acaba de recibir este la reflejará al usuario como una pregunta, al estilo de los psiquiatras. Este tipo de sistemas, sin embargo, requieren un gran esfuerzo para desarrollarlos. Es necesario un amplio conocimiento lingüı́stico para poder generar las reglas que puedan aplicarse a cada palabra y a cada tipo de frase. Además, no son fáciles de mantener, ya que para nuevas frases y palabras que aparezcan hace falta expandir la base de reglas, un proceso no trivial. Pese a esto, este tipo de sistemas una vez desarrollados dan buenos resultados en su ámbito..
(29) 2 Estado del arte:. 21. Basados en un corpus Por otra parte, encontramos los sistemas que la información sobre la respuesta que generar la obtienen de un corpus previo de conversaciones entre personas o frases previas de una persona a una máquina y no exclusivamente de las frases de entrada. De entrada, la ventaja que presentan es no tener que crear a mano las reglas para el procesado de las frases de entrada, que deberán ser tratadas por otros medios. Sin embargo, un claro problema que presentan estos sistemas es que su funcionamiento está profundamente relacionado con el corpus que tengan. Dado que las frases que generan las sacan de este, si vamos generando el corpus de manera no controlada, por ejemplo obteniendo de manera automática conversaciones entre personas de una red social como Twitter, no vamos a tener control sobre lo que pueda decir el sistema. Si elegimos otra fuente como conversaciones en libros o pelı́culas, hay que tener cuidado con el registro que utilicen, ya que puede no ser adecuado para el ámbito en el que nos encontremos. En estos sistemas el corpus es tan importante como las reglas en los sistemas anteriores, y va a requerir tiempo generar u obtener uno lo suficientemente bueno como para que el chatbot tenga un rendimiento adecuado. En cuanto al modelo que emplean, una aproximación a este tipo de chatbots es aplicando recuperación de la información en el corpus. La idea principal es, a partir de una frase que le planteen al sistema, tratar de obtener una frase de respuesta del corpus de una situación similar. Los distintos ejemplos de este modelo se diferencian entre sı́ en el tratamiento que hacen del corpus y en cómo calculan que una frase es una respuesta válida a un turno anterior. Una aproximación común es la de comparar la primera frase del turno con las primeras frases de los turnos del corpus. Esta comparación puede ser hecha con medidas como la distancia del coseno o con cualquier otra métrica de la similitud entre vectores de palabras. Una vez hallado el turno de mayor similitud, se contesta con la segunda frase del turno del corpus a lo que le hayan dicho al sistema. Estos sistemas no realizan ningún tipo de comprensión de la estructura o el contenido de las frases que les plantean, se basan en comparaciones de similitud entre situaciones previas y la actual. Dado que, como norma general, tampoco se realizan conversiones de las frases del corpus, es especialmente importante que este sea rico y que esté orientado al ámbito concreto del chatbot, si es que lo hay. Una ventaja de cara al mantenimiento de este tipo de chatbots, es que los turnos de los usuarios pueden ser empleados para ampliar el corpus. Esto, sin embargo, tiene que ser realizado con cuidado, ya que un sistema que guarde todas sus interacciones con los usuarios va a terminar por tener un comportamiento descontrolado y, en como en casos previos, inadecuado. Otra aproximación extendida es el uso de arquitecturas sequence to sequence (seq2seq) y aprendizaje automático [37]. La idea de estos modelos es encontrar “transcripciones” entre las frases de entrada a un turno y las frases de contestación, como si se tratara de encontrar una traducción para la frase de entrada. Esto suele tener por debajo sistemas con redes neuronales que hace falta entrenar con el corpus [54]. Esto a su vez genera problemas que han de ser solucionados al tratar.
(30) 2 Estado del arte:. 22. de aplicar redes profundas, como que la generación de respuestas tiende a frases cortas que cortan abruptamente la conversación, o que se centran exclusivamente en contestar la última frase introducida, por lo que sufren dificultades para seguir una conversación continuada. La dirección que parece seguir la investigación de los chatbots conversacionales es la de los sistemas basados en corpus, tanto con recuperación de la información como con aprendizaje automático. Esta tendencia puede deberse al alto coste que tiene generar un sistema basado en reglas y a su poca flexibilidad de cara al mantenimiento de sistemas, además del interés que levantan los métodos que emplean técnicas de machine learning. Evaluación Como ocurre con todos los sistemas de NLP, los chatbots de diálogo tienen que ser evaluados para comprobar su efectividad. En estos casos, la evaluación automática con métricas clásicas como BLEU no resulta muy efectiva, dado que una frase de entrada puede tener un gran número de respuestas válidas y que es difı́cil interpretar el valor de estas métricas. La evaluación con humanos es la más extendida en este ámbito, donde normalmente se trata de comprobar como de “humanas” son las respuestas que genera el chatbot. En ocasiones, también se trata de hacer pasar al sistema por una especie de test de Turing, de modo que se le presenta a expertos textos de conversaciones entre humanos y conversaciones entre humanos y el chatbot para ver si es capaz de reconocer ambos casos. Otro método de evaluación que ha surgido recientemente es la evaluación con adversario [37]. Esta evaluación consiste en una especie de simulación del test de Turing con humanos por una máquina. La idea subyacente es entrenar un sistema de clasificación para que diferencie turnos entre humanos de turnos entre un humano y una máquina. De este modo, si el sistema se equivoca al evaluar los resultados de un chatbot y clasifica sus turnos como de humano a humano, la evaluación es que el sistema es efectivo en su ámbito. 2.4.2.. Sistemas conversacionales orientados a una función. Este tipo de chatbots no tratan de seguir un número indefinido de turnos en una conversación, sino que tienen un objetivo concreto en un contexto determinado y quieren obtener algún tipo de información de las frases que introducen los usuarios. Según su objetivo, se pueden distinguir [19]: Los que buscan realizar una función concreta, como reservar una entrada para ver una pelı́cula en el cine. Los que se centran en contestar preguntas, como “¿Qué restaurantes cercanos hay?” y en base a la respuesta tratar algún tipo de continuación como “¿Cuáles de ellos son de comida china?”.
(31) 2 Estado del arte:. 23. Los que sirven como un asistente personal, que son una mezcla de las funciones de los dos anteriores, con ejemplos representativos en los asistentes para smartphones como Siri. En la literatura se hace también una distinción entre los chatbots que reciben del usuario lenguaje natural hablado en vez de escrito, requiriendo los primeros modelos de tratamiento diferentes para extraer información del formato de audio. En este estado del arte no nos vamos a centrar en esos modelos de reconocimiento de voz, pero podemos encontrar una review actual de ellos en [64]. Representación en marcos Uno de los puntos importantes que tienen este tipo de chatbots y que difiere de los anteriores es la representación de la información. Dado que en este caso se va a tratar con una base de datos o una fuente de información de la que poder sacar las respuestas a las preguntas del usuario, es necesario estructurar el tipo de datos que trata el sistema. Para representar esta información, se utilizan modelos basados en marcos. Dependiendo del sistema que sea, un marco modelará el objetivo concreto que trata de buscar el sistema. Por ejemplo, en la figura 9 se muestra un posible marco para representar direcciones de puntos de interés en una ciudad. Cada punto tiene asociado slots con la calle, la distancia a la que están, el tipo de punto, el nombre y el estado del tráfico en su dirección. La conversación posterior muestra cómo la información acerca de estos slots es extraı́da de las frases que introduce el usuario para su posterior uso y cómo se debe orientar la conversación para obtener estos datos y proporcionar una respuesta.. Fig. 9: Ejemplo mostrado en [60] de una base de conocimiento y un sistema de marcos para representar puntos de interés. Una estructura de marcos adecuada al problema facilita centrarse en qué información ha de extraerse de cada frase. Por eso, la estructura de control de la conversación estará centrada alrededor de los marcos que hayamos creado. Esta estructura ha sido, tradicionalmente, parecida a una máquina de estados finita. Si tomamos como referencia el anterior ejemplo de un posible marco para un chatbot de direcciones, podrı́amos sacar una estructura de control parecida a la de la figura.
(32) 2 Estado del arte:. 24. 10 para guiar las conversaciones. En ella, cada estado tiene una forma diferente de tratar las frases entrantes de cara a tratar un elemento concreto del sistema de marcos, y tiene una forma de responder orientada al siguiente estado al que vayamos a llegar. No es necesario que cada estado trate un único slot, o que haya un mayor o menor número de estados, cada caso se adecuará a sus necesidades. También es posible tratar con varios tipos de marcos, pero en este caso el sistema requerirá extraer más información para poder completarlos, lo que hará la conversación más larga o el tipo de frases que se pueden procesar más complejas.. Fig. 10: Posible estructura de control en base al ejemplo de marco en la figura 9 El cambio entre estados puede hacerse en base a la frase que introduzca el usuario, si tenemos que diferenciar entre una función u otra, o en base a los resultados que obtengamos de lo pedido por el usuario, si podemos completar la función que tengamos que hacer o si nos faltan datos. Una ventaja de dividir la conversación en estados diferenciables es que el modelo de procesado de lenguaje se puede dividir en sistemas más pequeños orientados a su función de comprensión y generación concreta. Estos sistemas son más fáciles de desarrollar y de mantener que un sólo sistema que cubra todos los casos de procesamiento de lenguaje. Para completar los marcos que nos permitan realizar la función del chatbot, se utiliza comprensión del lenguaje natural para extraer información de las frases y movernos entre estados. Técnicas de NLU Los modelos de comprensión varı́an en función de si estamos tratando lenguaje escrito o hablado, pero el objetivo subyacente es el mismo. Lo la comprensión busca es poder rellenar los slots de los marcos del sistema que nos permitan poder realizar nuestra función. Por ejemplo, en el caso de un chatbot que permite reservar un vuelo de avión, se querrá rellenar un marco con el origen y destino del usuario, el dı́a de ida, el dı́a de vuelta y el precio que está dispuesto a pagar. Para esto, hace falta analizar las frases que ha introducido el usuario, obtener datos de ellas y preguntar si es necesario por los datos que falten. Si el dominio del chatbot es más amplio, tal vez haga falta identificar también la función que quiere realizar el usuario y cuáles son los marcos que debemos rellenar según su intención..
(33) 2 Estado del arte:. 25. Uno de los métodos clásicos de localización y extracción de información de una frase es mediante reglas semánticas [28]. Estas reglas semánticas son creadas a mano con, normalmente, gramáticas libres de contexto (CFG) capaces de reconocer elementos dentro de una frase. Las CFG consisten en una serie de producciones con una parte izquierda donde sólo aparece un sı́mbolo no terminal y una parte derecha con las posibles derivaciones de ese sı́mbolo. Cada regla de la gramática consiste en una estructura que puede ser reconocida por estas derivaciones y representada como etiquetas en un árbol de derivación. Las gramáticas pueden ir desde tener unas pocas producciones hasta tener bases de varios miles de ellas, pero cuanto más escalan más complicadas son de mantener y puede afectar a su rendimiento. Una vez se tiene la gramática capaz de reconocer un tipo de frases en concreto, es necesario un algoritmo de parsing para recorrer las palabras de la frase que introduzcamos dentro de las posibles producciones de la gramática. Lo que diferencia un parser de otro es el orden en el que evalúan las producciones: si es desde arriba a abajo, es decir, desde los sı́mbolos iniciales de la gramática hasta los sı́mbolos terminales, o de abajo arriba, si evalúa las palabras iniciales primero o si empieza por las últimas o la regla que utiliza para elegir la próxima derivación a probar. No hay un parser que sea más efectivo que cualquier otro, en cada ámbito concreto y con cada tipo de frases puede variar el rendimiento. De cara a un nuevo problema, hay que probar cuál de los parsers posibles es el más eficaz. Cuando ha terminado el parsing se obtiene un árbol de derivación con la frase original con cada palabra etiquetada como la derivación a la que corresponde. Este árbol puede recorrerse para encontrar las etiquetas correspondientes a datos que pueden rellenar los slots dentro de nuestros marcos. La principal ventaja de este tipo de sistemas es su alta precisión, ya que si una frase es reconocida por la gramática, vamos a poder extraer sin ningún problema toda la información necesaria. Sin embargo, conforme el dominio de la aplicación se hace más amplio, crece en gran medida el esfuerzo necesario para crear reglas que reconozcan todas las frases posibles a las que se puede enfrentar el sistema, y mantenerlo se vuelve mas costoso. Otra posibilidad de diseño extendida es el uso de aprendizaje automático para identificar el tipo de pregunta que le han hecho al sistema y la posición de los datos relevantes en la frase. Para identificar el tipo de frase que nos presentan, lo más común es tener un sistema de clasificación del tema de la pregunta basado en n-gramas. Este sistema puede tener cualquier tipo de clasificador subyacente, desde un modelo de espacio de vectores que clasifique por distancia relativa entre frases hasta modelos de regresión logı́stica o redes neuronales. Este módulo de identificación se harı́a en el caso de tener un dominio amplio en el que es posible realizar más de un tipo de preguntas diferentes. Para llevar esto a cabo, primero necesitamos una base de preguntas de cada tipo de manera que podamos crear los modelos de clasificación de las nuevas preguntas entrantes. Por tanto, es necesario algún método de obtener estas preguntas, ya sea realizándolas a mano con ayuda de personas con conocimientos lingüı́sticos o recogiéndolas a partir de la clasificación manual de las preguntas introducidas por los usuarios con el tiempo..
Documento similar