Sistemas RAG en IA explicados

¿Qué es RAG? Una definición clara

La generación aumentada por recuperación (Retrieval-Augmented Generation, RAG) es un método en el que un modelo de lenguaje de gran tamaño (Large Language Model, LLM), antes de generar una respuesta, recupera de forma específica contenidos de conocimiento externos (retrieval) y los incorpora al prompt (augmentation) para apoyar la generación en fuentes verificables. La definición original procede de Lewis et al. (Facebook AI Research, NeurIPS 2020) y describe RAG como la combinación de una memoria paramétrica (el modelo de lenguaje entrenado) y una memoria no paramétrica (un índice externo en el que se puede buscar).

Si se comparan las distintas definiciones canónicas, se puede fijar un consenso mínimo. Un sistema RAG consta de tres elementos obligatorios: (i) un almacén de conocimiento externo con índice, (ii) un retriever que encuentra los pasajes relevantes y (iii) un LLM generador cuyo prompt se completa con los contenidos encontrados. La ventaja central: RAG ofrece respuestas basadas en fuentes y trazables, reduce las alucinaciones de forma medible y mantiene el conocimiento actualizado sin necesidad de volver a entrenar el modelo.

¿Por qué RAG? El problema que resuelve

Los LLM tienen tres debilidades estructurales: alucinan, su conocimiento se queda congelado en la fecha de entrenamiento y sus respuestas no son trazables. RAG aborda las tres. En lugar de entrenar el modelo con datos nuevos mediante un fine-tuning costoso, el conocimiento relevante se carga en tiempo de ejecución para cada consulta. Así, actualizar es tan sencillo como reindexar; las referencias a las fuentes (citations) son posibles de forma nativa a través de los ID de chunk, y la respuesta sigue ligada a material verificable.

Precisamente estas propiedades convierten a RAG en el patrón estándar de facto para la IA empresarial en Europa, donde la trazabilidad, la actualidad y el control de los datos no son opcionales, sino exigencias regulatorias y de confianza.

El pipeline RAG: ruta de indexación y ruta de consulta

Un sistema RAG en producción tiene dos rutas. La ruta de indexación (offline/batch) procesa las fuentes de conocimiento: los conectores cargan documentos desde SharePoint, S3, Confluence o bases de datos; un parser (p. ej., Docling) extrae texto, tablas y estructuras respetando la maquetación; un chunker divide los contenidos; un modelo de embeddings genera vectores y un upsert los escribe con sus metadatos (ID de tenant, ACL, fuente, marca de tiempo) en la base de datos vectorial; opcionalmente, todo ello acompañado de un índice BM25 paralelo.

La ruta de consulta (online) empieza con la consulta del usuario, que opcionalmente se reescribe (query rewriting, HyDE). Después se ejecuta una recuperación híbrida (normalmente top_k = 50–100), seguida de un reranker que condensa el resultado en los 5–10 pasajes más relevantes. Estos se insertan en una plantilla de prompt con citas de fuentes y se pasan al LLM; un control de fidelidad (faithfulness check) puede verificar la respuesta frente a las fuentes.

Embeddings y bases de datos vectoriales

Los embeddings son representaciones vectoriales numéricas de texto en las que la proximidad semántica se refleja como proximidad geométrica (la similitud del coseno es el valor por defecto para vectores normalizados). Para corpus en alemán rige una regla importante: el ranking MTEB en inglés no es el ranking en alemán. Los modelos que lideran en inglés suelen perder 5–15 puntos de nDCG@10 con los compuestos alemanes, el lenguaje técnico y las palabras largas. Lo determinante son los benchmarks en alemán o multilingües (MMTEB, MIRACL-de, MTEB-DE). Además, los compuestos alemanes generan más tokens; como regla general, según el modelo, el alemán consume aproximadamente 1,3–1,7 veces más tokens que el inglés.

Las bases de datos vectoriales almacenan embeddings y responden a consultas de similitud mediante índices de vecinos más cercanos aproximados (Approximate Nearest Neighbour). El algoritmo estándar es HNSW (Hierarchical Navigable Small World, Malkov & Yashunin 2016), que funciona en prácticamente todos los sistemas en producción: desde Qdrant, pasando por Weaviate, Milvus y pgvector, hasta SAP HANA. Valor de referencia práctico: HNSW ofrece un 95–99 % de recall y funciona con holgura hasta ~100 millones de vectores; por encima de esa cifra ayudan la cuantización (halfvec, SQ8) o los métodos basados en disco como DiskANN.

Para las pymes con menos de ~10–50 millones de vectores, pgvector sobre un Postgres gestionado (IONOS, STACKIT, OTC, Hetzner) es la opción soberana pragmática por defecto: una base de datos, una estrategia de copias de seguridad, una cadena de contratos de encargo del tratamiento. Las grandes empresas suelen operar dos o tres stores en paralelo: SAP HANA Vector para los datos residentes en SAP y, además, una base de datos vectorial dedicada (Qdrant, Weaviate) para los documentos no estructurados.

Chunking: cómo se fragmenta el conocimiento

El chunking determina en gran medida la calidad del retrieval. El chunking ingenuo de tamaño fijo (p. ej., 512 tokens con un solapamiento de 50 tokens) es robusto, pero corta frases, tablas y listas; un antipatrón frecuente. Estrategias mejores:

• El chunking recursivo/semántico respeta la estructura del documento o corta en los puntos donde cambia el contenido.
• El chunking jerárquico (parent-child) usa chunks pequeños para el retrieval y chunks padre grandes como contexto para el generador.
• Contextual Retrieval (Anthropic, 09/2024) antepone a cada chunk, antes del embedding, una breve cabecera de contexto generada por un LLM. Resultado: −49 % de errores de retrieval y −67 % con un reranker adicional. El precio es una llamada al LLM por chunk durante la ingesta.
• Late Chunking (Jina, 2024) invierte el orden: primero se genera el embedding del documento completo con un embedder de contexto largo y después se promedian los embeddings de los tokens dentro de los límites de cada chunk; así, los vectores de los chunks conservan el contexto del documento. El late chunking es prácticamente gratuito durante la ingesta (sin llamada adicional al LLM) y, en el estudio de Jina, rinde ~24 % mejor que el chunking ingenuo. Para proyectos con disciplina de costes, el late chunking con Jina v3/v4 o BGE-M3 suele ser la opción por defecto más rentable.

En los PDF con mucha maquetación (contratos, correspondencia con organismos públicos, informes NIIF) ganan los parsers que tienen en cuenta el layout (Docling, Marker) y, a medio plazo, los enfoques multimodales como ColPali/ColQwen o Jina v4, que renderizan cada página como imagen y evitan así los errores de OCR y de maquetación.

Búsqueda híbrida y reranking

La búsqueda híbrida combina el dense retrieval (embeddings, proximidad semántica) con el sparse retrieval (BM25 o modelos dispersos aprendidos como SPLADE/ELSER) y fusiona los resultados, normalmente mediante Reciprocal Rank Fusion (RRF). El motivo: los embeddings por sí solos fallan con códigos exactos, ID, números de expediente, números de material de SAP o IBAN, que son justo los tokens que cuentan en la práctica B2B. BM25 los captura. En alemán, con sus compuestos y su lenguaje técnico, la búsqueda híbrida aporta de forma sistemática 5–15 puntos de nDCG@10 más que el enfoque solo denso.

El reranking es la segunda etapa de ordenación, más precisa: un cross-encoder procesa conjuntamente la consulta y el documento y vuelve a puntuar a los mejores candidatos. Es la mejora individual con mayor ROI de todo el pipeline: normalmente +5–15 puntos porcentuales de recall@5. El estudio de Anthropic (09/2024) mide el efecto sobre la tasa de error en el retrieval top-20: los Contextual Embeddings por sí solos la reducen un 35 %; los Contextual Embeddings más Contextual BM25 (juntos, Contextual Retrieval), un 49 %, y con un reranker adicional, un 67 %. El paso del reranker baja la tasa de error del 2,9 % al 1,9 %.

Presupuesto de latencia para un pipeline estándar (10 millones de vectores): primera etapa BM25 y densa, 10–50 ms cada una; RRF, menos de 1 ms; reranker cross-encoder (p. ej., BGE Reranker M3 en una GPU), 100–300 ms; en total, 150–500 ms antes de la generación del LLM. Con SLA estrictos por debajo de 100 ms, el reranker es el primer candidato a eliminar, a cambio de una pérdida de recall de 5–15 puntos.

RAG frente a las alternativas: ¿cuándo usar cada una?

RAG no es la única estrategia. La elección frente al fine-tuning, el contexto largo y el prompt engineering depende del objetivo:

Un debate abierto, aunque cada vez más resuelto, es el de contexto largo frente a RAG. Los modelos actuales procesan alrededor de 1 millón de tokens de contexto, por ejemplo Gemini 3.1 Pro (preview) y los modelos actuales de Claude. En la clásica prueba de una sola aguja (single needle), ya Gemini 1.5 Pro alcanzaba más del 99,7 % de recall con 1 millón de tokens; si el modelo busca 100 agujas a la vez, el valor cae a algo más del 60 % (informe de Gemini 1.5, arXiv:2403.05530). A esto se suman una latencia ~30–60 veces mayor y unos costes por consulta varios órdenes de magnitud superiores frente a un pipeline RAG (estimación de Tian Pan, 2026). El consenso en 2026: el contexto largo complementa a RAG en cargas de trabajo muy acotadas, pero rara vez lo sustituye en escenarios multi-needle, multi-tenant o sensibles a los costes.

RGPD y operación soberana en Europa

Nota: las siguientes afirmaciones son informativas y no constituyen asesoramiento jurídico.

Una de las preguntas de fondo más importantes del RGPD en 2025/2026 es esta: ¿Son los embeddings datos personales? La respuesta honesta es «muy probablemente sí, si se derivan de datos personales». Los ataques de inversión reconstruyen con exactitud hasta el 92 % de entradas de 32 tokens (Morris et al., EMNLP 2023); por tanto, un embedding no es una seudonimización segura. El Dictamen 28/2024 del CEPD exige una evaluación caso por caso del riesgo de reidentificación; la sentencia del TJUE C-413/23 P (septiembre de 2025) precisa que los datos seudonimizados no son automáticamente datos personales para cualquier destinatario, pero solo acota las obligaciones, no las elimina.

Consecuencias prácticas para las arquitecturas RAG, en línea con la guía orientativa sobre RAG de la Conferencia de Protección de Datos alemana (DSK) y con las directrices del CEPD:

• Derecho de supresión (art. 17): los embeddings y los chunks también deben poder borrarse. Los grafos HNSW admiten el borrado de puntos con distinta eficacia; la semántica de borrado es un criterio de adquisición imprescindible (pgvector y Qdrant borran de forma eficiente).
• Aislamiento entre tenants: ID de tenant y ACL en los metadatos, filtro en cada consulta, defensa en profundidad (autenticación + filtro + nueva comprobación + registro de auditoría). Un índice compartido sin filtro de tenant es un incidente de RGPD anunciado.
• Residencia de datos: priorizar el alojamiento en regiones de la UE; con proveedores cloud estadounidenses, evaluar el riesgo residual derivado de la CLOUD Act y FISA 702 (cláusulas contractuales tipo + TIA). Transferir embeddings a una base de datos vectorial alojada en EE. UU. es una transferencia a un tercer país.
• Minimización antes del embedding: eliminar en la medida de lo posible nombres, correos electrónicos e ID antes del embedding o sustituirlos por seudónimos estables; cifrar los vectores con claves gestionadas por el cliente (CMK/BYOK).

Para cargas de trabajo reguladas, cada capa debe poder desplegarse de forma soberana. En la UE, esto afecta, por ejemplo, al sector financiero sujeto a DORA (en Alemania, además, a MaRisk), a los productos sanitarios y de diagnóstico in vitro sujetos a MDR/IVDR, a las entidades esenciales e importantes sujetas a la transposición nacional de NIS2 (en Austria, la NISG 2026) y, en Alemania, al sector público sujeto a la OZG. En Suiza rige la Ley Federal de Protección de Datos revisada (revDSG), concebida para ser compatible con el RGPD.

La infraestructura soberana en la región DACH (Alemania, Austria y Suiza) y en la UE es sólida en 2026: Qdrant (Berlín), Weaviate (Ámsterdam), Haystack/deepset (Berlín), SAP HANA Cloud Vector Engine y pgvector sobre STACKIT/IONOS/OTC/Hetzner. Entre los proveedores de modelos, el panorama ha cambiado. Aleph Alpha (Heidelberg) ha abandonado el desarrollo de sus propios modelos frontier y ofrece, entre otras cosas, la plataforma PhariaAI. En abril de 2026, Cohere anunció su fusión con Aleph Alpha y el 16 de septiembre de 2026 ambas empresas firmaron el acuerdo de fusión. La empresa resultante operará como Cohere, con sede en Toronto y Berlín, y la sede de Heidelberg se centrará en la investigación. El cierre de la operación sigue sujeto a las autorizaciones de las autoridades competentes. Jina AI (Berlín), proveedor de modelos de embeddings y rerankers, pertenece a Elastic desde octubre de 2025.

Nota sobre el Reglamento de IA de la UE (situación a 10/2026): el Digital Omnibus sobre IA, el Reglamento (UE) 2026/1744, está en vigor desde el 27 de julio de 2026. Por tanto, las obligaciones para los sistemas de alto riesgo del anexo III se aplican a partir del 2 de diciembre de 2027, y las de la IA de alto riesgo integrada en productos del anexo I, a partir del 2 de agosto de 2028. Las obligaciones de transparencia del art. 50 se aplican desde el 2 de agosto de 2026. Solo para el marcado legible por máquina del art. 50, apartado 2, los proveedores de sistemas que ya estaban en el mercado antes de esa fecha tienen plazo hasta el 2 de diciembre de 2026.

Control de calidad con RAGAS

Un sistema RAG sin evaluación empeora sin que nadie lo note. El estándar de facto es RAGAS, con las métricas clave Faithfulness (fidelidad a la fuente), Answer Relevancy, Context Precision y Context Recall, complementado con TruLens («RAG Triad») o DeepEval. Lo recomendable es combinar un conjunto de referencia (gold set), LLM-as-Judge y pruebas A/B en producción, integrados de forma permanente en el pipeline de CI. El citation forcing, los guardrails de fidelidad y la negativa a responder cuando la puntuación es baja son los recursos estándar contra las alucinaciones que persisten pese a RAG.

Perspectivas y recomendación práctica

Las bases de datos vectoriales y los modelos de embeddings se han convertido en gran medida en commodities a nivel de API: HNSW está en todas partes, la búsqueda híbrida es estándar y la multimodalidad (ColPali, Jina v4) es la nueva frontera. En paralelo, RAG evoluciona por las etapas Naive → Advanced → Modular → Agentic RAG, y el retrieval se entiende cada vez más como una herramienta dinámica de un agente (Singh et al. 2025).

El punto de partida pragmático para un proyecto: empieza con BM25 + Dense (BGE-M3) + reranker cross-encoder (BGE Reranker M3) sobre una base soberana de Postgres/pgvector, clasifica los datos personales antes del embedding y mide la calidad desde el primer día con RAGAS. Lo que domina la arquitectura en 2026 ya no es el rendimiento bruto, sino la pregunta de dónde están los embeddings, quién puede acceder a ellos y si, llegado el caso, el stack puede llevarse on-premise. Un stack RAG soberano, preparado para el alemán y orientado al open source es la respuesta sólida.