Abb. 1: Architectural Overview
AI verändert auf vielen Ebenen stetig Geschäftsprozesse. Eines der am fortgeschrittensten Themen ist die Verarbeitung natürlicher Sprache (NLP), welche sich nicht nur im Bereich Smart Home großer Beliebtheit erfreut, sondern auch im Kundenservice zunehmend an Bedeutung gewinnt. Durch NLP lassen sich komplexe Kundenanfragen automatisieren und neue Kanäle der Kundeninteraktion aufbauen.
Damit NLP einen tatsächlichen Mehrwert im Kundenservice erbringen kann und nicht nur eine Suchmaschine auf den FAQ´s ersetzt, sind Integrationen mit Unternehmensdaten unabdingbar.
Wie wir eine solche Integration im hybriden Cloud-Umfeld für einen großen Kunden im Bereich Telekommunikation umgesetzt haben, wollen wir im Folgenden erläutern. Dabei konzentrieren wir uns auf die wesentlichen Herausforderungen und den daraus resultierenden Entwurf.
Problemstellung
Als Service für den Bau von Dialogen und als NLP Modell hatte sich der Kunde für den Cloud Service IBM Watson Assistant entschieden. Die Hausforderung bestand darin eine Middleware zu bauen, welche es dem Watson Assistant ermöglicht auf Unternehmensdaten zuzugreifen, um diverse Use Cases wie Störungsmeldungen oder Benachrichtigungen zum nächsten Kündigungsdatum umzusetzen.
In Abbildung 1 ist der grundlegende Aufbau der Infrastruktur zu sehen. Unsere Lösung umfasst lediglich den Entwurf und die Implementierung der Middleware Komponente, bestehend aus dem Request Handler und den Use Case Modules (Abb. 2). Welche Herausforderungen es beim Entwurf gab und welche Lösungen wir dafür entwickelt haben, wollen wir im Weiteren erläutern.
Abb. 2: Aufbau Module
Nur eine REST-Schnittstelle
Eine wesentliche Einschränkung zu Beginn des Projektes war die Fähigkeit des IBM Watson Assistant nur eine POST REST-Schnittstelle aufrufen zu können. Dadurch konnten verschiedene Use Cases nicht wie sonst üblich über verschiedene REST-Schnittstellen abgebildet werden.
Um dieses Problem zu lösen, haben wir den Request Handler entworfen.
Der Request Handler entscheidet anhand von Parametern im Request Body welches Use Case Module oder welche Module für die Bearbeitung der Anfrage aufgerufen werden müssen. Außerdem übernimmt er Aufgaben im Logging für das Reporting und führt ein erstes allgemeines Input preprocessing durch.
Abb. 3 zeigt detaillierter wie bestimmte Parameter des Inputs erst geloggt werden, danach ein Sanitizing oder bei fehlenden Parametern ein Ablehnen der Request stattfindet oder wenn dies erfolgreich war ggf. ein oder mehrere Use Cases aufgerufen und ihre Ergebnisse zusammengeführt werden.
Abb. 3: Request Chain
Erweiterbarkeit und Skalierbarkeit
Zu Kernzeiten finden mehreren zehntausend Kundenkonversationen pro Stunde statt, was zu Belastungen auf der Middleware von 50.000+ Request pro Minute führen kann.
Entsprechend relevant ist es, dass die Middleware problemlos horizontal skalieren kann.
Um diese horizontale Skalierung zu ermöglichen lassen sich die Use Case-Module bei Bedarf in serverless Functions oder als eigener Microservice auslagern. Der Request Handler kommuniziert mit den Use Case Modulen über ein vom Modul bereitgestelltes Interface, sodass es keine Rolle spielt, ob dahinter ein API-Aufruf oder die Business Logik selbst liegt.
Dieser Aufbau ist ebenfalls vorteilhaft für die Erweiterbarkeit um Use Cases. Neue Use Cases müssen lediglich ein Interface bereitstellen, um eingebunden zu werden.
Abb. 4: Processing Chain
Die Implementierung erfolgte im SAFe-Framework mit einer Größe des Trains von 50+ Personen. Der Entwurf und PoC wurde von Attek umgesetzt, während die weitere Entwicklung in einem hybriden Team aus vier Mitgliedern stattfand.
Techstack
Node.js und TypeScript
Für TypeScript in Kombination mit Node.js gab es zwei relevante Argumente. Zum einen basierte ein großer Teil der restlichen Infrastruktur bereits auf Node.js, wodurch personelle Synergien erzeugt werden konnten, zum anderen eignet sich Node.js mit seinem non-blocking I/O Model sehr gut für den Bau einer performanten und einfach zu skalierenden Middleware. Um die Applikation möglichst modular zu halten und Module über Interfaces zugänglich zu machen, haben wir uns für TypeScript entschieden. Grade im Enterprise Bereich bringt die Typsicherheit von TypeScript diverse Vorteile mit sich.
AWS
Zum Betrieb der Applikation war vom Kunden AWS in Kombination mit Elastic Container Service (ECS) gewünscht.
Docker
Docker ist Standard für den Betrieb von Applikationen jeglicher Art und Voraussetzung für AWS ECS.
Die Lösung ist beim Kunden seit mittlerweile zwei Jahren unter hoher Last ohne Incidents erfolgreich in Betrieb und wird kontinuierlich um weitere Use Cases ergänzt. Wir betreuen das Projekt weiterhin und stehen unserem Kunden beim Ausbau seiner IT-Infrastruktur im Kundenservice mit Rat und Tat zur Seite.