Índice
- 1. Repaso: los límites del RAG ingenuo
- 2. El pipeline de RAG moderno de un vistazo
- 3. ① Chunking (lo más importante)
- 4. ② Elegir un modelo de embedding
- 5. ③ Elegir una vector DB (comparativa)
- 6. ④ Búsqueda híbrida (BM25 + vector)
- 7. ⑤ Reranking (retrieve-then-rerank)
- 8. Frameworks (LlamaIndex/LangChain)
- 9. RAG frente a contexto largo
- 10. Precauciones para producción
- Resumen
- FAQ
Ya entiendes qué es RAG. Pero cuando realmente construyes uno, mucha gente choca contra un muro: "más o menos funciona, pero la respuesta clave no es correcta." La causa casi siempre es la misma: sigue siendo "RAG ingenuo": trocear el documento descuidadamente y hacer una simple búsqueda vectorial.
El RAG práctico en 2026 ha superado claramente eso. Las claves están en un pipeline de varias etapas: "chunking inteligente → el embedding adecuado → búsqueda híbrida (palabras clave + vector) → reranking." Como continuación de implementación del artículo 030, esto cubre el cómo concreto de cada etapa, la elección de una vector DB (Chroma/pgvector/Qdrant/Pinecone/Weaviate/Milvus), los frameworks e incluso "¿seguimos necesitando RAG en la era del millón de tokens?": lo esencial de una implementación más avanzada.
Las 5 etapas del RAG moderno
— del RAG ingenuo al RAG que funciona en producción
Las dos mayores mejoras de precisión: búsqueda híbrida (BM25 + vector) y reranking.
Solo con añadir estas dos se corrige en gran medida el problema del RAG ingenuo de "la respuesta no es correcta".
* Los nombres de herramientas, los métodos y las cifras de benchmark se basan en fuentes oficiales y varios medios técnicos (a fecha de 2026). Este ámbito evoluciona rápido y las mejores opciones cambian. Las cifras de benchmark son las reportadas por las fuentes y varían según los datos y las condiciones. Evalúa con tus propios datos (más abajo) antes de elegir.
1. Repaso: los límites del RAG ingenuo
El RAG mínimo es "dividir el documento → vectorizar con embeddings → guardar en una vector DB → vectorizar la pregunta y recuperar los chunks más cercanos → pasarlos al LLM para responder." Eso son los fundamentos de RAG. Pero este "RAG ingenuo" tiene debilidades típicas.
- Chunks descuidados: cortados a mitad de frase, rompiendo el significado.
- Solo búsqueda vectorial: débil con términos exactos como nombres de producto o números de modelo (capta o pierde cosas semánticamente cercanas pero léxicamente distintas).
- Pasar los N primeros tal cual: los elementos realmente más relevantes quedan enterrados.
El RAG práctico en 2026 aplasta estos tres problemas con "división inteligente", "búsqueda híbrida" y "reranking". Vamos por orden.
2. El pipeline de RAG moderno de un vistazo
El flujo de datos de un RAG en producción tiene dos vías: preparación (indexación) y tiempo de consulta (búsqueda y generación).
Dos fases
Preparación (offline): dividir el documento en chunks con criterio → vectorizar con embeddings → guardar en una vector DB (construir al mismo tiempo un índice de palabras clave).
Tiempo de consulta (online): recuperar los 50-100 primeros con búsqueda híbrida (BM25 + vector) → reducir a unos pocos con reranking → pasar al LLM para generar la respuesta.
La diferencia con el RAG ingenuo está en si existen "④ la búsqueda híbrida" y "⑤ el reranking". Estas dos etapas elevan la precisión de búsqueda a un nivel práctico.
3. ① Chunking (lo más importante)
Es justo decir que el chunking decide la mitad de la calidad del RAG. Estas son las estrategias principales.
| Estrategia | Qué hace | Indicado para |
|---|---|---|
| recursive 512 tokens | Un valor por defecto pragmático. Reportada como nº 1 de 7 estrategias en un benchmark de feb. 2026 | En caso de duda, esta |
| semantic | Divide donde cambia el significado, para que cada chunk sea coherente temáticamente | Documentos técnicos densos |
| structural | Respeta encabezados, bloques de código y secciones HTML | Documentación y código |
| parent-child (jerárquico) | Busca con precisión sobre chunks pequeños; devuelve el chunk padre circundante al responder | Equilibrar precisión y contexto |
Si el problema es la pérdida de contexto en los límites, ayudan Contextual Retrieval (adjuntar el contexto del documento completo a cada chunk) o Late Chunking. Anthropic reporta que Contextual Retrieval + reranking redujeron los fallos de recuperación del top-20 hasta un 67% (una cifra reportada). El orden realista: empieza con "recursive 512" y añade semantic / parent-child / Contextual Retrieval si la precisión se queda corta.
4. ② Elegir un modelo de embedding
El modelo de embedding convierte los chunks en vectores: la base de la precisión de búsqueda.
- Valor por defecto seguro: OpenAI text-embedding-3-large. Un buen equilibrio entre calidad de recuperación y facilidad de integración.
- Otras opciones: embeddings de Cohere, Voyage, Gemini y varios modelos OSS.
- Importante: muchos embeddings OSS son de sobra suficientes para producción cuando se combinan con búsqueda híbrida + reranking. No te obsesiones solo con el embedding.
La clave es tratar "el embedding como una parte del pipeline de búsqueda completo". En lugar de cambiar a un embedding caro, añadir búsqueda híbrida y reranking suele ser más rentable.
5. ③ Elegir una vector DB (comparativa)
La vector DB almacena y busca vectores. Estos son los líderes de 2026 según su carácter.
| DB | Carácter / fortaleza | Para quién es |
|---|---|---|
| Chroma | AI-native, local-first, API de Python sencilla | Individuos/PoCs que prototipan RAG lo más rápido posible |
| pgvector | Una extensión de Postgres. Sin una segunda DB, consistencia transaccional | Equipos que ya usan Postgres |
| Qdrant | Baja latencia (p50 ~4ms; reportado frente a Milvus ~6ms / Pinecone ~8ms) | Enfocados en velocidad, producción |
| Pinecone | Totalmente gestionado. Cero infraestructura, empiezas solo con una API key | Quieren delegar la operación, cloud-first |
| Weaviate | Campeón de búsqueda híbrida (BM25 + vector + metadatos en una sola consulta) | Usuarios intensivos de búsqueda híbrida |
| Milvus | De nivel empresarial, maneja miles de millones de vectores | Escala muy grande |
Ejes de selección: "escala, gestionado frente a self-hosted, stack existente, presupuesto". En caso de duda: Chroma para prototipar, pgvector si tienes Postgres, Qdrant/Pinecone para una producción equilibrada, Weaviate si abusas de la búsqueda híbrida. Para la mayoría de cargas de RAG, Pinecone / Weaviate / Qdrant se consideran opciones sólidas.
6. ④ Búsqueda híbrida (BM25 + vector)
Lo que corrige la mayor debilidad del RAG ingenuo —ser débil con términos exactos— es la búsqueda híbrida. Fusiona BM25 (búsqueda por palabras clave/léxica) con la búsqueda vectorial densa.
Fusiona léxico + semántico
Fusionar ambos con Reciprocal Rank Fusion (RRF) se reporta que
supera de forma consistente a cualquiera de los dos enfoques por separado (mayor NDCG).
En la práctica, lo más fácil es usar una DB que devuelva resultados híbridos en una sola consulta, como Weaviate. Deja el complicado ajuste de puntuaciones a RRF (fusión basada en rankings) y no se romperá. El resultado: una búsqueda fuerte tanto con términos exactos como con paráfrasis.
7. ⑤ Reranking (retrieve-then-rerank)
El estándar de 2026 es "dos etapas: recuperar ampliamente primero → luego acotar (rerank)".
- Etapa 1 (retrieve): recupera los 50-100 primeros rápidamente con un bi-encoder (embeddings).
- Etapa 2 (rerank): con un cross-encoder, puntúa (pregunta, chunk) de forma conjunta y reduce a los pocos realmente más relevantes.
Los rerankers populares son Cohere Rerank 3.5, Voyage rerank-2.5, BGE reranker-v2, Jina Reranker v2. El reranking añade unos 50-200ms de latencia y coste, pero como los chunks que se pasan al LLM se reducen a unos pocos seleccionados, a menudo reduce el consumo de tokens del LLM y baja el coste total. Tanto en precisión como en coste, el reranking se está convirtiendo en una etapa que "no hay razón para no añadir".
8. Frameworks (LlamaIndex/LangChain)
Usar un framework es más rápido que escribirlo todo tú mismo. Este es el reparto de tareas en 2026.
- LlamaIndex: enfocado en la recuperación. Fuerte en indexación de documentos, calidad de búsqueda e iteración rápida de RAG.
- LangChain / LangGraph: el lado de la orquestación (control). Flujos de trabajo complejos y coordinación de agentes.
- Patrón combinado: en la práctica, muchos usan LlamaIndex como capa de recuperación y LangGraph como capa de control.
Ten en cuenta que últimamente, con la estandarización de herramientas mediante MCP y el auge de los Agent SDKs, hay una tendencia de agentes que construyen pipelines sobre la marcha sin frameworks pesados de LLM. Aun así, si estás puliendo la calidad de búsqueda, la familia LlamaIndex sigue siendo fuerte. Para la construcción de agentes en general, consulta cómo construir un agente de IA.
9. RAG frente a contexto largo
"Con una ventana de contexto de 1M de tokens, ¿no puedo simplemente meterlo todo y saltarme el RAG?": una pregunta común. La respuesta es "no, el RAG no queda reemplazado".
La trampa del "métele todo"
- Ineficiente en tokens: enviar cada vez un contexto enorme y redundante es costoso.
- Lost in the middle: la información en mitad de un texto largo tiende a ignorarse.
- Distracción: cuanta más información irrelevante, menor calidad de la respuesta.
La pauta: usa contexto largo para corpus pequeños e iteración rápida, añade pronto prompt caching para un contexto repetido y estable, y añade RAG en cuanto "frescura, escala, procedencia" se conviertan en requisitos. "Solo métele todo en la ventana de contexto" es el nuevo "solo añade una vector DB": no es una panacea. Combina esto con una comprensión de la ventana de contexto.
10. Precauciones para producción
- Construye primero una evaluación: "más o menos mejoró" no se puede mejorar. Cuantifica la precisión de recuperación con un conjunto de preguntas representativas × fuentes esperadas y compara por cada cambio.
- Monitorización: vigila de forma continua la tasa de aciertos de recuperación, la relevancia tras el rerank y el grounding de la respuesta.
- Diseño de costes: la facturación viene de los embeddings, el reranking y el LLM. Recortar tokens del LLM mediante el reranking es el ahorro de costes estándar. Consulta ahorro de tokens.
- Frescura y procedencia: diseña para reflejar las actualizaciones de datos (reindexación) y adjuntar siempre la fuente (qué documento) a las respuestas: clave para combatir las alucinaciones.
- Datos confidenciales: ten cuidado al vectorizar documentos internos y alojarlos en el exterior. Consulta las directrices de uso corporativo de IA.
Resumen
El RAG práctico ha evolucionado del ingenuo "trocear y buscar por vector" a un pipeline de varias etapas: "chunking inteligente → embedding → vector DB → búsqueda híbrida → reranking". Las dos mayores mejoras de precisión son la búsqueda híbrida (fusionar BM25 + vector con RRF) y el reranking (retrieve-then-rerank): solo con añadir estas dos se corrige en gran medida "la respuesta no es correcta".
Para las vector DB: Chroma para prototipar, pgvector si tienes Postgres, Qdrant/Pinecone para producción, Weaviate si abusas de la híbrida. Para los frameworks: LlamaIndex para recuperación, LangChain/LangGraph para control. Y incluso con 1M de tokens, el RAG no queda reemplazado: si necesitas frescura, escala y procedencia, es RAG. Un último imprescindible: "construye primero el conjunto de evaluación". No puedes mejorar lo que no puedes medir. Mantén eso y tu RAG evolucionará de forma fiable de "más o menos funciona" a "funciona en producción".
Lectura relacionada: qué es RAG (fundamentos), qué es una ventana de contexto, cómo construir un agente de IA, Claude Agent SDK y qué es MCP.
FAQ
P. La precisión de mi RAG es baja. ¿Qué debería arreglar primero?
R. Añadir las dos cosas —"búsqueda híbrida" y "reranking"— es lo más efectivo. La simple búsqueda vectorial por sí sola es débil con términos exactos como números de modelo y nombres propios, y los chunks más relevantes quedan enterrados. Fusionar con BM25 (vía RRF) + un rerank con cross-encoder eleva la calidad de búsqueda a un nivel práctico. Si aun así no basta, revisa tu chunking.
P. ¿Qué vector DB debería elegir?
R. Chroma para prototipar, pgvector si ya tienes Postgres son los comienzos fáciles. Para una producción equilibrada, Qdrant (baja latencia) o Pinecone (totalmente gestionado); para búsqueda híbrida intensiva, Weaviate; para escala muy grande, Milvus. Elige según la escala, la preferencia de operación, el stack existente y el presupuesto.
P. ¿Qué tamaño de chunk es bueno?
R. Alrededor de 512 tokens con división recursiva es un valor por defecto pragmático (reportado cerca de lo más alto en los benchmarks de 2026). Para documentos técnicos, semantic (dividir por significado); para documentación/código, structural (respetar encabezados/código); para precisión más contexto, parent-child. Empieza en 512 y ajusta mientras evalúas.
P. Con una ventana de 1M de tokens, ¿no es innecesario el RAG?
R. No se vuelve innecesario. Meterlo todo en el contexto baja la calidad por la ineficiencia de tokens, el "lost in the middle" y la distracción. Usa contexto largo para corpus pequeños y prototipos, y RAG en cuanto la frescura, la escala y la procedencia sean requisitos: ese es el reparto realista.
P. ¿LangChain o LlamaIndex, cuál debería usar?
R. LlamaIndex si estás puliendo la calidad de búsqueda; LangChain/LangGraph para el control complejo y la coordinación de agentes. En la práctica, muchos los combinan: "LlamaIndex como capa de recuperación, LangGraph como capa de control". Últimamente también hay una tendencia a ensamblar de forma ligera con Agent SDKs, así que elige según tus requisitos.
