Construir un pipeline RAG simple: un recorrido conceptual

La generación aumentada por recuperación (RAG) suena como una única técnica. En realidad es un pipeline: una secuencia de etapas pequeñas y ordinarias que juntas permiten a un modelo de lenguaje responder preguntas usando tus propios documentos en lugar de solo lo que memorizó durante el entrenamiento. Ninguna de las etapas es ingeniosa por sí sola. La habilidad está en conectarlas para que, en el momento en que el modelo escribe su respuesta, el pasaje correcto de tu texto esté delante de él. Este recorrido construye ese pipeline etapa por etapa y señala dónde tiende a romperse cada una.

Por qué existe RAG

Un modelo de lenguaje sabe aquello con lo que fue entrenado. No conoce el manual de tu empresa, el informe de incidentes de la semana pasada ni el contenido de un PDF que subiste hace un minuto. Podrías ajustar el modelo con ese material, pero eso es caro, lento de actualizar y fácil de hacer mal. RAG toma el camino más barato: deja el modelo en paz y, para cada pregunta, encuentra los pasajes relevantes y los pega en el prompt. El modelo entonces responde a partir de un texto que puede ver en lugar de una memoria que tal vez no tenga.

El modelo mental es un asistente competente con un libro abierto. El asistente es inteligente pero ignorante de tus particularidades; el libro tiene las particularidades pero no puede razonar. RAG le entrega al asistente la página correcta en el momento correcto. Todo lo que sigue está al servicio de "la página correcta en el momento correcto".

Etapa 1: Trocear tus documentos

No puedes entregar al modelo una biblioteca entera, así que divides tus documentos en piezas más pequeñas llamadas fragmentos (chunks). Un fragmento es simplemente un pasaje: unos párrafos, una sección, una página. El troceado importa más de lo que parece. Fragmentos demasiado grandes diluyen la frase relevante con ruido circundante y desperdician espacio en el prompt. Fragmentos demasiado pequeños pierden el contexto que hace significativa a una frase: una línea que dice "esto no está soportado" es inútil sin el párrafo que dice qué es "esto".

Un valor por defecto razonable es trocear siguiendo la estructura natural del documento: por sección, encabezado o párrafo, en lugar de por un recuento ciego de caracteres. Mantén juntas las ideas relacionadas. Muchos pipelines también permiten que los fragmentos se solapen ligeramente, para que una frase cerca de un límite aún aparezca entera en al menos un fragmento. No hay un tamaño correcto universal; depende de tus documentos, y vale la pena revisarlo una vez que puedas medir resultados.

Etapa 2: Embeddings y el almacén de vectores

Para encontrar fragmentos relevantes más tarde, necesitas una manera de comparar una pregunta con cada fragmento por significado, no solo por coincidencia de palabras clave. Esto es lo que proporcionan los embeddings. Un modelo de embeddings convierte una pieza de texto en una lista de números —un vector— posicionado de modo que los textos con significado similar caigan cerca unos de otros en ese espacio numérico. "¿Cómo restablezco mi contraseña?" y "pasos para recuperar el acceso a la cuenta" casi no comparten palabras pero quedan cerca como vectores.

Pasas cada fragmento por el modelo de embeddings una vez, guardando el vector de cada fragmento junto al texto original. Esa colección vive en un almacén de vectores: una base de datos construida para responder rápidamente "¿qué vectores almacenados están más cerca de este?", incluso a través de millones de entradas. Para un proyecto pequeño el almacén de vectores puede ser una estructura simple en memoria; a escala es una base de datos dedicada. La interfaz es la misma en ambos casos: mete vectores, pide los vecinos más cercanos.

Etapa 3: Recuperación en el momento de la consulta

Ahora el pipeline funciona en vivo. Un usuario hace una pregunta. Incrustas la pregunta con el mismo modelo que usaste para los fragmentos —esto importa, porque los vectores de modelos distintos no son comparables—. Entregas ese vector de pregunta al almacén de vectores y pides los fragmentos más cercanos. El almacén devuelve el puñado superior: los pasajes cuyo significado está más cerca de la pregunta.

"Cuántos" es una decisión real. Devuelve demasiado pocos y arriesgas perder el pasaje que contiene la respuesta. Devuelve demasiados y atiborras el prompt con texto marginalmente relacionado, lo que cuesta más y distrae al modelo. Un número pequeño —suficiente para cubrir la respuesta, no tantos como para que la señal se ahogue en ruido— es el punto de partida habitual. La recuperación es también donde la búsqueda puramente semántica a veces tropieza con términos exactos como códigos de producto o nombres, por lo que algunos pipelines la combinan con la búsqueda por palabras clave de toda la vida. Empieza simple; añade eso solo si ves el fallo.

Etapa 4: Ensamblar el prompt

Ahora tienes la pregunta del usuario y unos cuantos fragmentos recuperados. El paso de generación los ensambla en un único prompt. Conceptualmente se ve así:

You are answering using only the context below.
If the answer is not in the context, say you don't know.

Context:
[chunk 1 text]
[chunk 2 text]
[chunk 3 text]

Question: [the user's question]

Dos instrucciones ahí dentro hacen un trabajo silencioso y pesado. "Using only the context below" le dice al modelo que prefiera los pasajes suministrados sobre su propia memoria, que es el sentido entero de RAG. "If the answer is not in the context, say you don't know" le da al modelo permiso para abstenerse: sin ello, un modelo tiende a llenar el vacío con una conjetura segura. Nombrar ese modo de fallo es la diferencia entre un honesto "no encontrado" y una invención.

Etapa 5: Generación y citado de fuentes

El prompt ensamblado va al modelo de lenguaje, que escribe la respuesta anclada en el texto recuperado. Como conservaste la fuente original de cada fragmento, puedes hacer algo que el ajuste fino no puede: mostrar de dónde vino la respuesta. Lleva un identificador con cada fragmento —título del documento, sección, página— y pide al modelo que lo referencie, o simplemente muestra los pasajes fuente debajo de la respuesta. Las citas convierten una respuesta opaca en una que el usuario puede verificar, y la verificabilidad es a menudo lo que hace a un sistema RAG lo bastante fiable para desplegarse.

Aquí también se pone a prueba la honestidad del pipeline. Si la recuperación entregó los pasajes equivocados, el modelo responderá con fluidez a partir de los pasajes equivocados. Una respuesta segura no es evidencia de una respuesta correcta. Lo que lleva directamente a la parte que la mayoría de las primeras construcciones se salta.

Dónde se rompen realmente los pipelines RAG

Los fallos rara vez están en el modelo. Están aguas arriba, en la recuperación. Si el fragmento relevante nunca se devolvió, el mejor modelo del mundo no puede usarlo: "basura entra, basura fluida sale". Los culpables habituales: fragmentos divididos de modo que la respuesta queda a caballo de un límite y no aparece entera en ninguno; un modelo de embeddings que no capta el vocabulario de tu dominio; o simplemente pedir demasiados pocos fragmentos. Cuando un sistema RAG da una respuesta errónea, resiste la tentación de culpar primero al modelo. Mira qué devolvió realmente la recuperación para esa pregunta. La mayoría de las veces la respuesta no estaba en el conjunto recuperado en absoluto, y el arreglo está en el troceado o la recuperación, no en el prompt.

La manera de detectar esto es evaluar el pipeline con preguntas reales cuyas respuestas ya conoces, e inspeccionar los fragmentos recuperados, no solo el texto final. Un pipeline que recupera el pasaje correcto y luego responde bien está funcionando. Uno que responde bien por suerte mientras recupera el pasaje equivocado es un fallo esperando una pregunta más difícil.

En resumen

RAG no es un truco, sino una corta cadena de montaje: trocea tus documentos con sensatez, incrústalos en un almacén de vectores, recupera los fragmentos más cercanos para cada pregunta, ensámblalos en un prompt anclado y genera una respuesta que cite sus fuentes. El modelo es la parte fácil. La calidad del sistema entero la deciden el troceado y la recuperación: poner la página correcta delante del modelo en el momento correcto. Construye cada etapa con sencillez, luego mide la recuperación con preguntas reales, y dedicarás tu esfuerzo donde realmente viven los fallos en lugar de donde parecen más impresionantes.