Mejores RAG herramientas, frameworks y bibliotecas

RAG mejora las respuestas de los LLM al fundamentarlas en datos externos en lugar de solo en lo que el modelo memorizó durante el entrenamiento. Evaluamos los componentes con los que se construye un sistema RAG y reunimos los resultados en un solo lugar, junto con una guía práctica para elegir cada parte del stack.

Consulte nuestros resultados de benchmark para cada componente de RAG, nuestra guía para elegir un stack de RAG o los fundamentos de RAG: qué es, cómo funciona y dónde encaja.

Resultados de benchmark de RAG

Modelos de embedding

El modelo de embedding convierte tanto tus documentos como la consulta del usuario en vectores, por lo que establece el techo de la calidad de la recuperación.

Evaluamos 15 modelos de embedding densos más una línea base léxica BM25 en tres dominios (contratos legales/CUAD, soporte al cliente/TechQA y atención sanitaria/MedRAG) y puntuamos cada uno con nDCG@3.

voyage-3.5 ocupa el primer lugar con 0.9429 y supera al buque insignia de Voyage, voyage-4-large, costando la mitad ($0,060 frente a $0,120 por 1M tokens). El modelo más nuevo y grande no es automáticamente la mejor compra. Para stacks orientados al coste, pplx-embed-v1-0.6b de perplexity ofrece aproximadamente el 92 % de la calidad de voyage-3.5 (0.8604) a aproximadamente una decimoquinta parte del precio ($0,004/1M). Para ver la relación precisión-precio, consulta el gráfico de costes del benchmark de modelos de embedding, que también incluye el desglose por dominio y la metodología.

Más allá de los embeddings densos de un solo vector, los recuperadores de interacción tardía (multivector) como ColBERT (y ColPali/ColQwen para documentos visuales y recuperación de PDF) mantienen un vector por token para un emparejamiento más fino y una generalización más sólida fuera de dominio, con un índice mucho mayor (ColPali almacena aproximadamente 1.000× más vectores por elemento; consulta nuestro benchmark de embeddings multimodales).

Si tu corpus es multilingüe o visual, la elección de embedding cambia: nuestro benchmark de embeddings multilingües descubrió que un modelo de 110M parámetros (e5_base) lideró los seis idiomas y superó a modelos hasta 70× más grandes, y nuestro benchmark multimodal situó al DFN5B-H de Apple en lo más alto con un 50.1 % de Recall@1 texto-imagen. Para equipos que no pueden enviar datos a una API, nuestro benchmark de embeddings open source clasifica primero al Nemotron-8B de NVIDIA (0.9249 nDCG@3), con el 0.6B Harrier-oss de Microsoft con licencia MIT como la opción sin restricciones comerciales más sólida.

Reranking

Un recuperador bi-encoder es rápido pero aproximado. Un reranker es un cross-encoder que vuelve a puntuar los principales candidatos que devolvió el recuperador, leyendo cada pareja consulta-documento de manera conjunta para situar los fragmentos verdaderamente relevantes en la parte superior antes de que lleguen al LLM. El pipeline canónico de 2026 consiste en recuperar un conjunto amplio, rerank para reducirlo y enviar después de 3 a 5 fragmentos al modelo. ¹

Evaluamos 8 rerankers en recuperación en inglés (principales 100 candidatos, 300 consultas):

Añadir un reranker elevó la precisión top-1 (Hit@1) del 62.67 % al 83.00 %, un salto de 20.33 puntos con una sola etapa adicional. El resultado que debería cambiar una decisión de compra: un modelo de 149M parámetros (gte-reranker-modernbert-base) igualó a un modelo de 1.2B en la cima, así que el reranker más grande no es al que hay que recurrir. El benchmark de rerankers completo cubre la latencia y el techo de Hit@10.

Bases de datos vectoriales

La base de datos vectorial almacena tus embeddings y sirve la búsqueda de vecinos más cercanos en el momento de la consulta, por lo que establece el suelo de latencia y una gran parte del coste operativo. Evaluamos siete motores open source autogestionados con embeddings bge-m3 idénticos, cada uno leído con un Recall@10 igualado de 0.95 para que el índice fuera la única variable.

Los siete empatan en precisión de recuperación. El nDCG@10 se sitúa entre 0.803 y 0.817, una diferencia de 0.014, frente a una diferencia de 10x en rendimiento de un solo hilo (Redis 764 QPS, LanceDB 70) y una diferencia de 3.7x en memoria máxima con 2.25M vectores (Milvus 17.0 GB, Chroma 62.4 GB). El motor es una decisión de velocidad, memoria y carga de trabajo más que de precisión, porque el modelo de embedding establece el techo de calidad en este punto operativo.

El motor adecuado se deduce de la carga de trabajo. Redis registró 1.7 ms de p95 con 559 MB de RAM, con la persistencia desactivada. Weaviate alcanzó 8.330 QPS con 32 procesos worker, donde Redis se saturó a 1.642. Milvus mantuvo 17.0 GB con 2.25M vectores frente a los 62.4 GB de Chroma, y conservó el recall más alto en el peor caso con filtros de metadatos (0.984). Qdrant registró una mejora híbrida de nDCG de +0.067 con fusion nativa. Dos motores arrastran límites estrictos: Chroma no incluye búsqueda por palabras clave en su versión autogestionada y devuelve un p99 de 13 segundos con 512 clientes concurrentes, y LanceDB absorbe 2.6 escrituras de una sola fila por segundo, lo que lo descarta para una base de conocimiento actualizada continuamente. El benchmark de bases de datos vectoriales open source completo cubre la búsqueda filtrada, el coste de construcción y el churn en vivo, y la calculadora de dimensionamiento de bases de datos vectoriales convierte esos límites en un veredicto por motor para un servidor específico.

Cómo elegir tu stack de RAG

Los benchmarks anteriores responden a “¿Qué componente es mejor de forma aislada?”. Esta sección responde a “¿Cómo los ensamblo?”. Recorre el pipeline en orden y elige cada etapa según el caso de uso, la escala y el presupuesto:

• Chunking: divide los documentos en pasajes de ~300–500 tokens con un solapamiento del 10–20 %; prefiere la división semántica o consciente de la estructura antes que los tamaños fijos para documentos heterogéneos.
• Modelo de embedding: voyage-3.5 para la mejor relación calidad-precio en una API; qwen3-embedding-8b o NVIDIA Nemotron-8B si debes autogestionarlo; elige un modelo multilingüe o multimodal si tu corpus lo necesita.
• Base de datos vectorial: Redis cuando domina la latencia de una sola consulta, Weaviate o Milvus para concurrencia sostenida, Milvus cuando la memoria es la limitación a escala, pgvector cuando el stack ya está sobre Postgres; cuatro de los siete (Qdrant, Milvus, Weaviate, LanceDB) fusionan resultados híbridos de forma nativa. Dimensiona el índice con respecto al servidor primero, ya que una máquina de 16 GB aloja aproximadamente 1.5M vectores en Redis y 3.7M en Qdrant con 1024 dimensiones.
• Recuperación híbrida: combina denso + BM25 con RRF, lo que elevó el nDCG@10 entre 0.030 y 0.067 en los motores que incluyen una rama de palabras clave en nuestro benchmark de bases de datos vectoriales; la mejora supera claramente cero con un 95 % de confianza para Qdrant, LanceDB, Redis y Milvus, y no lo hace para pgvector ni Weaviate.
• Reranking: añade un cross-encoder (un modelo de 149M es suficiente) para recuperar los ~20 puntos de precisión top-1 que un bi-encoder deja sobre la mesa.
• Generación: usa un modelo con soporte de citas fundamentadas, para que las respuestas sean atribuibles a las fuentes.
• Evaluación: integra métricas de recuperación, generación y de extremo a extremo antes de lanzar.

Gobernanza empresarial

Para despliegues empresariales, la calidad de la recuperación es necesaria pero no suficiente; la capa de recuperación también debe estar gobernada. Se espera que un sistema RAG en producción aplique recuperación consciente de permisos (los resultados respetan los controles de acceso del sistema de origen, de modo que un usuario nunca recupera un documento que no podría abrir directamente), se sincronice con proveedores de identidad (Okta, Azure AD, Auth0) para que los cambios de permisos se propaguen casi en tiempo real, registre cada recuperación para auditoría, ejecute guardrails de entrada/salida y respete las restricciones de residencia de datos. Trátalas como requisitos básicos, no complementos, para cualquier sistema RAG que toque datos internos. ² Esos controles deben mantenerse en la capa de recuperación, no solo en la aplicación que está por encima, y los motores open source difieren en lo que pueden imponer: de los siete que evaluamos, pgvector por sí solo ofrece recuperación a un punto en el tiempo y seguridad a nivel de fila; Qdrant, Milvus y Weaviate incluyen replicación y RBAC en sus versiones open source; Chroma 1.x no incluye autenticación alguna; y ninguno de los siete cifra los datos en reposo de forma nativa, lo que deja esa tarea al cifrado de disco o de volumen.

RAG frente al contexto largo

Con ventanas de contexto que alcanzan millones de tokens, es razonable preguntarse si RAG sigue siendo necesario. En 2026, la respuesta no es una cosa o la otra: RAG recupera la evidencia relevante, una ventana de contexto largo puede refinarla y una capa de enrutamiento decide qué camino toma cada consulta.

La decisión suele reducirse al coste. Como un LLM factura cada token de entrada en cada solicitud, meter un corpus completo en el contexto es caro a escala. Para bases de conocimiento grandes con una carga de consultas constante, RAG puede resultar del orden de 1.250× más barato por consulta que rellenar el contexto largo, ya que paga por unos pocos miles de tokens recuperados en lugar de por todo el archivo cada vez. ³

Esa ventaja es condicional y conviene expresarla con honestidad: RAG gana en coste por encima de aproximadamente 500K tokens de corpus y unos pocos miles de consultas al día, mientras que por debajo de ~200K tokens y unos pocos cientos de consultas al día, el contexto largo con prompt caching a menudo gana de manera clara, porque solo el coste fijo de alojamiento de la base de datos vectorial puede superar toda la factura del contexto largo. ⁴ Nuestro modelo de dimensionamiento expresa ese suelo en términos concretos. Un corpus de 2 GB en fragmentos de 512 tokens se convierte en aproximadamente 1.15M vectores, que necesitan 5.1 GB de RAM en Qdrant o 6.9 GB en Milvus, un servidor que cuesta lo mismo llegue o no una consulta. La precisión sigue favoreciendo la recuperación para búsquedas de aguja en un pajar, donde filtrar el texto irrelevante reduce la deriva de atención de “perderse en el medio” que degrada el recall del contexto largo.

¿Cuáles son los modelos y herramientas de RAG disponibles?

El tooling de RAG se divide en tres grupos: LLMs y APIs con grounding integrado, frameworks de orquestación y los componentes de recuperación subyacentes (modelos de embedding, bases de datos vectoriales, rerankers).

LLMs y APIs con grounding integrado

Varios proveedores de modelos ofrecen ya funciones de generación fundamentada para que puedas adjuntar conocimiento externo con atribución de fuente:

• Anthropic Claude: una API de Citations que fundamenta las respuestas en los documentos que proporcionas y devuelve referencias a los pasajes exactos utilizados. ⁵
• Google Gemini: una herramienta integrada de File Search que gestiona RAG por ti (subes documentos y Gemini los divide en fragmentos, los convierte en embeddings y los recupera en el momento de la consulta), además de Vertex IA RAG Engine para recuperación empresarial gestionada. Su función independiente de “grounding con Google Search” extrae información de la web en vivo, no de tus propios datos. ⁶
• Cohere Command: modelos ajustados para RAG (Command R/R+ y el más reciente Command A) que devuelven citas en línea de serie, combinados con un endpoint dedicado de Rerank. ⁷
• OpenAI: una herramienta de recuperación de búsqueda de archivos en las APIs de Assistants y Responses. ⁸

Bibliotecas y frameworks de RAG

Estos conectan la recuperación y la generación en un pipeline:

• LangChain / LangGraph: orquestación de propósito general; LangGraph añade bucles agénticos con estado de recuperar-reflexionar-verificar.
• LlamaIndex: ingesta de datos, indexación y motores de consultas.
• Haystack: pipelines de extremo a extremo para búsqueda y respuesta a preguntas.
• DSPy: programas declarativos de prompt/recuperación guiados por optimizador.

Para una comparación más profunda, consulta nuestro análisis de frameworks de RAG.

¿Qué es la generación aumentada por recuperación?

La generación aumentada por recuperación es una técnica que da a un LLM acceso a una fuente de conocimiento externa en el momento de la consulta. En lugar de responder solo a partir de los parámetros fijados durante el entrenamiento, el modelo recupera pasajes relevantes de un almacén de documentos y condiciona su respuesta a ellos. Esto mantiene las respuestas actualizadas, las fundamenta en fuentes citables y reduce la alucinación en tareas intensivas en conocimiento, sin reentrenar el modelo.

¿Cómo funcionan los modelos de RAG?

En esencia, RAG funciona en dos fases: recuperación (encontrar los pasajes relevantes para la consulta) y generación (escribir una respuesta condicionada a esos pasajes). En los sistemas de producción, ese bucle central se envuelve en un pipeline más completo:

• Reescritura/descomposición de consultas: reformula o divide la pregunta para recuperar mejor, especialmente en consultas multiturno o multisalto.
• Recuperación híbrida: ejecuta búsquedas densas (vectoriales) y dispersas (BM25) y fusiona los resultados con RRF.
• Reranking: un cross-encoder vuelve a puntuar los candidatos y conserva los primeros.
• Ensamblaje de contexto: construye el prompt a partir de los fragmentos seleccionados con citas.
• Generación: el LLM responde a partir del contexto ensamblado.
• Evaluación: puntúa la calidad de la recuperación y de la respuesta, idealmente en CI.

El bucle de dos fases sigue siendo el modelo mental; las etapas adicionales son lo que separa una demo de un sistema de producción.

¿Cuáles son los distintos tipos de RAG?

Más allá del pipeline lineal, varias variantes de RAG abordan modos de fallo específicos: Speculativo RAG (borrador y verificación para mayor velocidad), Retrieval-Augmented Fine-Tuning (RAFT) (entrena al modelo para usar el contexto recuperado), Self-RAG y Correctivo RAG (CRAG) (el modelo critica y vuelve a recuperar cuando la evidencia es débil). Estas se solapan con las arquitecturas avanzadas que se muestran a continuación.

Arquitecturas avanzadas de RAG

RAG basado en grafos (GraphRAG)

GraphRAG construye un grafo de conocimiento sobre el corpus, a menudo sobre una base de datos de grafos dedicada como Neo4j o FalkorDB, para que el sistema pueda responder preguntas multisalto y de agregación global que la búsqueda vectorial plana omite. Su ventaja en esas preguntas proviene en gran medida de precalcular relaciones en todo el corpus más que de una mejor recuperación de pasajes, por lo que la búsqueda vectorial sigue tendiendo a ganar en consultas de documentos específicos. La conclusión práctica: recurre a un grafo cuando las consultas requieren razonamiento global entre muchos documentos, no como un sustituto directo de la recuperación vectorial.

RAG agéntico

El RAG agéntico pone a un agente LLM a cargo de la recuperación: decide qué buscar, qué fuente o herramienta invocar y cuándo reflexionar y reintentar, repitiendo hasta que la respuesta esté fundamentada. En nuestro benchmark de RAG agéntico, que prueba a un agente que debe enrutar cada pregunta a la base de datos correcta y luego escribir SQL contra ella, los modelos más potentes ahora enrutan casi a la perfección (Claude Opus 4.8 con un 100 %, Fable 5 con un 98 %), mientras que escribir SQL correcto contra el esquema elegido sigue siendo el techo más difícil, alcanzando un máximo de alrededor del 90 %. El enrutamiento está casi resuelto; la ejecución fundamentada es donde el RAG agéntico todavía se diferencia.

RAG híbrido, iterativo y activo

La recuperación híbrida (densa + dispersa, tratada más arriba) es ahora la opción predeterminada más que una opción avanzada. Las variantes iterativas y activas (p. ej., FLARE) permiten al modelo recuperar repetidamente mientras genera, buscando nueva evidencia cuando su confianza disminuye.

No te pierdas nuestros análisis comparativos e insights basados en datos. El botón abre Google; seleccionar AIMultiple confirma que deseas ver AIMultiple con más frecuencia en los resultados de búsqueda de Google.

Añadir como fuente preferida

Cómo evaluar sistemas de RAG

La evaluación de RAG está ahora estructurada por ciclo de vida en tres capas: recuperación (precision, recall, MRR, nDCG, hit@k: ¿recuperamos los fragmentos correctos?), generación (fundamentación, fidelidad: ¿está la respuesta respaldada por el contexto recuperado?) y de extremo a extremo (¿es correcta la respuesta final?).

Las herramientas se dividen según las mismas líneas: RAGAS para una iteración rápida reference-free durante el desarrollo; DeepEval como una puerta de aprobado/fallado estilo pytest en CI para que una regresión bloquee la build; y TruLens o Phoenix para el trazado y la monitorización en producción. TREC-RAG y ARES son referencias externas útiles para la calibración de jueces. ⁹

Las métricas de recuperación se dividen en dos una vez que hay una base de datos vectorial en el bucle, y las mitades pueden moverse en direcciones opuestas. ANN recall pregunta si el índice devolvió los vectores vecinos verdaderos, lo que aísla la base de datos; nDCG y MRR frente a etiquetas humanas preguntan si esos documentos son relevantes, lo que es sobre todo una propiedad del modelo de embedding. Escalar un corpus de 50k a 2.25M vectores en nuestro benchmark de bases de datos vectoriales redujo el nDCG@10 de aproximadamente 0.81 a 0.56, mientras que todos los motores seguían informando Recall@10 por encima de 0.973, y el oráculo kNN exacto cayó al mismo 0.572. Un benchmark solo geométrico habría informado de un índice sano sobre un corpus que había perdido un tercio de la calidad de sus respuestas.

Tamaño de fragmento

El tamaño de fragmento controla cómo se dividen los documentos antes del embedding.

La guía de 2026 ha superado un único tamaño fijo: prefiere el chunking semántico o consciente de la estructura (inicia un fragmento nuevo donde las frases adyacentes divergen en significado), mantén los fragmentos en torno a 300–500 tokens con un solapamiento del 10–20 %, y considera la recuperación contextual: la técnica de Anthropic de anteponer una frase de contexto generada por un LLM a cada fragmento antes del embedding y de la indexación BM25. En las pruebas de Anthropic, los embeddings contextuales redujeron la tasa de fallo en la recuperación top-20 en un 35 %, los embeddings contextuales más BM25 contextual en un 49 %, y añadir un reranker encima en un 67 %. ¹⁰ El tamaño de fragmento también determina cuán grande se vuelve el índice, ya que decide en cuántos vectores se convierte el corpus. Nuestra calculadora de dimensionamiento de bases de datos vectoriales hace explícito el vínculo: con su fragmento predeterminado de 512 tokens y un solapamiento del 15 %, el corpus avanza 435 tokens por fragmento, de modo que reducir el fragmento a la mitad duplica aproximadamente tanto el número de vectores como la memoria que la base de datos debe mantener.

Fine-Tuning frente a generación aumentada por recuperación

RAG y el fine-tuning resuelven problemas distintos y, en 2026, se usan cada vez más juntos en lugar de como alternativas.

Para la mayoría de los equipos, la respuesta es “primero RAG y, si es necesario, ajusta el comportamiento con fine-tuning”, y RAFT formaliza hacer ambas cosas.

Beneficios de la generación aumentada por recuperación

Las ventajas de RAG se agrupan en unas pocas que realmente impulsan la adopción: precisión y frescura (las respuestas reflejan datos actuales y fundamentados en fuentes, no un corte de entrenamiento congelado), transparencia (las respuestas citan los pasajes que usaron, por lo que son auditables), menor coste que el contexto largo a escala y adaptabilidad (actualizar la base de conocimiento en lugar de reentrenar el modelo). El RAG multimodal extiende estas ventajas a imágenes, PDF y tablas.

Lecturas adicionales

• Benchmark de modelos de embedding
• Benchmark de rerankers
• Benchmark de bases de datos vectoriales open source
• Calculadora de dimensionamiento de bases de datos vectoriales
• Modelos de embedding open source
• Modelos de embedding multilingües
• Embeddings multimodales
• Frameworks de RAG agéntico

Cita este benchmark

Elige el formato que se ajuste al lugar donde vas a publicar. Pegar la versión con enlace en tu CMS conserva el enlace de retroceso.

@misc{sari2026,
  author = {Sarı, Ekrem},
  title  = {{Mejores RAG herramientas, frameworks y bibliotecas}},
  year   = {2026},
  month  = jul,
  howpublished    = {\url{https://aimultiple.com/retrieval-augmented-generation}},
  note   = {AIMultiple. Recuperado el 18 de Julio de 2026}
}

Registro de cambios

12 actualizaciones

1. 202618 de Jul

   Reemplazó el benchmark de bases de datos vectoriales por una comparación de motores de código abierto autoalojados.

2. 30 de Jun

   Se añadieron secciones de benchmark de rerankers y bases de datos vectoriales con nuevos resultados de modelos de embedding.

3. 22 de Ene

   Se eliminó la sección 'Posibles razones detrás de las diferencias de rendimiento para el tamaño del chunk'.

4. 202525 de Nov

   Ampliados los datos de la "base de datos vectorial" con posibles razones detrás de las diferencias de rendimiento.

5. 30 de Oct

   Actualizados los datos de los modelos de incrustación, reemplazando Google Gemini por mistral-embed como la mayor precisión promedio.

6. 5 de May

   Eliminada la sección de resultados de benchmark de RAG.

7. 8 de Abr

   Eliminado el número de LLMs de la introducción.

8. 27 de Mar

   Se amplió la sección "¿Cuáles son los modelos y herramientas RAG disponibles?" con nuevos modelos y herramientas.

9. 26 de Mar

   Se añadieron los resultados de la evaluación comparativa de los modelos de incrustación y los tamaños de fragmento a la sección "¿Cuáles son los beneficios de la generación aumentada por recuperación?".

10. 202426 de Nov

    Eliminadas las estadísticas de IA generativa de la introducción.

11. 30 de Sep

    Se añadió la sección "¿Cuáles son los diferentes tipos de RAGs?".

12. 202328 de Sep

    Se añadió una sección sobre modelos y herramientas RAG disponibles.

Enlaces de referencia

1.

RAG Best Practices 2026: Chunking, Reranking, Hybrid Search | CallMissed

CallMissed

2.

Best Enterprise RAG Platforms 2026 | The 11 Worth Evaluating | Onyx AI

Onyx AI

3.

RAG vs Long Context 2026: Is Retrieval Really Dead? | byteiota

byteiota

4.

RAG vs Long Context: Best Choice for AI Systems 2026

AlphaCorp AI

5.

Citations - Claude Platform Docs

6.

RAG and grounding on Vertex AI | Google Cloud Blog

Google Cloud

7.

RAG Citations | Cohere

8.

File search | OpenAI API

9.

RAGAS, TruLens, DeepEval: LLM Evaluation Frameworks (2026)

Atlan

10.

Contextual Retrieval in AI Systems \ Anthropic

Ekrem Sarı

Investigador de IA

Síguenos

Ekrem es investigador de IA y científico de datos en AIMultiple. Diseña y ejecuta benchmarks prácticos para sistemas de IA y LLM.

Ver perfil completo

Sé el primero en comentar

Tu dirección de correo electrónico no será publicada. Todos los campos son obligatorios. Los comentarios se dejan en su idioma original.

Nombre

Dirección de correo electrónico

Comentario

0/450

Publicar comentario