Los modelos de IA se entrenan con cantidades enormes de texto. Libros, artículos, webs, código, conversaciones. Pero ese entrenamiento tiene una fecha de corte, y sobre todo, no incluye tu negocio. No sabe cuánto cobras, no sabe cómo funciona tu proceso de devoluciones, no sabe nada de lo que es específicamente tuyo.

Cuando le preguntas algo sobre tu empresa, hace lo que puede: extrapola, asume, rellena. Y lo peor no es que se equivoque, es que lo dice con tanta seguridad que te lo crees.

Eso tiene solución. Se llama RAG.

RAG es lo que transforma un modelo genérico en un agente que conoce tu negocio. Sin RAG, improvisa. Con RAG bien configurado, responde.

La solución obvia sería reentrenar el modelo con tus datos. Pero eso no es viable para la mayoría de empresas: cuesta tiempo, dinero y conocimientos técnicos que pocos equipos tienen.

RAG es la alternativa elegante. En lugar de reentrenar el modelo, le das acceso a tu documentación justo antes de que responda. El modelo consulta, encuentra la información relevante, y genera la respuesta basándose en lo que acaba de leer.

Y para entender cómo funciona por dentro, hay cinco conceptos. Los vamos uno a uno.

Imagina que tienes el documento completo de un gimnasio: tarifas, horarios, normas, preguntas frecuentes. Veinte páginas.

No puedes meterle ese documento completo al modelo cada vez que alguien hace una pregunta. Sería lento, caro e ineficiente, el 90% del texto no tiene nada que ver con lo que se está preguntando.

Lo primero que hace RAG es trocear el documento en fragmentos pequeños. Se llaman chunks.

Cada chunk tiene un tamaño limitado, unos pocos párrafos, unas pocas frases. Y hay un pequeño solapamiento entre un chunk y el siguiente, para que si una respuesta cae justo en el límite entre dos trozos, no se pierda.

Aquí viene la parte que más cuesta entender al principio: los modelos de IA no procesan palabras, procesan números.

Cada chunk de texto se convierte en un vector: una lista de cientos o miles de números que representan el significado de ese texto. No las palabras exactas. El significado.

Esto es clave. Porque dos frases completamente distintas pueden tener vectores muy parecidos si significan lo mismo. "¿Cuánto cuesta apuntarse?" y "¿cuál es el precio de la membresía?" son frases diferentes, pero su significado es casi idéntico. Sus vectores estarán muy cerca el uno del otro.

Eso es lo que hace posible la búsqueda semántica: buscar por significado, no por palabras clave exactas.

El proceso de convertir texto en vectores se llama crear embeddings. Hay modelos específicos para esto, Gemini Embeddings, OpenAI Embeddings, que hacen esa conversión.

Una vez tienes los chunks convertidos en vectores, necesitas guardarlos en algún sitio.

Un vector store es una base de datos diseñada específicamente para guardar vectores y buscar entre ellos de forma eficiente. No es como una base de datos normal donde buscas por nombre o por fecha. Aquí buscas por similitud.

Le dices: "dame los vectores más parecidos a este", y el vector store encuentra los fragmentos de texto cuyo significado se acerca más a tu consulta.

Supabase, Pinecone o Chroma son ejemplos de vector stores. Aunque herramientas como n8n y Make también tienen su vector store interno, así que no siempre es necesario usar uno externo.

Llega la pregunta del usuario. Por ejemplo: "¿hay descuento para estudiantes?"

Esa pregunta también se convierte en un vector, usando el mismo modelo de embeddings que usaste para los chunks.

Ese vector se compara con todos los que tienes guardados en el vector store. El sistema calcula qué chunks son más similares semánticamente a la pregunta. Y devuelve los más relevantes, en este caso, el chunk que habla de tarifas especiales y colectivos con descuento.

Solo esos chunks (los relevantes) se pasan al modelo como contexto.

Ahora el modelo tiene dos cosas: la pregunta del usuario y los fragmentos de documentación relevante que acaba de recuperar.

Con eso genera la respuesta.

Si la información está en los chunks, la usa. Si no está, puede decir que no la tiene, en lugar de fabricársela.

Eso es RAG. Retrieval: recuperar los fragmentos relevantes. Augmented: aumentar el contexto del modelo con esa información. Generation: generar la respuesta con ese contexto.

Tienes el documento de Iron Valley Gym: tarifas, horarios, FAQ.

Lo troceas en chunks. Los conviertes en embeddings con Gemini. Los guardas en un vector store.

Llega un email: "Hola, tengo 22 años y estoy en la universidad, ¿hay algún descuento para mí?"

La pregunta se convierte en vector. Se busca en el vector store. Se recuperan los chunks de tarifas especiales. El agente responde: "Sí, tenemos un 20% de descuento para estudiantes hasta 26 años, solo necesitas el carnet de estudiante vigente."

No inventó nada. Consultó, recuperó, respondió.

RAG no es un detalle técnico para ingenieros. Es la arquitectura que decide si un agente de IA es útil o un riesgo para tu negocio.

Si estás evaluando implementar un chatbot de atención al cliente, un agente interno de soporte o cualquier herramienta que responda preguntas sobre tu empresa, antes de elegir plataforma, antes de hablar con ningún proveedor, necesitas entender si la solución usa RAG y cómo está configurada.

Una mala configuración de RAG (documento desactualizado, chunks demasiado pequeños, embeddings incompatibles entre indexación y búsqueda) produce respuestas incorrectas con total seguridad. Y eso es peor que no tener el agente.

Si prefieres verlo explicado paso a paso, grabé un vídeo donde recorro todo esto de RAG en directo, con el agente montado desde cero. Lo tienes aquí.