Implementación de herramientas de atención al usuario mediante modelos fundacionales LLM en la UVa

1 E.T.S. Ingenieros de Telecomunicación TRABAJO DE FIN DE GRADO Grado en Ingeniería de tecnologías específicas de telecomunicación Mención en sistemas electrónicos Implementación de herramientas de atención al Usuario mediante modelos fundacionales LLM en la Uva. Septiembre 2024 Tutor: Don. Juan Pablo de Castro Fernández Autor: Don. Adrián Bernardo Barrero 2 Resumen El presente TFG tiene como objetivo el desarrollo de un chatbot sustentado en un LLM (Large Language Model) para la página web de la universidad. Este chatbot permitirá al Centro de Asistencia al Usuario (CAU), prestar un servicio asistido por IA, especialmente a los usuarios de nuevo ingreso, obtener información de forma rápida y sencilla sobre la resolución de diversos problemas y temas relacionados con la universidad, como, por ejemplo: • Problemas: acceso al campus virtual, recuperación de contraseñas o uso de vTUI • Información académica: Planes de estudio, asignaturas, horarios, exámenes, etc. • Trámites administrativos: Matrícula, becas, ayudas, etc. • Servicios universitarios: Biblioteca, comedor, alojamiento, etc. • Actividades extracurriculares: Deportes, asociaciones, eventos culturales, etc. • Preguntas frecuentes de índole técnica. 3 Abstract The present Final Degree Project aims to develop a chatbot based on a Large Language Model (LLM) for the university's Help Desk. This chatbot will enable the User Assistance Center (UAC) to provide AI-assisted service, especially to new users, allowing them to quickly and easily obtain information on the resolution of various problems and issues related to the university. Some examples could be: • Problems: access to the virtual campus, password recovery or vTUI use. • Academic information: subjects, timetables, exams… • Administrative procedures: school enrollment, scholarship. • University services: library, accommodation. • Extracurricular activities: Sports, association, events. • Frecuently asked questions Key words: AI, LLM, chatbot 4 Agradecimientos En primer lugar, a mi familia por darme la oportunidad de tener una educación de calidad, aunque nunca me entendiesen cuando hablaba de la carrera. A compañeros y amigos con los que tantas horas compartimos al final en la universidad, especialmente aquellos que formamos parte de una asociación increíble. A profesores y otro personal, que por su vocación han sido capaces de transmitir pasión y conocimiento sobre el sector. Gracias a todos por acompañar en este camino. 5 Índice general 1 Introducción .......................................................................................................................... 7 1.1 Contexto y motivación .................................................................................................. 7 1.2 Inteligencia Artificial ..................................................................................................... 7 1.3 Machine Learning y Deep Learning ............................................................................ 8 1.4 Deep Learning: ............................................................................................................. 9 1.5 Transformers ..............................................................................................................10 1.6 NLP (Procesado de lenguaje natural) .......................................................................12 2 OBJETIVOS ..........................................................................................................................14 3 ESTADO DEL ARTE ..............................................................................................................14 3.1 Chatbot basado en caminos lógicos .........................................................................14 3.1.1 Copilot Studio de Microsoft ...............................................................................15 3.1.2 Pruebas en Copilot Studio .................................................................................15 3.1.3 Dialogflow de Google Cloud ...............................................................................18 3.2 Chatbots basados en procesado de lenguaje natural (NLP) ...................................19 3.2.1 Chatbots basados en LLM .................................................................................20 3.2.2 Modelos fundacionales LLM ..............................................................................20 3.2.3 Soluciones Cloud IA ............................................................................................25 4 ENTORNO TECNOLÓGICO ..................................................................................................29 5 ANÁLISIS .............................................................................................................................30 5.1 Caso de uso ................................................................................................................31 5.1.1 Mensaje proporcionado por el usuario .............................................................31 5.1.2 Procedimiento seguido por el CAU ....................................................................31 6 DISEÑO DEL PROYECTO. ....................................................................................................33 6.1 Componentes del sistema .........................................................................................34 6.2 API’s y LDAP ................................................................................................................34 6.3 Diseño del sistema .....................................................................................................35 6.3.1 Documento de resolución de problemas ..........................................................35 6.3.2 Algoritmo .............................................................................................................36 6.3.3 Fase 1: Análisis del mensaje .............................................................................37 6.3.4 Fase 2: Enriquecimiento de contexto ...............................................................38 6.3.5 Fase 3: generación de respuesta ......................................................................42 6.4 Pruebas y validación ..................................................................................................42 6.4.1 Diseño de las Pruebas: ......................................................................................42 6.4.2 Casos de Prueba ................................................................................................43 6.4.3 Resultados y Análisis .........................................................................................45 7 CONCLUSIONES ..................................................................................................................45 8 Limitaciones y líneas futuras .............................................................................................46 6 9 BIBLIOGRAFÍA Y RECURSOS ..............................................................................................47 10 Anexo 1: Código ..............................................................................................................48 7 1 INTRODUCCIÓN 1.1 CONTEXTO Y MOTIVACIÓN En este momento donde la inteligencia artificial se encuentra en pleno auge, su uso para mejorar el potencial de esta institución es clave, además se plantean otros problemas a los que puede hacer frente: Mejora de la accesibilidad a la información: • Los usuarios podrán obtener información de forma rápida y sencilla, sin necesidad de tener que contactar con la secretaría de la universidad o buscar en la página web. • El chatbot estará disponible 24/7, de manera que la obtención de información sea posible en cualquier momento y desde cualquier lugar. Mejora de la calidad de los servicios: • El chatbot podrá recopilar información sobre las necesidades de los estudiantes, lo que permitirá mejorar la calidad de los servicios que ofrece la universidad. • El chatbot podrá ofrecer un servicio personalizado a cada estudiante, adaptándose a sus necesidades e intereses. Reducción de costes: • El chatbot puede automatizar o asistir en las tareas que actualmente realizan los empleados de la universidad, como por ejemplo responder a preguntas frecuentes, esto puede liberar a empleados de tareas repetitivas para su dedicación en tareas más productivas. Mejora de la imagen de la universidad: • El desarrollo de un chatbot innovador puede mejorar la imagen de la universidad y hacerla más atractiva de cara a posibles estudiantes. • La universidad se posicionará como una institución moderna y comprometida con la mejora de la calidad de la educación. En resumen, el desarrollo de un chatbot puede aportar numerosos beneficios tanto a los estudiantes como a la propia universidad. En el Centro de Atención al Usuario (CAU) de la Universidad se atienden multitud de solicitudes de ayuda y consultas repetitivas, lo cual consume una gran cantidad de recursos humanos. Estas tareas, por su naturaleza, son abordables mediante sistemas de inteligencia artificial para aumentar la eficiencia y mejorar la atención global. Es por eso por lo que se pretende implantar, una arquitectura experimental que pueda ayudar en la resolución de incidencias frecuentes y que se puedan detectar y responder mediante las capacidades de gestión del lenguaje natural de los nuevos LLM. Estas incidencias pueden necesitar realizar comprobaciones de servicios y consultas en base de datos, dado que suele ser necesario investigar las condiciones personales de cada problema y para cada usuario. 1.2 INTELIGENCIA ARTIFICIAL La inteligencia artificial (IA) es un campo de la informática que busca crear sistemas que puedan simular la inteligencia humana. Esto abarca una amplia gama de capacidades, 8 desde el reconocimiento de patrones y el aprendizaje automático, hasta el razonamiento complejo y la toma de decisiones. En el ámbito de la automatización de tareas, la IA tiene un enorme potencial para transformar la forma en que trabajamos. Algunas de las áreas donde la IA ya está teniendo un impacto significativo incluyen: • Procesamiento del lenguaje natural (PLN): La IA se puede usar para automatizar tareas como la traducción de idiomas, la redacción de textos y la extracción de información de documentos. • Visión artificial: La IA se puede usar para automatizar tareas como el reconocimiento de imágenes, la inspección de productos y el control de calidad. • Robótica: La IA se puede usar para controlar robots que pueden realizar tareas físicas en entornos industriales, médicos y otros. Esta herramienta ofrece una serie de oportunidades para automatizar tareas repetitivas y monótonas, como: • Análisis de datos: La IA puede usarse para analizar grandes conjuntos de datos de redes y dispositivos para identificar patrones y tendencias. • Mantenimiento de redes: También puede utilizarse para detectar y solucionar problemas de red de forma proactiva. • Optimización de redes: Otra opción es su uso para optimización del rendimiento de las redes y mejorar la calidad del servicio. • Atención al cliente: Por último, puede usarse para proporcionar asistencia a los clientes 24/7 y resolver problemas de forma rápida y eficiente. A medida que la IA continúe evolucionando, es probable que veamos aún más aplicaciones para la automatización de tareas, también en el ámbito de las telecomunicaciones. Algunos ejemplos específicos de cómo se está utilizando en la actualidad en el sector de las telecomunicaciones: • Verizon: Esta compañía utiliza inteligencia artificial para analizar datos de red y predecir cuándo es probable que ocurran fallos. Esto les permite tomar medidas preventivas y evitar interrupciones del servicio. [1] • Movistar: Movistar implementa soluciones de análisis de datos avanzados. Utilizan IA para comprender las necesidades de los clientes y crear ofertas personalizadas. [1] • Tesla: Tesla utiliza inteligencia artificial en sus vehículos para mejorar la conducción autónoma y la experiencia del usuario. La empresa ha desarrollado sistemas avanzados de aprendizaje automático que permiten a sus coches aprender de las condiciones de conducción y optimizar su rendimiento. [1] En resumen, la IA tiene un enorme potencial para transformar cualquier sector. Al automatizar tareas, puede liberar a las personas para que se concentren en tareas más creativas y estratégicas. 1.3 MACHINE LEARNING Y DEEP LEARNING El aprendizaje automático (Machine Learning) es un campo de la inteligencia artificial que se centra en la creación de algoritmos que puedan aprender y mejorar su rendimiento por sí mismos, sin ser programados explícitamente. Estos sistemas se entrenan con grandes cantidades de datos para identificar patrones y tomar decisiones basadas en esos patrones. 9 El aprendizaje profundo (Deep Learning) es un subcampo del aprendizaje automático que utiliza redes neuronales artificiales para aprender de los datos. Las redes neuronales están inspiradas en el funcionamiento del cerebro humano, y son capaces de aprender representaciones complejas de los datos. Concluyendo, el aprendizaje automático es un campo más amplio que abarca una variedad de técnicas, mientras que el aprendizaje profundo es un tipo específico de aprendizaje automático que utiliza redes neuronales. Aprendizaje Automático: El aprendizaje es un proceso mediante el cual las redes neuronales adquieren la capacidad de aprender de los datos, sin ser programados explícitamente para cada tarea. Estos algoritmos buscan identificar patrones y relaciones ocultas en grandes conjuntos de datos para realizar predicciones, tomar decisiones o generar contenido nuevo. Existen diferentes tipos de aprendizaje: • Aprendizaje supervisado: Se entrena el sistema con un conjunto de datos que incluye ejemplos de entrada y salida. • Aprendizaje no supervisado: Se entrena el sistema con un conjunto de datos sin ejemplos de salida. • Aprendizaje por refuerzo: Se entrena el sistema a través de ensayo y error, recompensándolo por comportamientos deseables y penalizándolo por comportamientos indeseables. La manera en la que se interactúa con la información de entrada de estas redes neuronales permite el desarrollo de aplicaciones complejas, como pueden ser: • Reconocimiento de imágenes: Identificar objetos o personas en imágenes. • Procesamiento del lenguaje natural: Entender y generar lenguaje humano. • Predicción de series temporales: Pronosticar valores futuros a partir de datos históricos. • Detección de fraudes: Identificar transacciones fraudulentas. 1.4 DEEP LEARNING: Redes neuronales: Las redes neuronales son modelos computacionales inspirados en el cerebro biológico. Están compuestas por nodos interconectados, llamados neuronas artificiales, que procesan información. Estas redes aprenden a partir de datos, ajustando los pesos de sus conexiones para realizar tareas como clasificación, regresión y generación.(4. Introducción a Redes Neuronales Artificiales, n.d.) • Neuronas: Unidades básicas de procesamiento de las redes neuronales. Cada conexión entre neuronas posee un peso que determina la importancia de la información que fluye a través de ella. Además, cada neurona cuenta con un sesgo, un valor constante que se añade a la suma ponderada de las entradas, permitiendo ajustar el umbral de activación. Para introducir no linealidad en el procesamiento, se emplean unas funciones de activación. • Capas: Las neuronas se organizan en capas, que pueden ser de entrada, ocultas o de salida. Estas capas funcionan de manera secuencial. Estas capas aprenden a extraer características cada vez más abstractas de los datos, desde bordes simples en imágenes hasta conceptos complejos como rostros o objetos. Esta capacidad de 16 3.1.2.1 GENERACIÓN DATASETS Y DOCUMENTOS Estos datasets incluyen la información necesaria para que el modelo sea capaz se responder las preguntas acerca de determinados temas, dado que la plataforma también acepta ficheros .docx y .pdf, no solo los archivos de texto serán necesarios para el modelo. 3.1.2.2 WEB SCRAPPING Y DESCARGA DOCUMENTOS Tras el proceso de adaptación al puesto de trabajo, y de manera independiente al modelo y sistema para el desarrollo del LLM, el primer paso tomado ha sido la creación de los Datasets con los que fine-tuneará posteriormente. La primera idea a la que se recurrió fue la extracción del histórico de correos de la cuenta de soporte, para ser procesada en un formato ‘.pst’. Donde la pregunta realizada por el usuario se pasaría como input, y la respuesta proporcionada por el CAU sería el ‘shot’ o respuesta de aprendizaje, a mayores del tunning. Esto requiere una transformación exhaustiva del contenido, dada la importancia del filtrado de contenido inapropiado, como datos de usuario, lenguaje informal, derivaciones de la conversación, etc. Aunque este hecho es relevante, se suma a otros que finalmente han desencadenado descartar esta opción. Para empezar, dado el tamaño del archivo con el que se pretende trabajar, es imposible descargarlo, debido a que es capaz de colapsar cualquier ordenador desde el que se pretenda obtener. A pesar de esto, se descargó otro archivo de prueba con un pesaje significativamente menor y cargarlo en el entorno de trabajo. Incluso con las librerías existentes para trabajar este formato (‘emailparser’), no es fácil de proceder. El archivo, el cuál puede contener documentos, se encuentran codificados de manera ilegible y unidos a la respuesta. Aunque consiguiésemos filtrar únicamente preguntas y respuestas, como ya se ha mencionado, la existencia de lenguaje informal, datos personales y otras van prácticamente a imposibilitar esta tarea Una recopilación más formal probablemente pueda ser llevada a través de la página web ‘digital.uva.es’. Para ello, recurriendo a ‘bs4’ (BeautifulSoup4), librería dedicada para webscrapping, vamos a recorrer la página principal y todos sus subapartados. Haciendo uso de esta librería junto con ‘request’, podemos extraer todos los ‘hrefs 1 ’, y analizar de manera recursiva la página completa. Posteriormente categorizaremos estos enlaces en los diferentes tipos. Se han encontrado enlaces a PDF’s (manuales y guías para usuarios), PNG’s (fotos explicativas de procesos digitales) y subapartados de la página que contengan información relevante. Con esto logramos un script que automatiza la descarga de los documentos indexados por la página, y las propias páginas de las que extraeremos la información necesaria. Este proceso como método de extracción de información resulta más adecuado, dado que a medida que la página se mantenga en constante actualización, podrá volver a ejecutarse el código para disponer de la misma. Una vez realizada la obtención de dichos ‘html’, para subirlos al repositorio de Copilot Studio, en caso de contener información relevante, será necesario convertirlos a texto. Estéticamente quedarán feos, pueden contener espacio o ‘enters’ innecesarias, prescindiendo de las fotos también, pero contendrán la información útil necesaria para responder a los usuarios. Este proceso de conversión también se ha automatizado en el entorno de trabajo, y guardando los .txt en un directorio aparte. 3.1.2.3 RETRIEVAL AUGMENTED GENERATION (RAG) Retrieval Augmented Generation es una técnica de inteligencia artificial que mejora la calidad de la IA generativa al permitir a los grandes modelos de lenguaje (LLM) aprovechar 1 HREF es el atributo utilizado en las páginas HTML que contiene la dirección real de un enlace. 17 recursos de datos adicionales sin necesidad de volver a entrenarlos. [9]La idea es aplicar dicha técnica a la documentación que se pretende utilizar. De una manera simplificada: La técnica de RAG ayuda a los LLM a proporcionar respuestas más precisas y relevantes al combinar la generación de texto con la recuperación de información de fuentes de datos adicionales. ¿Cómo funciona? • Recuperación: Se utiliza la consulta del usuario para buscar información relevante en una fuente de datos externa, como una base de conocimientos o un conjunto de documentos. • Generación: El LLM utiliza la información recuperada como contexto para generar una respuesta personalizada para el usuario. Beneficios de RAG: • Mayor precisión y relevancia: Las respuestas del LLM se basan en información real y verificada. • Mejora en la fluidez y coherencia: La información recuperada ayuda al LLM a generar respuestas más completas y mejor estructuradas. • Mayor diversidad de respuestas: El LLM puede acceder a una gama más amplia de información para generar respuestas más variadas. • Ahorro de tiempo y recursos: No es necesario volver a entrenar el LLM para añadir nueva información. Aplicaciones de RAG: • Atención al cliente: Generar respuestas personalizadas a las preguntas de los clientes. • Resumen de documentos: Extraer información clave de documentos largos y generar resúmenes concisos. • Creación de contenido: Generar textos creativos, como poemas, artículos o guiones. • Traducción: Mejorar la precisión y fluidez de las traducciones automáticas. 3.1.2.4 IMPLEMENTACIÓN OAUTH OAuth (Open Authorization) es un protocolo de autorización estándar abierto que permite a los usuarios conceder a aplicaciones de terceros el acceso a sus recursos en otros sitios web, sin tener que compartir sus credenciales de inicio de sesión. Esto significa que puedes permitir que una aplicación acceda a tu información de Facebook, por ejemplo, sin tener que darle tu contraseña de Facebook. El proceso de OAuth se basa en la idea de tokens de acceso. Un token de acceso es una cadena de caracteres única que se otorga a una aplicación después de que el usuario ha autorizado el acceso a sus recursos. La aplicación puede utilizar este token para acceder a los recursos del usuario en el sitio web del proveedor de servicios, como Facebook o Google. Este proceso se puede dividir en cuatro pasos: • Solicitud de autorización: El usuario inicia el proceso visitando la aplicación de terceros. La aplicación entonces redirige al usuario al sitio web del proveedor de servicios. 18 • Autorización del usuario: El usuario ve una lista de los recursos a los que la aplicación solicita acceso y decide si conceder o denegar el acceso. • Emisión del token de acceso: Si el usuario concede el acceso, el proveedor de servicios emite un token de acceso a la aplicación. • Acceso a los recursos: La aplicación utiliza el token de acceso para acceder a los recursos del usuario en el sitio web del proveedor de servicios. OAuth tiene varios beneficios, incluyendo: • Mayor seguridad: Los usuarios no tienen que compartir sus credenciales de inicio de sesión con aplicaciones de terceros, lo que reduce el riesgo de robo de identidad y fraude. • Mejor experiencia del usuario: Los usuarios pueden autorizar el acceso a sus recursos de forma granular, lo que les da un mayor control sobre su privacidad. • Mayor facilidad de uso: OAuth es un protocolo estándar, lo que facilita a los desarrolladores de aplicaciones implementar la autorización. OAuth se utiliza en una amplia variedad de aplicaciones: • Inicio de sesión social: Permite a los usuarios iniciar sesión en aplicaciones utilizando sus cuentas de redes sociales, como Facebook o Google. • Aplicaciones móviles: Permite a las aplicaciones móviles acceder a la información del usuario en otros sitios web, como listas de contactos o calendarios. • API: Permite a las aplicaciones acceder a datos y funcionalidades de otros sitios web. Durante la exploración de Copilot Studio como solución al problema, esta herramienta se llegó a implementar, pensando en que el chatbot fuese público, pero dirigido exclusivamente para usuarios de la universidad. 3.1.3 DIALOGFLOW DE GOOGLE CLOUD Dialogflow es otra plataforma de desarrollo de chatbots que permite crear interfaces de usuario conversacionales para aplicaciones móviles, aplicaciones web, dispositivos, bots, sistemas de respuesta de voz interactiva (IVR) y más. Utiliza la tecnología de comprensión del lenguaje natural (PLN) de Google para comprender el significado de las consultas de los usuarios y responder de forma precisa y relevante. También se puede utilizar Dialogflow para crear chatbots que puedan generar respuestas de voz natural. Dialogflow es una herramienta flexible que se puede utilizar para crear una amplia gama de chatbots, desde simples bots de preguntas frecuentes hasta chatbots conversacionales complejos que pueden mantener una conversación con un usuario. Entre sus características más destacables o mencionables podríamos hablar de: 1. Potente motor de procesamiento del lenguaje natural (PLN): • Dialogflow utiliza un motor de PLN para comprender el lenguaje natural de los usuarios y responder de forma precisa y relevante. • Soporta una amplia gama de idiomas, incluyendo español, lo que lo hace ideal para proyectos de atención al cliente multilingües. 2. Entorno de desarrollo intuitivo: • Dialogflow proporciona una interfaz gráfica de usuario intuitiva que facilita la creación de chatbots sin necesidad de conocimientos de programación. • Permite crear flujos de conversación complejos mediante guionizado. 19 • Ofrece herramientas para la gestión de entidades y variables, lo que permite flujos más personalizados. 3. Integración con Google Cloud Platform: • Dialogflow se integra con Google Cloud Platform (GCP), sin la necesidad de realizar cambios. • Se puede integrar un chatbot con otros servicios de GCP como Dialogflow CX, Contact Center AI, Cloud Functions y Cloud Storage para generar embeddings o ampliar capacidades. Esta integración facilita la creación de chatbots escalables y robustos. 3.2 CHATBOTS BASADOS EN PROCESADO DE LENGUAJE NATURAL (NLP) Los chatbots sustentados en NLP son sistemas que simulan una conversación con humanos utilizando técnicas de procesamiento del lenguaje natural implementado muy frecuentemente mediante redes neuronales. Estos chatbots son cada vez más populares en diversas áreas como atención al cliente, educación, marketing y entretenimiento. Técnicas clave de NLP: El Procesamiento del Lenguaje Natural (NLP) es un campo interdisciplinario que se enfoca en la interacción entre ordenadores y el lenguaje humano. A continuación, se detallan algunas de las técnicas clave que sustentan este campo: • Análisis sintáctico: Se utiliza para comprender la estructura de una oración, identificando sus componentes (sustantivos, verbos, adjetivos, etc.) y sus relaciones. • Análisis semántico: Se centra en el significado de las palabras y frases dentro del contexto de la conversación. • Análisis pragmático: Se encarga de la intención del usuario detrás de la oración, considerando el contexto social y las relaciones entre los participantes. Arquitectura de un chatbot basado en NLP: define la estructura y la interacción de los diferentes componentes que permiten al chatbot comprender, procesar y generar respuestas humanas. Esta arquitectura suele variar dependiendo de la complejidad del chatbot y de las tecnologías utilizadas, pero en general, podemos identificar los siguientes componentes principales: • Módulo de entrada: Recibe la entrada del usuario, ya sea texto o voz. • Procesamiento del lenguaje natural: Aplica las técnicas mencionadas para comprender la entrada del usuario. • Generación de la respuesta: Crea una respuesta natural y coherente a la consulta del usuario. • Módulo de salida: Envía la respuesta al usuario en el formato adecuado (texto, voz, etc.). Tecnologías clave para chatbots: Los chatbots, como interfaces conversacionales basadas en inteligencia artificial, se sustentan en una combinación de tecnologías que les permiten comprender, procesar y generar lenguaje humano de forma natural: • Redes neuronales profundas: Permiten a los chatbots aprender de grandes cantidades de datos y mejorar su capacidad de comprensión y generación de lenguaje. • Machine learning: Se utiliza para entrenar modelos de lenguaje que predicen la siguiente palabra o frase en una conversación. • Bibliotecas de NLP: Ofrecen herramientas pre-entrenadas para tareas como análisis sintáctico, análisis de sentimiento, lematización, extracción de entidades, etc. 20 Desafíos técnicos: el desarrollo de chatbots presenta una serie de desafíos técnicos que desarrolladores buscan superar constantemente: • Ambigüedad del lenguaje: El lenguaje natural es complejo y puede ser interpretado de diferentes maneras. • Falta de datos: Entrenar modelos de NLP requiere grandes cantidades de datos de alta calidad. • Sesgo: Los modelos de NLP pueden reflejar sesgos presentes en los datos con los que fueron entrenados. Los chatbots basados en NLP son una tecnología en constante evolución con un gran potencial para mejorar la interacción entre usuarios y máquinas. 3.2.1 CHATBOTS BASADOS EN LLM Los chatbots fundados en LLM son una nueva generación de chatbots que utilizan ‘modelos de lenguaje grandes' (LLM) para generar respuestas más espontáneas y atractivas. Parten de arquitecturas de redes neuronales profundas entrenadas con grandes cantidades de datos de texto, lo que permite comprensión y generación de lenguaje humano con un alto nivel de precisión. Ventajas de los chatbots cimentados en los LLM: • Respuestas más naturales y atractivas: Pueden generar respuestas que son más fluidas, coherentes y relevantes que las de los chatbots tradicionales. • Mejor comprensión del lenguaje natural: Son capaces de comprender mejor el significado de las consultas de los usuarios, incluso si son ambiguas o incompletas. • Capacidad de aprendizaje: Por último, estos pueden aprender de sus interacciones con los usuarios y mejorar su rendimiento con el tiempo. Desafíos para este tipo de chatbots: • Costo: Costosos de entrenar y ejecutar por la cantidad de recursos necesarios. • Sesgo: Existe la posibilidad de que puedan reflejar sesgos presentes en los datos con los que fueron entrenados. • Seguridad: Pueden ser utilizados para generar contenido malicioso a pesar de poder limitar temas. 3.2.2 MODELOS FUNDACIONALES LLM LLM o Modelos de Lenguaje de Grande, son redes neuronales profundas que han sido entrenados en enormes cantidades de texto. Estos modelos aprenden las complejidades del lenguaje humano, como la gramática, el significado y hasta ciertos aspectos del contexto. Es importante mencionar los diferentes parámetros, funciones y datos que influyen en el comportamiento del modelo y que pueden condicionar sus capacidades finales. Los datos de entrenamiento constituyen el pilar fundamental sobre el cual se erigen los LLM. Estos conjuntos de datos, vastos y diversos, actúan como base de aprendizaje para los algoritmos, proporcionándoles la información necesaria para adquirir las habilidades lingüísticas que los caracterizan. A través de un proceso iterativo de exposición y ajuste, los LLM extraen patrones, estructuras y significados del lenguaje natural. Es por ello la importancia de los datos usados: 21 • Cantidad: Los LLMs requieren grandes cantidades de datos, generalmente terabytes o petabytes. Estos datos son textos, en diferentes idiomas, en función de los que se pretenda que el LLM pueda hablar. Cuanto más grande sea el conjunto de datos, mayor será la capacidad del modelo para generar texto coherente y relevante. • Variedad: Los datos deben ser diversos en cuanto a temas, estilos y géneros para un mejor rendimiento y así evitar que el modelo pueda especializarse en un tema. Este conjunto de datos puede provenir de grandes colecciones de libros digitalizados, artículos de noticias, enciclopedias, foros y redes sociales y hasta código fuente. Con esto se consigue que la respuesta pueda adaptarse a casi cualquier ambiente. • Calidad: Los textos deben ser coherentes, gramaticalmente correctos y representativos del lenguaje natural. Datos de baja calidad pueden introducir sesgos y errores en el modelo. Parámetros adicionales: • Tokens: Unidades básicas de información que el modelo procesa, como palabras, subpalabras o caracteres. El tamaño del token afecta la granularidad del procesamiento del lenguaje. • Parámetros: Variables que el modelo aprende durante el entrenamiento. Un mayor número de parámetros permite al modelo aprender relaciones más complejas. Parámetros relacionados con la generación de texto: • Temperatura: Controla la creatividad del modelo durante la generación de texto. Una temperatura alta genera texto más creativo y variado, pero también puede ser menos preciso. • Top K: Limita el número de tokens que el modelo considera durante la generación de texto. Un valor de K alto reduce la diversidad del texto generado, pero lo hace más preciso. • Beam Search: Técnica que busca la mejor secuencia de tokens posible durante la generación de texto. • Nucleus Sampling: Técnica que da más peso a los tokens más probables durante la generación de texto. Otras técnicas avanzadas para conseguir comportamientos más precisos y respuestas más personalizadas pueden ser: • Dropout: Técnica para evitar que el modelo se sobreajuste a los datos de entrenamiento. El dropout consiste en desactivar aleatoriamente algunas neuronas durante el entrenamiento. • Embedding: Técnica para convertir palabras en vectores numéricos que el modelo puede procesar. Los embeddings se utilizan para representar el significado semántico de las palabras. • Normalización: Técnica para evitar que los valores de las activaciones de las neuronas se vuelvan demasiado grandes o demasiado pequeñas. Tamaño de ventana: • Define la cantidad de contexto que el modelo considera al procesar una palabra o frase. Un tamaño de ventana más grande permite al modelo tener una mejor comprensión del contexto. • El tamaño de ventana puede ser fijo o variable, y su elección depende de la tarea específica para la que se está entrenando el LLM. 22 Importante comentar la arquitectura de los LLM. Estos pueden ser monolíticos o de "Mixture of Experts" (MoE). A continuación, realizaremos una pequeña comparativa entre ellos para comprender sus diferencias y características: Los LLM monolíticos se implementan como un único modelo grande, mientras que los LLM "Mixture of Experts" se dividen en varios modelos más pequeños, cada uno con un propósito específico. Ventajas de los LLM monolíticos: • Más simples de desarrollar e implementar: No se requiere una compleja orquestación de múltiples modelos. • Más fáciles de entrenar: Se puede entrenar un solo modelo con un conjunto de datos único. Desventajas de los LLM monolíticos: • Menos escalables: Dificultad para aumentar la capacidad a medida que crece la demanda. • Menos flexibles: Dificultad para adaptar el modelo a diferentes tareas o dominios. • Más difíciles de mantener: Dificultad para corregir errores o actualizar el modelo. Ventajas de los LLM "Mixture of Experts": • Más escalables: Se pueden escalar individualmente los diferentes microservicios. • Más flexibles: Se pueden adaptar los diferentes microservicios a diferentes tareas o dominios. • Más fáciles de mantener: Se pueden corregir errores o actualizar individualmente los diferentes microservicios. Desventajas de los LLM "Mixture of Experts": • Más complejos de desarrollar e implementar: Se requiere una compleja orquestación de múltiples arquetipos. • Menos eficientes en cuanto a recursos: Varios modelos consumen más recursos que un solo modelo grande. • Más difíciles de entrenar: Se requiere entrenar diferentes modelos con diferentes conjuntos de datos. Dadas estas características, hubiese sido más oportuno el uso de un LLM MoE, para haber adaptado el modelo a diferentes tareas que se demandarán. 3.2.2.1 API DE MODELOS EXISTENTES Las API a LLM ya funcionales, sean Open Source en plataformas que permiten su uso, o de pago (Close Source), entendiéndose toda la variedad de opciones que se van a comentar en este estudio, pueden usarse para crear chatbots más flexibles y naturales que los apoyados en caminos lógicos. Estas API permiten a los desarrolladores interactuar con LLM grandes para generar texto, traducir idiomas, escribir diferentes tipos de contenido creativo y responder a preguntas de forma informativa. Las API para LLM funcionales tienen una serie de ventajas sobre los sustentados en caminos lógicos. En primer lugar, pueden responder a preguntas o comentarios que no estén previstos en el árbol de decisiones. En segundo lugar, pueden generar respuestas más naturales y relevantes. En tercer lugar, son más fáciles de actualizar y mantener. Por último, al no ser modelos Open Source no es posible realizar un proceso de fine-tunning con la 23 documentación adecuada, lo que puede aumentar el uso de contexto si se desean proporcionar instrucciones. A continuación, se presentan algunos ejemplos de API para LLM ya existentes: • OpenAI GPT-4o API: Esta API permite a los desarrolladores interactuar con GPT-4o, un LLM grande desarrollado por OpenAI. GPT-4o puede generar texto, traducir idiomas, escribir diferentes tipos de contenido creativo y responder a preguntas de forma informativa. • Google AI LaMDA API: En este caso, para interactuar con LaMDA, un LLM grande desarrollado por Google AI. De manera similar LaMDA puede generar texto, traducir idiomas, escribir diferentes tipos de contenido creativo y responder a preguntas de forma informativa. • Hugging Face Transformers API: Hugging face permite realizar prompts a todos sus modelos disponibles, entre los que se encuentran modelos mencionados. El uso de alguno de estos modelos sería interesante dadas las enormes capacidades que tienen. Aunque no sea posible realizar ningún entrenamiento sobre estos modelos es probable que con un buen uso del prompt se consigan resultados esperados. 3.2.2.2 MODELOS OPEN SOURCE Los modelos de código abierto como LlaMa o Vicuña brindan una serie de ventajas sobre los modelos propietarios. En primer lugar, son más accesibles. Cualquier persona puede descargarlos y utilizarlos sin necesidad de pagar una licencia. En segundo lugar, son más transparentes. El código fuente está disponible para que cualquiera lo revise y contribuya. En tercer lugar, son más flexibles. Pueden ser personalizados para adaptarse a diferentes necesidades. Existen una serie de modelos open Source, de los cuales comenzaremos comparando LlaMa 2, al haber sido de los primeros en liberarse. A medida que los arquetipos de lenguaje continúen desarrollándose, es probable que veamos un aumento en el uso de modelos de código abierto. En febrero 2024, los 5 LLM Open Source más potentes que se plantearon para la realización del proyecto fueron: • LlaMa 2 70B • Florecer (bloom) • MPT-7B • Halcón • Vicuña-13B 24 ILUSTRACIÓN 1: BANCO DE PRUEBAS CON DIFERENTES MODELOS ILUSTRACIÓN 2: COSTE COMPUTACIONAL DE ENTRENAR LLAMA 2. Esta figura representa el tiempo utilizado para el entrenamiento total del modelo, utilizando como GPU de referencia una NVIDIA A100, con una VRAM de 80Gb y un precio aproximado de en torno a 12.000€. Con esta referencia podemos llegar a la conclusión de que el proceso de fine-tunning de una manera aproximada también va a ser costoso a nivel computacional. Sin embargo, debemos replantearnos si es razonable trabajar con un modelo de 70B de parámetros, dado que, para cargarlo de manera completa, sin tamaño reducido, es decir, a 4bytes, serían necesarios 70B x 4bytes = 280Gb de VRAM. No cargarlo entero, o en un tamaño reducido supondría una pérdida de rendimiento y/o velocidad: tanto en funcionamiento como en velocidad de entrenamiento (fine-tune). Con los datos mencionados anteriormente estimar el gasto de un equipo que mantenga este sistema sería exorbitado. Por lo tanto, el siguiente punto será buscar y encontrar un modelo que pueda mantener un rendimiento similar, reduciendo lo máximo posible el ‘peso’ de este. En el momento actual, en el que se estaban investigando ‘Mistral 7B’, modelos muy eficientes que mezclan partes de otra serie de modelos, se ha producido la liberación de un nuevo modelo por parte de Google, ‘Gemma 2B’ (22/02/2024). Compararemos ‘benchmarks’, o pruebas de rendimiento en diferentes categorías para ambos, y evaluaremos si son capaces de cumplir con el propósito de este proyecto. Respectivamente, ambos modelos podrían cargarse enteros en una GPU con 28 y 8Gb (~9,5) de VRAM, lo que permite a este último poder ser cargado en casi cualquier tarjeta gráfica actual. No solo el modelo ocupa una cierta cantidad de VRAM por su cantidad de parámetros, además, el número de tokens a procesar es lineal a la memoria física requerida (RAM). Sin embargo, Mistral utiliza una técnica “Sliding Window Attention” que permite focalizar el input, y reducir estos recursos [3]. [11]. En todos los modelos de 7 billones de parámetros, Mistral demuestra el mejor rendimiento. Sin embargo, 25 hay poca documentación acerca de Gemma 2 , más allá de las pruebas que podemos realizar nosotros mismos en plataformas como Hugging face. En esta misma plataforma, el canal “Prompt Engineering”, en el video “How Bad is Gemma Compared to Mistral?”, demuestra de manera práctica la superioridad de Mistral contra Gemma, en la versión de 7B, con preguntas de razonamiento y lógica, incluyendo desde el ámbito matemático hasta el ético. ILUSTRACIÓN 3: COMPARATIVAS DE MISTRAL CON MODELOS DE DIFERENTES TAMAÑOS Podemos ver como Mistral consigue mejores resultados que modelos más ‘pesados’, por lo que en este punto podríamos considerar que en el momento actual es el modelo con mejor desempeño. 3.2.3 SOLUCIONES CLOUD IA El Cloud Computing, también conocido como computación en la nube o simplemente "la nube", es un paradigma de la tecnología de la información que ofrece acceso bajo demanda a recursos informáticos como servidores, almacenamiento, redes, software, bases de datos, análisis e inteligencia artificial a través de Internet. En términos más simples: • No necesitas tener tu propia infraestructura: Al contrario que en el pasado, donde las empresas tenían que comprar y mantener sus propios servidores y software, la nube permite "alquilar" estos recursos a un proveedor. • Pagas por lo que usas: Se utiliza un modelo de pago por uso, lo que significa que solo pagas por los recursos que consumes. • Acceso desde cualquier lugar: Puedes acceder a tus datos y aplicaciones desde cualquier lugar y en cualquier momento con una conexión a internet. A pesar de que cuando nos referimos al Cloud, suele ser implícito hacer referencia a los grandes proveedores, hay más tipos de Cloud: • Nube pública: La infraestructura es propiedad y está gestionada por un proveedor de servicios en la nube, como Amazon Web Services (AWS), Microsoft Azure o Google Cloud Platform (GCP). Es la opción más económica y escalable, pero ofrece menos control y personalización [12]. 2 https://huggingface.co/chat/settings/google/gemma-7b-it 32 • Correo externo (opcional): pedro.lop[email protected]m • Correo interno (opcional): NA Si en la resolución del problema hiciesen falta datos que no estuviesen mencionados en el mensaje se respondería al usuario con un mensaje solicitándolos. En general, todo problema se resuelve con una serie iterativa de comprobaciones y obtención de datos faltantes. Para codificar estos procedimientos, en este proyecto se propone utilizar un formato de texto plano en lenguaje natural que describa el curso de la resolución. Por ejemplo, para el problema “Recuperación de contraseña” se pueden definir la serie de pasos disponibles para diagnosticar en un guion de soluciones, como se describe en el apartado 6.3.1. 5.1.2.1 DIAGNÓSTICO 1: FUNCIONAMIENTO DE LOS SERVICIOS. Se deben de diagnosticar para este caso que los servicios LDAP y campus virtual están funcionando correctamente. Estos son los servicios descritos en las instrucciones para dicho problema. El modelo responderá con un archivo json que contiene las URL mencionadas en las instrucciones para la fase de resolución identificada, y el código de control las usará para realizar las peticiones y obtener los códigos de estado que serán añadidos al contexto en la siguiente iteración. El modelo interpretará los códigos de estado. • Códigos incorrectos: Se deben interpretar los códigos de la comprobación y dar una respuesta al usuario. Por ejemplo, ‘503’ Internal Server error. Servicio caído. • Códigos correctos: Los códigos de estado O.K. son ‘200’. Leer los atributos devueltos en el JSON, añadirlos al contexto del problema y proceder al siguiente paso del diagnóstico. 5.1.2.2 DIAGNÓSTICO 2: CONSULTAS EN BASES DE DATOS. En este punto que ya se ha descartado que el problema fuese debido al estado de algunos de los servicios se debe proceder obteniendo información relevante del usuario. Es el modelo el que lo descarta al interpretar que los códigos son correctos (200). En este caso se buscarán el perfil en LDAP, y algún dato extra como la situación de la persona (PAS, PDI, estudiante, alta temporal, etc). Por ejemplo, el operador del CAU ejecutaría la siguiente petición: https://trots.es/api-v2.0/users/tfg-api.php/?user=PedroLopez El operador observa las respuestas de los servicios y añade los atributos al contexto del problema. 5.1.2.3 RESOLUCIÓN: MENSAJE AL USUARIO Consideremos un ejemplo en el que el problema radica en que el correo conocido por el sistema (según se devuelve en las llamadas a los endpoints) y el utilizado por el usuario no coinciden. Este caso es relativamente habitual y puede deberse a que en el momento del registro inicial se cometió un error tipográfico, que no se recuerde el mail usado, o en el caso de alumnos de nuevo ingreso, que haya sido algún familiar el que realizó el trámite usando su dirección. A continuación, se muestra la respuesta que el CAU suele generar para este caso: Estimado Pedro López, 33 Gracias por ponerte en contacto con el Centro de Atención al Usuario de la Universidad de Valladolid. Hemos revisado tu perfil de usuario y hemos encontrado que hay una discrepancia en los correos electrónicos. Según nuestros registros, el correo registrado es "pedro.l[email protected]m". Para resolver este problema, dado que tu caso es el de una alta temporal, te pedimos que envíes un correo a [email protected]s adjuntando una foto de tu DNI para verificar tu identidad. Una vez recibida y verificada la identificación, te proporcionaremos un enlace para corregir esta información. Si necesitas más información o tienes alguna otra duda, no dudes en ponerte en contacto con nosotros. Atentamente, Centro de Atención al Usuario (CAU) Universidad de Valladolid Este es el comportamiento deseado para el asistente basado en LLM. 6 DISEÑO DEL PROYECTO. Tras el análisis de como el problema ha sido enfocado toca pasar a la fase de diseño. Durante esta fase se exploró la alternativa de Copilot Studio y se vio que no satisfacía los requisitos. A continuación, se ha explicado cómo se ha desarrollado el proyecto, con el requisito de la creación de una API que simulará ser una base de datos de la universidad. El proyecto cuenta de 3 partes como se refleja en la Ilustración 5: Diseño del proyecto ILUSTRACIÓN 5: DISEÑO DEL PROYECTO Estas partes son el LLM y las bases de datos de usuarios, que se relacionan a través del controlador. El LLM es el corazón de este proyecto. Usando Azure, el endpoint se conectará a una implementación de GPT-4o, cuya función será recibir el prompt y generar una respuesta. 34 Haciendo uso de la ingeniería del prompt, explotaremos la capacidad del modelo para cumplir instrucciones y redactar respuestas de una manera natural. El acceso a las bases de datos de usuarios se realizará mediante un servicio REST. La función de este servicio es devolver un archivo JSON con la información del usuario solicitado. Se realizará mediante el método GET y usando el atributo ‘user’. El controlador actuará como intermediario, recibirá el mensaje del usuario para componer el prompt, analizará la respuesta, usará los datos extraídos para realizar consultas en la base de datos, leerá instrucciones, añadirá todo este contexto para volver a componer prompts, y devolverá la respuesta final. 6.1 COMPONENTES DEL SISTEMA El sistema se ha diseñado siguiendo una arquitectura cliente-servidor, separando el frontend del backend para facilitar futuras implementaciones. • El backend del sistema ha sido implementado utilizando Flask, un framework web ligero y versátil para Python. La API backend implementa el controlador del proyecto y se encarga de una serie de pasos: recibir el problema del usuario, enviarlo una primera vez al LLM, solicitando al este modelo que genere un documento JSON con los datos que el usuario ha proporcionado, posteriormente con el problema extraído se leerán las instrucciones correspondientes, donde será necesario comprobar servicios y posteriormente realizar una consulta a una base de datos. Añadiendo al contexto (instrucciones del problema) el estado de los servicios y la información obtenida de la base de datos mencionada, el modelo será capaz de identificar la cuestión del problema (puede haber situaciones excepcionales no contempladas, que podrían añadirse posteriormente), leyendo las instrucciones y los datos necesarios, y devolver una respuesta apropiada. • Como componente central de nuestro sistema, hemos integrado el modelo de lenguaje GPT-4o de OpenAI en la plataforma Azure. Al configurarlo en 25k tokens por minuto (El contexto del modelo es superior pero se limita de esta manera para no generar demanda excesiva), hemos ampliado significativamente su capacidad para mantener y procesar información a largo plazo ya que el modelo puede mantener un contexto de conversación grande, lo que le permite generar respuestas más coherentes y relevantes a medida que la interacción evoluciona. Durante el ciclo iterativo el contexto va a crecer por lo que es necesario disponer de un modelo que pueda soportarlo. • Endpoints: Estos servicios REST, exponen un punto de acceso a una base de datos de usuarios. El servicio procesa la petición y devuelve un objeto JSON con los datos del usuario solicitado. Ha sido generada para este proyecto como una API en (https://trots.es/api-v2.0/), que simularía ser el LDAP utilizado por el CAU. 6.2 API’S Y LDAP Durante el desarrollo y pruebas del proyecto se implementó un simulador de endpoints REST para emular los servicios que, en un entorno de producción, proporcionarán la información necesaria al sistema. Estos endpoints se desplegaron en una IP pública accesible desde el controlador del chatbot. Para ello se ha utilizado la CDN de Cloudflare en un dominio personal que cuenta con certificado de seguridad y por lo tanto utiliza un canal seguro HTTPS. Esta API REST se ha desarrollado en PHP. 35 Los servicios toman un parámetro ‘user’ para identificar el usuario. Se han creado 5 usuarios de prueba con datos falsos. La URL para la API, con un usuario de ejemplo es el siguiente: https://trots.es/api-v2.0/users/tfg-api.php/?user=JuanGomez https://trots.es/api-v2.0/colectivo/tfg-api.php/?user=JuanGomez Un ejemplo del formato JSON que devolverá esta API con datos de usuario será: { "nombre": "Juan Gómez Rodríguez", "email": "juan.gome[email protected]", "ID": "e345678901X " } Por supuesto, en un entorno real de explotación, los endpoints que se usarán serán los que realmente realizan las consultas a los sistemas de la universidad. Los endpoints que se utilizan se especificarán en lenguaje natural en el documento de resolución de incidencias cuya estructura veremos en 6.3.1. por lo que el sistema es totalmente adaptable a otros casos reales. 6.3 DISEÑO DEL SISTEMA El objetivo es aprovechar al máximo las capacidades de generar texto predictivo del LLM para reducir el código tradicional al mínimo, agilizando el desarrollo y aumentando la flexibilidad del sistema Para ello se ha diseñado un sistema basado en un controlador iterativo que utiliza a un LLM para tomar todas las decisiones de acuerdo con una descripción textual del procedimiento. Este controlador se encargará de suministrar al LLM prompts cuidadosamente diseñados, delegando en él la toma de decisiones en cada etapa del proceso. La clave de este enfoque reside en la capacidad del LLM para comprender y ejecutar instrucciones complejas a partir de prompts bien formulados. Mediante la ingeniería del prompt, lograremos que el modelo no solo genere texto, sino que realice tareas específicas como estructurar datos o tomar decisiones lógicas. 6.3.1 DOCUMENTO DE RESOLUCIÓN DE PROBLEMAS La redacción del documento es una parte fundamental en la resolución del problema. Aunque se describe en lenguaje natural, lo que permite a gente sin conocimientos en programación contribuir a la resolución de nuevos problemas, debe redactarse cuidadosamente. De lo contrario es fácil que el modelo pueda entrar en bucle o no ser capaz de seguir las instrucciones. Fase: estado de servicios. Se deben comprobar si los siguientes servicios están funcionando correctamente: - Campus virtual: https://campusvirtual.uva.es/ - LDAP: https://ldapapps.uva.es/ - APPS STIC: https://apps.stic.uva.es/preinsmaster/ Si algún servicio no funciona ('fases comprobadas'), salta a la fase 'resolución' y redacta el mensaje al usuario comentando que se trata de un 36 problema técnico temporal. Si todos los servicios anteriores funcionan, pasamos a la fase 'comprobación 1' Fase: comprobación 1 realizar las siguientes consultas de datos: - perfildeusuario: https://trots.es/api-v2.0/users/tfgapi.php/?user={username} - diagnostico1: https://trots.es/api-v2.0/colectivo/tfgapi.php/?user={username} sustituye los parámetros que fuesen necesarios Fase: resolución. Redactar una respuesta para el usuario como CAU Universidad de valladolid con el diagnóstico: Si no existe identificador en perfildeusuario, el problema es que el usuario no pertenece a la UVa. Si el colectivo es estudiante y en diagnostico1 hay 0 créditos matriculados el problema es que el usuario no está matriculado en ninguna asignatura. Si el colectivo es profesor y diagnostico1 es negativo el problema es que el profesor no está registrado en el el POD adecuadamente y tiene que consultar con la secretaría administrativa de su departamento. Si ninguna de las causas contempladas ha generado el problema responde que se investigará el problema. Responde de manera concisa con el motivo del problema como si estuvieses contestando al usuario. Es importante por ello observar que hay una serie de marcadores de texto que se mencionan internamente como puede ser: • Secciones de resolución llamadas fases. • Comprobaciones a realizar en determinadas URLs. • Condiciones para cambio de fase. • Condiciones en caso de no encontrar un motivo del problema. • Instrucciones precisas. Al momento de añadir el contexto, usar los mismos tokens de la fase correspondiente ayuda al modelo a generar una relación para comprender las instrucciones. (‘perfildeusuario’ ‘diagnostico1’) 6.3.2 ALGORITMO Cada vez que se procese un mensaje en el sistema, se ejecutará el diagrama de flujo que se ve en la Ilustración 6: Diagrama de flujo del controlador 37 Ilustración 6: Diagrama de flujo del controlador En éste, podemos diferenciar 3 fases: 6.3.3 FASE 1: ANÁLISIS DEL MENSAJE En la primera fase se pretende procesar el mensaje mediante el LLM para identificar el tipo de problema que se describe y obtener algunos datos básicos. Primero se obtienen del directorio de configuración la lista de documentos de texto donde se describen los tipos de problemas documentados y su flujo de resolución. El nombre de los documentos de problemas tiene que ser suficientemente descriptivo. Después se confecciona un prompt que contiene la lista de los nombres de los problemas y que pide al LLM que identifique el 38 problema entre estas opciones. El prompt contiene también unas instrucciones predefinidas para que la respuesta del LLM sea un documento tipo JSON con la información extraída del mensaje del usuario. En todos los casos el prompt es una concatenación del mensaje del usuario, y las instrucciones que buscamos sobre dicho mensaje (‘chatrole’): problemas = [archivo for archivo in os.listdir('openai/data/') if archivo.endswith(".txt")] chatrole = f"Eres un programador que va a devolver unicamente un archivo json con información extraída del prompt. Omite incluir ```json... & ```. Necesito que devuelvas 'Nombre': Contiene nombre y apellido del usuario.'username': Es 'Nombre' formateado, sin tildes ni espacios entre nombre o apellidos y con las iniciales en mayúsculas. 'mail-interno': correo proporcionado con dominio uva.es. 'mail-externo': correo proporcionado con un dominio diferente. 'Identificador': tiene el tipo e + NIF. el usuario puede proporcionar NIF o identificador. 'Problema': Se debe clasificar el problema del usuario en uno de entre los siguientes tipos {problemas}. 'sesionID': ID de la conversación. 'Datos': si hay información extra que pueda ser relevante para la resolución del problema añádela a modo de comentario explicativo. Los datos que no se proporcionen se deben rellenar como 'NA'." La información extraída puede contener los atributos ‘nombre’, ‘username’ (nombre formateado), ‘id’, ‘mail_interno’(dominio @uva.es), ‘mail_externo’, ‘problema’ (se pedirá al modelo que clasifique entre los propuestos), ‘sessionID’, y un elemento JSON llamado ‘datos’ que contendrá información que pueda ser relevante para la resolución del problema. Por ejemplo, en un problema con la tarjeta virtual universitaria, el elemento datos puede adoptar el valor “Tiene iPhone 14” ya que el hecho de que el usuario use un determinado modelo de termnial es relevante. El prompt se ha diseñado para maximizar la probabilidad de que el LLM identifique este tipo de información en el contexto que se está procesando. { "Nombre": "Isabel Martín", "username": "IsabelMartin", "mail-interno": "NA", "mail-externo": "[email protected]", "Identificador": "NA", "Problema": " ", "sesionID": " ", "Datos": " " } Si en la respuesta existe un atributo ‘sessionID’ significa que hubo mensajes previos del usuario que deberían considerarse también, por lo que el controlador, los leerá de su almacenamiento y se utilizarán para añadir información al contexto en el nuevo prompt (que por lo tanto tendrá cada vez un contexto más rico) y se repetirá el procesado del LLM. 6.3.4 FASE 2: ENRIQUECIMIENTO DE CONTEXTO A continuación, se ejecuta la fase ‘añadeContexto’ que es donde se va a intentar que el LLM indique al controlador como ejecutar la secuencia de resolución del problema y, finalmente, se generará una respuesta para el usuario en lenguaje natural. Con el parámetro ‘problema’ obtenido en la fase inicial, el controlador lee el fichero de texto correspondiente que contiene las instrucciones para diagnosticar y resolver el problema. Al componer el prompt de la primera iteración, ya se incluyen los datos que proporcionó el usuario (‘Fases comprobadas’): 39 Fase: estado de servicios. Se deben comprobar si los siguientes servicios están funcionando correctamente: - Campus virtual: https://campusvirtual.uva.es/ - LDAP: https://ldapapps.uva.es/ - APPS STIC: https://apps.stic.uva.es/preinsmaster/ Si algún servicio no funciona ('fases comprobadas'), salta a la fase 'resolución' y redacta el mensaje al usuario comentando que se trata de un problema técnico temporal.Si todos los servicios anteriores funcionan, pasamos a la fase 'comprobación 1' Fase: comprobación 1 realizar las siguientes colsultas de datos: - perfildeusuario: https://trots.es/api-v2.0/users/tfgapi.php/?user={username} - diagnostico1: https://trots.es/api-v2.0/colectivo/tfgapi.php/?user={username} sustituye los parámetros que fuesen necesarios Fase: resolución. Redactar una respuesta para el usuario como CAU Universidad de valladolid con el diagnóstico: Si no existe identificador en perfildeusuario, el problema es que el usuario no pertenece a la UVa. Si el colectivo es estudiante y en diagnostico1 hay 0 créditos matriculados el problema es que el usuario no está matriculado en ninguna asignatura. Si el colectivo es profesor y diagnostico1 es negativo el problema es que el profesor no está registrado en el el POD adecuadmaente y tiene que consultar con la secretaría administrativa de su departamento. Si ninguna de las causas contempladas ha generado el problema responde que se investigará el problema. Responde de manera concisa con el motivo del problema como si estuvieses contestando al usuario. Fases comprobadas: . Datos usuario: Isabel Martín, id:NA, mail interno:NA, mail externo:[email protected], username:IsabelMartin. La descripción del proceso de resolución se realiza mediante lenguaje natural con unas pequeñas restricciones de estructura que no interfieren con la interpretación humana. La estructura del documento se ha diseñado teniendo en cuenta que la resolución de un problema puede necesitar comprobaciones de servicios, consultas de datos del usuario, y 40 posteriormente la interpretación de los datos según dichas instrucciones. Todo esto deberá estar detallado y segmentado de manera lógica en forma de fases de resolución (ver 35). El número de fases no supondrá un problema para la IA ya que el proceso será iterativo. El algoritmo iterativo generará en cada fase un prompt con las instrucciones del problema y los datos que se han recopilado del usuario hasta ahora. chatrole = f"solo si la fase actual es 'resolución' elabora una respuesta para el usuario siguiendo las instrucciones como si fueses atención al usuario de la universidad de Valladolid. En cualquier otro caso, la respuesta debe de ser un archivo json que contenga un objeto con los servicios que hay que consultar en dicha fase: la clave es el nombre del servicio y el valor su url sustituyendo argumentos necesarios si los hubiese. Se sigue este patrón en función del número de enlaces que se hayan proporcionado. Omite el resto de instrucciones, se utilizarán en otro momento y omite incluir ```json... & ``. Deduce la fase actual de las comprobaciones proporcionadas al final" Si el problema requiere realizar algún tipo de comprobación, mediante el prompt, se instruye al LLM para que la respuesta sea un documento en formato JSON con la lista de servicios que sean necesarios ejecutar. { "Campus virtual": "https://campusvirtual.uva.es/", "APPS STIC": "https://apps.stic.uva.es/preinsmaster/" } Esto se produce porque en las instrucciones se indica que para estar en la fase siguiente de resolución necesita comprobar los estados de los sistemas “APPS STIC” y “Campus Virtual”. Como no existe mención a estos tokens en el contexto, el LLM sigue las instrucciones y genera un JSON con los servicios que están asociados en las instrucciones a esos tokens. Esto se describe con el fragmento: Fase: estado de servicios. Se deben comprobar si los siguientes servicios están funcionando correctamente: - Campus virtual: https://campusvirtual.uva.es/ - APPS STIC: https://apps.stic.uva.es/preinsmaster/ Si algún servicio no funciona ('fases comprobadas'), salta a la fase 'resolución' y redacta el mensaje al usuario comentando que se trata de un problema técnico temporal. Si todos los servicios anteriores funcionan, pasamos a la fase 'comprobación 1' Una vez testeados los servicios por el controlador, se incorporan los datos obtenidos al contexto en el siguiente prompt. Se añadirá a todo lo anterior los nuevos estados de los servicios o la información obtenida de ellos. Campus virtual: OK APPS STIC: OK De esta manera, las instrucciones ahora contendrán: Fase: estado de servicios. Se deben comprobar si los siguientes servicios están funcionando correctamente: - Campus virtual: https://campusvirtual.uva.es/ - APPS STIC: https://apps.stic.uva.es/preinsmaster/ Si algún servicio no funciona ('fases comprobadas'), salta a la fase 'resolución' y redacta el mensaje al usuario comentando que se trata de un 41 problema técnico temporal.Si todos los servicios anteriores funcionan, pasamos a la fase 'comprobación 1' Fase: comprobación 1 realizar las siguientes colsultas de datos: - perfildeusuario: https://trots.es/api-v2.0/users/tfgapi.php/?user={username} - diagnostico1: https://trots.es/api-v2.0/colectivo/tfgapi.php/?user={username} sustituye los parámetros que fuesen necesarios Fase: resolución. Redactar una respuesta para el usuario como CAU Universidad de valladolid con el diagnóstico: Si no existe identificador en perfildeusuario, el problema es que el usuario no pertenece a la UVa. Si el colectivo es estudiante y en diagnostico1 hay 0 créditos matriculados el problema es que el usuario no está matriculado en ninguna asignatura. Si el colectivo es profesor y diagnostico1 es negativo el problema es que el profesor no está registrado en el el POD adecuadmaente y tiene que consultar con la secretaría administrativa de su departamento. Si ninguna de las causas contempladas ha generado el problema responde que se investigará el problema. Responde de manera concisa con el motivo del problema como si estuvieses contestando al usuario. Fases comprobadas: . Datos usuario: Isabel Martín, id:NA, mail interno:NA, mail externo:[email protected], username:IsabelMartin. Fases comprobadas: Campus virtual: OK APPS STIC: OK Ahora el LLM será capaz de avanzar a la fase ‘comprobación 1’. En este punto las instrucciones indican que hay que comprobar los datos del usuario con otros servicios externos “perfildeusuario” y “diagnostico1”. El LLM devuelve el siguiente json: { "perfildeusuario": "https://trots.es/api-v2.0/users/tfgapi.php/?user=IsabelMartin", "diagnostico1": "https://trots.es/api-v2.0/colectivo/tfgapi.php/?user=IsabelMartin" } El resultado de ejecutarlos por el controlador ahora incluirá información del usuario: perfildeusuario: OK {'nombre': 'Isabel Martín Fernández', 'email': 'isabel.marti[email protected]s', 'ID': 'e43267757v'} diagnostico1: OK {'colectivo': 'estudiante'} se añaden de nuevo al contexto y se itera de nuevo. 48 [1] R. Belloso Chacín, W. José Urdaneta Urdaneta, U. Privada Rafael Belloso Chacín, and V. Blanca Liliana González Pertuz, “UNIVERSIDAD PRIVADA,” Ciencias Administrativas y Gerenciales, vol. 21, no. 2, pp. 147–167, [Online]. Available: https://orcid.org/0009-0009-7788-3036 [2] “4. Introduccion a redes neuronales artificiales”. [3] A. Vaswani et al., “Attention Is All You Need.” [4] E. C. Elejalde -g Navarro -a Rosete -e Leyva et al., “SISTEMA PARA EL ENTRENAMIENTO PARALELO DE REDES NEURONALES DE PROPAGACIÓN HACIA ATRÁS informática.” [5] V. Dogra et al., “A Complete Process of Text Classification System Using State-ofthe-Art NLP Models,” 2022, Hindawi Limited. doi: 10.1155/2022/1883698. [6] M. Cheng, E. Durmus, and D. Jurafsky, “Marked Personas: Using Natural Language Prompts to Measure Stereotypes in Language Models,” Long Papers. [7] Redacción IA, “Chatbots conversacionales vs. basados en reglasdiferencias clave.,” Promptengineer. Accessed: Feb. 15, 2024. [Online]. Available: https://promptengineer.es/chatbots-conversacionales-vs-basados-en-reglasdiferencias-clave/ [8] Redacción IA, “Chatbots conversacionales vs. basados en reglasdiferencias clave.,” Promptengineer. Accessed: Feb. 15, 2024. [Online]. Available: https://promptengineer.es/chatbots-conversacionales-vs-basados-en-reglasdiferencias-clave/ [9] P. Lewis et al., “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.” [Online]. Available: https://github.com/huggingface/transformers/blob/master/ [10] A. Q. Jiang et al., “Mistral 7B,” Oct. 2023, [Online]. Available: http://arxiv.org/abs/2310.06825 [11] A. Q. Jiang et al., “Mistral 7B,” Oct. 2023, [Online]. Available: http://arxiv.org/abs/2310.06825 [12] G. Berg and A. Lincke, “Bachelor Degree Project Image Classification with Machine Learning as a Service-A comparison between Azure, SageMaker, and Vertex AI.” [13] G. Berg and A. Lincke, “Bachelor Degree Project Image Classification with Machine Learning as a Service-A comparison between Azure, SageMaker, and Vertex AI.” 10 ANEXO 1: CÓDIGO 49 import os from openai import AzureOpenAI import json import re import requests from flask import Flask, request import sib_api_v3_sdk from sib_api_v3_sdk.rest import ApiException import urllib import logging import time app = Flask(__name__) @app.route('/petición', methods=['GET']) def petición(): logging.basicConfig(filename=os.path.join('logs/', f'log_{time.strftime("%j_%H%M%S")}.log'), level=logging.INFO, format='%(asctime)s %(message)s') client = AzureOpenAI( api_key = os.getenv("AZURE_OPENAI_API_KEY"), api_version = "2024-02-01", azure_endpoint = os.getenv("AZURE_OPENAI_ENDPOINT") ) try: msg = request.args.get('msg') if not msg: raise ValueError("Missing 'msg' parameter") prompt = urllib.parse.unquote_plus(msg) except Exception as e: return f"Error: {e}" try: sndml = request.args.get('sndml') if not sndml: sndml=False except Exception as e: sndml=False return f"Error: {e}" respuesta = primerprompt(prompt, client) print(respuesta + "\n") 50 logging.info(f'MENSAJE DE USUARIO: {prompt} \nRespuesta de GPT4o:{respuesta}\n') datos_json = json.loads(respuesta) Nombre = datos_json["Nombre"] SID = datos_json["sesionID"] Identificador = datos_json["Identificador"] mail_interno = datos_json["mail-interno"] mail_externo = datos_json["mail-externo"] problema = datos_json["Problema"] username = datos_json["username"] context = datos_json["Datos"] if problema == "NA": return "El sistema no puede identificar el problema" if SID != "NA": logging.info(f'hay SID. Añadiendo contexto') with open(f"sesion/{SID}.txt", 'r') as archivo: prompt1 = prompt + archivo.read() with open(f"sesion/{SID}.txt", 'a') as archivo: archivo.write(prompt) prompt = prompt1 logging.info(f'Ambos prompts: \n{prompt}') respuesta = primerprompt(prompt, client) logging.info(f'Nueva respuesta de GPT-4o: \n{respuesta}') datos_json = json.loads(respuesta) Nombre = datos_json["Nombre"] Identificador = datos_json["Identificador"] SID = datos_json["sesionID"] mail_interno = datos_json["mail-interno"] mail_externo = datos_json["mail-externo"] problema = datos_json["Problema"] username = datos_json["username"] context = datos_json["Datos"] else: SID = assignSID() with open(f"sesion/{SID}.txt", 'a') as archivo: archivo.write(prompt) logging.info(f'Se ha asignado SID {SID}') with open(f"data/{problema}", 'r') as archivo: instructions = archivo.read() print(instructions) chatrole = f" si la fase actual es 'resolución' elabora una respuesta para el usuario siguiendo las instrucciones como si fueses atención al usuario de la universidad de valladolid. En cualquier otro caso, la respuesta 51 debe de ser un archivo json que contenga una objeto con los servicios que hay que consultar en dicha fase: la clave es el nombre del servicio y el valor su url sustituyendo argumentos necesarios si los hubiese. Se sigue este patrón en función del número de enlaces que se hayan proporcionado. Omite el resto de instrucciones, se utilizarán en otro momento y omite incluir ```json... & ```.Deduce la fase actual de las comprobaciones proporcionadas" #------------------------------------------------------ bucle resolución comprobaciones = "" # se inicializa antes del bucle respuesta = "{" # lo mismo. Si no no entra al bucle. Cuando no devuelve un json es la respuesta for i in range(0,5): instructions = f"{instructions}. Datos usuario: {Nombre}, id:{Identificador}, mail interno:{mail_interno}, mail externo:{mail_externo}, username:{username}.comentario: {context}\ \n\n Fases comprobadas:\n{comprobaciones}" #comentario: {context}\ logging.info(f'instrucciones ronda {i}:\n{instructions}\n') response = client.chat.completions.create(model = "gpt-4o25ktokens", messages=[{"role": "system", "content":chatrole},{"role": "user", "content": instructions}]) respuesta = response.choices[0].message.content print(respuesta + " \nRespuesta: " +str(i)) logging.info(f'respuesta ronda{i}:\n{respuesta}\n') #try: if respuesta.startswith('{') is False: logging.info(f'Salimos del bucle') break datos_json = json.loads(respuesta) comprobaciones += check_services(datos_json) print(comprobaciones) print(instructions) if respuesta.startswith('{') is True: return f"Estimado usuario. \n\nNo ha sido posible resolver su problema. Seguiremos buscando posibles causas para solucionarlo lo antes posible. Disculpe las molestias. \n\nsesionID = {str(SID)}\nCentro de Atención al Usuario (CAU).\nUniverisdad de Valladolid" #------------------------------------ formatea mail o devuelve respuesta if sndml is True: chatrole = "Necesito que al siguiente mensaje le incluyas las etiquetas <br> en los saltos de línea para formatearlo correctamente. El propio mensaje ya va a ser el contenido de un mail por lo que es necesario omitir todo lo que no sea necesario" resp = client.chat.completions.create(model = "gpt-4o25ktokens", messages=[{"role": "system", "content": chatrole },{"role": "user", "content": respuesta }]) content = resp.choices[0].message.content html = f"<p>{content}</p>" subject = "Respuesta CAU incidente" to_address = mail_interno if mail_interno != "NA" else mail_externo receiver_username = Nombre logging.info(f'sndml true, se va a formatear respuesta y enviar a {to_address}') 52 email_response = send_email(subject, html, to_address , receiver_username) print(email_response) logging.info(f'{email_response}') #return respuesta else: logging.info(f'sndml false, no se envía correo') respuesta += '\n sesionID= ' + str(SID) return respuesta # final de la ejecucción #------------------------------------ FUNCIONES, FIN EJECUCCIÓN PRINCIPAL def check_services(json_data): results = [] for service_name, url in json_data.items(): try: response = requests.get(url) response.raise_for_status() # Levanta una excepción si el estado no es 200 try: json_content = json.loads(response.content) except json.JSONDecodeError: print("¡¡¡¡¡¡ PRIMERA EXCEPCIÓN. !!!!!!!!") json_content = "" results.append(f"{service_name}: OK {json_content}\n") except requests.exceptions.RequestException as e: print("¡¡¡¡¡¡ SEGUNDA EXCEPCIÓN.!!!!!!!!") results.append(f"{service_name}: Error\n{e}\n") return " ".join(results) #---------------------------------------------------------------------------- def primerprompt(prompt, client): problemas = [archivo for archivo in os.listdir('data/') if archivo.endswith(".txt")] chatrole = f"Eres un programador que va a devolver unicamente un archivo json con información extraída del prompt. Omite incluir ```json... & ```. Necesito que devuelvas 'Nombre': Contiene nombre y apellido del usuario.'username': Es 'Nombre' formateado, sin tildes ni espacios entre nombre o apellidos y con las iniciales en mayúsculas. 'mail-interno': correo con dominio uva.es. 'mail-externo': correo con un dominio diferente. 'Identificador': tiene el tipo 'e' + NIF. el usuario puede proporcionar NIF o identificador. 'Problema': Se debe clasificar el problema del usuario en uno de entre los siguientes tipos {problemas}. 'sesionID': ID de la conversación. 'Datos': si hay información extra que pueda ser relevante para la resolución del problema añádela a modo de comentario explicativo. Los datos que no se proporcionen se deben rellenar como 'NA'. Si no se puede obtener 'Identificador' el problema es faltan_datos.txt" response = client.chat.completions.create(model = "gpt-4o25ktokens", messages=[{"role": "system", "content": chatrole },{"role": "user", "content": prompt }]) return response.choices[0].message.content #---------------------------------------------------------------------------- def assignSID(): used = [int(os.path.splitext(archivo)[0]) for archivo in os.listdir('sesion/') if archivo.endswith(".txt")] if len(used) == 0: return 1 53 else: return max(used) + 1 #---------------------------------------------------------------------------- def send_email(subject, html, to_address=None, receiver_username=None): # SendinBlue mailing parameters configuration = sib_api_v3_sdk.Configuration() configuration.api_key['api-key'] = os.getenv("BREVO_API_KEY") api_instance = sib_api_v3_sdk.TransactionalEmailsApi(sib_api_v3_sdk.ApiClient(configuration) ) subject = subject sender = {"name": "Adrián", "email": "[email protected]"} html_content = html if to_address: to = [{"email": to_address, "name": receiver_username}] else: to = [{"email": "[email protected]", "name": "Adrián"}] send_smtp_email = sib_api_v3_sdk.SendSmtpEmail(to=to, html_content=html_content, sender=sender, subject=subject) try: # Send the email api_response = api_instance.send_transac_email(send_smtp_email) print(api_response) return {"message": "Email sent successfully!"} except ApiException as e: print("Exception when calling SMTPApi->send_transac_email: %s\n" % e) #---------------------------------------------------------------------------- if __name__ == '__main__': app.run(host="0.0.0.0")