Teil 5 der Blogserie:
Lesen Sie hier die anderen Beiträge der Blogserie:
- Teil 1 „Mit digitalen Assistenten zur gelungenen Customer Experience“
- Teil 2 „How To: einen Chatbot mit Open Source implementieren“
- Teil 3 „Wenn der Chatbot nicht mehr weiter weiß. Wie Sie die Grenzen herkömmlicher virtueller Assistenten überwinden“
- Teil 4 „Smart Answers für Chatbots: Set-up und Konfiguration“
Im vorangegangenen Beitrag unserer Blogserie haben wir gezeigt, wie man Smart Answers – einen Bestandteil der intelligenten Suchplattform Fusion zur semantischen Suche – aufsetzen kann. In diesem abschließenden Teil der Blogserie werden wir dessen Integration in einen Chatbot zeigen, damit er tatsächlich sinnvolle Antworten auf die Fragen seiner Nutzer liefert.
Die Basis
Für die folgende Anleitung setzen wir voraus, dass Smart Answers aufgesetzt und konfiguriert wurde, wie wir es im letzten Blogbeitrag gezeigt haben.
Außerdem werden wir auf den Rasa-Chatbot zur Newsletteranmeldung aus dem zweiten Teil der Blogserie und den zugehörigen Konfigurationsfiles wie der nlu.yml, der domain.yml oder der rules.yml aufbauen. Diese Files werden wir so ergänzen, dass Smart Answers integriert wird und somit auch FAQs beantwortet werden können. Wer den zweiten Beitrag verpasst hat oder noch einmal „spicken“ möchte, wird im Beitrag „How To: einen Chatbot mit Open Source implementieren“ fündig.
Für die Erweiterung des „Basis-Chatbots“ durch Smart Answers wählen wir den folgenden Ansatz: Wir legen einen neuen „Frage-Intent“ an und hinterlegen eine Regel, damit dieser Intent stets eine benutzerdefinierte Aktion auslöst, die Smart Answers aufruft. Der Chatbot wird dann die von Smart Answers bereitgestellte Antwort an den User zurückgeben.
Beginnen wir also mit der Erweiterung der Konfiguration.
Intents
Zunächst ergänzen wir in der nlu.yml einige Beispielfragen für einen neuen Intent ask_question, damit der Chatbot diesen erkennen kann.
Diesen neuen Intent müssen wir auch in der domain.yml ergänzen, damit der Chatbot weiß, dass er existiert. Auch listen wir dort eine neue Aktion namens action_call_smart_answers.
Benutzerdefinierte Aktion zum Aufrufen von Smart Answers
Diese neue Aktion action_call_smart_answers soll die Frage des Users an Smart Answers weiterleiten und die durch Smart Answers gefundene Antwort an den User ausgeben. Dazu ergänzen wir die actions.py um die Klasse CallSmartAnswers. Im folgenden Code müssen einige Variablenwerte an das eigene Setup angepasst werden. Diese sind durch spitze Klammern gekennzeichnet.
Die Klasse CallSmartAnswers holt sich also zunächst die Frage des Users (Rasa speichert User-Input stets in einem sogenannten „Tracker Store“). Dann wird durch die Variable link der API-Call an Fusion zusammengesetzt. Dieser spezifiziert unter anderem die User-Frage, die Anzahl der gewünschten Ergebnisse, den Query-Pipelinenamen und den Collectionnamen. Query-Pipeline und Collection hatten wir im letzten Blogbeitrag aufgesetzt. Im Anschluss wird dieser API-Call ausgeführt, wobei wir auch die Zugangsdaten für Fusion übergeben müssen. Das Ergebnis, die von Smart Answers gefundene Antwort, wird dann durch den Rasa-Chatbot an den User ausgegeben.
Die neue Regel
Bisher kennt der Chatbot den neuen Intent ask_question und die neue benutzerdefinierte Aktion action_call_smart_answers, aber noch nicht deren „Zusammenhang“. Daher ergänzen wir in der rules.yml folgende Regel, damit durch den eben genannten Intent stets die eben genannte Aktion ausgelöst wird.
Die erste Unterhaltung mit dem Rasa Bot
Wir haben nun alle nötigen Konfigurationen vorgenommen, und einer ersten Unterhaltung mit dem Chatbot steht fast nichts mehr im Wege. Wie wir es schon von unserem ersten Rasa Bot kennen, müssen wir zu guter Letzt aber noch ein neues NLU-Modell trainieren, sodass die geänderten Konfigurationen auch wirksam werden. Aus dem Rasa-Projektverzeichnis senden wir also den Befehl
Anschließend müssen wir noch den Action-Server starten, damit der Code unserer benutzerdefinierten Aktion(en) ausgeführt werden kann:
Um schließlich die Unterhaltung mit unserem Assistenten zu starten, führen wir das folgende Kommando aus:
Um den Bot zu testen, begrüßen wir ihn und stellen ihm dann eine Frage. Wie wir unten sehen, liefert der Rasa-Bot die gewünschte Antwort, die er mittels Smart Answers gefunden hat. Zur Erinnerung: In Teil 4 der Blogserie hatten wir verschiedene Inhalte bzw. Antworten in Smart Answers geladen und zudem einige Konfigurationen vorgenommen, sodass Smart Answers mit Hilfe von KI-gestützter semantischer Suche in den geladenen Inhalten die passende Antworten auf Fragen in natürlicher Sprache finden kann.
Die Vorteile. Und geht da noch mehr?
An der eben getesteten Frage zeigt sich bereits ein Vorteil von Smart Answers. Es kann die passende Antwort finden, obwohl diese die Stichwörter „Päckchen“ oder „kaputt“ nicht enthält. Das Machine-Learning-Modell, das in Smart Answers integriert ist, zahlt sich also aus.
Würden wir die Beantwortung von FAQs stattdessen rein „Rasa-intern“ lösen wollen, würde dies einen enormen Aufwand bedeutet. Für sämtliche denkbaren Fragen müssten wir verschiedene beispielhafte Formulierungen hinterlegen. Dies nimmt uns Smart Answers‘ Machine-Learning-Modell ab. Und sobald sich eine Information ändert, müssten auch die in Rasa hinterlegten Antworten geupdatet werden, da der User sonst eine veraltete Antwort erhält.
Mit Smart Answers hingegen können wir nicht nur automatisch das Wissen aus allen möglichen Unternehmensquellen laden, sondern dieses auch regelmäßig automatisch updaten! Der Chatbot ist so ohne manuellen Pflegeaufwand stets auf dem aktuellen Stand und bietet eine einzige Schnittstelle zu allen Datensilos im Unternehmen. In unserem Beispiel hatten wir zwar „nur“ Antworten aus einer CSV-Datei geladen, doch natürlich könnte man in der Praxis auch unternehmensinterne Wissensquellen wie das CRM-System, das eigene Wiki oder Artikelbeschreibungen auf der Unternehmenswebsite anbinden.
Mit dem, was wir in dieser Blogreihe gezeigt haben, sind die Möglichkeiten von Fusion, Smart Answers und Rasa natürlich noch nicht ausgeschöpft. Etwa kann man mit Fusion sogenannte „Signals“ nutzen, um dem User ein personalisiertes Erlebnis zu bieten und so die Customer Experience zu optimieren.