Entender RAG, cuando la IA necesita tu conocimiento
Qué es RAG realmente, en palabras simples. Cuándo lo necesitas, cuándo no. La explicación más corta de RAG en la web.
El problema
Le preguntas a ChatGPT por una información que está en tu propio manual. ChatGPT no la sabe porque fue entrenado con el conocimiento del mundo, no con tu manual. Tienes dos opciones: copiar la información en cada pregunta, o montar una solución que lo haga automáticamente. La segunda se llama RAG. Retrieval-Augmented Generation.
Qué significan las palabras
"Retrieval" es solo una palabra fina para "buscar". "Augmented" significa "enriquecido". "Generation" significa "generar la respuesta".
Es decir: cuando haces una pregunta, el sistema primero busca en tu propio material, mete los fragmentos encontrados automáticamente en el prompt y el modelo responde tu pregunta con esa información extra. Tú no ves nada de eso. Preguntas como siempre y la respuesta viene a medida, pero con tu conocimiento dentro.
Cuándo necesitas RAG de verdad
Necesitas RAG cuando se cumplen tres cosas:
- Tienes tu propio material que no estaba en el entrenamiento de los modelos (manuales, protocolos de cliente, procesos internos, especificaciones de producto, historiales médicos, casos legales)
- El material es demasiado grande para copiarlo cada vez en el prompt (más que unas pocas páginas)
- Quieres que la respuesta se refiera con precisión a ese material y no sea alucinada
Si una de las tres no se cumple, no necesitas RAG. Si tu material cabe en un contexto de chat, pégalo y ya. Si no tienes datos privados y la información estándar basta, ChatGPT solo es suficiente.
Cómo se construye un sistema RAG
El esqueleto siempre tiene las mismas cuatro partes:
- Tus documentos en algún sitio. PDFs, Word, bases de datos, da igual.
- Un cortador que parte esos documentos en piezas más pequeñas, llamadas chunks. Normalmente unos cuantos párrafos por chunk.
- Una base de datos vectorial que guarda esos chunks de modo que se puedan buscar semánticamente (no "qué chunks contienen la palabra X" sino "qué chunks significan más o menos lo mismo que mi pregunta").
- Una aplicación que coge tu pregunta, busca en la BD vectorial, saca los chunks más relevantes, los mete con la pregunta en el prompt y genera la respuesta.
Eso es RAG. Arquitectura completa en cuatro frases.
Por qué búsqueda semántica y no por palabra clave
Porque la búsqueda por palabra clave falla cuando tu usuario formula distinto que tu documento. Si el manual dice "usamos autenticación por magic link" y el usuario pregunta "cómo entro sin contraseña", una búsqueda por palabra clave no encuentra nada porque no coincide ninguna palabra. Una búsqueda semántica entiende que ambos textos significan lo mismo y encuentra el punto correcto.
La magia ocurre con los llamados embeddings. Listas largas de números que representan un bloque de texto y que se pueden comparar matemáticamente. Si dos textos significan cosas parecidas, sus embeddings están cerca matemáticamente. Eso es todo.
No tienes que implementarlo tú. Hay herramientas listas que manejan los embeddings por ti. Metes texto, salen vectores, los guardas, buscas después.
Trampas típicas
Tamaño de chunk equivocado: Demasiado pequeño y el chunk no tiene contexto. Demasiado grande y entra mucho ruido. El sweet spot suele estar en 300 a 800 palabras por chunk.
Faltan metadatos: Si no guardas de qué documento viene un chunk, no puedes citar fuentes. Guarda como mínimo título de documento + página + fecha.
Sin estrategia de actualización: ¿Qué pasa cuando un documento cambia? Si no lo vuelves a chunkear y a indexar, tu RAG da respuestas obsoletas. Un mecanismo de actualización es obligatorio.
Demasiados aciertos irrelevantes: Si tu BD vectorial devuelve treinta chunks por cada pregunta y la mayoría no tienen nada que ver, el modelo se confunde. Normalmente con cinco o diez basta. Calidad antes que cantidad.
RAG vs. contexto largo
Modelos nuevos tienen ventanas de contexto de un millón de tokens. Es decir, podrías teóricamente pegar un libro entero en lugar de montar RAG. ¿Cuándo merece la pena?
Para un uso único: pega el libro y pregunta. Listo.
Para uso repetido por muchos usuarios y muchas preguntas: sigue siendo RAG. Los tokens cuestan dinero. Con 1000 consultas al día, cada una copiando el libro, sale carísimo. RAG saca solo los fragmentos relevantes y se ahorra el resto.
Lo que RAG NO puede
RAG no sustituye un buen entrenamiento. Si tu modelo no está entrenado en medicina, ni con los mejores documentos de RAG dará recomendaciones médicas sensatas. RAG da hechos al modelo. No cambia lo que el modelo puede hacer.
RAG tampoco sustituye consultas a base de datos. Si tu pregunta es "cuántos clientes ganamos esta semana", hace falta SQL, no RAG. Si es "qué dice nuestro email de bienvenida", RAG va bien.
Ejemplo concreto, cómo usa RAG un despacho de abogados
Un despacho tiene 2.000 PDFs de sentencias en el archivo. Cada abogado consulta regularmente para sus casos. Los PDFs no caben todos en el contexto de Claude y buscar a mano en la intranet tarda.
Solución: el despacho pasa todos los PDFs por un sistema RAG, una vez. Luego el abogado pregunta en una interfaz de Claude "¿hubo una sentencia sobre gastos por trabajo en casa antes de 2024?" y recibe tres sentencias relevantes con cita y referencia. Ahorro de tiempo: 30 minutos por pregunta. La tasa de errores baja porque Claude ahora cita sentencias concretas en lugar de inventárselas.
Eso es RAG en la práctica.
Qué puedes hacer ya
Si quieres construir RAG tú: hay kits listos: LlamaIndex, LangChain, Haystack para Python. Vercel AI SDK para JavaScript. Todos con tutoriales para los primeros pasos.
Si quieres usar RAG sin construir: ChatGPT tiene "Custom GPTs" con subida de archivos, Claude tiene "Projects" con su área de conocimiento, ambos lo hacen automáticamente para conjuntos pequeños de documentos. Eso es RAG para no-developers empaquetado en la interfaz de chat normal.
Cómo sigue
En el Nivel 4 mostramos cómo distribuir no solo documentos sino también memoria y knowledge graphs de forma portable entre varias herramientas de IA. Eso va un paso más allá de RAG: no solo "buscar documentos" sino "guardar y enlazar conocimiento estructurado".
Y en el Nivel 6 construyes tú mismo el backend, como tu propio MCP server con conexión a BD vectorial. Entonces no solo sabes qué es RAG, sino que tienes tu propio servicio RAG que encaja con tu proyecto.