RAG

Definición

RAG (Retrieval Augmented Generation) es un patrón arquitectónico que combina un LLM con un sistema de recuperación de información. Antes de que el modelo genere una respuesta, el sistema busca en una base de conocimiento externa los fragmentos más relevantes para la pregunta y los inyecta en el contexto del prompt. El modelo responde basándose en ese contexto recuperado, no solo en lo que sabe de su entrenamiento.

Es probablemente el patrón más usado en producción real con LLMs hoy. Permite a un modelo:

• Responder con información actualizada (posterior a su corte de entrenamiento).
• Acceder a datos privados de la empresa que no estaban en su entrenamiento.
• Citar fuentes verificables, reduciendo alucinaciones.
• Trabajar sobre corpus enormes (millones de documentos) sin necesidad de fine-tuning.

Cualquier asistente serio que "responde sobre tu documentación", "chatea con tus PDFs" o "busca en tu base de conocimiento" funciona con RAG bajo el capó.

Cómo funciona

El pipeline RAG clásico tiene dos fases:

Fase 1 — Indexación (una vez, offline)

1. Recolección: PDFs, páginas web, base de datos, transcripciones, código.
2. Chunking: cada documento se rompe en fragmentos manejables (chunks de 200-1000 tokens, con o sin overlap).
3. Embedding: cada chunk se convierte en un vector mediante un modelo de embeddings (text-embedding-3, Voyage, Cohere).
4. Almacenamiento: los vectores + metadatos se guardan en una base vectorial (Pinecone, Qdrant, Weaviate, pgvector).

Fase 2 — Retrieval + Generation (en cada query)

1. Embedding del query: la pregunta del usuario se convierte en vector con el mismo modelo de embeddings.
2. Retrieval: se buscan los K chunks más cercanos por similitud coseno (top-K típico: 5-20).
3. Re-ranking opcional: un modelo de re-ranking (Cohere Rerank, BAAI BGE Reranker) ordena los resultados por relevancia real, no solo por similitud vectorial.
4. Construcción del prompt: se monta un prompt con system instructions + chunks recuperados + pregunta del usuario.
5. Generación: el LLM responde basándose en el contexto inyectado.
6. Citación: idealmente la respuesta cita qué chunks usó, permitiendo al usuario verificar.

Ejemplo práctico

En antonioecheverria.es queremos un asistente que responda preguntas sobre los términos del diccionario. Sin RAG:

• "¿Cómo se calcula el EBITDA?" → el modelo responde de memoria, posiblemente bien pero sin enlazar al artículo. Si pregunto "¿cuántos términos tiene la categoría empresarial?" el modelo no tiene ni idea — no sabe qué hay en mi web.

Con RAG:

1. Indexación (una vez): todos los 63 términos del diccionario se chunkean, se generan embeddings con text-embedding-3-small (1536 dims), se guardan en Pinecone con metadatos (categoría, slug, URL, fecha).

2. Query: "¿cómo calcular el EBITDA?"

   • Embedding del query.
   • Pinecone devuelve top-5 chunks: principalmente fragmentos de /diccionario/empresarial/ebitda + alguno de /empresarial/margen-bruto.
   • Prompt construido: instrucciones + chunks + pregunta.
   • El LLM responde citando: "Según el artículo EBITDA del diccionario, se calcula como Beneficio + Intereses + Impuestos + Amortizaciones... ver artículo completo".

Resultado: respuesta concreta, basada en mi propio contenido, con enlace para profundizar. El usuario ve que el modelo no inventó.

Por qué RAG está en todas partes

Ventajas frente a alternativas:

• vs. solo prompting: RAG escala a corpus enormes sin que el contexto explote.
• vs. fine-tuning: actualización en tiempo real, sin reentrenar.
• vs. búsqueda clásica: entiende intención semántica, no solo palabras clave.
• vs. modelos sin contexto: respuestas verificables, menos alucinaciones, citables.

Y operativamente:

• Datos privados nunca pasan por entrenamiento; quedan en tu base.
• Cuando un documento cambia, solo reindexas esa pieza.
• Auditable: puedes ver qué chunks usó el modelo en cada respuesta.

Variantes y patrones avanzados

El RAG "vainilla" arriba descrito está obsoleto en producción seria. Las variantes que dominan hoy:

• Hybrid retrieval: combinar búsqueda densa (embeddings) con búsqueda léxica (BM25). Coge lo mejor de ambas.
• Re-ranking: aplicar un modelo más caro pero más preciso sobre el top-K inicial.
• Query rewriting: el LLM reescribe la query del usuario antes de buscar (más específica, más amplia, descompuesta en sub-queries).
• HyDE (Hypothetical Document Embeddings): el LLM genera una respuesta hipotética al query, y se busca por embedding de esa respuesta (no del query).
• Multi-step / Agentic RAG: el agente decide cuándo buscar, qué buscar y si necesita más rondas. Más caro pero mucho mejor en preguntas complejas.
• Graph RAG: combina vector search con un grafo de conocimiento. Permite trazar relaciones entre entidades, no solo similitud textual.
• Contextual retrieval (Anthropic): a cada chunk se le añade un resumen del contexto del documento entero antes de embeber. Mejora retrieval drásticamente.

Cuándo usar RAG vs alternativas

En producción, lo más común es fine-tuning ligero para estilo + RAG para hechos + prompting cuidado para comportamiento.

Errores comunes al implementar RAG

• Chunks demasiado grandes: pierden precisión.
• Chunks demasiado pequeños: pierden contexto.
• Chunking por carácter en lugar de por unidad semántica: rompe ideas a la mitad.
• No usar metadatos: sin filtros (fecha, categoría, autor) el retrieval se vuelve ruidoso.
• Solo retrieval denso sin BM25: pierdes coincidencias exactas que la búsqueda léxica capta.
• No medir calidad del retrieval: la mayoría de fallos de RAG son fallos de recuperación, no de generación. Mide recall@K antes de optimizar el prompt.
• Top-K demasiado bajo: 3 chunks puede ser insuficiente.
• No re-rankear: con re-ranking ganas 10-30% de calidad casi gratis.
• Pasar contexto sin estructura: si los chunks van como bloque de texto plano, el modelo se pierde. Numerados, con metadatos visibles, mejor.
• Olvidar evaluación: sin un set de Q&A propio para medir, vas a ciegas.

Stack típico de RAG en producción

• Embeddings: OpenAI text-embedding-3-small / Voyage / Cohere.
• Base vectorial: Pinecone (SaaS) o Qdrant/Weaviate/pgvector (autohospedados).
• Re-ranker: Cohere Rerank, BAAI BGE Reranker.
• Orquestación: LangChain, LlamaIndex (a pesar de fama mixta, son útiles para empezar), o código propio (cada vez más recomendado).
• LLM final: Claude, GPT, Llama según caso.
• Eval: Ragas, manual con un set propio.

Cuándo es la herramienta correcta

Sí, usa RAG cuando:

• Tienes un cuerpo de documentación o conocimiento que el LLM no tiene.
• Necesitas citas verificables.
• El conocimiento cambia con frecuencia.
• Tu corpus es grande (de cientos a millones de documentos).

No uses RAG cuando:

• Tu información ya está en el conocimiento general del modelo y no cambia.
• Necesitas que el modelo razone sobre los chunks de forma muy compleja (a veces fine-tuning + prompting estructurado funciona mejor).
• Tu volumen es muy bajo y prompting puro basta.

Referencias

• Lewis et al. · RAG paper original — el paper de 2020 que acuñó el término
• Anthropic · Contextual Retrieval — mejora moderna que aumenta calidad del retrieval significativamente
• LlamaIndex Docs — referencia práctica para construir pipelines RAG