← Volver al listado

Qué es RAG

RAG (Retrieval-Augmented Generation) es un enfoque en el que un modelo de lenguaje busca fragmentos relevantes en tu base de conocimiento antes de responder y luego genera texto. En lugar de "memorizar" todos los documentos en los pesos del modelo o cargarlos enteros en el contexto, el sistema encuentra los trozos necesarios y los inserta en el prompt. A continuación - qué es RAG, cómo funciona el pipeline y cuándo tiene sentido en producción.

Definición en términos simples

Retrieval-Augmented Generation combina dos etapas:

  1. Retrieval (recuperación) - según la consulta del usuario, el sistema encuentra los fragmentos de texto más adecuados en un corpus: wiki, PDF, tickets, código, normativas.
  2. Generation (generación) - el LLM recibe esos fragmentos como contexto y formula la respuesta apoyándose en ellos.

El término se consolidó tras Lewis et al. (2020) y se convirtió en estándar para chatbots corporativos, sistemas de soporte y asistentes internos. RAG no sustituye al modelo - lo complementa con datos actuales que no estaban en el entrenamiento o que cambiaron ayer.

Cómo funciona RAG: pipeline típico

┌──────────┐    ┌─────────────┐    ┌──────────────┐    ┌─────────┐
│Documentos│───▶│ Chunking +  │───▶│ Vector DB    │    │         │
│ (PDF, MD)│    │ Embeddings  │    │ (índice)     │    │   LLM   │
└──────────┘    └─────────────┘    └──────┬───────┘    │         │
                                          │            │         │
Consulta ──▶ Embedding ──▶ Top-K ──▶ Prompt + contexto ──▶ Respuesta

1. Preparación de datos (offline)

  • Carga - parseo de PDF, HTML, Markdown, Confluence, Notion, repositorios.
  • Chunking - división en fragmentos de 256-1024 tokens con solapamiento para no cortar el sentido al final del párrafo.
  • Embedding - cada chunk se convierte en vector con un modelo de embeddings (OpenAI text-embedding-3, Cohere, BGE, E5 open source).
  • Indexación - vectores guardados en vector store: Pinecone, Weaviate, Qdrant, pgvector, Chroma, Milvus.

Esta etapa se ejecuta al añadir o actualizar documentos, no en cada consulta del usuario.

2. Consulta (online)

  1. La pregunta del usuario también se embebe con el mismo encoder.
  2. La vector DB devuelve Top-K chunks más cercanos (normalmente K = 3-10).
  3. Opcionalmente - reranking: un segundo modelo reordena candidatos por relevancia con más precisión que la similitud coseno pura.
  4. Los fragmentos encontrados van al prompt system/user con la instrucción de "responder solo según el contexto".
  5. El LLM genera la respuesta; a menudo se añaden citas al id del chunk o página fuente.

La calidad de RAG depende ~80% de la recuperación: si el fragmento correcto no entra en Top-K, el modelo alucina o dice honestamente "no lo sé".

Componentes clave

Componente Rol Ejemplos
Modelo de embedding Texto → vector para búsqueda semántica text-embedding-3-large, bge-m3, voyage-3
Base vectorial Almacenamiento y búsqueda ANN rápida Qdrant, Pinecone, pgvector, Weaviate
Estrategia de chunking Equilibrio detalle vs ruido Tamaño fijo, split semántico, por encabezados
LLM Respuesta final con razonamiento GPT-5.6, Claude Fable 5, Gemini 3.1, modelos locales
Orquestador Une etapas, caché, logging LangChain, LlamaIndex, Haystack, código propio

En 2026 muchos frameworks (LlamaIndex, LangGraph) y productos (Cursor @Codebase, Notion AI, sistemas tipo Glean) implementan RAG por debajo, pero entender el pipeline básico es necesario para depurar y afinar.

Casos de uso prácticos

  • Soporte y FAQ - respuestas desde base de artículos y tickets pasados sin búsqueda manual.
  • Wiki interna - "cómo solicitar vacaciones", "dónde está el runbook de incidentes".
  • Legal y compliance - búsqueda en contratos y normativas con referencia al artículo.
  • Asistentes de código - búsqueda semántica en el repo (índice + embeddings), complemento al contexto completo en el IDE.
  • Análisis de documentos - preguntas sobre informes, investigaciones, transcripciones de reuniones.

Patrón común: corpus grande, actualizaciones frecuentes, citas a fuentes - RAG encaja mejor que subir un archivo una vez al chat.

RAG vs fine-tuning vs contexto largo

Enfoque Cuándo encaja Limitación
RAG Documentos actuales, fuentes transparentes, actualizaciones sin reentrenar Depende de la calidad de búsqueda
Fine-tuning Estilo, formato, terminología de dominio, conocimiento estable Caro actualizar cuando cambian los datos
Contexto largo Documento o codebase entero en una sesión Coste, latencia, "lost in the middle"

Estos enfoques no son excluyentes. Esquema típico 2026: RAG para buscar en el corpus + contexto largo para pocos archivos completos + fine-tuning ligero o system prompt para el tono de la empresa.

Limitaciones y problemas habituales

RAG resuelve el acceso al conocimiento, pero no:

  • garantía de exactitud factual (el modelo puede ignorar el contexto)
  • acciones complejas de varios pasos (hacen falta tools / MCP)
  • actualización automática del índice (se necesita ETL al cambiar documentos)

Fallos frecuentes:

  • Mal chunking - tabla partida por la mitad, fórmula sin encabezado.
  • K incorrecto - pocos chunks → hechos omitidos; demasiados → ruido en el prompt.
  • Índice obsoleto - documento actualizado, embedding no recalculado.
  • Búsqueda híbrida sin configurar - búsqueda semántica pura falla en SKU, ID, fechas exactas; ayuda híbrido (BM25 + vectores).

En producción conviene: monitorizar hit rate de retrieval, A/B de chunk size, feedback humano, guardrails "si la confianza es baja - no responder".

Cómo mejorar un sistema RAG

  1. Metadatos - etiquetas de departamento, fecha, versión; filtrado antes de vector search.
  2. Búsqueda híbrida - keyword (BM25) + semántica; especialmente en documentación técnica.
  3. Reranker - cross-encoder tras Top-20 inicial → Top-5 final.
  4. Transformación de consulta - reformulación, multi-query, HyDE (documento hipotético).
  5. Graph RAG - entidades relacionadas (personas, proyectos, dependencias) sobre chunks planos.
  6. Evaluación - dataset pregunta-respuesta gold; métricas faithfulness, context recall (RAGAS, DeepEval).

Empieza con pipeline simple (chunk → embed → Top-5 → GPT), mide baseline y añade complejidad solo donde suban las métricas.

RAG y el ecosistema de agentes

RAG suele ir con MCP y tool calling: RAG extrae conocimiento de documentos, las tools ejecutan acciones (crear ticket, consultar saldo). En Cursor el índice semántico @Codebase es un caso de RAG sobre archivos del proyecto; en enterprise se escala el mismo patrón a Confluence, Slack y CRM.

Capa Tarea
RAG "¿Qué dicen los documentos?"
MCP / tools "¿Qué hay ahora en el sistema? Actúa"
LLM Sintetizar respuesta y planificar pasos

Resumen

RAG es la forma estándar de conectar un LLM a tus datos sin reentrenar: se indexan documentos, se recuperan fragmentos relevantes por consulta y el modelo responde apoyándose en ellos. Escala desde prototipo Chroma + OpenAI hasta clúster con búsqueda híbrida, reranking y monitorización de calidad.

Para un primer proyecto: elige un corpus (p. ej. FAQ de 50 páginas), configura chunking y Top-K, mide si el párrafo correcto entra en contexto - es el mejor predictor del éxito del sistema.

Preguntas frecuentes

¿En qué se diferencia RAG del fine-tuning?

Fine-tuning cambia los pesos del modelo con tus ejemplos - útil para estilo, formato y patrones estables. RAG no toca los pesos: en cada consulta trae fragmentos frescos del índice. Documentos que cambian cada semana se actualizan mejor con RAG (reindexación) que reentrenando. Fine-tuning cuando el modelo debe "saber" un procedimiento de memoria; RAG cuando importan actualidad y cita de fuente.

¿Hace falta RAG si el modelo tiene contexto de un millón de tokens?

El contexto largo (1M+ tokens en Claude, Gemini, GPT-5.6) permite cargar mucho texto en una sesión, pero no sustituye RAG en corpus grandes: 100 GB de PDF no caben en el prompt y coste y latencia crecen linealmente. RAG elige trozos relevantes; contexto largo sirve para pocos archivos completos tras retrieval o código del repo en el IDE. En la práctica se combinan ambos.

¿Qué base vectorial elegir para RAG?

Depende de escala e infraestructura. pgvector - si ya tienes PostgreSQL y hasta millones de vectores. Qdrant, Weaviate, Milvus - self-hosted o managed al crecer. Pinecone - managed sin operar clúster. Chroma - inicio rápido de prototipo. Lo crítico es calidad de embeddings, chunking y monitorización; muchos sistemas empezaron en Chroma y migraron a pgvector o Qdrant sin cambiar la lógica de la app.

¿Por qué RAG a veces da respuestas incorrectas?

Causas principales: (1) fallo de retrieval - el chunk correcto no entró en Top-K; (2) modelo ignoró el contexto y completó desde "memoria"; (3) índice obsoleto; (4) chunks contradictorios. Se corrige mejorando búsqueda (híbrida, reranker), prompt estricto ("si no está en contexto - di que no sabes"), citas y set de evaluación para regresiones.

¿Se puede construir RAG con modelos locales?

Sí. Modelos de embedding (bge-m3, nomic-embed) y LLM (Llama, Qwen, Mistral vía Ollama) funcionan offline; la vector store también puede ser local. Límites - calidad en hardware modesto; elegir tamaño según GPU/RAM. Para datos confidenciales (sanidad, finanzas, sector público) RAG local es habitual: los documentos no salen del perímetro y la arquitectura del pipeline es la misma que en la nube.

Contacto