Construiste un chatbot el mes pasado. Con total confianza, le dijo a tu cliente que envías a Mongolia. Tú no lo haces. El LLM no tenía idea de lo que no sabía, así que inventó.
Este es el problema de RAG, y la solución no es un mejor prompt.
Retrieval-Augmented Generation (RAG) resuelve un modo de fallo específico: cuando un LLM no tiene el contexto necesario para responder correctamente, alucina. RAG inserta tus datos reales en la conversación antes de que el LLM genere una respuesta. Sin datos, sin alucinaciones. Sencillo en teoría. La ejecución es donde la mayoría de las implementaciones fallan.
Esta guía recorre RAG en producción: por qué funciona, dónde se atascan los equipos, cómo construir la arquitectura y las decisiones de configuración específicas que marcan la diferencia en el rendimiento.
Por Qué RAG Supera al Fine-Tuning (y Cuándo No)
Antes de decidirte por RAG, necesitas saber qué estás resolviendo realmente. Hay una diferencia fundamental entre enseñar a un LLM y darle datos para que los consulte.
El fine-tuning actualiza los pesos del modelo. Alimentas al modelo con miles de ejemplos de tus datos y las salidas esperadas, y aprende patrones. El conocimiento se convierte en parte del modelo. Esto cuesta dinero (cientos a miles por ejecución de entrenamiento), lleva tiempo (horas a días) y cambia permanentemente el comportamiento del modelo. No puedes actualizarlo fácilmente con nueva información sin reentrenar.
RAG recupera el contexto relevante en el momento de la inferencia. Almacenas tus datos en una base de datos separada, y cuando un usuario hace una pregunta, buscas las partes relevantes y las incluyes en el prompt. El modelo ve tus datos actuales en cada solicitud. Puedes actualizar los datos sin reentrenar nada.
Aquí está la elección práctica:
- Usa RAG cuando: tus datos cambian con regularidad (documentos de productos, precios, inventario, perfiles de clientes), necesitas información actual, quieres actualizar sin volver a desplegar, o no estás seguro de lo que el LLM necesita aprender todavía.
- Usa fine-tuning cuando: tus datos son estables y voluminosos, el patrón es sutil (estilo de escritura, tono, razonamiento especializado), y la velocidad de inferencia importa más que la frescura de los datos.
- Usa ambos cuando: tienes conocimiento de dominio estable (fine-tune) más datos dinámicos (RAG). Esto es común en dominios especializados: fine-tune en terminología médica, usa RAG para historiales de pacientes.
La mayoría de los equipos deberían empezar con RAG. Es más barato de construir, más fácil de iterar y no requiere la profundidad de ciencia de datos que exige el fine-tuning. La brecha de rendimiento entre RAG bien ajustado y fine-tuning es menor de lo que era hace dos años, especialmente con Claude Sonnet 4 y GPT-4o, que tienen ventanas de contexto más grandes.
El Pipeline de RAG: Cuatro Etapas Innegociables
Un sistema RAG en producción tiene cuatro etapas. Omite una y todo el sistema se rompe.
1. Ingesta. Cargas tus datos (PDFs, páginas web, bases de datos, documentos estructurados) y los conviertes en fragmentos lo suficientemente pequeños para la incrustación (embedding). Un fragmento suele tener entre 300 y 800 tokens: un párrafo, no un capítulo de libro. El objetivo es la granularidad: cada fragmento debe responder a una sola pregunta sin requerir contexto de otros cinco fragmentos.
2. Incrustación (Embedding). Cada fragmento se convierte en un vector: una lista de números que representa su significado semántico. Usas un modelo de incrustación (como text-embedding-3-small de OpenAI o embed-english-v3.0 de Cohere) para crear estos vectores. Los vectores residen en una base de datos vectorial (Pinecone, Weaviate, Milvus, o incluso PostgreSQL con la extensión pgvector). El modelo de incrustación es independiente de tu LLM.
3. Recuperación (Retrieval). Cuando un usuario hace una pregunta, incrustas la pregunta usando el mismo modelo de incrustación, luego buscas en la base de datos vectorial los fragmentos más similares. La similitud se mide por la distancia del coseno: cuán «cercanos» están los vectores entre sí. Normalmente recuperas los 3-10 fragmentos principales, dependiendo de cuánto contexto pueda manejar tu LLM.
4. Generación. Construyes un prompt que incluye los fragmentos recuperados, y luego lo envías a tu LLM. El LLM genera una respuesta basada tanto en la pregunta como en el contexto. Si el contexto es bueno, la respuesta es precisa. Si el contexto es incorrecto, el LLM seguirá alucinando, solo que con mayor confianza, porque tiene algo con qué trabajar.
Aquí tienes un flujo concreto:
# Paso 1: Ingesta (única vez, offline)
documentos_crudos = cargar_pdfs(
