Mejores herramientas, frameworks y librerías de RAG
RAG mejora las respuestas de los LLM al fundamentarlas en datos externos en lugar de solo 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, 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 del benchmark 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 límite máximo de calidad de la recuperación.
Evaluamos 15 modelos de embedding denso más una línea base léxica BM25 en tres dominios (contratos legales/CUAD, soporte al cliente/TechQA y salud/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 más grande no es automáticamente la mejor compra. Para stacks donde el coste 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 costes 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 un solo vector, los recuperadores de interacción tardía (multivector) como ColBERT (y ColPali/ColQwen para 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, con 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 colocó a DFN5B-H de Apple en primer lugar con un 50.1% de Recall@1 texto-a-imagen. 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 de Microsoft con licencia MIT como la mejor opción comercial sin restricciones.
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 colocar los fragmentos verdaderamente relevantes en las primeras posiciones antes de que lleguen al LLM. El pipeline canónico de 2026 consiste en recuperar un conjunto amplio, hacer rerank 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 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 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 suelo de latencia y una gran parte del coste operativo. Evaluamos seis servicios gestionados en un conjunto de datos de 1 millón de vectores de 768 dimensiones, midiendo la latencia promedio de consulta y el coste mensual.
No hay un único ganador, sino una frontera de latencia/coste. Zilliz Cloud fue el más rápido (26 ms) y Qdrant le siguió de cerca (39 ms), mientras que Pinecone fue el más barato a $60/100GB pero también el más lento (102 ms), y MongoDB Atlas fue el más caro por un amplio margen ($1,440/100GB). Los seis ahora admiten búsqueda híbrida nativa (vectores densos más emparejamiento por palabras clave BM25), con Reciprocal Rank Fusion (RRF) como la forma predeterminada de fusionar las dos listas de resultados. El benchmark completo de bases de datos vectoriales incluye la matriz de soporte híbrido y una calculadora de almacenamiento.
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 10–20% de solapamiento; prefiera la división semántica o consciente de la estructura sobre 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 necesita autoalojar; elija un modelo multilingüe o multimodal si su corpus lo requiere.
- Base de datos vectorial: Zilliz/Qdrant cuando la latencia sea prioritaria; Pinecone o Elasticsearch cuando el coste sea prioritario; cualquiera de los seis si necesita búsqueda híbrida nativa.
- Recuperación híbrida: combine denso + BM25 con RRF; es el valor predeterminado de 2026 porque la recuperación léxica y semántica fallan en consultas diferentes, por lo que fusionarlas es más fiable que cualquiera de las dos por separado.
- 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: use un modelo con soporte de citación fundamentada, para que las respuestas sean atribuibles a fuentes.
- Evaluación: incorpore métricas de recuperación, generación y extremo a extremo antes de poner el sistema en producción.
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 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 guardrail de entrada/salida y respete las restricciones de residencia de datos. Considere estos como requisitos mínimos, no como complementos, para cualquier sistema RAG que maneje datos internos.2
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 una cosa o la otra: 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 generalmente se reduce al coste. Dado que un LLM cobra por cada token de entrada en cada solicitud, introducir un corpus completo en el contexto es caro a escala. Para bases de conocimiento grandes bajo una carga de consultas constante, RAG puede ejecutarse en el orden de 1,250× más barato por consulta que el uso de contexto largo, ya que paga por unos pocos miles de tokens recuperados en lugar de todo el archivo cada vez.3
Esa ventaja es condicional y merece ser expuesta 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 almacenamiento en caché de prompts a menudo gana de forma contundente, porque el coste fijo de alojamiento de la base de datos vectorial por sí solo puede superar toda la factura del contexto largo.4 La precisión sigue favoreciendo la recuperación para búsquedas de "aguja en un pajar", donde filtrar texto irrelevante reduce la deriva de atención de "perdido en el medio" que degrada el recall en contextos largos.
¿Qué modelos y herramientas de RAG están disponibles?
Las herramientas de RAG se dividen en tres grupos: LLMs y APIs con fundamentación incorporada, 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 incorporada
Varios proveedores de modelos ahora ofrecen funciones de generación fundamentada para que pueda adjuntar conocimiento externo con atribución de fuentes:
- 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 integrada de File Search que gestiona RAG por usted (cargue documentos y Gemini los fragmenta, 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 "fundamentación con Google Search" 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 fábrica, emparejados con un endpoint Rerank dedicado.7
- OpenAI: una herramienta de búsqueda de archivos (file-search) en las APIs de Assistants y Responses.8
Librerías 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 con estado y agénticos de recuperar-reflexionar-verificar.
- 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 prompts/recuperación impulsados por optimizador.
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 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 de 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 por 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 en 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.
- Reranking: un cross-encoder vuelve a puntuar los candidatos y conserva los mejores.
- Ensamblaje de 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 usar contexto recuperado), Self-RAG y RAG correctivo (CRAG) (el modelo critica y vuelve a recuperar cuando la evidencia es débil). Estos se solapan con las arquitecturas avanzadas a continuación.
Añadir como fuente preferidaArquitecturas 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 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 sigue tendiendo 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 agéntico
El RAG agéntico pone a un agente LLM a cargo de la recuperación: decidir qué obtener, qué fuente o herramienta llamar, y cuándo reflexionar y reintentar, iterando 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 perfectamente (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, alcanzando un máximo de alrededor del 90%. El enrutamiento está casi resuelto; la ejecución fundamentada es donde el RAG agéntico aún se diferencia.
RAG híbrido, iterativo y activo
La recuperación híbrida (densa + dispersa, tratada anteriormente) es ahora el valor predeterminado 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.
Cómo evaluar sistemas de RAG
La evaluación de RAG ahora está estructurada por ciclo de vida en tres capas: recuperación (precisión, recall, MRR, nDCG, hit@k: ¿recuperamos los fragmentos correctos?), generación (fundamentación, fidelidad: ¿está la respuesta respaldada por el contexto recuperado?) y 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 puerta de aprobado/fallo al estilo pytest en CI para que una regresión bloquee la compilación; y TruLens o Phoenix para trazabilidad y monitorización en producción. TREC-RAG y ARES son referencias externas útiles para la calibración de jueces.9
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: prefiera la fragmentación semántica / consciente de la estructura (inicie un nuevo fragmento donde las oraciones adyacentes diverjan en significado), mantenga los fragmentos alrededor de 300–500 tokens con un 10–20% de solapamiento, 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 fallo 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
Fine-Tuning frente a generación aumentada por recuperación
RAG y el fine-tuning resuelven problemas diferentes, 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 "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 frescura (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 coste que el contexto largo a escala, y adaptabilidad (actualice la base de conocimiento en lugar de reentrenar el modelo). El RAG multimodal extiende estas ventajas a imágenes, PDFs y tablas.
Lecturas adicionales
- Benchmark de modelos de embedding
- Benchmark de rerankers
- Base de datos vectorial para RAG
- Modelos de embedding de código abierto
- 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{sar2026,
author = {Sarı, Ekrem},
title = {{Mejores herramientas, frameworks y librerías de RAG}},
year = {2026},
month = jun,
howpublished = {\url{https://aimultiple.com/retrieval-augmented-generation}},
note = {AIMultiple. Recuperado el 30 de Junio 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.