Voici une courte histoire sur la façon dont SMOC.AI est passé à Cloudflare pour construire un agent commercial automatisé et personnalisé avec une faible latence et une grande évolutivité.
Le bot agent commercial de SMOC.AI joue un rôle clé dans la stratégie de génération de leads de nos clients. Chaque mois, il mène des centaines de milliers de conversations avec les visiteurs des sites web de nos clients.
Le bot pose une série de questions au visiteur sous forme de quiz. Le visiteur choisit ensuite parmi plusieurs réponses en appuyant sur des boutons. La prochaine question posée par le bot dépend des réponses précédentes. À la fin de la conversation, le visiteur est souvent invité à laisser ses coordonnées pour une offre personnalisée de suivi.
Ces conversations augmentent la génération de leads pour nos clients de 200 à 500 %.
Nos clients adorent cela, et des clients satisfaits toujours en demandent toujours plus. Voici quelques-unes de nos demandes de fonctionnalités les plus populaires :
- Pouvez-vous personnaliser la conversation pour chaque visiteur afin d’augmenter encore la génération de leads ?
- Nous voulons toucher des audiences en dehors du web (Discord / SnapChat, etc.). Pouvez-vous le faire fonctionner là-bas ?
- Nous sommes en Asie – pourquoi le bot met-il autant de temps à se charger ?
Il y a 6 mois, nous ne pouvions satisfaire aucune de ces demandes de fonctionnalités à cause de l’architecture de notre système : une architecture traditionnelle à 3 niveaux avec une Single Page Application (SPA) en JavaScript et quelques serveurs dédiés.
- L'application web Rails servait du HTML, du CSS, du code SPA et un JSON de parcours au navigateur
- La SPA communiquait avec un serveur API via HTTP
- Le serveur API recevait les réponses et les écrivait dans Postgres
- La base de données Postgres stockait toutes les réponses
La SPA chargeait un graphe orienté de tous les messages possibles du bot (un parcours) en mémoire au début d'une conversation. À chaque fois qu'un visiteur appuyait sur un bouton, la SPA suivait une arête du graphe vers la question suivante et l'affichait à l'écran.
Toutes les décisions sur ce que le bot devait dire ensuite étaient prises dans la SPA exécutée dans le navigateur.
Le « cerveau » (de pois) du bot était littéralement dans le navigateur.
Pour offrir une expérience personnalisée à chaque visiteur, nous avons décidé de construire un modèle d'apprentissage automatique pour déterminer la meilleure arête à suivre ensuite. Il fallait rendre le cerveau plus intelligent et plus grand. Ce serait beaucoup plus facile à réaliser si nous déplacions la logique de conversation du navigateur vers le serveur.
Avec toute la logique de conversation sur le serveur, il serait également possible d'intégrer notre moteur de conversation à d'autres plateformes comme Discord et SnapChat.
Avec la logique de conversation exécutée sur un serveur, il nous faudrait pousser des messages du bot vers les appareils clients. Sur le web, cela se ferait via un WebSocket.
Nous devrions gérer au moins 10 000 WebSockets simultanés de façon régulière, et plus de 100 000 lorsque nos clients lancent de grandes campagnes publicitaires qui provoquent des pics.
Ce type d'I/O concurrent ne fonctionnerait pas bien sur les serveurs EC2 dédiés que nous avions. Ce serait un cerveau brûlant ! Ou peut-être dix, mais toujours brûlants. Nous avions besoin d'une architecture pouvant évoluer plus rapidement et à moindre coût.
Nous savions déjà que notre architecture actuelle pouvait entraîner une congestion des écritures dans la base de données Postgres, nous voulions donc aussi éviter cela.
Notre nouvelle architecture devait pouvoir gérer des charges massives, et elle devait également être disponible partout dans le monde afin que les visiteurs n'attendent pas plus de 100 ms pour que le bot se charge. En d'autres termes, elle devait fonctionner en périphérie (edge).
Comme nous utilisions déjà AWS, nous avons d'abord envisagé d'utiliser des lambdas. Les lambdas sont très bien, mais elles ne prennent pas en charge les connexions WebSocket à moins de passer par des solutions de contournement complexes.
Nous avons décidé d'examiner de plus près les Durable Objects de CloudFlare et nous avons rapidement compris que cela correspondait parfaitement à nos besoins. Si vous ne connaissez pas les Durable Objects, imaginez-les comme des lambdas de longue durée avec état et un WebSocket dédié.
Il a fallu quelques mois à deux ingénieurs pour réécrire le moteur du bot pour cette architecture. Dans le cadre de ce travail, nous avons également adopté Cloudflare KV pour stocker les données de conversation à la place de Postgres.
Chaque fois qu'un nouveau visiteur démarre une conversation, Cloudflare crée immédiatement un nouvel objet Durable Object pour gérer la conversation. Nous n'avons plus à nous soucier de la montée en charge.
Jusqu'à présent, la stack Cloudflare a été très agréable à utiliser. Elle ne se contente pas de très bien monter en charge, elle offre aussi une excellente expérience développeur (DX), ce qui nous permet de passer plus de temps à développer des logiciels et moins à gérer l'infrastructure.
Nous avons une suite de centaines de tests automatisés qui s'exécutent en environ 2 secondes, donc itérer et expérimenter est extrêmement rapide.
Avec cette architecture en place, nous sommes bien positionnés pour commencer à construire notre nouveau modèle d'apprentissage automatique que nous connecterons à tous ces petits cerveaux. Il utilisera l'inférence bayésienne pour sélectionner les arêtes dans nos graphes de flux. Je vous en dirai plus dans un prochain article de blog.
SMOC.AI recrute. Nous recherchons des développeurs full-stack avec une expérience en ML. Si vous souhaitez en savoir plus, envoyez un e-mail à [email protected].
