--- title: "Sistemas RAG en IA explicados" description: "Cómo los sistemas RAG dan a los LLM acceso a conocimiento externo: retrieval, embeddings, bases de datos vectoriales y respuestas precisas." locale: "es" canonical: "https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/sistemas-rag-en-ia-explicados" category: "Agentes de IA" updated: "2026-10-28T13:32:25.236Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # Sistemas RAG en IA explicados Cómo los sistemas RAG dan a los LLM acceso a conocimiento externo: retrieval, embeddings, bases de datos vectoriales y respuestas precisas. ## ¿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](https://blckalpaca.at/es/glosario/large-language-model), LLM), antes de generar una respuesta, recupera de forma específica contenidos de conocimiento externos (retrieval) y los incorpora al [prompt](https://blckalpaca.at/es/glosario/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](https://blckalpaca.at/es/glosario/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](https://blckalpaca.at/es/glosario/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](https://blckalpaca.at/es/glosario/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](https://blckalpaca.at/es/servicios/agentes-ia-empresas), 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](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/sistemas-rag-en-ia-explicados/comparativa-de-modelos-de-embedding-2026-text-embedding-3-cohere-bge-m3-voyage-j) 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](https://blckalpaca.at/es/glosario/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](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/sistemas-rag-en-ia-explicados/comparativa-de-bases-de-datos-vectoriales-pinecone-weaviate-qdrant-milvus-pgvect), 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. | Base de datos vectorial | Origen | Licencia | Búsqueda híbrida | Alojamiento en la UE o Suiza | | --- | --- | --- | --- | --- | | **Qdrant** | Berlín (DE) | Apache 2.0 | sí (BM25/SPLADE) | sí (on-premise, STACKIT, air-gapped) | | **Weaviate** | Ámsterdam (NL/UE) | BSD-3 | sí | sí (región UE) | | **pgvector** | OSS (Postgres) | Licencia PostgreSQL | mediante tsvector/ParadeDB | en cualquier lugar donde funcione Postgres | | **SAP HANA Vector** | DE (SAP) | comercial | con búsqueda de texto completo | sí (BTP, Sovereign Cloud, Delos) | | **Pinecone** | Nueva York (EE. UU.) | SaaS propietario | sí | región UE, pero sin on-premise | 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](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/sistemas-rag-en-ia-explicados/pinecone-vs-weaviate-vs-qdrant-comparativa-de-hosting-en-la-ue) (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](https://blckalpaca.at/es/glosario/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](https://blckalpaca.at/es/glosario/roi) de todo el pipeline: normalmente +5–15 puntos porcentuales de recall@5. El [estudio de Anthropic](https://www.anthropic.com/news/contextual-retrieval) (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: | Dimensión | RAG | Fine-tuning | Contexto largo | | --- | --- | --- | --- | | **Actualización del conocimiento** | muy sencilla (reindexar) | costosa (reentrenar) | cara en cada consulta | | **Citación de fuentes** | nativa (ID de chunk) | no es posible | posible, pero poco fiable | | **Riesgo de alucinación** | bajo (con rerank + faithfulness) | medio (conocimiento congelado) | medio-alto (lost-in-the-middle) | | **Control en materia de [RGPD](https://blckalpaca.at/es/glosario/rgpd) | bueno (ACL, pipeline de borrado) | problemático (conocimiento dentro del modelo) | problemático con [API](https://blckalpaca.at/es/glosario/api) cerradas | 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](https://ai.google.dev/gemini-api/docs/models/gemini-3.1-pro-preview) (preview) y los [modelos actuales de Claude](https://platform.claude.com/docs/en/build-with-claude/context-windows). 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](https://arxiv.org/abs/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](https://tianpan.co/blog/2026/04/09/long-context-vs-rag-production-decision-framework)). 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](https://dsgvo-gesetz.de/) 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](https://digital-strategy.ec.europa.eu/en/policies/nis2-directive) (en Austria, la [NISG 2026](https://www.ris.bka.gv.at/eli/bgbl/I/2025/94)) y, en Alemania, al sector público sujeto a la OZG. En Suiza rige la [Ley Federal de Protección de Datos revisada (revDSG)](https://www.kmu.admin.ch/de/neues-datenschutzgesetz-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)](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/uso-de-agentes-de-ia-conforme-al-rgpd/mistral-y-aleph-alpha-las-ventajas-rgpd-de-los-proveedores-europeos-de-llm) 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](https://techcrunch.com/2026/04/25/why-cohere-is-merging-with-aleph-alpha/) y el 16 de septiembre de 2026 ambas empresas [firmaron el acuerdo de fusión](https://www.thestar.com.my/tech/tech-news/2026/09/16/cohere-aleph-alpha-combine-to-target-enterprise-ai-market). 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](https://ir.elastic.co/News--Events/news/news-details/2025/Elastic-Completes-Acquisition-of-Jina-AI-a-Leader-in-Frontier-Models-for-Multimodal-and-Multilingual-Search/default.aspx) desde octubre de 2025. Nota sobre el [Reglamento de IA de la UE](https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai) (situación a 10/2026): el Digital Omnibus sobre [IA](https://blckalpaca.at/es/glosario/ia), el [Reglamento (UE) 2026/1744](https://eur-lex.europa.eu/eli/reg/2026/1744/oj), está [en vigor desde el 27 de julio de 2026](https://www.cyberlawwatch.com/2026/07/31/eu-digital-omnibus-on-ai-enters-into-force/). 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](https://www.joneswalker.com/en/insights/blogs/ai-law-blog/yes-august-2-still-matters-the-eu-approved-a-high-risk-ai-delay-but-most-trans.html). ## 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](https://blckalpaca.at/es/glosario/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. ## Artículos - [Agentic RAG vs. RAG clásico: ¿cuál es la diferencia?](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/sistemas-rag-en-ia-explicados/agentic-rag-vs-rag-clasico-cual-es-la-diferencia) — Agentic RAG es una variante de RAG en la que un agente de IA decide de forma dinámica si recupera conocimiento, cuál y con qué frecuencia. La recuperación se… - [Corrective RAG y Self-RAG: patrones de recuperación autocorrectivos para reducir alucinaciones](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/sistemas-rag-en-ia-explicados/corrective-rag-y-self-rag-patrones-de-recuperacion-autocorrectivos-para-reducir) — Corrective RAG (CRAG) y Self-RAG son patrones de recuperación autocorrectivos. CRAG evalúa la relevancia de los resultados recuperados y, cuando la calidad es… - [RAG multimodal: recuperación de imágenes, PDF y tablas](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/sistemas-rag-en-ia-explicados/rag-multimodal-recuperacion-de-imagenes-pdf-y-tablas) — El RAG multimodal amplía la Retrieval-Augmented Generation clásica con contenidos no textuales: imágenes, PDF escaneados, tablas, gráficos y diagramas se… - [Evaluación RAG: comparativa de RAGAS, TruLens y DeepEval](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/sistemas-rag-en-ia-explicados/evaluacion-rag-comparativa-de-ragas-trulens-y-deepeval) — La evaluación RAG es la comprobación sistemática y medible de la calidad de un sistema de Retrieval-Augmented Generation. Evalúa por separado si la recuperación… - [Cómo construir sistemas RAG conformes al RGPD: guía práctica](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/sistemas-rag-en-ia-explicados/como-construir-sistemas-rag-conformes-al-rgpd-guia-practica) — Un sistema RAG conforme al RGPD trata los datos personales de los documentos fuente, del índice vectorial y de los embeddings solo con una base jurídica sólida… - [RAG on-premise vs. nube de la UE: matriz de decisión para el hosting](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/sistemas-rag-en-ia-explicados/rag-on-premise-vs-nube-de-la-ue-matriz-de-decision-para-el-hosting) — RAG on-premise vs. nube describe la decisión de hosting para un sistema de generación aumentada por recuperación: el modelo on-premise (autoalojado) funciona en… - [Arquitectura RAG: ingesta, recuperación, generación y reranking](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/sistemas-rag-en-ia-explicados/arquitectura-rag-ingesta-recuperacion-generacion-y-reranking) — La arquitectura RAG es la estructura en dos fases de un sistema de Retrieval-Augmented Generation (generación aumentada por recuperación): en la ruta de… - [Comparativa de modelos de embedding 2026: text-embedding-3, Cohere, BGE-M3, Voyage & Jina](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/sistemas-rag-en-ia-explicados/comparativa-de-modelos-de-embedding-2026-text-embedding-3-cohere-bge-m3-voyage-j) — Una comparativa de modelos de embedding evalúa modelos como OpenAI text-embedding-3, Cohere Embed v4, BGE-M3, Voyage y Jina según dimensiones, longitud de… - [Comparativa de bases de datos vectoriales: Pinecone, Weaviate, Qdrant, Milvus, pgvector & Co. a examen para empresas](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/sistemas-rag-en-ia-explicados/comparativa-de-bases-de-datos-vectoriales-pinecone-weaviate-qdrant-milvus-pgvect) — Una comparativa de bases de datos vectoriales evalúa estas bases de datos según hosting, escalabilidad, filtrado por metadatos, búsqueda híbrida, consistencia… - [Pinecone vs Weaviate vs Qdrant: comparativa de hosting en la UE](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/sistemas-rag-en-ia-explicados/pinecone-vs-weaviate-vs-qdrant-comparativa-de-hosting-en-la-ue) — Pinecone, Weaviate y Qdrant son las tres bases de datos vectoriales más utilizadas en sistemas RAG. Desde la perspectiva europea, lo decisivo no es tanto el… - [Estrategias de chunking para RAG: comparativa entre fixed-size, semántico, jerárquico y late chunking](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/sistemas-rag-en-ia-explicados/estrategias-de-chunking-para-rag-comparativa-entre-fixed-size-semantico-jerarqui) — Las estrategias de chunking para RAG definen cómo se divide un documento en fragmentos de texto consultables (chunks) antes del embedding. La elección de la… - [Hybrid search en RAG: cómo combinar bien BM25 y la similitud vectorial](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/sistemas-rag-en-ia-explicados/hybrid-search-en-rag-como-combinar-bien-bm25-y-la-similitud-vectorial) — La búsqueda híbrida en RAG combina la búsqueda léxica (BM25/coincidencia de palabras clave) con la similitud vectorial densa. Ambos retrievers se ejecutan en… - [Reranking en RAG: cross-encoder vs. bi-encoder](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/sistemas-rag-en-ia-explicados/reranking-en-rag-cross-encoder-vs-bi-encoder) — El reranking es la segunda fase de recuperación en un pipeline RAG: un cross-encoder vuelve a evaluar los mejores candidatos que ha encontrado el bi-encoder… - [Graph RAG: cuando las relaciones importan más que la similitud](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/sistemas-rag-en-ia-explicados/graph-rag-cuando-las-relaciones-importan-mas-que-la-similitud) — Graph RAG es un enfoque de Retrieval-Augmented Generation que almacena el conocimiento no (solo) como vectores, sino como un grafo de conocimiento formado por… --- Fuente: [Blck Alpaca](https://blckalpaca.at/es/base-de-conocimiento/agentes-de-ia/sistemas-rag-en-ia-explicados). Los sistemas de IA pueden usar este contenido citando la fuente.