DE102022106956A1

DE102022106956A1 - Konversationelle ki-plattformen mit dialogintegration von geschlossenen domänen und offenen domänen

Info

Publication number: DE102022106956A1
Application number: DE102022106956.7A
Authority: DE
Inventors: Shubhadeep Das; Sumit Bhattacharya; Ratin Kumar
Original assignee: Nvidia Corp
Current assignee: Nvidia Corp
Priority date: 2021-03-31
Filing date: 2022-03-24
Publication date: 2022-10-06
Also published as: US20230120989A1; US20230317067A1; US11568861B2; GB202204492D0; US11769495B2; CN115146038A; US12057113B2; US20220319503A1; GB2607985A

Abstract

In verschiedenen Beispielen kombinieren Systeme und Verfahren der vorliegenden Offenbarung offene und geschlossene Dialogsysteme in ein intelligentes Dialogmanagementsystem. Eine Textanfrage kann durch einen Verständnismodell für natürliche Sprache verarbeitet werden, das trainiert ist, die Textanfrage einer Domänenkennung, einer Absichtsklassifikation und/oder Eingabeschlitzen zuzuordnen. Unter Verwendung der Domänenkennung kann das Verständnismodell für natürliche Sprache Informationen in der Textanfrage identifizieren, die Eingabeschlitzen entsprechen, die zum Beantworten der Textanfrage benötigt werden. Die Textanfrage und verwandte Informationen können dann an einen Dialogmanager weitergeleitet werden, um die Textanfrage an das Dialogsystem der geeigneten Domäne zu richten. Antworten, die von dem Dialogsystem der Domäne abgerufen werden, können dem Benutzer über Textausgabe und/oder über eine Text-zu-Sprache Komponente des Dialogmanagementsystems bereitgestellt werden.

Description

HINTERGRUND
Benutzer stützen sich häufig auf Softwareanwendungen - wie beispielsweise Chatbots, virtuelle Assistenten, soziale Bots und andere Formen von AI - um Anfragen zu übergeben und Gespräche zu führen. Diese Softwareanwendungen verwenden jedoch im Allgemeinen Dialogsysteme, die konfiguriert sind, um entweder breite oder enge Antworten, jedoch nicht beide, bereitzustellen. Beispielsweise sind Dialogsysteme einer geschlossenen Domäne konfiguriert, um spezifische, informierte Antworten bereitzustellen, und sind trainiert, Anfragen nur auf einen Satz von spezifischen Themen und/oder Domänen zu beantworten. Von daher kann ein Benutzer einen begrenzten Satz von Anfragen an ein Dialogsystem einer geschlossenen Domäne (z.B., einen Chatbot) hinsichtlich eines spezifischen Themas übergeben - wie beispielsweise Restaurants in einer Stadt - und spezifischen, ausführlichen Inhalt als eine Antwort empfangen. Im Gegensatz dazu werden Dialogsysteme offener Domänen trainiert, um menschenähnliche Antworten auf Anfragen bereitzustellen, die allgemeiner oder umgangssprachlicher und weniger ausführlich als jene sind, die durch Dialogsystem der geschlossenen Domäne bereitgestellt werden. Beispielsweise kann der Benutzer die meisten Anfragen an ein Dialogsystem einer offenen Domäne übergeben und eine relevante Antwort empfangen; Antworten auf Aufgaben-orientierte Anfragen (z.B., „Finden sie mir die besten 10 Restaurants in Seattle“) sind jedoch im Allgemeinen nicht so spezifisch oder enthalten so viel Informationen, wie die von dem Dialogsystem der geschlossenen Domäne empfangene Antwort.
Während Benutzer manuell wählen können, Dialogsysteme geschlossener Domänen für Aufgaben-orientierte Anfragen und Dialogsysteme offener Domänen für alle andere Anfragen zu verwenden, sind sich viele Benutzer nicht bewusst, welcher Art von System imstande sein wird, dem Benutzer eine gültige Antwort bereitzustellen. Somit werden viele Benutzer einfach darauf verzichten, unterschiedliche Anfragen an unterschiedliche Systeme zu leiten. Wenn ein Benutzer zwischen Dialogsystemen offener und geschlossener Domänen manuell umschaltet, geht außerdem der Kontext des Gesprächs verloren. Als Ergebnis können Benutzer nicht mit ausreichenden und/oder relevanten Antworten auf ihre Anfragen versorgt werden.
ZUSAMMENFASSUNG
Ausführungsformen der vorliegenden Offenbarung betreffen die gemeinsame Nutzung von Dialogsystemen geschlossener Domänen und offener Domänen. Systeme und Verfahren werden offenbart, die Textdaten, die für eine Benutzeranfrage repräsentativ sind, an mindestens eines von einem Dialogsystem einer offenen Domäne und einem Dialogsystem einer geschlossenen Domäne basierend auf Analysieren der Textdaten übertragen. Beispielsweise und im Gegensatz zu herkömmlichen Systemen, wie beispielsweise jene, die oben beschrieben sind, kombinieren Systeme und Verfahren der vorliegenden Offenbarung offene und geschlossene Dialogsystemen in einem integrierten, intelligenten Dialogmanagementsystem. Gemäß Ausführungsformen der vorliegenden Offenbarung kann, wenn ein Benutzer eine Textanfrage übergibt oder eine Textanfrage von einer Sprachanfrage transkribiert wird, die Textanfrage durch ein Verständnismodell für natürliche Sprache verarbeitet werden, das trainiert ist, die Textanfrage einer Domänenkennung, einer Absichtsklassifikation und/oder Eingabeschlitzen zuzuordnen. Unter Verwendung einer Domänenkennung kann das Verständnismodell für natürliche Sprache Informationen in der Textanfrage identifizieren, die Eingabeschlitzen entsprechen, die zum Beantworten der Textanfrage benötigt werden. Die Textanfrage und verwandte Informationen können dann an einen Dialogmanager weitergeleitet werden, um die Textanfrage an die geeignete Domäne zu richten.
Der Dialogmanager kann ein oder mehrere Dialogsysteme einer offenen Domäne sowie auch ein oder mehrere Dialogsysteme einer geschlossenen Domäne unterstützen. In einigen Ausführungsformen kann, wenn die Textabfrage, die Domänenkennung und die Absichtsklassifikation von einem Dialogmanager empfangen werden, der Dialogmanager auf die Domänenkennung und die Absichtsklassifikation für die Textanfrage zugreifen, um zu bestimmen, ob das Dialogmanagementsystem Regeln umfasst, um die Textanfrage an ein Dialogsystem einer Domäne zu leiten, die der Domänenkennung und der Absichtsklassifikation entspricht. Die Kennung/Klassifikation kann einem spezifischen geschlossenen oder offenen Dialogsystem entsprechen. Wenn es kein entsprechendes Dialogsystem gibt, kann der Dialogmanager die Textanfrage an ein Dialogsystem der Standarddomäne leiten. Das System der Standarddomäne kann dann eine Antwort auf die Textanfrage verarbeiten und zurückgeben. Wenn der Dialogmanager imstande ist, ein entsprechendes Dialogsystem zu bestimmen, kann der Dialogmanager die Textanfrage an das entsprechende Dialogsystem und das Dialogsystem der Standarddomäne leiten. Das spezifische Dialogsystem kann von dem Dialogmanager verlangen, eine Richtlinie für das Dialogsystem auszuführen. Abgerufene Antworten können dem Benutzer über Textausgabe und/oder über einen Text-zu-Sprache Komponente des Dialogmanagementsystem bereitgestellt werden.
In weiteren Ausführungsformen kann ein Dialogsystem einer offenen Domäne trainiert werden, um seine Antworten in Richtung von Dialogsystemen einer geschlossenen Domäne vorzuspannen (z.B., Gewicht oder direkt), die als Teil des Dialogmanagementsystems enthalten sind. Ein Satz von Trainingsdaten kann auf ein existierendes Dialogsystem einer offenen Domäne angewandt werden, um Antworten in Richtung enthaltener Dialogsysteme der geschlossenen Domäne zu richten, wenn das Dialogmanagementsystem nicht imstande ist, eine relevante Antwort auf eine Benutzeranfrage bereitzustellen. Demgemäß können Gespräche zwischen einem Benutzer und dem Dialogmanagementsystem in Richtung Erläuterungen geführt werden, die das Dialogmanagementsystem ausgestattet ist, beizubehalten.
Figurenliste
Die vorliegenden Systeme und Verfahren für die gemeinsame Nutzung von Dialogsystemen für eine geschlossene Domäne und eine offene Domänen werden ausführlich nachstehend mit Bezugnahme auf die beigefügten Zeichnungsfiguren beschrieben, wobei:

1 ein beispielhaftes Dialogmanagementsystem ist, das zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist;
2A-2B beispielhafte Routing-Operationen für Textanfragen sind, die zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Offenbarung geeignet sind;
3 eine beispielhafte Benutzerschnittstelle ist, die zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist;
4 ein Ablaufdiagramm zum Erzeugen einer Ausgabe auf eine Benutzeranfrage ist, das zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist;
5 ein Ablaufdiagramm zum Erzeugen einer Ausgabe auf eine Benutzeranfrage ist, das zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist;
6 ein Blockdiagramm einer beispielhaften Rechenvorrichtung ist, das zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist; und
7 ein Blockdiagramm eines beispielhaften Rechenzentrums ist, das zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist.

AUSFÜHRLICHE BESCHREIBUNG
Systeme und Verfahren werden offenbart, welche die gemeinsame Nutzung von Dialogsystemen einer geschlossenen Domäne und einer offenen Domäne betreffen. Obwohl hier primär mit Bezug auf Implementierungen von mobilen und digitale Desktop-Assistenten hier beschrieben, ist dies nicht bestimmt, beschränkend zu sein, und die Systeme und Verfahren der vorliegenden Offenbarung können in einer beliebigen Implementierung zum Kombinieren von Dialogsystemen einer offenen und geschlossenen Domäne implementiert werden, für nicht beschränkende Beispiele können die hier beschriebenen Systeme und Verfahren für intelligente Lautsprecheranwendungen, Smart-Appliance-Anwendungen, Sofortnachrichtendienstanwendungen, am menschlichen Körper tragbare Technologieanwendungen, intelligente Fahrzeuganwendungen und/oder andere Anwendungsarten implementiert werden, die einen interaktiven Austausch zwischen Mensch/Maschine erleichtern oder Aufgaben und/oder Dienste für einen Benutzer basierend auf Befehlen und/oder Fragen durchführen.
In einigen Ausführungsformen können offene und geschlossene Dialogsystemen in einem intelligenten Dialogmanagementsystem zum Erzeugen von Antworten auf Benutzeranfragen kombiniert werden. Beispielsweise kann ein Benutzer eine Anfrage an das Dialogmanagementsystem über Spracheingabe und/oder Texteingabe übergeben. Wenn der Benutzer die Anfrage über Spracheingabe übergibt, kann ein automatischer Spracherkenner Audiodaten verarbeiten, die der Spracheingabeanfrage entsprechen, um eine Textdarstellung (z.B., ein Transkript) der Audiodaten zu erzeugen. Die Textdarstellung oder die Spracheingabe und/oder eine Texteingabe - wie beispielsweise eingegebene Anfragen, die über ein Chat-Box empfangen werden - (zusammen „Textanfrage“) können dann durch einen Verständnismodell für natürliche Sprache verarbeitet und/oder analysiert werden, das trainiert ist, die Textanfrage einer Domänenkennung, einer Absichtsklassifikation und/oder Eingabeschlitzen zuzuordnen.
Die Domänenkennung kann eine Kennung für ein Dialogsystem einer spezifischen geschlossenen Domäne sein. Dialogsysteme einer geschlossenen Domäne - und entsprechende Kennungen - können umfassen, sind jedoch nicht begrenzt auf, Navigationssysteme, Wettersysteme, Restaurantsysteme, Sportsysteme, Musik- oder Entertainmentsysteme, digitale Mediensysteme, Theatersystemen, fahrzeuginterne Steuersysteme, Fitnesssysteme und/oder dergleichen. Diese Kennungen können einer Textanfrage durch das Verständnismodell für natürliche Sprache zugeordnet sein. Beispielsweise kann eine Anfrage, die angibt, „Bring mich zu dem nächsten Coffee-Shop“ mit einer geschlossenen Domänenkennung für Restaurants (z.B., eine Anwendung für Restaurantbewertungen und/oder einer Kennung für Navigation (z.B., einer Navigationsanwendung) gekennzeichnet werden.
Die Absichtsklassifikation kann beschreiben, was der Benutzer versucht, zu erreichen. In einigen Ausführungsformen kann das Verständnismodell für natürliche Sprache trainiert werden, um eine Antwort auf die Frage zu inferenzieren, warum ein Benutzer eine Anfrage übergibt und was der Benutzer wünscht, zu erreichen. Demgemäß kann das Verständnismodell für natürliche Sprache eine Absichtsklassifikation einer Textanfrage zuordnen. Beispielsweise kann die gleiche obige Anfrage, die angibt, „Bring mich zu dem nächsten Coffee-Shop“ mit einer Navigationsabsicht klassifiziert werden, weil das Verständnismodell für natürliche Sprache bestimmen kann, dass der Benutzer versucht, zu dem nächsten Coffee-Shop zu navigieren.
Unter Verwendung der einen oder mehreren Domänenkennungen kann das Verständnismodell für natürliche Sprache Informationen in der Textanfrage identifizieren, die Eingabeschlitzen der einen oder mehreren entsprechenden Domänen entsprechen, die zum Beantworten der Textanfrage benötigt werden. Beispielsweise kann eine Restaurantdomäne Eingabeschlitze für Ort, Preis, Küchenkategorie, offen/geschlossen usw. umfassen. Basierend auf einer empfangenen Textanfrage kann das Verständnismodell für natürliche Sprache Informationen der Textanfrage einem oder mehreren Eingabeschlitzen zuordnen. Beispielsweise kann eine Anfrage, die angibt, „Was ist das Wetter in Seattle morgen Abend?“ mit einer Wetterdomäne gekennzeichnet werden, die Eingabeschlitze für den Ort, Datum, Zeit usw. aufweisen kann. In diesem Beispiel kann das Verständnismodell für natürliche Sprache „Seattle“ einem Orteingabeschlitz, „morgen“ einem Datumeingabeschlitz und „Abend“ einem Zeiteingabeschlitz zugeordnet werden.
In einigen Ausführungsformen können dann die Textanfrage und verwandte Informationen (z.B., Domänenkennung, Absichtsklassifikation und/oder Eingabeschlitzdaten) an einen Dialogmanager weitergeleitet werden, um die Textanfrage an das geeignete Domäne zu richten. Der Dialogmanager kann ein oder mehrere Dialogsysteme offener Domänen - wie beispielsweise NVIDIA's MISTY, BLENDER oder andere Gesprächs-AI-Bot - sowie auch ein oder mehrere Dialogsystem geschlossener Domänen - wie beispielsweise ein oder mehrere spezifische Aufgaben-orientierte Bots unterstützen. Das Dialogmanagementsystem kann eine beliebige Anzahl von Dialogsystemen umfassen. Ein Entwickler kann Regeln (z.B., else-if-Anweisungen) konfigurieren, um Textanfragen an spezifische Domänen zu leiten (z.B., übertragen).
In einigen Ausführungsformen kann, wenn die Textanfrage und verwandte Informationen (z.B., Domänenkennung, Absichtsklassifikation und/oder Eingabeschlitzdaten) empfangen werden, der Dialogmanager auf die Domänenkennung und Absichtsklassifikation für die Textanfrage zugreifen. Die Domänenkennung und die Absichtsklassifikation können verwendet werden, um zu bestimmen, ob das Dialogmanagementsystem Regeln umfasst, welche die Textanfrage an ein Dialogsystem einer Domäne leiten, die der Domänenkennung und Absichtsklassifikation entspricht. Die Domänenkennung und Absichtsklassifikation können einem spezifischen geschlossenen oder offenen Dialogsystem entsprechen. In einigen Ausführungsformen kann, wenn es kein entsprechendes Dialogsystem gibt, der Dialogmanager die Textanfrage an ein Dialogsystem einer Standarddomäne leiten - wie beispielsweise einem Dialogsystem einer offenen Domäne. Das Dialogsystem der offenen Domäne kann dann einen Antwort auf die Textanfrage verarbeiten und zurückgeben.
In einigen Ausführungsformen kann, wenn der Dialogmanager imstande ist, ein entsprechendes geschlossenes Dialogsystem zu bestimmen, der Dialogmanager die Textanfrage an das entsprechenden geschlossene Dialogsystem zusätzlich zu dem Dialogsystem der offenen Domäne (z.B., so dass das Dialogsystem der offenen Domäne einen Zustand der Gesprächs beibehalten kann). Das spezifischen geschlossenen Dialogsystem kann erfordern der Dialogmanager, eine Richtlinie für das Dialogsystem auszuführen. Beispielsweise kann das Dialogsystem erfordern, dass Eingabeschlitz-Informationen eingefüllt werden (z.B., finde Wetter (Ort=„Seattle“, Tag=„Montag“, Zeit=„Abend“)), um einer Erfüllungskomponente zu erlauben, sich mit dem Domäne Dialogsystem schnittstellenmäßig zu verbinden und eine Antwort abzurufen. Abgerufene Antworten können dem Benutzer über Textausgabe und/oder über eine Text-zu-Sprache Komponente des Dialogmanagementsystems bereitgestellt werden.
In einigen Ausführungsformen kann, während ein Benutzer mit dem Dialogmanagementsystem wechselwirkt, der Benutzer Anfragen eingeben, die geleitet werden an und erfüllt werden durch ein oder mehrere Systeme offener Domäne sowie auch ein oder mehrere Systeme geschlossener Domäne. In derartigen Fällen kann das Dialogmanagementsystem einen Dialogzustand (z.B., einen Gesprächskontext) zwischen Systeme offener Domäne und Systeme geschlossener Domäne beibehalten. Wenn der Dialogmanager beispielsweise bestimmt, dass eine Textanfrage an ein identifiziertes Dialogsystem der geschlossenen Domäne geleitet werden sollte, kann der Dialogmanager die Textanfrage an sowohl das identifizierte Dialogsystem der geschlossenen Domäne sowie auch an ein Dialogsystem einer offenen Domäne (z.B., Standarddomäne Dialogsystem) leiten. Beide Dialogsysteme können dann die Textanfrage verarbeiten.
Die Verarbeitung einer Textanfrage durch sowohl ein identifiziertes Dialogsystem einer geschlossenen Domäne sowie auch ein Dialogsystem einer offenen Domäne kann dem Dialogsystem der offenen Domäne ermöglichen, einen internen Dialogzustand für das Dialogsystem einer offenen Domäne zu aktualisieren, der innerhalb das Dialogsystem der offenen Domäne gespeichert werden kann. Der Dialogmanager kann ebenfalls einen Dialogzustand basierend auf der Textanfrage aufzeichnen/speichern. Der Dialogzustand kann sich auf eine Historie, einer Einschätzung einer Absicht des Benutzers und/oder dem Status eines Gesprächs eines Benutzers mit einer digitalen Assistentenanwendung beziehen. In einigen Ausführungsformen können das identifizierte Dialogsystem der geschlossenen Domäne und das Dialogsystem der offenen Domäne jeweils einen Antwort auf die Textanfrage zurückgeben. Wenn die Textanfrage jedoch auf das identifizierte Dialogsystem der geschlossenen Domäne gerichtet ist, dann kann der Dialogmanager die von dem Dialogsystem einer offenen Domäne empfangene Antwort nicht beachten. Die von dem Dialogsystem der geschlossenen Domäne zurückgegeben Antwort kann dann dem Benutzer bereitgestellt werden. Vorteilhafterweise kann, durch Leiten von Textanfragen an sowohl das identifizierte Dialogsystem der geschlossenen Domäne als auch das Dialogsystem der offenen Domäne, wenn der Benutzer eine nachfolgende Anfrage übermittelt, die an das Dialogsystem der offenen Domäne geleitet wird, das Dialogsystem der offenen Domäne ein Verständnis des Dialogzustands aufweisen, um den Benutzer mit relevanten Ergebnissen zu versehen, als anderenfalls verfügbar sein würde.
In Ausführungsformen, in denen die Textanfrage nur an das Dialogsystem der offenen Domäne geleitet wird, kann die durch das Dialogsystem der offenen Domäne zurückgegebene Antwort von dem Dialogmanager berücksichtigt und verwendet werden, um den in dem Dialogmanager gespeicherten Dialogzustand zu aktualisieren. Vorteilhafterweise kann eine nachfolgende Benutzeranfrage, die an ein Dialogsystem der geschlossenen Domäne geleitet wird, auf den in dem Dialogmanager gespeicherten Dialogzustand zugreifen. Beispielsweise kann der Dialogmanager imstande sein, Informationen von dem Dialogzustand zu extrahieren, um in Eingabeschlitze zu füllen, die für das System erforderlich sind, um die Anfrage dem Dialogsystem der geschlossenen Domäne zu übergeben.
In weiteren Ausführungsformen kann ein Dialogsystem einer offenen Domäne trainiert werden, um seine Antworten in Richtung von Dialogsystemen von geschlossenen Domänen vorzuspannen, die als Teil des Dialogmanagementsystem umfasst sind. Beispielsweise kann das Dialogmanagementsystem Dialogsysteme der geschlossenen Domäne für Restaurants, Wetter, Reise, Sport, usw. umfassen. Ein Entwickler kann ein existierendes Dialogsystem einer offenen Domäne nehmen und einen Satz von Trainingsdaten auf das existierende Dialogsystem einer offenen Domäne anwenden, um Antworten in Richtung des umfassten Dialogsystems der geschlossenen Domäne zu richten, wenn das Dialogmanagementsystem nicht imstande ist, eine relevante Antwort auf eine Benutzeranfrage bereitzustellen. Wenn ein Benutzer beispielsweise fragt, „Was ist die Einwohnerzahl von Seattle?“ kann, da das Dialogmanagementsystem kein Dialogsystem für eine geschlossene Domäne aufweist, um diese Anfrage zu beantworten, die Anfrage an das Dialogsystem der offenen Domäne geleitet werden, das ebenfalls nicht imstande sein wird, Einwohnerzahlinformationen bereitzustellen. Basierend auf der trainierten Vorspannung kann das Dialogsystem der offenen Domäne jedoch das Gespräch in Richtung eines Dialogsystems der geschlossenen Domäne umleiten. Das Dialogsystem der offenen Domäne kann antworten mit „Ich weiß nichts darüber, ich weiß jedoch, dass es einige großartige Restaurants aufweist“. Vorteilhafterweise kann das Gespräch zwischen dem Benutzer und dem Dialogmanagementsystem kann daran gehindert werden, in eine ungewünschte Richtung abzuschweifen.
Mit Bezugnahme auf 1 ist 1 ein beispielhaftes Dialogmanagementsystem 100 (hier alternativ „System 100“ genannt) gemäß einigen Ausführungsformen der vorliegenden Erfindung. Es versteht sich, dass diese und andere hier beschriebene Anordnungen nur als Beispiele dargestellt werden. Andere Anordnungen und Elemente (z. B. Maschinen, Schnittstellen, Funktionen, Reihenfolgen, Gruppierungen von Funktionen usw.) können zusätzlich zu oder anstelle der gezeigten verwendet werden, und einige Elemente können ganz weggelassen werden. Außerdem sind viele der hier beschriebenen Elemente funktionale Einheiten, die als einzelne oder verteilte Komponenten oder in Verbindung mit anderen Komponenten und in jeder geeigneten Kombination und an jedem geeigneten Ort implementiert werden können. Verschiedene hier beschriebene Funktionen, welche von Einheiten ausgeführt werden, können von Hardware, Firmware und/oder Software ausgeführt werden. Beispielsweise können verschiedene Funktionen von einem Prozessor ausgeführt werden, der im Speicher gespeicherte Befehle ausführt. In einigen Ausführungsformen kann das System 100 ähnliche Komponenten, Merkmale und/oder Funktionalität wie die beispielhafte Rechenvorrichtung 600 von 6 und/oder das beispielhafte Rechenzentrum 700 von 7 umfassen.
Das Dialogmanagementsystem 100 kann unter anderem einen automatischen Spracherkenner 110, einen Verständnismodell für natürliche Sprache 120, einen Dialogmanager 130, ein oder mehrere Dialogsysteme einer offenen Domäne 150, ein oder mehrere Dialogsystemen einer geschlossene Domäne 160 und einen Text-zu-Sprache Wandler 170 umfassen.
Im Betrieb kann ein Benutzer eine Anfrage an das Dialogmanagementsystem 100 über die Spracheingabe 102 und/oder Texteingabe 104 übergeben. Obwohl nicht anschaulich dargestellt, können derartige Anfragen dem Dialogmanagementsystem 100 über eine oder mehrere von einer mobile Vorrichtung, einer Desktop-Vorrichtung, einer Smart-Appliance, einer am Menschen tragbaren Vorrichtung, einer Fahrzeugschnittstelle und/oder einer anderen Vorrichtung übergeben werden, die eine Vorrichtung unterstützen oder mit dieser kommunikativ gekoppelt ist, die eine digitale Assistentenschnittstelle ausführt. Wenn der Benutzer die Anfrage über die Spracheingabe 102 übergibt, kann der automatische Spracherkenner 110 Audiodaten verarbeiten, die der Spracheingabe 102 entsprechen, um eine Textdarstellung 112 (z.B., ein Transkript) der Audiodaten zu erzeugen. Die Textdarstellung 112 oder die Spracheingabe 102 und/oder eine Texteingabe 104 (zusammen anschaulich dargestellt und beschrieben als Textanfrage 114) können dann an das Verständnismodell für natürliche Sprache 120 weitergeleitet werden, das die Textanfrage 114 verarbeiten und/oder analysieren kann. Das Verständnismodell für natürliche Sprache 120 kann trainiert werden, um der Textanfrage 114 eine Domänenkennung, eine Absichtsklassifikation und/oder einen oder mehrere Eingabeschlitze zuzuordnen.
Die Domänenkennung kann eine Kennung für ein spezifisches Dialogsystem des einen oder mehreren Dialogsystemen der geschlossenen Domäne 160 sein. Die Dialogsystemen für die geschlossene Domäne 160 - und entsprechende Kennungen - können umfassen, sind jedoch nicht begrenzt auf, Navigationssysteme, Wettersysteme, Restaurantsysteme, Sportsysteme, Musik-Systeme, Kinosysteme und/oder dergleichen. Kennungen, die dem einen oder mehreren Dialogsystemen der geschlossenen Domäne 160 entsprechen, können der Textanfrage 114 durch das Verständnismodell für natürliche Sprache 120 zugeordnet werden.
Das Verständnismodell für natürliche Sprache 120 kann eine Absicht für die Textanfrage 114 durch Vorhersagen bestimmen, warum der Benutzer die Textanfrage 114 übergibt und was der Benutzer über die Textanfrage 114 erreichen will. Demgemäß kann das Verständnismodell für natürliche Sprache 120 ein oder mehrere bestimmte Absichtsklassifikationen der Textanfrage 114 zuordnen. Beispielsweise kann das Verständnismodell für natürliche Sprache 120 eine Navigationsabsicht und eine Restaurantabsicht der Textanfrage 114 zuordnen, wenn Textdaten für die Textanfrage 114 angeben, „Was ist das beste Barbeque in Seattle“. Das Verständnismodell für natürliche Sprache 120 kann diese Absicht der Textanfrage 114 zuordnen, weil das Verständnismodell für natürliche Sprache 120 vorhersagen kann, dass der Benutzer wünscht, dass das Dialogmanagementsystem 100 den Benutzer mit Informationen über ein Barbecue-Restaurant in Seattle mit den besten Bewertungen versorgt.
Das Verständnismodell für natürliche Sprache 120 kann ferner eine oder mehrere Domänenkennungen verwenden, die der Textanfrage 114 zugeordnet sind, um Informationen in der Textanfrage 114 zu identifizieren, die den Eingabeschlitzen der einen oder mehreren entsprechende Domänen entsprechen. Die Eingabeschlitze können als Platzhalter für Werte arbeiten, die von dem einen oder mehreren Dialogsystemen der offenen Domäne 150 und/oder dem einen oder mehreren Dialogsystemen der geschlossenen Domäne 160 zum Beantworten der Textanfrage 114 benötigt werden. Basierend auf der empfangenen Textanfrage 114 kann das Verständnismodell für natürliche Sprache 120 Informationen der Textanfrage 114 einem oder mehrere Eingabeschlitze zuordnen.
In einigen Ausführungsformen können die Textanfrage 114 eine oder mehrere Domänenkennungen, eine oder mehrere Absichtsklassifikationen und/oder der Textanfrage 114 zugeordnete Eingabeschlitzdaten an den Dialogmanager 130 weitergeleitet werden, um die Textanfrage 114 an die geeignete Domäne zu richten. Der Dialogmanager kann das eine oder mehrere Dialogsysteme der offenen Domäne 150 sowie auch ein oder mehrere Dialogsystem der geschlossenen Domäne 160 unterstützen. Das Dialogmanagementsystem kann eine beliebige Anzahl von Dialogsystemen umfassen, von denen jedes als eines des Dialogsystems der offenen Domäne 150, eines des Dialogsystems der geschlossenen Domäne 160 und/oder einem Dialogsystem der Standarddomäne durch einen Entwickler gekennzeichnet werden kann.
Der Dialogmanager 130 kann Dialogregeln 132, einen Domänencontroller 134, einen Kerndialogmanager 136 - der einen Dialogrichtlinienmanager 138 und einen Dialogzustands-Tracker 140 umfassen kann - und eine Aufgabenerfüllungsschnittstelle 142 umfassen. Die Dialogregeln 132 können Regeln zum Leiten der Textanfrage 114 an eine spezifische Domäne basierend auf einer Domänenkennung umfassen. Im Betrieb kann, wenn die Textanfrage 114 und die entsprechende(n) Domänenkennung(en), Absichtsklassifikation(n) und/oder Eingabeschlitzdaten von dem Dialogmanager 130 empfangen werden, der Dialogmanager auf die Domänenkennung und die Absichtsklassifikation für die Textanfrage zugreifen. Die Domänenkennung und die Absichtsklassifikation können verwendet werden, um zu bestimmen, ob die Dialogregeln 132 Regeln umfassen, um die Textanfrage 114 zu einen Domänendialogsystem zu leiten, das der Domänenkennung und der Absichtsklassifikation entspricht. Wenn die Textanfrage 114 beispielsweise einer spezifischen Domänenkennung zugeordnet ist, die den Regeln in den Dialogregeln 132 zugeordnet ist, dann kann die Textanfrage 114 an eine entsprechende spezifische Domäne basierend auf den Regeln übertragen werden - wie beispielsweise eine des Dialogsystem der geschlossenen Domäne 160. Wenn die Textanfrage 114 nicht einer spezifischen Domänenkennung zugeordnet ist oder die Domänenkennung irgendwelchen Regeln in den Dialogregeln 132 zugeordnet ist, dann kann die Textanfrage an eine Standarddomäne geleitet werden - wie beispielsweise eine des Dialogsystems der offenen Domäne 150.
In einigen Ausführungsformen können Richtlinien, die jeweils dem einen oder mehreren Dialogsystemen der offenen Domäne 150 und/oder dem einen oder mehreren Dialogsystem der geschlossenen Domäne 160 entsprechen, in dem Dialogrichtlinienmanager 138 gespeichert werden. Wenn eine Domänenkennung für die Textanfrage 114 einem Dialogsystem der bestimmten Domäne entspricht, kann der Dialogmanager 130 auf den Dialogrichtlinienmanager 138 zugreifen, um eine entsprechende Richtlinie zu identifizieren. Das eine oder mehrere Dialogsysteme der offenen Domäne 150 und/oder das eine oder mehrere Dialogsysteme der geschlossenen Domäne 160 können verlangen, dass der Dialogmanager 130 eine Richtlinie für ein Dialogsystem einer bestimmten Domäne ausführt. Basierend auf einer oder mehreren Richtlinien, die der spezifischen Domäne entsprechen, kann der Dialogmanager 130 eine Anfrage für das Dialogsystem der bestimmten Domäne erzeugen. Beispielsweise kann eine Anfrage für das Dialogsystem von der bestimmten Domäne verlangen, dass Eingabeschlitzinformationen von der Textanfrage 114 eingefüllt werden (z.B., finde Wetter (Ort=„Seattle“, Tag=„Monday“, Zeit=„Abend“)), um der Aufgabenbasierten Erfüllungsschnittstelle 142 zu ermöglichen, mit dem bestimmten Dialogsystem der Domäne zu kommunizieren.
Wenn die Textanfrage 114 mit dem einen oder mehreren Dialogsystemen der offenen Domäne 150 und/oder dem einen oder mehreren Dialogsystemen der geschlossenen Domäne 160 kommuniziert, kann die Textanfrage durch das eine oder mehrere Dialogsysteme der offenen Domäne 150 und/oder das eine oder mehrere Dialogsysteme der geschlossenen Domäne 160 verarbeitet werden, um ein oder mehrere Antworten (z.B., eine Textantwort) an die Textanfrage 114 zurückgeben. Eine der zurückgegebenen Antworten kann dem Benutzer über die Textausgabe 106 bereitgestellt werden und dem Benutzer vorgelegt werden. Beispielsweise kann der Text auf einer mobilen Vorrichtung des Benutzers, einen Fahrzeuganzeige, einer tragbaren Vorrichtung, usw. angezeigt werden. Zusätzlich oder alternativ kann die Antwort (z.B., die Textausgabe 106) an den Text-zu-Sprache Wandler 170 weitergeleitet werden. Der Text-zu-Sprache Wandler 170 kann die Antwort verarbeiten, um Audiodaten zu erzeugen, die der Antwort entsprechen, um eine Sprachausgabe 108 zu erzeugen. Die Sprachausgabe 108 kann dem Benutzer über eine mobile Vorrichtung des Benutzers, einen intelligenten Lautsprecher, ein Audiosystem eines Fahrzeugs, einer tragbaren Vorrichtung usw. bereitgestellt werden.
In einigen Ausführungsformen kann der Dialogzustands-Tracker 140 Wechselwirkungen mit dem einen oder mehreren Dialogsystemen der offenen Domäne 150 und/oder dem einen oder mehreren Dialogsystemen der geschlossenen Domäne 160 verfolgen, um einen Dialogzustand für einen Benutzer beizubehalten. Der Dialogzustand kann sich auf eine Historie, eine Schätzung der Absicht eines Benutzers und/oder den Status eines Gesprächs eines Benutzers mit einer digitalen Assistentenanwendung beziehen. Der Dialogzustands-Tracker 140 kann einen Dialogzustand basierend auf einer oder mehreren empfangenen Textanfragen 114 und/oder einer oder mehreren Antworten beibehalten, die von dem einen oder mehreren Dialogsystemen der offenen Domäne 150 und/oder dem einen oder mehreren Dialogsystemen der geschlossenen Domäne 160 erhalten werden, wie ferner gemäß 2A und 2B erläutert.
In einigen Ausführungsformen können ein oder mehrere Dialogsysteme der offenen Domäne 150 trainiert werden, um Antworten in Richtung eines oder mehrerer der Dialogsysteme der geschlossenen Domäne 160 vorzuspannen. Beispielsweise kann das Dialogmanagementsystem 100 ein Dialogsystem der geschlossenen Domäne 160 umfassen, das trainiert ist, um Textanfragen 114 hinsichtlich Restaurants, Wetter, Reise, Sport usw. zu erfüllen. In derartigen Ausführungsformen kann ein Satz von Trainingsdaten auf ein oder mehrere Dialogsysteme der offenen Domäne 150 angewandt werden, um das eine oder mehrere der Dialogsysteme der offenen Domäne 150 zu trainieren, um Antworten in Richtung eines oder mehrerer der Dialogsysteme der geschlossenen Domäne 160 zu richten, die in dem Dialogmanagementsystem 100 enthalten sind, wenn das Dialogmanagementsystem nicht imstande ist, eine relevante Antwort auf eine Textanfrage 114 bereitzustellen. Wenn das Dialogmanagementsystem 100 beispielsweise kein Dialogsystem in dem(den) Dialogsystem(en) der offenen Domäne 150 oder dem(den) Dialogsystem(en) der geschlossenen Domäne 160 aufweist, um eine Textanfrage 114 zu beantworten, kann die Textanfrage 114 zu einem Dialogsystem der Standarddomäne geleitet werden, das nicht imstande sein kann, eine Antwort bereitzustellen. Basierend auf der trainierten Vorspannung kann das Dialogsystem der Standarddomäne jedoch die Gespräche in Richtung eines oder mehrerer Dialogsystem der geschlossenen Domäne 160 und/oder eines oder mehrerer Dialogsysteme der offenen Domänen 150 leiten. Demgemäß kann verhindert werden, dass das Gespräch zwischen dem Benutzer und dem Dialogmanagementsystem 100 in eine ungewünschte Richtung abschweift, wobei es unwahrscheinlich ist, dass das Dialogmanagementsystem ausreichende Antworten auf zukünftige Textanfragen 114 des Benutzers bereitstellen kann.
Sich nun 2A-2B zuwendend, veranschaulichen 2A-2B beispielhafte Leitoperationen für Textanfragen, die zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Offenbarung geeignet sind. In einigen Ausführungsformen kann, wie beispielsweise diejenige, die in 2A gezeigt ist, ein Dialogmanager 210 eine Textanfrage lediglich an das(die) Dialogsystem(e) der offenen Domäne 220 leiten. Das(die) Dialogsystem(e) der offenen Domäne 220 kann(können) die Textanfrage verarbeiten und eine Antwort an den Dialogmanager 210 zurückgeben. Die Antwort kann von dem Dialogmanager berücksichtigt und verwendet werden, um den in dem Dialogmanager 210 gespeicherten Dialogzustand zu aktualisieren. In einigen Ausführungsformen kann der Dialogmanager 210 ebenfalls einen Dialogzustand basierend auf der Textanfrage aufzeichnen/speichern. Demgemäß kann eine nachfolgende Textanfrage, die zu einem Dialogsystem(en) der geschlossenen Domäne 230 geleitet wird, auf den im Dialogmanager 210 gespeicherten Dialogzustand zugreifen. Beispielsweise kann der Dialogmanager 210 imstande sein, Informationen aus dem Dialogzustand zu extrahieren, um Eingabeschlitze zu befüllen, die für den Dialogmanager 210 erforderlich sind, um eine Anfrage an das(die) Dialogsystem(e) der geschlossenen Domäne 230 zu übergeben. Wenn beispielsweise von Seattle in einem Gespräch mit einem Dialogsystem(en) der offenen Domäne 220 die Rede ist, dann kann der Benutzer sagen, „Wo ist der beste Coffee-Shop?“ und die intern gespeicherten Zustände in dem Dialogmanager 210 - die nun einen Ortszustand von „Seattle“ umfassen können - können verwendet werden, um eine Anfrage für das(die) Dialogsystem(e) der geschlossenen Domäne 230 zu erzeugen, die beste Coffee-Shops in Seattle umfasst, ohne von dem Benutzer zu verlangen, erneut den Ort zu spezifizieren, auf den sie Bezug nehmen.
Mit Bezugnahme auf 2B kann ein Dialogmanager 210 eine Textanfrage an das(die) Dialogsystem(e) der offenen Domäne 220 sowie auch an das(die) Dialogsystem(e) der geschlossenen Domäne 230 leiten. In derartigen Fällen kann das Dialogmanagementsystem 210 einen Dialogzustand (z.B., Gesprächskontext) zwischen dem(den) Dialogsystem(en) der offenen Domäne 220 und dem(den) Dialogsystem(en) der geschlossenen Domäne 230 beibehalten. Wenn der Dialogmanager 210 beispielsweise bestimmt, dass eine Textanfrage an ein identifiziertes Dialogsystem der geschlossenen Domäne des(der) Dialogsystems(e) der geschlossenen Domäne 230 geleitet werden sollte, kann der Dialogmanager 210 die Textanfrage an sowohl das identifizierte Dialogsystem der geschlossenen Domäne sowie auch an ein oder mehrere Dialogsysteme der offenen Domäne 220 leiten - wie beispielsweise ein Dialogsystem der Standarddomäne. Die Textanfrage kann dann durch sowohl das(die) Dialogsystem(e) der offenen Domäne 220 als auch das identifizierte Dialogsystem der geschlossenen Domäne verarbeitet werden.
Die Verarbeitung der Textanfrage durch sowohl das identifizierte Dialogsystem der geschlossenen Domäne des(der) Dialogsystems(e) der geschlossenen Domäne 230 sowie auch das(den) Dialogsystem(en) der offenen Domäne 220 kann dem(den) Dialogsystem(en) der offenen Domäne 220 ermöglichen, einen internen Dialogzustand für das(die) Dialogsystem(e) der offenen Domäne 220 zu aktualisieren, der innerhalb des Dialogsystem(en) der offenen Domäne 220 gespeichert werden kann. In einigen Ausführungsformen kann der Dialogmanager 210 ebenfalls einen Dialogzustand basierend auf der Textanfrage aufzeichnen/speichern. In weiteren Ausführungsformen kann der Dialogmanager 210 einen Antwort von dem(den) Dialogsystem(en) der geschlossenen Domäne 230 empfangen und kann die empfangene Antwort an das(die) Dialogsystem(e) der offenen Domäne 220 übertragen. Das(die) Dialogsystem(e) der offenen Domäne 220 kann(können) die Antwort empfangen, die durch das(die) Dialogsystem(e) der geschlossenen Domäne 230 empfangen wird, und den internen Dialogzustand des(der) Dialogsystems(e) der offenen Domäne 220 basierend auf der Antwort aktualisieren. Antworten, die durch das(die) Dialogsystem(e) der offenen Domäne 220 bereitgestellt werden, können dann Zustandsinformationen aufnehmen, die in dem(den) Dialogsystem(en) der offenen Domäne 220 basierend auf dem aktualisierten internen Dialogzustand gespeichert werden.
In einigen Ausführungsformen kann das identifizierte Dialogsystem der geschlossenen Domäne und das(die) Dialogsystem(e) der offenen Domäne 220 jeweils eine Antwort auf die Textanfrage zurückgeben. Wenn die Textanfrage jedoch auf das identifizierte Dialogsystem der geschlossenen Domäne des(der) Dialogsystems(e) der geschlossenen Domäne 230 gerichtet ist, kann der Dialogmanager 210 eine beliebige Antwort nicht beachten, die von dem(den) Dialogsystem(en) der offenen Domäne 220 empfangen wird. Die Antwort, die durch das(die) Dialogsystem(e) der geschlossenen Domäne 230 zurückgegeben wird, kann dann dem Benutzer bereitgestellt werden. Durch Leiten Textanfragen ein sowohl das identifizierten Dialogsystem der geschlossenen Domäne als auch das(die) Dialogsystem(e) der offenen Domäne 220, wenn ein Benutzer eine nachfolgende Anfrage übergibt, die an das(die) Dialogsystem(e) der offenen Domäne 220 geleitet wird, kann das(die) Dialogsystem(e) der offenen Domäne 220 auf den Dialogzustand zugreifen, um dem Dialogsystem der offenen Domäne 220 zu ermöglichen, einen Kontext der Textanfrage zu verstehen, um den Benutzer mit relevanteren Ergebnissen zu versehen, als anderenfalls verfügbar sein würde.
Bezugnehmend nun auf 3 veranschaulicht 3 eine beispielhafte Benutzerschnittstelle, die zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist. 3 umfasst die Vorrichtung 310, die AI-Graphik 320 und den Benutzer 330. In verschiedenen Ausführungsformen kann die Vorrichtung 310 sein: ein Smartphone, ein Laptop-Computer, ein Tablet-Computer, ein Desktop-Computer, eine tragbare Vorrichtung, eine Spielkonsole, ein System virtueller Realität (z.B., ein Headset, ein Computer, eine Spielkonsole), eine Streaming-Vorrichtung, (z.B., ein NVIDIA SHIELD), eine Smart-Home-Vorrichtung, eine Fahrzeugrechenvorrichtung, eine anderen Art von Vorrichtung, die Aufgaben und/oder Dienste für den Benutzer 330 basierend auf Befehlen und/oder Fragen, abhängig von der Ausführungsform oder Implementierung und/oder einen Kombination davon, durchführen kann. Die AI-Graphik 320 kann ein animierte Figur, ein Avatar oder eine andere Personifizierung sein. Im Betrieb kann der Benutzer 330 eine Anfrage an ein Dialogmanagementsystem, wie beispielsweise das System 100 von 1, über Spracheingabe und/oder Texteingabe an die Vorrichtung 310 übergeben. Die Vorrichtung 310 kann die Anfrage durch das Dialogmanagementsystem empfangen und verarbeiten. In einigen Ausführungsformen kann das Dialogmanagementsystem die AI-Graphik 320 veranlassen, dem Benutzer 330 über die Vorrichtung 310 einen Indikator bereitzustellen, um anzugeben, dass die Anfrage verarbeitet wird. Beispielsweise kann die AI-Graphik 320 einen Gesichtsausdruck der AI-Graphik 320 verändern, um eine denkende Person nachzuahmen. Sobald das Dialogmanagementsystem die Anfrage verarbeitet hat, kann dem Benutzer 330 über die Vorrichtung 310 eine Antwort bereitgestellt werden. In einigen Ausführungsformen kann es scheinen, dass die AI-Graphik 320 die Antwort durch passende Mundposen der AI-Graphik 320 zurück zu dem Benutzer in Schallreflexionen der Audiodaten der Antwort zum Ausdruck bringt.
Bezugnehmend nun auf 4-5 umfasst jeder Block der hier beschriebenen Verfahren 400 und 500 einen Rechenprozess, der unter Verwendung einer beliebigen Kombination aus Hardware, Firmware und/oder Software durchgeführt werden kann. Beispielsweise können verschiedene Funktionen von einen Prozessor durchgeführt werden, der im Speicher gespeicherte Anweisungen ausführt. Die Verfahren 400 und 500 können ebenfalls als computerverwendbare Anweisungen verkörpert sein, die auf Computerspeicherungsmedien gespeichert sind. Die Verfahren 400 und 500 können von einer eigenständigen Anwendung, einem Dienst oder gehosteten Dienst (eigenständig oder in Kombination mit einem anderen gehosteten Dienst) oder einen Plug-in in einem anderen Produkt bereitgestellt werden, um einige wenige zu nennen. Außerdem werden die Verfahren 400 und 500 beispielhaft mit Bezug auf das System 100 von 1 beschrieben. Diese Verfahren können jedoch zusätzlich oder alternativ durch ein beliebiges System oder eine beliebige Kombination von Systemen, einschließlich, jedoch nicht begrenzt auf jene, die hier beschrieben sind, ausgeführt werden.
Mit Bezugnahme auf 4 ist 4 ein Ablaufdiagramm, das ein Verfahren 400 zum Erzeugen einer Ausgabe auf eine Benutzeranfrage zeigt, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Das Verfahren 400 umfasst bei B402 das Analysieren von Textdaten, die für eine Benutzeranfrage repräsentativ sind. Beispielsweise kann die Textdarstellung 112 oder die Spracheingabe 102 und/oder eine Texteingabe 104 (zusammen als Textanfrage 114 anschaulich dargestellt und beschrieben) dann an das Verständnismodell für natürliche Sprache 120 weitergeleitet werden, welches die Textanfrage 114 verarbeiten und/oder analysieren kann.
Das Verfahren 400 umfasst bei B404 das Erzeugen einer Domänenkennung, die der Benutzeranfrage entspricht, basierend mindestens teilweise auf dem Analysieren. Beispielsweise kann das Verständnismodell für natürliche Sprache 120 trainiert werden, um die Textanfrage 114 einer Domänenkennung, einer Absichtsklassifikation und/oder einem oder mehreren Eingabeschlitzen zuzuordnen.
Das Verfahren 400 umfasst bei B406 das Übertragen der Textdaten an das Dialogsystem der offenen Domäne, wenn die Domänenkennung einem Dialogsystem einer offenen Domäne entspricht. Wenn die Textanfrage 114 beispielsweise einer spezifischen Domänenkennung zugeordnet ist, die Regeln in den Dialogregeln 132 zugeordnet ist, dann kann die Textanfrage 114 an eine entsprechende spezifischen Domäne basierend auf den Regeln übertragen werden.
Das Verfahren 400 umfasst bei B408, wenn die Domänenkennung einem Dialogsystem der geschlossenen Domäne entspricht, (1) Zugreifen, basierend mindestens teilweise auf der Domänenkennung, auf eine oder mehrere Anfragerichtlinien, die dem Dialogsystem der geschlossenen Domäne entsprechen; (2) basierend mindestens teilweise auf der einen oder mehreren Anfragerichtlinien, Erzeugen einen Anfrage für das Dialogsystem der geschlossenen Domäne unter Verwendung der Textdaten; und (3) Übertragen der Anfrage an das Dialogsystem der geschlossenen Domäne. Wenn eine Domänenkennung für die Textanfrage 114 beispielsweise einem Dialogsystem der bestimmten Domäne entspricht, kann der Dialogmanager 130 auf den Dialogrichtlinienmanager 138 zugreifen, um eine entsprechende Richtlinie zu identifizieren. Das eine oder mehrere Dialogsystem der offenen Domäne 150 und/oder das ein oder mehrere Dialogsystem der geschlossenen Domäne 160 können von dem Dialogmanager 130 verlangen, eine Richtlinie für ein Dialogsystem einer bestimmten Domäne auszuführen. Basierend auf einer oder mehreren Richtlinien, die der spezifischen Domäne entsprechen, kann der Dialogmanager 130 eine Anfrage für das Dialogsystem der bestimmten Domäne erzeugen.
Das Verfahren 400 umfasst bei B410 das Empfangen reagierender Textdaten von mindestens einem der Dialogsysteme einer offenen Domäne, das auf die Textdaten reagiert, oder das Dialogsystem der geschlossenen Domäne, das auf die Anfrage reagiert. Wenn die Textanfrage 114 beispielsweise an das eine oder mehrere Dialogsysteme der offenen Domäne 150 und/oder das eine oder mehrere Dialogsysteme der geschlossenen Domäne 160 kommuniziert wird, kann die Textanfrage durch das eine oder mehrere Dialogsysteme 150 der offenen Domäne und/oder das eine oder mehrere Dialogsysteme 160 der geschlossenen Domäne 160 verarbeitet werden, um eine oder mehrere Antworten (z.B., eine Textantwort) an die Textanfrage 114 zurückzugeben.
Das Verfahren 400 umfasst bei B412 das Erzeugen einer Ausgabe basierend mindestens teilweise auf den reagierenden Textdaten. Beispielsweise kann eine Textantwort auf einer mobilen Vorrichtung des Benutzers, einer Fahrzeuganzeige, einer tragbaren Vorrichtung usw. angezeigt werden. Zusätzlich oder alternativ kann die Antwort (z.B. die Textausgabe 106) an den Text-zu-Sprache Wandler 170 weitergeleitet werden. Der Text-zu-Sprache Wandler 170 kann die Antwort verarbeiten, um Audiodaten zu erzeugen, die der Antwort entsprechen, um eine Sprachausgabe 108 zu erzeugen. Die Sprachausgabe 108 kann dem Benutzer über eine mobile Vorrichtung des Benutzers, einen intelligenten Lautsprecher, einem Audiosystem eines Fahrzeugs, einer tragbaren Vorrichtung usw. bereitgestellt werden.
Bezugnehmend nun auf 5 ist 5 ein Ablaufdiagramm, das ein Verfahren 500 zum Erzeugen einer Ausgabe auf eine Benutzeranfrage zeigt, gemäß einigen Ausführungsformen der vorliegenden Offenbarung. Das Verfahren 500 umfasst bei Block B502 das Analysieren erster Textdaten, die für eine Benutzeranfrage repräsentativ sind. Beispielsweise kann die Textdarstellung 112 oder die Spracheingabe 102 und/oder eine Texteingabe 104 (zusammen anschaulich dargestellt und als Textanfrage 114 beschrieben) dann an das Verständnismodell für natürliche Sprache 120 weitergeleitet werden, welches die Textanfrage 114 verarbeiten und/oder analysieren kann.
Das Verfahren 500 umfasst bei Block B504 das Bestimmen einer Domänenkennung, die der Benutzeranfrage basierend mindestens teilweise auf dem Analysieren entspricht, der Domänenkennung, die einem oder mehrere eines Dialogsystem einer offenen Domäne oder eines Dialogsystem der geschlossenen Domäne entspricht. Beispielsweise kann das Verständnismodell für natürliche Sprache 120 trainiert werden, um die Textanfrage 114 einer Domänenkennung, einer Absichtsklassifikation und/oder einem oder mehreren Eingabeschlitze zuzuordnen.
Das Verfahren 500 umfasst bei Block B506 das Zugreifen auf eine oder mehrere Anfragerichtlinien, die dem Dialogsystem der geschlossenen Domäne entspricht, die bestimmt sind, der Domänenkennung zugeordnet zu sein. Wenn eine Domänenkennung für die Textanfrage 114 beispielsweise einem Dialogsystem einer bestimmten Domäne entspricht, dann kann der Dialogmanager 130 auf den Dialogrichtlinienmanager 138 zugreifen, um eine entsprechende Richtlinie zu identifizieren.
Das Verfahren 500 umfasst bei Block B508 das Erzeugen einer Anfrage für das Dialogsystem der geschlossenen Domäne unter Verwendung der ersten Textdaten basierend mindestens teilweise auf der einen oder mehreren Anfragerichtlinien. Beispielsweise kann basierend auf einer oder mehreren Richtlinien, die der spezifischen Domäne entsprechen, der Dialogmanager 130 eine Anfrage für das Dialogsystem der bestimmten Domäne erzeugen.
Das Verfahren 500 umfasst bei Block B510 das Senden der Anfrage an das Dialogsystem der geschlossenen Domäne. Wenn die Textanfrage 114 beispielsweise einer spezifischen Domänenkennung zugeordnet ist, die Regeln in den Dialogregeln 132 zugeordnet ist, dann kann die Textanfrage 114 an eine entsprechende spezifischen Domäne basierend auf den Regeln übertragen werden.
Das Verfahren 500 umfasst bei Block B512 das Empfangen zweiter Textdaten von dem Dialogsystem der geschlossenen Domäne, die auf die Anfrage reagieren. Beispielsweise kann der Dialogmanager 210 eine Antwort von dem Dialogsystem der geschlossenen Domäne 230 empfangen.
Das Verfahren 500 umfasst bei Block B514 das Senden der zweiten Textdaten an das Dialogsystem der offenen Domäne. Beispielsweise kann der Dialogmanager 210 die empfangene Antwort von dem(den) Dialogsystem(en) der geschlossenen Domäne 230 an das(die) Dialogsystem(e) der offenen Domäne 220 übertragen.
Das Verfahren 500 umfasst bei Block B516 das Erzeugen einer Ausgabe basierend mindestens teilweise auf den von dem Dialogsystem der geschlossenen Domäne empfangenen zweiten Textdaten. Beispielsweise können dann Antworten, die von dem Dialogsystem der offenen Domäne 220 bereitgestellt werden, Zustandsinformationen, die in dem(den) Dialogsystem(en) der offenen Domäne(n) 220 gespeichert sind, basierend auf dem aktualisierten internen Dialogzustand aufnehmen.
BEISPIEL EINER RECHENVORRICHTUNG
6 ist ein Blockdiagramm einer beispielhaften Rechenvorrichtung 600, die zur Verwendung bei der Implementierung einiger Ausführungsformen der vorliegenden Offenbarung geeignet ist. Die Rechenvorrichtung 600 kann einen Zwischenverbindungssystem 602 umfassen, das direkt oder indirekt die folgenden Vorrichtungen koppelt: Speicher 604, eine oder mehrere Zentralverarbeitungseinheiten (CPUs) 606, eine oder mehrere Graphikverarbeitungseinheiten (GPUs) 608, eine Kommunikationsschnittstelle 610, Ein-/Ausgabe (E/A)-Ports 612, Eingabe-/Ausgabe-Komponenten 614, eine Leistungsversorgung 616, eine oder mehreren Präsentationskomponenten 618 (z.B. Anzeige(n)) und eine oder mehrere Logikeinheiten 920. In mindestens einer Ausführungsform kann(können) die Rechenvorrichtung(en) 600 eine oder mehrere virtuelle Maschinen (VMs) umfassen und/oder kann jede der Komponenten davon virtuelle Komponenten (z.B. virtuelle Hardwarekomponenten) umfassen. Als nicht beschränkende Beispiele können eine oder mehrere der GPUs 608 eine oder mehrere vGPUs umfassen, können eine oder mehrere der CPUs 606 eine oder mehrere vCPUs umfassen, und/oder können eine oder mehrere der Logikeinheiten 620 eine oder mehrere virtuelle Logikeinheiten umfassen. Von daher kann(können) eine Rechenvorrichtung(en) 600 diskrete Komponenten (z.B. eine vollständige GPU, die der Rechenvorrichtung 600 zugeordnet ist), virtuelle Komponenten (z.B. einen Teil einer GPU, die der Rechenvorrichtung 600 zugeordnet ist) oder eine Kombination davon umfassen.
Obwohl die verschiedenen Blöcke von 6 als über das Zwischenverbindungssystem 602 mit Leitungen verbunden gezeigt sind, ist dies nicht bestimmt, einschränkend zu sein, und dient nur der Klarheit. Beispielsweise kann in einigen Ausführungsformen eine Präsentationskomponente 618, wie beispielsweise eine Anzeigevorrichtung, als eine E/A-Komponente 614 betrachtet werden (z.B., wenn die Anzeige ein Touchscreen ist). Als weiteres Beispiel können die CPUs 606 und/oder die GPUs 608 Speicher umfassen (z.B. kann der Speicher 604 für eine Speichervorrichtung zusätzlich zu dem Speicher der GPUs 608, der CPUs 606 und/oder anderer Komponenten repräsentativ sein). Mit anderen Worten ist die Rechenvorrichtung von 6 lediglich veranschaulichend. Es wird nicht zwischen derartigen Kategorien wie „Arbeitsstation“, „Server“, „Laptop“, „Desktop“, „Tablet“, „Client-Vorrichtung“, „mobile Vorrichtung“, „Handheld-Vorrichtung“, „Spielkonsole“, „elektronische Steuereinheit (ECU)“, „Virtual-Reality-System“ und/oder anderen Vorrichtungs- oder Systemarten unterschieden, wie sie alle innerhalb des Umfangs der Rechenvorrichtung von 6 denkbar sind.
Das Zwischenverbindungssystem 602 kann einen oder mehrere Verbindungen oder Busse darstellen, wie beispielsweise einen Adressbus, einen Datenbus, einen Steuerbus oder eine Kombination davon. Der Bus 602 kann eine oder mehrere Bus- oder Verbindungstypen umfassen, wie beispielsweise einen Industrie-Standard-Architektur (ISA)-Bus, einen erweiterten Industrie-Standard-Architektur (EISA)-Bus, einen Video Electronics Standards Association (VESA)-Bus, einen Peripheral Component Interconnect (PCI)-Bus, einen Peripheral Component Interconnect Express (PCIe)-Bus und/oder einen anderen Typ von Bus oder Verbindung. In einigen Ausführungsformen gibt es direkte Verbindungen zwischen Komponenten. Als Beispiel kann die CPU 606 direkt mit dem Speicher 604 verbunden sein. Ferner kann die CPU 606 direkt mit der GPU 608 verbunden sein. Wo es eine direkte oder Punkt-zu-Punkt-Verbindung zwischen Komponenten gibt, kann das Zwischenverbindungssystem 602 eine PCIe-Verbindung umfassen, um die Verbindung auszuführen. In diesen Beispielen muss ein PCI-Bus nicht in der Rechenvorrichtung 600 umfasst sein.
Der Speicher 604 kann beliebige einer Vielzahl von computerlesbaren Medien umfassen. Die computerlesbaren Medien können beliebige verfügbare Medien sein, auf die von der Rechenvorrichtung 600 zugegriffen werden kann. Die computerlesbaren Medien können sowohl flüchtige als auch nichtflüchtige Medien und entfernbare als auch nicht entfernbare Medien umfassen. Beispielsweise und nicht beschränkend können die computerlesbaren Medien Computer-Speichermedien und Kommunikationsmedien umfassen.
Die Computer-Speichermedien können sowohl flüchtige als auch nichtflüchtige Medien und/oder entfernbare als auch nicht entfernbare Medien umfassen, die in einem beliebigen Verfahren oder einer beliebigen Technologie zur Speicherung von Informationen, wie beispielsweise computerlesbaren Anweisungen, Datenstrukturen, Programmmodulen und/oder anderen Datenarten, implementiert sind. Beispielsweise kann der Speicher 604 computerlesbare Anweisungen (z.B. solche, die ein Programm(e) und/oder ein Programmelement(e), wie beispielsweise ein Betriebssystem darstellen) speichern. Computer-Speichermedien können umfassen, sind jedoch nicht begrenzt auf, RAM, ROM, EEPROM, Flash-Speicher oder andere Speichertechnologien, CD-ROM, Digital Versatile Disks (DVD) oder andere optische Plattenspeicher, Magnetkassetten, Magnetbänder, magnetische Plattenspeicher oder andere magnetische Speichervorrichtungen oder jedes andere Medium, das verwendet werden kann, um die erwünschten Informationen zu speichern, und auf das von der Rechenvorrichtung 600 zugegriffen werden kann. Wie hier verwendet, umfassen Computerspeichermedien keine Signale per se.
Die Computerspeicherungsmedien können computerlesbare Anweisungen, Datenstrukturen, Programmmodule und/oder andere Datenarten in einem modulierten Datensignal, wie beispielsweise einer Trägerwelle oder einem anderen Transportmechanismus, verkörpern und beliebige Information-liefernde Medien umfassen. Der Begriff „moduliertes Datensignal“ kann sich auf ein Signal beziehen, das eine oder mehrere seiner Eigenschaften eingestellt oder auf eine derartige Art und Weise geändert hat, um Informationen in dem Signal zu codieren. Beispielhaft und nicht einschränkend können die Kommunikationsmedien drahtgebundene Medien, wie beispielsweise ein drahtgebundenes Netzwerk oder eine direktverdrahtete Verbindung sowie drahtlosen Medien, wie beispielsweise akustische, HF-, Infrarot- und andere drahtlose Medien, umfassen. Kombinationen aus beliebigem des Obigen sollten ebenfalls innerhalb des Umfangs von computerlesbaren Medien umfasst sein.
Die CPU(s) 606 kann(können) konfiguriert sein, um mindestens einige der computerlesbaren Anweisungen auszuführen, um eine oder mehrere Komponenten der Rechenvorrichtung 600 zu steuern, um eines oder mehrere der hier beschriebenen Verfahren und/oder Prozesse durchzuführen. Die CPU(s) 606 kann(können) jeweils einen oder mehrere Kerne (z.B. ein, zwei, vier, acht, achtundzwanzig, zweiundsiebzig usw.) umfassen, die in der Lage sind, eine Vielzahl von Software-Threads gleichzeitig zu verarbeiten. Die CPU(s) 606 kann(können) jede Art von Prozessor umfassen und kann(können) unterschiedliche Arten von Prozessoren abhängig von der Art der implementierten Rechenvorrichtung 600 umfassen (z.B. Prozessoren mit weniger Kernen für mobile Vorrichtungen und Prozessoren mit mehr Kernen für Server). Beispielsweise kann der Prozessor abhängig von der Art der Rechenvorrichtung 600 ein Advanced RISC Machines (ARM) Prozessor sein, der unter Verwendung des Reduced Instruction Set Computing (RISC) implementiert ist, oder ein x86-Prozessor sein, der unter Verwendung des Complex Instruction Set Computing (CISC) implementiert ist. Die Rechenvorrichtung 600 kann eine oder mehrere CPUs 606 zusätzlich zu einem oder mehreren Mikroprozessoren oder zusätzliche Co-Prozessoren, wie beispielsweise mathematische Co-Prozessoren, umfassen.
Zusätzlich zu oder alternativ zu der(den) CPU(s) 606 kann(können) die GPU(s) 608 ausgestaltet sein, um zumindest einige der computerlesbaren Anweisungen auszuführen, um eine oder mehrere Komponenten der Recheneinrichtung 600 zu steuern, um eine oder mehrere der hier beschriebenen Verfahren und/oder Prozesse durchzuführen. Eine oder mehrere der GPU(s) 608 kann(können) eine integrierte GPU sein (z.B. mit einer oder mehreren der CPU(s) 606), und/oder eine oder mehrere der GPU(s) 608 kann(können) eine diskrete GPU sein. In Ausführungsformen können eine oder mehrere der GPU(s) 608 ein Coprozessor einer oder mehrerer der CPU(s) 606 sein. Die GPU(s) 608 kann(können) von der Recheneinrichtung 600 zum Rendern von Graphiken (z. B. 3D-Graphiken) oder zur Durchführung von Allzweckberechnungen verwendet werden. Die GPU(s) 608 kann(können) beispielsweise für General-Purpose-Computing auf GPUs (GPGPU) verwendet werden. Die GPU(s) 608 kann(können) Hunderte oder Tausende von Kernen aufweisen, die in der Lage sind, Hunderte oder Tausende von Software-Threads gleichzeitig zu verarbeiten. Die GPU(s) 608 kann(können) als Reaktion auf Rendering-Befehle (z. B. Rendering-Befehle von der/den CPU(s) 606, die über eine Host-Schnittstelle empfangen werden) Pixeldaten für Ausgabebilder erzeugen. Die GPU(s) 608 kann(können) einen Graphikspeicher, wie beispielsweise einen Anzeigespeicher, zum Speichern von Pixeldaten oder anderen geeigneten Daten, wie z.B. GPGPU-Daten, aufweisen. Der Anzeigespeicher kann als Teil des Speichers 604 vorhanden sein. Die GPU(s) 608 kann(können) zwei oder mehr GPUs aufweisen, die parallel arbeiten (z.B. über eine Verbindung). Die Verbindung kann die GPUs direkt (z.B. mit NVLINK) oder über einen Schalter (z.B. mit NVSwitch) verbinden. Wenn zusammen kombiniert, kann jede GPU 608 Pixeldaten oder GPGPU-Daten für verschiedene Abschnitte einer Ausgabe oder für verschiedene Ausgaben erzeugen (z.B. eine erste GPU für ein erstes Bild und eine zweite GPU für ein zweites Bild). Jede GPU kann ihren eigenen Speicher aufweisen oder kann den Speicher mit anderen GPUs gemeinsam nutzen.
Zusätzlich zu oder alternativ zu der (den) CPU(s) 606 und/oder der (den) GPU(s) 608 kann(können) die Logikeinheit(en) 920 so konfiguriert sein, dass sie zumindest einige der computerlesbaren Anweisungen ausführt (ausführen), um eine oder mehrere Komponenten der Recheneinrichtung 600 zu steuern, um eine oder mehrere der hier beschriebenen Verfahren und/oder Prozesse durchzuführen. In Ausführungsformen können die CPU(s) 606, die GPU(s) 608 und/oder die Logikeinheit(en) 920 diskret oder gemeinsam eine beliebige Kombination der Verfahren, Prozesse und/oder Teile davon ausführen. Eine oder mehrere der Logikeinheiten 920 kann(können) Teil einer oder mehrerer der CPU(s) 606 und/oder der GPU(s) 608 sein und/oder eine oder mehrere der Logikeinheiten 920 kann(können) diskrete Komponenten sein oder anderweitig außerhalb der CPU(s) 606 und/oder der GPU(s) 608 liegen. In Ausführungsformen können eine oder mehrere der Logikeinheiten 920 ein Coprozessor einer oder mehrerer der CPU(s) 606 und/oder einer oder mehrerer der GPU(s) 608 sein.
Beispiele der Logikeinheit(en) 620 umfassen einen oder mehrere Verarbeitungskerne und/oder Komponenten davon auf, wie z.B. Tensor-Cores (TCs), Tensor Processing Units (TPUs), Pixel Visual Cores (PVCs), Vision Processing Units (VPUs), Graphics Processing Clusters (GPCs), Texture Processing Clusters (TPCs), Streaming Multiprocessors (SMs), Tree Traversal Units (TTUs), Künstliche-Intelligenz-Beschleuniger (AIAs), Deep-Learning-Beschleuniger (DLAs), Arithmetik-Logik-Einheiten (ALUs), anwendungsspezifische integrierte Schaltungen (ASICs), Fließkomma-Einheiten (FPUs), Eingabe/Ausgabe(E/A)-Elemente; Peripheral-Component-Interconnect-Elemente (PCI) oder Peripheral-Component-Interconnect-Express-Elemente (PCIe) und/oder dergleichen.
Die Kommunikationsschnittstelle 610 kann einen oder mehrere Empfänger, Sender und/oder Sender-Empfänger umfassen, die es der Rechenvorrichtung 600 ermöglichen, mit anderen Rechenvorrichtungen über ein elektronisches Kommunikationsnetzwerk, das drahtgebundene und/oder drahtlose Kommunikation umfasst, zu kommunizieren. Die Kommunikationsschnittstelle 610 kann Komponenten und Funktionalität umfassen, um Kommunikation über ein beliebiges einer Anzahl von unterschiedlichen Netzwerken, wie beispielsweise drahtlose Netzwerke (z.B. Wi-Fi, Z-Wave, Bluetooth, Bluetooth LE, ZigBee usw.), drahtgebundene Netzwerke (z.B. Kommunikation über Ethernet), Low-Power-Weitbereichsnetzwerke (z.B. LoRaWAN, SigFox usw.) und/oder das Internet zu ermöglichen.
Die E/A-Ports 612 können es der Rechenvorrichtung 600 ermöglichen, logisch mit anderen Vorrichtungen, einschließlich der E/A-Komponenten 614, der Präsentationskomponente(n) 618 und/oder anderen Komponenten, von denen einigen in der Rechenvorrichtung 600 eingebaut (z.B. integriert) sein können, gekoppelt zu sein. Veranschaulichende E/A-Komponenten 614 umfassen ein Mikrophon, eine Maus, eine Tastatur, einen Joystick, ein Gamepad, einen Spielecontroller, eine Satellitenschüssel, einen Scanner, einen Drucker, eine drahtlose Vorrichtung usw. Die E/A-Komponenten 614 können eine natürliche Benutzer-Schnittstelle (NUI) bereitstellen, die Luftgesten, Sprache oder andere physiologische Eingaben, die von einem Benutzer erzeugt werden, verarbeitet. In einigen Fällen können Eingaben zur weiteren Verarbeitung an ein geeignetes Netzwerkelement übertragen werden. Eine NUI kann jede beliebige Kombination aus Spracherkennung, Styluserkennung, Gesichtserkennung, biometrischer Erkennung, Gestenerkennung sowohl auf dem Bildschirm als auch neben dem Bildschirm, Luftgesten, Kopf- und Augenverfolgung und Berührungserkennung (wie nachstehend ausführlicher beschrieben), einer Anzeige der Rechenvorrichtung 600 zugeordnet sind. Die Rechenvorrichtung 600 kann Tiefenkameras umfassen, wie beispielsweise stereoskopische Kamerasysteme, Infrarotkamerasysteme, RGB-Kamerasysteme, Touchscreen-Technologie und Kombinationen davon zur Gestenerfassung und -erkennung. Zusätzlich kann die Rechenvorrichtung 600 Beschleunigungssensoren oder Gyroskope (z.B. als Teil einer Trägheitsmesseinheit (IMU)) umfassen, die die Erfassung von Bewegungen ermöglichen. In einigen Beispielen kann die Ausgabe der Beschleunigungssensoren oder Gyroskope von der Rechenvorrichtung 600 dazu verwendet werden, immersive erweiterte Realität oder virtuelle Realität zu rendern.
Die Leistungsversorgung 616 kann eine fest verdrahtete Leistungsversorgung, eine Batterieleistungsversorgung oder eine Kombination davon umfassen. Die Leistungsversorgung 616 kann Leistung der Rechenvorrichtung 600 bereitstellen, um den Betrieb der Komponenten der Rechenvorrichtung 600 zu ermöglichen.
Die Präsentationskomponente(n) 618 kann(können) eine Anzeige (z.B. einen Monitor, einen Touchscreen, einen Fernsehbildschirm, eine Heads-up-Anzeige (HUD), andere Anzeigearten oder ein Kombination davon), Lautsprecher und/oder andere Präsentationskomponenten umfassen. Die Präsentationskomponente(n) 618 kann(können) Daten von anderen Komponenten (z.B. den GPU(s) 608, den CPU(s) 606 usw.) empfangen und die Daten (z.B. als ein Bild, Video, Ton) ausgeben.
BEISPIELHAFTE NETZWERKUMGEBUNGEN
Netzwerkumgebungen, die für die Implementierung von Ausführungsformen der Offenbarung geeignet sind, können ein oder mehrere Client-Vorrichtungen, Server, Network Attached Storage (NAS), andere Backend-Vorrichtungen und/oder andere Vorrichtungstypen umfassen. Die Client-Vorrichtungen, Server und/oder andere Vorrichtungstypen (z.B. jedes Gerät) können auf einer oder mehreren Instanzen der Recheneinrichtung(en) 600 aus 6 implementiert sein - z.B. kann jedes Gerät ähnliche Komponenten, Merkmale und/oder Funktionalität der Recheneinrichtung(en) 1100 aufweisen. Außerdem können, wo Backend-Vorrichtungen (z.B. Server, NAS usw.) implementiert sind, die Backend-Vorrichtungen als Teil eines Rechenzentrums 700 umfasst sein, wobei ein Beispiel davon hier ausführlicher mit Bezug zu 7 beschrieben wird.
Komponenten einer Netzwerkumgebung können über ein oder mehrere Netzwerke miteinander kommunizieren, die drahtgebunden, drahtlos oder beides sein können. Das Netzwerk kann mehrere Netzwerke oder ein Netzwerk von Netzwerken aufweisen. Beispielsweise kann das Netzwerk ein oder mehrere Wide Area Networks (WANs), ein oder mehrere Local Area Networks (LANs), ein oder mehrere öffentliche Netzwerke wie das Internet und/oder ein öffentliches Telefonwählnetz (PSTN) und/oder ein oder mehrere private Netzwerke umfassen. Wenn das Netzwerk ein drahtloses Telekommunikationsnetzwerk aufweist, können Komponenten wie eine Basisstation, ein Kommunikationsturm oder sogar Zugangspunkte (sowie auch andere Komponenten) eine drahtlose Verbindung bereitstellen.
Kompatible Netzwerkumgebungen können eine oder mehrere Peer-to-Peer-Netzwerkumgebungen - in diesem Fall darf ein Server nicht in eine Netzwerkumgebung eingebunden sein - und eine oder mehrere Client-Server-Netzwerkumgebungen aufweisen - in diesem Fall können ein oder mehrere Server in eine Netzwerkumgebung eingebunden sein. Bei Peer-to-Peer-Netzwerkumgebungen kann die hier beschriebene Funktionalität in Bezug auf einen oder mehrere Server auf einer beliebigen Anzahl von Client-Vorrichtungen implementiert sein.
Bei mindestens einer Ausführungsform kann eine Netzwerkumgebung eine oder mehrere Cloud-basierte Netzwerkumgebungen, eine verteilte Computerumgebung, eine Kombination davon usw. aufweisen. Eine Cloud-basierte Netzwerkumgebung kann eine Framework-Schicht, einen Job-Scheduler, einen Ressourcenmanager und ein verteiltes Dateisystem aufweisen, das auf einem oder mehreren Servern implementiert ist, die einen oder mehrere Core-Netzwerk-Server und/oder Edge-Server umfassen können. Eine Framework-Schicht kann ein Framework zur Unterstützung der Software einer Softwareschicht und/oder einer oder mehrerer Anwendungen) einer Anwendungsschicht aufweisen. Die Software oder die Anwendung(en) können jeweils webbasierte Service-Software oder -Anwendungen aufweisen. Bei Ausführungsformen kann/können eines oder mehrere der Client-Vorrichtungen die webbasierte Dienstsoftware oder Anwendungen nutzen (z.B. durch Zugriff auf die Dienstsoftware und/oder Anwendungen über eine oder mehrere Anwendungsprogrammierschnittstellen (APIs)). Die Framework-Schicht kann eine Art freies und quelloffenes Software-Framework für Webanwendungen sein, das z.B. ein verteiltes Dateisystem für die Verarbeitung großer Datenmengen (z.B. „Big Data“) verwenden kann, ist aber nicht darauf beschränkt.
Eine Cloud-basierte Netzwerkumgebung kann Cloud-Computing und/oder Cloud-Speicherung bereitstellen, die eine beliebige Kombination der hier beschriebenen Rechen- und/oder Datenspeicherfunktionen (oder einen oder mehrere Teile davon) ausführt. Jede dieser verschiedenen Funktionen kann über mehrere Standorte von zentralen oder Core-Servern aus verteilt sein (z.B. von einem oder mehreren Rechenzentren, die über einen Staat, eine Region, ein Land, den Globus usw. verteilt sein können). Wenn sich eine Verbindung zu einem Benutzer (z.B. ein Client-Gerät) relativ nahe bei einem oder mehreren Edge-Servern befindet, kann/können ein Core-Server zumindest einen Teil der Funktionalität dem/den Edge-Server(n) zuweisen. Eine Cloud-basierte Netzwerkumgebung kann privat (z.B. auf eine einzelne Organisation beschränkt), öffentlich (z.B. für viele Organisationen verfügbar) und/oder eine Kombination davon (z.B. eine hybride Cloud-Umgebung) sein.
Das (die) Client-Gerät(e) kann (können) zumindest einige der Komponenten, Merkmale und Funktionen der hier in Bezug auf 6 beschriebenen beispielhaften Recheneinrichtung(en) 700 aufweisen. Als Beispiel und nicht als Einschränkung kann ein Client-Gerät ausgestaltet sein als ein Personal Computer (PC), ein Laptop-Computer, ein mobiles Gerät, ein Smartphone, ein Tablet-Computer, eine Smart-Uhr, ein tragbarer Computer, ein Personal Digital Assistant (PDA), ein MP3-Player, ein Virtual-Reality-Headset, ein Global Positioning System (GPS) oder - Gerät, ein Video-Player, eine Videokamera, ein Überwachungsgerät oder -system, ein Fahrzeug, ein Boot, ein fliegendes Schiff, eine virtuelle Maschine, eine Drohne, ein Roboter, ein tragbares Kommunikationsgerät, ein Krankenhausgerät, ein Spielgerät oder - system, ein Unterhaltungssystem, ein Fahrzeug-Computersystem, ein Steuergerät für ein eingebettetes System, eine Fernbedienung, ein Gerät, ein Gerät der Unterhaltungselektronik, eine Workstation, ein Edge-Gerät, eine beliebige Kombination dieser abgegrenzten Vorrichtungen oder ein anderes geeignetes Gerät.
Die Offenbarung kann im allgemeinen Kontext von Computercode oder maschinenverwendbaren Befehlen, einschließlich computerausführbarer Befehle, wie z.B. Programmmodule, beschrieben werden, die von einem Computer oder einer anderen Maschine, wie z.B. einem Assistenten für persönliche Daten oder einer anderen in der Hand gehaltenen Einrichtung, ausgeführt werden. Im Allgemeinen beziehen sich Programmmodule, einschließlich Routinen, Programme, Objekte, Komponenten, Datenstrukturen usw., auf einen Code, der bestimmte Aufgaben ausführt oder bestimmte abstrakte Datentypen implementiert. Die Offenbarung kann in einer Vielzahl von Systemkonfigurationen ausgeführt sein, einschließlich in der Hand gehaltenen Einrichtungen, Unterhaltungselektronik, Allzweckcomputern, spezielleren Computervorrichtungen usw. Die Offenbarung kann auch in verteilten Computerumgebungen ausgeführt werden, in denen die Aufgaben von fernverarbeitenden Einrichtungen ausgeführt werden, die durch ein Kommunikationsnetz miteinander verbunden sind.
Wie hier verwendet wird, sollte eine Angabe von „und/oder“ in Bezug auf zwei oder mehr Elemente so interpretiert werden, dass nur ein Element oder eine Kombination von Elementen gemeint ist. Zum Beispiel kann „Element A, Element B und/oder Element C“ nur Element A, nur Element B, nur Element C, Element A und Element B, Element A und Element C, Element B und Element C oder die Elemente A, B und C enthalten. Darüber hinaus kann „mindestens eines von Element A oder Element B“ mindestens eines von Element A, mindestens eines von Element B oder mindestens eines von Element A und mindestens eines von Element B enthalten. Ferner kann „mindestens eines von Element A und Element B“ mindestens eines von Element A, mindestens eines von Element B oder mindestens eines von Element A und mindestens eines von Element B enthalten.
Der Gegenstand der vorliegenden Offenbarung wird hierin spezifisch beschrieben, um gesetzliche Anforderungen zu erfüllen. Die Beschreibung selbst ist jedoch nicht dazu gedacht, den Umfang dieser Offenbarung einzuschränken. Vielmehr haben die Erfinder in Betracht gezogen, dass der beanspruchte Gegenstand auch auf andere Weise ausgestaltet sein könnte, um verschiedene Schritte oder Kombinationen von Schritten, die den in diesem Dokument beschriebenen ähnlich sind, in Verbindung mit anderen gegenwärtigen oder zukünftigen Technologien einzubeziehen. Darüber hinaus, obwohl die Begriffe „Schritt“ und/oder „Block“ hier verwendet werden können, um verschiedene Elemente der eingesetzten Verfahren zu bezeichnen, sollten die Begriffe nicht so ausgelegt werden, dass sie eine bestimmte Reihenfolge unter oder zwischen den verschiedenen hier offengelegten Schritten implizieren, es sei denn, die Reihenfolge der einzelnen Schritte wird ausdrücklich beschrieben.

Claims

Prozessor, umfassend Verarbeitungsschaltungen, um: Anfragedaten zu analysieren, die für eine Benutzeranfrage repräsentativ sind; basierend mindestens teilweise auf dem Analysieren, eine Domänenkennung zu erzeugen, die der Benutzeranfrage entspricht; wenn die Domänenkennung einem Dialogsystem einer offenen Domäne entspricht, die Anfragedaten an das Dialogsystem einer offenen Domäne zu übertragen; wenn die Domänenkennung einem Dialogsystem der geschlossenen Domäne entspricht: Zugreifen, basierend mindestens teilweise auf dem Domänenkennung, auf eine oder mehrere Anfragerichtlinien, die dem Dialogsystem der geschlossenen Domäne entsprechen; basierend mindestens teilweise auf der einen oder mehreren Anfragerichtlinien, eine Anfrage für das Dialogsystem der geschlossenen Domäne unter Verwendung der Anfragedaten zu erzeugen; und die Anfrage an das Dialogsystem der geschlossenen Domäne zu übertragen; Empfangen reagierender Daten von mindestens einem der Dialogsysteme einer offenen Domäne, die auf die Anfragedaten reagieren, oder dem Dialogsystem der geschlossenen Domäne, das auf die Anfrage reagiert; und eine Ausgabe basierend mindestens teilweise auf den reagierenden Daten zu erzeugen.
Prozessor gemäß Anspruch 1, wobei die Verarbeitungsschaltungen ferner: Audiodaten zu empfangen hat, die der Benutzeranfrage entsprechen; und die Anfragedaten basierend mindestens teilweise auf den Audiodaten zu erzeugen hat.
Prozessor gemäß Anspruch 1 oder 2, wobei die Ausgabe mindestens eines von einer Anzeige von Text, welcher den reagierenden Daten entspricht, oder von Audio umfasst, das Audiodaten entspricht, die aus den reagierenden Daten unter Verwendung eines oder mehrerer Text-zu-Sprache Algorithmen erzeugt werden.
Prozessor gemäß Anspruch 1, wobei das eine oder mehrere Anfragerichtlinien das Befüllen eines oder mehrere Eingabeschlitze umfassen, die der Anfrage entsprechen, mit einem oder mehreren Abschnitten der Anfragedaten umfassen.
Prozessor gemäß einem vorangehenden Anspruch, wobei: die eine oder mehrere Anfragerichtlinien das Befüllen einer oder mehrerer Eingabeschlitze umfassen, die der Anfrage entsprechen, mit Informationen von einen Dialogzustands-Tracker; und der Dialogzustand-Tracker einen Kontext eines laufenden Gesprächs einschließlich der Benutzeranfrage verfolgt.
Prozessor gemäß einem vorangehenden Anspruch, wobei, wenn die Domänenkennung dem Dialogsystem der geschlossenen Domäne entspricht, die reagierenden Daten, die von dem Dialogsystem der geschlossenen Domäne empfangen werden, an das Dialogsystem der offenen Domäne übertragen werden, um dem Dialogsystem der offenen Domäne zu ermöglichen, einen Kontext eines laufenden Gesprächs beizubehalten, das die Benutzeranfrage und die Ausgabe umfasst.
Prozessor gemäß einem vorangehenden Anspruch, wobei, wenn die Domänenkennung dem Dialogsystem der geschlossenen Domäne entspricht, die Anfragedaten an das Dialogsystem der offenen Domäne übertragen werden, um dem Dialogsystem der offenen Domäne zu ermöglichen, einen Kontext eines laufenden Gesprächs beizubehalten, das die Benutzeranfrage umfasst.
Prozessor gemäß einem vorangehenden Anspruch, wobei das Dialogsystem einer offenen Domäne trainiert wird, um Antworten in Richtung von Domänen vorzuspannen, die mindestens einem der Dialogsysteme einer geschlossenen Domäne oder einem oder mehreren zusätzlichen Dialogsystemen der geschlossenen Domäne zugeordnet sind.
Prozessor gemäß einem vorangehenden Anspruch, wobei die Prozessor in mindestens einem der Folgenden umfasst ist: einem System für eine autonome oder semiautonome Maschine; einem System, das unter Verwendung einer Kantenvorrichtung implementiert ist; ein System, das unter Verwendung eines Roboters implementiert ist; einem System, das eine oder mehrere virtuelle Maschinen (VMs) aufnimmt; einem System, das mindestens teilweise in einem Rechenzentrum implementiert ist; oder einem System, das mindestens teilweise unter Verwendung von Cloud-Rechenressourcen implementiert ist.
System, umfassend: eine oder mehrere Verarbeitungseinheiten; und eine oder mehrere Speichereinheiten, um Anweisungen zu speichern, die, wenn durch die eine oder mehreren Verarbeitungseinheiten ausgeführt, die eine oder mehreren Verarbeitungseinheiten veranlassen, Operationen auszuführen, umfassend: Analysieren erster Anfragedaten, die für eine Benutzeranfrage repräsentativ sind; basierend mindestens teilweise auf dem Analysieren, Bestimmen einer Domänenkennung, die der Benutzeranfrage entspricht, wobei die Domänenkennung einem oder mehreren eines Dialogsystems einer offenen Domäne oder eines Dialogsystems einer geschlossenen Domäne entspricht; Zugreifen auf eine oder mehrere Anfragerichtlinien, die dem Dialogsystem der geschlossenen Domäne entspricht, die bestimmt ist, der Domänenkennung zugeordnet zu sein; basierend mindestens teilweise auf der einen oder mehreren Anfragerichtlinien, Erzeugen einen Anfrage für das Dialogsystem der geschlossenen Domäne unter Verwendung der ersten Anfragedaten; Senden der Anfrage an das Dialogsystem der geschlossenen Domäne; Empfangen zweiter Anfragedaten von dem Dialogsystem der geschlossenen Domäne, das auf die Anfrage reagiert; Senden der zweiten Anfragedaten an das Dialogsystem der offenen Domäne; und Erzeugen einer Ausgabe basierend mindestens teilweise auf den zweiten Anfragedaten, die von dem Dialogsystem der geschlossenen Domäne empfangen werden.
System gemäß Anspruch 10, wobei die Operationen ferner umfassen: Senden der ersten Anfragedaten an das Dialogsystem der offenen Domäne, wobei die ersten Anfragedaten und die zweiten Anfragedaten das Dialogsystem der offenen Domäne veranlassen, einen Dialogzustands-Tracker zu aktualisieren, der durch das Dialogsystem der offenen Domäne beibehalten wird.
System gemäß Anspruch 10 oder 11, wobei die Operationen ferner umfassen: Empfangen von Audiodaten, die der Benutzeranfrage entsprechen; und Erzeugen der ersten Anfragedaten basierend mindestens teilweise auf Audiodaten.
System gemäß einem der Ansprüche 10 bis 12, wobei die Ausgabe mindestens eines von einer Anzeige von Text, welches der zweite Anfragedaten entspricht, oder von Audio entspricht, das von der zweiten Anfragedaten unter Verwendung eines oder mehrerer Text-zu-Sprache Algorithmen erzeugt wird.
System gemäß einem der Ansprüche 10 bis 13, wobei die eine oder mehreren Anfragerichtlinien das Befüllen eines oder mehrerer Eingabeschlitze, die der Anfrage entsprechen, mit einem oder mehreren Abschnitten der ersten Anfragedaten umfasst.
System gemäß einem der Ansprüche 10 bis 14, wobei: die eine oder mehrere Anfragerichtlinien das Befüllen einer oder mehrerer Eingabeschlitze, die der Anfrage entsprechen, mit Informationen von einem Dialogzustands-Tracker umfassen; und der Dialogzustands-Tracker einen Kontext eines laufenden Gesprächs verfolgt, das die Benutzeranfrage umfasst.
System gemäß einem der Ansprüche 10 bis 15, wobei das Dialogsystem der offenen Domäne trainiert wird, um Antworten in Richtung von Domänen vorzuspannen, die mindestens einem Dialogsystem der geschlossenen Domäne oder einem oder mehreren zusätzlichen Dialogsystemen der geschlossenen Domäne zugeordnet sind.
System gemäß einem der Ansprüche 10 bis 16, wobei das System in mindestens einem der Folgenden umfasst ist: einem System für eine autonome oder semiautonome Maschine; einem System, das unter Verwendung einer Kantenvorrichtung implementiert ist; einem System, das unter Verwendung eines Roboters implementiert ist; einem System, das eine oder mehrere virtuelle Maschinen (VMs) aufnimmt; einem System, das mindestens teilweise in einem Rechenzentrum implementiert ist; oder einem System, das mindestens teilweise unter Verwendung von Cloud-Rechenressourcen implementiert ist.
Verfahren, umfassend: Analysieren von Textdaten, die für eine Benutzeranfrage repräsentativ sind; basierend mindestens teilweise auf dem Analysieren, Erzeugen einer Domänenkennung, die der Benutzeranfrage entspricht; wenn die Domänenkennung einem Dialogsystem einer offenen Domäne entspricht, Übertragen der Textdaten an das Dialogsystem der offenen Domäne; wenn die Domänenkennung einem Dialogsystem der geschlossenen Domäne entspricht: Zugreifen, basierend mindestens teilweise auf die Domänenkennung, auf eine oder mehrere Anfragerichtlinien, die dem Dialogsystem der geschlossenen Domäne entsprechen; basierend mindestens teilweise auf der einen oder mehreren Anfragerichtlinien, Erzeugen einer Anfrage für das Dialogsystem der geschlossenen Domäne unter Verwendung der Textdaten; und Übertragen der Anfrage an das Dialogsystem der geschlossenen Domäne; Empfangen reagierender Textdaten von mindestens einem Dialogsystems einer offenen Domäne oder dem Dialogsystem der geschlossenen Domäne; und Erzeugen einer Ausgabe basierend mindestens teilweise auf den reagierenden Textdaten.
Verfahren gemäß Anspruch 18, ferner umfassend: Empfangen von Audiodaten, die der Benutzeranfrage entsprechen; und Erzeugen einer Textdarstellung basierend mindestens teilweise auf Audiodaten.
Verfahren gemäß Anspruch 18 oder 19, wobei die eine oder mehrere Anfragerichtlinien das Befüllen eines oder mehrerer Eingabeschlitze, die der Anfrage entsprechen, mit einem oder mehreren Abschnitten der Textdaten umfassen.
Verfahren gemäß einem der Ansprüche 18 bis 20, wobei die eine oder mehrere Anfragerichtlinien das Befüllen eines oder mehrerer Eingabeschlitze, die der Anfrage entsprechen, mit Informationen von einen Dialogzustands-Tracker umfassen, wobei der Dialogzustands-Tracker einen Kontext eines laufenden Gesprächs verfolgt, das die Benutzeranfrage umfasst.
Verfahren gemäß einem der Ansprüche 18 bis 21, wobei, wenn die Domänenkennung dem Dialogsystem der geschlossenen Domäne entspricht, die reagierenden Textdaten, die von dem Dialogsystem der geschlossenen Domäne empfangen werden, an das Dialogsystem der offenen Domäne übertragen werden, um dem Dialogsystem der offenen Domäne zu ermöglichen, einen Kontext eines laufenden Gesprächs beizubehalten, das die Benutzeranfrage und die Ausgabe umfasst.