El problema que RAG resuelve

Los LLMs como GPT-4o o Claude 3.5 Sonnet son entrenados en datos hasta una fecha de corte y no tienen acceso a tu información privada: los manuales internos de tu empresa, las conversaciones pasadas con clientes, el inventario actualizado de productos. Preguntarle a un LLM sobre tus datos específicos sin darle acceso produce respuestas genéricas o inventadas (alucinaciones).

RAG resuelve esto de manera elegante: en lugar de reentrenar el modelo con tus datos (costoso, lento, complejo), busca en tiempo real los fragmentos de información relevantes para la consulta del usuario y los incluye en el contexto del LLM. El modelo entonces responde basándose en tu información, no en su entrenamiento general.

Por qué RAG domina producción

Según el State of AI in Production de Andreessen Horowitz (2024), RAG es la técnica de personalización de LLMs más usada en producción, presente en el 67% de las aplicaciones empresariales de IA. Fine-tuning ocupa el segundo lugar con el 22%.

Cómo funciona RAG: los tres pasos

1
Indexar documentos
como vectores
2
Recuperar fragmentos
relevantes por similitud
3
Generar respuesta
con contexto recuperado

Paso 1 — Indexación: tus documentos se fragmentan en chunks (500-1000 tokens cada uno) y se convierten en vectores numéricos usando un modelo de embeddings. Esos vectores se almacenan en una base de datos vectorial. Paso 2 — Retrieval: cuando el usuario una pregunta, también se vectoriza y se buscan los chunks más similares en la base de datos. Paso 3 — Generation: los chunks recuperados se incluyen en el prompt del LLM junto con la pregunta original. El LLM genera la respuesta usando esa información.

Bases de datos vectoriales: las opciones

# Principales opciones de bases de datos vectoriales Pinecone — cloud managed, escala a billones de vectores Weaviate — open source, búsqueda híbrida (vector + keyword) Qdrant — open source, alta performance, Rust-based pgvector — extensión de PostgreSQL, menos operacional overhead Chroma — embebido, ideal para desarrollo y pequeña escala Supabase — PostgreSQL + pgvector managed, fácil integración

Cuándo usar RAG vs contexto largo

Con modelos de 1M tokens de contexto (Gemini 1.5 Pro, Claude 3.5 Sonnet), algunos casos de RAG pueden manejarse simplemente incluyendo todos los documentos en el contexto. RAG sigue siendo superior cuando: la base de conocimiento supera la ventana de contexto, necesitás respuestas con citas exactas, el costo de tokens importa (RAG reduce el contexto enviado), o los documentos se actualizan frecuentemente.

Implementación práctica: un pipeline básico

El stack mínimo viable para RAG en producción: un modelo de embeddings (OpenAI text-embedding-3-small o nomic-embed-text para open source), una base de datos vectorial (Supabase pgvector para simplicidad operacional), y un LLM para generación. Con LangChain o LlamaIndex, el tiempo de implementación de un prototipo funcional es de 2-4 horas.

Conclusión

RAG es la arquitectura más práctica para el 80% de los casos de uso empresarial que requieren que la IA trabaje con información propia. La inversión en indexar bien los documentos — buena segmentación, buenos metadatos, actualizaciones frecuentes — determina en gran medida la calidad de las respuestas. El LLM solo es tan bueno como la información que recupera.