Arquitectura RAG: 101

Desde el lanzamiento de ChatGPT (OpenAI) en noviembre de 2022 millones de usuarios hemos podido experimentar una nueva forma de relacionarnos con la tecnología. Generó tanta curiosidad durante su lanzamiento que en menos de una semana ya había sido usada por más de 1 millón de personas.

Nuestro paradigma de búsqueda de información que durante muchos años ha estado dominado por el buscador de Google acaba de cambiar. Este buscador sigue siendo imprescindible en nuestro día. Sin embargo, se abren algunos escenarios donde un chatbot basado en un LLM (Large Language Model) puede ser más eficiente que un buscador. Por ejemplo, cuando necesito un resumen sobre un texto, si quiero hacer una traducción rápida o para cambiar el tono de un email.

Incluso a la hora de desarrollar software los LLM han irrumpido en nuestro flujo de trabajo. Después de casi un año usando GitHub Copilot considero que es una herramienta imprescindible en mi día a día. Con el paso del tiempo he percibido como sus sugerencias son cada vez más precisas. Las soluciones que propone no son perfectas pero aceleran el tiempo de desarrollo una barbaridad evitando las consultas constantes a documentación de librerías.

Si tienes poca experiencia programando, el uso de herramientas como GitHub Copilot puede ser contraproducente. Es importante que entiendas las soluciones que te propone y saber decidir en cada momento si son válidas o no para tu contexto.

Limitaciones de los LLM

Los LLMS tiene un conocimiento limitado a los datos que se han usado para entrenarlos. En el caso de ChatGPT, no maneja información posterior a septiembre de 2021. Por ejemplo, si le preguntas por el actual presidente de un país es posible que la respuesta esté desactualizada. Tampoco es posible incorporar información nueva por sí solos. Por ejemplo, añadir documentación sobre el producto que vende tu empresa.

Para incorporar información nueva a un LLM se puede utilizar una arquitectura RAG, que combina la capacidad de recuperación con la de generación. Veamos cómo funciona.

RAG

Generación

Empecemos con la "G" (Generation) de RAG. Es la parte encargada de generar una respuesta a una pregunta del usuario. Esta pregunta junto con instrucciones específicas del chatbot son enviadas al LLM.

El conocimiento de los LLMs es limitado y no siempre actualizado por lo que la respuesta generada puede no ser del todo correcta e incluso en ocasiones "inventada" lo cual es bastante peligroso (lo que se suele llamar "alucinaciones").

Y lo más importante, la generación de la respuesta es una caja negra. No podemos saber cómo el LLM ha llegado a esa respuesta. Por lo que no podemos saber si es correcta o no.

El objetivo de RAG es mejorar el contexto asociado a la pregunta del usuario para aumentar la probabilidad de que la respuesta generada por el LLM sea correcta.

Recuperación Aumentada

¿Cómo podemos incluir más contexto?

La estrategia es muy sencilla, además de enviar al LLM la pregunta y las instrucciones específicas del chatbot, enviaremos información relevante que el LLM pueda usar para dar una respuesta más precisa. A grandes rasgos, le estamos dando al LLM la información que necesita para responder. Esta es la parte de "RA" (Retrieval-Augmented) de RAG. Aunque pueda parecer algo trivial, la composición de un buen Prompt (contexto que enviamos al LLM) es crítico para la generación de buenas respuestas y por ello existe una disciplina llamada Prompt Engineering dedicada en exclusiva a ello.

¿Cómo podemos obtener información relacionada con la pregunta del usuario?

Aunque no es la única forma de conseguirlo, se ha popularizado el uso de embeddings y bases de datos vectoriales para solucionar este problema.

Los embeddings son representaciones vectoriales de palabras, frases, documentos, transcripciones de videos, audios o imágenes. Estos embeddings son una representación en un espacio vectorial multidimensional donde conceptos similares se encuentran "cerca" y conceptos relacionados guardan cierta "distancia" entre ellos.

Las bases de datos vectoriales permiten almacenar y recuperar información basada en vectores. Por ejemplo, podemos almacenar los embeddings de los documentos de una wiki en una base de datos vectorial y luego recuperar los fragmentos más relevantes en relación a la pregunta del usuario.

Flujo RAG con embeddings y bases de datos vectoriales

El proceso de RAG sigue un flujo preciso de transformación y recuperación de información:

1. Vectorización de la consulta: La pregunta del usuario se procesa a través de un modelo de embeddings para obtener su representación vectorial.

2. Búsqueda semántica: Se realiza una búsqueda de similitud coseno en la base de datos vectorial para encontrar los k-vecinos más cercanos al vector de la pregunta.

3. Construcción del contexto: Los fragmentos recuperados se incorporan al prompt siguiendo una estructura predefinida que ayuda al LLM a entender y utilizar el contexto adicional.

4. Generación de respuesta: El LLM procesa el prompt enriquecido y genera una respuesta.

Ventajas de la arquitectura RAG

Precisión y Confiabilidad

RAG mejora significativamente la calidad de las respuestas de dos formas:

1. Contexto actualizado y relevante: Al proporcionar información específica del dominio, el LLM puede generar respuestas más precisas y contextualizadas.

2. Reducción de alucinaciones: Al anclar las respuestas en datos verificables, se minimiza la tendencia del modelo a generar información incorrecta.

Trazabilidad

Ahora el chatbot ya no actúa como una caja negra sino que en sus respuestas puede hacer referencias a datos verificables. Podemos implementar un sistema de citación que vincule cada parte de la respuesta con los fragmentos específicos de la base de conocimiento que la respaldan, proporcionando transparencia y verificabilidad.

Análisis de Costes

Comparado con el fine-tuning, RAG ofrece ventajas significativas en costes:

• Sin reentrenamiento: RAG evita el coste de reentrenar el modelo que es ordenes de magnitud más caro que aplicar la arquitectura RAG.
• Actualización dinámica: Podemos actualizar la base de conocimiento sin tocar el modelo base.
• Menor complejidad operativa: No requiere mantener y versionar modelos personalizados.

Consideraciones Técnicas y Limitaciones

Calidad y Preprocesamiento de Datos

La efectividad de RAG depende criticamente de:

• Calidad del dato: Los datos deben ser precisos, actualizados y bien estructurados.
• Chunking adecuado: La segmentación del texto afecta directamente la relevancia de la recuperación.
• Selección de embeddings: Diferentes modelos de embeddings pueden funcionar mejor según el dominio. De hecho, en Éutika hemos sufrido durante meses problemas en una de nuestras implementaciones RAG debido a utilizar unos embeddings que no estaban optimizados para textos en español, que era el lenguaje principal de nuestra base de conocimiento.

Optimización de Recursos

RAG introduce costes operativos que escalan con el uso:

• Computación de embeddings: Cada consulta requiere vectorización.
• Almacenamiento vectorial: Las bases de datos vectoriales tienen costes de infraestructura.
• Tamaño del contexto: Prompts más grandes aumentan el coste por token del LLM. Cuanta más información envíes al LLM para generar una respuesta, mayor será el coste.

Estos costes se pueden optimizar mediante:

• Caché de embeddings y resultados frecuentes
• Compresión de vectores
• Técnicas de reranking de los resultados vectorizados

Conclusión

La arquitectura RAG representa una solución práctica y escalable para potenciar sistemas LLM. Su capacidad de integrar conocimiento externo verificable, junto con la flexibilidad para actualizar la base de conocimiento sin reentrenamiento, la convierten en una opción robusta para chatbots empresariales. Los beneficios en precisión y control superan significativamente los costes operativos, especialmente cuando se implementan estrategias de optimización adecuadas.