AI Agent ROI Rechner
Kostenloses Training: Chatbot Crashkurs
Whitepaper: Die Akzeptanz von Chatbots
System Entities
--> zum BOTwiki
System Entities sind vordefinierte Entitäten, die in einer AI Agent Plattform bereits ab Werk zur Verfügung stehen und häufig wiederkehrende Datentypen aus natürlicher Sprache extrahieren. Typische Beispiele sind Datum, Uhrzeit, Ort, Währung, Telefonnummer oder Zahl. Während Custom Entities individuell für einen Anwendungsfall angelegt werden, decken System Entities universelle Konzepte ab und sparen Trainingsaufwand.
Wie System Entities funktionieren
Wenn ein Nutzer eine Anfrage formuliert, analysiert das NLU-Modell zunächst den Intent und sucht parallel nach relevanten Parametern in der Äußerung. Genau hier kommen System Entities ins Spiel: Sie identifizieren standardisierte Datentypen unabhängig von der konkreten Formulierung und liefern die extrahierten Werte in einem normalisierten Format zurück.
Sagt eine Anruferin am Telefon „Ich hätte gerne einen Termin am Dienstag um zehn Uhr“, erkennt der AI Agent über eine Datums-Entität den nächsten Dienstag und liefert ihn im ISO-Format zurück. Eine Uhrzeit-Entität ergibt parallel den Wert 10:00. Diese Normalisierung ist entscheidend, weil nachgelagerte Systeme wie Kalender, CRM oder Ticketing eindeutige Werte benötigen und keine Freitext-Interpretation leisten können.
Typen von System Entities
Plattformen unterscheiden meist drei Kategorien, die sich im Rückgabewert unterscheiden. Sie sind eng mit dem Konzept der Entity verknüpft und erweitern dieses um sofort einsetzbare Standardtypen.
- System Mapping: Liefert einen normalisierten Referenzwert, etwa ein Datum im ISO-8601-Format oder eine Währung als Zahlenwert mit Code.
- System Enum: Gibt den erkannten Begriff so zurück, wie er geäußert wurde, ohne ihn auf eine Standardform zu mappen, beispielsweise Farbnamen.
- System Composite: Kombiniert mehrere Entitäten zu einem Objekt, etwa einen Geldbetrag bestehend aus Wert und Währung.
Typische vordefinierte Entitäten in modernen Plattformen sind Datum, Uhrzeit, Dauer, Zahl, Ordinalzahl, Geldbetrag, Mengenangabe, Adresse, Stadt, Land, Sprache, Personenname, E-Mail und Telefonnummer.
Häufig gestellte Fragen (FAQ)
System Entities sind vordefinierte Entitäten, die eine AI Agent Plattform standardmäßig mitbringt. Sie erkennen universelle Datentypen wie Datum, Uhrzeit, Ort, Zahl oder Währung in natürlicher Sprache und liefern die Werte in einem normalisierten Format zurück. Dadurch müssen diese Standardfälle nicht selbst trainiert werden.
System Entities decken allgemeine Konzepte ab, die in vielen Anwendungsfällen gleich sind. Custom Entities werden individuell für ein Projekt definiert, etwa Produktkategorien, Vertragstypen oder interne Bezeichnungen. In der Praxis werden beide kombiniert, um sowohl universelle als auch fachspezifische Informationen zuverlässig zu erfassen.
> Zurück zum BOTwiki
Chatbot Operations
--> zum BOTwiki
Die Chatbot Operations beginnt nach der Entwicklungsphase des Chatbots und setzt meistens den Go Live, also die Veröffentlichung des Chatbots, voraus. Es handelt sich also um den Betrieb des Chatbots. Denn nachdem echte Nutzende mit dem Chatbot interagieren, ergeben sich viele Optimierungspotenziale und vor allem muss der Chatbot stetig trainiert werden.
Dabei strebt man an, den Chatbot sowohl kurzfristig als auch langfristig zu optimieren.
Bei der kurzfristigen Optimierung des Chatbots sollten direkt nach der Live-Stellung die Konversationen mit den Nutzern noch täglich geprüft werden. Dies kann dann nach einem bestimmten Trainingsgrad des Chatbots reduziert werden. Denn das wichtigste ist es vor allem den Chatbot zu trainieren. Das heißt falsche Intent Zuweisungen zu korrigieren, neue Trainings phrasen zu matchen und neue Inhalte nachzupflegen.
Langfristig sollte sich Gedanken gemacht werden, ob beispielsweise der Messenger Dienst der Richtige war, welche bestehenden Services gut oder schlecht funktionieren, welche weiteren Fragen oder Prozesse der Chatbot noch erschließen kann oder ob man weitere Sprachen oder in Länder ausrollen möchte.
Chatbot Operations kann auch nur mit funktionierender Analytics effizient betrieben werden, um gegen seine Ziele oder KPIs zu messen. Dabei können eigene Analytic Tools aufgebaut werden oder es werden Third Party Tools wie Chatbase oder Dashbot integriert.
Zum Chatbot Betrieb gehört auch eine Intent Management Guideline, welche Prozesse und Regeln definiert auf welche Weise neue Inhalte in den Chatbot eingepflegt werden und auf was man achten sollte. Diese Guidelines behandeln zum Beispiel Themen wie Intent Granularität, Korrelation, Namenskonventionen oder Freigabeprozesse.
> Zurück zum BOTwiki
Clustering
--> zum BOTwiki
In vielen Kontexten der Datenverarbeitung kommt es vor, dass man Einheiten eines Typs gruppieren möchte. Clustering bezeichnet eine Analyse der vorliegenden Daten, bei der jedem Datenpunkt eine Klasse zugewiesen wird. In einem Cluster werden Daten zusammengefasst, die sich ähnlich sind. Man kann Clusteringverfahren benutzen, um neue Daten automatisch in vorhandene Gruppen hinzuzufügen oder um vorhandene Daten auf ihre Gruppierung hin zu analysieren. Dafür braucht man keine Beispieldaten, die man vorher per Hand in vorgegebene Gruppen eingeteilt hat. Es handelt sich um ein unüberwachtes Lernverfahren.
Anwendung bei Chatbots
Im Kontext von Chatbots ist Clustering hilfreich zur initialen Datenanalyse, sofern historische Daten gegeben sind. So kann man zum Beispiel aus der Chathistorie bestimmen, welche Intents erstellt werden sollten. Im Betrieb eines Chatbots können außerdem gesammelte Sätze, die keinen Intent getroffen haben, durch Clustering in eine Struktur gebracht und so neue Intents identifiziert werden.
Funktionsweise:
Für ein Clustering braucht man zunächst eine Datenrepräsentation. Im Normalfall werden Daten als Zahlenvektoren dargestellt, wobei einzelne Dimensionen des Vektors Eigenschaften der Daten widerspiegeln. Um diese nun sinnvoll zu gruppieren, benötigt man ein Maß für Ähnlichkeit. In den meisten Fällen wird hierfür die euklidische Distanz benutzt. [1] Je nach Algorithmus kann diese Metrik und die Art wie die Daten den Gruppen zugeteilt werden variieren.
Nearest Neighbour
Die einfachste Art wäre, dass man am Anfang einer gewissen Anzahl an Datenpunkten, zufällig eine Klasse zuweist, und daraufhin für alle anderen Punkten die Klasse annimmt, die ihr nächster Nachbar hat.
Wenn diese Methode aber zu ungenau ist, kann man sie erweitern, indem man statt nur einem Nachbar die Klassen von mehreren Nachbarn in Betracht zieht und die Klasse wählt, die am häufigsten vorkommt. [2]
Centroid-basierte Verfahren
Noch besser werden die Ergebnisse, wenn man Centroid-basierte Verfahren benutzt. Hierbei wird für jedes Cluster ein Zentrumspunkt bestimmt (zum Beispiel der Mittelwert aller Punkte eines Clusters) und dieser als Referenzpunkt für die Zuweisung benutzt. Am Anfang können diese Centroids zufällig gesetzt werden. Für die Daten wird dann jeweils die Entfernung zu allen Zentren berechnet. Der Datenpunkt kommt dann in das Cluster zu dem er die geringsten Entfernung hat. Daraufhin wird der Centroid entsprechend angepasst, weil durch das Hinzufügen eines Punkts ein neuer Mittelwert entsteht. Das Zentrum wandert mit der Zeit. Sobald ein Konvergenzkriterium erfüllt ist (zum Beispiel wenn die Änderungen der Centroids zu klein sind), stoppt der Algorithmus. [3][4]
Textrepräsentation: Bag of Words
Textdaten können auf verschiedene Weisen in Vektoren repräsentiert werden. In einfachen Anwendungsfällen kann man zum Beispiel ein Vokabular definieren, das man sich wie eine Tabelle vorstellen kann. Jedes Wort entspricht einer ganzen Zahl (wie eine ID). Mit Hilfe einer solchen Tabelle kann nun ein Satz in ein Vektor umgewandelt werden. Jeder Satz entspricht einem Vektor, bei dem jede Dimension einem Wort des Vokabulars entspricht. Für jedes Wort, das im Satz vorkommt, erhält die Dimension den Wert 1, alle nicht vorhandenen Worte bleiben auf 0. [5]
Textrepräsentation: Deep Learning Modelle
Für eine Repräsentation, die mehr semantische Eigenschaften des Texts beinhaltet, benutzt man Vektoren, die durch Deep Learning-Verfahren entstehen. Für diese Art von Verfahren werden viele Daten benötigt. Zum Beispiel kann man mit recurrent neural networks (RNNs) Sprachmodelle trainieren, indem man immer das nächste Wort für eine gegebene Wortsequenz vorhersagt. Dies funktioniert so, dass man die Sequenz in einem Encoder-RNN zu einem Vektor umwandelt und mit einem Decoder-RNN den Vektor in das folgende Wort übersetzt. Wenn man jetzt nur den Encoder benutzt, erhält man eine Vektorrepräsentation des Satzes, die deutlich weniger Dimensionen als bei einem Bag-of-Words Ansatz hat und mehr semantischen Inhalt besitzt.
> Zurück zum BOTwiki
Quellen
[1] https://sites.google.com/a/erhard-rainer.com/erhard-rainer/mathematik/distanz-zwischen-zwei-punkten
[2] k-nearest neighbors, https://towardsdatascience.com/k-nearest-neighbours-introduction-to-machine-learning-algorithms-18e7ce3d802a
[3] https://www.youtube.com/watch?v=_aWzGGNrcic
[4] https://www-m9.ma.tum.de/material/felix-klein/clustering/Methoden/K-Means.php
[5] https://machinelearningmastery.com/gentle-introduction-bag-words-model/
Messenger Dienste
--> zum BOTwiki
Messenger Services bezeichnen textbasierte Kommunikationsplattformen wie WhatsApp, Facebook Messenger, Telegram, Microsoft Teams oder Slack, über die Privatpersonen und Unternehmen in Echtzeit Nachrichten austauschen. Im B2B-Kontext sind sie längst von rein privaten Chat-Apps zu unternehmenskritischen Dialogkanälen geworden, über die Kundenservice, Beratung und interne Prozesse abgewickelt werden.
Aus Sicht eines AI Agents sind Messenger Services derjenige Touchpoint, an dem die meisten asynchronen Kundendialoge stattfinden und damit ein zentraler Baustein moderner Conversational AI. Wer Voice, Chat und E-Mail orchestriert, muss verstehen, welche Eigenschaften jeder Messenger mitbringt, welche Zielgruppen er erreicht und wie sich AI Agents technisch und regulatorisch einbinden lassen.
Was Messenger Services im Unternehmenskontext leisten
Messenger Services unterscheiden sich von klassischen Kommunikationskanälen wie Telefon oder E-Mail in mehreren Punkten: Sie sind asynchron, mobil-first und für Nutzerinnen und Nutzer im Alltag fest etabliert. Eine Anfrage wird dort gestellt, wo die Person ohnehin kommuniziert. Ohne App-Wechsel, ohne Login-Reibung. Für Unternehmen bedeutet das kürzere Reaktionszeiten, höhere Antwortquoten und eine niedrigere Hemmschwelle bei sensiblen Themen wie Terminbuchung, Reklamation oder Bestellstatus.
Gleichzeitig haben Messenger-Plattformen eigene technische Spielregeln: Business APIs, Template-Nachrichten, 24-Stunden-Servicefenster, Opt-in-Pflichten und unterschiedliche Datenschutzanforderungen. Eine professionelle Conversational-AI-Lösung muss diese Rahmenbedingungen kennen und sauber in den AI Workflows abbilden, statt jeden Kanal isoliert zu behandeln.
Überblick über relevante Messenger-Dienste
Im DACH-Raum dominieren wenige Dienste den Endkundenkontakt, während internationale Märkte und der B2B-Bereich eigene Schwerpunkte haben. Die folgenden Plattformen sind für AI Agents am relevantesten:
- WhatsApp Business: Marktführer im DACH-Endkundenkontakt, über die offizielle Cloud API für AI Agents nutzbar, mit klaren Vorgaben für Opt-in und Template-Nachrichten.
- Facebook Messenger: relevant für Marken mit starker Social-Präsenz, geeignet für FAQ, Recruiting und Pre-Sales-Beratung.
- Telegram: technisch offen, beliebt für Communities, Newsletter und Status-Updates, mit unkomplizierter Bot-Anbindung.
- WeChat: praktisch unverzichtbar für Unternehmen mit China-Geschäft, deckt Service, Bestellung und Bezahlung in einer App ab.
- Microsoft Teams und Slack: Standardkanäle für interne Use Cases wie IT-Support, HR-Self-Service und Wissensdatenbanken.
- Apple Messages for Business und RCS: zunehmend relevant für markenkonforme, native Konversationen auf iOS und Android.
Für die Auswahl ist weniger die technische Reichweite entscheidend als die Frage, wo die eigene Zielgruppe tatsächlich erreichbar ist und welche Dienste sich rechtssicher in bestehende Systeme einbinden lassen.
Häufig gestellte Fragen (FAQ)
Messenger Services sind textbasierte Kommunikationsplattformen wie WhatsApp, Facebook Messenger, Telegram oder Microsoft Teams, die Nachrichten in Echtzeit zwischen Personen oder zwischen Unternehmen und Kund:innen übermitteln. Im B2B-Kontext werden sie als Servicekanal genutzt und lassen sich über Business APIs an AI Agents anbinden. Sie sind asynchron, mobil-first und meist tief in den Alltag der Nutzerinnen und Nutzer integriert.
Für den Endkundenkontakt im DACH-Raum sind WhatsApp Business und Facebook Messenger besonders relevant, im internationalen Umfeld zusätzlich WeChat. Für interne Use Cases dominieren Microsoft Teams und Slack. Die Auswahl sollte sich an der Zielgruppe, der gewünschten Reichweite und den Datenschutzanforderungen orientieren, nicht an der reinen Anzahl verfügbarer Konnektoren.
Jeder Messenger hat eigene Anforderungen an Auftragsverarbeitung, Datenstandort und Opt-in. WhatsApp Business etwa setzt eine ausdrückliche Einwilligung sowie Template-Nachrichten für proaktive Kommunikation voraus. Unternehmen im DACH-Raum sollten die jeweiligen Verträge, Speicherorte und Löschfristen prüfen und die Kanalauswahl mit Datenschutz und IT-Sicherheit abstimmen.
--> Zurück zum BOTwiki
Channel Connector
--> zum BOTwiki
Ein Channel Connector ist eine Softwarekomponente, die Nachrichten aus verschiedenen Messaging-Kanälen in ein einheitliches Datenformat überführt. Er wird in der Entwicklung von Chatbot-Applikationen eingesetzt, wenn mehrere Kanäle gleichzeitig unterstützt werden sollen. Durch den Einsatz eines Channel Connectors wird die Formatlogik aus der eigentlichen Chatbot-Applikation ausgelagert.
Warum Channel Connectors benötigt werden
Sobald eine Chatbot-Applikation über mehr als einen Kanal erreichbar sein soll, entsteht ein strukturelles Problem: Jeder Messaging-Dienst liefert Nachrichten in einem eigenen Datenformat. Ein Kanal wie Facebook Messenger strukturiert eingehende Nachrichten anders als etwa Slack oder WhatsApp. Die Nutzernachricht, also der eigentliche Text einer Konversation, ist in jedem dieser Formate an einer anderen Stelle im Datensatz zu finden und muss entsprechend unterschiedlich angesprochen werden.
Wird diese Formatvielfalt direkt in der Chatbot-Applikation behandelt, entstehen schnell mehrfach vorhandene, kanalspezifische Codestücke. Solche Duplikate erhöhen den Wartungsaufwand und erschweren die Weiterentwicklung der Applikation.
Funktionsweise eines Channel Connectors
Ein Channel Connector kennt die Datenformate der angebundenen Kanäle und überführt alle eingehenden Nachrichten in ein gemeinsames, einheitliches Schema. Die Chatbot-Applikation erhält damit unabhängig vom Ursprungskanal immer gleich strukturierte Daten. Ebenso werden ausgehende Antworten durch den Connector kanalspezifisch aufbereitet, bevor sie an den jeweiligen Dienst weitergeleitet werden.
Ein konkretes Beispiel für dieses Prinzip ist Smooch, ein Dienst, der Nachrichten aus Kanälen wie Slack, Facebook Messenger, WhatsApp, Telegram und weiteren Plattformen empfängt, vereinheitlicht und auf ein selbst definiertes Schema abbildet. Die Chatbot-Applikation kommuniziert in diesem Fall ausschließlich mit Smooch, nicht direkt mit den einzelnen Kanälen.
Vergleich von Datenformaten am Beispiel Facebook und Slack
Der Unterschied zwischen kanalspezifischen Datenformaten lässt sich gut am Vergleich von Facebook Messenger und Slack verdeutlichen. In beiden Fällen enthält der Datensatz dieselbe Nutznachricht, beispielsweise den Text „Das ist eine Text Message". Der Pfad, über den diese Nachricht im jeweiligen Datensatz erreichbar ist, unterscheidet sich jedoch. Bei Facebook Messenger ist die Nachricht in einer verschachtelten Struktur aus Objekt- und Array-Ebenen zu finden, bei Slack folgt der Aufbau einem anderen Schema mit abweichenden Feldbezeichnungen.
Ohne eine vereinheitlichende Schicht müsste für jeden Kanal ein eigener Algorithmus geschrieben werden, der die Nachricht aus dem jeweiligen Format extrahiert. Ein Channel Connector übernimmt diese Aufgabe zentral und stellt der Chatbot-Applikation einen einheitlichen Zugriffspunkt zur Verfügung.
Facebook: [2] Slack: [3]
Vorteile für die Chatbot-Entwicklung
Durch den Einsatz eines Channel Connectors wird der Implementierungsaufwand bei der Anbindung neuer Kanäle deutlich reduziert. Ein neuer Kanal muss lediglich im Connector konfiguriert werden, ohne dass die Kernlogik der Chatbot-Applikation angepasst werden muss. Bestehende Konversationslogik, Intents und Antwortstrukturen bleiben unverändert und können kanalübergreifend genutzt werden.
Darüber hinaus wird die Wartbarkeit verbessert, da kanalspezifische Formatlogik an einem zentralen Ort gepflegt wird. Änderungen an einem Kanalformat erfordern nur eine Anpassung im Connector, nicht mehrere Eingriffe in der Applikationslogik.
Eine API-Integration bezeichnet die direkte technische Anbindung eines einzelnen Dienstes über seine Programmierschnittstelle. Ein Channel Connector hingegen ist eine übergeordnete Schicht, die mehrere solcher Anbindungen verwaltet und die daraus resultierenden Datenformate vereinheitlicht. Während eine API-Integration kanalspezifisch ist, ermöglicht ein Channel Connector die kanalunabhängige Kommunikation einer Chatbot-Applikation mit mehreren Diensten gleichzeitig.
Nein, es gibt sowohl externe Dienste wie Smooch als auch plattformseitig integrierte Lösungen, wie sie etwa in BOTfriends X verfügbar sind. Diese übernehmen die Normalisierung der Nachrichtenformate, ohne dass eine eigene Implementierung erforderlich ist. Der Aufwand für die Kanalanbindung beschränkt sich in solchen Fällen auf die Konfiguration.
Wird kein Channel Connector verwendet, muss die Chatbot-Applikation für jeden Kanal separate Formatierungslogik enthalten. Das führt zu kanalspezifischen Codeduplikaten, erhöhtem Wartungsaufwand und erschwerter Skalierbarkeit. Bei der Anbindung eines neuen Kanals müssten Teile der Applikationslogik jeweils neu geschrieben oder angepasst werden.
Zurück zum BOTwiki
On Premise
--> zum BOTwiki
On Premise Voicebots und Chatbots sind dialogfähige Systeme, die vollständig in der eigenen Infrastruktur eines Unternehmens laufen und keine externen Cloud-Dienste für die Sprachverarbeitung benötigen. Sie bilden den Gegenpol zu cloud-basierten Lösungen und sind für Branchen mit hohen Anforderungen an Datenschutz, Compliance und Souveränität relevant.
Für Unternehmen aus dem Banken-, Versicherungs-, Gesundheits- und Behördenumfeld ist die Frage nach On-Premise- oder EU-Hosting-Modellen oft entscheidend. In modernen Architekturen werden On Premise Lösungen als Teil einer AI Agent Plattform gedacht, die Voice, Chat und E-Mail in einer Multi-Agent-Orchestrierung verbindet.
Was On Premise ausmacht
Bei einem On Premise Voicebot oder Chatbot werden alle relevanten Komponenten - Sprachverstehen, Dialogsteuerung, Knowledge AI und Backend-Anbindung - auf Servern des Unternehmens oder in einer dedizierten privaten Umgebung betrieben. Konversationsdaten verlassen diese Infrastruktur nicht und werden weder zu Trainingszwecken an Drittanbieter weitergegeben noch in öffentlichen Cloud-Regionen verarbeitet. Das ist zentral, sobald personenbezogene Daten, Vertragsdetails oder Patientendaten im Dialog vorkommen.
Technisch unterscheiden sich On Premise Lösungen dadurch, dass externe NLU-Services kommerzieller Cloud-Anbieter nicht ohne Weiteres nutzbar sind. Stattdessen kommen quelloffene oder selbst betriebene Sprachmodelle zum Einsatz.
DSGVO, EU-Hosting und Made in Germany
Der Treiber für On Premise Lösungen ist regulatorisch. DSGVO, branchenspezifische Vorgaben wie BAIT, KAIT oder VAIT sowie interne Konzernrichtlinien fordern Kontrolle darüber, wo Daten verarbeitet werden. On-Premise oder dediziertes EU-Hosting in deutschen Rechenzentren minimieren Risiken bei Drittlandtransfers.
- Volle Hoheit über Konversationsdaten und Audio-Mitschnitte aus Voice-Kanälen.
- Hosting in deutschen oder europäischen Rechenzentren, optional Made in Germany.
- Klare Trennung zwischen produktiven Daten und Trainingsdaten.
- Nachvollziehbare Verarbeitungsverzeichnisse für Datenschutzbeauftragte und Auditoren.
Bedeutung für Voice und Chat
Im Voice-Kanal, etwa bei einem Voicebot in der Hotline-Triage einer Versicherung oder eines Klinikverbunds, ist die On-Premise-Frage besonders sensibel, da Anrufdaten Stimmprofile, Krankheitsdetails oder Vertragsbezüge enthalten.
Im Chat- und E-Mail-Kontext, etwa im Mitarbeitenden-Support oder im Schadensmeldungsprozess, sind On Premise Chatbots relevant, sobald Wissensquellen mit vertraulichen Inhalten angebunden werden. Knowledge AI auf eigenen Servern bindet interne Dokumente, Verträge und Tickets in den Dialog ein, ohne sie für externe Modelle zu öffnen.
Nachteile von On-Premise
In der Praxis ist eine reine On-Premise-Welt nicht immer wirtschaftlich. Hochleistungsfähige Sprachmodelle, kontinuierliches Training und der Betrieb einer skalierbaren Conversational AI Platform verursachen Aufwand, wenn alles ausschließlich intern läuft.
Häufig gestellte Fragen (FAQ)
Ein On Premise Chatbot ist ein dialogfähiger AI Agent, dessen Komponenten für Sprachverstehen, Dialogsteuerung und Wissensanbindung vollständig in der eigenen Infrastruktur eines Unternehmens betrieben werden. Konversationsdaten verlassen diese Umgebung nicht und werden nicht an externe Cloud-Anbieter übermittelt. Damit eignet sich das Modell besonders für Branchen mit hohen Datenschutz- und Compliance-Anforderungen.
Sinnvoll ist On-Premise vor allem dann, wenn regulatorische Vorgaben, branchenspezifische Aufsichtsanforderungen oder interne Sicherheitsrichtlinien eine externe Datenverarbeitung ausschließen. Typische Felder sind Banken, Versicherungen, Gesundheitswesen, öffentliche Verwaltung und kritische Infrastrukturen. In weniger sensiblen Bereichen ist hingegen oft eine EU-Cloud-Variante mit klaren Auftragsverarbeitungsverträgen ausreichend.
Bei On-Premise läuft die Lösung im eigenen Rechenzentrum oder einer dedizierten privaten Umgebung. EU-Hosting bedeutet, dass die Lösung in einer Cloud-Region innerhalb der EU betrieben wird, oft mit deutschen Standorten und Made-in-Germany-Anspruch. Beide Modelle adressieren Datenschutzanforderungen, unterscheiden sich aber in Kontrolle, Aufwand und Skalierbarkeit.
Ja, Voicebots lassen sich grundsätzlich on-premise oder in einem dedizierten EU-Hosting realisieren, sodass Audiodaten und Transkripte die kontrollierte Umgebung nicht verlassen. Die Architekturentscheidung sollte jeweils anhand von Lastprofil, Latenzanforderungen und regulatorischem Rahmen getroffen werden.
On Premise Chatbots erfordern mehr Eigenleistung beim Betrieb der Sprachmodelle, beim Skalieren der Infrastruktur und beim laufenden Monitoring. Da viele leistungsstarke Modelle primär als Cloud-Service angeboten werden, müssen on-premise oft alternative oder selbst betriebene Modelle eingesetzt werden.
--> Zurück zum BOTwiki
Happy Path
--> zum BOTwiki
Der Happy Path beschreibt den idealen und störungsfreien Ablauf eines Prozesses oder einer Konversation. Es handelt sich um den erwarteten Weg, auf dem ein Ziel ohne Abweichungen oder Fehler erreicht wird. Dieser Prozesspfad wird als der effizienteste und kostengünstigste angesehen, da keine unerwarteten Ereignisse oder Probleme auftreten.
Im Bereich der Conversational AI, insbesondere bei Chatbots und Voicebots, stellt der Happy Path die am häufigsten und erfolgreichsten genommenen Interaktionspfade der Nutzer dar. Er wird für die Konzeption und Optimierung von Dialogen verwendet, um sicherzustellen, dass Nutzeranfragen effizient bearbeitet werden und eine positive Interaktion erlebt wird.
Abgrenzung zum Unhappy Path und Edge Case
Im Gegensatz dazu stehen die "Unhappy Paths" oder "Edge Cases". Dies sind alternative Szenarien, die eintreten, wenn Nutzer vom idealen Weg abweichen. Gründe dafür können Fehleingaben, unerwartete Anfragen oder technische Störungen sein. Während der Happy Path den Regelfall abbildet (z.B. erfolgreiche Passworteingabe), decken Edge Cases die Ausnahmen ab (z.B. Passwort vergessen, falsches Format, System-Timeout). Ein klares Verständnis beider Konzepte ist essenziell für die Entwicklung robuster Systeme. Historisch gesehen lag der Fokus oft rein auf der Kernfunktionalität, doch mit dem Aufstieg des UX-Designs wurde die ganzheitliche Betrachtung aller potenziellen Nutzerwege, inklusive der Edge Cases, zum Standard.
Wie funktioniert der Happy Path?
Der Happy Path ist kein technisches System an sich, sondern ein Design- und Testkonzept, das auf sorgfältiger Planung und Analyse basiert. Seine "Funktionsweise" liegt in der methodischen Konzeption und Validierung des idealen Nutzerflusses.
- Zielgruppendefinition und Anforderungsanalyse: Am Anfang steht die genaue Definition der Nutzerziele. Was möchte der primäre Nutzer in 80% der Fälle erreichen? Für einen E-Commerce-Chatbot wäre dies z.B. "Produkt finden und kaufen".
- User Journey Mapping: Der ideale Prozess wird Schritt für Schritt visualisiert. Dies geschieht oft in Form von Flowcharts oder User-Journey-Maps. Jeder Interaktionspunkt (Touchpoint) wird definiert, von der ersten Anfrage des Nutzers bis zum erfolgreichen Abschluss.
- Dialogdesign (Conversational AI): Im Kontext von Chatbots werden die Dialogflüsse (Conversation Flows) entworfen. Für den Happy Path bedeutet das, klare Fragen zu stellen, eindeutige Antwortoptionen zu bieten und die notwendigen Informationen in einer logischen Reihenfolge abzufragen.
4. Prototyping und Validierung: Ein Prototyp des Prozesses wird erstellt und getestet. Beim Happy Path Testing wird überprüft, ob der definierte Idealweg technisch einwandfrei funktioniert. Hierbei werden ausschließlich valide Daten und erwartete Aktionen verwendet.
Beispiel für den Happy Path am Use Case "Pizza bestellen"
An diesem Beispiel wird dargestellt wie eine "glückliche" Konversation zwischen User und Chatbot aussehen kann bei einer Pizza Bestellung. Alle Informationen, welche der Nutzer dem Chatbot mitgibt können verarbeitet werden und es entstehen keine Missverständnisse.
Beispiel für den Edge Case am Use Case "Pizza bestellen"
An diesem Beispiel erkennt man, dass es allerdings auch großes Fehlerpotenzial geben kann, wenn der User Antworten sendet, welche der Chatbot nicht verarbeiten kann. In der unteren Grafik wird gezeigt, dass der User eine Adresse eingibt, die außerhalb von Deutschland ist. In diesem Fall kann keine Lieferung stattfinden. Solche Edge Cases sollte man im Vorhinein bedenken und in der Conversational Map abbilden. Man sollte sich fragen, wie in solchen Situationen mit dem User umgegangen wird. Zum Beispiel informiert man den Nutzer, dass man nur innerhalb von Deutschland liefert oder man gibt ihm die Möglichkeit die Adresse erneut einzugeben im Falle eines Missverständnisses.
Anwendungsbereiche und Use Cases
Der Happy Path ist ein universelles Konzept, das in allen digitalen Interaktionen Anwendung findet, bei denen ein Nutzer ein Ziel verfolgt.
- Kundenservice-Automatisierung: Ein AI Agent für die Meldung eines Schadens in einer Versicherung folgt dem Happy Path, indem er den Nutzer strukturiert durch die erforderlichen Angaben führt (Vertragsnummer, Schadensdatum, Beschreibung), ohne dass der Nutzer den Prozess abbricht oder menschliche Hilfe benötigt.
- Automatisierte Terminvereinbarung: Ein KI-Terminplaner koordiniert ein Meeting zwischen drei Teilnehmern, indem er deren Kalender abgleicht, einen für alle freien Slot findet und die Einladungen verschickt, ohne dass ein langwieriges Hin- und Herschreiben über alternative Termine oder Zeitzonen-Konflikte notwendig wird.
- E-Commerce Einkaufs-Assistent: Ein Shopping-Agent identifiziert präzise ein gesuchtes Ersatzteil anhand eines hochgeladenen Fotos, prüft die Kompatibilität mit dem hinterlegten Gerätemodell des Nutzers und legt den Artikel direkt in den Warenkorb, ohne dass der Kunde technische Spezifikationen manuell vergleichen oder den Support kontaktieren muss.
Ein gut definierter Happy Path löst das Problem der Prozesskomplexität, indem er den kognitiven Aufwand für den Nutzer minimiert und die Effizienz maximiert. Branchen-Benchmarks zeigen, dass eine Reduzierung der Schritte im Checkout-Prozess (ein optimierter Happy Path) die Konversionsrate um 20-30% steigern kann.
Vorteile und Herausforderungen
Die Konzentration auf den Happy Path bietet klare Vorteile, birgt aber auch Herausforderungen, wenn Edge Cases vernachlässigt werden.
Vorteile:
- Verbesserte User Experience
- Höhere Konversionsraten
- Effiziente Entwicklung
- Einfacheres Testing
Herausforderungen
- Gefahr der Übersimplifizierung
- Frustration bei Abweichung
- Unvollständiges Bild
Die größte Herausforderung besteht darin, die richtige Balance zu finden: den Happy Path zu optimieren, ohne die robusten Mechanismen zur Behandlung von Ausnahmen zu vernachlässigen.
Häufig gestellte Fragen (FAQ)
Der Happy Path beschreibt den idealen, fehlerfreien Weg eines Nutzers zur Zielerreichung: das erwartete Standardszenario. Ein Edge Case hingegen ist ein seltener Ausnahmefall, der auftritt, wenn der Nutzer vom idealen Weg abweicht, z.B. durch eine unerwartete Eingabe oder einen Systemfehler. Der Happy Path ist die Regel, der Edge Case die Ausnahme, die aber für ein robustes System ebenfalls berücksichtigt werden muss.
Organisatorisch benötigt man ein klares Verständnis der Nutzerziele und der primären Geschäftsprozesse. Technisch sind Analyse-Tools (z.B. Web-Analytics, CRM-Daten) zur Identifizierung der häufigsten Nutzerwege entscheidend. Zudem ist ein interdisziplinäres Team aus UX-Designern, Produktmanagern und Entwicklern notwendig, um den Prozess ganzheitlich zu gestalten und zu validieren, von der ersten Skizze bis zum finalen Test.
Die Dauer hängt stark von der Komplexität des Prozesses ab. Ein einfacher Prozess wie eine Newsletter-Anmeldung kann in wenigen Tagen optimiert werden. Ein vollständiger Checkout- oder Onboarding-Prozess kann wesentlich mehr Zeit in Anspruch nehmen. Faktoren sind die Qualität der Bestandsdaten, die Komplexität der Systemintegration und der Umfang der erforderlichen A/B-Tests zur Validierung der Verbesserungen.
Die Kosten umfassen primär personelle Ressourcen für Analyse, Konzeption (UX/UI), technische Entwicklung und Testing. Hinzu können Lizenzkosten für Analyse- oder A/B-Testing-Tools kommen. Der Total Cost of Ownership (TCO) sollte dem erwarteten Return on Investment (ROI) gegenübergestellt werden, der sich durch höhere Konversionsraten, gesteigerte Effizienz und verbesserte Kundenzufriedenheit ergibt.
Eine rein auf den Happy Path fokussierte Entwicklung ist nicht zu empfehlen. Der beste Ansatz ist eine ganzheitliche "Journey-Optimierung". Dabei wird der Happy Path als Priorität 1 optimiert, gleichzeitig werden aber auch die häufigsten "Unhappy Paths" identifiziert und mit robusten Fehlerbehandlungen und alternativen Lösungswegen versehen. Ziel ist ein fehlertolerantes System, das Nutzer auch bei Abweichungen vom Idealweg sicher zum Ziel führt.
> Zurück zum BOTwiki
Conversational Design
--> zum BOTwiki
Conversational Design beschreibt den konzeptionellen Prozess, der jedem technisch gebauten AI Agent vorausgeht. Es legt fest, welche Probleme der Agent lösen soll, mit welchen Nutzergruppen er spricht, welche Persönlichkeit er hat und wie Dialoge konkret verlaufen. Damit ist Conversational Design das Fundament für jede Conversational-AI-Lösung.
Unabhängig davon, ob sie als Voicebot in der Hotline, als Chatbot auf der Website oder als E-Mail-Automation eingesetzt wird. Eine durchdachte Design-Phase entscheidet später darüber, ob Anrufende und Schreibende ihre Anliegen wirklich lösen können oder im Fallback landen.
Bestandteile eines sauberen Conversational Designs
Ein vollständiges Conversational Design folgt mehreren Phasen, die aufeinander aufbauen. Zuerst werden Use Cases definiert, also konkrete Anliegen wie Terminvereinbarung, Tarifauskunft oder Statusabfrage. Daraus ergeben sich User Stories und funktionale Anforderungen, die den fachlichen Rahmen abstecken. Anschließend werden Verhaltensregeln und die Tonalität in Form von Personas modelliert, um Sprachstil, Do's und Don'ts abzustecken. Erst danach beginnt die Ausarbeitung der eigentlichen Dialogflüsse.
Zentrales Werkzeug ist die Conversational Map. Eine visuelle Darstellung aller möglichen Gesprächspfade, Verzweigungen und Rückfragen. Sie macht sichtbar, wo Sackgassen entstehen, wo Eskalationen an Mitarbeitende nötig sind und wo der Agent eigenständig abschließen kann.
Persönlichkeit, Tonalität und Markenstimme
Ein AI Agent ist immer auch Repräsentant der Marke. Ein Teil des Conversational Designs ist es, festzulegen, wie der Agent klingt, welche Werte er transportiert und wie er auf schwierige Situationen reagiert. In BOTfriends X werden diese Einstellungen in der AI Agent Persona gemacht. Das umfasst Wortwahl, Satzlänge, Anrede, Humorgrad und den Umgang mit Beschwerden. Bei einem Versicherungsunternehmen wird die Tonalität anders ausfallen als bei einer jungen D2C-Marke. Die Methodik dahinter ist jedoch dieselbe.
Für die Umsetzung helfen einige Leitlinien:
- Eine konsistente Persönlichkeit über alle Kanäle hinweg, von der Telefonansage bis zum Chat-Fenster.
- Klare Sprachregeln für Begrüßung, Rückfragen, Bestätigungen und Verabschiedung.
- Definierte Eskalationsformulierungen, wenn ein Anliegen an Mitarbeitende übergeben wird.
- Verständliche, kurze Sätze statt Behördendeutsch. Gerade für gesprochene Ausgaben essenziell.
- Klare Guardrails um festzulegen, über welche Themen nicht gesprochen werden darf.
Bedeutung für Voice und Chat
Im Voice-Kanal stellt Conversational Design besonders hohe Anforderungen. Ein Voicebot in der Hotline-Triage hat keine Buttons, keine Listen und keine zweite Chance, wenn Anrufende den Faden verlieren.
Im Chat- und E-Mail-Kanal sind die Spielregeln anders, aber die Grundlogik bleibt. Auf der Website kann mit Quick Replies, Karussells und Buttons gearbeitet werden, was den Designprozess flexibler macht. Für E-Mail-Automation wiederum zählt eine präzise Intent-Erkennung, weil Anliegen oft in mehreren Absätzen formuliert sind.
Conversational Design muss diese kanalspezifischen Eigenheiten berücksichtigen und gleichzeitig eine konsistente Markenstimme über alle Touchpoints hinweg wahren.
Conversational Design in Multi-Agent-Setups
In modernen Setups mit mehreren spezialisierten AI Agents wird Conversational Design zur Architekturaufgabe. Jeder Agent erhält einen klar abgegrenzten Aufgabenbereich, etwa Terminbuchung, Vertragsfragen oder technische Störungen. Hybride Intelligenz und Multi-Agent-Orchestrierung sorgen dafür, dass Anliegen sauber zwischen den Agents wandern, ohne dass Anrufende oder Schreibende den Kontext erneut erklären müssen. Auch die Anbindung an Knowledge AI und nachgelagerte AI Workflows wird im Conversational Design vorbereitet. Inklusive der Frage, wann an einen Mitarbeitenden eskaliert wird und wie diese Übergabe sprachlich aussieht.
Conversational Testing schließt den Kreis: Vor dem Go-Live werden alle Pfade systematisch durchgespielt. Mit echten Trainingsphrasen, Sprachsamples und Edge Cases. Erkannte Schwächen fließen zurück in Map, Personas und Tonalitätsleitfaden. Conversational Design ist damit ein laufender Prozess, der sich mit jedem produktiven Dialog weiterentwickelt.
Häufig gestellte Fragen (FAQ)
Conversational Design ist der konzeptionelle Prozess, der vor der technischen Entwicklung eines AI Agents stattfindet. Er definiert Use Cases, Zielgruppen, Persönlichkeit und Dialogflüsse und bildet die Grundlage für jede Conversational-AI-Lösung über Voice, Chat und E-Mail.
Ohne durchdachtes Conversational Design bleibt selbst die beste Sprachtechnologie unter ihren Möglichkeiten. Schlecht gestaltete Dialoge führen zu Fallbacks, Frustration und Abbrüchen. Sauberes Design dagegen sorgt für hohe Abschlussquoten, Entlastung im Service und ein konsistentes Markenerlebnis über alle Kanäle.
Personas modellieren typische Nutzergruppen mit ihren Bedürfnissen, ihrem Sprachstil und ihren Erwartungen. Sie helfen dabei, Tonalität, Wortwahl und Dialogtiefe so zu wählen, dass sich Anrufende und Schreibende verstanden fühlen. Personas sind damit eine zentrale Brücke zwischen Fachbereich und technischer Umsetzung.
Voice-Dialoge brauchen kurze Sätze, klare Rückfragen und eine robuste Fehlertoleranz, weil keine Buttons oder Listen zur Verfügung stehen. Chat-Dialoge können mit Quick Replies und visuellen Elementen arbeiten und erlauben längere Antworten. Die Markenstimme bleibt über alle Kanäle hinweg konsistent, während Format und Interaktionsmuster kanalspezifisch angepasst werden.
Conversational Design startet vor jeder technischen Implementierung. Idealerweise direkt nach der Zieldefinition des Projekts. Wer erst nach der technischen Konfiguration mit Design beginnt, baut Korrekturschleifen ein, die teuer und zeitaufwendig sind. Frühes Design spart spätere Eskalationen.
> Zurück zum BOTwiki
Geführte Kommunikation / Guided Communication
--> zum BOTwiki
Guided Communication, auch geführte Kommunikation genannt, bezeichnet einen Dialogstil bei Chatbots, bei dem Nutzende nicht frei formulieren, sondern über vordefinierte Buttons, Karussells, Quick Replies oder Auswahllisten durch ein Gespräch geleitet werden. Statt offener Spracheingabe präsentiert der AI Agent jeweils klar umrissene Optionen, aus denen die Nutzerin oder der Nutzer auswählt.
Damit grenzt sich Guided Communication bewusst von rein NLU-basierten Free-Text-Dialogen ab. Sie kommt häufig dort zum Einsatz, wo Anwendungsfälle stark strukturiert sind, schnelle Time-to-Market gefragt ist oder eine sichere Nutzerführung im Vordergrund steht.
Wie Guided Communication aufgebaut ist
Technisch basiert Guided Communication auf einem regelbasierten Dialogbaum. Jede Antwort des Bots enthält neben dem Text eine Liste möglicher Folgeaktionen, etwa als Buttons unter einer Chat-Nachricht. Der Dialogpfad ist dadurch deterministisch: Eine Auswahl führt zu einem klar definierten nächsten Schritt.
Ein vereinfachtes Beispiel aus einem Service-Chat: Auf die Begrüßung folgt die Auswahl „Bestellung verfolgen“, „Termin ändern“ oder „Mitarbeitenden sprechen“. Die Nutzerin tippt im Chat auf eine Schaltfläche und der Agent führt durch die folgenden Schritte. Diese Struktur reduziert Erkennungsfehler, weil das System keine offenen Formulierungen interpretieren muss.
Vorteile und Grenzen
Guided Communication beschleunigt Projekte deutlich, weil aufwendige NLU-Trainingsphasen entfallen oder zumindest reduziert werden können. Gleichzeitig erhöht sie die Verlässlichkeit, weil Nutzende nur gültige Pfade auswählen können.
- Schnellere Umsetzung, da kein umfangreiches Training für Trainingsphrasen nötig ist.
- Geringere Fehlerquote, weil keine missverstandenen Free-Text-Eingaben auftreten.
- Klare Erwartungssteuerung, da Nutzende nur sehen, was tatsächlich angeboten wird.
- Eingeschränkte Flexibilität bei komplexen oder offenen Anliegen.
- Risiko langer Menübaumstrukturen.
In der Praxis zeigt sich aber, dass reine Button-Dialoge bei wachsendem Funktionsumfang nicht zielführend sind und den Nutzer zu sebr einschränken. Wer dauerhaft skalieren will, kombiniert Guided Communication mit KI basierter Freitextverarbeitung, sodass der AI Agent auf möglich alle Themen optimal reagieren kann.
Bedeutung für Voice und Chat
Im Voice-Kanal wirkt Guided Communication anders als im Chat. Eine klassische IVR ist im Grunde reine Auswahlführung. Sie folgt der Logik „Body ohne Brain“ und lässt keine echte Konversation zu. Ein Voicebot auf Basis von AI-Native Voice kann hingegen eine geleitete Auswahl mit natürlichem Sprachverstehen kombinieren und so die Vorteile beider Ansätze vereinen.
Im Chat sind Buttons, Karussells und Quick Replies tragende Elemente einer geleiteten Führung. Sie eignen sich besonders, um Nutzende durch Formularstrecken, Self-Service-Prozesse oder mehrstufige Auswahlfragen zu führen.
Häufig gestellte Fragen (FAQ)
Guided Communication ist ein Dialogstil, bei dem Nutzende über vordefinierte Buttons, Karussells oder Auswahlmenüs durch ein Gespräch geführt werden. Statt frei zu formulieren, wählen sie aus klar umrissenen Optionen aus. Damit ist der Dialogpfad weitgehend deterministisch.
Sinnvoll ist sie immer dann, wenn Anwendungsfälle stark strukturiert sind und Präzision wichtiger ist als Konversationsbreite. Typische Beispiele sind Self-Service-Prozesse, Authentifizierungsschritte oder kurze Auswahldialoge in einer Hotline-Triage. Auch bei knappen Projektzeiträumen ist sie eine gute Option, weil sie ohne umfangreiches NLU-Training auskommt.
Reine Button-Dialoge skalieren schlecht, sobald Anwendungsfälle vielfältiger werden. Lange Menübäume frustrieren Nutzende. Komplexe Anliegen, die außerhalb der vorgesehenen Pfade liegen, lassen sich nicht abbilden, ohne in einen Fallback zu laufen.
> Zurück zum BOTwiki
Trainings Phrasen / Utterances
--> zum BOTwiki
Utterances sind Trainingsphrasen, mit denen ein AI Agent erkennt, was Nutzende meinen, indem er die im System hinterlegten Beispiele mit der Live-Anfrage vergleicht. Dieses Konzept stammt aus der klassischen, intentbasierten Dialogarchitektur und war über viele Jahre ein zentrales Element bei der Entwicklung von Chatbots und virtuellen Assistenten.
In modernen agentischen Systemen, die auf Large Language Models basieren, verliert das manuelle Pflegen von Utterances zunehmend an Bedeutung. Diese Systeme verstehen Freitext kontextbasiert und können mit sprachlicher Variation umgehen, ohne vorab auf konkrete Beispielformulierungen trainiert worden zu sein. Wer jedoch mit intentbasierten NLU-Modellen arbeitet oder bestehende Systeme dieser Art betreut, findet im Folgenden die wesentlichen Grundlagen.
Jede Utterance ist eine konkrete Beispielformulierung, die einem bestimmten Intent zugeordnet wird. Aus vielen solcher Beispiele lernt das NLU-Modell, sprachliche Variationen einer Anfrage zu erkennen. Je breiter und realistischer die Utterances, desto stabiler die Klassifikation in der Produktion.
Was eine Utterance ist und wie sie wirkt
Eine Utterance ist eine kurze, in natürlicher Sprache formulierte Beispieleingabe. Für den Intent „Termin_buchen“ sind das etwa: „Ich bräuchte einen Termin“, „Können Sie mir einen Termin geben?“ oder „Ich möchte nächste Woche kommen“.
Aus diesen Beispielen leitet das NLU-Modell sprachliche Muster ab. Es erkennt anschließend auch Formulierungen, die nicht wörtlich im Training enthalten waren. Utterances sind damit das Trainingsmaterial, das über die Erkennungsqualität entscheidet.
Anforderungen an gute Utterances
Pro Intent sollten mehrere Utterances hinterlegt sein, die unterschiedliche Formulierungen abdecken. Wichtig sind dabei:
- Sprachliche Varianten: kurze und lange Formulierungen, mit und ohne Höflichkeitsfloskeln.
- Synonyme: „Termin“, „Verabredung“, „Sprechstunde“.
- Realistische Eingaben aus Sicht der Zielgruppe, keine künstlich konstruierten Sätze.
- Abdeckung typischer Tippfehler, Umgangssprache und Dialekte, sofern in der Praxis vorkommen.
Ebenso wichtig ist die Abgrenzung. Utterances unterschiedlicher Intents dürfen sich semantisch nicht zu stark überschneiden. Sonst sinkt der Confidence Score, weil das Modell nicht mehr eindeutig entscheiden kann.
Häufig gestellte Fragen (FAQ)
Utterances sind Trainingsphrasen, mit denen ein AI Agent lernt, einen Intent zu erkennen. Jede Utterance ist eine konkrete Beispieleingabe, etwa „Ich bräuchte einen Termin“ für den Intent „Termin_buchen“. Aus vielen solcher Beispiele leitet das NLU-Modell sprachliche Muster ab und erkennt damit auch Varianten, die nicht wörtlich trainiert wurden.
Pro Intent sind in der Regel zehn bis dreissig Utterances ein guter Startwert. Entscheidend ist nicht die reine Menge, sondern die sprachliche Vielfalt. Kurze und lange Formulierungen, Synonyme und realistische Tippfehler erhöhen die Erkennungsstabilität stärker als zusätzliche ähnliche Sätze.
Der Confidence Score zeigt, wie sicher das Modell einen Intent zugeordnet hat. Gut formulierte Utterances erhöhen den Score, weil das Modell klare Muster lernt. Überlappen sich Utterances verschiedener Intents, sinkt der Score und das System weicht häufiger auf einen Fallback aus.
> Zurück zum BOTwiki