Arquitectura de referencia de un RAG en producción
Indexación offline y consulta online, colas, reintentos y el flujo completo de una pregunta de principio a fin.
Empieza el séptimo y último bloque de la serie, dedicado a lo que ocurre cuando el prototipo deja de ser un cuaderno y pasa a atender tráfico real. Antes de hablar de coste, seguridad u observabilidad conviene fijar el plano: qué piezas hay, cuáles viven en la ruta de indexación y cuáles en la de consulta, y por qué confundirlas es el error de diseño más caro de todos.
Dos sistemas que comparten un almacén
Un RAG en producción no es un sistema, son dos. Uno recoge documentos, los procesa y llena el índice. El otro recibe preguntas y devuelve respuestas. Comparten el almacén vectorial y poco más: tienen requisitos distintos, perfiles de carga distintos, modos de fallo distintos y —esto es lo importante— deben poder desplegarse y escalarse por separado.
La ruta de indexación es offline. Trabaja por lotes, tolera latencias de minutos u horas, se ejecuta a ráfagas y su métrica de éxito es que todo documento acabe indexado exactamente una vez, con su versión correcta. Si tarda cuarenta minutos en absorber un lote de tres mil PDF, no pasa nada, siempre que termine y que nadie se quede con dos copias del mismo documento en el índice.
La ruta de consulta es online. Trabaja petición a petición, tiene un presupuesto de latencia medido en cientos de milisegundos o pocos segundos, y su métrica de éxito es que el percentil 95 se mantenga dentro de ese presupuesto sin que la calidad se hunda.
El error clásico consiste en meter trabajo de indexación en la ruta de consulta: extraer texto de un PDF, generar un resumen con un modelo o recalcular embeddings mientras el usuario espera. Todo lo que se pueda calcular antes, se calcula antes. La ruta de consulta sólo debería hacer lo que depende de la pregunta concreta.
El plano de componentes
Una arquitectura de referencia mínima pero completa tiene estas piezas. Ninguna es opcional en producción, aunque varias pueden empezar siendo un proceso pequeño dentro de otro.
RUTA DE INDEXACIÓN (offline, por lotes)
[Fuentes] -> [Conectores] -> [Cola de trabajos]
(S3, CMS, extracción reintentos
Drive, DB, normalización backoff
scraping) detección de clave de
cambios idempotencia
|
v
[Trabajadores de ingesta]
troceado -> metadatos ->
embeddings (por lotes)
|
+---------------------+---------------------+
v v
[Almacén vectorial] [Almacén de documentos]
vectores + metadatos texto completo, versiones,
índice ANN procedencia, permisos
RUTA DE CONSULTA (online, con presupuesto de latencia)
[Cliente] -> [API/Gateway] -> [Orquestador] -> [Recuperación] -> [Reranking]
autenticación transformar híbrida + cross-encoder
cuotas la consulta filtro de top-k final
validación caché exacta permisos
caché semántica |
v
[Montaje del prompt]
|
v
[Modelo generador]
streaming al cliente
|
v
[Traza y métricas]
Atraviesa todo: [Observabilidad] (trazas, métricas, costes, alertas)
Qué hace cada pieza
- Conectores. Uno por tipo de fuente. Su responsabilidad no es sólo leer: es detectar qué ha cambiado desde la última pasada. Un conector que reindexa el corpus entero cada noche funciona con diez mil documentos y se vuelve inviable con un millón.
- Cola de trabajos. El desacople entre «he detectado un documento nuevo» y «lo he indexado». Sin ella, un pico de ingesta tumba el servicio de embeddings y no hay forma limpia de reintentar. Con ella, los fallos transitorios se reintentan solos y los permanentes acaban en una cola de mensajes muertos que alguien revisa.
- Trabajadores de ingesta. Procesos sin estado que consumen de la cola. Escalan horizontalmente y son el sitio natural para agrupar llamadas de embeddings por lotes, que es donde está casi todo el ahorro de esta ruta.
- Almacén vectorial. Vectores, metadatos filtrables e índice ANN. Como vimos en el bloque cuarto, la elección concreta importa menos que el hecho de que soporte filtrado previo eficiente, porque de eso depende el control de acceso.
- Almacén de documentos. La pieza que más se olvida. El vectorial guarda fragmentos; necesitas además el texto completo, la versión, la URL de origen, la fecha, el hash y los permisos. Sirve para citar, para reconstruir contexto padre-hijo, para auditar y para reindexar sin volver a las fuentes.
- Orquestador. El código que decide la secuencia: transformar consulta, buscar, reordenar, montar prompt, generar. Puede ser un framework o doscientas líneas propias; lo que no puede es estar repartido entre el endpoint HTTP y el cliente.
- Cachés. Al menos dos niveles, que la entrega 42 desarrolla en detalle.
- Observabilidad. No es una capa que se añade después: la traza se emite desde el primer día o no se emite nunca.
Idempotencia, o cómo no duplicar el corpus
La propiedad menos glamurosa y más crítica de la ruta de indexación. Un trabajo de ingesta va a ejecutarse dos veces: porque la cola garantiza entrega «al menos una vez», porque un trabajador murió a mitad, porque alguien relanzó el lote. Si al ejecutarse dos veces el índice acaba con dos copias del mismo fragmento, la recuperación devolverá duplicados, el reranking los reordenará y el prompt gastará su presupuesto en repetir lo mismo.
La solución no es complicada, pero hay que decidirla antes: cada fragmento tiene un identificador determinista, derivado del identificador estable del documento en su fuente, de su versión y del índice del fragmento dentro del documento. Escribir en el vectorial se hace siempre como upsert, no como inserción. Reprocesar el mismo documento sobrescribe sus fragmentos en lugar de añadirlos.
Con documentos cuyo troceado cambia entre versiones, el patrón que funciona es borrar por filtro (todos los fragmentos cuyo doc_id sea este) y volver a escribir, dentro de la misma unidad de trabajo. Y conviene guardar el hash del contenido normalizado: si el hash no ha cambiado, el trabajo termina sin gastar ni una llamada de embeddings. En corpus grandes con reindexaciones frecuentes, ese único control ahorra más dinero que cualquier optimización de modelo.
El recorrido de una pregunta, con su reloj
Ahora la ruta de consulta, paso a paso. Los números son órdenes de magnitud para una configuración típica con servicios gestionados y un corpus de tamaño medio; cambian mucho con el despliegue, pero las proporciones entre etapas se mantienen sorprendentemente bien.
| Etapa | Qué ocurre | Orden de magnitud |
|---|---|---|
| 1. Entrada y autenticación | Validar petición, resolver identidad y permisos del usuario | Unidades de ms |
| 2. Cachés | Consulta a caché exacta y, si aplica, semántica | Unidades de ms (acierto: fin del recorrido) |
| 3. Transformación de consulta | Reescritura o resolución de anáforas, si el diseño la incluye | Cientos de ms si usa un modelo; cero si no |
| 4. Embedding de la consulta | Un vector para un texto corto, vía API o local | Decenas de ms |
| 5. Recuperación | Búsqueda densa + léxica con filtro de permisos, fusión de rangos | Decenas de ms |
| 6. Reranking | Cross-encoder sobre los candidatos, recorte al top-k final | Cientos de ms |
| 7. Montaje del prompt | Plantilla, orden de fragmentos, recorte al presupuesto de tokens | Unidades de ms |
| 8. Generación (primer token) | Procesado del contexto hasta emitir el primer token | Cientos de ms a un segundo |
| 9. Generación (resto) | Emisión del cuerpo de la respuesta, en streaming | Segundos, percibidos como progreso |
| 10. Traza | Emisión asíncrona de la traza y las métricas | Fuera de la ruta crítica |
Dos lecturas de esta tabla. La primera: las etapas 4 a 7, que son todo el aparato de recuperación del que ha hablado media serie, suman típicamente menos que el tiempo hasta el primer token del generador. La segunda, consecuencia de la anterior: optimizar la recuperación por latencia es casi siempre optimizar la parte pequeña. El reranking es la excepción, porque es la única etapa de recuperación con coste comparable al del modelo.
El presupuesto se reparte en sentido inverso a la intuición: se fija primero el objetivo global —pongamos, primer token por debajo de un segundo y medio en el percentil 95—, se resta lo que el generador va a consumir, y lo que queda es el presupuesto real de recuperación. Si no cabe el reranking, se recorta el número de candidatos antes de recortar la calidad de la búsqueda.
El streaming cambia la ecuación
Con respuesta en streaming, la métrica que percibe el usuario no es la latencia total sino el tiempo hasta el primer token. Eso da margen para respuestas largas, pero también castiga con dureza cualquier etapa que ocurra antes de empezar a emitir. Un paso de verificación posterior a la generación, del tipo que veíamos en la entrega 19, es incompatible con el streaming tal cual: o se acepta emitir y corregir, o se renuncia al streaming en esos casos.
Límites de este plano
Esta arquitectura es de referencia, no de obligado cumplimiento. Un sistema interno con doscientas consultas al día no necesita cola de trabajos ni trabajadores separados: un cron y un script bastan, y montar lo demás es tiempo tirado. La cola empieza a justificarse cuando la ingesta es continua, cuando las fuentes fallan con regularidad o cuando el volumen hace que un reproceso completo deje de caber en una ventana nocturna.
Hay además dos costes que este diagrama esconde. Uno es operativo: cada caja es algo que hay que desplegar, monitorizar, actualizar y pagar. El otro es de coherencia: con indexación asíncrona, entre que un documento cambia en la fuente y queda disponible en el índice pasa un tiempo. Ese retardo hay que medirlo, publicarlo y, en algunos dominios, exponerlo al usuario. Un sistema que responde con la política de precios de la semana pasada sin decir de cuándo es la información no está siendo trazable, está siendo confuso.
Qué viene ahora
La siguiente entrega coge este mismo recorrido y le pone precio: dónde se va exactamente el dinero en cada consulta —con los tokens de entrada dominando casi siempre la factura—, cómo se calcula un coste por consulta razonable en órdenes de magnitud, y qué hacen realmente las tres cachés que aparecen en el diagrama, incluida la semántica, que es la que más ahorra y la que más fácilmente estropea respuestas.
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.
