¿Cuándo aparece la necesidad? (el momento exacto)
La necesidad surge en un momento muy concreto: cuando tu IA tiene que trabajar con mucha información a la vez y empieza a fallar. Señales típicas: subes 30 PDFs y la IA "se olvida" de la mitad; le pegas un manual largo y responde mezclando cosas o inventando; o tienes que pegar el mismo documentón en cada conversación porque no lo retiene. Ahí es cuando alguien te dice "necesitas un RAG".
RAG en cristiano (sin una sola palabra técnica)
RAG significa "generación aumentada por recuperación". Suena horrible, pero la idea es simple: en vez de meterle TODOS tus documentos a la IA cada vez (carísimo e imposible si son muchos), guardas tus documentos aparte y, cuando preguntas algo, un buscador recupera solo los pedacitos relevantes y se los pasa a la IA para que responda con eso. Buscar primero, responder después.
La gran ventaja extra: como la IA responde a partir de pedazos concretos de TUS documentos, puede citarte la fuente ("esto sale del manual, página 12"). Eso es lo que mata las invenciones: si no está en tus documentos, no se lo inventa.
El gran beneficio: RAG ahorra MUCHOS tokens (cuando el corpus es grande)
Aquí está la razón principal por la que existe el RAG, y no es menor: el ahorro de dinero. Cada palabra que le metes a la IA cuesta tokens, y los tokens cuestan plata. Si tienes 5.000 páginas de documentos y se las pegas enteras en CADA pregunta, pagas una fortuna (y muchas veces ni siquiera caben). El RAG resuelve eso: en vez de mandar las 5.000 páginas, manda solo los 3 o 4 pedacitos que de verdad responden tu pregunta.
¿Por qué se llaman "chunks"? (la pieza clave del RAG)
Chunk en inglés significa "pedazo" o "trozo". Es la pieza central del RAG, así que vale entenderla. Tus documentos NO se guardan enteros: se cortan en pedazos pequeños —cada chunk suele ser un párrafo o un par de ellos— y cada pedazo se guarda con una especie de "huella de su significado".
La regla de oro · ¿de verdad necesitas RAG?
Aquí está el dato que casi ningún "gurú" te dice, y viene de la propia Anthropic (los creadores de Claude). La regla es sorprendentemente generosa:
¿Por qué importa tanto? Porque 500 páginas es muchísimo para la mayoría de los proyectos. Tu manual de marca, tus plantillas, las políticas de tu negocio, un par de libros… normalmente cabe. Y si cabe, montar un RAG es complicarte la vida sin razón. RAG es para cuando de verdad te pasas de ese tamaño: bibliotecas enormes, miles de documentos, datos que cambian todo el tiempo.
- Tu material NO cabe en ~500 páginas (miles de documentos, una base de datos grande, años de transcripciones).
- La información cambia seguido y no quieres re-pegar todo cada vez.
- Estás construyendo una app para muchos usuarios que consultan un corpus grande (ej. un asistente que responde sobre toda tu documentación).
- Necesitas citas a la fuente de forma sistemática y a gran escala.
- Tu material cabe en ~500 páginas → pégalo en el contexto. Con prompt caching, repetirlo sale barato — más que montar un RAG.
- Solo quieres que la IA recuerde tus reglas y tu proyecto → eso es memoria (escalón 1), no RAG.
- Tienes un puñado de documentos que consultas de vez en cuando → súbelos al chat cuando los necesites.
- Apenas estás empezando → casi seguro estás a uno o dos escalones por debajo de RAG.
La escalera completa (para que veas dónde encaja RAG)
RAG no es el primer paso ni el último — es un peldaño en una escalera. Súbela en orden, no te saltes peldaños por moda:
- 1 · Memoria / contexto — tus reglas y tu proyecto en un archivo o en el chat. Para casi todo. (Escalón 1 de la serie.)
- 2 · Pegar todo + caching — si tu material cabe en ~500 páginas, métele todo. Sin RAG.
- 3 · RAG sin código — cuando es demasiado: un buscador que trae los pedazos relevantes. (Esta guía.)
- 4 · RAG "de verdad" — para apps a escala, con base de datos vectorial. Open-source, ya con algo de técnica.
- 5 · Grafo de conocimiento — cuando además necesitas que la IA entienda CÓMO se conecta todo. (Graphify, al final.)
Las 3 formas de implementar un RAG (elige según tu nivel)
No hay una sola manera de montar un RAG: hay tres, de menos a más esfuerzo y poder. Lo importante es elegir la que de verdad te corresponde, no la más impresionante. Aquí están, y luego vamos una por una:
- Forma 1 · Sin código — arrastras documentos a una herramienta lista (NotebookLM, Custom GPT). Cero técnica. Para la mayoría.
- Forma 2 · Con un repo open-source — instalas algo como RAGFlow o AnythingLLM, control total, gratis. Tu agente de código te ayuda.
- Forma 3 · A la medida (superaplicación) — construyes tu propio motor para una app a gran escala. Nivel ingeniero. Te muestro cómo es el nuestro.
Forma 1 · Montar un RAG SIN escribir código (la vía fácil)
Si pasaste el filtro y de verdad te toca RAG, buenas noticias: no necesitas programar ni montar bases de datos. Hay herramientas donde arrastras tus documentos y listo, ya tienes tu buscador inteligente con citas. Dos que cualquiera puede usar hoy:
Forma 2 · Con un repo open-source (más control)
Cuando tu proyecto crece o quieres tener el control en tu propio servidor, hay herramientas open-source potentes y gratuitas. Las dos más amigables para no-expertos (tu IA te ayuda a instalarlas):
RAGFlow — motor de RAG open-source líder, pensado para no-developers: armas tu pipeline de forma visual y entiende documentos complejos (Word, PDFs, Excel, escaneos, imágenes). Responde con citas a la fuente. Fusiona RAG con capacidades de agente.
AnythingLLM — app de escritorio "todo en uno" para tener tu propio chat con RAG sobre tus documentos, local y privado. "Deja de alquilar tu inteligencia, hazla tuya." Ideal si quieres que tus datos no salgan de tu máquina.
Quiero montar un RAG open-source sobre mis documentos usando uno de estos repos: - RAGFlow (https://github.com/infiniflow/ragflow) — RAG visual, ideal si quiero algo completo. - AnythingLLM (https://github.com/Mintplex-Labs/anything-llm) — app de escritorio, local y privada. Guíame paso a paso en lenguaje simple, asumiendo que no sé programar: 1. Ayúdame a elegir cuál me conviene según mi caso: [describe tus documentos, si quieres que todo sea local/privado, y tu sistema operativo]. 2. Dime cómo instalarlo (con sus requisitos, ej. Docker) y hazlo tú donde puedas. 3. Ayúdame a subir mis documentos y crear la base de conocimiento. 4. Configúralo para que responda SOLO con lo que está en mis documentos y SIEMPRE cite la fuente. 5. Dame 3 preguntas de prueba para confirmar que está leyendo bien mis documentos. Si algún paso tengo que hacerlo yo a mano, dímelo con instrucciones exactas.
Forma 3 · El RAG de una superaplicación (así funciona el nuestro)
La tercera forma es la más seria: cuando construyes una superaplicación —una plataforma con muchísima información y muchos usuarios— ninguna herramienta llave en mano te alcanza. Ahí construyes tu propio motor de RAG a la medida. Es nivel ingeniero (lo haces tú o tu equipo dirigiendo agentes de código), pero te lo mostramos por dentro, sin humo, para que veas a dónde puede llegar: así funciona el motor de RAG que usamos en nuestras aplicaciones.
- Base vectorial: PostgreSQL con la extensión
pgvector(sobre Supabase) + un índice HNSW para buscar rápido entre cientos de miles de vectores. - Embeddings: el modelo que convierte cada chunk en su "huella de significado" — Gemini de 768 dimensiones, en tier gratis (costo $0).
- Escala: más de 15.000 chunks indexados (documentos, código, notas) — imposible de meter en un chat; aquí RAG no es un lujo, es la única forma.
- Búsqueda híbrida: 70% por significado (vectorial) + 30% por palabra exacta (texto), con re-ranking que sube lo más relevante. Más certero que cualquiera de las dos sola.
- Índice que se auto-cuida: el sistema re-indexa lo dañado, marca lo viejo y descarta lo inservible — el RAG se mantiene sano solo. (Esto es mantenimiento del buscador, no la "memoria del usuario" — esa es otra pieza, la del brain.)
- Chunks de ~200 tokens cada uno: el tamaño dulce entre "trae el párrafo justo" y "no pierdas el contexto".
Cópialo y pégaselo a tu agente de código (Claude Code, Cursor) cuando vayas a construir un RAG a la medida. Trae integradas las decisiones que a nosotros nos funcionan, para que arranque sobre terreno sólido en vez de improvisar:
Vas a ayudarme a construir un RAG a la medida para una aplicación a gran escala. NO escribas código todavía. Primero PLANIFICA conmigo, porque el error más caro es codear sin haber decidido la arquitectura. PASO 1 — Entrevístame (una pregunta a la vez, en lenguaje simple): - ¿Qué información va a indexar el RAG y cuánta? (tipos de documento, volumen aproximado) - ¿Cuántos usuarios y cuántas consultas por día esperas? - ¿Los datos cambian seguido? ¿Necesito borrar/actualizar chunks? - ¿Es multi-inquilino (varios clientes con datos separados)? ¿Hay datos sensibles? - ¿Qué stack ya uso (base de datos, lenguaje, dónde está alojado)? PASO 2 — Propón la arquitectura, usando estas decisiones probadas como punto de partida (y dime si en mi caso conviene cambiarlas y por qué): - Base vectorial: PostgreSQL + pgvector con índice HNSW (si ya uso Postgres/Supabase, reutilízalo). - Embeddings: un modelo económico o gratis (ej. Gemini), guardando la dimensión que elijas. - Chunking: pedazos de ~200 tokens con un poco de solape, y guarda metadatos (fuente, fecha, sección). - Búsqueda híbrida: combina vectorial + texto exacto, y un re-ranking para subir lo más relevante. - Aislamiento: si es multi-inquilino, filtra SIEMPRE por el id del cliente en cada consulta. PASO 3 — Dame un PLAN POR FASES (qué construir primero, qué dejar para después) con una fase mínima que funcione end-to-end antes de optimizar. PASO 4 — Lista los 5 errores más comunes en un RAG de producción y cómo evitarlos desde el día uno (ej. no filtrar por inquilino, chunks mal cortados, no manejar actualizaciones, confiar sin citar la fuente, no medir la calidad de las respuestas). Cuando aprobemos el plan, recién ahí empezamos a construir la fase 1, paso a paso, y guardamos el progreso en GitHub en cada fase que funcione.
Prompt 1 · Diagnóstico — ¿necesito RAG o no?
Antes de montar nada, deja que tu IA te diga en qué escalón estás de verdad. Cópialo y pégaselo a ChatGPT, Claude o tu agente:
Quiero saber si de verdad necesito un RAG o si me estoy complicando. Hazme estas preguntas una por una, espera mi respuesta, y al final dime en qué escalón estoy y por qué: 1. ¿Cuántos documentos tengo, aproximadamente, y de qué tamaño? (un cálculo grueso de páginas total) 2. ¿Esa información cambia seguido o es estable? 3. ¿Necesito que me cite la fuente de cada respuesta? 4. ¿Es para mí solo, o para una app que usarán muchas personas? 5. ¿Qué herramienta de IA uso hoy? Reglas para tu recomendación: - Si todo mi material cabe en ~500 páginas (unos 200.000 tokens), dime que NO necesito RAG: que pegue todo en el contexto, es más simple y preciso. - Si es claramente más que eso, o cambia mucho, o es para muchos usuarios, recomiéndame RAG y dime si la vía sin código (NotebookLM / Custom GPT) me alcanza o si necesito algo open-source. - No me empujes a sobre-ingeniería. Recomiéndame el escalón MÁS SIMPLE que resuelva mi caso, y justifícalo.
Prompt 2 · Monta tu mini-RAG sin código y a prueba de invenciones
Si el diagnóstico dijo "sí, RAG sin código", este prompt te guía a montarlo y, sobre todo, a verificar que de verdad esté leyendo tus documentos y no inventando:
Voy a montar un RAG sin código para consultar mis documentos. Guíame paso a paso, en lenguaje simple, asumiendo que no sé programar. 1. Recomiéndame entre NotebookLM (gratis) y un Custom GPT de ChatGPT según mi caso: tengo [describe tus documentos: cuántos, de qué tipo, para qué los consultaré]. 2. Dime los pasos exactos (con clics) para crear el espacio y subir mis documentos. 3. Redáctame las instrucciones que debo ponerle para que responda SOLO con lo que está en mis documentos, cite la fuente, y diga claramente "no está en los documentos" en vez de inventar. 4. Dame 3 preguntas de prueba para confirmar que de verdad está leyendo mis documentos (y no respondiendo de memoria general). 5. Dime cómo darme cuenta si está inventando, y qué ajustar si pasa. Hazlo simple. Si algo solo lo puedo hacer yo en la web, dímelo con los clics exactos.
Errores típicos (para que no caigas)
El siguiente escalón · de una pieza al cerebro completo
El RAG es una pieza poderosa, pero es solo una: busca en tus documentos. Cuando construyes una app de verdad, esa app necesita además recordar a cada usuario y, a veces, entender cómo se conecta todo. Las tres cosas juntas —RAG + memoria + grafo— forman lo que se llama un brain, el cerebro propio de tu app. Ese es el siguiente recurso, y junta todo lo que has visto.
El brain · dale a tu app un cerebro propio (el siguiente escalón)El RAG es una de sus piezas. El brain las junta todas: lo que tu app sabe y lo que recuerda de cada usuario.La memoria de tu IA · el escalón 1 (si te lo saltaste)Antes de RAG, casi siempre lo que necesitas es memoria simple. Empieza por aquí.