Esta es una breve historia sobre cómo SMOC.AI migró a Cloudflare para construir un bot de agente de ventas automatizado y personalizado con baja latencia y alta escalabilidad.
El bot de agente de ventas de SMOC.AI desempeña un papel importante en la estrategia de generación de leads de nuestros clientes. Cada mes realiza cientos de miles de conversaciones con los visitantes de los sitios web de nuestros clientes.
El bot hace una serie de preguntas al visitante a modo de cuestionario. El visitante elige entre varias respuestas pulsando botones. La siguiente pregunta que hace el bot depende de las respuestas anteriores. Al final de la conversación, a menudo se pide al visitante que deje sus datos de contacto para una oferta personalizada de seguimiento.
Estas conversaciones aumentan la generación de leads para nuestros clientes en un 200-500 %.
A nuestros clientes les encanta, y los clientes satisfechos siempre siempre piden más. Algunas de nuestras solicitudes de funciones más populares son:
- ¿Podéis adaptar la conversación a cada visitante para aumentar aún más la generación de leads?
- Queremos llegar a audiencias fuera de la web (Discord / SnapChat, etc.). ¿Podéis hacerlo funcionar allí?
- Estamos en Asia: ¿por qué tarda tanto en cargarse el bot?
Hace 6 meses no podíamos satisfacer ninguna de estas solicitudes de funciones debido a la arquitectura de nuestro sistema: una arquitectura tradicional de 3 capas con una Single Page Application (SPA) en JavaScript y un par de servidores dedicados.
- La aplicación web de Rails servía HTML, CSS, código SPA y un flujo JSON al navegador
- La SPA se comunicaba con un servidor API a través de HTTP
- El servidor API recibía las respuestas y las guardaba en Postgres
- La base de datos Postgres almacenaba todas las respuestas
La SPA cargaba un grafo dirigido de todos los posibles mensajes del bot (un flujo) en memoria al inicio de una conversación. Cada vez que un visitante pulsaba un botón, la SPA seguía una arista del grafo hasta la siguiente pregunta y la mostraba en pantalla.
Todas las decisiones sobre lo que el bot debía decir a continuación se tomaban en la SPA que se ejecutaba en el navegador.
El (cerebro de guisante) del bot estaba literalmente en el navegador.
Para ofrecer una experiencia personalizada a cada visitante, decidimos crear un modelo de aprendizaje automático para decidir qué arista era mejor seguir a continuación. Teníamos que hacer el cerebro más inteligente y grande. Esto sería mucho más fácil de lograr si trasladábamos la lógica de la conversación del navegador al servidor.
Con toda la lógica de conversación en el servidor, también sería posible integrar nuestro motor de conversación con otras plataformas como Discord y SnapChat.
Con la lógica de conversación ejecutándose en un servidor, tendríamos que enviar mensajes del bot a los dispositivos cliente. En la web, esto se haría a través de un WebSocket.
Tendríamos que gestionar al menos 10.000 WebSockets simultáneos de forma habitual, y más de 100.000 cada vez que nuestros clientes lanzan grandes campañas publicitarias que provocan picos.
Este tipo de I/O concurrente no funcionaría bien en los servidores EC2 dedicados que teníamos. ¡Sería un cerebro muy caliente! O quizá diez, pero igual de calientes. Necesitábamos una arquitectura que pudiera escalar más rápido y a menor coste.
Ya sabíamos que nuestra arquitectura actual podía provocar congestión de escritura en la base de datos Postgres, así que también queríamos evitar eso.
Nuestra nueva arquitectura debía soportar cargas masivas y también estar disponible en todo el mundo para que los visitantes no tuvieran que esperar más de 100 ms a que el bot se cargara. En otras palabras, debía funcionar en el edge.
Como ya usábamos AWS, primero consideramos usar lambdas. Las lambdas son estupendas, pero no admiten conexiones WebSocket a menos que hagas malabares.
Decidimos analizar más a fondo los Durable Objects de CloudFlare y enseguida nos dimos cuenta de que era la solución perfecta para nuestras necesidades. Si no conoces los Durable Objects, piensa en ellos como lambdas de larga duración con estado y un WebSocket dedicado.
Dos ingenieros tardaron unos meses en reescribir el motor del bot para esta arquitectura. Como parte de este trabajo, también adoptamos Cloudflare KV para almacenar los datos de las conversaciones en lugar de Postgres.
Cada vez que un nuevo visitante inicia una conversación, Cloudflare crea inmediatamente un nuevo Durable Object para gestionar la conversación. Ya no tenemos que preocuparnos por la escalabilidad.
Hasta ahora, la pila de Cloudflare ha sido excelente para trabajar. No solo escala extremadamente bien, sino que también ofrece una experiencia de desarrollador (DX) excelente, por lo que podemos dedicar más tiempo a crear software y menos a gestionar la infraestructura.
Tenemos un conjunto de cientos de pruebas automatizadas que se ejecutan en unos 2 segundos, así que iterar y experimentar es extremadamente rápido.
Con esta arquitectura en marcha, estamos bien posicionados para empezar a construir nuestro nuevo modelo de aprendizaje automático, que conectaremos a todos estos pequeños cerebros. Utilizará inferencia bayesiana para seleccionar los bordes en nuestros diagramas de flujo. Os contaré más sobre ello en una próxima entrada del blog.
SMOC.AI está contratando. Buscamos desarrolladores full-stack con experiencia en ML. Si te interesa saber más, envía un correo a [email protected].
