Los Grandes Modelos de Lenguaje (o LLMs por sus siglas en Inglés) han demostrado un desempeño impresionante en diferentes tareas de análisis y procesamiento del lenguaje natural y esto en parte ha llevado a todo este «boom» de la Inteligencia Artificial en estos últimos años.
Sin embargo, estos Grandes Modelos de Lenguaje también sufren en la actualidad de muchas limitaciones, específicamente porque en ocasiones no son capaces de responder preguntas en áreas específicas, para los cuales no fueron entrenados, lo cual los lleva a producir alucinaciones cuando son consultados sobre temas que desconocen.
Y recientemente la Generación Aumentada por Recuperación, más conocida como RAG (de Retrieval-Augmented Generation) ha surgido como una solución que permite que el modelo pueda consultar información específica y actualizada de bases de datos externas reduciendo así la probabilidad de alucinaciones y mejorando las respuestas entregadas al usuario.
Así que en este artículo veremos en detalle qué es y cómo funciona esta tecnología RAG aplicada a los LLMs.
El problema de las alucinaciones en los LLM: un ejemplo práctico
Para entender de dónde surge la necesidad de implementar un sistema RAG, partamos de un ejemplo muy sencillo. Supongamos que desarrollamos un chatbot basado en uno de estos Grandes Modelos de Lenguaje y le presentamos la siguiente pregunta: «Dame las especificaciones del último iPhone».
¿Qué ocurre en este escenario? El modelo, muy probablemente, fue entrenado hace varios meses y no tiene esa información del último iPhone que salió al mercado hace 15 días. Ante esta petición, se pueden dar dos situaciones:
- El modelo genera una alucinación: el modelo nos responde detallando características específicas (ej. la pantalla tiene cierta resolución y tamaño, el procesador tiene tales características, una capacidad de almacenamiento específica, etc.). Sin embargo, esas especificaciones corresponden al modelo de iPhone que, entre comillas, «conocía» ese modelo hace un año cuando fue entrenado, no a las del modelo más reciente. El modelo nos genera una respuesta que parece válida pero que no es precisa, ya que no es posible actualizar esa información en tiempo real en un modelo previamente entrenado.
- El modelo indica su falta de conocimiento: dependiendo de cómo haya sido construido el chatbot, el modelo calcula la fecha actual, la compara con el momento en el que fue entrenado (hace casi un año) y nos indica en pantalla que desconoce la información.
Si bien la segunda opción es la esperada, lo ideal sería que pudiésemos obtener las especificaciones exactas del último iPhone independientemente del momento histórico en el cual fue entrenado el modelo.
¿Qué es la Generación Aumentada por Recuperación (RAG)?
Para evitar que el modelo genere alucinaciones, tenemos que presentarle de alguna manera información actualizada y mucho más precisa.
Y RAG es precisamente una solución a este problema: la idea es que el modelo pueda tener acceso a bases de datos externas, provenientes por ejemplo de sitios web, documentos PDF u otro tipo de archivos.
El objetivo es que el modelo pueda extraer esa información relevante de la base de datos para luego generar respuestas fundamentadas.
La arquitectura básica de un sistema RAG se muestra a continuación:

En esta arquitectura:
- Partimos de una pregunta o consulta que plantea el usuario al modelo.
- Contamos con una base de datos que contendrá múltiples documentos (PDFs, enlaces a sitios web, etc.) donde se encuentra la información real (como las características del último iPhone).
- Tanto la pregunta como lo almacenado en la base de datos se llevan a lo que se conoce como un sistema de recuperación (de allí proviene la «R» de Retrieval). Este sistema toma la pregunta y busca qué porciones del texto dentro de la base de datos pueden responder a esa pregunta.
- La información relevante que se extrajo (el contexto) junto con la pregunta original, se le presenta al Gran Modelo de Lenguaje. En este punto, el LLM ya no tiene que empezar a inventar información (alucinar) ni recurrir exclusivamente a lo almacenado en su entrenamiento. Al tener información fresca proveniente del sistema de recuperación, combina ambos elementos y genera una respuesta mucho más específica y precisa.
Detalles técnicos de un sistema RAG
Ya teniendo clara la idea básica (presentarle al modelo no solo la pregunta, sino también un contexto proveniente de bases de datos externas), es necesario entender todos los detalles técnicos para implementar esta tecnología.
A continuación, veremos el paso a paso de los elementos que conforman un sistema RAG:
1. Construcción de la Base de Datos Vectorial
El primer paso es construir lo que se conoce como la base de datos vectorial. Y resulta necesario pues tenemos nuestros documentos almacenados y debemos llevarlos a una representación que el modelo pueda entender computacionalmente.
En primer lugar, no podemos introducir la totalidad del documento al modelo, porque este tiene un límite de capacidad de procesamiento de información. Lo que hacemos es tomar cada documento y partirlo en diferentes trozos o pedazos, un proceso conocido como la creación de chunks. Cada chunk puede ser un párrafo, una frase o un conjunto de párrafos (nosotros podemos controlar este tamaño al momento de implementar el sistema).
Sin embargo, el modelo realmente no interpreta texto de forma directa, sino que interpreta cantidades numéricas. Por esto, debemos representar cada bloque de texto (cada chunk) de forma numérica como un vector. Estos vectores de texto representados numéricamente se conocen como embeddings.
Una vez representados todos los trozos vectorialmente, esa información se almacena y se indexa en lo que se conoce precisamente como una base de datos vectorial. A partir de este momento, lo que se consultará no son directamente los documentos originales, sino la base de datos vectorial:

2. Procesamiento de la consulta
El segundo paso consiste en tomar la consulta introducida por el usuario en lenguaje natural (texto) y representarla numéricamente como un vector. Es decir, lo que se hace es obtener el «embedding» de la pregunta:

En este punto ya se tienen los documentos de referencia representados vectorialmente (y almacenados en la base de datos vectorial) junto con la consulta del usuario (también representada como un «embedding»). Así que la siguiente fase es la etapa de recuperación.
3. Fase de recuperación (o retrieval)
Teniendo tanto la pregunta como la base de datos en formato vectorial, llevamos esta información al sistema de recuperación. Este sistema tomará el vector de la pregunta y el conjunto de vectores de la base de datos para evaluar qué porciones de texto guardan similitud y podrían responder al usuario.
A nivel de álgebra lineal, esto se interpreta como una comparación de vectores a través de una operación matemática conocida como la similitud del coseno. Esta métrica nos indica el nivel de relación: si dos vectores son muy similares, el resultado de la comparación será un número cercano a 1; si prácticamente no guardan relación, será casi igual a 0.
Supongamos que hacemos iterativamente estas comparaciones contra cinco elementos de la base de datos vectorial:

- Comparación con el primer chunk: 0.4
- Comparación con el segundo chunk: 0.6
- Comparación con el tercer chunk: 0.2
- Comparación con el cuarto chunk: 0.5
- Comparación con el quinto chunk: 0.7
De todas las comparaciones realizadas, debemos definir un umbral (por ejemplo 0.3, 0.4 o 0.5) a partir del cual consideraremos que la similitud es relativamente alta. Luego, generamos un ranking de mayor a menor con las comparaciones que superaron dicho umbral.
En el ejemplo anterior, organizando de la similitud más alta a la más baja, tendríamos:
- Último chunk: 0.7
- Segundo chunk: 0.6
- Penúltimo chunk : 0.5
Tomamos esas tres porciones de información (chunks) de la base de datos, pues son las que guardan mayor relación semántica con la consulta del usuario. Estas tres conformarán el resultado o salida del sistema de recuperación.
Si te interesa ver de forma práctica este concepto, te invito a dar una mirada al curso de Búsqueda Semántica, acá en la Academia Online, donde vemos cómo usar LLMs pre-entrenados para precisamente implementar un sistema de recuperación conocida como búsqueda densa (o dense retrieval).
3. Integración con el LLM mediante Prompt Engineering
El último paso es presentarle esta información pre-filtrada al Gran Modelo de Lenguaje. Esto se hace a través del diseño de un prompt, que es básicamente una instrucción sobre cómo queremos que genere la respuesta.
El prompt en un sistema RAG se compone de tres partes clave:

- Descripción de la tarea: se le indica al modelo en lenguaje natural su rol: «Tú eres un asistente que va a realizar una tarea de pregunta-respuesta. Utiliza el siguiente contexto para responder a la pregunta. Si en ese contexto no se encuentra la respuesta, simplemente indica que no sabes la respuesta». Con esto limitamos estrictamente la posibilidad de alucinaciones.
- La pregunta: la consulta original del usuario en formato de lenguaje natural.
- El contexto: las porciones de texto relevantes entregadas por el sistema de recuperación (el retriever).
Al presentarle esta estructura al Gran Modelo de Lenguaje, el modelo no tiene opción de comenzar a inventar información (o bueno, ¡al menos será menos probable que lo haga!). Ya tiene descrita claramente su tarea, cuenta con la pregunta del usuario y se le ha indicado que busque la respuesta exclusivamente en el contexto extraído de la base de datos vectorial. Así, la respuesta final será idealmente específica, veraz y estará fundamentada en la información presente en los documentos.
Conclusión
En este artículo hemos analizado la idea básica y los detalles técnicos de cada uno de los elementos que conforman un sistema RAG.
En esencia, si queremos que los Grandes Modelos de Lenguaje generen respuestas precisas y evitar las alucinaciones, la solución radica en proporcionar junto con la pregunta el contexto adecuado. Este contexto es recuperado mediante bases de datos externas vectorizadas, particionadas en chunks, y evaluadas matemáticamente utilizando la similitud del coseno para extraer de manera exclusiva aquella información estrictamente relevante a la consulta del usuario.
Si te interesa, en la sección Proyectos de la Academia Online, puedes ver cómo se implementa de forma práctica un sencillo sistema RAG para consultar nuestros propios documentos.
