RAG: qué es y cómo funciona

Piensa en la diferencia entre un estudiante que responde de memoria (LLM normal) y uno que puede consultar sus apuntes antes de responder (LLM con RAG). El segundo es más preciso, más actualizado y puede citar fuentes.

Cómo funciona paso a paso

El flujo de RAG tiene tres fases:

1. Indexación (una vez): tus documentos se dividen en fragmentos (chunks), se convierten en vectores numéricos (embeddings) y se almacenan en una base de datos vectorial.

2. Recuperación (cada consulta): cuando el usuario hace una pregunta, esa pregunta se convierte en un vector y se buscan los fragmentos más similares en la base de datos.

3. Generación (cada consulta): los fragmentos recuperados se pasan como contexto al LLM junto con la pregunta original. El modelo genera una respuesta basada en esa información.

# Flujo simplificado de RAG
1. INDEXACIÓN (offline)
 Documentos → Chunking → Embeddings → Vector DB

2. CONSULTA (runtime)
 Pregunta usuario → Embedding → Búsqueda similar → Top-K chunks

3. GENERACIÓN (runtime)
 System prompt + Chunks relevantes + Pregunta → LLM → Respuesta

Embeddings explicados de forma simple

Los embeddings son el corazón de RAG. Imagina que cada frase de texto se convierte en un punto en un espacio de muchas dimensiones (768, 1024, o hasta 3072 dimensiones). Frases con significado similar terminan como puntos cercanos entre sí.

Ejemplo intuitivo:

• "El gato duerme en el sofá" y "El felino descansa en el sillón" estarán muy cerca en el espacio vectorial (mismo significado).
• "El gato duerme en el sofá" y "La economía creció un 3% este trimestre" estarán lejos (significados distintos).

Esto permite buscar por significado en lugar de por palabras exactas. Si preguntas "mascota descansando", encontrará el fragmento sobre el gato durmiendo aunque no comparta ninguna palabra.

Modelos de embedding populares en 2026:

• text-embedding-3-small (OpenAI): 1536 dimensiones, buena calidad, bajo coste (0.02 USD por 1M tokens). El más usado por su equilibrio calidad/precio.
• text-embedding-3-large (OpenAI): 3072 dimensiones, máxima calidad cloud. Para cuando necesitas la mejor precisión posible.
• embed-v3 (Cohere): Multilingüe nativo, excelente para español. Gratis hasta 100 llamadas/minuto en el plan trial.
• BGE-M3 (BAAI, open source): Ejecutable localmente. Multilingüe. Gratis total si tienes GPU. La mejor opción soberana.
• nomic-embed-text (open source): Ligero, funciona en CPU. Perfecto para prototipado rápido con Ollama.

Consideración clave: el modelo de embedding debe ser el mismo para indexar y para buscar. Si indexas con text-embedding-3-small, debes buscar con el mismo modelo. Cambiar de modelo requiere re-indexar todos los documentos.

Estrategias de chunking

Cómo divides tus documentos en fragmentos es la decisión más importante de un pipeline RAG (y la más infravalorada). Un mal chunking arruina todo lo demás.

Chunking por tamaño fijo

Divide cada X caracteres con overlap. Simple pero tosco. Puede cortar frases a mitad. Útil como baseline.

# Ejemplo: chunks de 500 caracteres con 100 de overlap
splitter = RecursiveCharacterTextSplitter(
    chunk_size=500, chunk_overlap=100
)

Chunking recursivo (el más usado)

Intenta dividir por párrafos, luego por frases, luego por caracteres. Respeta la estructura del texto. Es el default de LangChain y funciona bien para el 80% de los documentos.

Chunking semántico

Usa embeddings para detectar cambios de tema y divide ahí. Más costoso computacionalmente, pero produce chunks con coherencia temática. Ideal para documentos largos con múltiples temas.

Chunking por estructura

Divide por headers (H1, H2, H3), secciones de Markdown, o estructura del documento. Ideal para documentación técnica, wikis y manuales que ya están bien estructurados.

Regla práctica: empieza con chunks de 500-1000 tokens con 10-20% de overlap. Si la recuperación es mala, experimenta con tamaños más pequeños (200-500) para documentos densos o más grandes (1000-2000) para documentos narrativos.

Opciones de vector store

La base de datos vectorial almacena tus embeddings y permite buscar por similitud. Las opciones principales en 2026:

Para empezar (gratis/simple):

• ChromaDB: Base de datos vectorial embebida. Se instala con pip, funciona en memoria o en disco. Perfecta para prototipado y proyectos pequeños (menos de 100K documentos). Sin servidor, sin configuración.
• pgvector (PostgreSQL): Extensión de PostgreSQL para vectores. Si ya usas PostgreSQL (Supabase, RDS), añadir vectores es trivial. Excelente para no añadir otra base de datos a tu stack.
• SQLite-VSS: Vectores en SQLite. Ultra-ligero, ideal para aplicaciones de escritorio o prototipos.

Para producción (escalables):

• Qdrant: Self-hosted o cloud. Rápido, filtros avanzados, API REST clara. Nuestra elección para producción. Plan cloud gratuito con 1 GB de almacenamiento.
• Pinecone: Serverless, escala automática. Plan gratuito generoso (100K vectores). La opción más fácil para producción sin gestionar infraestructura.
• Weaviate: Hybrid search (vectorial + keyword). Bueno si necesitas combinar búsqueda semántica con búsqueda tradicional. Cloud y self-hosted.
• Milvus: El más escalable. Para millones de vectores. Más complejo de operar. Usado por grandes empresas.

Nuestra recomendación: ChromaDB para prototipos, pgvector si ya usas PostgreSQL/Supabase, Qdrant para producción self-hosted.

Pipeline RAG paso a paso

Un pipeline RAG completo de producción tiene más componentes que el flujo básico. Aquí está la versión realista:

# Pipeline RAG completo (producción)

1. INGESTA
   Documentos → Parsing (PDF, DOCX, HTML) → Limpieza de texto
   → Metadata extraction (fecha, autor, categoría)

2. PROCESAMIENTO
   Texto limpio → Chunking (estrategia elegida)
   → Embedding (batch processing)
   → Almacenamiento en vector DB + metadata

3. CONSULTA
   Pregunta → Query rewriting (opcional, mejora resultados)
   → Embedding de la pregunta
   → Búsqueda vectorial (top-K, típicamente K=4-8)
   → Re-ranking (opcional, reordena por relevancia)
   → Filtrado por metadata (fecha, categoría, permisos)

4. GENERACIÓN
   System prompt + Contexto recuperado + Pregunta
   → LLM → Respuesta + Citations

5. POST-PROCESAMIENTO
   Verificación de hallucinations → Formateo
   → Logging para evaluación

Query rewriting: antes de buscar, reformulas la pregunta para obtener mejores resultados. Ejemplo: "cuánto tardó?" se reescribe como "plazos de entrega del proyecto mencionado anteriormente". Un LLM pequeño puede hacer esto por ti.

Re-ranking: los resultados de la búsqueda vectorial no siempre están en el orden óptimo. Un modelo de re-ranking (como Cohere Rerank o BGE Reranker) reordena los resultados por relevancia real a la pregunta. Mejora significativamente la calidad.

Cuándo usar RAG

Usa RAG cuando: necesitas respuestas basadas en documentos específicos (manuales, contratos, base de conocimiento), los datos cambian frecuentemente (noticias, precios, inventario), necesitas citar fuentes, o quieres reducir alucinaciones del modelo.

No uses RAG cuando: la tarea es puramente creativa (escribir ficción), el conocimiento necesario es general y estable (gramática, matemáticas básicas), o tienes muy pocos documentos (menos de 10 páginas, mejor pásalos directamente en el prompt).

RAG vs fine-tuning: cómo decidir

La pregunta más frecuente. Para entender cuándo elegir cada uno, lee nuestra guía de fine-tuning: cuándo lo necesitas y cuándo no. Aquí está la decisión desgranada:

Elige RAG cuando:

• Los datos cambian frecuentemente (semanal o más a menudo)
• Necesitas respuestas con fuentes citables
• Tienes una base de conocimiento grande (100+ documentos)
• Quieres resultados rápido (implementación en horas, no semanas)
• El presupuesto es limitado (no quieres pagar GPU de entrenamiento)
• Necesitas multi-tenancy (cada usuario ve solo sus documentos)

Elige fine-tuning cuando:

• Necesitas un estilo o formato muy específico de respuesta
• El dominio es tan especializado que el modelo base no entiende la jerga
• Quieres reducir latencia (sin paso de recuperación)
• Tienes datos de entrenamiento de alta calidad (miles de pares pregunta-respuesta)
• El conocimiento es estable y no cambia a menudo

La opción híbrida (lo mejor de ambos): Fine-tune para el estilo y dominio base, RAG para los datos específicos y actualizados. Es la arquitectura que usamos en producción para nuestro módulo GRC: el modelo entiende la jerga de ciberseguridad (fine-tuning), y recupera normativas específicas del cliente (RAG).

Arquitectura básica

Los componentes de un sistema RAG son:

Document loader: lee PDFs, Word, HTML, Markdown, CSVs. Herramientas: LangChain loaders, Unstructured, LlamaIndex.

Chunker: divide documentos en fragmentos de 200-1000 tokens. Estrategias: por párrafos, por overlap, semántico.

Embedding model: convierte texto en vectores. Modelos: text-embedding-3-small (OpenAI), embed-v3 (Cohere), BGE (open source). Para entender los embeddings, lee sobre bases de datos vectoriales.

Vector database: almacena y busca vectores. Opciones: Qdrant, Pinecone, Weaviate, ChromaDB, pgvector.

LLM: genera la respuesta final. Cualquier LLM sirve: GPT-4o, Claude Sonnet, Llama, Qwen. Si no sabes cuál elegir, revisa qué LLM elegir.

Herramientas para implementar RAG

Sin código: ChatGPT con archivos adjuntos (RAG implícito), Claude Projects (sube documentos), Google NotebookLM (RAG automático sobre tus fuentes).

Low-code: n8n con nodos de vector store, Flowise (drag & drop RAG), Dify (plataforma RAG visual).

Con código: LangChain (Python/JS, el más popular), LlamaIndex (especializado en RAG), Haystack (pipeline-based). Para empezar con código, revisa el tutorial de LangChain en español.

Métricas de evaluación

Un RAG sin métricas es un RAG que no sabes si funciona. Las métricas clave:

Métricas de recuperación (el buscador):

• Recall@K: De los documentos relevantes totales, cuántos aparecen en tu top-K resultados. Si hay 3 chunks relevantes y recuperas 2 de 4, tu recall@4 es 66%.
• Precision@K: De los K documentos recuperados, cuántos son realmente relevantes. Si recuperas 4 chunks y 2 son relevantes, precision@4 es 50%.
• MRR (Mean Reciprocal Rank): En qué posición aparece el primer resultado relevante. Cuanto más arriba, mejor.

Métricas de generación (la respuesta):

• Faithfulness: La respuesta se basa en el contexto recuperado? O inventa información? Un RAG con faithfulness baja tiene alucinaciones.
• Relevance: La respuesta contesta realmente la pregunta del usuario?
• Completeness: La respuesta cubre toda la información disponible en los chunks recuperados?

Framework de evaluación recomendado: RAGAS (ragas.io). Es un framework open source que calcula automáticamente faithfulness, answer relevancy, context precision y context recall. Se integra con LangChain y LlamaIndex.

# Evaluación con RAGAS (ejemplo)
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_precision

result = evaluate(
    dataset,  # preguntas + respuestas + contextos
    metrics=[faithfulness, answer_relevancy, context_precision]
)
print(result)  # Scores de 0 a 1 por métrica

Errores comunes y cómo evitarlos

Chunks demasiado pequeños: pierden contexto. Un párrafo cortado a mitad no tiene sentido. Solución: usa overlap de 10-20% y chunking recursivo que respete límites de párrafo.

Chunks demasiado grandes: diluyen la relevancia. El modelo recibe mucho texto pero poco útil. Solución: si tus chunks superan los 1000 tokens, probablemente son demasiado grandes para la mayoría de consultas.

No evaluar la recuperación: si los chunks recuperados no son relevantes, la respuesta nunca será buena. Mide la precisión de la búsqueda antes de culpar al LLM. Solución: log los chunks recuperados y revisalos manualmente para tus primeras 50 consultas.

Ignorar el pre-procesamiento: PDFs escaneados, tablas complejas, imágenes con texto. Si el documento no se parsea bien, RAG falla. Solución: usa Unstructured.io o servicios de OCR antes de chunking.

No usar metadata: recuperar chunks sin filtrar por fecha, autor o categoría mezcla información obsoleta o irrelevante. Solución: siempre almacena metadata junto con el embedding y filtra cuando sea apropiado.

K demasiado alto: recuperar 20 chunks satura el contexto del LLM y diluye la señal. Solución: empieza con K=4, sube a K=6-8 solo si necesitas más cobertura. Más de 10 rara vez mejora los resultados.

Siguiente paso

Si nunca has implementado RAG, empieza con Claude Projects o NotebookLM (cero código). Sube 5-10 documentos y prueba a hacer preguntas. Cuando entiendas el concepto, pasa a LangChain para implementaciones personalizadas.

En IAcademy cubrimos RAG en profundidad: desde el concepto hasta la implementación con código.

Preguntas frecuentes

RAG funciona bien con documentos en español?

Sí, siempre que uses un modelo de embedding multilingüe. text-embedding-3-small (OpenAI), embed-v3 (Cohere) y BGE-M3 soportan español con buena calidad. Evita modelos entrenados solo en inglés.

Cuántos documentos puede manejar un sistema RAG?

No hay límite práctico. ChromaDB gestiona cientos de miles de chunks. Qdrant y Pinecone escalan a millones. La latencia de búsqueda se mantiene en milisegundos incluso con millones de vectores (búsqueda aproximada, HNSW).

RAG puede trabajar con imágenes o solo texto?

RAG multimodal es posible con modelos de embedding que soportan imágenes (CLIP, Jina CLIP). Puedes indexar imágenes, diagramas y capturas de pantalla. También puedes usar OCR para extraer texto de imágenes antes de indexar.