Dies ist eine kurze Geschichte darüber, wie SMOC.AI zu Cloudflare wechselte, um einen personalisierten, automatisierten Vertriebsagenten-Bot mit niedriger Latenz und hoher Skalierbarkeit zu bauen.
Der Vertriebsagenten-Bot von SMOC.AI spielt eine wichtige Rolle in der Leadgenerierungsstrategie unserer Kunden. Jeden Monat führt er Hunderttausende von Gesprächen mit Besuchern der Kundenwebseiten.
Der Bot stellt dem Besucher eine Reihe von Fragen als Quiz. Der Besucher wählt dann zwischen mehreren Antworten, indem er auf Schaltflächen klickt. Die nächste Frage, die der Bot stellt, hängt von den vorherigen Antworten ab. Am Ende des Gesprächs wird der Besucher oft gebeten, seine Kontaktdaten für ein persönliches Folgeangebot zu hinterlassen.
Diese Gespräche steigern die Leadgenerierung für unsere Kunden um 200–500 %.
Unsere Kunden lieben es, und zufriedene Kunden immer fragen immer nach mehr. Einige unserer beliebtesten Funktionswünsche sind:
- Können Sie das Gespräch für jeden Besucher individuell anpassen, um die Leadgenerierung noch weiter zu steigern?
- Wir möchten Zielgruppen außerhalb des Webs erreichen (Discord / SnapChat usw.). Können Sie es dort zum Laufen bringen?
- Wir sind in Asien – warum dauert es so lange, den Bot zu laden?
Vor 6 Monaten konnten wir keine dieser Funktionswünsche erfüllen, weil unser System als traditionelle 3-Schichten-Architektur mit einer Single Page Application (SPA) in JavaScript und ein paar dedizierten Servern aufgebaut war.
- Die Rails-Webanwendung lieferte HTML, CSS, SPA-Code und ein Flow-JSON an den Browser
- Die SPA kommunizierte über HTTP mit einem API-Server
- Der API-Server empfing die Antworten und schrieb sie in Postgres
- Die Postgres-Datenbank speicherte alle Antworten
Die SPA lud einen gerichteten Graphen aller möglichen Bot-Nachrichten (ein Flow) in den Speicher zu Beginn eines Gesprächs. Jedes Mal, wenn ein Besucher einen Button drückte, folgte die SPA einer Kante im Graphen zur nächsten Frage und zeigte diese auf dem Bildschirm an.
Alle Entscheidungen darüber, was der Bot als Nächstes sagen sollte, wurden in der im Browser laufenden SPA getroffen.
Das (Erbsen-)Gehirn des Bots befand sich buchstäblich im Browser.
Um jedem Besucher ein personalisiertes Erlebnis zu bieten, beschlossen wir, ein Machine-Learning-Modell zu bauen, das entscheidet, welche Kante als nächstes verfolgt werden sollte. Wir mussten das Gehirn größer und schlauer machen. Das wäre viel einfacher umzusetzen, wenn wir die Gesprächslogik vom Browser auf den Server verlagern würden.
Mit der gesamten Gesprächslogik auf dem Server wäre es auch möglich, unsere Gesprächs-Engine mit anderen Plattformen wie Discord und SnapChat zu integrieren.
Mit der Gesprächslogik, die auf einem Server läuft, müssten wir pushen Bot-Nachrichten an die Client-Geräte senden. Im Web würde dies über eine WebSocket-Verbindung erfolgen.
Wir müssten regelmäßig mindestens 10.000 gleichzeitige WebSockets handhaben und über 100.000, wenn unsere Kunden große Werbekampagnen durchführen, die zu Spitzen führen.
Diese Art von gleichzeitiger I/O würde auf den dedizierten EC2-Servern, die wir hatten, nicht gut funktionieren. Das wäre ein heißes Gehirn! Oder vielleicht zehn, aber immer noch heiß. Wir brauchten eine Architektur, die schneller und kostengünstiger skalieren konnte.
Wir wussten bereits, dass unsere aktuelle Architektur zu Schreibstaus in der Postgres-Datenbank führen könnte, daher wollten wir das ebenfalls vermeiden.
Unsere neue Architektur musste enorme Lasten bewältigen und weltweit verfügbar sein, damit Besucher nicht länger als 100 ms warten müssen, bis der Bot geladen ist. Mit anderen Worten: Sie musste am Rand (Edge) leben.
Da wir bereits AWS nutzten, haben wir zunächst überlegt, Lambdas zu verwenden. Lambdas sind großartig, aber sie unterstützen keine WebSocket-Verbindungen, es sei denn, man durch viele Reifen springt.
Wir haben uns entschieden, CloudFlare Durable Objects genauer anzuschauen, und schnell erkannt, dass dies perfekt zu unseren Anforderungen passt. Falls Sie Durable Objects nicht kennen: Stellen Sie sie sich wie langlaufende Lambdas mit Zustand und einer eigenen WebSocket-Verbindung vor.
Zwei Ingenieure brauchten ein paar Monate, um die Bot-Engine für diese Architektur neu zu schreiben. Im Zuge dieser Arbeit haben wir auch Cloudflare KV eingeführt, um Konversationsdaten statt in Postgres dort zu speichern.
Jedes Mal, wenn ein neuer Besucher ein Gespräch beginnt, startet Cloudflare sofort ein neues Durable Object, um das Gespräch zu verwalten. Wir müssen uns keine Gedanken mehr über Skalierung machen.
Bisher war der Cloudflare-Stack großartig zu nutzen. Er skaliert nicht nur extrem gut, sondern bietet auch eine hervorragende Developer Experience (DX), sodass wir mehr Zeit mit der Entwicklung von Software und weniger Zeit mit dem Management der Infrastruktur verbringen können.
Wir haben eine Suite von Hunderten automatisierten Tests, die in etwa 2 Sekunden durchlaufen, sodass das Iterieren und Experimentieren ist extrem schnell.
Mit dieser Architektur sind wir bestens aufgestellt, um unser neues Machine-Learning-Modell zu entwickeln, das wir an all diese kleinen Gehirne anschließen werden. Es wird bayessche Inferenz verwenden, um Kanten in unseren Flussdiagrammen auszuwählen. Mehr dazu erzähle ich in einem zukünftigen Blogbeitrag.
SMOC.AI stellt ein. Wir suchen Full-Stack-Entwickler mit ML-Erfahrung. Wenn Sie mehr erfahren möchten, senden Sie eine E-Mail an [email protected].
