Implementación de IA en el comercio minorista con Apache Cassandra y Apache Pulsar

El viaje para implementar soluciones de inteligencia artificial y aprendizaje automático requiere resolver muchos desafíos comunes que surgen de manera rutinaria en los sistemas digitales: actualizar los sistemas heredados, eliminar los procesos por lotes y usar tecnologías innovadoras basadas en AI/ML para mejorar la experiencia del cliente en formas que parecían ciencia ficción hace apenas unos años.

Para ilustrar esta evolución, sigamos a un contratista hipotético que fue contratado para ayudar a implementar soluciones de IA/ML en un gran minorista. Este es el primero de una serie de artículos que detallarán aspectos importantes del viaje hacia AI/ML.

El problema: un proceso por lotes frágil

Es el primer día en BigBoxCo en el equipo de "Infraestructura". Después de trabajar en las actividades obligatorias de recursos humanos, recibí mi credencial de contratista y me dirigí a mi nuevo espacio de trabajo.

Después de reunirme con el equipo, me dijeron que tenemos una reunión con el equipo de "Recomendaciones" esta mañana.

El acceso a mi sistema aún no funciona del todo, así que espero que TI lo arregle mientras estamos en la reunión.

En la sala de reuniones, somos solo algunos de nosotros: mi gerente y otros dos ingenieros de mi nuevo equipo, y un ingeniero del equipo de Recomendaciones. Comenzamos con algunas presentaciones y luego pasamos a discutir un tema de la semana anterior.

Evidentemente, hubo algún tipo de falla en el lote de la noche a la mañana la semana pasada, y todavía sienten los efectos de eso.

Parece que las recomendaciones de productos actuales están impulsadas por los datos recopilados de los pedidos de los clientes. Con cada pedido, hay una nueva asociación entre los productos pedidos, que se registra.

Cuando los clientes ven las páginas de productos, pueden obtener recomendaciones basadas en cuántos otros clientes compraron el producto actual junto con diferentes productos.

Las recomendaciones de productos se sirven a los usuarios en bigboxco.com a través de una capa de microservicio en la nube. La capa de microservicio utiliza una implementación de centro de datos local (en la nube) de Apache Cassandra para ofrecer los resultados.

Sin embargo, cómo se recopilan y sirven los resultados es una historia completamente diferente. Básicamente, los resultados de las asociaciones entre productos (comprados juntos) se compilan durante un trabajo de MapReduce. Este es el proceso por lotes que falló la semana pasada.

Si bien este proceso por lotes nunca ha sido rápido, se ha vuelto más lento y frágil con el tiempo. De hecho, a veces el proceso tarda dos o incluso tres días en ejecutarse.

Mejorando la Experiencia

Después de la reunión, reviso mi computadora y parece que finalmente puedo iniciar sesión. Mientras miro a mi alrededor, nuestro ingeniero principal (PE) se acerca y se presenta.

Le cuento la reunión con el equipo de Recomendaciones y me cuenta un poco más de la historia detrás del servicio de Recomendaciones.

Parece que ese proceso por lotes ha estado en vigor durante unos 10 años. El ingeniero que lo diseñó ha seguido adelante, no mucha gente en la organización realmente lo entiende y nadie quiere tocarlo.

El otro problema, empiezo a explicar, es que el conjunto de datos que impulsa cada recomendación casi siempre tiene un par de días de antigüedad.

Si bien esto podría no ser un gran problema en el gran esquema de las cosas, si los datos de recomendación pudieran estar más actualizados, beneficiaría las promociones a corto plazo que ejecuta el marketing.

Él asiente con la cabeza y dice que definitivamente está abierto a sugerencias sobre cómo mejorar el sistema.

¿Tal vez es un problema de gráficos?

Al principio, esto me suena como un problema gráfico. Tenemos clientes que inician sesión en el sitio y compran productos. Antes de eso, cuando miran un producto o lo agregan al carrito, podemos mostrar recomendaciones en forma de "Los clientes que compraron X también compraron Y".

El sitio tiene esto hoy, en el sentido de que el servicio de recomendaciones hace exactamente esto: devuelve los cuatro productos adicionales principales que se compran juntos con frecuencia.

Pero tendríamos que tener alguna forma de "clasificar" los productos porque el mapeo de un producto a cada otro comprado al mismo tiempo por cualquiera de nuestros 200 millones de clientes va a crecer rápidamente.

Entonces podemos clasificarlos por la cantidad de veces que aparecen en un pedido. Un gráfico de este sistema podría parecerse a lo que se muestra a continuación en la Figura 1.

Después de modelar esto y ejecutarlo en nuestra base de datos de gráficos con volúmenes reales de datos, rápidamente me di cuenta de que esto no iba a funcionar.

El recorrido de un producto a los clientes cercanos a sus productos y el cómputo de los productos que aparecen más toma alrededor de 10 segundos.

Esencialmente, hemos "despegado" en el problema del lote de dos días, para que cada búsqueda coloque la latencia transversal precisamente donde no la queremos: frente al cliente.

Pero tal vez, ese modelo gráfico no está muy lejos de lo que necesitamos hacer aquí. De hecho, el enfoque descrito anteriormente es una técnica de aprendizaje automático (ML) conocida como "filtrado colaborativo".

Esencialmente, el filtrado colaborativo es un enfoque que examina la similitud de ciertos objetos de datos en función de la actividad con otros usuarios, y nos permite hacer predicciones basadas en esos datos.

En nuestro caso, recopilaremos implícitamente datos de pedidos/carritos de nuestra base de clientes, y los utilizaremos para hacer mejores recomendaciones de productos para aumentar las ventas en línea.

Implementación

En primer lugar, echemos un vistazo a la recopilación de datos. Agregar una llamada de servicio adicional a la función de "hacer pedido" de compras no es gran cosa. De hecho, ya existe; es solo que los datos se almacenan en una base de datos y se procesan más tarde. No se equivoque: todavía queremos incluir el procesamiento por lotes.

Pero también querremos procesar los datos del carrito en tiempo real, para que podamos volver a introducirlos en el conjunto de datos en línea y usarlos inmediatamente después.

Comenzaremos instalando una solución de transmisión de eventos como Pulsar apache . De esa manera, toda la actividad del carrito nuevo se pone en un Pulsar tema , donde se consume y se envía tanto a la base de datos por lotes subyacente como para ayudar a entrenar nuestro modelo de aprendizaje automático en tiempo real.

En cuanto a lo último, nuestro consumidor de Pulsar escribirá en una tabla de Cassandra (que se muestra en la Figura 2) diseñada simplemente para contener entradas para cada producto en el pedido. Luego, el producto tiene una fila para todos los demás productos de ese y otros pedidos:

 CREATE TABLE order_products_mapping ( id text, added_product_id text, cart_id uuid, qty int, PRIMARY KEY (id, added_product_id, cart_id) ) WITH CLUSTERING ORDER BY (added_product_id ASC, cart_id ASC); 

Luego podemos consultar esta tabla para un producto en particular ("DSH915" en este ejemplo), así:

 SELECT added_product_id, SUM(qty) FROm order_products_mapping WHERE id='DSH915' GROUP BY added_product_id; added_product_id | system.sum(qty) ------------------+----------------- APC30 | 7 ECJ112 | 1 LN355 | 2 LS534 | 4 RCE857 | 3 RSH2112 | 5 TSD925 | 1 (7 rows)

Luego, podemos tomar los cuatro resultados principales y colocarlos en la tabla de recomendaciones de productos, listos para que el servicio de recomendaciones los consulte por ` product_id :

 SELECT * FROM product_recommendations WHERE product_id='DSH915'; product_id | tier | recommended_id | score ------------+------+----------------+------- DSH915 | 1 | APC30 | 7 DSH915 | 2 | RSH2112 | 5 DSH915 | 3 | LS534 | 4 DSH915 | 4 | RCE857 | 3 (4 rows)

De esta forma, los nuevos datos de recomendación se mantienen constantemente actualizados. Además, todos los activos de infraestructura descritos anteriormente se encuentran en el centro de datos local.

Por lo tanto, el proceso de extraer relaciones de productos de un pedido, enviarlos a través de un tema de Pulsar y procesarlos en recomendaciones almacenadas en Cassandra ocurre en menos de un segundo.

Con este modelo de datos simple, Cassandra es capaz de brindar las recomendaciones solicitadas en milisegundos de un solo dígito.

Conclusiones y próximos pasos

Querremos asegurarnos de examinar cómo se escriben nuestros datos en nuestras tablas de Cassandra a largo plazo. De esta forma, podemos adelantarnos a los problemas potenciales relacionados con cosas como el crecimiento de filas sin límites y las actualizaciones en el lugar.

Es posible que también sea necesario agregar algunos filtros heurísticos adicionales, como una lista de "no recomendar".

Esto se debe a que hay algunos productos que nuestros clientes comprarán una vez o con poca frecuencia, y recomendarlos solo le quitará espacio a otros productos que es mucho más probable que compren por impulso.

Por ejemplo, no es probable que recomendar la compra de algo de nuestra división de electrodomésticos, como una lavadora, genere una "compra impulsiva".

Otra mejora futura sería implementar una plataforma de inteligencia artificial/aprendizaje automático en tiempo real como Kaskada para manejar tanto la transmisión de la relación del producto como para entregar los datos de recomendación al servicio directamente.

Afortunadamente, se nos ocurrió una manera de aumentar el lento proceso por lotes existente usando Pulsar para alimentar los eventos de carrito agregado para que se procesen en tiempo real. Una vez que tengamos una idea de cómo funciona este sistema a largo plazo, deberíamos considerar cerrar el proceso por lotes heredado.

El PE reconoció que avanzamos mucho con la nueva solución y, mejor aún, que también hemos comenzado a sentar las bases para eliminar algunas deudas técnicas. Al final, todos se sienten bien con eso.

En un próximo artículo, veremos cómo mejorar las promociones de productos con la búsqueda vectorial .

Descubra cómo DataStax habilita la IA en tiempo real

Por Aaron Ploetz, DataStax

También publicado aquí