Tu
LLM
acaba de citar con confianza
un artículo de investigación
que no existe.
Le preguntaste
sobre la documentación de la API de tu empresa,
y describió endpoints
que fueron dados de baja
en 2019.
Esto sucede porque
los modelos de lenguaje generan texto
basado en patrones de los datos de entrenamiento,
no consultando tu información real.
Retrieval Augmented Generation
(RAG)
lo soluciona.
No haciendo a los modelos más inteligentes,
sino dándoles acceso
a datos reales antes de generar una respuesta.
La técnica se ha vuelto esencial
para sistemas en producción,
pero la mayoría de las implementaciones fallan silenciosamente —
o devolviendo documentos irrelevantes,
o mejorando la recuperación tanto que el modelo se confunde por demasiado contexto.
Esta guía recorre cómo funciona RAG en realidad,
por qué fallan las configuraciones básicas,
y los patrones específicos que funcionan en producción.
Qué Hace Realmente RAG
RAG tiene tres pasos:
- Recuperar:
Busca en tu almacén de documentos
contenido relevante para la pregunta del usuario - Aumentar:
Inyecta los documentos recuperados
en el prompt junto con la pregunta original - Generar:
El LLM responde usando tanto la pregunta como el contexto recuperado
La idea crítica: el modelo nunca alucina sobre tus datos porque está viendo tus datos reales mientras genera la respuesta. Tiene la información justo delante.
Pero aquí es donde divergen las implementaciones. Un sistema RAG ingenuo recupera todos los documentos vagamente relevantes, inunda la ventana de contexto, y el modelo se pierde en el ruido. Un sistema RAG bien ajustado recupera exactamente lo que importa, lo clasifica por relevancia, y el modelo tiene una guía clara.
Por Qué Falla el RAG Básico: Las Tres Fallas Comunes
Antes de arreglar nada, entiende dónde falla.
Falla 1: La recuperación devuelve ruido.
Buscas en tu base de datos de documentos
usando coincidencia básica de palabras clave o embeddings simples,
y obtienes 10 resultados donde solo 2 son relevantes.
El LLM ve el ruido y se confunde o ignora la buena información por completo.
Este es el modo de fallo más común.
Falla 2: Los documentos recuperados son demasiado largos.
Incluso si la recuperación funciona, recuperas documentos completos (800+ tokens cada uno).
Tu ventana de contexto de 4K desaparece. Claude o GPT-4o desperdician tokens analizando secciones irrelevantes y no tienen espacio para matices en la respuesta.
Falla 3: El desajuste recuperación-generación.
Tu sistema de recuperación encuentra documentos optimizados para un tipo de consulta (búsqueda factual),
pero el paso de generación necesita documentos estructurados de manera diferente (para razonamiento, para ejemplos, para casos extremos).
Estás resolviendo dos problemas diferentes con un solo recuperador.
Construyendo una Pipeline RAG de Producción: Paso a Paso
Un sistema RAG funcional necesita cuatro componentes: un almacén de documentos, un recuperador, un clasificador y una estructura de prompt. Vamos a construir uno.
Paso 1: Ingesta y División de Documentos
Los documentos brutos son demasiado grandes para recuperarlos eficientemente. Necesitas dividirlos en fragmentos — típicamente de 300-500 tokens cada uno, con un solapamiento del 10-20% entre fragmentos.
# Ejemplo: dividir un documento para RAG
documents = load_documents(
