RAG (Retrieval-Augmented Generation) es la arquitectura que conecta un LLM al conocimiento privado de tu empresa en tiempo de ejecución, sin entrenar un modelo, sin exponer datos al proveedor, y con la posibilidad de citar la fuente de cada respuesta. En 2026, es el enfoque estándar para un chatbot interno, atención al cliente, un copilot de producto, soporte a ingeniería y cualquier caso que necesita que la IA responda con base en tu contenido, no en el conocimiento genérico del modelo.
Esta guía explica cómo funciona RAG de verdad, qué decisiones importan, qué trampas evitar y cómo medir la calidad para pasar del "parece que funciona" al "funciona en producción con métricas".
Por qué RAG y no fine-tuning
Existen tres formas de hacer que un LLM sepa algo que no sabía: (1) ponerlo en el prompt (in-context), (2) entrenar el modelo (fine-tuning), (3) recuperarlo dinámicamente (RAG). RAG combina las ventajas de las tres: contexto fresco y actualizable como (1), la capacidad de absorber un corpus grande como (2), y un bajo costo operativo como (3).
El fine-tuning brilla cuando el estilo de la respuesta importa mucho (voz, formato, tono) o cuando hay patrones lingüísticos específicos. El conocimiento factual, en cambio, es el territorio natural de RAG: puedes actualizar la base sin reentrenar, citar la fuente y revocar el acceso a documentos específicos. Para la mayoría de los casos corporativos, RAG gana.
Anatomía de un pipeline RAG completo
Siete etapas. 1. Ingesta: extracción de contenido de las fuentes (PDF, HTML, Word, Confluence, Notion, repositorios, bases de datos). Incluye OCR para imágenes, parsing de tablas, preservación de la jerarquía. 2. Limpieza y normalización: eliminación de boilerplate, deduplicación, anonimización cuando aplica. 3. Chunking: división en pedazos con un tamaño y una estructura adecuados. 4. Generación de embeddings: cada chunk se vuelve un vector. 5. Indexación: los vectores + metadatos se guardan en el vector DB. 6. Retrieval: dada una query, recuperar los top-K chunks más relevantes vía similitud + filtros + re-ranking. 7. Generación: los chunks recuperados entran en el prompt y el LLM genera la respuesta, citando fuentes.
Chunking: la decisión que más impacta la calidad
Un mal chunking sabotea cualquier modelo. Principios. Respeta la estructura: dividir por sección, párrafo o bloque de código, no por un conteo ciego de tokens. Tamaño coherente con el dominio: 256 a 512 tokens para un FAQ corto; 800 a 1200 para documentación técnica; 2000+ para código que necesita contexto. Overlap entre chunks del 10 al 20% para preservar la continuidad. Enriquece con contexto: cada chunk lleva el título del documento, el breadcrumb de la sección, la fecha, el autor, la fuente.
Patrón avanzado: contextual retrieval, en el que cada chunk recibe una frase corta generada por un LLM que describe el contexto del chunk dentro del documento mayor. Ese pequeño enriquecimiento eleva drásticamente el recall en queries ambiguas.
Retrieval híbrido y re-ranking
La búsqueda puramente vectorial pierde en queries con un término exacto (nombre de producto, sigla, código de error). La búsqueda puramente por keyword pierde en queries con paráfrasis. El camino moderno es híbrido: combinar BM25 con similitud vectorial y fundir los resultados con un esquema como RRF (Reciprocal Rank Fusion).
Por encima de la fusión viene el re-ranker. Tomando los top-50 del retrieval y reordenándolos con un modelo especializado (Cohere Rerank, Voyage Reranker, BGE Reranker), duplicas la precisión en muchos casos, con un costo marginal aceptable. En un RAG serio, el re-ranker casi siempre vale la pena.
El prompt de generación: el último kilómetro
El prompt de generación hace o rompe la respuesta. Buenas prácticas. Inyectar el contexto recuperado en un bloque identificable, con la fuente. Instruir a citar la fuente en cada afirmación. Instruir a admitir que no sabe cuando el contexto no cubre la pregunta. Limitar la creatividad en dominios sensibles (médico, jurídico, financiero): "responde solo con base en el contexto proporcionado". Pedir un formato estructurado cuando aplica (JSON, markdown, bullets).
Evaluación de RAG: las métricas que importan
Sin evaluación, RAG se vuelve una sensación. Métricas necesarias. Recall@k y Precision@k: del retrieval, cuántos chunks relevantes aparecieron en los top-k. MRR (Mean Reciprocal Rank): la posición promedio del chunk correcto. Faithfulness: si la respuesta generada usa de hecho el contexto, sin inventar. Answer relevancy: si la respuesta responde a la pregunta. Context precision: si el contexto recuperado es mayoritariamente útil o tiene ruido. Frameworks como Ragas, TruLens, Phoenix y DeepEval automatizan estas métricas.
Arma temprano un dataset de evaluación con 50 a 200 pares de pregunta/respuesta esperada, y córrelo antes de cada cambio en el pipeline. Sin esto, un buen cambio a veces empeora la calidad promedio y nadie lo nota.
Permisos y multi-tenant
En muchos casos, el vector DB no tiene ACL nativa. Necesitas modelar los permisos a nivel de chunk. Patrones. Filtro de metadatos: cada chunk trae una lista de grupos/usuarios que pueden verlo; la consulta filtra por el grupo del usuario. Colección por tenant: cada cliente en una colección separada (más aislamiento, más costo operativo). Capa de posprocesamiento: filtra el resultado antes de enviarlo al LLM con base en la ACL del sistema de origen.
Tratar los permisos como algo secundario es el error más caro en RAG corporativo: una filtración entre clientes o entre departamentos se vuelve un incidente serio rápidamente.
Actualización e ingesta continua
Los datos cambian. Tu base de conocimiento necesita ser incrementada continuamente, no reindexada cada vez. Patrón: una cola de eventos desde las fuentes (webhook de Confluence, polling de Drive, CDC de la base de datos) que dispara una ingesta incremental, con versionado de documentos y deduplicación de chunks. Un documento eliminado en el origen debe eliminarse (o marcarse) en la base; si no, la IA cita una fuente muerta.
Dónde falla RAG (y cómo sortearlo)
RAG sufre en algunos escenarios. Preguntas agregativas ("¿cuántos clientes pidieron cancelación este mes?"): un vector DB no suma; combina RAG con SQL o con un agente que delega a una query estructurada. Preguntas que exigen razonamiento multi-hop ("si A depende de B y B cambió en enero, ¿cuál es el impacto en C?"): el RAG simple no navega la cadena; usa un agente que hace múltiples búsquedas guiadas. Preguntas sobre código con referencia a un símbolo específico: el chunking necesita preservar el AST; la búsqueda pura por embedding pierde. Usa una combinación con un índice de símbolos.
RAG como producto, no como proyecto
Un buen RAG es un producto vivo: tiene owner, métricas, ciclo de mejora, evals continuos, observabilidad. Las empresas que lo tratan como un proyecto que "queda listo" ven la calidad degradarse con el tiempo mientras los datos cambian y el patrón de uso evoluciona. Las empresas que lo tratan como un producto cosechan una ganancia compuesta.
En Steply, montamos RAG corporativo en ciclos cortos: del diagnóstico del conocimiento disponible al primer caso de uso en producción, con observabilidad y evals, en pocas semanas. A partir de ahí, evoluciona con el uso real, conectando nuevas fuentes, refinando el re-ranking y expandiéndose a más casos.