Qué es RAG, explicado con un caso real

RAG (retrieval augmented generation, o generación aumentada por recuperación) es una técnica en la que un sistema de inteligencia artificial, antes de responder, busca en tu propio contenido los fragmentos más relevantes para la pregunta y se los pasa al modelo de lenguaje con la instrucción de contestar a partir de ellos. El modelo no aprende tu contenido. Lo lee justo a tiempo, cada vez.

Las búsquedas de «qué es RAG» en español crecen rápido: según datos de Google Ads, en México el promedio es de 390 al mes y los últimos tres meses rondan los 517, un 72 % más que los tres primeros del año; en España, el promedio también es de 390 y los últimos tres meses rondan los 463, un 54 % más. Preferimos explicarlo con un sistema en producción y no con un diagrama: el de ChatWise, nuestro producto de chat de soporte, que responde en un sitio web y en WhatsApp a partir del contenido de cada negocio. Cada número que verás sobre ChatWise sale de su código.

El problema que resuelve RAG

Un modelo de lenguaje sabe lo que vio durante su entrenamiento. Eso deja tres huecos cuando lo pones a atender a tus clientes:

• No conoce tu contenido. Tus horarios, tus políticas de devolución y tu catálogo nunca estuvieron en sus datos de entrenamiento.
• Inventa cuando no sabe. Si le preguntas algo que desconoce, tiende a producir una respuesta plausible en lugar de decir que no sabe. Eso es una alucinación.
• Su conocimiento tiene fecha. Aunque supiera algo de tu empresa, sería la versión de hace meses.

RAG ataca los tres a la vez: el conocimiento vive fuera del modelo, en un índice que tú controlas y actualizas, y el modelo solo redacta la respuesta con lo que el índice le entrega.

La alternativa que se suele mencionar es el fine-tuning, que reentrena el modelo con ejemplos tuyos. Sirve para cambiar cómo se comporta (el tono, el formato, una tarea muy específica), pero es una mala forma de enseñarle hechos que cambian: cada actualización exige otro entrenamiento, y no puedes señalar de qué documento salió una respuesta. Con RAG, cambiar un precio es volver a indexar una página.

Cómo funciona RAG, paso 1: indexar el contenido

Antes de responder cualquier pregunta, hay que preparar el contenido. Este trabajo se hace una vez por documento y se repite cuando el documento cambia.

1. Reunir el contenido. Páginas web, PDF, documentos de texto, preguntas frecuentes. Se convierten a texto plano o Markdown.
2. Dividirlo en fragmentos (chunks). Un documento entero es demasiado grande y demasiado general para compararlo con una pregunta. Se corta en pedazos de unos cientos de palabras, normalmente con algo de solapamiento para que una idea no quede partida a la mitad.
3. Calcular el embedding de cada fragmento. Un modelo de embeddings convierte cada fragmento en un vector: una lista de cientos o miles de números que representa su significado. Dos textos que dicen cosas parecidas quedan con vectores cercanos, aunque usen palabras distintas.
4. Guardarlo en una base de datos vectorial con metadatos. Junto a cada vector se guarda el texto original y datos como la URL, el número de página o el documento de origen. Esos metadatos son los que después permiten citar la fuente.
5. Separar por cliente o por sitio. Si el sistema atiende a varios negocios, cada uno necesita su propia colección. Así una búsqueda de un negocio nunca puede devolver texto de otro.

Cómo funciona RAG, paso 2: responder la pregunta

Cuando llega una pregunta, el sistema hace esto:

1. Calcula el embedding de la pregunta con el mismo modelo que se usó para los fragmentos. Tiene que ser el mismo: los vectores de modelos distintos no se pueden comparar.
2. Recupera los fragmentos más cercanos (los top-k, por ejemplo los cinco más parecidos).
3. Opcionalmente, mejora esa lista. Un reranker puede reordenar los candidatos con un modelo más preciso, y la búsqueda híbrida puede sumar resultados de búsqueda por palabras clave.
4. Arma el prompt: las instrucciones del sistema, los fragmentos recuperados y la pregunta, con la indicación de responder solo a partir de ese contexto.
5. Genera la respuesta con el modelo de lenguaje.
6. Cita o deriva. Lo ideal es guardar qué fragmentos se usaron, para mostrarlos o auditarlos, y tener un camino de salida cuando el contenido no alcanza: decir que no se sabe o pasar la conversación a una persona.

El caso real: cómo lo hace ChatWise

ChatWise tiene un backend en Python (FastAPI) que se encarga de todo el pipeline de RAG, construido con LlamaIndex y Qdrant como base de datos vectorial. Esto es lo que hace en cada paso, según su código.

Indexación

• Fuentes. Un negocio puede cargar archivos, URLs, texto pegado o un sitemap. Los PDF se leen página por página y cada página guarda su número. Las URLs se descargan con un servicio de scraping (Firecrawl) y se guardan como Markdown. El texto pegado debe tener entre 50 y 100.000 caracteres y se sube como un archivo más. Con un sitemap, el sistema descubre todas las URLs, crea una fuente por cada una que no exista todavía y encola su propia tarea.
• Cola de trabajo. Cada fuente genera una tarea en Postgres que toma un proceso aparte. Si una tarea falla, se reintenta sola, y la fuente queda marcada como fallida cuando se agotan los reintentos. También existe una tarea de reindexación, así que cualquier fuente se puede procesar de nuevo.
• Fragmentos. ChatWise usa el divisor por oraciones de LlamaIndex con su configuración estándar, que corta en fragmentos de hasta 1.024 tokens con 200 tokens de solapamiento.
• Embeddings. Por defecto, el modelo text-embedding-3-large de OpenAI, que produce vectores de 3.072 dimensiones. Un sitio puede configurar otro modelo, y el tamaño del vector de su colección se fija según ese modelo al crearla.
• Almacenamiento. Cada sitio recibe su propia colección en Qdrant, con un nombre aleatorio y distancia coseno. Cada fragmento lleva como metadatos el id de la fuente, el id del sitio, el tipo de fuente y, según el caso, la URL, el nombre del archivo o el número de página.

Al momento de la pregunta

• Primero, decidir si es una pregunta para RAG. Un modelo de lenguaje actúa como enrutador: lee el mensaje y devuelve un JSON con el destino y su nivel de confianza. Si duda, o si algo falla, el mensaje va a RAG por defecto. La derivación a una persona está reservada a pedidos explícitos («quiero hablar con un agente») y pasa por una segunda validación que descarta, sin gastar otra llamada al modelo, mensajes como «gracias» u «ok». Cómo se diseña ese traspaso lo contamos en chatbot RAG con tu propio contenido.
• La pregunta incluye la conversación. ChatWise busca con el último mensaje y también con lo que se habló antes: arma una consulta con hasta once mensajes anteriores y la pregunta actual («Contexto de la conversación hasta ahora: … Mensaje más reciente del usuario: …»). Ese texto completo es el que se convierte en embedding y se busca. Gracias a eso, una pregunta como «¿y cuánto cuesta?» llega con el contexto de qué producto se estaba hablando.
• Recuperación. Hace una búsqueda vectorial en la colección del sitio y se queda con los 5 fragmentos más parecidos, con la conversación ya incluida en la consulta.
• Prompt. Concatena el prompt de sistema que configuró el negocio, los fragmentos recuperados entre separadores y la instrucción de responder «con la información del contexto y no con conocimiento previo».
• Generación. Un modelo de lenguaje redacta la respuesta, con respaldo en modelos de otros proveedores: si uno falla, prueba el siguiente.
• Fuentes. Cada respuesta que sale de la base de conocimiento se guarda junto con los fragmentos que la sustentaron: su id, su puntaje de similitud, el tipo de fuente y sus metadatos (la URL o la página del PDF). También se registran tokens y latencia.

Tres reglas de recuperación que aplicamos en otros sistemas

ChatWise no es el único sistema donde recuperamos información. En los que usamos para la memoria de nuestros propios agentes (los describimos en memoria de agentes de IA en la práctica) aplicamos tres reglas que sirven para cualquier RAG.

Combina búsqueda semántica con búsqueda de texto completo. La búsqueda por vectores encuentra significados parecidos, pero falla justo con lo que la gente más busca de forma literal: nombres de producto, identificadores y códigos de error. En nuestro buscador de sesiones pasadas usamos vectores más BM25 (búsqueda por palabras clave) y fusionamos ambas listas con reciprocal rank fusion, que premia lo que aparece arriba en cualquiera de las dos. Recomendamos la búsqueda híbrida para cualquier RAG cuyos usuarios busquen nombres, códigos o siglas.

Usa un solo modelo de embeddings por sistema. Cada modelo produce su propio espacio de vectores, así que cambiarlo obliga a recalcular todo el corpus. En nuestro servicio de memoria usamos Qwen3-Embedding-8B a través de la API de Tessera. El modelo produce 4.096 dimensiones y admite truncarlas; guardamos 1.536 porque el índice HNSW de pgvector sobre el tipo vector tiene un límite de 2.000 dimensiones. ChatWise, en cambio, usa text-embedding-3-large con 3.072 dimensiones en Qdrant. Son sistemas distintos con modelos distintos, y cada uno usa el mismo modelo para indexar y para preguntar. En el código de ChatWise esa regla está a la vista: el tamaño del vector de cada colección queda fijado por el modelo al crearla.

Mantén el índice reconstruible desde la fuente. Una actualización de la herramienta de búsqueda puede cambiar el formato del índice. Nuestro buscador de sesiones genera su índice a partir de resúmenes en Markdown, así que ante un cambio de formato basta con apartar el índice anterior y reconstruirlo desde esos resúmenes, sin perder nada. El índice es un derivado; la fuente es lo que hay que cuidar. ChatWise sigue el mismo principio: guarda los archivos y las URLs originales de cada fuente, así que la reindexación es una tarea más de la cola.

RAG, fine-tuning o un LLM wiki

Hay tres formas comunes de darle conocimiento a un sistema con IA, y resuelven problemas distintos:

Las opciones no se excluyen. Nuestra empresa opera sobre un LLM wiki, y nada impide montar RAG encima de él.

¿Cuándo necesitas RAG?

Tiene sentido cuando se cumplen varias de estas condiciones:

• Tu contenido es más grande de lo que cabe cómodamente en un prompt.
• Cambia con frecuencia: precios, inventario, políticas, documentación.
• Necesitas saber de dónde salió cada respuesta.
• Atiendes a varios clientes o sitios y su información debe quedar separada.

Probablemente no lo necesitas si todo tu contenido cabe en un prompt de sistema (unas pocas páginas de preguntas frecuentes), o si lo que buscas es cambiar el estilo del modelo y no lo que sabe. Y antes de ponerlo frente a clientes, mide si recupera los fragmentos correctos: lo explicamos en las evals que de verdad necesitas.

Si estás evaluando RAG para tu soporte o tus documentos internos, hablemos. Es parte de los agentes de IA y automatizaciones que construimos y operamos para nuestros clientes.