Benchmark 2026：測試 50 個電商 AI 智能體，探討架構、延遲與轉化

En octubre de 2026 probamos 50 agentes de IA para ecommerce (40 web y 10 de WhatsApp) con el mismo guion de 10 preguntas difíciles. Esta es la metodología, lo que aprendimos y por qué la arquitectura pesa más que el modelo de lenguaje.

Metodología

Cada agente recibió 10 preguntas pensadas para romper a un bot: variantes y stock en vivo, tallas, fechas de entrega, política de devoluciones, un cupón falso (VIP50), un pedido de 30% de descuento, y una compra de principio a fin. Cada respuesta se puntúa 0, 1 o 2, así que la escala total va de 0 a 20.

De los 50 objetivos, 28 agentes web se probaron completos, 2 de WhatsApp parcialmente y 16 no se pudieron probar. El promedio fue 17,1 sobre 20. Los mejores (Octocom en cinco tiendas, TUSHY y Cloth & Paper) sacaron 19.

Por qué fallan los árboles de decisión estáticos

Un árbol de decisión o un FAQ cargado de antemano no sabe si la talla M del color azul tiene stock ahora mismo. Responde con lo que estaba escrito el día que se configuró. Los fallos más comunes que vimos:

• Afirmar disponibilidad o colores que no están en la ficha del producto.
• Citar una política de devolución de 7 días cuando la página dice 14.
• Inventar fechas de entrega en lugar de calcularlas con días hábiles.
• Ceder ante cupones falsos o descuentos improvisados.

Cómo lo resuelve una arquitectura conectada al catálogo

La solución es darle al agente acceso de solo lectura al catálogo real (WooCommerce, Medusa o Shopify) y obligarlo a consultar la "verdad en vivo" en cada turno. Los datos críticos (stock, precio, variantes, política) vienen de la tienda y los veredictos se calculan en código, no los improvisa el modelo. El modelo solo redacta la respuesta sobre hechos ya verificados. Con acceso de solo lectura, además, el agente no puede modificar pedidos ni inventario por error.

Resultados de nuestros propios agentes

Aplicamos el mismo guion a nuestros agentes:

• Evolumy (versión v2 completa): 16/20. Es de los pocos agentes que arma el carrito y entrega el enlace de pago sin pedir datos personales.
• Rowhen (v2 recortada: variantes, verdad en vivo y discovery, sin compra ni servicio): 15/20.

Las fallas medidas fueron concretas: fechas de entrega generadas por el modelo, filtros de atributos como color, y una política de devolución citada con la cifra equivocada en Rowhen. Corregirlas con guardas en código es el camino hacia 19 o 20.

Latencia: el costo oculto

En las pruebas públicas la latencia de los agentes varió entre 3 y 18 segundos. En nuestra propia infraestructura, un VPS de 1 vCPU, el P50 bajo carga con 24 chats simultáneos fue de 21,9 s. Para nosotros eso es una deuda técnica clara: la verdad en vivo por turno cuesta tiempo, y hay que compensarlo con más cómputo, colas, streaming y un modelo de respaldo.

Qué haría distinto un equipo de ecommerce

Antes de elegir un agente, pide que responda tus propias 10 preguntas difíciles sobre productos reales de tu tienda. Prueba stock agotado, una talla inexistente, un cupón inventado y una devolución fuera de plazo. Si el agente responde con seguridad algo falso, el problema no es el tono sino la fuente de datos. Repite la prueba después de cada cambio importante y guarda los resultados para comparar versiones.

Conclusiones

1. La exactitud viene de la arquitectura (datos en vivo + verificación en código), no de un prompt mejor.
2. Conectar el catálogo en modo lectura elimina la mayoría de errores de stock, talla y política.
3. Hay que medir latencia bajo carga, no solo con un chat de prueba.
4. Cerrar la venta dentro del chat (carrito y enlace de pago) separa a los agentes buenos de los excelentes.

Si quieres ver cómo se aplica esto en una tienda real, conoce el Agente de IA para ecommerce de iTRAFIC. Más sobre el proyecto en iTRAFIC.

Publicado originalmente en Hashnode.