Qué es RAG

RAG 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

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

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.

Cuándo RAG no encaja

RAG añade complejidad de ingeniería y requiere mantenimiento, así que no siempre conviene adoptarlo:

• Base de conocimiento pequeña y que casi no cambia - basta con pegar el texto una vez en el system prompt; no hace falta búsqueda ni base vectorial.
• Sin recursos para mantener el pipeline - el índice hay que actualizarlo cada vez que cambian los documentos y vigilar la calidad de la búsqueda; sin un equipo o proveedor dedicado, el sistema queda obsoleto rápido y empieza a dar respuestas erróneas.
• Se necesita exactitud garantizada - para cálculos, redacción legal y otras tareas donde el error no es aceptable, los sistemas deterministas y la revisión humana son más fiables que la generación del modelo.
• La tarea es sobre acciones, no búsqueda de documentos - crear un ticket, actualizar un registro - RAG solo no basta, hacen falta tools/MCP (ver más abajo).

Antes de empezar conviene estimar el volumen de documentos, con qué frecuencia cambian y quién será responsable del índice - eso determina si RAG compensa o si basta una solución más simple.

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.

Si necesita ayuda con el desarrollo, la implementación de IA o el soporte del sitio para su proyecto - escríbame.

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.

Términos del artículo

RAG — Retrieval-Augmented Generation — generación aumentada por recuperación

pipeline — sequence of processing stages

retrieval — finding relevant context before generation — búsqueda de contexto relevante antes de generar

LLM — Large Language Model — modelo de lenguaje grande

Confluence — Atlassian wiki for team documentation — wiki de Atlassian para documentación de equipo

chunking — splitting documents into retrieval-friendly pieces — división de documentos en fragmentos para búsqueda

embeddings — numeric vectors that capture text meaning — vectores numéricos que capturan el significado del texto

vector store — database optimized for similarity search over embeddings — almacén optimizado para búsqueda por similitud de embeddings

Pinecone — managed vector database for similarity search — BD vectorial gestionada para similitud

pgvector — PostgreSQL extension for vector search — extensión de PostgreSQL para búsqueda vectorial

vector db — database for similarity search over embeddings — BD para búsqueda por similitud de embeddings

Qdrant — vector database for similarity search — base de datos vectorial para búsqueda por similitud

reranking — reordering search results by relevance — reordenación de resultados por relevancia

Chroma — open-source embedding database for RAG apps — BD de embeddings open-source para apps RAG

chunks — small text pieces indexed for retrieval — trozos cortos de texto indexados para retrieval

top-k — keep only the k most likely next tokens when sampling — en el muestreo dejar solo los k tokens más probables

LlamaIndex — framework for connecting LLMs to private data — framework para conectar LLM con datos privados

LangChain — framework for building LLM applications — framework para aplicaciones con LLM

ANN — Approximate Nearest Neighbor — búsqueda aproximada de vecinos cercanos en espacio vectorial

fine-tuning — additional training of a model on domain data — entrenamiento adicional del modelo con datos del dominio

system prompt — hidden instructions that steer the model for a task — instrucciones ocultas que guían el comportamiento del modelo

runbook — step-by-step playbook for incidents and operations — guía paso a paso para incidentes y operación

vector search — finding nearest neighbors in embedding space — búsqueda de vecinos cercanos en el espacio de embeddings

cross-encoder — rerank model that scores query and document together — modelo de rerank que puntúa consulta y documento juntos

guardrails — rules and filters that keep AI outputs safe and on-policy — reglas y filtros que mantienen las salidas de IA seguras y a norma

faithfulness — how well an answer sticks to the retrieved sources — cuánto se ciñe la respuesta a las fuentes recuperadas

tool calling — model invoking external tools or APIs — el modelo invoca herramientas o API externas

hit rate — share of requests served from cache — porcentaje de peticiones servidas desde caché

reranker — model that reorders search hits by relevance — modelo que reordena resultados por relevancia

SKU — Stock Keeping Unit — unidad de mantenimiento de stock

baseline — reference measurement before changes

MCP — Model Context Protocol — protocolo de contexto del modelo

CRM — Customer Relationship Management — gestión de relaciones con clientes

self-hosted — software you run on your own servers — software que ejecutas en tus propios servidores

GPU — Graphics Processing Unit — unidad de procesamiento gráfico