RAG (Retrieval Augmented Generation)

RAG (en inglés *Retrieval Augmented Generation*, o generación aumentada por recuperación) es una técnica de IA que le da a un modelo de lenguaje acceso a una fuente de conocimiento externa en el momento de responder. En lugar de depender solo de lo que el modelo memorizó durante su entrenamiento, RAG busca primero los documentos o datos relevantes a la pregunta y luego genera la respuesta apoyándose en ese material recuperado.

El flujo tiene dos etapas que le dan el nombre. Primero la recuperación (*retrieval*): el sistema convierte la pregunta del usuario en una búsqueda, normalmente sobre una base de datos vectorial, y trae los fragmentos más parecidos. Después la generación: esos fragmentos se insertan en el prompt junto con la pregunta, y el LLM redacta una respuesta fundamentada en ese contexto. Por eso se dice que RAG aumenta al modelo: le suma información que no estaba en sus parámetros.

Es la arquitectura que permite que un agente de IA responda sobre los documentos, políticas o catálogo de tu empresa en vez de hablar en general. Es parte de la base técnica de los agentes de IA conectados a Salesforce: el agente consulta el conocimiento de la organización antes de contestarle a un cliente.

Por qué existe RAG

Un modelo de lenguaje tiene dos limitaciones estructurales. La primera es la fecha de corte: solo sabe lo que existía hasta el momento de su entrenamiento, así que ignora una política que cambiaste la semana pasada o el stock de hoy. La segunda es que no conoce tus datos privados: nunca vio tu manual de procedimientos, tu base de clientes ni tus contratos. Encima, cuando no sabe algo, el modelo tiende a inventar una respuesta con tono seguro, lo que se conoce como alucinación. RAG ataca los tres problemas a la vez: en lugar de pedirle al modelo que recuerde, le entrega la información correcta en cada consulta.

Cómo funciona, paso a paso

El proceso se arma en dos fases. La fase de preparación ocurre una sola vez (y se repite cuando agregás contenido): se toman los documentos, se parten en fragmentos manejables (*chunks*), se transforman en embeddings (vectores numéricos que capturan el significado) y se guardan en una base de datos vectorial. La fase de consulta ocurre en cada pregunta:

• El usuario hace una pregunta y el sistema la convierte también en un embedding.
• Se busca por similitud semántica qué fragmentos guardados se parecen más a la pregunta (no por palabras exactas, sino por significado).
• Los fragmentos más relevantes se inyectan en el prompt como contexto, una práctica llamada grounding (anclar la respuesta en evidencia).
• El LLM genera la respuesta usando ese contexto y, idealmente, cita la fuente de donde sacó cada dato.

La clave es que el modelo no aprende nada nuevo de forma permanente: cada respuesta se construye con la información fresca que se le pasó en ese momento, dentro de su ventana de contexto.

Por qué importa para un negocio

RAG es lo que vuelve confiable y auditable a un asistente de IA en un entorno empresarial. Sin RAG, un chatbot de atención podría inventar una condición de garantía; con RAG, responde con el texto exacto de tu política y muestra de qué documento lo sacó. Hay tres beneficios concretos: la respuesta queda siempre actualizada (basta actualizar el documento fuente, sin reentrenar nada), se reduce drásticamente la invención de datos, y el equipo de cumplimiento puede rastrear el origen de cada afirmación.

Ejemplo concreto (LATAM)

Una distribuidora mayorista en Argentina monta un agente de IA sobre WhatsApp para que sus vendedores consulten precios, condiciones de pago y disponibilidad. La lista de precios cambia cada 15 días por inflación. Con un modelo pelado sería imposible: respondería con precios viejos o inventados. Con RAG, cada vez que un vendedor pregunta cuál es el precio de un SKU para un cliente puntual, el agente recupera la lista vigente y la grilla de descuentos de ese cliente desde el sistema, y genera una respuesta exacta citando la lista del día. Cuando el área comercial sube la lista nueva, el agente queda actualizado al instante, sin tocar el modelo.

RAG frente a fine-tuning

Es la comparación más útil para entender RAG, porque son dos formas distintas de especializar una IA y suelen confundirse. El fine-tuning reentrena el modelo para que cambie su comportamiento o estilo; RAG le da datos frescos sin tocar el modelo. No compiten: muchas soluciones serias usan las dos.

Errores comunes al implementar RAG

• Fragmentar mal los documentos: chunks demasiado grandes o cortados a la mitad de una idea hacen que la búsqueda traiga contexto pobre y la respuesta falle.
• Confundir RAG con búsqueda por palabras clave: RAG busca por significado (semántica), no por coincidencia de texto; encontrar un número de factura exacto a veces requiere combinar ambos métodos (búsqueda híbrida).
• No mostrar las fuentes: si el agente no cita de dónde sacó cada dato, se pierde la principal ventaja de auditabilidad.
• Creer que RAG elimina toda alucinación: la reduce mucho, pero si el documento correcto no se recupera, el modelo puede igual inventar. Por eso conviene sumar guardrails y, en casos sensibles, un human-in-the-loop.

En definitiva, RAG es hoy la arquitectura por defecto para llevar la IA generativa a casos de negocio reales: combina la fluidez del lenguaje del modelo con la precisión y actualidad de tus propios datos, sin el costo ni la opacidad de reentrenar.