Arquitectura RAG: ingesta, recuperación, generación y reranking

La arquitectura RAG describe la estructura técnica de un sistema de Retrieval-Augmented Generation en dos fases claramente separadas. La primera fase, la ingesta (también llamada indexación), se ejecuta offline y convierte los documentos fuente en un índice consultable. La segunda fase, el tiempo de consulta (query time), se ejecuta online con cada petición: recupera los contenidos adecuados, los reordena y se los entrega a un modelo de lenguaje para que genere la respuesta. Si quieres operar RAG en producción, tienes que entender y gestionar ambas rutas por separado.

• Dos rutas, no una: la ingesta (loading, chunking, embedding, upsert) se ejecuta por lotes; la ruta de consulta (embedding, retrieval, filtrado, reranking, generación) se ejecuta con cada petición.
• El reranking es obligatorio, no opcional: un cross-encoder después de la búsqueda preliminar reduce de forma medible la tasa de error de recuperación (hasta un 67 % combinado con Contextual Retrieval, datos de septiembre de 2024).
• Los metadatos deciden el cumplimiento normativo: tenant_id, ACL y la referencia a la fuente en cada chunk son la base técnica del multi-tenancy, la separación de datos por cliente y la capacidad de borrado.

Fase 1: ingesta / indexación (offline)

La ruta de ingesta es el trabajo previo que condiciona de antemano la calidad y la latencia de la operación posterior. Consta de cuatro o cinco pasos:

1. Loading / conectores. Fuentes como SharePoint, S3, Confluence o una base de datos se integran mediante conectores. Ya en este punto se registran para cada documento identificadores estables y metadatos (fuente, marca de tiempo, cliente, permisos de acceso).

2. Parsing. Los documentos en bruto, sobre todo PDF y contratos, se convierten en texto estructurado. Los parsers que respetan el layout conservan la estructura de tablas, listas y encabezados, lo que evita alucinaciones más adelante. Algunas herramientas para ello son Docling (IBM, open source), Unstructured.io, LlamaParse o Azure Document Intelligence.

3. Chunking. El texto se divide en unidades recuperables. El chunking ingenuo de tamaño fijo (p. ej., 512 tokens, overlap de 50) es sencillo, pero corta frases y tablas. Son mejores el chunking recursivo/semántico (corte cuando la similitud coseno entre frases deriva) o el chunking jerárquico parent-child (chunks pequeños para el retrieval, chunks parent grandes como contexto). Regla general: de 200 a 800 tokens, con un overlap del 10 al 20 %.

4. Embedding. Un modelo de embedding convierte cada chunk en un vector. En corpus en alemán dominan los modelos multilingües como Cohere Embed v4, los modelos de Voyage, Gemini Embedding 2 o BGE-M3. Para una operación soberana sirven sobre todo modelos open-weight como BGE-M3 o los Jina Embeddings, on-premise o en un proveedor de hosting europeo. Eso sí, Jina AI pertenece a Elastic desde octubre de 2025, y antes de un uso comercial tienes que revisar la licencia de cada versión del modelo. Mistral Embed procede del proveedor parisino Mistral AI. Aleph Alpha, de Heidelberg, se está fusionando con el proveedor canadiense Cohere. Cuando se firmó el contrato, en septiembre de 2026, todavía estaba pendiente la autorización de las autoridades. Importante: según el tokenizer, el alemán consume entre 1,3 y 1,7 veces más tokens que el inglés.

5. Indexación / upsert. Los vectores se escriben junto con sus metadatos en una base de datos vectorial. El algoritmo de indexación estándar es casi siempre HNSW (Malkov & Yashunin 2016), con los parámetros M, ef_construction y ef_search, que equilibran recall y velocidad. Opcionalmente, se construye en paralelo un índice BM25 para la búsqueda híbrida y se antepone a cada chunk una cabecera de contexto generada por un LLM (Contextual Retrieval).

Fase 2: tiempo de consulta (online)

La ruta de consulta se ejecuta con cada petición de usuario. El embedding de la consulta, el retrieval, el filtrado y el reranking necesitan en conjunto, como valor orientativo, entre unos 100 y 800 milisegundos, según el tamaño del índice y el reranker. Un preprocesamiento opcional basado en LLM, como HyDE o un reescritor de consultas, cuesta una llamada adicional al modelo. La generación final del LLM suele tardar entre uno y varios segundos, según la longitud de la respuesta. Los pasos en detalle:

1. Preprocesamiento de la consulta (opcional). Un query rewriter, HyDE o un decomposer reformulan las preguntas complejas o las descomponen. En sistemas multi-tenant, aquí se realizan además la autenticación y la autorización (AuthN/Z) y la resolución del tenant.

2. Embedding de la consulta. La pregunta se convierte en un vector con el mismo modelo de embedding que los chunks. En paralelo se genera una consulta BM25.

3. Retrieval / búsqueda vectorial. La base de datos vectorial devuelve los chunks más similares (normalmente top_k = 50 a 100). En la búsqueda híbrida, la búsqueda densa y la dispersa se ejecutan en paralelo y se combinan mediante rank fusion (Reciprocal Rank Fusion).

4. Filtrado. Los filtros de metadatos (tenant_id, ACL, fecha) acotan los candidatos. Esto también afecta al cumplimiento normativo: la guía orientativa de la DSK sobre sistemas de IA generativa con método RAG (octubre de 2025) menciona la separación de datos por cliente y un concepto de permisos y roles como medidas para garantizar la confidencialidad y la limitación de la finalidad.

5. Reranking. Un cross-encoder (Cohere Rerank, BGE-Reranker, Jina Reranker) evalúa la consulta y el documento de forma conjunta y reduce los 50 a 100 candidatos a los top_k = 5 a 10 más relevantes. Los cross-encoders son más precisos, pero más lentos que los bi-encoders de la búsqueda preliminar; por eso se ejecutan solo después del recall, que es más barato.

6. Ensamblaje del contexto & prompting. Los chunks finales se insertan con sus referencias de fuente en una plantilla de prompt. Los pasajes importantes van al principio para evitar el problema de lost in the middle.

7. Generación con el LLM. El modelo de lenguaje genera la respuesta, idealmente con citation forcing (citas de fuentes obligatorias) y un guardrail de faithfulness posterior que comprueba si la respuesta está respaldada por las fuentes.

Tabla: pipeline RAG por fase, tarea y herramientas

El flujo de datos descrito en palabras

Un documento recorre offline el loader, el parser y el chunker, el modelo de embedding lo vectoriza y acaba, junto con sus metadatos, como registro en la base de datos vectorial. Cuando llega online una pregunta, se convierte en embedding con el mismo modelo, se compara a través del índice HNSW con todos los vectores de los chunks y se obtiene una preselección. Los filtros de metadatos eliminan lo que el usuario no debe ver. El reranker condensa la preselección en los mejores resultados. Estos se montan en el prompt con sus referencias de fuente, el LLM genera a partir de ellos la respuesta y un guardrail comprueba la fidelidad a la fuente. Lo decisivo: el embedding de la ingesta y el de la consulta tienen que usar el mismo modelo; de lo contrario, los vectores no son comparables.

Ejemplo concreto con cifras

Un bot de soporte para un producto SaaS indexa 50.000 documentos. Con un chunking semántico de unos 500 tokens por chunk, se generan alrededor de 300.000 vectores. Según Anthropic, la indexación con Contextual Retrieval cuesta aproximadamente 1,02 dólares estadounidenses por 1 millón de tokens de documento con prompt caching (datos de septiembre de 2024). En producción, cada consulta recupera top_k = 50 candidatos; el reranker de Cohere los reduce a top_k = 5.

La evaluación de Anthropic muestra el efecto de cada componente sobre la tasa de error de recuperación en el top 20: sin optimización, se situaba en el 5,7 %. Solo con Contextual Embeddings bajó al 3,7 % (un 35 % menos); con Contextual Retrieval completo (embeddings más Contextual BM25), al 2,9 % (un 49 % menos), y con reranking adicional, al 1,9 % (un 67 % menos). En cuanto a latencia, una consulta de retrieval híbrido con reranking se sitúa en torno a 100 a 800 milisegundos.

Pseudocódigo de la ruta de consulta:

```
q_vec = embed(query) # mismo modelo que en la ingesta
dense = vdb.search(q_vec, top_k=50, filter={tenant_id})
sparse = bm25.search(query, top_k=50, filter={tenant_id})
cands = rrf_fuse(dense, sparse) # búsqueda híbrida
top5 = rerank(query, cands)[:5] # Cross-Encoder
prompt = template(query, top5, cite=True)
answer = llm.generate(prompt)
assert faithfulness(answer, top5) > 0.8 # Guardrail
```

Errores de arquitectura frecuentes

• El chunking ingenuo de tamaño fijo ignora los límites de las frases y las tablas, lo que provoca contenidos incompletos y alucinaciones.
• Un modelo de embedding inadecuado para el idioma (embeddings en inglés para un corpus en alemán) destruye el recall en las consultas en alemán.
• Sin reranking: los resultados son semánticamente similares, pero no relevantes.
• Lost-in-the-chunks: sin una cabecera de contexto, un chunk como «Aumentó un 12 %» no sabe de qué trata.
• Semántica pura sin BM25: no se encuentran códigos ni identificadores exactos.
• Sin filtros de metadatos: no hay protección multi-tenant ni por ACL; un chunk del cliente A puede recuperarse para el cliente B.
• Un top_k excesivo para el LLM: lost in the middle y costes más altos.
• Sin evaluación ni citas de las fuentes: regresión silenciosa de la calidad y riesgo de incumplimiento normativo.
• Deriva de embeddings al cambiar de modelo: sin una cadena de versión y una reindexación completa, los vectores antiguos y los nuevos son incompatibles.

Para agencias y B2B

Una arquitectura RAG bien hecha es un pipeline con ingesta, retrieval híbrido, reranking, evaluación y un concepto de borrado. Para las agencias, el valor está en la estrategia de datos, el chunking y la separación de datos por cliente. Para los responsables de decisiones B2B en Europa cuenta además la soberanía: Qdrant, Weaviate, Haystack y el hosting en la UE son una buena base para una operación conforme al RGPD. Blck Alpaca diseña y opera este tipo de pipelines de principio a fin, incluida la evaluación con RAGAS y un pipeline de borrado conforme a la guía orientativa de la DSK. Habla con nosotros si quieres que un piloto de IA se convierta en un sistema de conocimiento en producción y verificable.