Mejores herramientas, frameworks y bibliotecas de RAG
RAG mejora las respuestas de los LLM al basarlas en datos externos en lugar de solo en lo que el modelo memorizó durante el entrenamiento. Hemos evaluado los componentes con los que se construye un sistema RAG y recopilado los resultados en un solo lugar, con una guía práctica para elegir cada parte del stack.
Consulte nuestros resultados de referencia 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 referencia de RAG
Modelos de embedding
El modelo de embedding convierte tanto sus documentos como la consulta del usuario en vectores, por lo que establece el techo de calidad de 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 médica/MedRAG), puntuando cada uno con nDCG@3.
voyage-3.5 ocupa el primer lugar con 0.9429 y supera al propio buque insignia voyage-4-large de Voyage, costando la mitad ($0.060 frente a $0.120 por 1M de tokens). El modelo más nuevo y grande no es automáticamente la mejor compra. Para stacks donde el costo es prioritario, pplx-embed-v1-0.6b de Perplexity ofrece aproximadamente el 92% de la calidad de voyage-3.5 (0.8604) a aproximadamente una quinceava parte del precio ($0.004/1M). Para ver la relación precisión-precio, consulte el gráfico de costos en el benchmark completo de modelos de embedding, que también incluye el desglose por dominio y la metodología.
Más allá de los embeddings densos de vector único, los recuperadores de interacción tardía (multivector) como ColBERT (y ColPali/ColQwen para la recuperación de documentos visuales y PDF) mantienen un vector por token para un emparejamiento más fino y una generalización más sólida fuera de dominio, a costa de un índice mucho más grande (ColPali almacena aproximadamente 1,000× más vectores por elemento; consulte nuestro benchmark de embeddings multimodales).
Si su corpus es multilingüe o visual, la elección del embedding cambia: nuestro benchmark de embeddings multilingües encontró que un modelo de 110M de parámetros (e5_base) lideró los seis idiomas y superó a modelos hasta 70× más grandes, y nuestro benchmark multimodal situó a DFN5B-H de Apple en la cima con un Recall@1 texto-imagen del 50.1%. Para equipos que no pueden enviar datos a una API, nuestro benchmark de embeddings de código abierto clasifica a Nemotron-8B de NVIDIA en primer lugar (0.9249 nDCG@3), con Harrier-oss de 0.6B con licencia MIT de Microsoft como la opción comercial sin restricciones más sólida.
Reordenamiento (Reranking)
Un recuperador bi-encoder es rápido pero aproximado. Un reranker es un cross-encoder que vuelve a puntuar los mejores candidatos devueltos por el recuperador, leyendo cada par consulta-documento conjuntamente para llevar los fragmentos verdaderamente relevantes a la cima antes de que lleguen al LLM. El pipeline canónico de 2026 consiste en recuperar un conjunto amplio, rerankearlo para reducirlo, y luego enviar de 3 a 5 fragmentos al modelo. 1
Evaluamos 8 rerankers en recuperación en inglés (top-100 candidatos, 300 consultas):
Añadir un reranker elevó la precisión en el top-1 (Hit@1) de 62.67% a 83.00%, un salto de 20.33 puntos con una sola etapa adicional. El resultado que debería influir en una decisión de compra: un modelo de 149M de parámetros (gte-reranker-modernbert-base) igualó a un modelo de 1.2B en la cima, por lo que el reranker más grande no es al que hay que recurrir. El benchmark completo de rerankers cubre la latencia y el techo de Hit@10.
Bases de datos vectoriales
La base de datos vectorial almacena sus embeddings y sirve la búsqueda de vecinos más cercanos en el momento de la consulta, por lo que establece el piso de latencia y una gran parte del costo operativo. Evaluamos siete motores autogestionados de código abierto con embeddings bge-m3 idénticos, cada uno leído con un Recall@10 equiparado de 0.95 para que el índice fuera la única variable.
Los siete empatan en precisión de recuperación. nDCG@10 se sitúa entre 0.803 y 0.817, una dispersión de 0.014, frente a una dispersión de 10x en el rendimiento de un solo hilo (Redis 764 QPS, LanceDB 70) y una dispersión de 3.7x en la memoria pico con 2.25M de vectores (Milvus 17.0 GB, Chroma 62.4 GB). El motor es una decisión de velocidad, memoria y carga de trabajo, no de precisión, porque el modelo de embedding establece el techo de calidad en este punto de operación.
Qué motor se ajusta depende de la carga de trabajo. Redis registró un p95 de 1.7 ms con 559 MB de RAM, con persistencia desactivada. Weaviate alcanzó 8,330 QPS con 32 procesos trabajadores, donde Redis se saturó a 1,642. Milvus mantuvo 17.0 GB con 2.25M de vectores frente a los 62.4 GB de Chroma, y conservó el mejor recall en el peor de los casos bajo filtros de metadatos (0.984). Qdrant registró una mejora de nDCG híbrido de +0.067 con fusión nativa. Dos motores tienen 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 completo de bases de datos vectoriales de código abierto cubre la búsqueda filtrada, el costo de construcción y la rotación 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 su stack de RAG
Los benchmarks anteriores responden a “¿Qué componente es mejor de forma aislada?”. Esta sección responde a “¿Cómo los ensamblo?”. Recorra el pipeline en orden y elija cada etapa según el caso de uso, la escala y el presupuesto:
- Fragmentación (Chunking): divida los documentos en pasajes de ~300–500 tokens con un solapamiento del 10–20%; prefiera la división semántica o consciente de la estructura en lugar de 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 debe autogestionarse; elija un modelo multilingüe o multimodal si su corpus lo requiere.
- Base de datos vectorial: Redis cuando domina la latencia de consulta única, Weaviate o Milvus para concurrencia sostenida, Milvus cuando la memoria es la restricción a escala, pgvector cuando el stack ya está en Postgres; cuatro de los siete (Qdrant, Milvus, Weaviate, LanceDB) fusionan resultados híbridos de forma nativa. Dimensione el índice primero con respecto al servidor, ya que una caja de 16 GB contiene aproximadamente 1.5M de vectores en Redis y 3.7M en Qdrant con 1024 dimensiones.
- Recuperación híbrida: combine denso + BM25 con RRF, lo que elevó el nDCG@10 entre 0.030 y 0.067 en los motores que incorporan un brazo de palabras clave en nuestro benchmark de bases de datos vectoriales; la mejora supera el cero con una confianza del 95% para Qdrant, LanceDB, Redis y Milvus, y no lo hace para pgvector o Weaviate.
- Reordenamiento (Reranking): añada 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: utilice un modelo con soporte de citas fundamentadas, para que las respuestas sean atribuibles a la fuente.
- Evaluación: conecte métricas de recuperación, generación y de extremo a extremo antes de poner en producción.
Gobernanza empresarial
Para implementaciones empresariales, la calidad de recuperación es necesaria pero no suficiente; la capa de recuperación también debe estar gobernada. Se espera que un RAG en producción imponga una recuperación consciente de permisos (los resultados respetan los controles de acceso del sistema de origen, de modo que un usuario nunca recupere 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 barreras de protección de entrada/salida y cumpla con las restricciones de residencia de datos. Trate estos como requisitos mínimos indispensables, no como complementos, para cualquier sistema RAG que toque datos internos. 2 Esos controles deben mantenerse en la capa de recuperación, no solo en la aplicación que está por encima, y los motores de código abierto difieren en lo que pueden imponer: de los siete que evaluamos, solo pgvector 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 de código abierto; 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 volumen.
RAG frente a contexto largo
Con ventanas de contexto que alcanzan millones de tokens, una pregunta justa es si RAG sigue siendo necesario. En 2026, la respuesta no es uno u otro: RAG recupera la evidencia relevante, una ventana de contexto larga puede refinar sobre ella, y una capa de enrutamiento decide qué camino toma cada consulta.
La decisión suele reducirse al costo. Dado que un LLM factura por cada token de entrada en cada solicitud, introducir un corpus completo en el contexto es costoso a escala. Para bases de conocimiento grandes bajo una carga de consultas constante, RAG puede ser del orden de 1,250× más barato por consulta que el relleno de contexto largo, ya que paga por unos pocos miles de tokens recuperados en lugar de por todo el archivo cada vez. 3
Esa ventaja es condicional y vale la pena expresarla honestamente: RAG gana en costo 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 almacenamiento en caché de prompts a menudo gana de forma absoluta, porque el costo fijo de alojamiento de la base de datos vectorial por sí solo puede superar toda la factura del contexto largo. 4 Nuestro modelo de dimensionamiento expresa ese límite en términos concretos. Un corpus de 2 GB en fragmentos de 512 tokens se convierte en aproximadamente 1.15M de vectores, lo que necesita 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 aún favorece la recuperación para búsquedas de aguja en un pajar, donde filtrar el texto irrelevante reduce la deriva de atención “perdido en el medio” que degrada el recuerdo en contextos largos.
¿Cuáles son los modelos y herramientas de RAG disponibles?
Las herramientas de RAG se dividen en tres grupos: LLMs y APIs con fundamentación integrada, frameworks de orquestación y los componentes de recuperación subyacentes (modelos de embedding, bases de datos vectoriales, rerankers).
LLMs y APIs con fundamentación integrada
Varios proveedores de modelos ahora ofrecen funciones de generación fundamentada para que pueda adjuntar conocimiento externo con atribución de fuente:
- Anthropic Claude: una API de Citations que fundamenta las respuestas en los documentos que usted proporciona y devuelve referencias a los pasajes exactos utilizados. 5
- Google Gemini: una herramienta de búsqueda de archivos integrada que maneja RAG por usted (cargue documentos y Gemini los fragmenta, incrusta y recupera en el momento de la consulta), además de Vertex IA RAG Engine para recuperación empresarial gestionada. Su función separada de “grounding con la Búsqueda de Google” obtiene información de la web en vivo, no de sus propios datos. 6
- Cohere Command: modelos ajustados para RAG (Command R/R+ y el más reciente Command A) que devuelven citas en línea de forma inmediata, emparejados con un endpoint Rerank dedicado. 7
- OpenAI: una herramienta de búsqueda de archivos en las APIs de Assistants y Responses. 8
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 agentivos con estado de recuperación-reflexión-verificación.
- LlamaIndex: ingesta de datos, indexación y motores de consulta.
- Haystack: pipelines de extremo a extremo para búsqueda y respuesta a preguntas.
- DSPy: programas declarativos de recuperación/prompts impulsados por optimización.
Para una comparación más profunda, consulte 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 le 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 necesidad de reentrenar el modelo.
¿Cómo funcionan los modelos RAG?
En esencia, RAG se ejecuta en dos fases: recuperación (encontrar los pasajes relevantes para la consulta) y generación (escribir una respuesta condicionada a esos pasajes). En sistemas de producción, ese bucle central se envuelve en un pipeline más completo:
- Reescritura/descomposición de la consulta: reformular o dividir la pregunta para recuperar mejor, especialmente para consultas de múltiples turnos o múltiples saltos.
- Recuperación híbrida: ejecutar búsquedas densas (vectoriales) y dispersas (BM25) y fusionar los resultados con RRF.
- Reordenamiento (Reranking): un cross-encoder vuelve a puntuar los candidatos y se queda con los mejores.
- Ensamblaje del contexto: construir el prompt a partir de los fragmentos seleccionados con citas.
- Generación: el LLM responde a partir del contexto ensamblado.
- Evaluación: puntuar la calidad de la recuperación y 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 diferentes tipos de RAG?
Más allá del pipeline lineal, varias variantes de RAG apuntan a modos de fallo específicos: RAG especulativo (borrador y verificación para velocidad), Retrieval-Augmented Fine-Tuning (RAFT) (entrenar al modelo para que use el contexto recuperado), Self-RAG y RAG correctivo (CRAG) (el modelo critica y vuelve a recuperar cuando la evidencia es débil). Estas se superponen con las arquitecturas avanzadas a continuación.
Arquitecturas avanzadas de RAG
RAG basado en grafos (GraphRAG)
GraphRAG construye un grafo de conocimiento sobre el corpus, a menudo en una base de datos de grafos dedicada como Neo4j o FalkorDB, para que el sistema pueda responder preguntas de múltiples saltos y de agregación global que la búsqueda vectorial plana no alcanza. Su ventaja en esas preguntas proviene en gran medida de precomputar relaciones en todo el corpus en lugar de una mejor recuperación de pasajes, por lo que la búsqueda vectorial aún tiende a ganar en búsquedas de documentos específicos. La conclusión práctica: recurra a un grafo cuando las consultas requieran razonamiento global a través de muchos documentos, no como un reemplazo directo de la recuperación vectorial.
RAG agentivo
El RAG agentivo pone a un agente LLM a cargo de la recuperación: decidir qué obtener, a qué fuente o herramienta llamar, y cuándo reflexionar y reintentar, iterando hasta que la respuesta esté fundamentada. En nuestro benchmark de RAG agentivo, 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 fuertes ahora enrutan casi a la perfección (Claude Opus 4.8 al 100%, Fable 5 al 98%), mientras que escribir SQL correcto contra el esquema elegido sigue siendo el techo más difícil, llegando a un máximo de alrededor del 90%. El enrutamiento está casi resuelto; la ejecución fundamentada es donde el RAG agentivo aún se diferencia.
RAG híbrido, iterativo y activo
La recuperación híbrida (densa + dispersa, cubierta anteriormente) es ahora la opción predeterminada en lugar de una opción avanzada. Las variantes iterativas y activas (por ejemplo, FLARE) permiten que el modelo recupere repetidamente a medida que genera, obteniendo nueva evidencia cuando su confianza disminuye.
Añadir como fuente preferidaCómo evaluar sistemas RAG
La evaluación de RAG ahora se estructura en ciclos de vida a través de tres capas: recuperación (precisión, exhaustividad, 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 iteración rápida y libre de referencias durante el desarrollo; DeepEval como una puerta de aprobación/rechazo estilo pytest en CI para que una regresión bloquee la compilación; y TruLens o Phoenix para el seguimiento y monitoreo en producción. TREC-RAG y ARES son referencias externas útiles para la calibración de jueces. 9
Las métricas de recuperación se dividen en dos una vez que una base de datos vectorial está en el circuito, y las mitades pueden moverse en direcciones opuestas. El recall ANN pregunta si el índice devolvió los verdaderos vectores más cercanos, lo que aísla la base de datos; nDCG y MRR frente a etiquetas humanas preguntan si esos documentos son relevantes, lo que es principalmente una propiedad del modelo de embedding. Escalar un corpus de 50k a 2.25M de 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 aún informaron un Recall@10 superior a 0.973, y el oráculo exacto de kNN cayó al mismo 0.572. Un benchmark puramente geométrico habría informado un índice saludable sobre un corpus que había perdido un tercio de su calidad de respuesta.
Tamaño de fragmento (chunk size)
El tamaño del fragmento controla cómo se dividen los documentos antes del embedding.
La guía de 2026 ha ido más allá de un único tamaño fijo: prefiera la fragmentación semántica / consciente de la estructura (comience un nuevo fragmento donde las oraciones adyacentes divergen en significado), mantenga los fragmentos alrededor de 300–500 tokens con un solapamiento del 10–20%, y considere la recuperación contextual: la técnica de Anthropic de anteponer una oración de contexto generada por un LLM a cada fragmento antes del embedding y la indexación BM25. En las pruebas de Anthropic, los embeddings contextuales redujeron la tasa de fallos de recuperación en el top-20 en un 35%, los embeddings contextuales más BM25 contextual en un 49%, y añadir un reranker encima en un 67%. 10 El tamaño del fragmento también determina el tamaño del í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 configuración predeterminada de fragmentos de 512 tokens y un solapamiento del 15%, el corpus avanza 435 tokens por fragmento, por lo que reducir el fragmento a la mitad duplica aproximadamente tanto el recuento de vectores como la memoria que la base de datos debe mantener.
Fine-Tuning vs. Generación Aumentada por Recuperación
RAG y el fine-tuning resuelven problemas diferentes, y en 2026 se utilizan cada vez más juntos en lugar de como alternativas.
Para la mayoría de los equipos, la respuesta es “RAG primero, ajuste el comportamiento con fine-tuning si es necesario”, 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 actualidad (las respuestas reflejan datos actuales y fundamentados en fuentes, no un corte de entrenamiento congelado), transparencia (las respuestas citan los pasajes que utilizaron, por lo que son auditables), menor costo que el contexto largo a escala, y adaptabilidad (actualice la base de conocimiento en lugar de reentrenar el modelo). El RAG multimodal extiende estos beneficios a imágenes, PDFs y tablas.
Lecturas adicionales
- Benchmark de modelos de embedding
- Benchmark de rerankers
- Benchmark de bases de datos vectoriales de código abierto
- Calculadora de dimensionamiento de bases de datos vectoriales
- Modelos de embedding de código abierto
- Modelos de embedding multilingües
- Embeddings multimodales
- Frameworks de RAG agentivo
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 herramientas, frameworks y bibliotecas de RAG}},
year = {2026},
month = jul,
howpublished = {\url{https://aimultiple.com/retrieval-augmented-generation}},
note = {AIMultiple. Recuperado el 18 de Julio de 2026}
}Enlaces de referencia
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.