NavigAItor: Una herramienta recomendadora de LLMs basada en la descripción del dominio a aplicar

NAVIG(AI)TOR: UNA HERRAMIENTA RECOMENDADORA DE LLMS BASADA EN LA DESCRIPCIÓN DEL DOMINIO A APLICAR TRABAJO FIN DE GRADO 2023-2024 AUTORES: ÁNGELA LUCENA PRIETO SUPERVISADO POR: ISMAEL SAGREDO OLIVENZA GRADO EN INGENIERÍA INFORMÁTICA FACULTAD DE INFORMÁTICA UNIVERSIDAD COMPLUTENSE DE MADRID NAVIG(AI)TOR: A TOOL FOR RECOMMENDING LLMS BASED ON THE DESCRIPTION OF THE DOMAIN TO APPLY BCS THESIS 2023-2024 AUTHORS: ÁNGELA LUCENA PRIETO SUPERVISED BY: ISMAEL SAGREDO OLIVENZA BSC IN COMPUTER ENGINEERING SCHOOL OF COMPUTER SCIENCE COMPLUTENSE UNIVERSITY OF MADRID 2 DEDICATORIA A mi familia y amigos, especialmente a mis padres, mis hermanas y a Marita. 3 AGRADECIMIENTOS Venir a estudiar a Madrid ha sido lo más importante que me ha ocurrido en la vida, y esto se debe a las siguientes personas a las que me gustaría agradecer todo lo que han hecho por mí a lo largo de estos años. Primero, a mis padres, por haberme brindado la oportunidad de vivir esta experiencia, apoyándome económica y moralmente en cada decisión que he tomado, confiando siempre en mí y dejándome ser lo suficientemente independiente para aprender por mí misma. A mis hermanas, por su apoyo incondicional desde el principio y por darme el valor y la confianza en mí misma que muchas veces me ha faltado. A Marita, por no separarse de mi lado en las peores épocas de estudio, y por estar siempre dispuesta a hacer de lo malo algo mucho más llevadero. Te echo de menos. A mis amigas y amigos, mi segunda familia. Por no dejarme nunca sola, por hacer que Madrid no parezca tan grande y por darle sentido a todo lo vivido durante estos años. Gracias. A mi tutor Ismael, por su ayuda y disposición constante para resolver cualquier duda o sugerir posibles mejoras en mi trabajo. Su orientación ha sido fundamental en mi proceso académico y ha hecho mucho más ameno el esfuerzo que ha implicado el desarrollo de este proyecto. Finalmente, al equipo de Nexus and Innovation de Stratesys, por haberme otorgado la oportunidad de desarrollar este proyecto, asumiendo todos los gastos adheridos al mismo. Especialmente, quiero agradecer a Irene, Edu, Guille, Juli y Fran, por abrirme las puertas al fascinante mundo de la Inteligencia Artificial y por su colaboración, junto con mi tutor, en la resolución de cualquier problema en el desarrollo de mi Trabajo de Fin de Grado. A todos vosotros, por acompañarme en esta etapa, mil gracias de corazón; esto no tendría sentido si no hubierais estado ahí. 4 RESUMEN NavigAItor: Una herramienta recomendadora de LLMs basada en la descripción del dominio a aplicar El procesamiento del lenguaje natural (NLP) ha sido un desafío tecnológico durante décadas. Este estudio se centra en evaluar el rendimiento de diversos modelos de lenguaje a gran escala (LLMs) en casos de uso específicos de NLP, con el objetivo principal de desarrollar un asistente virtual llamado NavigAItor que ofrezca recomendaciones basadas en los resultados del estudio. Se identifican y comparan modelos de OpenAI, LLAMA y Mistral en dos contextos: el análisis de entrevistas de trabajo y de llamadas telefónicas. Se han utilizado herramientas de evaluación que incluyen un formulario para la valoración subjetiva de los usuarios sobre las salidas generadas en las tareas de cada caso de uso por cada modelo, junto con la medición de la latencia, indicando el tiempo que cada modelo tarda en ejecutar dichas tareas. Además, se ha llevado a cabo una investigación exhaustiva sobre otras métricas relevantes, como el rendimiento en benchmarks estandarizados y el precio por token. Los resultados obtenidos buscan guiar a desarrolladores y profesionales de IA en la selección de modelos de lenguaje para aplicaciones del mundo real, contribuyendo al avance del campo del NLP y mejorando la eficacia de las soluciones implementadas. Palabras clave Modelos Grandes de Lenguaje (LLM), Procesamiento del lenguaje natural (NLP), generación de reúmenes, extracción de insights, Talent Scan, Smart Call Transcript, métricas de evaluación, bechmarks estandarizados, asistente virtual e inteligencia artificial. 5 ABSTRACT NavigAItor: A tool for recommending LLMs base don the description of the domain to apply Natural Language Processing (NLP) has been a technological challenge for decades. This study focuses on evaluating the performance of various large language models (LLMs) in specific NLP use cases, with the primary objective of developing a virtual assistant called NavigAItor that provides recommendations based on the study's findings. Models from OpenAI, LLAMA, and Mistral are identified and compared in two contexts: the analysis of job interviews and phone calls. Evaluation tools used include a user feedback form for subjective assessment of the outputs generated by each model for each use case task, along with latency measurement indicating the time each model takes to execute these tasks. Additionally, an exhaustive investigation into other relevant metrics, such as performance in standardized benchmarks and cost per token, has been conducted. The results aim to guide developers and AI professionals in selecting language models for real-world applications, contributing to the advancement of NLP and improving the effectiveness of implemented solutions. Keywords Large Language Models (LLM), Natural Language Processing (NLP), text generation, insights extraction, Talent Scan, Smart Call Transcript, evaluation metrics, standardized benchmarks, virtual assistant, artificial intelligence. 6 ÍNDICE DE CONTENIDOS Contenido 1. Introducción ........................................................................................................................................ 15 1.1 Motivación ........................................................................................................................................ 16 1.2 Hipótesis del estudio ......................................................................................................................... 17 1.3 Objetivos ........................................................................................................................................... 17 1.4 Plan de Trabajo ................................................................................................................................. 18 2. Estado del arte..................................................................................................................................... 21 2.1 Introducción a los Modelos de Lenguaje a Gran Escala .................................................................... 21 2.1.1 ¿Qué son los LLMs y cómo funcionan? ...................................................................................... 21 2.1.2 Evolución de los LLMs ................................................................................................................ 23 2.1.3 Tipos de Modelos de Lenguaje .................................................................................................. 24 2.2 Agentes Inteligentes y su relación con los LLMs ............................................................................... 26 2.3 Agente basado en LLM y sus componentes críticos .......................................................................... 27 2.3.1 Text Splitter................................................................................................................................ 28 2.3.2 Embeddings ............................................................................................................................... 30 2.3.3 RAG y VectorDB ......................................................................................................................... 34 2.3.4 Memoria .................................................................................................................................... 35 2.3.5 Prompt Engineering ................................................................................................................... 39 3. Casos de Uso Por Evaluar .................................................................................................................... 40 3.1 Presentación de los casos de uso ...................................................................................................... 41 3.1.1 Talent Scan................................................................................................................................. 41 3.1.2 Smart Call Processor .................................................................................................................. 42 7 3.2 Implementación de los casos de uso ................................................................................................ 43 3.2.1 Infraestructura y Comunicación con las APIs de los Modelos en Azure ..................................... 43 3.2.2 Funciones generales .................................................................................................................. 45 3.2.3 Funciones específicas de Talent Scan ........................................................................................ 46 3.2.4 Funciones específicas de Smart Call Processor .......................................................................... 48 4. Modelos Grandes de Lenguaje a Evaluar ............................................................................................. 51 4.1 OPENAI .............................................................................................................................................. 53 4.1.1 GPT-4 32K .................................................................................................................................. 54 4.2 MISTRAL ............................................................................................................................................ 56 4.3 LLAMA 2 ............................................................................................................................................ 58 5. Resultados ........................................................................................................................................... 61 5.1 Procedimiento de Ejecución ............................................................................................................. 62 5.2 Resultados de la Ejecución ................................................................................................................ 63 5.3 Evaluación del Formulario y Resultados Obtenidos .......................................................................... 67 5.3.1 Diseño e implementación del formulario .................................................................................. 67 5.3.2 Resultados obtenidos en el formulario ...................................................................................... 68 5.4 Resultados de algunos modelos en benchmarks estandarizados ..................................................... 74 5.5 Evaluación Final................................................................................................................................. 78 6. NavigAItor ............................................................................................................................................ 82 7. Conclusiones y Trabajos Futuros ......................................................................................................... 88 Introduction ................................................................................................................................................ 90 1. Motivation ............................................................................................................................. 91 2. Study Hypothesis ................................................................................................................... 92 3. Objectives .............................................................................................................................. 92 14 15 1. Introducción El procesamiento del lenguaje natural (NLP) ha representado un desafío tecnológico durante décadas. A pesar de los avances, los agentes conversacionales han enfrentado múltiples deficiencias, como la incapacidad para recordar conversaciones previas, mantener diálogos coherentes sobre temas específicos y responder con precisión a preguntas comprometidas, donde revelaban fácilmente su naturaliza artificial. Estas deficiencias se hicieron evidentes en la interacción con asistentes de voz populares como ‘Alexa’ y ‘Siri’, quienes, a pesar de su amplia adopción, han sido objeto de críticas por sus errores y limitaciones a la hora de responder al usuario. En el contexto de la pérdida de control, fue un ejemplo notorio el chatbot de Microsoft, ‘Tay’, retirado de Twitter debido a su comportamiento inapropiado y a la incapacidad para gestionar adecuadamente las interacciones con los usuarios. 'Como muchos de ustedes sabrán, el miércoles lanzamos un chatbot llamado Tay. Lamentamos profundamente los tweets involuntarios ofensivos e hirientes de Tay, que no representan quiénes somos ni qué representamos, ni cómo diseñamos a Tay'. (Peter Lee, 2016) Sin embargo, en los últimos años, el panorama del NLP ha experimentado una transformación revolucionaria, impulsada por el surgimiento de los Modelos de Lenguaje a Gran Escala o Large Language Models (LLMs) en inglés, basados en la arquitectura Transformer. Estos avances han sido posibles gracias al desarrollo de redes neuronales profundas y al aumento en la capacidad de procesamiento de los datos. La introducción de los LLMs ha marcado un punto de inflexión en el campo, permitiendo que los sistemas de NLP alcancen niveles de rendimiento sin precedentes en tareas como la generación de texto. Además, es esencial destacar que la evolución de los LLMs ha sido impulsada por hitos específicos en la investigación. Uno de los momentos más significativos fue la presentación del modelo GPT (Generative Pre-trained Transformer) por OpenAI en 2018, seguido por su sucesor, ‘GPT-2’, y los innovadores ‘GPT-3’ y ‘GPT-4’, que establecieron un nuevo estándar en la capacidad de los modelos de lenguaje para comprender y generar texto natural. Asimismo, la aparición de potentes modelos de código abierto pertenecientes a familias como LLAMA (Large Language Model for Model Analysis) y MISTRAL, que han contribuido significativamente al avance del campo, democratizando el acceso a estas tecnologías y fomentando la colaboración en la comunidad de investigación del NLP. Estos avances han sentado las bases para una nueva era en el NLP, con aplicaciones potenciales que abarcan desde la asistencia virtual hasta la creación de contenido automatizado. 16 1.1 Motivación El campo de la inteligencia artificial (IA), y en particular el procesamiento del lenguaje natural ha experimentado un crecimiento sin precedentes en los últimos años, gracias al desarrollo de modelos de lenguaje cada vez más avanzados y potentes. Sin embargo, con la proliferación de estos modelos, surge la necesidad de evaluar su rendimiento en diferentes casos de uso y escenarios específicos. La motivación detrás de este estudio radica en la necesidad de comprender cómo diferentes modelos de lenguaje se desempeñan en una variedad de tareas y situaciones, con el objetivo de identificar cuál de ellos ofrece mejores resultados en cada caso. Esta necesidad lleva varios años siendo estudiada por otros desarrolladores pertenecientes al campo de la IA. (Lipenkova, 2022). En este proyecto particular, se propone evaluar diferentes modelos de lenguaje pertenecientes a OpenAI, LLAMA y Mistral, en dos casos de uso distintos. Estos casos de uso abarcan la generación de resúmenes y la extracción de insights relevantes, entendidos como información valiosa o hallazgos significativos, en dos contextos diferentes: el análisis de una entrevista de trabajo y el análisis de una llamada telefónica. Al evaluar estos modelos en diversos escenarios, podremos determinar sus fortalezas y debilidades, así como su idoneidad para diferentes aplicaciones y contextos. Además, este estudio tiene como objetivo proporcionar una guía práctica para la selección de modelos de lenguaje en aplicaciones del mundo real. Al entender qué modelos funcionan mejor en qué situaciones, los desarrolladores y profesionales de IA podrán tomar decisiones más informadas y eficaces al implementar soluciones de NLP en diversos proyectos. Con esta información, se espera facilitar la adopción y el desarrollo de soluciones de NLP más efectivas y adaptadas a las necesidades del mundo real. Esta motivación subyace en la creación de NavigAItor, un asistente virtual basado en la información recopilada, capaz de recomendar el modelo de lenguaje más adecuado para una tarea específica, proporcionando así una herramienta útil y práctica para aquellos que trabajan en el campo de la IA y el procesamiento del lenguaje natural. 17 1.2 Hipótesis del estudio La premisa básica de este trabajo es que, al evaluar y comparar diferentes modelos de lenguaje en distintos casos de uso del procesamiento del lenguaje natural, se podrá identificar cuál de ellos proporciona los mejores resultados en términos de rendimiento y eficacia para cada situación específica. Se hipotetiza que al analizar el desempeño de los modelos de OpenAI, LLAMA2 y MISTRAL en dos casos de uso diferentes que involucran tareas como la generación de resúmenes y la extracción de insights valiosos, se podrá determinar cuál de ellos se adapta mejor a cada aplicación particular. Así, se espera que esta evaluación proporcione una guía útil para los desarrolladores y usuarios que buscan implementar modelos de lenguaje en aplicaciones prácticas, al ofrecer recomendaciones sobre qué modelo utilizar en función de las necesidades específicas de cada caso de uso. Asimismo, se espera que este estudio contribuya a la comprensión y la valoración de los modelos de lenguaje disponibles en el mercado, considerando tanto su rendimiento como su aplicabilidad en escenarios del mundo real. Además, se anticipa que los resultados obtenidos serán utilizados para informar el diseño y desarrollo de un asistente recomendador de modelos de lenguaje que pueda orientar a los usuarios en la selección del modelo más adecuado para sus necesidades específicas. 1.3 Objetivos Los objetivos de este proyecto son los siguientes: Crear dos casos de uso diferentes del procesamiento del lenguaje natural sobre los que se realizarán la evaluación de los modelos: 1. Primer Caso: desarrollar un sistema de procesamiento del lenguaje natural para analizar entrevistas de trabajo. Este sistema extraerá información sobre las habilidades blandas (soft skills) y habilidades técnicas (technical skills) de los candidatos, y generará un resumen que evaluará la idoneidad del candidato para la vacante. 2. Segundo Caso: implementar un sistema de procesamiento del lenguaje natural para analizar llamadas telefónicas. Este sistema generará un resumen detallado de los eventos ocurridos durante la llamada y realizará un análisis de sentimientos para evaluar las emociones del receptor a lo largo de la conversación. 18 Analizar las métricas de los modelos de lenguaje de gran escala pertenecientes a OpenAI, LLAMA y Mistral, incluyendo la evaluación humana, el precio por token, la ventana de contexto del modelo y la latencia, entre otros aspectos. Evaluar y comparar el rendimiento de los modelos seleccionados, en los casos de uso previamente creados. Desarrollar herramientas de evaluación: 1. Crear un formulario de evaluación para que expertos y usuarios puedan calificar y proporcionar retroalimentación sobre el rendimiento de los modelos en cada caso de uso. 2. Estudiar el rendimiento de los modelos seleccionados en benchmarks estandarizados. Implementación y Evaluación de un asistente virtual: 1. Desarrollar un asistente virtual recomendador de modelos de lenguaje que, basado en la información recopilada y las métricas de evaluación, sugiera el modelo más apropiado para una tarea específica, teniendo en cuenta las preferencias y requisitos del usuario. 2. Proporcionar una funcionalidad adicional al asistente para que responda sobre cualquier pregunta cuyo contexto forme parte de este proyecto de investigación. 3. Evaluar la eficacia del asistente virtual para recomendar el modelo más adecuado teniendo en cuenta las preferencias y requisitos del usuario. 1.4 Plan de Trabajo Etapa 1: Preparación y Diseño 1. Pasos Iniciales: Investigación previa sobre el uso de Streamlit, LangChain, Azure y cómo utilizar estas plataformas para realizar las diferentes implementaciones y llamadas a los LLMs, junto con todos los requisitos que esto implica. Investigación de los casos de uso más relevantes en el campo de la IA generativa y el NLP, para decidir los casos de uso a desarrollar. 19 Investigación de los LLMs más relevantes del mercado actual y su disponibilidad en Azure. 2. Definición de los Casos de Uso: Revisión detallada de las necesidades y requisitos para cada caso de uso: Talent Scan y Smart Call Transcript. Diseño de los flujos de trabajo y la arquitectura de los sistemas de procesamiento del lenguaje natural para cada caso de uso. 3. Recopilación de Métricas: Investigación exhaustiva sobre las métricas de evaluación de modelos de lenguaje, incluyendo el precio por token, la ventana de contexto del modelo y la latencia, entre otros. Identificación y recopilación de datos relevantes para la comparación de los modelos pertenecientes a OpenAI, LLAMA y Mistral. Etapa 2: Implementación y Evaluación de Modelos 1. Desarrollo de Casos de Uso: Implementación de los sistemas de procesamiento del lenguaje natural para el análisis de entrevistas de trabajo y llamadas telefónicas. Integración de los modelos de lenguaje seleccionados en cada caso de uso y pruebas preliminares para ver la viabilidad de los modelos. 2. Ejecución Comparativa: Ejecución de pruebas exhaustivas para evaluar el rendimiento de los modelos en los casos de uso desarrollados, junto con la toma de medidas como la latencia. Recopilación de los resultados obtenidos, para utilizar en la evaluación subjetiva. 20 Etapa 3: Desarrollo de Herramientas de Evaluación 1. Creación del Formulario de Evaluación: Diseño y desarrollo de un formulario estructurado para la evaluación de expertos y usuarios sobre el rendimiento de los modelos en cada caso de uso, utilizando los resultados obtenidos en la etapa anterior. Pruebas y ajustes del formulario para garantizar su eficacia y usabilidad. 2. Estudio de Rendimiento en Benchmarks: Investigación del rendimiento de los modelos en benchmarks estandarizados para evaluarlos en escenarios específicos y poder comparar dicha evaluación con la del formulario. Etapa 4: Implementación y Evaluación del Asistente Virtual 1. Desarrollo del Asistente Virtual: Implementación del asistente virtual recomendador de modelos de lenguaje, basado en toda la información recopilada y las métricas de evaluación de las etapas anteriores. Añadir la funcionalidad de que pueda responder a cualquier tema que aparezca en la documentación y, de hecho, utilice esta información para explicar sus resomendaciones. 2. Evaluación de Eficacia: Realización de pruebas de usabilidad y evaluación de la eficacia del asistente virtual en la recomendación de modelos adecuados. Análisis de si realiza la funcionalidad adicional de proporcionar cualquier información que se encuentre en el documento. Etapa 5: Conclusiones y trabajos futuros Aportar conclusiones en base a los resultados obtenidos y posibles futuras mejoras o implementaciones. 21 2. Estado del arte En el mundo del procesamiento del lenguaje natural y la creación de agentes inteligentes, son dos las tecnologías que han supuesto una fuerte disrupción: los Large Language Models (LLMs) y la generación procedimental. Durante los últimos años, se ha sido testigo de una evolución sorprendente en el mundo de los LLMs. Desde sus humildes comienzos entorno al año 2018 con ‘GPT-1’, estos modelos han experimentado una transformación notable, especializándose significativamente en diversas áreas. Este progreso no solo refleja su crecimiento en complejidad, sino también la diversificación de sus aplicaciones prácticas, marcando así una era fascinante en el procesamiento del lenguaje natural. Adentrándose en los entresijos, en esta sección se explorarán a fondo los componentes esenciales que potencian a los agentes inteligentes en conjunto con los LLMs, desde procesos como el ‘Splitting’ hasta la integración de ‘Embeddings’, entre otros. Con esta narrativa, no solo se busca descubrir estos elementos, sino también arrojar luz sobre cómo contribuyen a la eficacia y toma de decisiones de los agentes digitales con los que convivimos en nuestro día a día. Este viaje a través del estado del arte tiene como objetivo contextualizar estos elementos esenciales, proporcionando así una base sólida. Una base que, a su vez, será la guía en la evaluación de modelos y la creación de un asistente virtual capaz de señalar el modelo más adecuado para diversos desafíos específicos. 2.1 Introducción a los Modelos de Lenguaje a Gran Escala 2.1.1 ¿Qué son los LLMs y cómo funcionan? Al sumergirse en el universo de los Large Language Models, se adentra en algoritmos de aprendizaje profundo diseñados para abordar una amplia gama de tareas relacionadas con el procesamiento del lenguaje natural. Estos modelos poseen una capacidad única para captar patrones de lenguaje, gramática y contexto, convirtiéndolos en componentes esenciales para una amplia variedad de aplicaciones relacionadas con el NLP. Entre estas destacan la generación y el resumen de texto, la traducción de idiomas, la respuesta a consultas, la obtención de insights e incluso la generación de código. 22 Su habilidad para sintetizar y generar información los posiciona como elementos invaluables en la inteligencia artificial y el procesamiento del lenguaje. En el corazón de los LLMs se encuentran los Transformers (Vaswani, 2017), una arquitectura revolucionaria que ha marcado un cambio significativo en la forma en la que los modelos comprenden y generan texto. Estos Transformers destacan por su habilidad a la hora de manejar dependencias a larga distancia mediante lo que se conoce como mecanismos de autoatención, que como su propio nombre indica, en lugar de centrarse exclusivamente en una parte específica del texto, permite al modelo considerar todas las palabras (o elementos) en la entrada, asignando diferentes niveles de importancia. En particular, los Transformers se centran en la atención multi-cabeza (Multi-Head Attention). Cada ‘cabeza’ funciona como un conjunto independiente de pesos y conexiones para capturar diferentes patrones y relaciones en los datos. Durante el procesamiento, cada cabeza de atención calcula pesos específicos para cada palabra en función de su relevancia en el contexto global. Esta capacidad única le permite al modelo adaptarse a diferentes patrones y jerarquías dentro del texto, mejorando significativamente su capacidad para comprender y generar texto de manera efectiva. Es crucial destacar el proceso de entrenamiento de estos modelos, ya que sienta las bases para su funcionamiento. Durante la fase de preentrenamiento, los LLMs se sumergen en vastos conjuntos de datos, aprendiendo patrones lingüísticos complejos. Luego, en el ajuste fino (fine-tuning) se adaptan a tareas específicas. Finalmente, es esencial mencionar que, en ambas fases, la optimización de los pesos se lleva a cabo mediante algoritmos de retropropagación que permiten propagar los errores de predicción hacia atrás a través de la red neuronal, ajustando los pesos para que el modelo aprenda a generar predicciones más precisas; y el descenso del gradiente, que calcula el gradiente (la derivada) de la función de pérdida respecto a los pesos, y los actualiza en la dirección opuesta, reduciendo la pérdida y permitiendo que el modelo converja, haciendo que el error se minimice. Este proceso iterativo de retropropagación y descenso del gradiente es fundamental para que los LLMs desarrollen su capacidad de comprender y generar texto, adaptándose a diversas tareas y contextos. 23 2.1.2 Evolución de los LLMs En el transcurso de la historia de la Inteligencia Artificial, el NLP ha sido una de las áreas más destacadas. Desde los años 50, figuras como Alan Turing, pionero de la informática y la IA, plantearon ideas fundamentales que hoy son centrales en este campo. Turing introdujo el famoso ‘Test de Turing’ (Josue, 2021), concebido para evaluar la inteligencia de una máquina, asemejándose a lo que conocemos como un ChatBot. Esto subrayó desde el principio que comprender y procesar el lenguaje humano sería una meta esencial de la IA. En sus primeras etapas, los enfoques basados en reglas y gramáticas formales enfrentaron limitaciones debido a su incapacidad para adaptarse a las complejidades del lenguaje natural. Sin embargo, la introducción de las redes neuronales artificiales en la década de los 80 permitió el desarrollo de modelos más avanzados, como las redes neuronales recurrentes (RNN) que están diseñadas para procesar datos secuenciales, y las redes neuronales convolucionales (CNN), las cuales son conocidas por su eficiencia en el procesamiento de datos que tienen una estructura de cuadrícula, como imágenes o representaciones vectoriales de palabras. Estos modelos, inspirados en el cerebro humano, posibilitaron que las máquinas aprendieran a partir de ejemplos, mejorando significativamente su capacidad para comprender y generar texto en lenguaje natural. Sin embargo, el verdadero cambio de paradigma ocurrió hace menos de un decenio, con la introducción de los Transformers en 2017. Como se discutió en el apartado anterior (2.1.1), los Transformers, con su arquitectura innovadora, permiten superar las limitaciones de las RNN y las CNN al abordar eficientemente las relaciones de largo alcance entre palabras en el texto. Esta revolución allanó el camino para los Modelos de Lenguaje Pre-entrenados (PLMs) y, más recientemente, los LLMs, como ‘BERT’ y ‘GPT’, que han mostrado un rendimiento excepcional en diversas tareas de NLP. A pesar de estos avances, es crucial abordar preocupaciones emergentes en este contexto tecnológico. Los LLMs, aunque poderosos, requieren enormes recursos y plantean desafíos en términos de sostenibilidad y accesibilidad. Además, la presencia de sesgos en los datos de entrenamiento puede dar lugar a resultados discriminatorios. ‘Los modelos de lenguaje a gran escala tienen una confiabilidad limitada, una comprensión limitada, un alcance limitado y, por lo tanto, necesitan supervisión humana.’ (Michael Osborne profesor de Machine Learning de la Universidad de Oxford, 2023) 30 Nombre División Añade Metadatos Descripción Recursive Lista de caracteres definida por el usuario Divide el texto de forma recursiva. Esta división sirve para tratar de mantener fragmentos de texto relacionados uno al lado del otro. Es la forma recomendada de comenzar a dividir texto. HTML Caracteres específicos de HTML Divide el texto en función de caracteres específicos de HTML. Esto agrega información importante (metadatos) sobre la procedencia de ese fragmento. Code Caracteres específicos de código (Python, JS) Divide el texto en función de los caracteres específicos de los lenguajes de codificación. Hay 15 idiomas diferentes disponibles para elegir. Token Tokens Divide el texto en tokens (grupos de caracteres que representan una unidad fundamental de texto). Existen algunas formas diferentes de medir los tokens. Character Un carácter definido por el usuario Divide el texto en función de un carácter definido por el usuario. Uno de los métodos más sencillos. [Experimental] Semantic Chunker Oraciones Primero se divide en oraciones. Luego combina unos al lado de otros si son lo suficientemente similares semánticamente. Tomado de (Kamradt, 2024) Tabla 1. Tipos de Text Splitters 2.3.2 Embeddings Los Large Language Models no interpretan el texto de la manera en que lo hacen los humanos, sino que en su lugar lo convierten a una representación numérica conocida como ‘embeddings’ (Word Embeddings through Hellinger PCA, 2017). Esta técnica ha revolucionado las tareas de descubrimiento de conocimiento y recomendación de contenido desde su popularización en 2013 con el desarrollo de ‘word2vec’. 31 Figura 2-6. Representación de los Embeddings (Image Source: (Ruder, 2016)) Para ilustrar este concepto, considera el desarrollo de un sistema de reconocimiento facial. En este contexto, la tarea es comparar una imagen del rostro de una persona con una base de datos que contiene imágenes de referencia para determinar su autenticidad. En lugar de comparar directamente las imágenes, se construye una red convolucional que procesa las imágenes y genera un ‘embedding’, una representación vectorial que es esencialmente una lista de números. La clave aquí es que rostros similares producirán embeddings cercanos, mientras que los rostros diferentes generarán embeddings más distantes. En el ámbito del procesamiento y análisis del lenguaje natural se emplea un enfoque similar llamado Word Embedding. Este método toma palabras, las representa como tokens y las convierte en embeddings. Al igual que en el contexto de las imágenes, palabras contextualmente similares tendrán embeddings cercanos entre sí. Las figuras (Figura 2-6 y Figura 2-7) representan gráficamente esta relación en una nube de Embeddings, ofreciendo una visión más clara. 32 Figura 2-7. Ejemplos de Embeddings (Image Source: (Thcookieh, 2024)) Sin embargo, es crucial entender que, en el lenguaje natural, las palabras no existen de manera aisladas, sino en un contexto específico, como una frase. Dependiendo de ese contexto, una palabra puede adquirir diferentes significados. Aquí es donde entran en juego los LLMs y las Redes Transformer. Estas tecnologías permiten generar embeddings capaces de capturar la información contextual, asegurando que frases con significado similar tengan representaciones vectoriales similares. Esta técnica se conoce como Text Embedding (Feldges, 2023). Al explorar las diferentes opciones de modelos de Text Embeddings, se encuentran diversos proveedores destacados como OpenAI, Cohere y Hugging Face, entre otros. Langchain complementa esta variedad al ofrecer una clase base diseñada para interactuar con estos modelos, simplificando el proceso de embebido de documentos y consultas. Este proceso interno compara el embedding de la consulta con el de los documentos ofreciendo la mejor respuesta basada en la similitud de los embeddings. En particular, OpenAI destaca con dos modelos de embeddings de tercera generación, detallada en la siguiente tabla extraída de (OpenAI, 2024): Figura 2-8. Embedding models OpenAI 33 La tabla presenta una visión detallada de cada modelo, incluyendo el costo por páginas de texto en dólares (basado en aproximadamente 800 tokens por página), el rendimiento evaluado en MTEB (Massive Text Embedding Benchmark) y la capacidad máxima admitida por cada modelo. El nuevo modelo ‘text-embedding-3-small’ se destaca como una versión altamente eficiente, representando una mejora significativa respecto a su predecesor, el ‘text-embedding-ada-002’ lanzado en diciembre de 2022. Este modelo exhibe un rendimiento mejorado en la evaluación estándar para recuperación multilingüe (MIRACL), con una puntuación promedio aumentada del 31.4% al 44%. Además, ha mejorado su rendimiento evaluado con MTEB, pasando de un 61% a un 62.3%. Una ventaja adicional es su reducción de precio en una quinta parte con respecto al ‘text-embedding-ada-002’, disminuyendo de 0.0001$ a 0.0002$ por cada 1000 tokens. En la misma tabla, se destaca el modelo ‘text-embedding-3-large’, una versión de texto a gran escala que genera embeddings con hasta 3072 dimensiones. Este modelo se posiciona como el mejor rendimiento de OpenAI, obteniendo un 54.9% en la prueba MIRACL, en comparación con el 31.4% de textembedding-ada-002. Asimismo, en MTEB, la puntuación promedio ha crecido de 61% a 64.6% 1 . En conclusión, los embeddings representan un avance crucial en el procesamiento del lenguaje natural, permitiendo la traducción de conceptos lingüísticos a representaciones numéricas. Su aplicación va más allá de la mera comprensión semántica, ya que impulsan herramientas como el Retrieval Augmented Generation (RAG) y facilitan la creación de sistemas más eficientes para la recuperación y generación de información. Estos avances no solo optimizan la interacción con modelos de lenguaje, sino que también abren nuevas posibilidades para la innovación en inteligencia artificial y el desarrollo de aplicaciones más intuitivas y contextuales. 1 Todos estos resultados pueden ser consultados en la página oficial de OpenAI: https://openai.com/ 34 2.3.3 RAG y VectorDB Figura 2-9. Elementos en una arquitectura RAG (Image Source: (Escalona, 2023)) Uno de los problemas más preocupantes en los LLMs son las alucinaciones, caracterizadas por la generación de información incoherente, irrelevante o simplemente falsa. A pesar del entrenamiento extensivo con grandes volúmenes de datos, las erratas en la comprensión del contexto persisten. Para abordar este desafío, destacan dos conceptos fundamentales en el ámbito del Procesamiento del Lenguaje Natural: el Retrieval-Augmented Generation (RAG) y VectorDB, una base de datos especializada para almacenar vectores de embeddings, comúnmente integrada en implementaciones de RAG. El RAG, o Generación con Recuperación (Alvarado, 2023), representa una técnica avanzada en NLP que fusiona modelos recuperativos y generativos. Los modelos recuperativos seleccionan información relevante en respuesta a una consulta, mientras que los generativos producen texto completamente nuevo. Esta combinación ha concedido resultados de vanguardia en tareas como respuestas a preguntas abiertas y diálogos complejos. Además de los LLMs, otros elementos clave en la arquitectura RAG incluyen las bases de datos vectoriales o VectorDB, que almacenan embeddings para permitir una búsqueda semántica eficiente durante la etapa de recuperación inicial. Para escalar en grandes corpus de texto, bases de datos altamente optimizadas como Chroma (Chroma, 2024) o Pinecone (Pinecone, 2024) son esenciales (En el presente trabajo se ha utilizado Pinecone en la implementación del agente recomendador de modelos). 35 Estas arquitecturas destacan por su capacidad para almacenar miles de millones de vectores de texto o documentos, facilitando búsquedas de similitud de baja latencia, es decir casi instantáneas. Estas bases de datos vectoriales utilizan estructuras avanzadas, como índices invertidos y árboles de decisión (Ortega, 2023), y estrategias como hashing (Martínez) y gráficos HNSW (Yu. A. Malkov, 2018) para la búsqueda aproximada del vecino más cercano en espacios de alta dimensión, evitando cálculos costosos. Otros componentes destacables de la arquitectura RAG son los modelos de incrustación (Embedding models), que transforman consultas y datos en vectores, facilitando la comparación y búsqueda eficaz en las bases de datos vectoriales. Estos modelos se tornan vitales en la identificación y recuperación de la información más pertinente. Por otro lado, se debe destacar el papel que desempeñan los modelos recuperativos o Retrieval models, que se encargan de seleccionar información relevante almacenada en el VectorDB durante la fase de recuperación, que posteriormente se utiliza en la etapa de generación de respuestas. Para lograr esto, los Retrieval models aplican diversas técnicas, como MMR (Maximum Marginal Relevance) (Kumar, 2024), que diversifica los resultados de la búsqueda seleccionando de las k respuestas más similares aquellas que sean diversas entre sí. También emplean la técnica de self-query, que modifica o expande la consulta original utilizando información (metadatos) de documentos recuperados previamente. Por último, destaca en este contexto el concepto de comprensión, que alude a la reducción de la cantidad de información redundante o no relevante de los resultados. Esta reducción puede lograrse mediante técnicas como la eliminación de términos comunes o la representación compacta de documentos, contribuyendo a acelerar la recuperación y a mejorar la eficiencia del sistema. 2.3.4 Memoria Para mantener una conversación coherente, es fundamental que los Modelos de Lenguaje a Gran Escala dispongan de una memoria conversacional que les permita responder a múltiples consultas de manera similar a un chat. Esta memoria es esencial para recordar interacciones pasadas y contextualizar las respuestas, evitando que cada consulta se trate como una entrada independiente. 36 Figura 2-10. LLM con y sin memoria conversacional. Los recuadros azules representan al usuario, mientras que los grises son la respuesta del LLM. Sin memoria conversacional (derecha), el LLM no puede responder utilizando el conocimiento de interacciones previas. (Source Image: (Pinecone, 2024)) En el contexto de (LangChain, 2024), la implementación de esta memoria se basa en ConversationChain, que consta de dos parámetros principales: el historial (history) y la entrada (input). El historial almacena información sobre conversaciones previas entre el usuario y la IA, mientras que la entrada hace referencia a la última consulta realizada por el usuario. Estos parámetros se utilizan para alimentar al LLM, permitiendo que continúe la conversación de manera coherente. Existen varios tipos de memoria conversacional, cada uno con sus propias características y aplicaciones. Uno de los enfoques más simples es la ConversationBufferMemory (Langchain, 2024), que utiliza un buffer para almacenar directamente cada interacción en el historial de chat, lo que ofrece ventajas en cuanto a la cantidad de información disponible para el LLM. Sin embargo, este enfoque también presenta desventajas, como el aumento del tiempo de respuesta y el costo a medida que se acumulan más tokens en el buffer. Además, existe un límite en la cantidad de tokens que se pueden almacenar en el LLM (por ejemplo 4096 tokens para ‘text-davinci-003’ y ‘gpt-3.5-turbo’), lo que puede resultar en la pérdida de información cuando se alcanza este límite. 37 Para mitigar este problema, se introduce la ConversationSummaryMemory, que resume el historial de conversaciones antes de pasarlo al parámetro ‘historial’. Este enfoque implica el uso de un LLM adicional para realizar el resumen de cada nueva interacción y agregarla a un resumen continuo de todas las interacciones pasadas. Figura 2-11. Recuento de Tokens a medida que aumenta el número de interacciones para la ConversationBufferMemory frente a la ConversationSummaryMemory (Image Source: (Pinecone, 2024)) En la Figura 2-11 se puede observar que, aunque la ConversationSummaryMemory consume más tokens que la ConversationBufferMemory en una conversación prolongada, permite conversaciones más extensas y evita la pérdida de información cuando se alcanza el límite de tokens. Otra variante es la ConversationBufferWindowMemory, que agrega una ventana de memoria al enfoque de buffer. Esta ventana retiene solo un número determinado de interacciones pasadas antes de ‘olvidarlas’. En esta configuración, se debe especificar un valor k, que representa el número de interacciones que la ventana puede recordar. Aunque esta memoria no es ideal para recordar interacciones distantes, resulta útil para limitar el número de tokens utilizados, ya que la ventana puede ajustarse aumentando o disminuyendo el valor de k según las necesidades de la conversación. 38 Finalmente, la ConversationSummaryBufferMemory combina los principios de la ConversationSummaryMemory y la ConversationBufferWindowMemory. La esencia esta memoria radica en su capacidad para resumir las primeras interacciones de una conversación, manteniendo simultáneamente los tokens más recientes sin procesar (sin resumir), identificados por un límite máximo predefinido (max_tokens_limit). Esto permite establecer un equilibrio entre la necesidad de recordar interacciones pasadas relevantes y la optimización del uso de tokens, evitando la pérdida de información vital en las interacciones más recientes. No obstante, la implementación de la ConversationSummaryBufferMemory conlleva desafíos propios. Como se observa en la Figura 2-12, el proceso de resumir las interacciones pasadas puede aumentar el recuento de tokens en conversaciones más cortas, lo que puede afectar la eficiencia del sistema en ciertos escenarios. Además, el almacenamiento de las interacciones sin procesar, aunque se considera valioso en términos de retención de información, también puede incrementar el consumo de recursos computacionales. Figura 2-12. Comparaciones de recuentos de tokens, incluido el tipo ConversationSummaryBufferMemory con valores de max_token_limit de 650 y 1300. (Image Source: ( (Pinecone, 2024))) 39 2.3.5 Prompt Engineering Para cerrar el panorama del estado del arte, es importante mencionar el Prompt Engineering, también conocido como ingeniería de indicaciones. Este proceso es fundamental en el contexto de los LLMs, ya que se centra en diseñar y refinar las instrucciones proporcionadas a estos modelos para dirigir su generación de respuestas de manera más precisa y relevante. La práctica del prompt engineering involucra dos tipos principales de prompts: los prompts dirigidos al usuario (human prompts) y los prompts dirigidos al sistema (system prompts). Los prompts dirigidos al usuario buscan guiar al usuario final en la formulación de sus solicitudes para que el modelo pueda procesar de manera más efectiva. Estos prompts ayudan a los usuarios a estructurar sus entradas de forma que el modelo pueda entender y generar respuestas más relevantes. Por otro lado, los prompts dirigidos al sistema se utilizan para configurar y ajustar el propio modelo de lenguaje. Estos prompts le indican al modelo cómo debe comportarse, cuáles son sus objetivos y restricciones, y cómo debe generar las respuestas. Al definir estos prompts de sistema, los ingenieros de prompts pueden optimizar aún más el desempeño del modelo para aplicaciones específicas. La importancia del prompt engineering radica en su capacidad para guiar la atención del modelo hacia aspectos específicos de una tarea o dominio, lo que desemboca en la obtención de resultados más coherentes y contextualmente relevantes. Al diseñar indicaciones claras y específicas, se reduce la necesidad de intervención humana o de post-procesamiento extenso, lo que contribuye a la eficiencia del sistema. Además, facilita la adaptación de los LLMs a diferentes escenarios y aplicaciones al ajustar las indicaciones según las necesidades específicas de cada tarea, lo que optimiza los resultados generados por el modelo y mejora su utilidad y aplicabilidad en diversos contextos. En esta práctica, la experimentación y la iteración desempeñan un papel crucial. Es común que la primera vez que un ingeniero escribe un prompt, el modelo no actúe con la precisión esperada. Por lo tanto, es esencial probar diferentes enfoques y refinar continuamente las indicaciones en función del rendimiento del modelo. Este proceso de retroalimentación y ajuste se considera fundamental para garantizar la calidad de las respuestas generadas y maximizar el potencial de los LLMs en una amplia gama de aplicaciones. En definitiva, este componente se percibe como absolutamente crucial, ya que puede variar significativamente el resultado del modelo utilizado en el desarrollo de una tarea específica. 46 3.2.3 Funciones específicas de Talent Scan Como se ha visto anteriormente, Talent Scan se centra en la evaluación de candidatos para puestos de trabajo específicos, extrayendo habilidades blandas y técnicas de entrevistas laborales. Sus funciones específicas incluyen: Transcripción de la Entrevista: Esta función proporciona formato al archivo de entrada que contienen la conversación de la entrevista. Lo que se consigue principalmente en esta función es: distinguir de manera clara quién es el entrevistador y quién el entrevistado, corregir posibles errores gramaticales y estructurar la visualización de las intervenciones para que se muestren de manera clara. El resultado de esta llamada se guarda en una variable llamada guion, que es la utilizada como argumento en el resto de las funciones. Extraer Soft Skills y Technical Skills: Talent Scan identifica y extrae del guion las habilidades blandas y técnicas relevantes del candidato, proporcionando una visión integral de sus competencias. Generar Descripción del Rol: Utilizando información sobre el puesto y la empresa, Talent Scan genera una descripción detallada del rol vacante, ayudando a definir claramente las expectativas y requisitos del puesto. Esta función se utiliza en caso de que el puesto especificado sea distinto a ‘Chief Happiness Officer’ o a ‘Technical RPA consultant’ para los cuales se presentan unos prompts específicos de la descripción en main.py, antes de llamar a la función expuesta a continuación. Generar Conclusiones y Resumen de la Entrevista: Esta función sintetiza los hallazgos de la entrevista y genera un resumen detallado que destaca los puntos clave discutidos y las impresiones generales sobre el candidato, destacando aspectos como cuáles son las habilidades del candidato que se consideran interesantes para el puesto, así como aquellos aspectos en los que el candidato presenta carencias. 47 Figura 3-4.Diagrama del flujo de llamadas de Talent Scan 48 3.2.4 Funciones específicas de Smart Call Processor Por otro lado, Smart Call Processor se enfoca en el análisis de llamadas telefónicas, generando resúmenes y analizando sentimientos del receptor. Sus funciones específicas abarcan: Generar Transcripción de la Llamada: Esta función, al igual que la del caso de uso anterior procesa el archivo de entrada que contiene la llamada telefónica para generar un guion de la conversación, identificando al emisor y receptor de cada mensaje, corrigiendo posibles errores gramaticales y aportando una estructura clara. Analizar Sentimientos del Receptor: Smart Call Processor analiza los sentimientos del receptor a lo largo de la llamada, proporcionando información sobre las emociones predominantes y los puntos clave de la conversación. Generar Resumen de la Llamada: Utilizando el guion de la conversación y el análisis de sentimientos, esta función genera un resumen conciso y relevante de lo ocurrido en la llamada, facilitando la comprensión y revisión del contenido. 49 Figura 3-5. Diagrama del flujo de llamadas de Smart Call Processor 50 Con estas funciones específicas, Talent Scan y Smart Call Processor ofrecen soluciones completas y efectivas para sus respectivos casos de uso, aprovechando las tecnologías mencionadas para proporcionar una experiencia de usuario intuitiva y una funcionalidad avanzada de procesamiento de lenguaje natural. La utilización de funciones generales en la implementación realizada proporciona una estructura robusta y flexible que permite agregar fácilmente nuevas funciones o modelos para su evaluación, ampliando así las capacidades de las herramientas y su adaptabilidad a diferentes casos de uso. Esta arquitectura del sistema (Figura 3-4 y Figura 3-5) permite una rápida iteración y experimentación, lo que facilita la exploración de nuevas ideas y enfoques en el procesamiento de lenguaje natural. Garantiza que las herramientas puedan mantenerse actualizadas y relevantes en un entorno en constante cambio, al tiempo que proporciona una experiencia de usuario consistente y de alta calidad. 51 4. Modelos Grandes de Lenguaje a Evaluar La selección y despliegue de modelos de lenguaje ha sido de gran importancia en el desarrollo de este TFG, ya que inciden directamente en el rendimiento y la eficacia de las tareas de los casos de uso expuestos anteriormente (Casos de Uso Por Evaluar). En este proyecto, se ha optado por aprovechar la infraestructura y herramientas proporcionadas por Microsoft Azure para implementar tres modelos pertenecientes a LLAMA, MISTRAL y OpenAI. Para evaluar y comparar estos modelos se han tenido en cuenta métricas clave como el precio por token, el número de parámetros utilizados en el entrenamiento del modelo, el contexto máximo admitido, la latencia, consideraciones éticas, la transparencia y la evaluación de expertos a través de un Google Form. Además de las métricas anteriores, se ha obtenido información acerca del rendimiento de varios modelos en benchmarks 2 estandarizados de la industria, que se verán en la futura sección 5.4 Resultados de algunos modelos en benchmarks estandarizados. La elección de estos modelos se basa en su amplio reconocimiento y uso en la actualidad, además de que presentan diferentes naturalezas; mientras que MISTRAL y LLAMA-2 contienen modelos Open Source o código abierto, OpenAI proporciona modelos de caja negra. Es importante destacar que Azure ofrece dos posibilidades de despliegue para los modelos: el pago por uso de sus respectivas API o la opción de ejecutarlos en una máquina virtual con los requisitos hardware necesarios para su ejecución (el precio en este caso consiste en el tiempo que se mantiene activa la máquina virtual y depende de lo compleja que sea esta máquina). Para garantizar una comparación equitativa entre los tres modelos, se ha optado por el pago por uso, dado que se dispone de la métrica de precio por token de los tres modelos para evaluar su eficiencia económica con mayor precisión. La elección de Azure se debe a su destacada posición como una de las principales plataformas de computación en la nube a nivel mundial. Stratesys, empresa en la que estoy realizando las prácticas, ha facilitado el acceso a Azure, proporcionando un usuario para su uso. Además, ha asumido los costos asociados al uso de las APIs para llamar a estos modelos, lo que ha contribuido significativamente a la 2 Un benchmark es una prueba o conjunto de pruebas utilizadas para comparar el rendimiento de diferentes sistemas o componentes, generalmente bajo condiciones estándar. En el contexto de la IA generativa y el NLP, los benchmarks son un conjunto de pruebas estandarizadas diseñadas para evaluar el rendimiento de los LLM en diversas habilidades, como el razonamiento y la comprensión, y utilizar puntuaciones o métricas específicas para medir cuantitativamente estas habilidades. 52 viabilidad económica de esta implementación. Esto demuestra el compromiso de la empresa con la innovación y el desarrollo tecnológico, así como su interés en aprovechar al máximo las capacidades de la inteligencia artificial para beneficio de sus proyectos y clientes. Por otro lado, es importante mencionar que existe la opción de ejecutar tanto MISTRAL como LLAMA de manera gratuita en local, siempre y cuando se cuente con el hardware adecuado. Sin embargo, esto requiere una inversión en infraestructura, como una potente tarjeta gráfica, una cantidad considerable de memoria VRAM y otros recursos necesarios para la ejecución de estos modelos tan exigentes. Esta alternativa puede resultar económica a largo plazo, pero es importante tener en cuenta los costos iniciales y el mantenimiento de la infraestructura. ‘Loading even a relatively small model such as Llama2 7B and performing inference requires approximately 30GB of GPU memory [1]. The largest Llama2 model at 70B parameters requires approximately 320GB of GPU memory which can be prohibitive.’ (Coelho, 2024). Además, es relevante mencionar la existencia de modelos cuantizados. ‘La cuantificación es un conjunto de técnicas para reducir la precisión, hacer que el modelo sea más pequeño y entrenar más rápido en modelos de aprendizaje profundo.’ (Noyan, 2023). Estos modelos son ligeramente menos precisos y más lentos, pero ocupan menos memoria y requieren menos recursos de hardware. ‘If instead of loading the model weights at 32-bit precision, they can be reduced down to 8-bit, 4-bit, or an even lower precision, it becomes possible to load and run these models on consumer hardware, democratizing access to LLMs and their applications.’ (Coelho, 2024) Antes de optar por utilizar las llamadas a las APIs de los modelos a través de Azure, se llevaron a cabo pruebas de ejecución local gratuita de modelos como el ‘llama-2-13B-GGUF’ para los casos de uso mencionados anteriormente. Sin embargo, los resultados no cumplieron con las expectativas, ya que el contexto era demasiado grande para dicho modelo. A pesar de ello, para tareas menos complejas, como la generación de correos electrónicos a partir de un tema dado, y la indicación de la formalidad de este, el modelo funcionaba correctamente. Otro modelo cuantizado investigado en este proyecto y que ha resultado intrigante es el de ‘Dolphin-2.7-mixtral-8x7b-GGUF’, un modelo de código abierto sin cesura. Su falta de limitaciones éticas resulta tanto curiosa como potencialmente peligrosa, lo que ha llevado a explorar cuidadosamente sus capacidades y posibles implicaciones. 53 En resumen, la elección de Azure para el despliegue de modelos de lenguaje nos proporciona una solución integral, escalable y segura que combina la potencia de la nube con la versatilidad de los modelos de LLAMA, MISTRAL y OpenAI. Esta plataforma nos permite aprovechar al máximo las capacidades de la inteligencia artificial y ofrecer experiencias de usuario excepcionales en nuestras aplicaciones de procesamiento del lenguaje natural. 4.1 OPENAI El primer modelo de lenguaje con el que se han realizado las pruebas de evaluación de los Casos de uso ha sido el Transformer Pre-entrenado Generativo (GPT) desarrollado por OpenAI, ‘GPT-3.5-Turbo0125-16K’. Este modelo, opera de forma similar a ‘GPT-3.5-Turbo’ con la principal diferencia de que su ventana de contexto ha sido ampliada a 16.385 tokens. Esta expansión aumenta ocho veces la capacidad de retención de memoria del modelo, lo que le permite mantener el contexto de las interacciones en textos más largos (ahora puede admitir 20 páginas de texto en una sola solicitud, cuando antes simplemente podía poco más de 2 páginas). El modelo de ’GPT-3.5-Turbo’ es una versión avanzada de la serie de modelos de lenguaje generativo pre-entrenados de OpenAI. Está diseñado para ser más eficiente y preciso que sus predecesores, con mejoras en la comprensión y generación de texto en varios idiomas y en la capacidad de seguir instrucciones más complejas. La realidad es que no se sabe a ciencia cierta la cantidad de parámetros con los que ha sido entrenado este modelo específico; sin embargo, se conoce que ‘GPT-3’, el predecesor de ‘GPT-3.5’, tiene 175 mil millones de parámetros. Es común que las versiones posteriores de los modelos, como ‘GPT-3.5Turbo’, mantengan un número de parámetros similar o incrementado para mejorar su rendimiento. Un factor a tener en cuenta es que este modelo ha sido entrenado con datos hasta el año 2021, lo que significa que su conocimiento interno y la información que puede generar se basa en datos que pueden considerarse desactualizados. Es importante destacar que, aunque su funcionamiento interno puede considerarse como una ‘caja negra’ que afecta a la transparencia, OpenAI ha tomado medidas significativas para ofrecer seguridad y mitigar los riesgos éticos. Al utilizar la API de OpenAI alojada en Azure, se beneficia de las sólidas prácticas de seguridad de Microsoft, lo que proporciona una capa adicional de confianza y cumplimiento normativo. Sin embargo, la naturaleza opaca de estos modelos de IA plantea desafíos continuos en 54 términos de transparencia y explicabilidad, lo que requiere un compromiso constante con la mejora de la interpretabilidad y la implementación de prácticas éticas en su desarrollo y uso. Por último, cabe mencionar el coste del método adoptado para desplegar el modelo en Azure, el pago por uso. Este enfoque permite pagar exclusivamente por los recursos que se consumen, siendo en este caso cada token procesado al llamar a la API. Por tanto, el precio es de 0.0005 € por cada 1000 tokens de entrada y 0.0014 € por cada 1000 tokens de salida como se ilustra en la Figura 4-1. Figura 4-1.Pago por Uso de Gpt-3.5-Turbo-0125-16k en Azure 4.1.1 GPT-4 32K Uno de los sucesores del modelo anterior que se ha utilizado también en este proyecto ha sido el modelo ‘GPT-4-32K’. Aunque no se ha evaluado en el Google Form que se muestra en secciones futuras (5.3 Evaluación del Formulario y Resultados Obtenidos); sí que se ha tenido en cuenta para hacer una pequeña prueba que se ha considerado crítica en el desarrollo de este TFG y que se muestra en los Resultados. Además, este será el modelo utilizado para implementar nuestro agente recomendador de LLMs. El ’GPT-4-32K’ es una versión mejorada del GPT-4 desarrollado por OpenAI. Aunque comparte muchas similitudes con el ’GPT-3.5-Turbo-0125-16K’ que hemos explicado antes, hay algunas diferencias clave que lo distinguen. 55 Una de las diferencias más notables es la ventana de contexto del ’GPT-4-32K’, que ha sido ampliada a 32.768 tokens. Esto significa que el modelo puede mantener el contexto de las interacciones en textos aún más largos, lo que le permite analizar y procesar información de manera más efectiva. Según las pruebas realizadas, el ’GPT-4-32K’es capaz de resolver problemas difíciles con mayor precisión que cualquier modelo anterior de OpenAI. Esto se debe en parte a su ventana de contexto mencionada anteriormente. En cuanto al coste, el método adoptado para desplegar el modelo en Azure es igual que para el anterior, el pago por uso. El precio para el modelo ‘GPT-4-32K’ en Azure es de 0.0562€ por cada 1000 tokens de entrada y 0.1124€ por cada 1000 tokens de salida. (Figura 4-2) Figura 4-2. Pago por uso Gpt-4-32k en Azure Dada su eficiencia y rendimiento superior, en este TFG se ha decidido hacer más hincapié en comparar el rendimiento del ’GPT-4-32K’ con el modelo no perteneciente a OpenAI más avanzado utilizado, que ha sido ’Mistral-large’ y que se expone a continuación. 62 5.1 Procedimiento de Ejecución El proceso de ejecución de los modelos se diseñó meticulosamente para optimizar la comparación entre los diferentes modelos de lenguaje en los casos de uso específicos seleccionados. Se consideraron diversas medidas para garantizar la uniformidad y coherencia en las pruebas realizadas. Durante la ejecución de los modelos, se mantuvo casi intacto todo el código utilizado en los casos de uso, con mínimas modificaciones necesarias para adaptar la llamada a los modelos alojados en Azure. Esta estrategia garantizó la homogeneidad en las pruebas, asegurando que las entradas para los modelos fueran consistentes en todas las funciones. Se prestó especial atención a varias consideraciones clave para facilitar la evaluación precisa de los modelos: o Prompts Consistentes: Se emplearon los mismos prompts en todas las funciones para garantizar que los modelos recibieran la misma información inicial. Esto permitió que los input-tokens y el contexto fueran idénticos en los tres modelos, facilitando una comparación justa basada en las respuestas generadas. Se optó por no modificar los prompts entre los modelos para evitar posibles impactos en el rendimiento y asegurar una evaluación equitativa. o Archivos de entrada: El mismo archivo de entrada fue utilizado para la llamada a la primera función que generaba el guion inicial en todas las pruebas. Aunque se realizaron múltiples pruebas con diferentes entradas, se repitió el mismo procedimiento con los tres modelos para poder comparar los resultados obtenidos con dichos datos. Esto garantizó que el contexto inicial proporcionado fuera uniforme entre los modelos. Posteriormente, la información generada por el modelo en la función inicial se utilizó como entrada para las siguientes funciones, asegurando coherencia en el proceso de generación. o Número máximo de tokens de salida: Se ajustó el mismo número máximo de tokens de salida en los tres modelos (1000 tokens). Aunque no se puede prever exactamente cuáles serán los tokens en el output de cada modelo, esta aproximación permitió una comparación equitativa de los resultados obtenidos. Esto también facilitó la comparativa del precio base por 1000 tokens entre los modelos, asegurando una evaluación equitativa en términos de costo. 63 o Temperatura: este parámetro indica la diversidad y creatividad en las respuestas generadas por el modelo. A menor temperatura, el modelo tiende a generar respuestas más predecibles y menos diversas. En este proyecto se ha optado por mantener la temperatura en los tres modelos a 0.1, que asegura que el proceso de generación de respuestas se mantenga consistente y predecible, lo que facilita la comparación entre los diferentes modelos. Durante la ejecución de los modelos, se cronometró el tiempo en el que cada modelo generaba la respuesta, es decir, la latencia. Esta métrica proporcionó información valiosa sobre la velocidad de respuesta de cada modelo en cada tarea específica, lo que facilitó la comparación de su eficiencia en la generación de respuestas. Este proceso garantizó la coherencia y fiabilidad en las pruebas realizadas, proporcionando una base sólida para la evaluación precisa y significativa de los modelos de lenguaje en los casos de uso específicos abordados. 5.2 Resultados de la Ejecución En esta sección se presentan los resultados obtenidos al ejecutar los diferentes modelos en las distintas tareas de los casos de uso seleccionados. Los resultados se muestran en formato de imagen, detallando las respuestas generadas por cada modelo en cada tarea específica. Es importante destacar que las capturas de pantalla de las respuestas generadas se han incluido en el Apéndice de este informe. (Imágenes de los resultados utilizados en el formulario) Inicialmente, se llevaron a cabo varias pruebas utilizando archivos de entrada que podrían considerarse “sencillos”, como entrevistas y llamadas en las que se predecía claramente los roles de las dos personas que intervenían en las conversaciones. En la prueba utilizada en el formulario, todos los modelos fueron capaces de generar diálogos bien estructurados con el formato indicado en el prompt. Esta función resultó ser la más determinante, ya que el resto de las funciones dependen del guion generado. Como se observó que algunos modelos, como ‘LLAMA-2-Chat-70B’ y ‘GPT-3.5-Turbo-16k’, ofrecían respuestas muy similares, en algunos casos pareciendo hasta idénticas, se optó por realizar una prueba más complicada que hiciera una especie de criba en el rendimiento de los modelos. El objetivo era obtener 64 una visión más realista de diferentes escenarios, más allá de la valoración subjetiva de los usuarios sobre respuestas coherentes en todos los casos. Se realizó una prueba adicional, específicamente en el caso de "Talent Scan", utilizando una entrevista de entrada más compleja. (Imágenes de los resultados de la prueba con la entrevista más ) Esta entrevista se llevó a cabo sin seguir un orden de intervención estricto, lo que provocó que algunos modelos perdieran el contexto y generaran guiones erróneos. ‘Mistral-Large’ destacó al ser el único modelo capaz de captar correctamente la secuencia de intervenciones y mantener el orden adecuado para generar el guion. Posteriormente, se decidió introducir, solo en este caso, una prueba con el modelo de ‘GPT-432k’. Sorprendentemente, este modelo tampoco fue capaz de captar la segunda intervención del entrevistador, lo que resultó en una pérdida de contexto similar a los otros modelos evaluados. A pesar de que ‘GPT-4’ muestre un rendimiento superior en benchmarks estándar en comparación con Mistral, en este contexto específico, parece que ‘Mistral-Large’ es más capaz. Estas pruebas fueron críticas para determinar la idoneidad de ‘Mistral-Large’ en entradas más complejas, mostrando un mejor rendimiento con respecto a sus modelos rivales. Se ha supuesto que esto se debe a su carácter de modelo comercial optimizado, el cual se explica en el capítulo de Modelos Grandes de Lenguaje a Evaluar. Sin embargo, se examinará en la próxima sección cómo ha sido considerado este modelo en el formulario contestado por los usuarios expertos en la materia. Para las pruebas realizadas, se incluye la métrica de la latencia, que representa el tiempo que ha tardado cada modelo en completar cada tarea. Estos tiempos de ejecución se muestran en las siguientes tablas comparativas para facilitar la visualización y la comparación entre los modelos. 65 Tabla 2. COMPARATIVA DEL TIEMPO DE EJECUCIÓN DE LOS DIFERENTES MODELOS EN CADA UNA DE LAS TAREAS DE TALENT SCAN GPT-3.5-Turbo-16k GPT-4-32K MISTRAL-Large LLAMA-2-Chat-70B Guion de la entrevista 10 segundos 50 segundos 39 segundos 11 segundos Soft Skills 8 segundos NA 26 segundos 7 segundos Technical Skills 8 segundos NA 19 segundos 11 segundos Conclusiones 9 segundos NA 35 segundos 13 segundos De esta tabla se pueden obtener las siguientes conclusiones: En general, el modelo ‘GPT-3.5-Turbo-16k’ muestra tiempos de ejecución consistentemente más bajos en comparación con los otros modelos en la mayoría de las tareas. El modelo ‘LLAMA-2-Chat-70B’ destaca por su rapidez en la tarea de “Soft Skills”, demostrando una eficiencia notable en la generación de habilidades blandas. ‘MISTRAL-Large’ tiende a tener tiempos de ejecución más altos en todas las tareas, especialmente en la generación del “Guion de la entrevista” y las “Conclusiones”. Mencionar también que, aunque solo se haya ejecutado en la tarea de “Guión de la entrevista”, ‘GPT-4-32K’ es el más lento de todos los modelos. 66 Tabla 3. COMPARATIVA DEL TIEMPO DE EJECUCIÓN DE LOS DIFERENTES MODELOS EN CADA UNA DE LAS TAREAS DE SMART CALL TRANSCRIPT GPT-3.5-Turbo-16k MISTRAL-Large LLAMA-2-Chat-70B Guion de la llamada 13 segundos 32 segundos 10 segundos Resumen de la llamada 12 segundos 12 segundos 6 segundos Sentimientos de la llamada 8 segundos 14 segundos 5 segundos De esta tabla se pueden obtener las siguientes conclusiones: ‘LLAMA-2-Chat-70B’ emerge como el modelo más rápido en la mayoría de las tareas, con tiempos de ejecución consistentemente bajos. ‘MISTRAL-Large’ muestra tiempos de ejecución más altos en comparación con los otros modelos, especialmente en la generación del “Guion de la llamada”. Aunque ‘GPT-3.5-Turbo-16k’ no es el modelo más rápido en todas las tareas, es competitivo y muestra una consistencia notable en sus tiempos de ejecución. 67 5.3 Evaluación del Formulario y Resultados Obtenidos 5.3.1 Diseño e implementación del formulario En esta sección, se explorará el diseño y la implementación del formulario utilizado para recopilar las opiniones de expertos con el fin de elegir el modelo óptimo “a ciegas”, es decir, sin saber cuál modelo ha producido cada respuesta. Asimismo, se presentarán y analizarán los resultados obtenidos a partir de las respuestas recopiladas. Se optó por utilizar Google Forms para crear el formulario debido a su capacidad para insertar imágenes de gran tamaño sin pérdida de calidad. El formulario 3 se confeccionó a partir de capturas de los resultados obtenidos, disponibles en Imágenes de los resultados utilizados en el formulario. Se incluyó una breve introducción sobre el tema del TFG para contextualizar a los encuestados, seguida de una pregunta inicial sobre cuál creían que era el mejor modelo entre los tres que se iban a evaluar. El formulario se dividió en dos secciones: una para las respuestas de Talent Scan y otra para Smart Call Transcript, ambas siguiendo el mismo formato. Para garantizar la imparcialidad de las evaluaciones, los modelos se identificaron como: “Modelo 1”, “Modelo 2” y “Modelo 3”. La única persona con conocimiento de qué modelo correspondía a cada uno de ellos era yo misma, y revelo ahora que en orden son: ‘GPT-3.5-Turbo-16K’, ‘Mistral-Large’ y ‘LLAMA-2-Chat-70B’. Cada sección incluyó los objetivos específicos que debían cumplirse en cada tarea. Los encuestados debían asignar una puntuación del 1 al 3 a cada modelo en cada tarea, donde 1 representaba la mejor respuesta y 3 la peor. Se prohibió repetir el mismo número para dos modelos diferentes en una misma tarea. Sin embargo, en la generación de los guiones, donde los resultados de todos los modelos eran muy similares, se solicitó a los encuestados que seleccionaran cuál o cuáles de ellos les resultaban más atractivos en términos de estructura, y explicaran sus razones. Al final de cada sección, se incluyó una pregunta opcional para que los encuestados compartieran sus percepciones sobre el proceso de valoración. Finalmente, se concluyó con una pregunta en la que se les pidió a los encuestados que votaran por el modelo que consideraban mejor en general, basándose en su propio criterio. 3 Enlace al formulario: https://forms.gle/AjS8LqY6Fxf1PgnX7 68 5.3.2 Resultados obtenidos en el formulario A continuación, se abordará en detalle las respuestas recopiladas a través del formulario. Se examinarán las puntuaciones otorgadas por los expertos a cada modelo en las distintas tareas de Talent Scan y Smart Call Transcript. Asimismo, se explorarán los comentarios adicionales proporcionados por los encuestados con el fin de comprender mejor sus percepciones y consideraciones al evaluar los modelos. A través de este análisis exhaustivo, se buscará identificar patrones, discrepancias significativas y otros aspectos relevantes que puedan influir en la selección del modelo óptimo para los casos de uso específicos abordados. En primer lugar, se puede observar como la mayoría de los usuarios apostaban por ‘GPT-3.5Turbo-16K’ como el mejor modelo, esto puede deberse a la popularidad que ha marcado OpenAI çcon ChatGPT. Figura 5-1. Pregunta inicial Formulario En el interior de la primera sección, se encuentran las respuestas relacionadas a las tareas pertenecientes a Talent Scan, entre las cuales estaba la generación del guion de la entrevista formateado. Los encuestados debían seleccionar cuál o cuáles de los guiones les resultaban mejor estructurados y por qué. Se han obtenido las siguientes respuestas (Figura 5-2) en las que se obtienen que los modelos mejor valorados a la hora de generar el guion han sido ‘GPT-3.5-Turbo-16K’ y ‘LLAMA-2-Chat-70B’. Esta elección ha sido justificada por la mayoría de los encuestados con comentarios como estos: 69 ‘Los resultados no es que sean parecidos, son iguales, salvo que en uno de los modelos en vez de decir entrevistador y entrevistada, dice interviewer e interviewed’ ‘La única diferencia que veo, es que se identifica el entrevistador y entrevistado en inglés o en español. Me parece más razonable que se identifique en español ya que la conversación está en ese idioma. Por ese motivo he marcado los guiones 1 y 3.’ Figura 5-2.Valoración por expertos de los guiones de la entrevista generados por los modelos Aunque se haya considerado por este pequeño detalle a ‘Mistral-Large’ como el peor modelo, se tiene que recordar cómo realmente es el que mejor formatea los guiones puesto que en entradas más complicadas como el caso que se explicó anteriormente en el que el entrevistador y el entrevistado no siguen un patrón en las intervenciones, todos los modelos se pierden excepto este. Continuando con la tarea de la generación de los Soft Skills del entrevistado, se han obtenido los siguientes resultados: 70 Figura 5-3. Valoraciones de GPT-3.5-Turbo-16K en la generación de Soft Skills Figura 5-4. Valoraciones de Mistral-Large en la generación de Soft Skills Figura 5-5.Valoraciones de LLAMA2-Chat-70B en la generación de Soft Skills 71 El análisis revela claramente las preferencias de los encuestados en cuanto a la generación de Soft Skills, donde el modelo más apreciado fue ‘Mistral-Large’ con 18 votos como primer puesto, seguido de ‘LLAMA-2-Chat-70B’ con 14 votos como el segundo mejor modelo, y ‘GPT-3.5-Turbo-16K’ obtuvo 11 votos como el peor modelo en esta tarea. NOTA: A partir de este momento no se proporcionarán las imágenes del resto de tareas puesto que todas mantienen el mismo formato y lo que realmente interesa es el contenido que contienen, el cual se redacta detalladamente. En la tarea de generar los Technical Skills, los resultados estuvieron mucho más reñidos. Aunque ‘Mistral-Large’ se llevó el primer puesto con 11 votos (menos votos que en el caso anterior), el segundo lugar resultó en empate entre ‘GPT-3.5-Turbo-16K’ y ‘LLAMA-2-Chat-70B’, ambos con 9 votos. No obstante, el desempate se basó en el tercer puesto, que fue para ‘LLAMA-2-Chat-70B’ con 9 votos. Por tanto, en esta tarea, los modelos se ordenaron de la siguiente manera: ‘Mistral-Large’, ‘GPT-3.5-Turbo16K’ y ‘LLAMA-2-Chat-70B’. En la generación de las Conclusiones, ‘Mistral-Large’ fue nuevamente el modelo más votado con 16 votos, seguido de ‘GPT-3.5-Turbo-16K’ con 13 votos y ‘LLAMA-2-Chat-70B’ ocupó el último lugar con 13 votos. Los comentarios recopilados sobre los resultados destacan que los modelos ‘GPT-3.5-Turbo-16K’ y ‘LLAMA-2-Chat-70B’ parecen ofrecer respuestas muy similares y, en ocasiones, menos precisas en comparación con el modelo ‘Mistral-Large’. Se resalta que el segundo modelo destaca por captar las cualidades del entrevistado de manera más precisa en las conclusiones, mientras que los otros dos modelos tienden a señalar carencias. ‘Las respuestas de los modelos 1 y 3 siempre han sido muy parecidas, y a mi parecer inferiores a las del modelo 2, con información más inexacta’ ‘Destaca el 2 modelo por encima de los demás, es el único que en las conclusiones capta realmente las cualidades del entrevistado, los otros dos la ponen como carencias’ 78 En esta última gráfica se puede observar la precisión media calculada a partir de los valores obtenidos por los modelos en múltiples benchmarks estandarizados (Figura 5-11). Algunos de los modelos utilizados en los casos de uso de este proyecto están incluidos en esta evaluación. El modelo 'gpt-4-32k' obtiene la mayor precisión media, destacándose como el mejor modelo en este contexto. Le sigue ‘mistral-large’, que se sitúa como el segundo mejor modelo evaluado, aunque no supera a ninguna versión de ‘gpt-4’. Los modelos ‘gpt-3.5-turbo’ presentan una precisión media superior a la de ‘llama-2-70b-chat’. Sin embargo, es notable que el nuevo modelo lanzado por Meta, ‘llama-3-70b’, muestra una precisión media superior a la de ‘gpt-3.5-turbo’ y ‘llama-2-70b-chat’, aunque todavía es inferior a la de ‘mistrallarge’. Finalmente, la versión ‘llama-3-70b-instruct’ ha superado en precisión media a ‘mistral-large’, aunque sigue estando por debajo de ‘gpt-4-32k’. Estos resultados en benchmarks estandarizados, como MMLU y HellaSwag, proporcionan una valiosa validación objetiva de las capacidades de los modelos de lenguaje analizados. Permiten identificar sus fortalezas y debilidades en áreas clave como el razonamiento de sentido común, la comprensión del lenguaje y la versatilidad en diferentes dominios de conocimiento. Esta información, combinada con los hallazgos de la evaluación subjetiva basada en las respuestas de los usuarios, brinda una imagen más completa y confiable del desempeño de estos modelos, lo que es fundamental para tomar decisiones informadas sobre su selección y aplicación en diversos contextos. 5.5 Evaluación Final Tras recopilar y analizar todas las métricas seleccionadas para la evaluación de los modelos, esta sección presenta una evaluación final integral de los mismos. Se ha tenido en cuenta la información recopilada en el capítulo de los modelos, la latencia obtenida en la ejecución de los casos de uso, la evaluación subjetiva mediante el formulario de Google y los datos obtenidos sobre el rendimiento de estos modelos en diferentes benchmarks estandarizados. Con toda esta información, se ha elaborado una tabla comparativa final (Tabla 5. Comparativa Final de los Modelos) que permite visualizar de manera clara y concisa las diferencias y similitudes entre los distintos modelos evaluados. En esta tabla se incluyen métricas clave como: 79 Rendimiento en benchmarks como MMLU, HellaSwag, Wino Grande, Arc Challenge y TriviaQA Puntuaciones en la evaluación subjetiva de los usuarios Latencia y tiempos de respuesta en la ejecución de los casos de uso Precio de los modelos en Azure Ventana de contexto Número de parámetros utilizados en su entrenamiento Transparencia Tabla 5. Comparativa Final de los Modelos MODELOS GPT-3.5-Turbo-16k GPT-4-32K MISTRAL-Large LLAMA-2-Chat-70B PARAMETROS 175 Billones 175 Billones 7,3 Billones 70 Billones PRECIO POR 1000 TOKENS INPUT 0.0005 € 0.0562 € 0.00369 € 0.00146 € PRECIO POR 1000 TOKENS OUTPUT 0.0015 € 0.1124 € 0.01108 € 0.00167 € CONTEXTO MÁXIMO 16.385 tokens 32.768 tokens 32.000 tokens 4096 tokens TRANSPARENTE NO NO NO SÍ RAPIDEZ Rápido Más Lento Lento Rápido RENDIMIENTO EN BENCHMARKS 3º 1º 2º 4º EVALUACIÓN SUBJETIVA 3º 2º 1º 4º 80 En la anterior tabla comparativa se presentan los puntos más relevantes extraídos de la investigación y ejecución de estos modelos: En lo que respecta al rendimiento de los modelos, se observa una discrepancia entre las puntuaciones en los benchmarks y la realidad de la ejecución de uno de nuestros casos de uso. A pesar de que ‘GPT-4-32k’ es considerado el mejor modelo según los benchmarks, en nuestra experiencia, ‘Mistral-Large’ demostró ser el más eficaz al estructurar y comprender de manera óptima la entrevista recibida como entrada. Además, ‘Mistral-Large’ fue el modelo preferido por los usuarios que completaron el formulario. Por otro lado, tanto la evaluación subjetiva como la de los benchmarks sitúan a los modelos de la familia de LLAMA2 y GPT3.5-Turbo en posiciones similares en el ranking, aunque ‘GPT-3.5-Turbo16K’ se acaba mostrando superior a ‘LLAMA-2-Chat-70B’. En cuanto al precio por token en Azure, ‘GPT-4’ es el modelo más costoso con una diferencia significativa, llegando a ser hasta aproximadamente 15.22 veces más caro que ‘Mistral-Large’ para los tokens de entrada y aproximadamente 10.14 veces más caro para los tokens de salida. Este factor es importante considerar, ya que se ha observado que el rendimiento de estos modelos es comparable. Cuando se analizan modelos menos eficientes, ‘GPT-3.5-Turbo-16K’, además de ofrecer un mejor rendimiento que ‘LLAMA-2-Chat-70B’, resulta ser más económico en términos de tokens de entrada y salida, posicionándose como el modelo más asequible de los cuatro evaluados. Al evaluar la rapidez de los modelos, se observa una correlación directa con el rendimiento de cada uno. Los modelos más eficientes tienden a ser más lentos en comparación con aquellos que ofrecen respuestas de calidad ligeramente inferior. Aun siendo lenta su ejecución, ‘Mistral-Large’ supera en la generación del guion, a ‘GPT-4’ en este aspecto. Un punto importante a destacar sobre ‘LLAMA-2-Chat-70B’ es su transparencia al tratarse de un modelo Open Source. Esto significa que los usuarios tienen acceso al código fuente completo del modelo, lo que facilita la comprensión de su funcionamiento interno y brinda la posibilidad de realizar modificaciones según las necesidades específicas. Esta característica de transparencia puede fomentar la colaboración y el desarrollo de una comunidad en torno a ‘LLAMA-2-Chat-70B’, permitiendo a los usuarios experimentar con el modelo y adaptarlo de acuerdo a sus requerimientos particulares. Finalmente, se destaca la importancia de la ventana de contexto de los modelos, la cual permite mantener conversaciones coherentes y extensas, recordando detalles previos y generando respuestas 81 más precisas y contextuales. En este sentido, los resultados en orden de mayor a menor han sido los siguientes: ‘GPT-4’, ‘Mistral-Large’, ‘GPT-3.5-Turbo-16K’ y ‘LLAMA-2-Chat-70B’. En conclusión, la evaluación detallada de los modelos de lenguaje ‘GPT-4’, ‘Mistral-Large’, ‘GPT3.5-Turbo-16K’ y ‘LLAMA-2-Chat-70B’ destaca la diversidad de características y desempeños que cada uno ofrece en distintos aspectos como rendimiento, precio, transparencia y capacidad contextual. Estos hallazgos subrayan la importancia de considerar múltiples factores al seleccionar un modelo de lenguaje para satisfacer las necesidades específicas de cada aplicación. La variedad de opciones disponibles en el campo de la inteligencia artificial y el procesamiento del lenguaje natural brinda a los usuarios la oportunidad de elegir el modelo que mejor se adapte a sus requerimientos, ya sea en términos de eficacia, accesibilidad al código fuente, coste o capacidad para mantener conversaciones coherentes y contextualmente precisas. Además de servir como fuente principal de conocimiento para NavigAItor, este análisis detallado de los modelos resalta la complejidad y la diversidad de enfoques en el desarrollo y la aplicación de tecnologías de procesamiento del lenguaje natural, ofreciendo a los usuarios una gama amplia de opciones para optimizar sus proyectos y aplicaciones. 82 6. NavigAItor Tras una exhaustiva investigación sobre diversos modelos de lenguaje avanzados (LLMs) y la recopilación de valiosa información sobre su comportamiento en dos casos de uso específicos: Talent Scan y Smart Call Transcript, se ha desarrollado un agente recomendador de modelos de lenguaje llamado NavigAItor. Como se detalló en la revisión de la sección ‘2.3 Agente basado en LLM y sus componentes críticos‘ del Estado del Arte, la documentación generada durante este proceso de investigación se ha almacenado en un espacio de nombres (namespace) de Pinecone, la base de datos vectorial utilizada en este proyecto. El procedimiento de carga de la información incluyó los siguientes pasos: En primer lugar, se aplicó la técnica de Splitting sobre la documentación, utilizando el ‘RecursiveCharacterTextSplitter’ del paquete Langchain-text-splitters. Esta herramienta permitió dividir el texto en chunks de 1000 tokens (chunk_size), con un solapamiento de 100 tokens entre ellos (chunk_overlap), con el objetivo de mantener la coherencia y relación entre los fragmentos de texto consecutivos. Posteriormente, se generaron los embeddings correspondientes; es decir, se convirtieron estos fragmentos en una representación numérica apta para ser almacenada en la VectorDB usando el modelo ‘text-embedding-ada-002’ de la clase AzureOpenAIEmbedding, accesible a través de Langchain. Una vez subidos los documentos, se procedió al desarrollo del asistente virtual NavigAItor, cuyo frontend fue implementado con Streamlit. NavigAItor cuenta con una memoria conversacional, específicamente la ‘ConversationBufferMemory’ de Langchain, que le permite almacenar cada interacción en el historial del chat, proporcionando el mayor contexto posible al modelo utilizado, en este caso ‘GPT4-32K’, puesto que se buscaba el mayor rendimiento posible y Stratesys se encargaba una vez más del coste de su implementación. Para recuperar la información (RAG) relacionada con la pregunta del usuario en Pinecone, se ha utilizado la técnica de ‘Maximun Marginal Relevance (MMR)’. Esta técnica diversifica los resultados de la búsqueda seleccionando, de las k respuestas más similares, aquellas que sean diversas entre sí. En este proyecto, se ha establecido un valor de k igual a 8, para recuperar los 8 fragmentos más relevantes para la pregunta realizada. 83 Finalmente, se desarrolló un sistema de indicaciones claro para guiar al modelo en el manejo de la información recuperada y las directrices a seguir en su respuesta, destacando los criterios clave que deben considerarse al seleccionar el modelo más adecuado para la tarea especificada. Estos criterios incluyen el presupuesto, la velocidad del modelo, la eficiencia deseada en la tarea, las consideraciones éticas y cualquier modificación de parámetros internos del modelo. Además, el agente está preparado para responder preguntas sobre cualquier tema presente en la documentación del TFG. Todos estos componentes se encadenaron en una cadena de pensamiento, concretamente la ‘ConversationalRetrievalChain’ de LangChain, que coordina todas las llamadas a estos componentes para generar respuestas eficientes. A continuación, se mostrarán imágenes que representan el diseño del asistente virtual y algunos ejemplos de cómo responde este a las consultas realizadas: Figura 6-1. NavigAItor FrontEnd 84 Figura 6-2.Conversación con NavigAItor 1 85 Figura 6-3. Conversación con NavigAItor 2 86 Figura 6-4. Conversación con NavigAItor 3 87 Figura 6-5. Final de la conversación con NavigAItor El análisis de NavigAItor revela una respuesta clara y precisa, respaldada por la información recopilada en este proyecto. Aunque ocasionalmente ofrece consejos ingeniosos, siempre se mantiene dentro del contexto del tema discutido. Este logro se ha alcanzado al ajustar el parámetro 'temperature' a 0.4, lo que permite al modelo exhibir una mayor creatividad. Es importante destacar que NavigAItor no inventa información que no posee, lo que garantiza su precisión y fiabilidad. El tono de NavigAItor es amable y respetuoso hacia el usuario, y tiene la capacidad de sintetizar la pregunta del usuario con el contexto relacionado para proporcionar una respuesta coherente, incluso cuando la información no está explícitamente presente en la documentación. Por ejemplo, cuando se le pregunta sobre el mejor modelo para desarrollar un chatbot, como se muestra en la Figura 6-4. NOTA: Tener en cuenta que las valoraciones aportadas sobre NavigAItor acerca de cómo funciona ha sido subjetivo en base a mis conocimientos adquiridos durante el desarrollo del proyecto y escritura de esta Memoria. Sería interesante probarlo con un gran número de usuarios para hacer una valoración realmente efectiva. 94 Research on the most relevant LLMs in the current market and their availability in Azure. 2. Definition of Use Cases: Detailed review of the needs and requirements for each use case: Talent Scan and Smart Call Transcript. Design of the workflows and architecture of the natural language processing systems for each use case. 3. Metrics Collection: Extensive research on language model evaluation metrics, including token price, model context window, and latency, among others. Identification and collection of relevant data for the comparison of models belonging to GPT, LLAMA and Mistral. Stage 2: Model Implementation and Evaluation 1. Use Case Development: Implementation of natural language processing systems for the analysis of job interviews and telephone calls. Integration of the selected language models in each use case and preliminary tests to see the viability of the models. 2. Comparative Execution: Execution of exhaustive tests to evaluate the performance of the models in the developed use cases, along with the measurement of metrics such as latency. Compilation of the obtained results, to be used in the subjective evaluation. 95 Stage 3: Development of Evaluation Tools 1. Creation of the Evaluation Form: Design and development of a structured form for the evaluation of experts and users on the performance of the models in each use case, using the results obtained in the previous stage. Testing and adjustments of the form to ensure its effectiveness and usability. 2. Performance Study in Benchmarks: Research on the performance of the models in standardized benchmarks to evaluate them in specific scenarios and be able to compare this evaluation with that of the form. Stage 4: Implementation and Evaluation of the Virtual Assistant 1. Virtual Assistant Development: Implementation of the virtual assistant that recommends language models, based on all the information collected and the evaluation metrics from the previous stages. Add the functionality so that it can respond to any topic that appears in the documentation, and in fact, use this information to explain its recommendations. 2. Effectiveness Evaluation: Conducting usability tests and evaluating the effectiveness of the virtual assistant in recommending suitable models. Analysis of whether it performs the additional functionality of providing any information found in the document. Stage 5: Conclusions and Future Work Provide conclusions based on the results obtained and possible future improvements or implementations 96 Conclusions and future work As mentioned at the beginning of this document: 'The motivation behind this study lies in the need to understand how different language models perform in a variety of tasks and situations, with the aim of identifying which one offers the best results in each case'. By analyzing the behavior of different language models in two specific use cases involving tasks commonly used in generative AI projects, it has been found that some models, though less popular, can perform as well as or even better than globally recognized models such as those from OpenAI. Furthermore, it has been observed that performance metrics in certain standardized benchmarks do not always guarantee which models are the most efficient. For instance, 'Mistral' scored lower than 'GPT-4' in these benchmarks, yet in the specific use cases developed in this project, it proved to be more efficient. Such details have given meaning to the research presented in this thesis and to the development of NavigAItor, which, as demonstrated in previous examples, appears to operate efficiently. Although this evaluation is subjective and based on the knowledge gained during this project, NavigAItor is presented as a valuable tool for developers and researchers in the AI field, providing guidance on which LLM best suits their needs. It would be interesting for NavigAItor to undergo future analysis with performance tests conducted by a larger number of specialized users to evaluate its usability and performance more comprehensively. This project contributes to the field of technology, which is still relatively unknown but has enormous potential. By automating tasks previously performed by humans, efficiency and speed of processes are improved. In summary, this study represents a step forward in the practical application of language models and their impact on the real world. The potential of this project lies in its ability to improve. The generated code has been structured in such a way that it is very easy to test new models by simply finding the necessary requirements to implement them. This structure also allows for the addition of new tasks in a simple and coherent manner. This opens the door to the possibility of testing a greater number of LLMs in the future, addressing other relevant natural language processing tasks. The information gathered from these tests could be used to retrain NavigAItor and keep it always updated, making it an even more useful and cutting-edge tool. 97 Moreover, Pinecone facilitates the ability to upload a larger number of documents to the vector database. This would allow the recommendation assistant to be fed with all the relevant documentation available and even update it to add new language models as they emerge, incorporating the results they generate. Regarding more complex future implementations, it could be useful to transform this agent into a service that, given a project with different types of tasks, is capable of identifying each one and selecting the most efficient model in terms of cost-effectiveness to execute them. In this way, the agent could call these models with the corresponding task, optimizing the process integrally. Finally, creating numerical metrics based on the tasks from the use cases carried out could be contemplated to evaluate certain important characteristics when performing such tasks. This would allow the development of an algorithm that quantitatively scores the responses generated by each model, functioning as a sort of benchmark. 98 BIBLIOGRAFÍA Xi∗†, Zhiheng, Chen∗, Wenxiang and Guo∗, Xin. 2023. The Rise and Potential of Large Language Model. [Online] 9 19, 2023. https://arxiv.org/pdf/2309.07864. A.Zhang. 2024. What is Chain-of-Thought Prompting(CoT)? Explained in Everyday Language for AI Beginners. [Online] 2 21, 2024. https://medium.com/ai-for-absolute-beginners/what-is-chain-of-thoughtprompting-cot-explained-in-everyday-language-for-ai-beginners-88861f64c657. Alkhayrat, Maha, Aljnidi, Mohamad and Aljoumaa, Kadan. 2020. A comparative dimensionality reduction study in telecom customer segmentation using deep learning and PCA. [Online] 2 2020. https://www.researchgate.net/publication/338995559_A_comparative_dimensionality_reduction_study _in_telecom_customer_segmentation_using_deep_learning_and_PCA. Alvarado, Paulo. 2023. La generación aumentada por recuperación (RAG). [Online] 11 5, 2023. https://medium.com/@eltechno/la-generaci%C3%B3n-aumentada-por-recuperaci%C3%B3n-ragdcae0a571f4b. Chroma. 2024. chroma the AI-native open-source embedding database. [Online] 2024. https://www.trychroma.com/. Coelho, Aimee. 2024. Quantization in LLMs: Why Does It Matter? Medium. [Online] Enero 11, 2024. https://medium.com/data-from-the-trenches/quantization-in-llms-why-does-it-matter-7c32d2513c9e. D, Soren. 2023. Understanding Transformer model architectures. [Online] 2 13, 2023. https://www.practicalai.io/. Encarnación, Johnny. 2023. Prompt Engineering Explained: The Key to Unlocking AI’s Potential. Medium. [Online] 5 8, 2023. https://medium.com/aimonks/prompt-engineering-explained-the-key-to-unlocking-aispotential-936a79b177bc. Escalona, Mario Arias. 2023. GENERACIÓN AUMENTADA DE RECUPERACIÓN (RAG): IA GENERATIVA CON TUS PROPIOS DATOS. [Online] diciembre 17, 2023. https://www.thepowerplatformcave.com/rag-iagenerativa-con-tus-datos/. —. 2023. GENERACIÓN AUMENTADA DE RECUPERACIÓN (RAG): IA GENERATIVA CON TUS PROPIOS DATOS. [Online] 12 17, 2023. https://www.thepowerplatformcave.com/rag-ia-generativa-con-tus-datos/. 99 Feldges, Claude. 2023. Word Embeddings and Text Embeddings: a Comparison. [Online] 6 25, 2023. https://medium.com/@claude.feldges/word-embeddings-and-text-embeddings-a-comparison9547f8f0c9a3. Ghosh, Bijit. 2024. RAG Vs VectorDB. Medium. [Online] 1 18, 2024. https://medium.com/@bijit211987/ragvs-vectordb-2c8cb3e0ee52. HuggingFace. Hugging Face - ELECTRA. [Online] https://huggingface.co/docs/transformers/model_doc/electra. Jawade, Bhavin. 2023. Demystifying GQA — Grouped Query Attention for Efficient LLM Pre-training. [Online] 12 27, 2023. https://towardsdatascience.com/demystifying-gqa-grouped-query-attention3fb97b678e4a. Josue. 2021. Turing Test. [Online] 1 8, 2021. https://medium.com/technology-hits/turing-testae3803942b60. Kamradt, Greg. 2024. 5 Levels Of Text Splitting. GitHub. [Online] 2024. https://github.com/FullStackRetrievalcom/RetrievalTutorials/blob/main/5_Levels_Of_Text_Splitting.ipynb. Kanade, Vijay. 2023. What Is a Large Language Model (LLM)? Meaning, Types, Working, and Examples. [Online] 2023. https://www.spiceworks.com/tech/artificial-intelligence/articles/what-is-llm/#_002. Kumar, Sachin. 2024. Evaluating Advanced Retrieval Augmented Generation : Comparisons and Evaluations of various RAG techniques. [Online] 4 12, 2024. https://medium.com/@techsachin/evaluating-advancedretrieval-augmented-generation-comparisons-and-evaluations-of-various-rag-32fea2de155a. Langchain. 2024. Conversation Buffer. [Online] 2024. https://python.langchain.com/v0.1/docs/modules/memory/types/buffer/. LangChain. 2024. LangChain. Text Splitters. [Online] 2024. https://python.langchain.com/docs/modules/data_connection/document_transformers/. Lipenkova, Janna. 2022. Choosing the right language model for your NLP use case. [Online] 9 26, 2022. https://towardsdatascience.com/choosing-the-right-language-model-for-your-nlp-use-case1288ef3c4929. 100 Lu, P., B. Peng, H. Cheng, et al. 2023. Chameleon: Plug-and-play compositional reasoning with large language models. 2023. Martínez, M. en C. Edgardo Adrián Franco. Estructuras de datosTema 05: Tablas hash. [Online] https://docencia.eafranco.com/materiales/estructurasdedatos/05/Tema05.pdf. Meta. 2023. Building Generative AI Features Responsibly. [Online] Septiembre 27, 2023. https://about.fb.com/news/2023/09/building-generative-ai-features-responsibly/. Michael Osborne, profesor de Machine Learning de la Universidad de Oxford. 2023. 2023. Microsoft. 2024. Azure AI Services. [Online] 2024. https://azure.microsoft.com/en-us/products/aiservices/. Mishra, Onkar. 2023. Using langchain for Question Answering on Own Data. [Online] 8 7, 2023. https://medium.com/@onkarmishra/using-langchain-for-question-answering-on-own-data3af0a82789ed. Mistral AI, Equipo de Mistral. 2024. Mistral AI. [Online] 2024. https://mistral.ai/news/mistrallarge/?ref=aihub.cn. Nantasenamat, Chanin. 2024. Streamlit. [Online] 2024. https://streamlit.io/. Noyan, Merve. 2023. Introduction to Quantization cooked . Hugging Face. [Online] 8 25, 2023. https://huggingface.co/blog/merve/quantization. OpenAI. 2024. New Embeddings Models OpenAI. [Online] 2024. https://openai.com/blog/new-embeddingmodels-and-api-updates. —. 2024. What are Embeddings. OpenAI. [Online] 2024. https://platform.openai.com/docs/guides/embeddings/what-are-embeddings. Ortega, Cristina. 2023. Árbol de decisión: Qué es, tipos, ventajas y ejemplo. [Online] 2023. https://www.questionpro.com/blog/es/arbol-de-decision/. Peter Lee, vicepresidente corporativo de Microsoft. 2016. Blog oficial de Microsoft . [Online] 3 25, 2016. Pinecone. 2024. Conversational Memory for LLMs with Langchain. [Online] 2024. https://www.pinecone.io/learn/series/langchain/langchain-conversational-memory/. —. 2024. Pinecone. [Online] 2024. https://www.pinecone.io/. 101 Qin, Y., S. Hu, Y. Lin, et al. 2023. Tool learning with foundation models. . 2023. Rossum, Guido van. 1989. Python. [Online] 1989. https://www.python.org/downloads/. Ruder, Sebastian. 2016. On word embeddings - Part 1. [Online] 4 11, 2016. https://www.ruder.io/wordembeddings-1/. Schick, T., J. Dwivedi-Yu, R. Dessì, et al. 2023. Toolformer: Language models can teach themselves to use tools. 2023. Sotaquirá, Miguel. 2023. ¿Qué son los Embeddings? codificandobits. [Online] Agosto 28, 2023. https://www.codificandobits.com/blog/embeddings-y-llms/. Stanford University, Center for Research on Foundation Models. 2024. HELM. [Online] 3 1, 2024. https://crfm.stanford.edu/helm/lite/v1.1.0/#/. Thcookieh. 2024. Embeddings + Knowledge Graphs: El futuro de la IA Generativa. [Online] 4 4, 2024. https://medium.com/@thcookieh/embeddings-knowledge-graphs-el-futuro-de-la-ia-generativac7795554f1d8. Vaswani, Ashish. 2017. Attention Is All You Need. Medium. [Online] 2017. https://arxiv.org/pdf/1706.03762.pdf. Word Embeddings through Hellinger PCA. Remi Lebret and Ronan Collobert. 2017. 1 4, 2017. Yu. A. Malkov, D. A. Yashunin. 2018. Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs. [Online] 2018. https://arxiv.org/abs/1603.09320. Yule Wang, PhD. 2023. A Complete Guide to LLMs-based Autonomous Agents(Part I). Medium. [Online] 10 10, 2023. https://medium.com/the-modern-scientist/a-complete-guide-to-llms-based-autonomousagents-part-i-69515c016792. 102 APÉNDICES Apéndice A - Imágenes de los resultados utilizados en el formulario A.1 Resultados en Talent Scan A.1.1 GPT-3.5-Turbo-16K Figura 0-1.Guion de la entrevista 2 usando el modelo de OpenAI 103 Figura 0-2. Soft Skills de la Entrevista 2 usando el modelo de OpenAI 110 A.1.3 LLAMA-2-Chat-70B Figura 0-9. Guion de la entrevista 2 usando el modelo de LLAMA 111 Figura 0-10. Soft Skills de la entrevista 2 usando el modelo de LLAMA 112 Figura 0-11. Technical Skills de la entrevista 2 usando el modelo de LLAMA 113 Figura 0-12. Conclusiones de la entrevista 2 usando el modelo de LLAMA 114 A.2 Resultados en Smart Call Transcript A.2.1 GPT-3.5-Turbo-16K Figura 0-13. Guion de la llamada 1 usando el modelo de OpenAI 115 Figura 0-14. Resumen de la llamada 1 usando el modelo de OpenAI Figura 0-15.Sentimientos de la llamada 1 usando el modelo de OpenAI 116 A.2.2 Mistral-Large Figura 0-16. Guion de la llamada 1 usando modelo de MISTRAL 117 Figura 0-17. Resumen de la llamada 1 usando modelo de MISTRAL Figura 0-18. Sentimientos de la llamada 1 usando modelo de MISTRAL 118 A.2.3 LLAMA-2-Chat-70B Figura 0-19. Guion de la llamada 1 usando modelo de LLAMA 119 Figura 0-20. Resumen de la llamada 1 usando modelo de LLAMA Figura 0-21. Sentimientos de la llamada 1 usando modelo de LLAMA 126 conclusión detallada. Un recurso poderoso para reclutadores que acelera la toma de decisiones de contratación de forma precisa y eficiente.") st.markdown('</div>', unsafe_allow_html=True) # Cerrar el contenedor with col2: st.markdown('<div style="margin-bottom: 20px;">', unsafe_allow_html=True) # Agregar margen inferior st.markdown('<h2 style="text-align: left; display: inlineblock;">Principales métricas</h2>', unsafe_allow_html=True) st.markdown('<hr style="border: 1px solid #000; margin: 0;">', unsafe_allow_html=True) st.markdown(f''' <div style="margin-top: 20px; display: flex; margin-bottom: 20px;"> <div style="margin-right: 20px; display: flex; flex-direction: column; align-items: center;"> <img src="data:image/png;base64,{encoded_image1}" style="margin-top: -20px; height: 40px; width: 40px; object-fit: contain;"> <p style="font-size: 12px; font-weight: bold; text-align: center;">Eficiencia de la evaluación</p> </div> <div style="margin-right: 20px; display: flex; flex-direction: column; align-items: center;"> <img src="data:image/png;base64,{encoded_image1}" style="margin-top: -20px; height: 40px; width: 40px; object-fit: contain;"> <p style="font-size: 12px; font-weight: bold; text-align: center;">Mejora en la selección de candidatos</p> </div> <div style="display: flex; flex-direction: column; align-items: center;"> <img src="data:image/png;base64,{encoded_image1}" style="margin-top: -20px; height: 40px; width: 40px; object-fit: contain;"> <p style="font-size: 12px; font-weight: bold; text-align: center;">Satisfacción del reclutador</p> </div> </div> ''', unsafe_allow_html=True) #Para subir la entrevista, parte de la interfaz gráfica formCol1, formCol2, formCol3 = st.columns([0.15,0.7,0.15], gap="large") #Variables de streamlit que se utilizan durante el programa 127 if 'uploaded_file' not in st.session_state: st.session_state['uploaded_file'] = None if 'count' not in st.session_state: st.session_state.count = 0 if 'guion' not in st.session_state: st.session_state.guion = None if 'softskills' not in st.session_state: st.session_state.softskills = "Las soft skills aparecerán aquí" if 'technicalskills' not in st.session_state: st.session_state.technicalskills = "Las competencias técnicas aparecerán aquí" if 'resumen' not in st.session_state: st.session_state.resumen = "Las conclusiones de la entrevista aparecerán aquí" if 'jobrole' not in st.session_state: st.session_state.jobrole = None with formCol2: with st.form("interviewTranscript"): st.write('## Adjunta la entrevista y nosotros te ayudaremos a analizar al candidato.') #Subimos el txt que contiene la entrevista y lo guardamos en uploaded_file uploaded_file = st.file_uploader("Suba la entrevista para su analisis", type=["txt"]) #Los roles de las vacantes opciones = ['','Chief Happiness Officer','Technical RPA consultant', 'Data analyst', 'Project manager', 'Otros'] jobrole = st.selectbox('Selecciona la vacante', opciones) if jobrole=='Otros': jobrole = st.text_input('Escriba la posición') #Boton que procesa el texto de la entrevista proporcionada if st.form_submit_button("Analizar Entrevista ►",type='primary'): st.session_state['uploaded_file'] = uploaded_file.read().decode('utf8') with st.spinner("Transcribiendo..."): #Si se ha cargado bien el txt nos aseguramos de que el guion no se ha generado previamente, y transcribimos el txt if st.session_state['uploaded_file'] is not None: 128 if st.session_state.count == 0: if st.session_state.guion is None: # Asegúrate de que el guion no se haya generado previamente ##transcript = audio_transcript(uploaded_file) guion = interview_transcript(st.session_state['uploaded_file']) st.session_state.guion = guion st.session_state.count = 1 #Generamos dos columnas para la transcripcion y los tres tabs formCol1, formCol2 = st.columns([0.5,0.5], gap="large") #Si se ha generado el guion if st.session_state.count == 1: #Metemos en la segunda columna los tres tabs: "Soft Skills", "Competencias técnicas", "Conclusiones de la entrevista" with formCol2: tab1, tab2, tab3 = st.tabs(["Soft Skills", "Technical Skills", "Conclusiones de la entrevista"]) #Empezamos con el primer tab --> Soft skills with tab1: if st.button("Analizar Soft Skills"): # Si se ha pulsado el Botón para generar soft skills if st.session_state.guion is not None: # Asegúrate de que el guion esté generado with st.spinner("Analizando Soft skills..."): guion = st.session_state.guion #Cogemos el guion st.session_state.jobrole = jobrole #Cogemos el rol del vacante softskills = soft_skills(st.session_state.jobrole,guion) #Llamamos a la funcion soft_skills st.session_state.softskills = softskills st.success("Soft skills analizadas!") #Para escribir las soft skills analizadas en el espacio que corresponde output_placeholder1 = st.empty() output_placeholder1.write(st.session_state.softskills) #Segundo tab --> Technical skills 129 with tab2: if st.button("Analizar Technical Skills"): #Si pulsamos el Botón para generar technical skill if st.session_state.guion is not None: # Asegúrate de que el guion esté generado with st.spinner("Generando Technical Skills..."): guion = st.session_state.guion st.session_state.jobrole = jobrole technical_skills_result = technicalskills(st.session_state.jobrole,guion) #Llamamos a la funcion technicalskills st.session_state.technicalskills = technical_skills_result st.success("Technical Skills analizadas!") #Para escribir las technical skills analizadas en el espacio que corresponde output_placeholder2 = st.empty() output_placeholder2.write(st.session_state.technicalskills) #Tercer tab --> Resumen with tab3: if st.button("Generar conclusiones de la entrevista"):#Si pulsamos el Botón para generar resumen if st.session_state.guion is not None: # Asegúrate de que el guion esté generado with st.spinner("Generando conclusión..."): guion = st.session_state.guion #Para tener en el resumen una descripción detallada dependiente del rol del vacante, hemos considerado hacerlo por dos vías: #Hemos realizado la descripción a mano de dos de los roles y para el resto hemos utilizado la funcion jobDescription que te genera #con ia la descripción pertinente para ese rol if st.session_state.jobrole == "Chief Happiness Officer": jobdescription= '''Propósito del puesto: El Chief Happiness Officer (CHO) es responsable de promover un ambiente de trabajo positivo y motivador en la organización. Su objetivo principal es garantizar la felicidad y el bienestar de los empleados, fomentando la satisfacción laboral y promoviendo una cultura de colaboración y apoyo mutuo. El CHO trabaja en estrecha colaboración con los líderes y equipos de Recursos Humanos para implementar 130 estrategias y programas que mejoren el compromiso y la satisfacción de los empleados. Responsabilidades clave: 1. Desarrollar e implementar programas y actividades que promuevan la felicidad y el bienestar de los empleados. 2. Colaborar con los líderes de la organización para identificar oportunidades de mejora en el ambiente laboral y proponer soluciones innovadoras. 3. Realizar encuestas de satisfacción y análisis de clima laboral para evaluar el nivel de felicidad y satisfacción de los empleados. 4. Organizar eventos y actividades de team building para fortalecer el espíritu de equipo y la colaboración entre los empleados. 5. Brindar apoyo y asesoramiento a los empleados en temas relacionados con el bienestar emocional y la conciliación trabajo-vida personal. Habilidades esenciales: 1. Excelentes habilidades de comunicación y capacidad para establecer relaciones sólidas con los empleados de todos los niveles de la organización. 2. Conocimiento profundo de las mejores prácticas en bienestar laboral y satisfacción de los empleados. 3. Capacidad para identificar y abordar problemas y conflictos en el ambiente laboral de manera efectiva y empática. 4. Habilidades de liderazgo y capacidad para influir positivamente en la cultura organizacional. 5. Orientación al detalle y capacidad para analizar datos y métricas relacionadas con el bienestar y la satisfacción de los empleados. ''' if st.session_state.jobrole == "Technical RPA consultant": jobdescription = '''Propósito del puesto: El Consultor Técnico desempeña un papel fundamental en la implementación de soluciones tecnológicas para nuestros clientes. Trabajando en estrecha colaboración con el equipo de proyectos, el Consultor Técnico es responsable de 131 brindar asesoramiento y soporte técnico, asegurando la entrega exitosa de proyectos y la satisfacción del cliente. Responsabilidades clave: 1. Colaborar con el equipo de proyectos en la definición de requisitos técnicos y funcionales para la implementación de soluciones. 2. Desarrollar y mantener soluciones tecnológicas utilizando Python y Excel, asegurando su eficiencia y calidad. 3. Participar en la configuración y personalización de sistemas, asegurando su correcto funcionamiento y adaptación a las necesidades del cliente. 4. Realizar pruebas y depuración de soluciones, identificando y resolviendo problemas técnicos. 5. Brindar capacitación y soporte técnico a los usuarios finales, asegurando una correcta adopción de las soluciones implementadas. Habilidades esenciales: 1. Experiencia demostrable en el desarrollo de soluciones utilizando Python. 2. Amplio conocimiento y experiencia en el uso de Excel para el análisis y manipulación de datos. 3. Experiencia en la implementación de al menos 2 proyectos de Automatización Robótica de Procesos (RPA). 4. Habilidades interpersonales destacadas, incluida la empatía y la capacidad de trabajar en equipo. 5. Capacidad para comunicarse de manera efectiva y presentar ideas técnicas de manera clara y concisa. ''' else: jobdescription=jobDescription(jobrole) st.session_state.jobrole=jobrole #Una vez tenemos la jobDescription llamamos a la funcion resumen_interview_prueba que tiene en cuenta la descripción anterior y te devuelve un resumen de la entrevista resumen = resume_interview(guion,position = st.session_state.jobrole, jobdescription=jobdescription) st.session_state.resumen = resumen st.success("Conclusión generada!") 132 #Mostramos finalmente el resumen generado output_placeholder3 = st.empty() output_placeholder3.write(st.session_state.resumen) #En la columna 1 mostramos el guion de la entrevista que le pasamos en el txt with formCol1: st.title('Guion de la entrevista') st.write(st.session_state.guion) C.2 functions.py import streamlit as st import os from langchain.chat_models import AzureChatOpenAI from langchain.prompts import ChatPromptTemplate from mistralai.client import MistralClient from mistralai.models.chat_completion import ChatMessage import requests import json azureOpenAIKey = st.secrets["AZURE"]["OPENAI_KEY"] os.environ["OPENAI_API_TYPE"] = "azure" os.environ['OPENAI_API_KEY'] = azureOpenAIKey os.environ['OPENAI_API_VERSION'] = "2023-07-01-preview" os.environ['OPENAI_API_BASE'] = st.secrets["AZURE"]['API_BASE'] openai_api_key = st.secrets["AZURE"]['OPENAI_API_KEY'] # Definición de las variables globales de los modelos global OPENAI_MODELO global LLAMA_MODELO global MISTRAL_MODELO # Asignación de valores a las variables OPENAI_MODELO = "Modelo de OpenAI" LLAMA_MODELO = "Modelo de LLAMA" MISTRAL_MODELO = "Modelo de MISTRAL" # Aquí podemos cambiar el modelo a evaluar modelo = MISTRAL_MODELO 133 #--------------------------------------------FUNCIONES DE LLAMADAS A LOS MODELOS- -------------------------------------------------------------- #Funcion que llama al modelo de OPENAI con el prompt concreto def llm_openai(system_prompt, human_prompt): #llm = AzureChatOpenAI(deployment_name='gpt4-32k',model_name='gpt-432k',temperature=0.4,max_tokens=8000,streaming=True,openai_api_version="2023-0515",openai_api_base="https://str-nexus-azureopenai.openai.azure.com/",) llm = AzureChatOpenAI(deployment_name='gpt-35-turbo-16k', model_name='gpt-35turbo-16k',temperature=0.1,max_tokens=1000) generalTemplate = ChatPromptTemplate.from_messages([ ( "system" , system_prompt), ( "human",human_prompt), ]) prompt = generalTemplate.format_messages() answer = llm(prompt) return answer.content #Funcion que llama al modelo de MISTRAL con el prompt concreto def llm_mistral(system_prompt, human_prompt): client = MistralClient( endpoint="https://Mistral-large-hqhggserverless.eastus2.inference.ai.azure.com", api_key="t6tqNxlVz0QkYmKD0FJxmnALeHnASm1s" ) chat_response = client.chat( model="azureai", messages=[ ChatMessage(role="system",content=system_prompt ), ChatMessage(role="user",content=human_prompt), ], max_tokens=1000, ) return chat_response.choices[0].message.content #Funcion que llama al modelo de LLAMA con el prompt concreto def llm_llama(system_prompt, human_prompt): # URL a la que se enviará la solicitud POST 134 url = 'https://Llama-2-70b-chat-vvyexserverless.eastus2.inference.ai.azure.com/v1/chat/completions' # Tu token Bearer y API key headers = { 'Authorization': 'Bearer 8fRGEsyEQp8LvO91DLtDaXFfJSgABDLD', 'Content-Type': 'application/json' } # Datos que deseas enviar como parte del cuerpo de la solicitud POST datos = { "messages":[ { "role": "system", "content": system_prompt}, {"role": "user", "content": human_prompt} ], "temperature": 0.1, "max_tokens": 1000, } # Realizar la solicitud POST respuesta = requests.post(url, headers=headers, json=datos) respuesta_json = json.loads(respuesta.text) return respuesta_json["choices"][0]["message"]["content"] #---------------------------------------------FUNCION QUE SELECCIONA EL MODELO A LLAMAR----------------------------------------------- def generar_texto(system_prompt, human_prompt, modelo): answer = "Aqui vendrá la respuesta del modelo con el prompt indicado" if(modelo == OPENAI_MODELO): answer = llm_openai(system_prompt, human_prompt) if(modelo == MISTRAL_MODELO): answer = llm_mistral(system_prompt, human_prompt) if(modelo == LLAMA_MODELO): answer = llm_llama(system_prompt, human_prompt) 135 return answer #-----------------------------------------------FUNCIONALIDADES DEL CASO DE USO-- --------------------------------------------------------- #Le da formato entrevista al guion proporcionado en el .txt def interview_transcript(transcript): system_prompt = "Eres un asistente que ayuda a crear un guion de una transcripcion de audio de la entrevista para la empresa Stratesys." human_prompt = """Te voy a adjuntar un texto que es la transcripción de una entrevista. Realiza la transcripción en Español. En la transcripción no está definido quién es el entrevistador y quien es el entrevistado. Puedes coger este texto y generarme a partir de el un guión entendiendo quien dice que. Quiero que tenga este formato:\n\n Entrevistador: [Mensaje del entrevistador]\nEntrevistado: [Mensaje del entrevistado]\n\n. NO te olvides de poner saltos de línea entre el mensaje del entrevistado y el del entrevistador. en en cuenta que no siempre se intercalan entrevistador y entrevistado, se puede dar el caso donde el emisor hable dos veces seguidas. Para esto, utiliza el contexto para saber quien es el entrevistador y quien el entrevistado. El texto de la transcripcion es el siguiente:\n\n """ + transcript guion = generar_texto(system_prompt, human_prompt, modelo) return guion #Genera las soft skills del entrevistado, explicando el porqué y teniendo en cuenta el rol y los devuelve en formato de texto --> Corresponde al tab1 def soft_skills(jobrole,guion): system_prompt = "Eres un asistente que ayuda a crear un resumen de una entrevista." human_prompt = """Cogiendo el guion de esa entrevista, enuncia una lista de soft skills que detectes del entrevistado y desarrolla porque identificas que el entrevistado tiene esa soft skill. Ten en cuenta que buscamos soft skills características de un: """ + jobrole + """El guion de la entrevista es el siguiente:\n\n""" + guion soft_skills = generar_texto(system_prompt, human_prompt, modelo) 142 #Generamos dos columnas para la transcripcion y los tres tabs formCol1, formCol2 = st.columns([0.5,0.5], gap="large") #Si se ha generado el guion if st.session_state.count == 1: #Metemos en la segunda columna los dos tabs: "Resumen de llamada", "Sentimientos Analizados" with formCol2: tab1, tab2 = st.tabs(["Resumen de llamada","Sentimientos Analizados"]) #Empezamos con el primer tab --> Resumen de la llamada with tab1: if st.button("Resumen de la llamada"): # Si se ha pulsado el Botón para generar el resumen if st.session_state.guion is not None: # Asegúrate de que el guion esté generado with st.spinner("Generando resumen de la llamada..."): guion = st.session_state.guion resumen_llamada = generar_resumen(guion) st.session_state.resumen_llamada = resumen_llamada st.success("Resumen realizado!") #Para escribir el resumen en el espacio que corresponde output_placeholder1 = st.empty() output_placeholder1.write(st.session_state.resumen_llamada) #Segundo tab --> Sentimientos del cliente with tab2: if st.button("Sentimientos del receptor"): #Si pulsamos el Botón para generar sentimientos del cliente if st.session_state.guion is not None: # Asegúrate de que el guion esté generado with st.spinner("Generando los sentimientos del receptor"): guion = st.session_state.guion sentimiento = get_sentiment(guion) st.session_state.sentimiento = sentimiento st.success("Sentimientos analizados!") #Para escribir las technical skills analizadas en el espacio que corresponde output_placeholder2 = st.empty() output_placeholder2.write(st.session_state.sentimiento) #En la columna 1 mostramos el guion de la entrevista que le pasamos en el txt 143 with formCol1: st.title('Guion de la llamada') st.write(guion) D.2 functions.py import streamlit as st import os from langchain.chat_models import AzureChatOpenAI from langchain.prompts import ChatPromptTemplate from mistralai.client import MistralClient from mistralai.models.chat_completion import ChatMessage import requests import json azureOpenAIKey = st.secrets["AZURE"]["OPENAI_KEY"] os.environ["OPENAI_API_TYPE"] = "azure" os.environ['OPENAI_API_KEY'] = azureOpenAIKey os.environ['OPENAI_API_VERSION'] = "2023-07-01-preview" os.environ['OPENAI_API_BASE'] = st.secrets["AZURE"]['API_BASE'] openai_api_key = st.secrets["AZURE"]['OPENAI_API_KEY'] # Definición de las variables globales de los modelos global OPENAI_MODELO global LLAMA_MODELO global MISTRAL_MODELO # Asignación de valores a las variables OPENAI_MODELO = "Modelo de OpenAI" LLAMA_MODELO = "Modelo de LLAMA" MISTRAL_MODELO = "Modelo de MISTRAL" # Aquí podemos cambiar el modelo a evaluar modelo = OPENAI_MODELO #--------------------------------------------FUNCIONES DE LLAMADAS A LOS MODELOS- -------------------------------------------------------------- 144 #Funcion que llama al modelo de OPENAI con el prompt concreto def llm_openai(system_prompt, human_prompt): llm = AzureChatOpenAI(deployment_name='gpt-35-turbo-16k', model_name='gpt-35turbo-16k',temperature=0.1,max_tokens=1000) generalTemplate = ChatPromptTemplate.from_messages([ ( "system" , system_prompt), ( "human",human_prompt), ]) prompt = generalTemplate.format_messages() answer = llm(prompt) return answer.content #Funcion que llama al modelo de MISTRAL con el prompt concreto def llm_mistral(system_prompt, human_prompt): client = MistralClient( endpoint="https://Mistral-large-zfmidserverless.eastus2.inference.ai.azure.com", api_key="52tE6V90gzjXFTKIenr30Tbb3Qrhz70N" ) chat_response = client.chat( model="azureai", messages=[ ChatMessage(role="system",content=system_prompt ), ChatMessage(role="user",content=human_prompt), ], max_tokens=1000, ) return chat_response.choices[0].message.content #Funcion que llama al modelo de LLAMA con el prompt concreto def llm_llama(system_prompt, human_prompt): # URL a la que se enviará la solicitud POST url = 'https://Llama-2-70b-chat-vvyexserverless.eastus2.inference.ai.azure.com/v1/chat/completions' # Tu token Bearer y API key headers = { 'Authorization': 'Bearer 8fRGEsyEQp8LvO91DLtDaXFfJSgABDLD', 145 'Content-Type': 'application/json' } # Datos que deseas enviar como parte del cuerpo de la solicitud POST datos = { "messages":[ { "role": "system", "content": system_prompt}, {"role": "user", "content": human_prompt} ], "temperature": 0.1, "max_tokens": 1000, } # Realizar la solicitud POST respuesta = requests.post(url, headers=headers, json=datos) respuesta_json = json.loads(respuesta.text) return respuesta_json["choices"][0]["message"]["content"] #---------------------------------------------FUNCION QUE SELECCIONA EL MODELO A LLAMAR----------------------------------------------- def generar_texto(system_prompt, human_prompt, modelo): answer = "Aqui vendrá la respuesta del modelo con el prompt indicado" if(modelo == OPENAI_MODELO): answer = llm_openai(system_prompt, human_prompt) if(modelo == MISTRAL_MODELO): answer = llm_mistral(system_prompt, human_prompt) if(modelo == LLAMA_MODELO): answer = llm_llama(system_prompt, human_prompt) return answer #-----------------------------------------------FUNCIONALIDADES DEL CASO DE USO-- --------------------------------------------------------- #Le da formato entrevista al guion proporcionado en el .txt 146 def call_transcript(transcript): system_prompt = "Eres un asistente que ayuda a crear un guion de una transcripcion de audio de una llamada telefónica." human_prompt ="""Te voy a adjuntar un texto que es la transcripción de una llamada telefonica. Realiza la transcripción en Español. Esta transcripción puede contener errores y deberías corregir todo lo que no tenga sentido o temas repetidos que sean claramente un error de transcripción. Si de todo el proceso de interpretación hay partes de la conversación que se salen del objeto de la misma, obvialas.Las faltas de ortogradía que veas, corrígelas tambien. Por ejemplo: no es @Gemay si no @gmail, esto puede ocurrir con otros elementos. En la transcripción no está definido quién es el entrevistador y quien es el entrevistado. Puedes coger este texto y generarme a partir de el un guión entendiendo quien dice que. CADA MENSAJE QUIERO QUE APAREZCA EN UNA LINEA DE TEXTO DIFERENTE, EN FORMATO LISTA, así: -Emisor(Nombre del emisor): [Mensaje del emisor de la llamada]\n\n -Receptor(Nombre del receptor): [Mensaje del receptor de la llamada]\n\n. Es muy importante que identifiques bien al emisor y al receptor. Ten en cuenta que no siempre se intercalan emisor y receptor, se puede dar el caso donde el emisor hable dos veces seguidas. Para esto, utiliza el contexto para saber quien es el emisor y quien el receptor. NO te olvides de poner saltos de línea entre el mensaje del emisor y el del receptor. El texto de la transcripcion es el siguiente:\n\n""" + transcript guion = generar_texto(system_prompt, human_prompt, modelo) return guion #Te hace el resumen de la entrevista def generar_resumen(guion): system_prompt = """Eres un asistente especializado en generar resumenes sobre conversaciones telefónicas. Trabajas en stratesys y haces resumenes sobre llamadas telefónicas donde un receptor contacta con atención al cliente. 147 El resumen debe ser generado desde el punto de vista del agente(emisor) que esta interactuando con el cliente(receptor). La estructura del resumen siempre tiene que ser de esta manera: - Primero: Que pide el cliente, qué problema tiene... - Segundo: Motivo del cliente para realizar tal accion - Tercero: Que le ofrece el agente para tratar de complacer al cliente y solucionar su problema - Cuarto: Conclusion Recuerda que tiene que ser desde el punto de vista del Agente(Emisor) """ human_prompt =""" - **Transcripción de la entrevista**:""" + guion resumen = generar_texto(system_prompt, human_prompt, modelo) return resumen #Genera las habilidades tecnicas del entrevistado, explicando el porqué y teniendo en cuenta el rol y los devuelve en formato de texto --> Corresponde al tab2 def get_sentiment(guion): system_prompt = "Eres un asistente especializado en identificar el sentimiento de un usuario en una transcripción de una llamada telefónica con atencion al cliente." human_prompt ="""Trabajas en stratesys y realizas un análisis del sentimientos de un usuario(el receptor) que realiza una llamada con atencion al cliente porque tiene un problema. Debes de realizar un análisis breve de los sentimientos del cliente(receptor), destacando las partes de la llamada en los que los has percibido. Básate en la conversación para realizar este análisis, y comprueba si el cliente queda satisfecho con la solución del emisor. 148 Ten en cuenta que pueden haber expresiones con cierto tono de sarcasmo y por tanto el significado puede ser distinto que el original. Utiliza el contexto como ayuda para analizar esto La transcripción de la llamada es la siguiente:\n\n""" + guion sentimiento = generar_texto(system_prompt, human_prompt, modelo) return sentimiento 149 Apéndice E - Código de NavigAItor E.1 main.py # Importación de módulos y configuración inicial from lib.utils import * from lib.streaming import * from langchain.document_loaders import PyPDFLoader from langchain.memory import ConversationBufferMemory from langchain.prompts import ( ChatPromptTemplate, HumanMessagePromptTemplate, SystemMessagePromptTemplate, ) from langchain.document_loaders import UnstructuredExcelLoader from langchain.chains import ConversationalRetrievalChain from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.vectorstores import Pinecone import pinecone from langchain.embeddings import AzureOpenAIEmbeddings from langchain.prompts import ( ChatPromptTemplate, HumanMessagePromptTemplate, SystemMessagePromptTemplate, ) import streamlit as st from langchain.chat_models import AzureChatOpenAI import openai from langchain.memory import ConversationSummaryBufferMemory # Configuración de las claves y entornos de Pinecone y Azure OpenAI os.environ["PINECONE_API_KEY"] = # your pinecone api key os.environ["PINECONE_ENV"] = # pinecone enviroment azureOpenAIKey = # your AzureOpenAI api key os.environ["OPENAI_API_TYPE"] = "azure" os.environ['OPENAI_API_KEY'] = azureOpenAIKey os.environ['OPENAI_API_VERSION'] = # ------------- os.environ['OPENAI_API_BASE'] = # ------------- 150 # Inicialización de Pinecone pinecone.init( api_key=os.getenv("PINECONE_API_KEY"), # find at app.pinecone.io environment=os.getenv("PINECONE_ENV"), # next to api key in console ) # Creación de la instancia de Pinecone Index index = pinecone.Index(= # your pinecone index name ) index_name = # your pinecone index name # Configuración de la página de Streamlit st.set_page_config(layout='wide',page_title="NavigAItor", page_icon="🏠") # Sección de presentación en la interfaz de usuario st.title("NavigAItor") col1,col2 = st.columns(2,gap="large") with col1: st.markdown('<h1 style="text-align: left; display: inline-block;">Reto</h1>', unsafe_allow_html=True) st.markdown('<hr style="border: 1px solid #000; margin: 0;">', unsafe_allow_html=True) st.write("Abordar la evaluación de diversos modelos de lenguaje en contextos variados representa un reto significativo. La necesidad de comprender su desempeño en diferentes escenarios y tareas específicas exige una evaluación detallada y precisa para identificar la opción más adecuada en cada caso.") with col2: st.markdown('<h1 style="text-align: left; display: inlineblock;">Solución</h1>', unsafe_allow_html=True) st.markdown('<hr style="border: 1px solid #000; margin: 0;">', unsafe_allow_html=True) st.write("NavigAItor, su asistente virtual especializado en modelos de lenguaje, le proporciona evaluaciones detalladas para una selección informada. Comprenda cómo los modelos GPT de OpenAI, LLAMA y Mistral se desempeñan en casos de uso específicos y descubra cuál se ajusta mejor a sus necesidades.") st.write("¡Potencie sus decisiones en inteligencia artificial y procesamiento del lenguaje natural con NavigAItor, su guía confiable para implementaciones efectivas!") if 'history' not in st.session_state: st.session_state['history'] = '' 151 class CustomDataChatbot: #Metodo de inicialización que se llama automáticamente cnd se crea una instancia de la clase #Configura la API_key de OpenAI y define el modelo de OpenAI que se utilizará en el chat def __init__(self): configure_openai_api_key() self.openai_model = "gpt-4" #Guarda un archivo en una ubicación específica def save_file(self, file): folder = 'tmp' if not os.path.exists(folder): os.makedirs(folder) file_path = f'./{folder}/{file.name}' with open(file_path, 'wb') as f: f.write(file.getvalue()) return file_path @st.spinner('Analizando documentos..') #En este método configuramos los distintos componentes de nuestro asistente - -> cadena de pensamiento def setup_qa_chain(self,memory): # Creamos los embeddings and guardamos en vectordb embeddings = AzureOpenAIEmbeddings(azure_deployment="gpt-embedding", openai_api_version="2023-05-15") #vectordb = Pinecone.from_documents(docs, embeddings, index_name=index_name,namespace = 'DEMO-AsistenteHorse') vectordb = Pinecone.from_existing_index(index_name=index_name, embedding=embeddings, namespace="NavigAItor-RecomendadorLLM") # Define retriever --> Recupera la información retriever = vectordb.as_retriever( search_type='mmr', search_kwargs={'k':8, 'fetch_k':8} ) # Definimos la memoria para que la conversación tenga contexto memory = ConversationBufferMemory(