Anatomía de un pipeline RAG: los seis componentes

Segunda entrega de la serie. En la primera vimos qué problema resuelve RAG. Ahora abrimos la caja: seis componentes, seis decisiones y seis formas distintas de que el sistema devuelva una respuesta mala sin que nadie se entere.

Un pipeline con dos tiempos

Un sistema RAG —recuperación aumentada por generación— no es un programa que se ejecute de principio a fin cada vez que alguien pregunta. Son dos procesos con ritmos distintos que comparten una base de datos.

El primero es la indexación, y ocurre fuera de línea: cuando entra un documento nuevo o cambia uno existente. Recoge material, lo convierte en texto, lo trocea, lo vectoriza y lo guarda. Puede tardar minutos u horas y a nadie le importa, porque no hay un usuario esperando.

El segundo es la consulta, y ocurre en línea, con un usuario mirando la pantalla. Convierte la pregunta en vector, busca, selecciona, monta un prompt y llama al modelo generador. Aquí cada milisegundo se nota y el presupuesto total suele estar entre uno y cuatro segundos antes de que el usuario perciba lentitud.

Los seis componentes se reparten entre los dos tiempos. Los tres primeros —ingesta, embeddings y base vectorial— trabajan sobre todo en indexación. Los tres últimos —recuperación, aumento del prompt y generación— trabajan en consulta. El componente de embeddings es el único que aparece en ambos, y esa doble vida tiene consecuencias que veremos.

1. Ingesta: de fuentes heterogéneas a texto troceado

La ingesta recoge los documentos allí donde vivan —un bucket de S3, un gestor documental, una base de datos relacional, una web, un buzón de correo— y los convierte en texto plano limpio. Después lo trocea en fragmentos (chunks) del tamaño que el resto del sistema puede manejar.

Qué decide. Qué se extrae y qué se descarga por el sumidero. Un PDF maquetado a dos columnas puede leerse como dos columnas o como un galimatías que alterna líneas de ambas. Una tabla puede convertirse en texto tabulado legible o en una sopa de cifras sin cabeceras. Un HTML puede conservar la estructura de encabezados o llegar como un bloque plano donde se ha perdido de qué sección era cada párrafo.

Parámetros que expone. El extractor por formato, las reglas de normalización (espacios, guiones de corte de línea, caracteres de control), el tratamiento de tablas e imágenes, si se aplica OCR y con qué umbral, y sobre todo la estrategia de troceado: tamaño del fragmento, solapamiento entre fragmentos consecutivos y criterio de corte (por caracteres, por tokens, por párrafo, por encabezado).

Dónde se rompe. En el troceado que parte una idea por la mitad. Un fragmento que termina en «los plazos de devolución son los siguientes:» y otro que empieza con la lista, sin nada que los una, produce dos fragmentos individualmente inútiles. También se rompe en silencio: un extractor de PDF que devuelve cadena vacía para los documentos escaneados no lanza ningún error, simplemente indexa cero contenido y nadie lo nota hasta que un usuario pregunta por ese documento.

2. Embeddings: del texto a coordenadas

Un modelo de embeddings convierte cada fragmento en un vector: una lista de números, habitualmente entre 384 y 3.072, que representa su significado en un espacio geométrico. Textos que significan cosas parecidas quedan cerca; textos que significan cosas distintas quedan lejos.

Qué decide. Qué se considera «parecido». Es la decisión más determinante de todo el pipeline, porque toda la recuperación posterior se apoya en ella. Un modelo entrenado sobre todo en inglés puede colocar cerca dos frases en español por razones equivocadas. Un modelo de dominio general puede no distinguir dos conceptos que en tu sector son opuestos.

Parámetros que expone. El modelo elegido, su dimensionalidad, su ventana máxima de entrada, si normaliza los vectores, y si admite prefijos de instrucción distintos para documentos y para consultas —varios modelos abiertos lo exigen y funcionan bastante peor si se ignora.

Dónde se rompe. En la asimetría. Si indexas con un modelo y consultas con otro, o con la misma familia pero distinta versión, los vectores viven en espacios diferentes y la búsqueda devuelve resultados aleatorios sin fallar. Es un error que no produce excepción, sólo respuestas malas. También se rompe cuando el fragmento supera la ventana del modelo: lo que sobra se trunca en silencio, y ese final truncado puede ser justamente la parte que contenía la respuesta.

3. Base vectorial: almacenar y buscar por proximidad

La base vectorial guarda los vectores junto con su texto y sus metadatos, y ofrece una operación central: dado un vector de consulta, devolver los k más cercanos. Para que eso sea rápido con millones de vectores construye un índice aproximado.

Qué decide. El compromiso entre exactitud, velocidad y memoria. Un índice aproximado no garantiza devolver los vecinos verdaderos, sólo unos muy probables. Cuánto se aparta de la verdad es un parámetro que tú fijas, a veces sin saberlo, aceptando los valores por defecto.

Parámetros que expone. Tipo de índice y su configuración, métrica de distancia, esquema de metadatos indexables, estrategia de filtrado (antes, durante o después de la búsqueda) y política de cuantización si se comprime.

Dónde se rompe. En el filtrado posterior. Si el motor busca los 10 vecinos más cercanos y después descarta los que no cumplen el filtro de departamento o de fecha, puedes acabar con dos resultados cuando pediste diez, o con ninguno. También se rompe con la escala: configuraciones que funcionan con 50.000 vectores degradan su exactitud a los cinco millones sin que ninguna alarma se dispare.

4. Recuperación: elegir qué merece entrar

La recuperación es la lógica que rodea a la consulta bruta: qué se busca, cómo, y qué se hace con los candidatos. Puede ser una simple búsqueda vectorial, o combinar búsqueda densa con búsqueda por palabras clave, reescribir la pregunta antes de buscar, lanzar varias variantes y fusionar resultados, o reordenar los candidatos con un modelo más caro y más preciso.

Qué decide. Qué fragmentos ve el modelo generador. Aquí es donde se juega el partido: la calidad de la recuperación pone el techo a la calidad del sistema. Ningún prompt ni ningún modelo posterior arregla un fragmento que no se recuperó.

Parámetros que expone. El valor de k, el umbral mínimo de similitud, los pesos entre señal densa y señal léxica, el tamaño del conjunto de candidatos que pasa al reordenador y los filtros por metadatos.

Dónde se rompe. Con vocabulario que el modelo de embeddings no entiende: referencias de producto, códigos internos, nombres propios poco frecuentes. La búsqueda semántica es notablemente mala con identificadores exactos, y ese es el motivo por el que la búsqueda híbrida existe. También falla cuando la respuesta requiere sintetizar veinte documentos: recuperar cinco fragmentos no sirve para una pregunta cuya respuesta está repartida.

5. Aumento del prompt: montar el contexto

Con los fragmentos elegidos se construye el prompt final: instrucciones de sistema, fragmentos con sus identificadores de fuente, historial de conversación si lo hay y la pregunta del usuario.

Qué decide. Cuánta libertad tiene el modelo. La instrucción de fidelidad —«responde exclusivamente con la información de estos fragmentos; si no está, dilo»— es la que convierte un generador en un lector. Sin ella, el modelo mezcla lo recuperado con lo que recuerda de su entrenamiento y ya no hay forma de saber de dónde viene cada frase.

Parámetros que expone. La plantilla, el presupuesto de tokens, el orden de los fragmentos, la deduplicación, el formato de las citas y qué hacer cuando no se ha recuperado nada relevante.

Dónde se rompe. En el truncado por longitud, cuando el fragmento que se cae del presupuesto es el bueno. Y en el efecto «perdido en el medio»: un dato colocado en el centro de un contexto largo se recupera peor que el mismo dato al principio o al final.

6. Generación: redactar sobre lo dado

El modelo de lenguaje recibe el prompt y produce la respuesta. Es el componente más visible y, sorprendentemente, el que menos margen de mejora suele ofrecer.

Qué decide. La calidad de la redacción y, sobre todo, el grado de obediencia a la instrucción de fidelidad. Los modelos difieren mucho en su disposición a decir «esto no está en el contexto» en lugar de rellenar el hueco.

Parámetros que expone. Modelo, temperatura, límite de tokens de salida, formato de respuesta y si se fuerza salida estructurada.

Dónde se rompe. Ignorando el contexto cuando contradice lo que el modelo cree saber. Y contestando con seguridad a partir de un fragmento que trata de otra cosa: si la recuperación falló, el generador rara vez lo detecta.

Tabla de referencia

Lo que esta anatomía no te dice

Dividir el sistema en seis piezas ayuda a diagnosticar, pero induce a un error: creer que los fallos son locales. No lo son. Un tamaño de fragmento demasiado grande no rompe la ingesta, rompe los embeddings —porque un vector que representa cuatro ideas no representa bien ninguna— y luego rompe la recuperación. Un cambio en el modelo de embeddings obliga a reindexar todo el corpus, algo que no aparece en ningún diagrama.

La consecuencia práctica es que evaluar el sistema sólo por su respuesta final es engañarse. Cuando una respuesta es mala hay que poder distinguir si el fragmento correcto no se recuperó, si se recuperó y no entró en el prompt, o si entró y el modelo lo ignoró. Son tres averías distintas con tres arreglos distintos, y confundirlas lleva a semanas de ajustar el prompt cuando el problema estaba en el troceado.

Qué viene ahora

La siguiente entrega baja al segundo componente y se queda ahí: qué es exactamente un vector de significado, cómo se mide la proximidad entre dos textos, por qué dos frases sin palabras en común pueden quedar juntas y por qué a veces quedan juntas cosas que deberían estar en extremos opuestos, como una afirmación y su negación.

Si prefieres leerlo todo de golpe y en orden, los tres libros gratuitos de los que nace esta serie están disponibles en PDF y EPUB: RAG para tu negocio (nivel básico), RAG por dentro (intermedio) y RAG en producción (avanzado).

Aviso de contenido generado con inteligencia artificial.
Este artículo ha sido redactado con la asistencia de sistemas de inteligencia artificial y revisado antes de su publicación. Se informa de ello de forma expresa en cumplimiento de la normativa vigente sobre transparencia en el uso de IA.