Das vorliegende Verfahren betrifft eine Implementierung auf einem Computer, der auch ein Mobiltelefon, Smartphone oder ein sonstiges tragbares Gerät mit einer digitalen

Recheneinheit sein kann, die es dem Nutzer ermöglicht, ein natürliches, alltags-taugliches Gespräch mit einem Computersystem zu führen. Über Text oder Spracheingabe werden verschiedene Schritte zur Klassifizierung und nachfolgendem Sprachverständnis ausgeführt, worauf kontext-basiert im Anwendungsfall ein Gespräch zwischen Nutzer und dem

Computersystem ermöglicht wird. Der besondere Schwerpunkt wird dabei auf die Erkennung der Nutzerabsicht sowie deren weitere Verarbeitung gelegt. Hierzu erkennt das Verfahren jeweils den Sinn der Sprache.

Computersysteme, die mit gesprochener oder geschriebener natürlicher Sprache umgehen, sind seit langem Stand der Technik. So gibt es Diktiersysteme, die gesprochene Wörter sowie Satzzeichen erkennen und in geschriebenen Text umsetzen können. Auf der anderen Seite gibt es eine Vielzahl von Vorlesesystemen, die einen vorgegebenen Text ansagen können. Diese Systeme sind nicht in der Lage, den Sinn der Sprache zu verstehen.

Auch Navigationsgeräte in Fahrzeugen sind üblicherweise in der Lage, dem Fahrer, der ein Ziel eingegeben hat, Anweisungen in gesprochener Sprache zum Fahren zu erteilen. Sie erfahren aber nicht, ob der Nutzer die Anweisungen verstanden hat. Auch diese Systeme können den Nutzer nicht verstehen, sondern sind auf seine Zieleingabe angewiesen. Sie lassen dabei von vornherein nur Ziele zu, die in der systemimmanenten Datenbank gespeichert sind.

Seit einiger Zeit sind auch aufwendige Computersysteme erhältlich, die gesprochene Fragen analysieren und Antworten darauf in gesprochener Sprache geben können. Hierbei handelt es sich um einfache Abfragen, deren fertige Antworten in Datenbanken gespeichert sind, und bei denen das Computersystem lediglich vor der Aufgabe steht, die richtige dieser Antworten herauszusuchen und diese zu sprechen. Das Computersystem muss dazu den Sinn der Frage nicht wirklich verstehen, es reicht, wenn es bestimmte Schlüsselwörter erkennt, anhand derer die Menge der möglichen Antworten soweit eingegrenzt werden kann, dass die Antwort mit der größten zahlenmäßigen Übereinstimmung der Schlüsselwörter als Antwort ausgegeben werden kann.

So beschreibt bereits die US 6,964,023 B2 ein System für multimodale Nutzerkonversation, das in der Lage ist, gesprochene Sprache in Text umzusetzen, Mehrdeutigkeiten aufzulösen und die Stimmung des Nutzers zu erkennen, etwa mittels Gesichtserkennung. Das System veranlasst ggf. Rückfragen an den Nutzer, um dessen Anweisungen zu klären. Hierbei fragt das System so oft nach, bis es die Absicht des Nutzers erkannt hat. Danach führt das System entsprechende Anweisungen aus, beispielsweise schaltet es das Radio ein. Der Erkennungsvorgang findet auf der Basis der Gesichts- und Spracherkennung statt. Eine Fehlerwahrscheinlichkeit wird für jeden Zweig des Entscheidungsbaums ermittelt, sowohl mittels eines Vergleichs mit einem Schwellenwert als auch über lineare Regression. Die Entscheidungsbäume werden dafür auf wortabhängige Eigenschaften trainiert.

Die WO 02/073331 A2 stellt eine Systemarchitektur für kommerzielle Transaktionen in natürlicher Sprache bereit, bei der Nutzer sich über Produkte eines Katalogs informieren können. Hierbei greift das System auf eine Datenbank für Produkte und eine Datenbank der Nutzervorlieben zu und stellt Rückfragen zur Klärung. Die Datenbank der Nutzervorlieben besitzt eine Update-Funktion, eine selbstlernende Funktion fehlt jedoch.

Die US 8,600,747 B2 beschreibt ein Verfahren zur Verwaltung eines Dialogs, der auch gesprochene Sprache, etwa im Rahmen eines Telefonats, umfassen kann. Hierzu wird eine Vielzahl von Dialogmotivatoren eingesetzt, die eine Fehlerbehandlung, eine

Mehrdeutigkeitsbehandlung, Annahme und Bestätigung, fehlende Information und

Fortsetzung durchführen. Hiermit sind Bestell- und Bezahlvorgänge möglich, das System kann Rückfragen an den Nutzer stellen. Es ist jedoch nicht selbstlernend und dient vorwiegend dazu, Nutzer an menschliche Dialogpartner weiterzuvermitteln.

Die DE 60 2004 006 641 T2 beschreibt ein Audio-Dialogsystem, das über eine

Spracherkennung und eine Audioschnittstelle sowie über einen Browser mit Zugang auf Inhalte verfügt und Aktivierungsphrasen ermittelt. Mittels einer Anwendung latenter semantischer Analyse wird die Ähnlichkeit zwischen den Nutzeräußerungen und den

Aktivierungsphrasen als numerischer Wert ermittelt. Bei den Kopplungen der

Aktivierungsphrasen und der Inhalte wird ein Sprachmodell trainiert. Eine Absichtserkennung findet nicht statt.

Die US 8,543,407 B1 beschreibt ein System, welches statistische Modellierung und formale Logik dazu benutzt, Gesprächseingaben hinsichtlich Dateninhalten wie Kommandos und Diktaten auszuwerten. Hierzu werden ein Kommandowörterbuch und eine dynamische Grammatik zur Identifikation, der Klärung von Mehrdeutigkeit und der Extraktion von

Befehlen verwendet, das System arbeitet kontextsensitiv und kann weitere

Nutzerschnittstellen ansprechen. Es kann aber keine Nutzerabsichten erkennen und hierüber auch keinen Dialog mit dem Nutzer führen.

Die WO 2014/047270 A1 beschreibt ein Verfahren und eine Vorrichtung, um die Absicht in einem IVR - Interactive voice response - bei der Verwendung natürlicher Sprache

vorherzusagen und löst das Problem, dass die vom Nutzer verwendeten allgemeinen Begriffe während der Konkretisierung einem Wandel unterworfen sind, die es einem System erschweren, deren Konsistenz sicherzustellen. Die Nutzerabsicht wird dabei mit früheren Absichten und mit dem üblichen normalen Verhalten durchschnittlicher Nutzer abgeglichen und in seiner relativen Wertigkeit geschätzt. In Abhängigkeit dieser Wertigkeit werden dem Nutzer voreingestellten Schwellenwerten entsprechende werthaltige Angebote unterbreitet. Die Absichtserkennung wird dadurch zu einer Absichtsgenerierung.

Die US 8,849,652 B2 beschreibt ein System, welches sprachbasierte und nicht- sprachbasierte Interfaces umfasst und Nutzer-Kontext, frühere Informationen und

Nutzerdaten dazu nutzt, eine natürliche Nutzerumgebung für Nutzer, die Anfragen stellen oder Befehle erteilen wollen, herzustellen. Es kann jedoch die Absichten der Nutzer nicht erkennen und sich darauf nicht einstellen.

Die US 9,502,027 B1 beschreibt ein Verfahren, um die Ausgabe einer Spracherkennung zu verarbeiten. Hierbei wird nach der Umsetzung der gesprochenen Sprache in Text, dem Parsing, zunächst untersucht, ob es sich um einen Befehl handelt. Wenn dies der Fall ist, wird dieser Befehl ausgeführt, und wenn nicht, mittels einer Rückfrage um Klärung der Uneindeutigkeit gebeten. Das Verfahren kann jedoch weder Absichten erkennen noch einen natürlichen Dialog führen.

Während die hierdurch aufgeworfenen technischen Probleme inzwischen weitgehend als gelöst betrachtet werden können, bereiten das tiefe Verstehen und das Kommunizieren immer noch erhebliche Probleme, das betrifft besonders solche Computersysteme, die in Echtzeit Sprachsignale sehr schnell verarbeiten und dabei gleichzeitig mit begrenzten Ressourcen auskommen müssen.

Die Anforderungen resultieren vor allem darin, die Nutzereingaben zu„verstehen" und zu „interpretieren". Ziel ist es hierbei stets, den Turing-Test zu bestehen. Der Test ist dann bestanden, wenn der Nutzer aus den Antworten nicht mehr unterscheiden bzw. erkennen kann, ob er mit einem Menschen oder einer Maschine kommuniziert hat. Außer der reinen Spracherkennung sind hierbei auch die Gesetzmäßigkeiten der menschlichen

Kommunikation zu berücksichtigen, vor allem die, die in der Transaktionsanalyse der Psychologie behandelt werden, also muss das Computersystem

• "anderen Menschen" respektvoll gegenübertreten,

• Erwartungen klären, vor allem dabei die Fragen, worum es geht und was man

voneinander will,

• Informationen zum Thema einholen, darf dabei nicht werten, soll öffnende Fragen stellen, statt Alternativen vorzugeben, sie soll die Informationsflut stoppen, und sie soll strukturieren und auswählen lassen,

• wichtige Gesprächsinhalte paraphrasieren oder paraphrasieren lassen, Interpretationen als solche deutlich machen, diese dabei sparsam anwenden,

kennzeichnen, ggf. anbieten,

authentisch und selektiv kommunizieren entsprechend dem Grundsatz "Nicht alles, was wahr ist, muss ich sagen; aber alles was ich sage, muss wahr sein",

die 50%- Regel beachten, was bedeutet, dass mindestens die Hälfte der Energie zur Problemlösung beim Gesprächspartner liegen muss,

Bilanz ziehen und summieren, was geklärt wurde und was offengeblieben ist, welche Fragen neu entstanden sind und welche nächsten Schritte anstehen,

Feedback geben können.

Die Aufgabe der Erfindung ist daher, das Computersystem in die Lage zu versetzen, die menschliche Kommunikation besser nachzubilden und nicht nur die Sprache oder sogar nur deren Wörter und Grammatik zu erfassen und auszuwerten, und damit mit einem

menschlichen Nutzer einen Dialog zu führen.

Darüber hinaus sollte die Software einige Grundregeln des strategischen Vorgehens kennen, damit sie nicht leicht getäuscht oder ausgetrickst werden kann.

Die Erfindung löst diese Aufgabe durch ein Verfahren zur Dialogführung zwischen Mensch und Computer unter Verwendung eines selbstlernenden Systems, aufweisend

• das Empfangen von Nutzereingaben in natürlichem Sprachtext,

• Zuordnung von Synonymen und Schlüsselworten sowie Wortzuordnungen,

• das Analysieren der Nutzereingaben auf Satzstruktur und Satzbau und deren Erkennung,

• Zuordnung von Schlüsselphrasen,

• das Ermitteln und Klassifizieren der Nutzerabsicht,

• Prüfung, ob eine Bestätigung erforderlich ist,

• logisches Verarbeiten in einer Reasoning-and-Answer-Preparation unter Formulierung einer Entscheidung über die weitere Dialogausgestaltung, Formulierung oder den Dialogverlauf mit möglicher Generierung einer Antwort,

• wobei

• zur Erkennung der Nutzerabsicht die statistische Relevanz der Zugehörigkeit zu einer Ziel-Absicht bei gleichzeitiger Beibehaltung sämtlicher Meta-Informationen ermittelt wird,

• die Klassifizierung mit einem Klassifizierungsalgorithmus zur Absichtsklärung erfolgt, in dem Entscheidungsbaum, Logik und Sprachverständnis über Metainformation verknüpft werden,

• eine Rückmeldung unter Verwendung früherer Nutzerbefragungen an das selbstlernende System generiert wird, • bei Grenzwertunterschreitung statistischer Relevanz eine Abfrage an den Nutzer generiert wird, ob die erkannte Absicht korrekt verstanden wurde,

• in diesem Fall eine Antwort des Nutzers empfangen und dann auf Satzstruktur und

Satzbau analysiert wird und wiederholt die Nutzereingaben in Sachinhalte und in Metainformationen über den Nutzer aufgespalten werden sowie erneut die Nutzerabsicht ermittelt und klassifiziert wird,

• das Erkennungsergebnis an das selbstlernende System abgegeben wird,

• das selbstlernende System automatische System-Empfehlungen und/oder

Entscheidungen zur Verbesserung der Absichtserkennung über mehrere

Nutzerinteraktionen erarbeitet und zur späteren Verwendung bereithält,

• bei Grenzwertüberschreitung statistischer Relevanz die Generierung der Sprachtext- Antwort an den Nutzer einleitet, und anderenfalls eine weitere Nachfrage veranlasst.

Die einzelnen Verfahrensschritte werden im Folgenden in Bezug auf den bekannten Stand der Technik eingehender erläutert.

Zunächst wird der Nutzer nach Möglichkeit identifiziert. Dies kann etwa durch eine eindeutige Nutzer-ID geschehen. Hat sich der Nutzer bereits zuvor mit dem System verbunden, wird er wiedererkannt und das Gespräch wird wiederaufgenommen. Meldet er sich nach einer Abiaufzeit wieder an, generiert das System anhand der gespeicherten Kontextinformationen eine neue Instanz und lässt den Nutzer einen neuen Dialog beginnen. Der Nutzer kann sich über ein beliebiges Interface wie Chat oder Sprache verbinden und bei entsprechender Identifikation und Authentifizierung kann dann der entsprechende Nutzerkontext geladen werden.

Eine solche Anmeldung kann ähnlich einer Weiterleitung von Mobilfunksignalen zwischen einzelnen Funkzellen Kanal- und Interface-übergreifend erfolgen, die Dialogübernahme zwischen den einzelnen Kanälen wird so ermöglicht. Das System behält dabei den Kontext, den gespeicherten Dialogstatus und den Dialogverlauf bei.

Das Empfangen und das anschließende Analysieren der Nutzereingaben auf Satzstruktur und Satzbau und deren Erkennung erfolgt durch einen Parser für natürliche Sprache, der grammatikalische Information eines Satzes ausgibt, so etwa identifizierte Subjekte, weiterhin Information über jedes Wort und einen Strukturbaum, auch als "Dependency Tree" bezeichnet, der die Relation zwischen den einzelnen Wörtern zeigt.

Dieser Strukturbaum wird anschließend im Verarbeitungsschritt "Dependency Tree Parsing" weiter analysiert, wobei nach Möglichkeit Subjekt-Prädikat-Objekt-Strukturen erzeugt werden. Die Verarbeitung der Dependency trees und daraus extrahierte strukturelle Informationen werden mit weiteren existierenden Meta-Informationen kombiniert, um anhand dieser Informationen die Werthaltigkeit einer Nutzereingabe zu ermitteln. Dieses sogenannte Input- Objekt, welches zusätzliche weitere Informationen enthält, ermöglicht es, entsprechende Meta-Informationen aus der Eingabe zu entziehen und diese im gesprächsabhängigen Kontext zwischenzuspeichern.

Es findet daher eine Transformation zwischen der Nutzereingabe und dem vorhandenen Nutzerkontext anhand vorliegender struktureller Kriterien, z.B. den Sprachmodellen als Grundlage des "Dependency tree parsing" statt.

Danach wird die Nutzerabsicht mehrstufig ermittelt und klassifiziert. Unter der Nutzerabsicht, auch als "Intent" bezeichnet, soll im Folgenden ein weitergehender Begriff als nur der einer bloßen Anfrage verstanden werden, wobei die Anfrage, als "Query" bezeichnet, eine Teilmenge der Nutzerabsicht darstellt. Aus Sicht der Kommunikation betrifft die

Nutzerabsicht aber nicht nur das Ziel, einen Sachverhalt darzustellen, sondern sie beinhaltet auch die Zielvorstellung des Nutzers selbst, der entweder etwas Kaufen möchte oder eine Freigabe oder eine Genehmigung oder eine Auskunft erteilt bekommen möchte, oder auch eine Beschwerde abgeben oder eine Anzeige erstatten will. Damit werden die vier

Sprachebenen "Sachebene", "Appellebene", Beziehungsebene" und

"Selbstoffenbarungsebene" relevant.

Für all diese Ebenen muss das Computersystem in der Lage sein eine entsprechende Gesprächsebene zu bilden oder sich diese selbstlernend zu erarbeiten und diese über strukturelle Kriterien zielgerichtet ausführen können. Diese Wissensbasis wird durch eine Datenbank der Ziel- Absichten, der relevanten Kontext-Informationen und aus externen Datenquellen bereitgestellt.

Hierbei wird zur Erkennung der Nutzerabsicht die statistische Relevanz der Zugehörigkeit zu einer Ziel-Absicht bei gleichzeitiger Beibehaltung sämtlicher Meta-Informationen ermittelt. Nachfolgend erfolgt die Klassifizierung mit einem Klassifizierungsalgorithmus zur Absichtsund Bedeutungsklärung. In diesem Schritt werden die Meta-Informationen und die

Abarbeitungslogik, auch als Flow bezeichnet, zu einer Grundlage für eine

anwenderspezifische strukturierte Gesprächsführung zusammengeführt.

Die zuvor als Meta-Informationen zur Eingabe gehörigen Informationen wurden in

Strukturen, wie etwa dem Datenaustauschformat JSON, gespeichert und werden im nachfolgenden Schritt zur Intent-Erkennung und Erkennung der Bedeutung herangezogen. Wie der Kontext dabei strukturiert ist, hängt vom Anwendungsfall ab. Hierdurch erfolgt eine weitere Eingrenzung der zuvor ermittelten Meta-Informationen auf einen konkreten Anwendungsfall, der eine sinnvolle Gesprächsführung nach den Regeln ordentlicher

Gesprächsführung erst möglich macht.

Sollte hierbei die statistische Relevanz eines ausgewählten Referenz-Intents einen definierten Schwellenwert unterschreiten, ist das System in der Lage, Rückfragen an den Nutzer zu formulieren, um die Validität der Erkennung zu bestätigen oder zu widerlegen. Durch diese Art der Rückfragen und der Speicherung der Nutzer-Rückmeldungen entsteht ein Kreislauf, in dem das System eigenständig in der Lage ist, sein Verhalten zu verbessern, also eigenständig zu lernen. Dies in der Form, dass ab einer gewissen Anzahl betätigter Rückfragen keine weiteren Rückfragen an jegliche Nutzer mehr gestellt werden müssen. Das System hat dann gelernt, eine zuvor unbekannte, nicht zum Referenz-Intent passende Nutzeranfrage zu interpretieren und zuzuordnen.

Es wird dabei nicht nur eine reine Erkennung durchgeführt, sondern abhängig vom

Gesprächszustand erfolgt eine gezielte Freischaltung oder Deaktivierung sinnvoller, zum Gespräch passender Intents. Hierzu wird eine vom Gesprächsstatus abhängige Intent- Erkennung mit gesprächszustandsabhängiger Eingrenzung erlaubter oder geduldeter oder sinnvoller Intents durchgeführt. Hierdurch wird eine gravierende Verbesserung der statusabhängigen Intent-Erkennung erzielt. Gepaart mit dem oben beschriebenen

Rückfrage-algorithmus entsteht ein Verfahren, bei dem initial nur wenige strukturelle

Informationen vorgegeben werden müssen und das System eigenständig lernt, einen möglichst natürlichen Dialog mit dem Nutzer zu führen.

Die Absichtserkennung erfolgt durch statistischen Vergleich. Zunächst wird die

Nutzeraussage in einem Parsing-System auf Tripel heruntergebrochen, die die Struktur Subjekt-Prädikat-Objekt aufweisen. Die Anordnung der Tripel wird in einem Dependency Tree dargestellt. Alle infrage kommenden Tripel, die zur Verarbeitung geeignet sind, sind im System gespeichert, wobei jedem der Tripel ein statistischer Wahrscheinlichkeitswert zugeordnet ist. Im Rahmen des lernenden Systems wird dieser Wahrscheinlichkeitswert stets angepasst, wenn mehrere Nutzer hintereinander dasselbe Tripel verursachen, wird die Wahrscheinlichkeit heraufgesetzt. Das Tripel mit der höchsten Wahrscheinlichkeit wird als Absicht/ Intent ausgewählt.

Nach erfolgter Intent-Erkennung sieht der Verarbeitungsschritt "Intent-Clarification" vor, abhängig von der Relevanz erkannter und identifizierter Absichten eine Rückfrage an den Nutzer zu formulieren, so dass etwaige Unklarheiten der Nutzereingabe durch Nachfrage und erneuter Erfassung der zuvor beschriebenen Verarbeitungsschritte dazu genutzt werden, eine klarere Aussage zu Absicht und Bedeutung der Nutzereingabe zu erlangen. Bei Unklarheiten der Nutzereingabe in Bezug auf die Referenz-Intents klärt die "Intent- Clarification", ob das System den richtigen Intent erkannt hat oder nicht. Bei der Generierung der Rückfrage werden die folgenden Verfahren ssc ritte durchlaufen:

Jedem Referenz-Intent sind eine oder mehrere explizite Rückfragen zugeordnet. Über ein Script werden Inhalte aus den Meta-Informationen und dem Kontext in eine dynamisch generierte Rückfrage einbezogen. Damit wird die Rückfrage auf die Nutzereingabe angepasst und eine wesentlich natürlichere Rückfrage oder sonstige Rückmeldung an den Nutzer generiert.

Nach der Rückfrage an den Nutzer wartet das Computersystem auf eine Antwort. Falls keine Antwort gegeben wird, fragt das System erneut nach oder bricht die Anfrage des Nutzers ab, falls eine Antwort kommt, prüft das Computersystem, ob diese vom selben Nutzer gegeben wird, authentifiziert sie, und die Analysen und Verarbeitungsschritte laufen erneut ab. Zuvor wird sichergestellt, dass das System in einem validen Zustand auf weitere Nutzereingaben wartet oder selbst aktiv durch Fragestellung den Nutzer zur Konversation auffordert.

Nach erfolgreicher Intent-Erkennung wird der nächste Verarbeitungsschritt der„Reasoning and Answer preparation" erforderlich. In diesem Verarbeitungsschritt wird anhand einer logischen Entscheidungsmatrix, einem Flow, einem Entscheidungsbaum, einem neuronalen Netzwerk oder sonstiger Realisierung eine kontextbezogene, dem Anwendungsfall passende strukturierte Dialogführung ermöglicht.

Entscheidender Teil der "Reasoning Engine" ist die grafische Repräsentation einer Struktur zur Dialogführung. Über logische Verarbeitungselemente wie Bedingungen, etwa "if", "eise", "then", "switch case" und Elemente zur Nutzerinteraktion wie "say", "say-once",

"asYNQuestion" etc. wird ein logischer Rahmen für einen Anwendungsfall-spezifischen Dialog erstellt. Die "Reasoning Engine" verwaltet dabei den aktuellen Gesprächsstatus einer Diskussion mit dem Nutzer, sowie vorheriger Diskussionen, um entsprechend der

Nutzerinteraktion als Gesprächspartner agieren zu können. Aus vorherigen Informationen ermittelter Gesprächskontext kann dabei als Gesprächsgrundlage hinzugezogen werden.

Diese Reasoning Engine ermöglicht es, die Meta-Informationen aus vorherigen

Verarbeitungsschritten mit Entscheidungskriterien zur sinnvollen, kontextbezogenen

Gesprächsführung zu nutzen. Zuvor durchlaufene Verarbeitungsschritte stellen dabei die notwendigen Meta-Informationen einer oder mehrerer Nutzereingaben zur Verarbeitung in der Reasoning Engine bereit.

Die Intent-Erkennung erfolgt vor der Verarbeitung im Flow. Einerseits kann direkt aus der Intent-Erkennung eine Rückfrage an den Nutzer erstellt werden. Andererseits können auch direkt aus dem Flow heraus Rückfragen an den Nutzer formuliert werden. Der Unterschied ist, dass der Intent meist nicht bereits alle möglichen Spezifikationen enthält, die danach erst vom Flow abgefragt werden. Diese Trennung zwischen Intent und Flow folgt aus der Wissensposition den Nutzers, der aus Unwissen über das mögliche Ausgestaltungsspektrum seine konkrete Absicht oft noch nicht ausreichend spezifizieren kann, oder auch weil seine Willensbildung noch nicht abgeschlossen ist und er sich Alternativen vorbehält.

Zur Nutzerinteraktion werden aus vorherigen Verfahrensschritten oder direkt aus der Reasoning Engine Antworten oder Rückmeldungen an den Nutzer generiert, die passend zum Kontext eines Gesprächs die vollständige, bidirektionale Nutzerinteraktion ermöglichen. Hierbei können zur Verbesserung der Gesprächsqualität sogenannte„Natural Language Generation" [NLG] Tools und Frameworks zum Einsatz kommen.

Das System ermöglicht hierbei bereits die teilweise dynamische Generierung von Antworten auf dem Kontext oder aus gespeicherten Meta-Informationen. Die Rückfragen werden somit aus dem Kontext erstellt und an den Nutzer ausgegeben. An dieser Stelle erzeugt der Flow die vier Sprachebenen "Sachebene", "Appellebene", Beziehungsebene" und

"Selbstoffenbarungsebene", damit die Dialogführung den kommunikativen Ansprüchen genügt.

In weiteren Ausgestaltungen der Erfindung ist vorgesehen, dass dem Empfangen von Nutzereingaben ein Umwandeln von gesprochener natürlicher Sprache in Text vorangeht. Eine solche Umwandlung ist an sich bekannter Stand der Technik. Darüber hinaus wird dieser vorangestellte Verfahrensschritt aber dazu verwendet, um weitere Meta-Informationen über den Dialogpartner zu gewinnen. So kann vorgesehen werden, dass beim Umwandeln von gesprochener Sprache in Text Meta-Informationen des Nutzers aufgenommen und separat dem Algorithmus der Absichtserkennung zur Verfügung gestellt werden. Als MetaInformationen können die Parameter Eile, Emotion, Sprache, Dialekt und Person oder Kombinationen oder Teile davon erfasst werden. Hierzu gehört auch das Aufspalten der Nutzereingaben in Meta-Informationen für Sachinhalte und in Meta-Informationen über den Nutzer. Aus marktbekannten Anwendungen zur Sprachumwandlung sind bereits Variationen bekannt, die derartige Meta-Informationen zusätzlich zum ermittelten Text bereitstellen.

Weiterhin können diese aus der natürlichen Sprechweise des Nutzers gewonnenen MetaInformationen als Rohdaten für die Absichtserkennung sowie für die nachfolgende logische Verarbeitung dienen und an diese die Parameter Tonation, Dringlichkeit und Beruhigung abgegeben werden. So kann manchmal schon aus der Tonation darauf geschlossen werden, ob eine Beschwerde oder ein Kaufwunsch vorliegt. Beim Vorliegen von Dringlichkeit kann es sinnvoll sein, die Grenzwerte für die statistische Relevanz herabzusetzen. Zudem

ermöglichen derartige Meta-Informationen den Gesprächsfluss angemessen ans

Nutzerverhalten zu adaptieren, etwa indem zwischen einem Kaufprozess, einem

Beratungsprozess oder einem Reklamationsprozess differenziert wird. Sofern dem Empfangen von Nutzereingaben ein Umwandeln von gesprochener natürlicher Sprache in Text vorangegangen ist, sieht eine weitere Ausgestaltung der Erfindung vor, dass der Generierung der Sprachtext-Antwort an den Nutzer ein Umwandeln von Text in gesprochene natürliche Sprache nachfolgt, um einen einheitlichen Dialog zu führen. In solchen Fällen ist es nötig, jeden Nutzer jederzeit eindeutig zu authentifizieren, damit sichergestellt ist, dass das System demselben Nutzer antwortet, der die Anfrage gestellt hat, der Dialog also mit derselben Person weiter stattfindet.

Das System ordnet daher in einer Ausgestaltung jedem Nutzer einen Identifikationsdatensatz zu, was den Zugriff auf Nutzer-abhängige Kontextinformationen ermöglicht. Auf diese Weise ist es auch möglich, einen Interface-unabhängigen Dialog zu führen, der Kontext und der aktuelle Gesprächs- und Dialogstatus bleiben dabei bestehen und sind stets konsistent. Wenn der Nutzer den Dialog beendet, indem er seine Verbindung mit dem System trennt, wird zunächst geprüft, ob ein technischer Fehler vorliegt und der Kontext wird

zwischengespeichert. Sofern der Dialog final beendet wurde, wird der aktuelle Dialogstatus vernichtet bzw. gelöscht.

Neben der Rückmeldung von gesprochenem Text können auch Daten als Steuerbefehle für eine Anwendung zurückgegeben werden. Eine Interaktion per Sprache kann dadurch mit realer Interaktion am Bildschirm, z.B. durch Anzeige von Grafik oder einem Gerät wie einem Roboter, einem "lnternet-of-Things"-Gerät, oder auch einem Smartphone oder einem

Computer oder einer virtuellen oder digitalen Umgebung kombiniert werden. Diese

Benutzerschnittstelle ist vorzugsweise so ausgestaltet, dass sie auch multiple

Eingangssignale bestehend aus Text oder Sprache und Eingabedaten wie Steuerbefehle und Meta-Informationen erzeugen kann,

Aus den Meta-Informationen können auch Steuerbefehle als Datensätze direkt verarbeitet und dadurch eine Beeinflussung des Gesprächsverlaufs aus dem Kontext heraus und unter Verwendung von Flow-Elementen, die abhängig von Kontext das Gespräch steuern, mit dem Nutzer vorgenommen werden. So kann etwa ein verbundener Roboter den Nutzer begrüßen, wenn er Bewegungen erkennt. Über eine mögliche Gesichtserkennung könnte ein solcher Roboter versuchen, einen Nutzer und seine Begleitung eindeutig zu identifizieren. Das System hätte daraufhin die Möglichkeit, anhand vorliegender Kontextinformationen, eine dynamisch generierte Begrüßung unter Verwendung des Namens und anderer Kontext- Informationen zu erstellen und über den Roboter in Form von Sprache an den Nutzer zu übermitteln.

Weitere Ausgestaltungen der Erfindung betreffen die Weise, wie das selbstlernende System in das Verfahren zur Dialogführung eingebettet ist bzw. eingreift. So kann vorgesehen werden, dass die Meta-Informationen im selbstlernenden System automatisch kombiniert, interpretiert, konsolidiert und gespeichert werden, wobei es dem Anwender obliegt, die datenschutzrechtlichen Belange zu berücksichtigen.

Selbstlernende Systeme werden gelegentlich dafür kritisiert, dass sie unerwünschte

Nutzereingaben unreflektiert automatisieren und inkorporieren. Dies führt zu Missbrauch und Schäden, etwa wenn Gruppen von Nutzern unsinnige Fragen stellen, um das System zu manipulieren, oder wenn das System Vorurteile und Diffamierungen lernt. Um dies zu verhindern, kann vorgesehen werden, dass auf bestimmte Schlüsselwörter das

selbstlernende System durch einen Administrator unterstützt wird, den es beim Auftreten von Schlüsselwörtern oder beim Auftreten von Überforderung von sich aus involviert. Im hier beschriebenen System ist durch den Flow und durch handhabbare Kontextinformationen sichergestellt, dass das System zwar in Teilen selbstlernend ist, sein eigentliches Verhalten aber nicht ändert, da es nach wie vor anhand vorgegebener Strukturen agiert. Der

Administrator kann lediglich kontrollierend eingreifen und entsprechende neue Elemente für erweiterte oder verbesserte Nutzerdialoge einbringen.

Weitere Ausgestaltungen der Erfindung betreffen die Sprachanalyse. Hierbei kann vorgesehen werden, dass das selbstlernende System durch eine Synonymerkennung unterstützt wird. Die Synonymerkennung geht einher mit der Erarbeitung weiterer Kontext- Informationen, so können Schlüsselworte identifiziert werden, und damit die Eingaben über temporäre Meta-Informationen entsprechend der erkannten Schlüsselworte erweitert werden.

Weiterhin kann vorgesehen werden, dass durch Analyse der Satzstruktur von

Nutzereingaben im Dependency Parsing eine Abhängigkeitsabbildung erarbeitet wird.

Weitere Ausgestaltungen der Erfindung betreffen die Einbindung und Abfrage externer Datenbanken. So kann vorgesehen werden, dass zur Ermittlung gesprächsrelevanter Daten, wie etwa Kontextinformationen oder Meta-Informationen, entsprechende, verbundene Datenbanken abgefragt werden. Dies können beispielsweise Produktdatenbanken von Herstellern oder Waren und deren Lagerort in einem Einkaufszentrum sein. Sofern diese Datenbanken fremdsprachig sind, kann auch ein Übersetzungsprogramm zum Einsatz kommen.

In einer weiteren Ausgestaltung der Erfindung ist vorgesehen, dass das System zur

Generierung von Ausgaben über eine Auszeichnungssprache Zugriff auf die MetaInformationen und den Kontext hat und diese Informationen somit in die Rückmeldung und allgemeine Verarbeitung einbeziehen kann.

Die Erfindung wird nachfolgend anhand einer Figur näher erläutert. Fig. 1 zeigt ein Übersichts-Blockfließbild über das gesamte Verfahren einschließlich der Optionen.

Die Erfindung wird nachfolgend an einem Beispiel näher erläutert, wobei sich die Erfindung aber nicht auf dieses Beispiel beschränkt.

Fig. 1 zeigt die Nutzereingabe 1 als Text. Der Nutzer kann diese Eingabe entweder durch gesprochene Sprache vornehmen, was ein nachfolgendes Programm für die Umsetzung von Sprache in Text erfordert, oder über ein Smartphone oder einen Computer oder ein sonstiges Gerät. Die Umwandlung kann auch integriert mittels einer Sprachsteuerung in einem Smartphone, Computer oder sonstigen Gerät erfolgen. Auch eine vorgeschaltete automatische Übersetzung ist möglich. Zur eindeutigen Nutzeridentifikation ist zudem eine Art Authentifizierung bzw. Nutzer- Identifikation erforderlich. Die Nutzereingabe, wie auch der ganze nachfolgende Dialog, kann auch gemischt über verschiedene Eingangskanäle erfolgen.

Im ersten Verarbeitungsschritt "Synonym Mapper" 2 findet eine Synonym-Erkennung statt, wobei der Text auf vom Administrator vorgegebene synonyme Phrasen geprüft wird. Falls solche Synonyme gefunden werden, erzeugt "Synonym Mapper" 2 Metadaten, in denen der ursprüngliche Text durch diese Synonyme ersetzt wird, ohne jedoch die ursprünglichen Daten zu löschen. Dieser Meta-Datensatz zu dem ursprünglichen Satz des Nutzers wird in den nachfolgenden Verarbeitungsschritten sukzessive erweitert.

Im zweiten Verarbeitungsschritt "NLP" 3 (Natural Language Processing) werden die im vorangegangenen, durch Metadaten erweiterten Nutzereingaben auf Satzstruktur und Satzbau analysiert. Im Einzelnen werden zunächst

• Zahlwörter ermittelt und durch Zahlen ersetzt,

• Füllwörter entfernt und Zusammenziehungen erweitert,

• Leerzeichen entfernt

• fehlende Punktuation ergänzt,

und es wird analysiert, ob der Satz eine Frage ist und falls ja, deren Eigenheiten extrahiert.

Danach wird das Ergebnis in einen NLP-Parser gegeben, der eine Zuordnung von Wörtern und Satzzeichen eines Textes zu Wortarten vornimmt, was auch als "POS-tagging" bezeichnet wird, und die Abhängigkeiten werden ermittelt, um die grammatischen und syntaktischen Beziehungen zwischen den Satzkomponenten als Daten auszugeben. Hierbei können eigens trainierte Machine Learning Modelle zur generischen Identifikation der Satzstrukturen zum Einsatz kommen. Im Anschluss daran werden die vom Parser erzeugten Daten dahingehend nachbereitet, dass Subjekt, Objekt sowie ihre Beziehung zueinander und ihre Eigenschaften identifiziert werden. Außerdem wird der Satztyp bestimmt, also beispielsweise, ob es eine Frage oder eine Aussage ist. Diese Daten werden als Metadaten dem Datensatz des vorangegangenen Schrittes hinzugefügt.

Im dritten Verarbeitungsschritt "Keyphrase Mapping" 4 erfolgt ein zweiter Durchlauf einer Synonym-Erkennung unter Verwendung der im vorangegangenen Schritt gewonnenen Metadaten. Zusätzlich wird die Häufigkeit ihres Auftretens gezählt. Außerdem wird die Negativität bewertet, es könnte ja auch sein, dass der Nutzer etwas genau nicht beabsichtigt, also nicht will. Weiterhin wird eine Kategorisierung vorgenommen, damit für die weitere Bearbeitung die richtigen Kontext-Datenbanken und ggf. externen Datenbanken involviert werden können. Weiterhin werden Tags vergeben. "Keyphrase Mapping" 4 erweitert somit den bestehenden Meta-Datensatz um diese Bedeutungen.

Im vierten Verarbeitungsschritt "Intent Mapper" 5 wird identifiziert, was der Nutzer

ausdrücken wollte, als er seine Nutzereingabe machte. Hierfür kommt der folgende Scoring- Algorithmus zum Einsatz.

Der "Intent Mapper" 5 nimmt zunächst alle vom Administrator definierten gültigen

Absichtsdefinitionen und für jeden Beispielsatz A, den der Administrator bereitgestellt hat, erzeugt er ein Paar P, bestehend aus dem Satz S des Nutzers einschließlich der zur

Verfügung gestellten Metadaten und dem Beispielsatz A. Jedem dieser Paare ordnet der Scoring-Algorithmus einen Ähnlichkeitswert W zu, indem er die folgenden Vergleiche anstellt:

Sind A und S identisch, erhält W den Wert 1 . Dies gilt ebenso für die lemmatisierte Form von S und die Form von S, bei denen Synonyme ersetzt wurden.

Wenn keine Identität von A und S festgestellt wurde, werden eine Reihe von

Eigenschaftsvergleichen vorgenommen, die jeweils einen Ähnlichkeitswert W zwischen 0 und 1 ergeben. Diese Eigenschaften umfassen Subjekte, Beziehungen, Objekte, sowie deren Lemmata, die Fragetypen wer-wie-was-wo, den Umstand, ob es sich überhaupt um eine Frage handelt, Bedingungen, verneinende Adverbien und ggf. weitere Aspekte.

Die Berechnung folgt dabei beispielhaft folgendem Schema, wobei EQ für Ergebnisanteile der Eigenschaften des jeweilgen Gesamtwertes W steht:

Sind Subjekt(A) und Subjekt(S) identisch, dann ist EQ = 1 , sonst ist EQ=0. Diese

Berechnung kann auf der lemmatisierten Version der entsprechenden Wörter erfolgen. Nun werden die Ergebnisse dieser ersten Berechnung folgendermaßen zusammengeführt.

W = EQ(Subjekt) ^* 0,1 + EQ(Verb) ^* 0,2 + EQ(Objekt) ^* 0,3 + EQ(Frage) ^* 0,2 +

EQ(Negativität) ^* 0,2 Die Anzahl der hierbei verwendeten Parameter kann je nach Verwendung variieren und auch die Gewichtungen sind beispielhaft.

Der Scoring-Algorithmus prüft dann für bestimmte Fälle, ob ein Wert 0 vergeben werden muss, etwa wenn der Beispielsatz eine Frage ist, die Nutzereingabe jedoch nicht, oder wenn Subjekt, Beziehung und Objekt nicht zueinander passen. Außerdem könnte das System bei ermittelter Negativität den Wert W von 0 vergeben.

Die Scoring-Werte W, der verschiedenen Paare P, werden danach gesammelt, in einer Tabelle abgelegt und ihrer Größe nach sortiert. Diese Tabelle wird dem Meta-Datensatz zugefügt.

Nun wird für jeden Beispielsatz A und die Nutzereingabe S diese Berechnung durchgeführt und das Ergebnis der Berechnung für die Nutzereingabe S mit sämtlichen aktiven Intents und damit mit einer gewissen Anzahl an Beispielsätzen A verglichen. Der Beispielsatz mit der höchsten Relevanz wird ausgewählt. Durch Zugehörigkeit des Beispielsatzes zu einem bestimmten Intent erfolgt die Intent-Zuordnung.

Im nächsten Bearbeitungsschritt "Prüfung des Intent Score" 6 wird geprüft, ob eine

Rückfrage an den Nutzer erforderlich ist, und wenn ja, wie. Hierzu werden vom Administrator zwei Schwellenwerte zwischen 0 und 1 vorgegeben. Der erste Wert ist der Rückfrage- Schwellenwert RT und der zweite Schwellenwert ist der Validitätsschwellenwert CT, der Schwellenwert CT ist dabei höher als der des RT.

Die beiden Schwellenwerte RT und CT teilen den Bereich der Scoring-Werte W in drei Bereiche. Wird der erste Schwellenwert RT nicht erreicht, erklärt das Programm dem Nutzer, es hätte ihn nicht verstanden und richtet höflich an ihn die Bitte 7, seine Eingabe

umzuformulieren. Wird der zweite Schwellenwert CT erreicht oder überstiegen, wird die Absicht als valide angesehen und auf eine Rückfrage wird verzichtet, nachfolgend fährt das Programm mit dem Flow 8 fort.

Wird zwar der erste Schwellenwert RT erreicht, der zweite Schwellenwert CT aber noch nicht, nimmt das Programm unter Nutzung seines lernenden Systems und seiner

Datenbanken eine tiefere Untersuchung vor. Das lernende System setzt nach dem Intent- Mapper 5 ein und ist mit einer Datenbank 100 verbunden, die aus drei Teilen besteht:

Nutzerdaten 101 , Kontext-Daten 102 und allgemeinen, externen Daten 103, außerdem ist das lernende System ggf. mit den APIs 104 verbunden.

Der Teil der Nutzerdaten 101 enthält Daten über den jeweiligen Nutzer und Daten aller Nutzer aus früheren Nutzereingaben und verfügt über je eine Lerndatenbank sowohl für jeden Nutzer individuell, als auch eine gemeinsame Lerndatenbank für alle Nutzer zusammen. Die jeweiligen Lerndatenbanken enthalten die bereits verarbeiteten Daten früherer Dialoge einschließlich der damit zusammenhängenden Meta-Informationen und eines Zählers, der angibt, wie oft jeder Satz, der eine erkannte Absicht enthält, vom jeweiligen Nutzer und von allen anderen Nutzern aufgetreten ist. Das lernende System agiert hierbei folgendermaßen:

Nachdem der Scoringwert W ermittelt wurde, wird zunächst in der Abfrage 6 geprüft, ob CT erreicht oder überschritten wurde oder nicht. In diesem Fall fährt das Programm ohne Eingriff in das lernende System mit dem nächsten Bearbeitungsschritt 8 fort. Wenn W zwischen RT und CT liegt, wird in den Nutzerdaten 101 in der Prüfung früherer Bestätigungen 10 geprüft, ob der Nutzer einen solchen Eingabesatz in einem vergleichbaren Kontext bereits früher bestätigt hat. Ist das der Fall, wird keine Rückfrage an den Nutzer formuliert, vielmehr „denkt" das System, dass der Nutzer erneut die geratene Eingabe meint und erhöht den Zähler für diesen erkannten Satz um 1 . Das Programm fährt ebenfalls mit dem Flow 8 fort.

Falls nicht, nimmt das Programm den Beispielsatz A, der zu dem höchsten Scorewert W gehört, formuliert in der Rückfrage 1 1 daraus eine Bestätigungsfrage und fragt den Nutzer, ob dies seine Absicht sei.

Falls der Nutzer dies in seiner Antwort 12 verneint, bestätigt das Programm, dass die Absicht nicht verstanden wurde und versucht, falls andere Beispielsätze ebenfalls RT erreicht hatten, deren Scorewert W aber niedriger als der vorherige war, vom Benutzer zu erfragen, ob dann diese Beispielssätze seine Absicht besser träfen. Ansonsten fährt das Programm mit dem Flow 8 fort, setzt jedoch ein„Flag" im Eingabeobjekt, das ausdrückt, dass die Absicht des Nutzers nicht ordnungsgemäß ermittelt werden konnte. So kann der Flow 8 entsprechend auf die Eingabe reagieren und den Nutzer-Dialog weiter fortführen.

Natürlich kann der Nutzer dann auch jederzeit zu einer Neuformulierung greifen, für die dann der ursprüngliche Prozess wieder von vorne beginnt. Sofern durch dieses Nachfragen keine Bestätigung erreicht wird, prüft das lernende System für jede der (ergebnislosen) Abfragen, ob der Satz des Nutzers als Lernsatz in der Lerndatenbank LDB bereits hinterlegt war.

Sofern dies der Fall ist, wird der zugehörige Zähler um 1 verringert, es sei denn, er war schon bei 0. Damit verringert das Programm die Gefahr, dass Missverständnisse tradiert werden.

Falls der Nutzer dagegen zustimmt, wird bestätigt, dass dieser Satz die Absicht bedeutet und der Zähler wird für diesen Nutzer und diesen Satz um 1 erhöht. Außerdem wird in der Verarbeitung der Antwort 14 geprüft, ob dieser Satz in früheren Abfragen anderer Nutzer bereits als Absicht bestätigt worden ist und als Lernsatz in der Lerndatenbank LDB gespeichert wurde. Wenn ein solcher Lernsatz bereits besteht, wird sein Zähler um 1 erhöht, wenn nicht, wird er als Lernsatz in der Lerndatenbank LDB angelegt. Danach wird im Schritt "Prüfung für Beispielsätze" 15 geprüft, ob der gelernte Satz als neuer Beispielsatz für weitere Fälle geeignet ist. Übersteigt der Zähler in der Lerndatenbank LDB dabei einen vom Administrator vorgegebenen Wert LT, entfernt das Programm den Lernsatz aus der Lerndatenbank im Schritt "Modifikation LDB" 16 und führt ihn künftig als Beispielsatz, so dass eine direkte Erkennung erfolgt. Hierbei wird der neue Beispielsatz als solcher markiert, um dem Administrator zu ermöglichen, diesen Beispielsatz wiederzufinden und ggf. manuell wieder zu löschen. Damit wird Missbrauch vermieden.

Das Programm setzt nunmehr mit dem Verarbeitungsschritt "Flow" 8 fort. Der Flow 8 ist ein Entscheidungsbaum, durch den man in der Lage ist, während eines Dialogs mit einem Nutzer Aussagen mit Bedeutungsinhalt zu erzeugen. Der Flow 8 nutzt die gespeicherten Kontextdaten 102 und den Status der Konversation, um einen menschenähnlichen

Nutzerdialog zu erreichen. Der Kontext wird benutzt, um Information zu speichern über alles, was sich auf den aktuellen Nutzer und den Dialog mit ihm bezieht, beispielsweise den Namen des Nutzers, nachdem er ihn genannt hat. Die Kontextdaten 102 werden gespeichert und stehen dann für zukünftige Nutzergespräche zur Verfügung. Der Status bestimmt, wo man sich in der Konversation gerade befindet, also beispielsweise am Anfang, am Ende oder in einem spezifischen Verarbeitungsschritt. Die Statusinformation ist entscheidend für angemessene Antworten, da identische Nutzereingaben in Abhängigkeit des aktuellen Dialogstatus völlig verschiedene Bedeutungen haben können.

Der Flow 8 hat per Konfiguration direkten Zugriff auf externe Datenquellen, externe Daten 103 sowie externe APIs 104 und kann diese in den Kontext und ein Gespräch einbeziehen.

Der Flow 8 besteht aus einer Anzahl verschiedenartiger Knoten, die die logische Struktur bestimmen, um einem Gespräch Struktur zu geben und die gewünschten Ausgaben zu erzeugen. Dies sind ein Startknoten, der den Beginn eines Flow bestimmt, Funktionsknoten, die eine bestimmte Funktion ausführen, beispielsweise eine Aussage an einen Nutzer auszugeben oder einen Eintrag in eine Datenbank vorzunehmen, Logikknoten, die den Ablauf innerhalb des Flow strukturieren, beispielsweise durch if/then/else oder

switch/case/default, und Codeknoten, die ausführbaren Programmcode enthalten, beispielsweise JavaScript. Mithilfe dieser Knoten kann der Flow 8 die aktuelle

Nutzereingabe, den Kontext und den Status erfassen, vorzugsweise mittels einer während der Laufzeit aktivierten Skriptsprache.

Eine solche während der Laufzeit aktivierte Skriptsprache besteht typischerweise aus einer Auszeichnungssprache mit Tags, die Teile von Texten oder Daten kennzeichnen. Ferner ermöglicht diese während der Laufzeit aktivierte Skriptsprache, entsprechende Anfragen an Datenbanken mit externen Daten 103 zu formen und aus den Flow-Knoten heraus direkte Anfragen an diese Datenquellen zu ermöglich. Synchron in der Form, dass etwaige Anfragen erst beantwortet werden müssen, bis der Flow 8 seine Abarbeitung fortsetzt, oder asynchron in der Form, dass die Abarbeitung weiterer Flow-Anfragen unmittelbar erfolgt. Die

Abarbeitung im Flow 8 nach einer asynchronen Datenbank-Anfrage erfolgt dabei, sobald die angefragten externen Daten 103 vorliegen, der Ablauf des immer noch gültigen Flow 8 wird mit den nun vorliegenden neuen Daten fortgesetzt. In ähnlicher Prozedur kann hierbei auch auf externe Programmierschnittstellen APIs 104 zugegriffen werden.

Jeder Flow startet mit einem Startknoten, dem beliebig viele Kindknoten folgen. Alle Knoten werden strangweise ausgehend vom Startknoten nacheinander ausgeführt, sobald sie erreicht werden. Logikknoten, die zu Verzweigungen führen, steuern den Ablauf und sorgen dafür, dass nur relevante Knoten während eines Gesprächs durchlaufen werden. So kann es sein, dass einige Knoten im Laufe eines Dialoges mehrfach oder auch gar nicht durchlaufen werden. Durch diese Konstellation ergibt sich ein freier aber strukturierter Dialog.

Besonders vorteilhaft ist es, eine Auszeichnungssprache innerhalb des Flow 8 zu benutzen, die es ermöglicht, die Meta-Informationen zu Nutzereingaben, den Kontext und den Status direkt innerhalb des Entscheidungsbaums aufzurufen oder zu verändern. Der Zugriff erfolgt z.B. über verschiedene Knoten oder per freier Programmierung.

Im Folgenden wird anhand eines einfachen Beispiels das Zusammenwirken näher beschreiben. Betrachtet werden soll eine größere Gruppe von Besuchern eines

Einkaufszentrums, die kleinen Hunger haben. Der erste Besucher spricht das System an mit den Worten: "Ich möchte einen Snack, wo gibt's das hier?". Zunächst wird dieser

gesprochene Satz mittels bekannter Technologie in Text umgewandelt, da der Zugriff von mehreren aufeinanderfolgenden Benutzern erfolgen kann, wird dem derzeit aktiven Dialog eine Identifikationsnummer zugeteilt und eine neuer, default-Gesprächskontext geladen. Nachfolgende Nutzerinteraktionen innerhalb eines aktiven Dialoges erfolgen unter

Verwendung dieses Gesprächskontextes. Führt ein dann neuer Nutzer ein Gespräch, wird erneut ein neuer, default-Gesprächskontext geladen.

Mit dieser Texteingabe 1 startet das System. Im Keyphrase Mapper 2 werden für den Begriff "Snack" Synonyme bzw. Oberbegriffe gesucht, beispielsweise wird hierfür der Begriff "Pizza" gefunden und es wird aus dem vom Nutzer hinzugefügten Lexikon geladen. Dort wird ein Schlüsselwort mit einem eindeutigen Identifier, der später im Flow verwendet werden kann, und einer frei definierbaren Anzahl an zugeordneten Synonymen, angelegt. Im

anschließenden Schritt NLP 3 wird die Eingabe Wort für Wort und die Beziehung zwischen den Wörtern untersucht. In diesem Fall wird erkannt, dass es sich um zwei Halbsätze handelt, von denen der letzte eine Frage ist, die sich auf eine Ortsangabe richtet. Subjekt des ersten Halbsatzes ist der Nutzer selbst, Objekt ist ein Nahrungsgegenstand. Eine Zahl wurde gefunden: das Wort "einen". Das Verb könnte auf eine Beziehungszustand hinweisen, der eine Absicht enthält. Aber auch der Fragesatz könnte eine Absicht darstellen.

Im Schritt "Keyphrase Mapping" 4 wird zunächst geprüft, ob etwas negiert wird, dies ist hier nicht der Fall. Die Kategorisierung wird präzisiert, Gegenstände sind ein Nahrungsmittel und eine Ortsangabe.

Im Schritt "Intent Mapper" 5 werden die Beispielsätze A für Nahrungsmittel und für

Ortsangaben geladen und es werden Paare gebildet. So gibt es etwa für "Snack" belegte Brötchen, Pizza und Chips mit entsprechenden Beispielsätzen A aus der

Synonymdatenbank. Für die Ortsangabe kann wegen des Bezuges "das" noch kein

Beispielsatz geladen werden, da der Gegenstand erst aus dem ersten Halbsatz folgt, der zunächst zu klären ist. Für jeden dieser Beispielsätze A wird ein Scoringwert W vergeben. Diese Scoringwerte können etwa proportional der typischen Umsätze der örtlichen

Lokalisationen vergeben worden sein, auch andere Vergabemodalitäten, etwa Bezüge auf aktuelle Werbeaktivitäten sind denkbar.

Im vorliegenden Beispielfall existiert kein Beispielsatz A mit "Snack", also weist keiner der Beispielsätze den Scoringwert W=1 auf. Die übrigen Bespielsätze sollen die Werte W-0,6 für Chips, W=0,7 für belegte Brötchen und W=0,8 für Pizza haben, was durch den Administrator zuvor festgelegt wurde, festgelegt wurden ferner ein Wert CT für nicht mehr zu bestätigende Rückfragen und RT=0,5 für zu unverständliche Nutzereingaben.

Im folgenden Schritt "Prüfung des Intent Score" 6 wird geprüft, ob der höchste Scoringwert der der Beispielsätze den Wert CT übersteigt. Dies ist vorliegend nicht der Fall. Danach wird geprüft, ob dieser höchste Wert wenigstens über RT liegt, dies ist der Fall. Daraufhin prüft das System im Schritt 13, ob es für diesen Nutzer und für eine solche Nutzereingabe bereits eine Bestätigung aus einer früheren Nutzereingabe gibt. Ist dies der Fall, wird nicht weiter nach einer Bestätigung gesucht, sondern die Nutzereingabe wird als bestätigt betrachtet und das System geht zum Flow 8 als nächstem Schritt über.

Bei einem solchen Überspringen der Bestätigung muss vorsichtig vorgegangen werden, und der Flow 8 muss aus dem Kontext sowie dem Status nachträglich prüfen, ob das

Überspringen der Bestätigung wirklich sachgerecht war, beispielsweise hätte ja derselbe Nutzer später wiederkommen können, und noch einen Snack verlangen können. Da er ja jetzt den Ort kenne, wo er Pizza bekommen könne, wäre seine Erwartung dann die, dass ihm jetzt was anderes angeboten werde, sonst hätte er ja nicht gefragt. Die zweite, identische Frage muss daher nicht automatisch dieselbe Erwartungshaltung bezüglich der Antwort beinhalten, sondern kann statusabhängig auch eine andere Absicht ausdrücken, diese Klärung ist aber nicht Gegenstand der Prüfung des Intent Score 6, sondern des Flow 8.

Wenn es keine Bestätigung dieses Nutzers der Vergangenheit gibt, leitet das Programm die Rückfrage 1 1 ein, die mit dem Beispielsatz des Höchsten Scoring-Werts W in Verbindung steht. Im vorliegenden Beispiel sei das der Satz, "Möchten Sie eine Pizza?". Das Programm erwartet hier eine Ja-Nein-Antwort. Sofern die Antwort "Ja" lautet, prüft das Programm für den zweiten Halbsatz, ob es hierfür einen Beispielsatz mit einem Wert 1 gibt, in diesem Beispiel wird das angenommen und eine weitere Rückfrage erübrigt sich. Das Programm geht auch hier weiter zum Flow, speichert den Satz aber zuvor in seiner Lerndatenbank LDB, die Teil der Nutzerdatenbank 101 ist, damit es die Frage beim nächsten Mal wiedererkennen kann.

Außerdem prüft das Programm, ob es die Frage nach dem Snack bereits aus anderen Nutzerabfragen kennt. Wenn dies der Fall wäre, würde es den Zähler in der Lerndatenbank für alle Nutzer um 1 erhöhen, im vorliegenden Beispiel muss der Satz in der Lerndatenbank aber erst neu angelegt werden. Aus diesem Grund erübrigt sich die Abfrage, ob der

Schwellenwert LT für die Übernahme in die Datenbank für Beispielsätze in die Datenbank für Referenz- bzw. Beispielsätze für Intents ebenfalls überschritten wurde.

Das Programm fährt dann mit dem Flow 8 fort, der eine Antwort generiert, wo eine Pizza zu bekommen ist, ggf. in Form einer Aufzählung, wenn es mehrere Orte hierzu geben sollte, die es kennt. Evtl. fragt es auch nach den gewünschten Belägen und nimmt direkt eine vollständige Bestellung auf, die das System dann an ein digitales Bestellsystem weiter leiten kann. Hierbei kann der Flow 8 per Konfiguration auf weitere anwendungsspezifische, externe Daten 103 oder Programmierschnittstellen APIs 104 zugreifen.

Im vorliegenden Fall fragt danach der zweite Benutzer "Ich möchte auch einen Snack, aber keine Pizza". Die ersten Schritte laufen analog, aber es gibt keinen zweiten Halbsatz mit einer Ortsfrage, außerdem gibt es eine Verneinung, die im Keyphrase Mapping 4 identifiziert wird, wenn sie nicht schon im vorangegangenen Schritt NLP 3 identifiziert wurde. Da eine Negierung zu Pizza enthalten ist, wird dem Beispielsatz mit der Pizza der Scoringwert 0 gegeben. Im nachfolgenden Schritt "Intent Mapping" 5 wird nur noch gefragt "Möchten Sie ein belegtes Brötchen?". Wenn der Nutzer dies bejaht, wird analog wie im vorangegangenen Fall weiter vorgegangen, erst im Flow 8 stellt das Programm fest, dass nicht nach einem Ort gefragt wurde und stellt weitere Fragen hierzu, möglicherweise bietet es Benutzer auch eine entsprechende direkte Bestellung an.

Die Lerndatenbank hat danach für die Frage nach dem Snack zwei verschiedene

Bestätigungen mit jeweils dem Zählerstand 1 . Sofern die Gruppe weitere ähnliche Anfragen stellt, lernt das System durch Erhöhung bzw. Herabsetzung des Zählers und unter Einbeziehung sämtlicher Kontext- und Meta-Informationen, was die Nutzer meinen und wollen.

Bezugszeichenliste

1 Nutzereingabe

2 Synonym-Mapper

3 NLP

4 Keyphrase Mapping

5 Intent Mapper

6 Prüfung des Intent Score

7. Bitte

8. Flow

9. (leer)

10. Prüfung früherer Bestätigungen

1 1 . Rückfrage an Nutzer

12. Antwort vom Nutzer

13 Prüfung der Antwort

14 Verarbeitung der Antwort

15 Prüfung für Beispielsätze

16 Modifikation LDB

100 Datenbank

101 Nutzerdaten

102 Kontextdaten

103 Externe Daten

104 Externe Programmierschnittstelle API