Anatomía de un chatbot basado en LLM con arquitectura RAG

Impacto de los LLMs en nuestro día a día

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.

Supongo que por inercia, mi primer instinto cuando quiero buscar información sobre un tema es hacerlo a través de Google. Es rápido y si las palabras usadas en la búsqueda son específicas el resultado suele ser inmediato. Es más, si estoy usando el móvil es muy cómodo hacer la búsqueda por voz. Sin embargo, hay ocasiones donde para mí tiene mucho más sentido usar ChatGPT. Por ejemplo, cambiar un texto entre tonos formales o informales, obtener la estructura de un tema sobre el que quieres profundizar o ayudarte con la redacción de un email o artículo.

Incluso en el ámbito del desarrollo de software se ha vuelto común apoyarse en LLMs para generar, revisar y corregir código. Llevo más de un año usando GitHub Copilot y me parece increíble cómo sus sugerencias se han vuelto cada vez más precisas. La mayoría de las veces indicando tu intención en el código es capaz de predecir lo que pretendes hacer. Lo normal es que tenga que retocar la solución pero compensa con creces el tiempo que tardaría en hacerlo de cero.

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. Algunos compañeros con un perfil más junior están explorando herramientas como Cursor. Se trata de un editor similar a Visual Studio Code que permite chatear con el código de tu proyecto.

No es oro todo lo que reluce

Los LLMs tienen algunos problemas de base.

El primero es que su conocimiento está limitado al conjunto de datos que se ha usado para entrenarlos. En el caso de ChatGPT, no maneja información posterior a septiembre de 2021. Por ejemplo, si le preguntamos por el precio actual de una acción de una empresa no tendrá acceso a esa información.

El segundo problema es que no pueden acceder a información fuera de su base de conocimiento. El ejemplo más claro es que no puede acceder a información privada como por ejemplo la base de conocimiento de una empresa.

El primer problema lo podemos resolver con agentes. Estos agentes se encargan de buscar información actualizada y devolvérsela al LLM para que pueda generar una respuesta con información actualizada.

Para el segundo problema tenemos varias aproximaciones. La más sencilla es usar una arquitectura RAG (Retrieval-Augmented Generation). En este artículo vamos a explorar cómo funciona esta arquitectura y cómo podemos usarla para crear un chatbot mejorado basado en LLM.

RAG

Generación

Empecemos con la “G” (Generation) de RAG. Es la parte encargada de generar una respuesta a una pregunta del usuario (prompt).

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 Mejorada

¿Cómo podemos incluir más contexto?

Básicamente con cualquier mecanismo que nos permita obtener información relacionada con la pregunta del usuario y que podamos enviar en el prompt al LLM para que lo use en la generación de la respuesta. Esta es la parte de “RA” (Retrieval-Augmented) de RAG.

El prompt es simplemente el conjunto de instrucciones, preguntas o texto que se envían al LLM para obtener una respuesta. Aunque pueda parecer algo trivial 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.

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

A alto nivel, lo que está sucediendo cuando un usuario hace una pregunta al chatbot es lo siguiente:

1. El usuario hace una pregunta al chatbot y esta pregunta se transforma en un vector usando un embedding model.
2. Se busca en la base de datos vectorial aquellos vectores cercanos al vector de la pregunta.
3. Se envía como parte del prompt al LLM la información adicional recuperada en el paso 2 junto a la pregunta inicial del usuario.
4. El LLM genera una respuesta y se devuelve al usuario.

Ventajas de RAG

Mejora la calidad de las respuestas

La principal ventaja de este mecanismo es que podemos añadir contexto relevante a la pregunta del usuario y por lo tanto las respuestas generadas por el LLM serán más precisas.

Evidencias

Podemos incluir en el prompt información adicional que nos permita explicar por qué el LLM ha generado esa respuesta. Por ejemplo, podríamos hacer referencias a elementos de la base de datos vectorizada que han sido usados para generar la respuesta de modo que el usuario pueda comprobar por sí mismo las fuentes de la respuesta.

Coste

La alternativa directa a RAG es utilizar Fine-tuning. Es decir, re-entrenar un LLM añadiendo un nuevo conjunto de datos. Sin embarog, el coste de entrenar un LLM es elevado. Existen nuevas técnicas que abaratan este entrenamiento pero aún así en la mayoría de los casos sigue compensando el coste de RAG (y variantes) frente a usar Fine-tuning.

Contrapartidas de RAG

Calidad de los datos del nuevo dataset

Si el proceso de recuperación y la calidad de los datos que vectorizamos no son suficientemente buenos la calidad de las respuestas puede ser muy baja e incluso peor que la que obtendríamos sin usar RAG.

Coste

El uso de embeddings, la base de datos vectorial y el mayor tamaño del prompt (dado que se incluye un contexto adicional) impactan directamente en el precio de esta solución. Aunque estos costes son relativamente bajos, en escenarios B2C donde el número de usuarios es muy elevado deberíamos tenerlo en cuenta. Incluir en la arquitectura RAG cachés y agentes puede ayudar a reducir estos costes.

Conclusión

La arquitectura RAG permite de una forma bastante simple ampliar las capacidades de los LLMs. Incluir las referencias a los datos usados para generar las respuestas permite al usuario comprobar por sí mismo la calidad de las respuestas. Dado su coste y su baja complejidad RAG se posiciona como una de las primeras opciones a tener en cuenta para el uso de IA Generativa en chatbots.

En próximos artículos profundizaremos en técnicas para mejorar la arquitectura RAG mediante el uso de cachés, agentes y guardarraíles.