3.1. Tecnologías con Procesamiento de Lenguaje Natural o Inteligencia Artificial conversacional

Entre las tecnologías cognitivas se destacan aquellas que operan sobre el lenguaje y su entendimiento, con plataformas de procesamiento que incluso pueden simular una conversación humana, como lo son para cada caso: Google con Dialog Flow, Amazon con Lex, IBM con Watson, Rasa, Flow XO, entre otras. Cada tecnología implementa diferentes técnicas y enfoques, y esta es la base para el desarrollo de los sistemas conversacionales, a continuación, se presenta una revisión de las características y el alcance que las tecnologías existentes proveen.

En la Tabla 1 se presentan las tecnologías revisadas y se consideran siete criterios para su comparación, los criterios se describen a continuación:

La Tabla 1 muestra que para los criterios costo cero, instalación, programación, GUI las herramientas son muy similares, a excepción de Rasa que permite una programación avanzada y si permite la instalación. Otro criterio que permite tomar una decisión de la tecnología a utilizar para la implementación es el cobro por demanda, pues esto implica que para el desarrollo de nuevos proyectos está limitado por el pago de acuerdo con el número de mensajes.

De esta forma, la comparación de las tecnologías muestra que Rasa tiene ventajas y se adapta más a nuestro contexto en términos de costos por instalación y cobro por demanda. De igual manera permite la programación y la adición de nuevas funcionalidades, lo cual es clave para un proyecto de investigación o de desarrollo, así para este este trabajo se elige a Rasa ¹¹, la cual es una biblioteca para la comprensión del lenguaje natural que clasifica intenciones, extrae entidades nombradas y otras características del lenguaje natural directamente desde el texto. La tecnología se caracteriza por ser código abierto, gratuita y requiere de instalación local. Aunque, no incluye integración predefinida con sistemas de mensajería instantánea (IM), sistemas como Telegram o Whatsapp al permitir la programación avanzada se puede realizar una conexión de interoperabilidad con dichos sistemas (IM).

La elección de Rasa permite la instalación y la ausencia de interfaz de usuario para su configuración (GUI). Con la instalación se pueden configurar y desplegar microservicios con tareas específicas que puedan responder a múltiples situaciones de riesgo. Con la interfaz de línea de comandos (CLI, del inglés, Command Line Interface) se logra un control granular del sistema operativo y las dependencias de instalación. Lo anterior permite el uso eficiente de los recursos de la máquina y mayor control sobre el desarrollo y las funcionalidades de la herramienta prototipo chatbot.

3.2. Entrenamiento y preparación de los conjuntos de datos

Un chatbot puede considerarse como una estrategia para diseminar información correcta para las personas en un escenario de riesgo. Con el marco conversacional de Rasa ¹¹ primero, se establece el dominio o contexto del bot conversacional y las intenciones conversacionales, necesidades de información u oraciones que definen el tema de la conversación, estas pueden ser preguntas tipo y respuestas asociadas para resolver la necesidad de información. De acuerdo con estos elementos de diseño, se recopila un conjunto de datos que contiene una muestra de las intenciones conversacionales y otros textos que acompañan y guían la conversación.

Dominio de la información: Una herramienta chatbot debe recibir el lenguaje natural directamente desde el texto de entrada del usuario y entender la demanda de información. En este trabajo, el modelo es de propósito específico o de dominio es cerrado, en especial para responder al escenario de riesgo de pandemia COVID-19. En este sentido, los textos, preguntas y conversaciones tendrán varias intenciones relacionadas con cuatro grupos: las relacionadas con casos, las que involucran normas generadas durante la pandemia, preguntas frecuentes y generales.

Para que el chatbot comprenda el texto es necesario descubrir la intención conversacional que tiene el usuario al enviar el mensaje, esta intención se construye a partir de la información lingüística obtenida del mensaje: la estructura sintáctica, palabras claves y entidades nombradas. Un ejemplo de esta clasificación puede ser:

Conjunto de datos de entrenamiento: Para desarrollar una herramienta con inteligencia artificial conversacional, se utiliza el marco de desarrollo Rasa ¹¹, es necesario construir un conjunto de datos para entrenar los modelos. Para este trabajo el conjunto de datos contiene diversas muestras de las intenciones del usuario, o lo que es lo mismo preguntas y textos que un usuario enviaría para consultar información, los cuales el modelo de PLN toma como fuente de conocimiento para entrenarse. De esta manera, intenciones, textos muestra y otros de requerimiento de información particular, se estructuran en un corpus del que se utiliza un 80% para el entrenamiento del modelo y 20% para probarlo. El conjunto de datos contempla 32 muestras por cada intención de usuario, un subconjunto muestral de los textos que se presentan en la Tabla 2.

Los datos se construyeron a partir de la información del municipio de Cali, principalmente información de la vulnerabilidad del contagio en puntos específicos de la ciudad, cantidad de casos por barrio y comuna. También se extrajo datos departamentales y regionales de Esri Colombia ^26-28 y Datos-Abiertos-Colombia ²⁹, los decretos y normativas fueron obtenidas directamente de los portales gubernamentales, todo de manera automática con técnicas de extracción de información web (Web scraping). Para las noticias se utilizó rutas de distribución de noticias (RSS, del inglés, Really Simple Syndication) directamente de periódicos colombianos y de la ciudad de Cali. Las preguntas y respuestas comunes sobre síntomas, prevención, contagio, vacunas se obtuvieron desde el portal de los Centros para el control y prevención de enfermedades (CDC) ^30,31 y coronavirus Colombia ³².

Teniendo en cuenta que los modelos se construyen como prototipado incremental, los conjuntos de datos de entrenamiento siguen la misma lógica, de esta manera, el conjunto de datos es compilado de forma automática para cada una de las intenciones de comunicación asociadas al prototipo incremental: línea base para casos generales (BC); línea base, zonas geográficas y normativa (BCN); y línea base, zonas geográficas, normativa y preguntas frecuentes (BFAQS).

De esta forma para cada modelo hay su corpus de entrenamiento correspondiente, al cual se agregan preguntas, textos y consultas o requerimientos tipo que contienen la estructura de sintáctica de las preguntas, o requerimientos de información que se esperan del usuario. El corpus de entrenamiento total cuenta con 636 oraciones aproximadamente y 20 consultas por cada intención. Cada modelo fue entrenado siguiendo el enfoque supervisado y el conjunto de muestras se dividía en 80% para entrenamiento y 20% de las muestras para pruebas.

El conjunto de entrenamiento contiene textos con las entidades nombradas (EN), que permiten guiar al Chatbot por un grupo de intenciones relacionadas con la consulta de casos en sitios de interés de la ciudad, como barrios, comunas e incluso fechas. De igual manera los textos para entrenamiento incluyeron palabras claves que son elementos fijos en la solicitud del usuario y guían al Chatbot por las intenciones relacionadas con preguntas frecuentes, mitos, síntomas, decretos, normas y otras diferentes a los casos, ejemplo de ellas son: lavado de manos, dolor en el pecho, diabetes, síntomas, decretos, entre otras. En la Tabla 3, se presentan ejemplos del conjunto de entrenamiento, entre las que se destacan las entidades que hacen referencia a las comunas y barrios; y las palabras claves, noticias sobre el escenario de pandemia, entre otras.

3.3. Arquitectura de referencia para el prototipo

La arquitectura diseñada para la herramienta chatbot prototipo permite la estandarización de una solución para el despliegue de modelos de PLN. La aplicación está basada en microservicios con funciones específicas, autónomos que trabajan juntos y que están acoplados. La arquitectura está basada en microservicios de diseño modular, escalable, flexible y reutilizable ³³. Este prototipo puede ser desplegado en cualquier máquina para responder a un escenario de riesgo de pandemia, la cual es portable y es flexible al permitir agregar, modificar o quitar funcionalidades sin dañar la funcionalidad de la herramienta como un todo. La Figura 1 presenta las tecnologías y las relaciones entre los microservicios de la herramienta. La arquitectura se puede describir como el despliegue con tres microservicios:

La herramienta prototipo que se describe en este documento se basa en microservicios los cuales están desarrollados con el patrón arquitectural RESTFUL, con una comunicación basada en estructuras JSON. La implementación se hizo con Python v3.5, JavaScript v8.0 y Rasa v2.5. La arquitectura soporta los siguientes requerimientos de información: i) estadística de casos en barrios, comunas, el municipio de Cali y el departamento del Valle del Cauca, Colombia, ii) decretos, circulares, noticias y normativas para Colombia durante el escenario de riesgo de pandemia; y iii) preguntas frecuentes sobre covid-19, su propagación, la vacunación, el escenario de riesgo de pandemia entre otras que son relevantes para la población y su contexto.

El marco de desarrollo en el proyecto fue Rasa ¹¹ que incorpora módulos de Natural Language Understanding (NLU), una rama de PLN, la cual permite el entendimiento del lenguaje natural. Bajo este marco de trabajo el chatbot aprende a clasificar automáticamente las intenciones, a partir de texto, identificando datos adicionales como entidades nombradas, palabras clave o cualquier otra información que permita dar respuesta a la necesidad de información del usuario. Así, Rasa es utilizado para entrenar los modelos de NLU o PLN, clasificar automáticamente las intenciones comunicacionales de las entradas del usuario, leer los archivos de configuración, las muestras y dar repuestas a las preguntas solicitadas.

La búsqueda de la respuesta se lleva a cabo en el módulo de acciones, las acciones se construyen con un agente basado en Rasa ¹¹, una vez el asistente es capaz de entender lo que el usuario le solicita, debe ejecutar una secuencia de acciones para obtener la respuesta. El mensaje de respuesta debe ser coherente y en lenguaje natural. Es por esta razón que para los casos de barrios, comunas o sitios de interés se crea una lista de plantillas de respuesta, que especifican el número de casos activos, casos confirmados y fallecimientos en el sitio especificado en la solicitud. Los datos se actualizan a diario y se almacenan de manera estructurada. Para todos los otros casos las respuestas se construyen a partir de los textos recopilados en el conjunto de datos. Esto es todo el corpus de datos considerado en el conjunto de datos que no poseen una estructura y están escritas en lenguaje natural. Así, hallar una respuesta en los textos representa un reto de minería de texto. En este trabajo para la caracterización y extracción de textos se incluyeron técnicas de PLN, que permiten el preprocesamiento del texto, normalización de textos, eliminación de caracteres extraños, saltos y espacios en blanco, tokenizado y lematización de palabras ^34,35,36,37. Todas estas tareas se llevan a cabo en Rasa ¹¹ y permite la construcción de una respuesta a partir de un texto en lenguaje natural.

Para hallar una respuesta, El Servicio Depot, diseñado puede consultar y almacenar la información estructurada o no estructurada desde las diferentes fuentes de datos, la versión prototipo utiliza las técnicas de Matriz de términos del documento (DTM, del inglés, Document Term Matrix) y la similaridad coseno sobre el conjunto de datos permite identificar automáticamente la relación entre el requerimiento de información y la respuesta asociada, para más información sobre el método revisar ³⁶. Lo que significa que la respuesta posee una ponderación numérica en relación con la consulta del usuario, el chatbot posee diversas formas de contestar a una pregunta, pero la más cercana a la consulta será entregada como respuesta al usuario.

3.4. Prototipado incremental

Las arquitecturas basadas en microservicios aportan la modularidad necesaria para permitir la reutilización y evolución de prototipos ^33,38,39. Tres prototipos fueron puestos a prueba para demostrar la usabilidad de este tipo de soluciones y evidenciar problemas potenciales. La herramienta prototipo que incorpora el modelo línea base (BC) se configuró para suplir las necesidades de información estadística de casos en barrios, comunas, municipios y departamentos, como prueba de concepto se estableció para el contexto de la ciudad de Cali, Colombia. Con un mínimo de 20 oraciones para el entrenamiento y pruebas que incluían Entidades Nombradas (EN) para reconocer los nombres de los barrios y otros lugares específicos de la ciudad, después del entrenamiento este modelo se incorporó al servicio de entendimiento del lenguaje y los datos de los barrios, comuna y de más puntos de interés se almacenaron en el servicio Depot. El diseño incremental utilizado es altamente reutilizable y personalizable para evitar la reconstrucción de los prototipos desde cero. Una vez terminado un modelo, se evalúa y se toma decisiones de mejora, para la evaluación de cada modelo se puso a disposición de los usuarios a través de en un sitio web y de la plataforma Telegram.

Con el prototipado incremental los usuarios finales tienen una participación activa durante la construcción y despliegue de herramientas. Es por esta razón que una vez se avala el comportamiento de una de las versiones de la herramienta prototipo se realizan ajustes, cambios y se incorporan nuevas características para una nueva versión prototipo. Para la herramienta prototipo que responde a noticias, normativas, se mantienen las intenciones con entidades nombras y se agregan al entrenamiento aquellas que le permiten a Rasa identificar que el usuario requiere nueva información relacionada con los documentos gubernamentales generados durante la pandemia.

Para poder suplir las necesidades de información de una población en su contexto, se deben considerar diferentes tipos de preguntas acerca del escenario de riesgo de la pandemia, la prevención, el contagio entre otras que son de vital importancia. Para lograrlo se entrenó e incorporó el modelo BFAQ a la herramienta prototipo, que en este artículo presenta un mejor desempeño en comparación con el modelo base, con una respuesta aceptable. Esta versión incluye mensajes de saludo, despedidas con el objetivo de guiar y simular una conversación humana, presenta algunas preguntas iniciales para ayudar al usuario que no sabe cómo iniciar la conversación. El prototipo se conectó a la plataforma de mensajería instantánea Telegram con el nombre de @SigeloBotCali y está actualmente disponible para su utilización.

3.5. Evaluación de los prototipos

Para conocer la capacidad de generalización de un modelo, es decir, la capacidad de hacer bien el trabajo de clasificación ante una consulta nueva es importante su evaluación. Para realizar esta evaluación es necesario contar con dos conjuntos de muestras: entrenamiento y pruebas.

El conjunto de entrenamiento se utiliza para que el modelo aprenda los parámetros automáticamente y minimice el error de clasificación. Luego con el conjunto de prueba se calcula el error que comete el modelo sobre las muestras de ese conjunto. Esta división permite conocer de manera fiable la capacidad de generalización. Es común para este tipo de herramientas utilizar las medidas de precisión, cobertura (recall) y valor-F (F-Score). Con la precisión se mide la cantidad de textos clasificados en la intención a la que realmente pertenecen, con la cobertura se mide la cantidad de textos que se han clasificado en la intención correcta y el valor-F es la media armónica entre precisión y cobertura. Cuanto mayot sea el resultado del valor-F, mejor se comporta el modelo ⁴¹.

Aunque las medidas son comúnmente usadas para evaluar el desempeño, para este tipo de herramientas que incorporan chatbots es necesario evaluar el contenido, la satisfacción del usuario y otros aspectos funcionales ⁴². Es por esta razón que en este trabajo se evalúa la herramienta prototipo con una encuesta de seis preguntas: ¿Con qué frecuencia utiliza asistentes virtuales para obtener información? ¿Cómo ha sido la experiencia con el asistente virtual? ¿Utilizaría nuevamente esta herramienta para obtener información bajo situaciones de riesgo (sanitarias, naturales, entre otras)? ¿Qué fue lo más te llamó la atención? ¿En qué grupo enmarcaría las preguntas que le realizó al bot? y ¿Cómo calificaría la respuesta que entregó la herramienta?

Con estas preguntas se espera que los encuestados den a conocer su opinión sobre el prototipo y entender sus necesidades de información.

4.1. Efectividad de los modelos de PLN

Entre los elementos más importantes de la investigación es la comprensión de los componentes necesarios de NLU y PLN para responder a los requerimientos e información en un escenario de pandemia. Los cuales se encargan de clasificar las intenciones de comunicación del usuario directamente desde el texto. Además, permite encontrar la respuesta más cercana a un requerimiento de información. La compresión del lenguaje natural es considerada como un problema de clasificación múltiple. Para evaluar el desempeño de los modelos en la tarea de clasificación se cuenta con las métricas de precisión, cobertura (recall) y Valor-F (F-Score, por su nombre en inglés). La precisión permite medir el grado de efectividad del modelo, la cobertura o exhaustividad la cual mide la cantidad de ejemplos que el modelo es capaz de identificar correctamente frente al total de ejemplos correctos y el valor-F que es una medida representativa de un bajo número falsos positivos y falsos negativos, lo que significa que el modelo realiza la tarea de clasificación con pocos errores. En la Tabla 4 se presenta el rendimiento de cada uno de los modelos considerados en la investigación, en esta se resalta el rendimiento del modelo BFAQ que en comparación con los otros modelos de referencia logra una mejor valor-F. Es por esta razón que la herramienta prototipo utiliza el modelo BFAQ para responder a las necesidades de información de la ciudad de Cali.

Las métricas permiten comparar los modelos y la efectividad del método de desarrollo prototipado incremental. Aunque es común utilizar estas métricas, la matriz de confusión del clasificador de intenciones ayuda a reconocer cuáles intenciones tienen mayor confianza.

En la Figura 2, se presenta una matriz de correlación de las intenciones de comunicación, las filas representan las intenciones y en las columnas representan la clasificación realizada por el modelo automáticamente. La matriz de confusión del modelo BFAQ contiene colores oscuros, o con un mayor valor en la diagonal principal y con conteo bajo en otras zonas de la matriz. Esto significa que el modelo predice bien cuando las preguntas del usuario están relacionadas con covid-19, la mitigación, la precaución, la propagación, las medidas de prevención, entre otras preguntas comunes. Para preguntas relacionadas con el número de casos el modelo presenta tiende a fallar más, ya que la sintaxis de este tipo de preguntas es similar, preguntar por el número de casos en barrios, departamento o municipios poseen la misma estructura sintáctica y así el modelo presenta más errores en la matriz. La herramienta posee una combinación de tecnologías de NLU y PLN, para lograr la integración de datos de diferentes fuentes, datos públicos y el conocimiento disponible en las páginas web, noticias y documentos gubernamentales. Además, incorpora en su diseño un marco conversacional autónomo que responde de forma acertada a preguntas bajo situaciones de riesgo.

Fuente: Elaboración propia

Figura 2 Matriz de confusión para el modelo BFAQ. 

La construcción de los conjuntos de datos, la implementación de las tecnologías y el desarrollo de la tecnología prototipo se hizo en tres meses, lo que muestra que frente a un escenario de riesgo de pandemia la arquitectura acá presentada y las tecnologías acá descritas permitiría crear un chatbot en menor tiempo. La cual puede ser una herramienta de soporte a la toma de decisiones de los ciudadanos, para que ellos se mantengan actualizados, informados y tomen decisiones informadas en cuanto a movilidad, normatividad y demás aspectos relacionados en un escenario de pandemia. Finalmente, dado que la herramienta se conecta con sistemas de información de IM, el flujo de información con los usuarios es transparente, pues ellos pueden comunicarse como con un contacto en facebook, messenger u otro (ver Figura 3).

Fuente: Elaboración propia

Figura 3 Ejemplo de interacción en Telegram.