RAG vs workflow automatizado: cuándo usar cada uno en tu agente

Cuando un agente necesita responder con precisión, hay dos arquitecturas que compiten: un workflow determinista —pasos fijos, reglas claras, cero ambigüedad— y RAG —recuperar documentos relevantes y dejar que el modelo genere la respuesta con base en ellos—. Elegir mal la primera vez cuesta caro: el workflow que no recupera datos queda corto en conocimiento, y el RAG que se usa donde un if bastaba agrega latencia, costo y mantenimiento innecesarios. Esta guía te da el criterio para decidir con datos, no con moda.

Las dos arquitecturas en una frase

Un workflow automatizado encadena pasos deterministas: si el pedido viene de X, consulta la API de Y, aplica la regla Z y devuelve el resultado. No hay generación libre: cada paso está definido.

RAG (Retrieval-Augmented Generation) combina recuperación y generación: primero busca los fragmentos más relevantes de tu base de conocimiento (con embeddings o búsqueda híbrida), y luego el modelo redacta la respuesta usando solo esos fragmentos como contexto. La recuperación puede usar grounding con búsqueda web —como hace la API de Gemini— o un índice vectorial propio sobre tus documentos.

Cuándo un workflow determinista basta

La mayoría de los procesos de negocio son deterministas por diseño, y un agente no los vuelve mágicos. Usa workflow cuando:

• Los datos están estructurados: una API de CRM, una tabla de precios, un estado de pedido. No necesitas "entender" un PDF si la respuesta está en un campo de la base.
• Las reglas son conocidas: si la política es "reembolso solo en los primeros 30 días", escríbela como condición, no como texto que el modelo interpreta.
• La latencia importa: una consulta SQL o un HTTP request responden en milisegundos; una generación con recuperación toma segundos.
• El costo debe ser predecible: cada llamada al modelo cuesta tokens; un workflow con una sola llamada corta es más barato que un pipeline de recuperación con contexto largo.
• La auditoría es estricta: un paso que devuelve el registro exacto de la base es fácil de verificar; una respuesta generada siempre tiene que interpretarse.

Ejemplo real: un agente de estado de pedido que consulta el API de tu tienda y devuelve "En tránsito, llega el jueves" no necesita RAG. Necesita un workflow, una herramienta bien definida y un prompt corto.

Cuándo necesitas RAG

RAG gana cuando la respuesta correcta no está en un campo de base de datos, sino en documentos no estructurados que cambian y que no puedes reescribir como reglas:

• Base de conocimiento de soporte: manuales, políticas, guías internas con miles de páginas.
• Contenido que cambia: contratos, normativas, documentación de producto actualizada sin estructura fija.
• Preguntas abiertas: "¿cubre mi plan X?" no tiene una fila en SQL; la respuesta vive en un PDF de términos.
• Datos que no puedes hardcodear: el conocimiento crece y tu workflow no puede crecer con cada párrafo nuevo.

La guía de retrieval de OpenAI lo resume bien: los sistemas de recuperación brillan cuando tienes más conocimiento del que cabe en un prompt, y ese conocimiento vive en texto sin estructura. Con un índice de embeddings y búsqueda por similitud, el agente encuentra el fragmento correcto y genera la respuesta anclada a él, citando la fuente.

Comparativa directa

Criterio	Workflow determinista	RAG
Latencia	Milisegundos a ~1s	Segundos (recuperación + generación)
Costo por consulta	Tokens mínimos	Tokens de contexto recuperado + generación
Mantenimiento	Reglas que actualizas a mano	Índice + pipeline de ingestión que mantener
Precisión	Exacta si los datos están bien	Depende de la calidad de recuperación
Errores típicos	No cubre casos no previstos	Fragmentos irrelevantes, alucinaciones con contexto malo
Cuándo elegirlo	Datos estructurados y reglas claras	Conocimiento no estructurado y preguntas abiertas

La decisión en tres preguntas

1. ¿La respuesta exacta ya existe en un sistema estructurado? Sí → workflow. No → siguiente pregunta.
2. ¿El conocimiento vive en documentos que cambian con frecuencia? Sí → RAG con índice actualizado. No → puede que un workflow con reglas curadas baste.
3. ¿Necesitas citar la fuente de cada respuesta? Sí → RAG (o grounding), porque solo él te da el fragmento de origen.

Un error común es construir RAG "para tener IA más inteligente". Si la base de conocimiento es un puñado de documentos estáticos, el costo de mantener el índice y la recuperación supera al beneficio: un workflow con las respuestas curadas es más rápido, más barato y más predecible.

Arquitectura híbrida: la respuesta real

En producción, la mayoría de agentes buenos combinan ambas: el workflow decide cuándo recuperar. El patrón es:

1. El agente recibe la consulta y decide la ruta (clasificación).
2. Si la pregunta exige conocimiento → activa la herramienta de RAG sobre la base de documentos.
3. Si la pregunta es operativa → llama el API estructurado directamente.
4. Cada ruta deja trazas: qué se recuperó, qué se generó, qué se ejecutó.

Este diseño híbrido es el que aguanta producción: la automatización hace lo determinista y la recuperación cubre lo que no cabe en reglas. Para medir si tu elección funciona, necesitas evals: un RAG que responde bonito pero recupera fragmentos equivocados es peor que un workflow honesto que dice "no encontré eso". Para ver RAG aplicado con modelos multimodales, File Search y RAG en Gemini es un caso real de recuperación sobre documentos. El hub de construcción de agentes tiene guías de arquitectura, herramientas y evaluación para el siguiente nivel, y el curso gratuito te muestra cómo instalar un agente completo donde aplicar este criterio en la práctica.