En el post anterior vimos cómo almacenar embeddings y consultar por similitud. Hoy unimos las piezas: RAG toma fragmentos relevantes de tus documentos y los inyecta en el contexto del modelo para que responda apoyado en fuentes recientes y citables. El enfoque fue formalizado por Lewis et al. y sigue siendo la base de la mayoría de asistentes empresariales.

Idea clave: el modelo “piensa” con tus datos, no solo con lo que trae entrenado.

¿Qué es RAG (de verdad)?

1. Consulta: recibes una pregunta del usuario.
2. Recuperación: buscas los Top-K fragmentos en tu base vectorial.
3. Enriquecimiento: insertas esos fragmentos (y metadatos) en el prompt.
4. Generación: el LLM redacta la respuesta basada en esos fragmentos y añade citas.

El artículo original demostró que combinar memoria paramétrica (el modelo) con memoria no paramétrica (tu índice de documentos) mejora la factualidad y permite actualizar conocimiento sin re-entrenar. :contentReference[oaicite:0]{index=0}

Chunking que funciona (y por qué importa)

El chunking define la unidad de información que vectorizas y recuperas. Fragmentos demasiado largos meten ruido; demasiado cortos rompen el contexto. Recomendación práctica: fragmentos breves con solape pequeño, guardar buen metadata (título, URL, fecha, idioma, tenant) y filtrar por metadatos antes de la similitud. Esto suele mejorar el recall@K y reduce tokens. :contentReference[oaicite:1]{index=1}

Métricas mínimas para saber si tu RAG sirve

• Recall@K y MRR/nDCG en recuperación (¿aparecen los fragmentos correctos y en qué orden?).
• Precisión útil (respuestas correctas verificables / total) y tasa de abstención sana.
• Groundedness (¿la respuesta se apoya en las citas?) y latencia p95.
• Coste por interacción (tokens de entrada/salida) y feedback humano cuando aplique.

Más allá del RAG básico: tres ideas que elevan calidad

1. HyDE (Hypothetical Document Embeddings): genera un documento hipotético con el LLM y úsalo para buscar vecinos reales; mejora recuperación en cero-shot. :contentReference[oaicite:2]{index=2}
2. Self-RAG: el modelo decide cuándo recuperar, se autocritica y ajusta el uso de fuentes según la consulta. :contentReference[oaicite:3]{index=3}
3. Corrective RAG (CRAG): añade una etapa de revisión/corrección para detectar y arreglar errores de recuperación y generación. :contentReference[oaicite:4]{index=4}

Encuentras panoramas amplios y taxonomías recientes en encuestas de 2024 en adelante. :contentReference[oaicite:5]{index=5}

Micro-workflow en n8n: “RAG con citas y modo seguro”

1. Webhook (POST) → recibe { query, userId }.
2. Function → normaliza el texto, detecta idioma y construye filtros por metadatos.
3. HTTP Request → consulta la base vectorial (Top-K = 3–5) usando filtros previos.
4. LLM → system prompt con reglas: “si no hay evidencia suficiente, responde ‘no sé’”.
5. IF → si groundedness bajo o sin citas → fallback (FAQ clásica) y pide más contexto.
6. Database → guarda costo, latencia, recall@K, groundedness.
7. Notifier → alerta si p95 o coste superan umbrales.

Errores comunes (y cómo evitarlos)

• Inyectar documentos enteros en lugar de fragmentos relevantes con metadatos.
• Top-K demasiado alto: más tokens, más ruido, peor calidad.
• Sin guardrails: no exigir citas o permitir respuestas sin respaldo documental.
• No medir nada: sin tracing ni evaluación continua, no sabrás por qué baja la calidad.

Conclusión

RAG no es un “truco de prompt”: es una arquitectura. Empieza con buen chunking, filtros por metadatos y métricas; luego itera con técnicas como HyDE, Self-RAG o CRAG. Con eso, tu asistente deja de “adivinar” y empieza a argumentar con fuentes.

← Anterior: Bases de datos vectoriales explicadas fácil (y cuándo no las necesitas)

Siguiente: Agentes inteligentes: cuándo usarlos y cuándo evitarlos →