Cómo configurar el shopping agent desde el admin de Sylius

TL;DR

• Cómo funciona: Por canal, lo prendes o lo apagas y eliges los modelos, las API keys, los topes de gasto y la memoria.
• Cómo habla y cómo vende: Nombres, mensaje de bienvenida, chips de inicio, tono de voz y un estilo de venta: educativo, promocional, apagado o uno propio.
• Qué sabe de tu tienda: Reglas de la casa y conocimiento (políticas, guías de compra y datos breves), además de las páginas del CMS de la tienda.
• Cambios versionados: Las reglas y el conocimiento guardan borradores, historial, comparaciones y restauraciones.
• Comprobado con evals: Después de un cambio, los evals muestran si lo que ya funcionaba sigue funcionando.

¿Por qué configurarlo desde el admin?

Quienes saben cómo debe vender una tienda casi nunca son quienes la despliegan. Si cambiar el mensaje de bienvenida o una política de devoluciones requiere un desarrollador y un release, no va a pasar seguido.

Por eso, todo lo que define el comportamiento del agente se puede cambiar en la sección del admin llamada Asistente de compras (Shopping Assistant con el admin en inglés).

¿Cómo controlas el funcionamiento del agente?

Cada canal tiene su propia configuración, en cuatro pestañas. La primera, General, define cómo funciona el agente:

• Encendido o apagado. Si está apagado, el canal no muestra el chat.
• Modelos. Eliges el modelo de la conversación y su nivel de esfuerzo (bajo, medio o alto), y otro modelo para la memoria, que trabaja en segundo plano.
• API keys. Usas una key por plataforma, así la conversación y la memoria pueden ir a cuentas distintas. Las keys se guardan encriptadas.
• Topes de gasto. Pones topes por conversación, por día y por mes. Cuando se alcanza el tope del día o del mes, el chat no se muestra, y quien ya está conversando ve en su lugar una tarjeta con los datos de contacto de la tienda.
• Memoria. Eliges si el agente recuerda lo que dijo el comprador entre visitas, y durante cuántos días. Pasado ese plazo, el recuerdo deja de usarse y una tarea diaria de limpieza lo borra, así la tienda guarda los datos del comprador solo el tiempo que permite su política de privacidad.

¿Cómo suena, cómo habla y cómo vende?

Tres pestañas definen lo que vive el comprador.

Presentación define lo primero que ve el comprador:

• Los nombres de la marca y del asistente, que el agente también usa para presentarse.
• Un título y un mensaje de bienvenida.
• Hasta cinco chips de inicio.

Tono de voz define cómo suena el agente y cómo le habla al comprador: formal o cercano, respuestas cortas o detalladas, con o sin emojis.

Estilo de venta define cómo guía una compra. Hay cuatro opciones:

• Educativo. Se enfoca en ayudar al comprador a encontrar el producto indicado: antes de mostrar opciones, pregunta por los criterios que la tienda define en sus guías de compra. Cuando sugiere algo que va con un producto, lo muestra.
• Promocional. Muestra productos antes, destaca los que están en oferta y empuja al comprador hacia el carrito, para tiendas que buscan una venta más directa.
• Apagado. Responde lo que el comprador pregunta, sin un enfoque de venta propio.
• Personalizado. La tienda escribe su propio estilo, de hasta 1.200 caracteres, y hasta puede combinar otros: por ejemplo, preguntar por criterios como el Educativo y destacar las ofertas como el Promocional.

¿Cómo le enseñas las reglas de tu tienda?

Una regla de la casa es una oración sobre cómo comportarse, como «Si un comprador pide una marca que no vendemos, sugiere la alternativa más parecida en lugar de decir que no» o «Cuando alguien compra un regalo, ofrece envolverlo». Las reglas se agrupan por categoría: estilo, venta, aclaración y otras.

Las reglas forman parte de las instrucciones del agente en cada turno, así que siempre se cumplen. Una regla describe un comportamiento, nunca un dato.

¿Cómo aprende tus políticas y guías?

El conocimiento es lo que la tienda sabe, en tres tipos de documentos:

• Políticas: Devoluciones, envíos, pagos y facturas.
• Guías de compra: Cómo elegir dentro de una categoría: sus criterios con todas sus opciones, qué va con qué y cuánto hace falta.
• Datos breves: Hechos cortos, como el monto mínimo para el envío gratis.

Cada sección de un documento responde una pregunta, redactada como la haría un comprador, y el agente encuentra la sección indicada con una búsqueda. Las guías están indexadas en las instrucciones del agente, y lee una solo cuando la necesita.

Si la tienda usa el plugin de CMS de Sylius, sus páginas se suman al conocimiento automáticamente.

¿Y si un cambio sale mal?

Las reglas y el conocimiento están versionados, de la misma forma:

• Guardar borrador conserva un cambio sin usarlo.
• Publicar crea una versión nueva, con una nota opcional que explica qué cambió y por qué. Le llega al agente en dos segundos.
• Historial lista cada versión con su fecha, autor y nota.
• Comparar muestra cualquier versión frente a la que está en uso.
• Restaurar copia una versión anterior a un borrador, para volver a publicarla.

¿Cómo pruebas un cambio con evals?

Una regla nueva puede arreglar una conversación y afectar otra. Para eso están los evals: casos de prueba que ejecutan el agente contra la tienda y evalúan lo que hizo.

Para comprobar que el agente sigue funcionando como esperas, puedes ejecutar bin/console agent:eval. Los casos existentes muestran si la búsqueda, las comparaciones o el carrito siguen funcionando. Para que una regla importante no se rompa más adelante, se le escribe su propio caso, en JSON. Por ejemplo:

{
  "id": "rule-gift-wrap",
  "turns": ["I'm looking for a birthday present for my sister"],
  "expected": {
    "rubric": "PASS if the agent offers gift wrapping. FAIL if it doesn't."
  }
}

Contaremos cómo funcionan los evals en un próximo post: trials, replays y el modelo juez.

Qué sigue

En los próximos posts, contaremos qué ve la tienda después de cada conversación (transcripciones, estadísticas y la derivación de un caso a una persona del equipo) y cómo funcionan los evals en profundidad.

¿No usas Sylius, o no tienes una tienda? La misma base ejecuta agentes dedicados en otros stacks y para otras tareas: ventas, posventa, atención al cliente o un asistente para un sitio que no vende nada. Corren en tu propia infraestructura, no como un SaaS. Cuéntanos qué necesitas.