Arquitectura de pipeline RAG: indexación y recuperación como responsabilidades separadas

El tutorial típico de RAG comienza y termina en el mismo script: cargar documentos, fragmentarlos, incrustarlos, almacenarlos en una base de datos vectorial, y luego consultar esa base de datos en tiempo de inferencia. Todo se ejecuta en un solo proceso. Funciona para una demostración. No funciona para producción.

Los sistemas RAG de producción sirven a usuarios reales contra datos reales que cambian constantemente. Los documentos se agregan, actualizan y eliminan. Los modelos de incrustación se actualizan. Las estrategias de fragmentación se refinan. Mientras tanto, la ruta de recuperación necesita mantenerse rápida, estable y observable — incluso mientras se reconstruye el índice. Cuando la indexación y la recuperación están entrelazadas, cambiar una rompe la otra.

La mejor arquitectura RAG para producción trata la indexación y la recuperación como dos pipelines separados que comparten solo una cosa: el almacén de vectores.

Por qué el script RAG monolítico falla

En una implementación RAG de script único, la misma base de código maneja la ingestión de documentos, la fragmentación, la incrustación, el almacenamiento, el procesamiento de consultas, la búsqueda vectorial, el ensamblaje de contexto y la generación de respuestas. Esto crea varios modos de fallo que solo aparecen a escala.

La reindexación bloquea la recuperación. Cuando necesita reprocesar su corpus de documentos — porque cambió su estrategia de fragmentación, actualizó su modelo de incrustación o recibió un lote de documentos nuevos — la ruta de recuperación está bloqueada u operando contra un índice parcialmente actualizado. Los usuarios experimentan resultados degradados o tiempo de inactividad total.

Sin escalado independiente. La indexación es una carga de trabajo por lotes. Es intensiva en CPU durante el análisis y la limpieza, intensiva en GPU durante la incrustación e intensiva en E/S durante las escrituras vectoriales. La recuperación es una carga de trabajo en línea sensible a la latencia. Necesita incrustación rápida de consultas cortas y búsqueda rápida de vecinos más cercanos aproximados. Estas cargas de trabajo tienen perfiles de recursos fundamentalmente diferentes. Ejecutarlas en el mismo proceso significa que ninguna está optimizada.

La depuración se convierte en arqueología. Cuando la calidad de la recuperación disminuye, necesita determinar si el problema está en cómo se analizaron los documentos, cómo se fragmentaron, cómo se incrustaron o cómo se construye la consulta de recuperación. En un pipeline monolítico, estas responsabilidades están entrelazadas en la misma base de código. Rastrear un problema de calidad hasta su causa raíz requiere leer todo el sistema.

La gestión de versiones es imposible. Quiere hacer pruebas A/B de una nueva estrategia de fragmentación contra la actual. O quiere revertir un cambio de modelo de incrustación que degradó los resultados. En un sistema monolítico, estas operaciones requieren reprocesar todo el corpus y redesplegar toda la aplicación.

La arquitectura de dos pipelines

Separar RAG en un pipeline de indexación y un pipeline de recuperación crea límites claros con un contrato bien definido entre ellos.

El pipeline de indexación (por lotes)

El pipeline de indexación procesa documentos en representaciones vectoriales. Se ejecuta según un calendario o en respuesta a disparadores — nuevos documentos que llegan, una actualización de modelo o una solicitud manual de reindexación. Sus etapas son:

1. Importación de archivos — Ingestar documentos desde sistemas fuente (sistema de archivos, S3, SharePoint, exportaciones de bases de datos). Manejar la detección de formato y la deduplicación.
2. Analizador — Extraer texto de formatos estructurados y no estructurados (PDF, DOCX, HTML, Markdown, CSV). Preservar los metadatos del documento y la información estructural.
3. Limpieza — Normalizar texto, eliminar encabezados y pies de página repetitivos, manejar problemas de codificación, eliminar marcado irrelevante. Esta etapa tiene un impacto desproporcionado en la calidad de la recuperación y a menudo se invierte poco en ella.
4. Fragmentador RAG — Dividir el texto limpio en unidades de recuperación. Aquí es donde vive la estrategia de fragmentación — tamaño fijo con superposición, fragmentación semántica o fragmentación consciente de la estructura del documento. El fragmentador es el componente que se itera con más frecuencia en un sistema RAG maduro.
5. Incrustación — Convertir los fragmentos en representaciones vectoriales usando el modelo de incrustación. Esta es la etapa más intensiva en cómputo y se beneficia del procesamiento por lotes y la aceleración por GPU.
6. Escritor de almacén de vectores — Escribir las incrustaciones y sus metadatos asociados en la base de datos vectorial. Manejar inserciones, eliminaciones y gestión del índice.

Cada etapa es comprobable de forma independiente. Se puede validar la salida del analizador sin ejecutar el incrustador. Se pueden intercambiar estrategias de fragmentación y comparar su salida antes de comprometerse con una reindexación completa. Se puede actualizar el modelo de incrustación y escribir en una nueva colección sin tocar la existente.

El pipeline de recuperación (en vivo)

El pipeline de recuperación maneja consultas en tiempo real. Es un servicio en línea sensible a la latencia. Sus etapas son:

1. Endpoint de API — Aceptar consultas entrantes con autenticación, limitación de tasa y validación de solicitudes.
2. Incrustador de consultas — Convertir la consulta del usuario en un vector usando el mismo modelo de incrustación que se utilizó durante la indexación. Esto debe usar el mismo modelo y configuración — una discrepancia aquí degrada silenciosamente los resultados.
3. Búsqueda vectorial — Realizar búsqueda aproximada de vecinos más cercanos contra el almacén de vectores. Aplicar filtros de metadatos, manejar consultas multicolección si se ejecutan múltiples versiones del índice.
4. Ensamblador de contexto — Tomar los fragmentos recuperados, reordenarlos si es necesario, ensamblarlos en una ventana de contexto coherente y formatearlos para el LLM posterior. Esta etapa gestiona los presupuestos de tokens y la deduplicación.
5. Respuesta de API — Devolver el contexto ensamblado (o una respuesta generada, si se integra un LLM) junto con metadatos de atribución de fuentes.

El pipeline de recuperación tiene características operativas completamente diferentes al pipeline de indexación. Necesita estar siempre disponible, responder en milisegundos y manejar solicitudes concurrentes. No necesita analizar documentos, gestionar estrategias de fragmentación ni manejar trabajos de incrustación por lotes.

El contrato entre pipelines

El almacén de vectores es la interfaz entre los dos pipelines. El contrato es sencillo: el pipeline de indexación escribe vectores con una dimensionalidad conocida, un esquema de metadatos conocido y una convención de nomenclatura de colecciones conocida. El pipeline de recuperación lee de esas colecciones usando el mismo modelo de incrustación.

Este contrato permite el despliegue independiente. Se puede desplegar una nueva versión del pipeline de indexación — con una estrategia de fragmentación diferente o un nuevo modelo de incrustación — sin redesplegar el pipeline de recuperación. Se escribe en una nueva colección, se validan los resultados y luego se apunta el pipeline de recuperación a la nueva colección. La reversión consiste en apuntarlo de nuevo a la anterior.

Cómo se ve esto en la práctica

En Ertas Data Suite, ambos pipelines se construyen como grafos visuales de nodos en el mismo lienzo. El pipeline de indexación es una cadena de nodos: Importación de archivos, Analizador, Limpieza, Fragmentador RAG, Incrustación, Escritor de almacén de vectores. El pipeline de recuperación es una cadena separada: Endpoint de API, Incrustador de consultas, Búsqueda vectorial, Ensamblador de contexto, Respuesta de API. Se ubican uno al lado del otro en el lienzo, visualmente distintos pero compartiendo la conexión del almacén de vectores.

Esta separación visual hace que la arquitectura sea tangible. Se puede ver que los dos pipelines son independientes. Se puede modificar el nodo de fragmentación en el pipeline de indexación sin tocar el pipeline de recuperación. Se puede agregar un nodo de reordenamiento al pipeline de recuperación sin activar una reindexación. Cada pipeline se ejecuta según su propio calendario — el pipeline de indexación como un trabajo por lotes, el pipeline de recuperación como un servicio persistente.

Dado que Ertas se ejecuta en las instalaciones del cliente como una aplicación de escritorio, toda la arquitectura permanece dentro de su infraestructura. El almacén de vectores es local. Los modelos de incrustación se ejecutan localmente. Ningún contenido de documento ni datos de consulta salen de la máquina. Para empresas con requisitos de soberanía de datos, esto elimina la sobrecarga de cumplimiento de evaluar servicios RAG en la nube.

Beneficios operativos de la separación

Observabilidad independiente. Cada pipeline obtiene sus propias métricas. Indexación: documentos procesados por hora, estadísticas de distribución de fragmentos, rendimiento de incrustación, latencia de escritura. Recuperación: latencia de consulta en p50/p95/p99, puntuaciones de relevancia, tasas de aciertos de caché, conteo de consultas concurrentes. Cuando la calidad de la recuperación se degrada, se verifican primero las métricas de recuperación. Si la recuperación está sana, el problema está en el índice — y se verifican las métricas de indexación para encontrar la causa raíz.

Iteración independiente. La estrategia de fragmentación es el componente que se cambia con más frecuencia en un sistema RAG de producción. Con pipelines separados, se puede ejecutar una nueva configuración de fragmentación a través del pipeline de indexación, escribir los resultados en una colección de prueba y evaluar la calidad de recuperación contra esa colección — todo sin afectar la ruta de recuperación en producción.

Dominios de fallo independientes. Si el pipeline de indexación falla durante un trabajo por lotes, la recuperación sigue sirviendo desde el índice existente. Si el pipeline de recuperación tiene un pico de latencia, la indexación sigue procesando documentos. Ningún fallo se propaga al otro.

Límites claros de equipo. En organizaciones más grandes, el equipo responsable de la ingestión y calidad de datos (a menudo ingeniería de datos) puede ser dueño del pipeline de indexación, mientras que el equipo responsable de la aplicación orientada al usuario puede ser dueño del pipeline de recuperación. El contrato del almacén de vectores es la API entre los dos equipos.

Cuándo comenzar a separar

Si su sistema RAG es un prototipo o herramienta interna con un corpus pequeño y estático y un solo usuario, el enfoque monolítico está bien. La separación agrega sobrecarga arquitectónica que no se justifica a esa escala.

Separe cuando aparezca cualquiera de estas condiciones: su corpus se actualiza regularmente, necesita iterar sobre fragmentación o incrustación sin tiempo de inactividad, múltiples personas o equipos están trabajando en el sistema, o la confiabilidad de la recuperación es un requisito empresarial en lugar de una conveniencia.

Para la mayoría de los despliegues RAG empresariales, estas condiciones están presentes desde el primer día. Comenzar con pipelines separados evita la dolorosa migración desde un sistema monolítico más adelante — una migración que normalmente requiere reprocesar todo el corpus y rediseñar la arquitectura de la aplicación bajo presión de producción.

La mejor arquitectura de pipeline RAG no es la que tiene el algoritmo de recuperación más sofisticado. Es aquella donde se puede cambiar cualquier componente — analizador, fragmentador, incrustador, estrategia de recuperación — sin romper todo lo demás.