Flujos de trabajo deterministas frente a flujos de trabajo basados en agentes: Lecciones tras crear un asistente de compras

Lecciones sobre flujos de trabajo deterministas, razonamiento basado en agentes y gestión de estados

Crear asistentes de IA suele empezar con un problema engañosamente sencillo. Un usuario hace una pregunta, el sistema recupera la información y un LLM genera una respuesta. La primera versión suele funcionar sorprendentemente bien.

El verdadero desafío surge a medida que se amplían las capacidades. Con la introducción de nuevas herramientas y flujos de trabajo, los usuarios empiezan a hacer preguntas que abarcan múltiples dominios. Las conversaciones se vuelven más largas y contextuales, lo que transforma al asistente: deja de ser un simple bot de preguntas y respuestas para convertirse en una herramienta que ayuda a los usuarios a realizar tareas complejas.

En TrueFoundry, nos enfrentamos a este mismo reto al crear un asistente de compras conversacional. El asistente comenzó como un compañero para la página de detalles del producto (PDP), capaz de responder preguntas sobre un solo artículo. Con el tiempo, evolucionó hasta convertirse en un asistente de compras para todo el catálogo, capaz de gestionar el descubrimiento de productos, la búsqueda, el resumen de reseñas, el procesamiento de cupones, la localización de tiendas, la comprobación de inventario, la selección de la opción de entrega y las operaciones del carrito.

Aunque las capacidades externas se ampliaron de forma significativa, los desafíos de ingeniería más críticos aparecieron en dos áreas:

1. Decidir cuándo utilizar flujos de trabajo deterministas frente al razonamiento basado en agentes.
2. Evolucionar la gestión de estados desde un modelo de conversación centrado en un único producto hacia una experiencia de compra multiproducto.

1. Visión general de la arquitectura del sistema

El asistente de compras se basa en cuatro capas arquitectónicas principales diseñadas para equilibrar el rendimiento, el coste y la fiabilidad.

A. Capa de datos

El sistema mantiene una estricta separación entre los sistemas de almacenamiento estructurado y no estructurado:

• Catálogo de productos: almacenado en PostgreSQL (Cloud SQL), contiene los metadatos del producto, precios, variantes, información de categorías y metadatos de tramitación.
• Reseñas: las opiniones de los clientes se almacenan en Qdrant. Esto permite la recuperación semántica del contenido de las reseñas en lugar de depender únicamente de la coincidencia de palabras clave. Cuando los usuarios hacen preguntas semánticas como "¿Qué dicen los clientes sobre la duración de la batería?", el sistema recupera las reseñas relevantes y genera un resumen basado en evidencias.

B. Canalización de ingesta de datos

Los datos del catálogo y de las reseñas llegan de forma continua a través de Google Cloud Storage (GCS) y se procesan mediante canalizaciones de Google Dataflow:

• Canalización del catálogo: GCS → Dataflow → Cloud SQL (se procesa diariamente).
• Canalización de reseñas: GCS → Dataflow → Generación de embeddings → Qdrant (se procesa tanto diariamente como a cada hora para mantener actualizada la opinión de los clientes).

C. Capa de modelos

Todas las interacciones con los modelos se enrutan a través del TrueFoundry AI Gateway. Esto proporciona acceso centralizado a los modelos, observabilidad, gobernanza, seguimiento de costes, limitación de frecuencia y abstracción de modelos. El asistente utiliza los modelos Gemini 2.5 Flash y Qwen para equilibrar latencia, calidad y coste operativo.

D. Capa de orquestación

El flujo de trabajo conversacional se orquesta mediante LangGraph, lo que permite transiciones de estado explícitas y la gestión del flujo de trabajo, respaldando tanto las rutas de ejecución deterministas como el razonamiento basado en agentes.

2. Desafío n.º 1: Flujos de trabajo deterministas frente a flujos basados en agentes

Una tendencia habitual en los sistemas de IA es hacer que todo funcione completamente mediante agentes, asumiendo que si un LLM puede razonar, debería encargarse de todo. En producción, un enfoque basado exclusivamente en agentes se vuelve rápidamente caro, lento y difícil de controlar.

Dividimos las interacciones de compra en dos paradigmas de ejecución distintos basándonos en compromisos claros de rendimiento e intención:

Bajo el capó: La mecánica de la ejecución

La decisión arquitectónica de separar estos flujos se debe en gran medida a los bucles internos, el número total de llamadas al LLM y la sobrecarga del procesamiento de tokens.

El ciclo de vida del agente ReAct (bucle de 3 pasos)

Para los flujos de trabajo complejos, un agente ReAct dedicado gestiona la ejecución de forma dinámica a través de un ciclo de tres pasos:

1. Paso 1: El prompt de planificación (Llamada al LLM): El sistema pasa la consulta del usuario junto con los prompts del sistema que contienen las definiciones de todas las herramientas disponibles. El LLM debe razonar sobre lo que dijo el usuario, identificar qué herramienta utilizar y extraer los parámetros exactos necesarios para esa herramienta.
2. Paso 2: La ejecución de la herramienta: El sistema ejecuta la herramienta o la llamada a la API real utilizando los parámetros extraídos.
3. Paso 3: El prompt de observación y síntesis (Llamada al LLM): La respuesta sin procesar de la herramienta se devuelve al LLM. El modelo evalúa la respuesta de la herramienta en relación con la pregunta original del usuario y la transforma en una respuesta limpia y contextualizada para el usuario.

El ciclo de vida determinista (Atajo de 2 pasos)

Capacidades como las especificaciones de productos, las reseñas y los cupones no necesitan razonar sobre la elección de herramientas ni sobre el orden de ejecución. Para optimizar el rendimiento, nos saltamos por completo la fase de planificación:

1. Paso 1: Ejecución directa de la herramienta: Dado que la clasificación de la intención se asigna directamente a una herramienta conocida, la primera llamada al prompt del LLM se omite por completo. El sistema ejecuta la herramienta inmediatamente, eliminando un ciclo de inferencia completo y reduciendo el time-to-first-byte (tiempo hasta el primer byte).
2. Paso 2: Síntesis de la respuesta (Llamada al LLM): El sistema envía los datos sin procesar de la herramienta y la consulta del usuario directamente a un prompt altamente especializado para dar formato a la respuesta final.

La penalización por latencia y complejidad del prompt

Más allá de contar el número de llamadas, la complejidad del prompt condiciona significativamente la velocidad de respuesta:

• Carga del prompt ReAct: En el Paso 1 de un agente ReAct, el prompt es sumamente complejo. El LLM debe examinar múltiples herramientas, evaluar la lógica de ejecución y mantener el contexto. Esta elevada carga cognitiva aumenta el tiempo de procesamiento de tokens y la latencia de generación.
• Eficiencia del prompt determinista: En un flujo determinista, el prompt final es sencillo: "Aquí está la pregunta y aquí está la respuesta sin procesar de la herramienta. Proporciona la respuesta". Dado que el modelo no necesita evaluar rutas ni realizar un seguimiento de las herramientas, la generación de tokens es rápida y ligera.

Lección principal: Forzar un bucle de razonamiento ReAct en consultas de datos básicas añade latencia, coste y complejidad operativa innecesarios sin mejorar la calidad de la respuesta. Si una interacción se puede gestionar de forma determinista, debe hacerse así.

Establecer límites a los agentes ReAct

Allí donde las rutas deterministas no son suficientes (por ejemplo, "¿Puedo recibir esto hoy?", que implica la resolución de la ubicación, la búsqueda de tiendas y las comprobaciones de disponibilidad), los agentes ReAct son vitales. Sin embargo, los agentes totalmente autónomos suelen ofrecer experiencias de cliente inconsistentes. Para mantener el control, TrueFoundry implementó etapas de flujo de trabajo estructuradas dentro de los agentes dinámicos:

• Etapas del agente de inventario: Resolución de ubicación → Selección de tienda → Comprobación de inventario → Explicación del resultado.
• Etapas del agente de compra: Validación del producto → Verificación del inventario → Selección de la opción de entrega → Operación en el carrito → Confirmación.

3. Desafío n.º 2: Evolución de la gestión de estados

Evolucionar de un asistente para la página de un solo producto a un compañero de compras para todo el catálogo es, en esencia, un problema de gestión de estados.

• Fase 1 (Estado de un solo producto): El contexto del producto se derivaba implícitamente de la página activa. El modelo de estado era un hilo simple y plano con el historial de la conversación.
• Fase 2 (Conversaciones sobre múltiples productos): La búsqueda en el catálogo permite a los usuarios introducir, comparar y alternar entre varios productos simultáneamente.

Para escalar sin introducir fragilidad en el sistema, la arquitectura de estados se rediseñó por completo en torno a cuatro principios de diseño clave:

1. Separación de los ámbitos de estado

Mezclar los datos del usuario con los datos transitorios del producto crea sistemas frágiles. El estado se refactorizó en límites diferenciados:

• Estado a nivel de usuario: Persistente a lo largo de toda la sesión de compra (por ejemplo, tienda favorita, preferencias de ubicación, opciones de entrega elegidas).
• Estado a nivel de producto: Vinculado a artículos específicos (por ejemplo, metadatos del catálogo, cupones activos, reseñas).

2. Seguimiento explícito del contexto (current_product_id)

Pasamos de un contexto de producto implícito a uno explícito mediante la introducción de current_product_id como una variable de estado de primer nivel. Cuando un usuario cambia su atención a un nuevo artículo, la actualización de este único ID purga y actualiza automáticamente los datos del catálogo, las reseñas, los cupones y las variables de inventario que dependen de él.

3. Memoria de hilo específica para cada agente

Mantener un único array plano conversación_historial = [] introducía un enorme ruido de tokens y degradaba el rendimiento del modelo. Las conversaciones de búsqueda requieren ventanas de contexto completamente diferentes a las de las operaciones finales de pago. La memoria se delimitó directamente en hilos de agentes aislados (Búsqueda, Inventario, Compra, Producto) para minimizar la contaminación entre contextos.

4. Resolución de referencias a productos

La clasificación de la intención por sí sola es insuficiente cuando se trabaja con un catálogo global. Cuando un usuario pregunta "¿Está disponible cerca de mí?", el sistema recurre a una capa de Resolución de referencias a productos recién incorporada para deducir matemáticamente a qué artículo se refiere "esto", evaluar si la consulta es ambigua y decidir si se necesita un prompt de aclaración.

Conclusión clave de la arquitectura: El estado debe representar los flujos de trabajo (Búsqueda, Inventario, Compra) en lugar de los dominios de datos (Reseñas, Cupones, Productos). Diseñar el estado en función de la intención del usuario y la progresión del flujo de trabajo simplifica enormemente la orquestación y reduce la complejidad del seguimiento entre múltiples agentes.