Arquitectura RAG: cómo diseñar un sistema RAG en producción
Publicado: · Actualizado:
Por Goiko, Founder & AI Solutions CTO de GUGŌ Creative
Cómo diseñar la arquitectura de un sistema RAG en producción: ingesta, chunking, embeddings, búsqueda híbrida, reranking, citas, evaluación, permisos y costes.
Una arquitectura RAG (Retrieval-Augmented Generation) en producción tiene dos circuitos. El de indexación, en segundo plano, extrae los documentos, los trocea, guarda cada fragmento con sus metadatos y permisos y genera sus embeddings. El de consulta, en tiempo real, busca los fragmentos relevantes con una búsqueda híbrida —semántica y por palabras clave— filtrada por lo que el usuario puede ver, los reordena con un reranker y pide al modelo una respuesta que cite sus fuentes. Alrededor van la evaluación, la observabilidad y el control de costes.
La calidad la decide sobre todo la recuperación, no el modelo de lenguaje: si el fragmento correcto no llega al contexto, ninguna respuesta será buena. Un buen punto de partida es trocear por la estructura del documento, fusionar la búsqueda híbrida con Reciprocal Rank Fusion, reordenar los candidatos, filtrar los permisos en la propia consulta y repetir en cada cambio un banco de preguntas reales. Esta guía es técnica; el servicio de implantación está en sistemas RAG para empresas.
Abajo repasamos cada capa, con una tabla comparativa, cómo evaluar, ejemplos y costes.
Qué es una arquitectura RAG y cuándo hace falta
El término viene del artículo de Lewis et al. (2020), que combinó un modelo generativo con un índice de documentos consultado al responder: la memoria del modelo más una memoria externa que se actualiza sin reentrenar. En una empresa, esa memoria son manuales, contratos, procedimientos o tickets, con tres ventajas: los datos se actualizan reindexando, las respuestas citan el documento y cada usuario recupera solo lo que puede ver.
No siempre hace falta. Anthropic, en su artículo sobre contextual retrieval, sugiere que con menos de unos 200.000 tokens —unas 500 páginas— puede ser más sencillo incluirlo todo en el prompt con caché de prompts. Si lo que quieres es cambiar el tono o el formato, y no darle información al modelo, mira fine-tuning o RAG.
Las dos fases de un sistema RAG en producción
- Indexación (asíncrona): conectores a las fuentes, extracción del texto, limpieza, troceado, metadatos y permisos, embeddings y escritura en el índice. Se ejecuta en la carga inicial y con cada alta, cambio o baja de documento.
- Consulta (en tiempo real): reformulación opcional de la pregunta, búsqueda híbrida con filtro de permisos, reranking, construcción del contexto, generación con citas y registro de la traza.
Cada etapa debe dejar rastro —versión del documento indexado, modelo de embeddings, fragmentos recuperados y su puntuación—; sin esa traza, cuando una respuesta falla no se sabe si el problema está en la fuente, el troceado, la búsqueda o el modelo.
Ingesta y extracción: la capa que más se subestima
Un PDF escaneado, una tabla partida entre dos páginas o un Word con control de cambios producen texto sucio, y el texto sucio se recupera mal. Conviene convertir cada documento a un formato que conserve la estructura, como Markdown, aplicar OCR donde haga falta y descartar duplicados y versiones obsoletas antes de indexar. Para documentos complejos, ver IA para análisis de documentos.
La actualización importa tanto como la carga inicial: hay que detectar altas, cambios y bajas —por ejemplo, con un hash del contenido—, reindexar solo lo que cambia y propagar los cambios de permisos. La documentación de Azure AI Search advierte que un cambio de permisos en el origen solo se refleja cuando se sincroniza con el índice. Ese flujo se detalla en cómo construir un data pipeline para IA.
Chunking y metadatos: cómo trocear los documentos
El troceado (chunking) decide qué unidad de texto se recupera. La guía de chunking de Microsoft recomienda empezar con fragmentos de 512 tokens y un solapamiento inicial del 25 %, y describe también el troceado por estructura, usando los títulos, y el semántico. En documentación técnica y normativa, trocear por secciones suele respetar mejor el sentido, pero se decide midiendo.
El problema clásico es el fragmento sin contexto: «El plazo es de 30 días» no dice de qué producto ni de qué contrato. El remedio sencillo es anteponer a cada fragmento el título del documento y la ruta de secciones. El avanzado es que un modelo redacte una breve descripción del contexto de cada fragmento antes de indexarlo: Anthropic lo llama contextual retrieval y, en sus pruebas, redujo los fallos de recuperación entre los 20 primeros resultados un 49 %, y un 67 % al añadir reranking.
Cada fragmento debería guardar, como mínimo:
- Identificador y versión del documento, sección y página.
- Fecha de vigencia, idioma y responsable del contenido.
- Grupos o usuarios con permiso de lectura, copiados del origen.
- Hash del contenido, para detectar cambios.
Embeddings e índice vectorial
El modelo de embeddings debe funcionar bien en español y en tu dominio, y aceptar el tamaño de fragmento elegido. Según la guía de embeddings de OpenAI, por ejemplo, text-embedding-3-small y text-embedding-3-large admiten hasta 8.192 tokens y devuelven 1.536 y 3.072 dimensiones. Pregunta y documentos se vectorizan con el mismo modelo, así que cambiarlo obliga a reindexarlo todo: guarda siempre el texto original.
Como índice, muchas veces basta pgvector en tu PostgreSQL; la comparación con bases dedicadas está en qué es una base de datos vectorial. Un detalle que afecta a los permisos: según su documentación, con índices aproximados el filtro se aplica después de recorrer el índice, y una consulta muy filtrada puede devolver menos resultados de los pedidos; desde la versión 0.8.0, los escaneos iterativos siguen recorriendo el índice hasta reunir suficientes resultados.
Recuperación: búsqueda híbrida y reranking
La búsqueda vectorial encuentra textos de significado parecido, pero falla con códigos, referencias o nombres propios, justo lo que más se pregunta en una empresa; la búsqueda por palabras clave (BM25) sí los encuentra. Para fusionar ambas listas se usa Reciprocal Rank Fusion (RRF): cada documento suma 1/(k + posición) por cada lista en la que aparece, y según la documentación de Azure AI Search funciona mejor con un k pequeño, como 60. La documentación de pgvector propone combinar su búsqueda con la de texto completo de PostgreSQL.
El reranking es la segunda etapa: un cross-encoder lee juntos la pregunta y cada candidato y los vuelve a puntuar. Es más preciso pero más lento, así que se aplica a pocos candidatos; la documentación de Sentence Transformers pone como ejemplo reordenar unos 100. Al modelo se le pasan después solo los mejores: el estudio Lost in the Middle mostró que los modelos aprovechan peor la información que queda en mitad de un contexto largo.
Generación con citas y respuesta «no lo sé»
El prompt pide responder solo con el contexto, citar el identificador de cada fragmento usado y decir cuándo no hay información suficiente. Conviene una salida estructurada —respuesta y citas— y validar que cada cita corresponde a un fragmento recuperado. Algunas API lo resuelven: las citas de Claude devuelven el pasaje exacto que respalda cada afirmación. Una cita válida permite comprobar la respuesta, no garantiza que sea correcta.
El texto recuperado es contenido no fiable. OWASP describe la inyección indirecta de prompts (LLM01:2025), con instrucciones escondidas en documentos o webs, y entre sus escenarios incluye un documento manipulado en el repositorio de un RAG. Por eso un asistente RAG no debería tener herramientas de escritura sin aprobación humana.
Permisos y seguridad del índice
Los permisos se filtran dentro de la consulta de recuperación, nunca después de generar: si un fragmento sin permiso llega al contexto, el modelo puede usarlo. El patrón habitual es guardar en cada fragmento los grupos con acceso y añadir ese filtro a cada búsqueda; Azure AI Search lo llama security trimming y ofrece, en versión preliminar, la sincronización de permisos desde fuentes como SharePoint.
OWASP dedica a estos sistemas el riesgo Vector and Embedding Weaknesses (LLM08:2025): fugas entre usuarios que comparten una base vectorial, envenenamiento de datos e inversión de embeddings, es decir, recuperar parte del texto original a partir de los vectores. Recomienda control de acceso por documento, particiones lógicas estrictas y registros inmutables de cada recuperación. Los embeddings se protegen como el texto del que salen; más en seguridad y privacidad en proyectos de IA.
Tabla comparativa: decisiones de diseño por capa
En cada capa hay una opción sencilla para empezar y otra más avanzada para cuando las métricas lo pidan:
| Capa | Para empezar | Opción avanzada | Cuándo dar el salto |
|---|---|---|---|
| Troceado | Tamaño fijo con solapamiento, con título y sección en cada fragmento | Por estructura o con contexto generado para cada fragmento | Cuando los fragmentos recuperados no dicen de qué producto o contrato hablan |
| Índice | pgvector en el PostgreSQL existente | Base vectorial dedicada | Cuando el volumen, los filtros o la multitenencia superan a pgvector en tus pruebas |
| Búsqueda | Vectorial | Híbrida, vectorial y BM25, fusionada con RRF | En cuanto las preguntas incluyan códigos, referencias o nombres propios |
| Ordenación | Puntuación del índice | Reranker cross-encoder sobre los candidatos | Cuando el fragmento correcto se recupera, pero no en las primeras posiciones |
| Permisos | Filtro por grupos guardados en cada fragmento | Permisos sincronizados desde el sistema de origen | Cuando los permisos cambian a menudo o viven en SharePoint, Drive o el ERP |
| Evaluación | Banco de preguntas revisado a mano | Métricas automáticas en cada cambio, con revisión de muestras | Cuando varias personas modifican el sistema o se añaden fuentes a menudo |
Evaluación: cómo saber si un RAG funciona
Recuperación y generación se evalúan por separado, porque fallan por motivos distintos. En la recuperación se mide si el fragmento correcto aparece entre los k primeros (recall@k) y si los relevantes quedan por encima de los irrelevantes, lo que Ragas llama precisión de contexto. En la generación se mide la fidelidad —cuánto de la respuesta está respaldado por el contexto, de 0 a 1—, el acierto frente a la respuesta esperada y si el sistema reconoce cuándo no sabe.
- Reúne preguntas reales de usuarios, tickets o correos, con la respuesta esperada y el documento que la contiene.
- Añade casos difíciles: preguntas sin respuesta en la documentación y preguntas sobre documentos que ese usuario no puede ver.
- Repite el banco en cada cambio de troceado, embeddings, prompt o modelo, y compara con la versión anterior.
- Vigila producción: búsquedas sin resultados, valoraciones negativas y documentos que nunca se recuperan.
Las métricas automáticas aceleran, pero no sustituyen la revisión de muestras por alguien que conozca el contenido. Más en testing de sistemas de IA.
Ejemplos de arquitectura RAG
Los escenarios siguientes son hipotéticos e ilustrativos, no casos de clientes.
Soporte técnico sobre manuales de producto
Cientos de manuales en PDF con tablas y códigos de recambio. Los códigos hacen imprescindible la búsqueda híbrida; se trocea por secciones, con la referencia del producto en los metadatos, y la consulta filtra por el producto que el técnico tiene delante. El banco de evaluación sale de tickets resueltos.
Normativa interna con permisos por departamento
Políticas de recursos humanos, finanzas y operaciones en SharePoint. Los permisos se sincronizan con el índice y la evaluación incluye preguntas de personas sin acceso, que deben recibir «no tengo información» y no un resumen de la política salarial.
Una base de conocimiento pequeña
Un equipo con 150 páginas de procedimientos que cambian dos veces al año. Caben en el contexto del modelo, así que no hay índice: se envían completas con caché de prompts. Es la arquitectura más barata y, aquí, la correcta.
Cuánto cuesta un sistema RAG en producción
Estos son los rangos de nuestro informe de precios de software e IA 2026:
- Chatbot o asistente con RAG sobre la documentación de la empresa, con fuentes y panel de gestión: 10.000-25.000 €, en 4-8 semanas.
- Copiloto interno con RAG y permisos por rol, integrado en CRM, helpdesk o herramientas internas: 20.000-50.000 €, en 6-12 semanas.
A eso se suman el uso de modelos por API, desde unos 100 € al mes con poco volumen y entre 2.000 y 5.000 € al mes con volumen alto; la infraestructura cloud, entre 50 y 500 € al mes según tráfico y datos; y el mantenimiento, entre el 15 y el 25 % del coste de desarrollo al año. El precio lo mueven sobre todo el estado de los documentos, el número de fuentes, la sincronización de permisos y la evaluación exigida. Ver el alcance en sistemas RAG para empresas y el desglose en cuánto cuesta automatizar procesos con IA.
Errores frecuentes en arquitecturas RAG
- Indexarlo todo: versiones obsoletas y duplicados compiten con el documento vigente.
- Filtrar permisos después de generar: el modelo ya ha leído lo que el usuario no debía ver.
- Llenar el contexto de fragmentos en vez de reordenarlos y quedarse con los mejores.
- Olvidar las bajas: un documento retirado sigue respondiendo si no se borra del índice.
Preguntas frecuentes
¿Qué componentes tiene una arquitectura RAG?
Una fase de indexación —conectores, extracción, troceado, metadatos y permisos, embeddings e índice— y otra de consulta —búsqueda híbrida filtrada por permisos, reranking, generación con citas y registro—, más evaluación y observabilidad continuas.
¿Qué tamaño de chunk conviene en un sistema RAG?
No hay un tamaño universal. Microsoft propone empezar con 512 tokens y un 25 % de solapamiento; en documentación estructurada suele funcionar mejor trocear por secciones. Se decide midiendo la recuperación con preguntas reales.
¿Hace falta búsqueda híbrida en un sistema RAG?
En empresa, casi siempre. La búsqueda vectorial falla con códigos, referencias y nombres propios, que la búsqueda por palabras clave sí encuentra. Las dos listas se fusionan, normalmente con Reciprocal Rank Fusion.
¿Cómo se respetan los permisos de los documentos en RAG?
Guardando en cada fragmento los usuarios o grupos con acceso, sincronizados con el sistema de origen, y filtrando por la identidad del usuario dentro de la búsqueda, antes de que ningún fragmento llegue al modelo.
¿Cómo se evalúa un sistema RAG?
Con un banco de preguntas reales con su respuesta y su documento esperados. Se miden por separado la recuperación y la generación, y el banco se repite en cada cambio del sistema.