RAG vs Agentes

RAG recupera documentos y se los pasa a un modelo para responder con contexto propio. Un agente de IA decide y ejecuta acciones con herramientas. No son equivalentes: RAG cubre memoria; el agente cubre operación. En sistemas reales suelen combinarse.

Muchas personas creen que cuando hablamos de un sistema RAG y un sistema de agentes estamos hablando de algo similar, cuando la realidad es que no. ¿Ambos usan IA como componente principal? Sí, pero tienen objetivos muy diferentes. En este artículo mi objetivo es aclararte todas las dudas para que puedas entender los puntos fuertes de cada uno de estos sistemas y, sobre todo, cuándo conviene usar cada uno.

---

¿Qué es un sistema RAG?

RAG, cuyas siglas significan Retrieval Augmented Generation, es una arquitectura que combina la recuperación de información relevante con la generación de texto. En términos simples, su funcionamiento se puede resumir en 4 pasos:

1. El usuario hace una pregunta.
2. El sistema busca información relevante dentro de una base de datos vectorial.
3. Esa información es inyectada como contexto en un modelo de lenguaje (LLM).
4. El LLM genera una respuesta basándose tanto en la pregunta del usuario como en la información recuperada.

Pero la verdad es que no es tan sencillo como parece.

¿Qué resuelve?

Si alguna vez trabajaste con algún LLM como Claude, ChatGPT, Gemini, etc., posiblemente hayas notado que la información que generaba no siempre estaba actualizada, o que si le preguntabas algo muy específico, por ejemplo algo relacionado con tu empresa o industria, simplemente no sabía nada al respecto. Esto ocurre porque los modelos de lenguaje tienen una fecha de corte en su entrenamiento y, por defecto, no tienen acceso a información externa en tiempo real ni a documentos privados. Ahí es exactamente donde entra RAG.

RAG viene a solucionar exactamente esto. En lugar de depender únicamente del conocimiento con el que fue entrenado el modelo, esta arquitectura le permite al LLM consultar una fuente de información externa antes de generar su respuesta. Esa fuente puede ser cualquier cosa: la documentación interna de tu empresa, un conjunto de artículos, reportes, manuales, o incluso información actualizada en tiempo real. De esta forma, el modelo ya no responde "desde su memoria", sino basándose en información concreta y relevante que vos mismo le proporcionás.

Arquitectura y funcionamiento

Para entender cómo funciona RAG por dentro, hay que conocer tres componentes clave:

1. La base de datos vectorial

Cuando queremos que nuestro sistema tenga acceso a información específica, primero necesitamos procesarla y almacenarla. Esto se hace convirtiendo los documentos en vectores numéricos, llamados embeddings, que representan el significado semántico del texto. Estos vectores se guardan en una base de datos vectorial como Pinecone, Weaviate o ChromaDB, entre otras.

2. El proceso de recuperación (Retrieval)

Cuando el usuario hace una pregunta, esa pregunta también se convierte en un embedding. Luego el sistema compara ese embedding con todos los que están almacenados en la base de datos y recupera los fragmentos de texto más similares semánticamente. No busca palabras exactas, sino significado.

3. La generación aumentada (Augmented Generation)

Una vez recuperada la información relevante, esta se inyecta junto con la pregunta original en el prompt del LLM. El modelo entonces genera una respuesta basándose en ese contexto enriquecido, lo que resulta en respuestas mucho más precisas y fundamentadas.

Ejemplo básico de arquitectura de un sistema RAG

---

¿Qué es un sistema de agentes?

Un agente de IA es un sistema donde el modelo de lenguaje no solo genera texto, sino que puede tomar decisiones, ejecutar acciones y encadenar múltiples pasos de forma autónoma para alcanzar un objetivo, ya sea ejecutar código en tu computadora, navegar por internet o cualquier otra cosa. En términos simples, la diferencia con RAG es fundamental: mientras RAG le da memoria al LLM, un agente le da capacidad de acción.

¿Qué resuelve?

Si alguna vez intentaste pedirle a un LLM que hiciera algo más complejo que responder una pregunta, por ejemplo que investigue un tema en internet, escriba un informe basándose en esa investigación y lo envíe por correo, te habrás dado cuenta de que solo no puede. Un LLM por defecto es reactivo: recibe un input, genera un output, y ahí termina su trabajo.

Los sistemas de agentes vienen a resolver exactamente eso. En lugar de limitarse a generar una respuesta, un agente puede interactuar con el mundo exterior: buscar en la web, ejecutar código, leer y escribir archivos, llamar APIs, enviar mensajes, o incluso coordinar otros agentes. El LLM sigue siendo el cerebro, pero ahora tiene manos. Entonces, esto nos abre un abanico de posibilidades, dado que ahora no solo podemos hacer una pregunta y esperar una respuesta, sino que también podemos pedirle al agente que ejecute múltiples acciones de forma autónoma.

Arquitectura y funcionamiento

Al igual que en un sistema RAG, hay ciertos puntos cruciales a conocer en un sistema de agentes:

1. El LLM como motor de decisiones

A diferencia de RAG, donde el LLM tiene un rol casi pasivo (recibe contexto y genera una respuesta), en un sistema de agentes el LLM es quien decide qué hacer en cada momento. Analiza la situación, elige qué herramienta usar, evalúa el resultado y decide si continuar o si ya tiene suficiente información para responder.

2. Las herramientas (tools)

Las herramientas son las capacidades que le damos al agente para interactuar con el mundo. Pueden ser tan simples como una búsqueda en Google o tan complejas como ejecutar código Python, consultar una base de datos, enviar un email o llamar a una API externa. El agente elige cuál usar según lo que necesite en cada paso.

3. El ciclo de razonamiento (loop)

Lo que hace único a un agente es su capacidad de operar en ciclos. El flujo básico es:

razona -> actua -> observa el resultado -> razona de nuevo

Este loop se repite hasta que el agente considera que completó la tarea. A este patrón se lo conoce como ReAct (Reasoning + Acting) y es la base de la mayoría de los sistemas agénticos modernos.

Ejemplo básico de arquitectura de un agente

---

Tabla comparativa entre las arquitecturas

Para que tengas una referencia clara a la hora de decidir cuál usar, acá va una comparación directa de los aspectos más relevantes de cada arquitectura.

¿Se pueden combinar?

Aunque a lo largo del artículo tratamos RAG y agentes como arquitecturas separadas, en la práctica pueden, y suelen, combinarse. En sistemas multiagente, RAG funciona como una herramienta más dentro del agente: cuando necesita información específica, la consulta y la usa para tomar mejores decisiones.

El siguiente diagrama ilustra cómo se vería esto:

Esto es apenas la punta del iceberg. En los próximos artículos voy a profundizar en cómo implementar cada una de estas arquitecturas, hablando de frameworks como LangChain y LlamaIndex, las herramientas más usadas en producción y los errores más comunes que vas a querer evitar.

Si todavía no está clara la mecánica de recuperación, partí por qué es un sistema RAG. Si el agente va a leer documentos o la web, el riesgo siguiente es prompt injection.

Preguntas frecuentes

¿Cuándo usar RAG y cuándo un agente?

Usá RAG cuando el problema es responder con información propia o actualizada. Usá un agente cuando el modelo tiene que buscar, escribir, llamar APIs o encadenar pasos. Si necesitás las dos cosas, el agente puede invocar RAG como una herramienta más.

¿Se pueden combinar RAG y agentes?

Sí. En sistemas multiagente, RAG suele ser una tool: el agente recupera contexto y después decide. Eso mejora las decisiones sin convertir al RAG en un operador. El diagrama de este artículo muestra exactamente ese patrón.

¿RAG y agentes usan el mismo LLM?

Pueden compartir el modelo, pero el rol cambia. En RAG el LLM genera una respuesta con contexto recuperado. En un agente el LLM elige herramientas, observa el resultado y vuelve a razonar hasta completar la tarea.