DE112018007578T5

DE112018007578T5 - Dialogsystem, das zu Semantik-Verständnis-Mapping zwischen Benutzerabsichten und Maschinenservices fähig ist

Info

Publication number: DE112018007578T5
Application number: DE112018007578.8T
Authority: DE
Inventors: Jilei Tian; Yang Cao
Original assignee: Bayerische Motoren Werke AG
Current assignee: Bayerische Motoren Werke AG
Priority date: 2018-05-07
Filing date: 2018-05-07
Publication date: 2021-07-01
Also published as: CN111566728B; US20210249001A1; CN111566728A; US11984115B2; WO2019214798A1

Abstract

Ein Dialogsystem und ein Intelligent Personal Assistant, der zu Semantik-Verständnis-Mapping zwischen Benutzerabsichten und Maschinenservices fähig ist. Das Dialogsystem enthält eine Schnittstelle, um eine Sprach- oder Textanfrage von einem Benutzer zu empfangen. Die Semantik der Anfrage, die zumindest ein Element von Einheiten, Absicht oder Kontext enthält, wird aus der Anfrage des Benutzers extrahiert. Eine Sequenz von Aktionsmerkmalen wird auf der Basis der extrahierten Semantik ausgewählt. Eine Sequenz von Anwendungsprogrammierschnittstellen (APIs), die der Sequenz von Aktionsmerkmalen entspricht, wird dann ausgeführt, um ein Ergebnis zu erzeugen. Ein Aktionssequenzoptimierer kann die Sequenz von Aktionsmerkmalen auf der Basis der Benutzerkonfiguration optimieren. Die Beispiele stellen eine technische Lösung bereit, um ein reicheres Semantik-Verständnis-Mapping zwischen Benutzerabsichten und verfügbaren APIs zu modellieren, welche die Benutzererfahrung in dem Sprachdialogsystem als Kern des persönlichen Assistenten erheblich verbessern werden.

Description

Technisches Gebiet
Beispiele betreffen ein Dialogsystem, insbesondere ein Dialogsystem und einen Intelligent Personal Assistant (IPA), der zu Semantik-Verständnis-Mapping zwischen Benutzerabsichten und Maschinenservices fähig ist.
Hintergrund
Der Intelligent Personal Assistant (IPA) entwickelt sich zu einem Gegenstand von weit verbreiteten Anwendungen und Services. Ein Sprachdialogsystem, das bestimmt ist, sich mit Menschen zu unterhalten, spielt eine Schlüsselrolle in dem IPA. 1 zeigt ein konventionelles Dialogsystem 100. Ein aktuelles Dialogsystem 100 verwendet Natural Language Understanding (NLU) 102, um eine Benutzerabsicht durch Dialoginteraktion zu finden. Ein Dialogrichtlinienmodul 106 wählt eine richtige Reaktion gemäß einem aktuellen Dialogzustand. Das Sprachdialogsystem 100 erfordert eine Komponente 104, die verfolgen kann, was in einem Dialog geschehen ist, indem sie Systemausgaben, Benutzersprache, Kontext von früheren Runden und andere externe Informationen einbezieht. Die Ausgabe des Dialogzustandsmoduls 104 wird dann durch das Dialogrichtlinienmodul 106 verwendet, um zu entscheiden, welche Aktion das System als Nächstes ergreifen sollte. Das Dialogzustandsmodul 104 dient im Wesentlichen zum Verwalten des Zustands und der endgültigen Leistung eines kompletten Systems. Sind die erforderlichen Informationen unvollständig, erzeugt das System 100 einen Satz, um weitere Informationen anzufordern. Wenn alle Informationen bereit sind, benutzt das System 100 eine vordefinierte Aktionsvorlage zum Auswählen einer richtigen Aktion 108, wie z. B. Abfragen einer Datenbank, Aufrufen von entsprechenden Service-Anwendungsprogrammierschnittstellen (APIs) und/oder Ausführen einer Steueraktion.
Ein aktuelles Dialogsystem ist in der Lage, den Service einfach mit nur einer Aktion zu handhaben, zum Beispiel mit einer Abfrage von einer Datenbank, einem API-Aufruf, oder Anfordern weiterer Informationen von dem Benutzer. In konkreten Fällen erwartet der Benutzer, als Mensch mit dem IPA zu kommunizieren, mit reicherer Semantik, die möglicherweise mehrere APIs für Servicekomposition erfordert.
Obwohl es eine Vielzahl von verfügbaren Webservice-APIs gibt, müssen in dem aktuellen Dialogsystem Informationen schrittweise abgefragt werden, um reichere Semantik in typischer natürlicher menschlicher Kommunikation zu erhalten, was sehr ungünstig ist. Es wäre unpraktisch, alle gültigen Service-API-Kombinationen für ein großes System erschöpfend aufzulisten, da die Anzahl von gültigen API-Kombinationen enorm sein kann. In NLU ist die Semantik für menschliche Kommunikationszwecke festgelegt, weshalb sie für Kommunikation und Verstehen durch Maschinen, z. B. API, nicht optimal ist.
Kurzfassung
Die hierin offenbarten Beispiele bieten neuartige technische Lösungen, um reicheres Semantik-Verständnis-Mapping zwischen Benutzerabsichten und Kontext und verfügbaren Maschinenservices (z. B. APIs) zu modellieren. Die Beispiele werden die Benutzererfahrung in einem Dialogsystem, wie z. B. einem Sprachdialogsystem, als Kern von Personal Assistant-Anwendungen erheblich verbessern. Die Beispiele bieten auch eine intelligente Servicekomposition, z. B. Aufbauen eines Dialogsystems, das mehrere APIs als eine Antwortaktion auswählen kann.
Das Dialogsystem kann, über eine Schnittstelle, eine Sprach- oder Textanfrage von einem Benutzer empfangen. Die Semantik der Anfrage, die zumindest ein Element von Einheiten, Absicht oder Kontext enthält, kann aus der Anfrage extrahiert werden. Eine Sequenz von Aktionsmerkmalen kann auf der Basis der extrahierten Semantik durch Verwenden eines rekurrenten Neuronalnetzes oder eines beliebigen anderen Maschinenlernsystems ausgewählt werden. Die Sequenz von Aktionsmerkmalen kann als Ressourcengrafik organisiert werden. Eine Sequenz von APIs, die der Sequenz von Aktionsmerkmalen entspricht, kann dann ausgeführt werden. Ein Aktionssequenzoptimierer kann die Sequenz von Aktionsmerkmalen auf der Basis der Benutzerkonfiguration optimieren.
Das Dialogsystem kann ferner einen Aktionssequenzoptimierer enthalten, der dazu ausgelegt ist, die Sequenz der Aktionsmerkmale auf der Basis der Benutzerkonfiguration zu optimieren. Die Anfrage kann eine Sprachanfrage sein, und die Schnittstelle kann einen Spracherkenner enthalten, der dazu ausgelegt ist, eine Sprachanfrage in eine Textzeichenfolge umzuwandeln. Zusätzlich oder alternativ dazu kann die Anfrage als eine Textanfrage empfangen werden. Die Sequenz von Aktionsmerkmalen kann als Ressourcengrafik organisiert werden. Der API-Mapper kann mit einem rekurrenten Neuronalnetz implementiert werden. Das rekurrente Neuronalnetz kann durch Umwandeln von Reden und Antworten in Merkmale, Organisieren der Merkmale der Reden und entsprechenden Antworten als eingegebenes Sequenz-zu-Ziel-Sequenzpaar, und Durchführen von überwachtem Sequenz-zu-Sequenz-Training trainiert werden, um Parameter des rekurrenten Neuronalnetzes zu trainieren und zu optimieren. Mehrere APIs können als Antwort auf die Anfrage aufgerufen werden. Die Anfrage kann von einem Benutzergerät empfangen werden.
Im Einklang mit einem weiteren Aspekt wird ein Verfahren des Implementierens eines Dialogsystems bereitgestellt. Das Verfahren umfasst Folgendes:

Empfangen einer Anfrage von einem Benutzer,
Extrahieren der Semantik der Anfrage, die zumindest ein Element von Einheiten, Absicht oder Kontext der Anfrage enthält,
Auswählen einer Sequenz von Aktionsmerkmalen auf der Basis der extrahierten Semantik, und
Ausführen einer Sequenz von Maschinenservices, die der Sequenz von Aktionsmerkmalen entspricht. Das Verfahren kann Optimieren der Sequenz von Aktionsmerkmalen auf der Basis der Benutzerkonfiguration beinhalten. Die Anfrage kann eine Sprachanfrage sein, und die Sprachanfrage kann in eine Textzeichenfolge umgewandelt werden. Die Anfrage kann als Textanfrage empfangen werden. Die Sequenz von Aktionsmerkmalen kann als Ressourcengrafik organisiert werden. Die Sequenz von Aktionsmerkmalen kann durch ein rekurrentes Neuronalnetz ausgewählt werden. Das rekurrente Neuronalnetz kann durch Umwandeln von Reden und Antworten in Merkmale, Organisieren der Merkmale der Reden und entsprechenden Antworten als eingegebenes Sequenz-zu-Ziel-Sequenzpaar, und Durchführen von überwachtem Sequenz-zu-Sequenz-Training trainiert werden, um Parameter des rekurrenten Neuronalnetzes zu trainieren und zu optimieren. Mehrere Anwendungsprogrammierschnittstellen können als Antwort auf die Anfrage aufgerufen werden. Die Anfrage kann von einem Benutzergerät empfangen werden.

Im Einklang mit noch einem weiteren Aspekt wird ein nicht-transitorischer maschinenlesbarer Speicher bereitgestellt. Der maschinenlesbare Speicher kann maschinenlesbare Anweisungen enthalten, um bei Ausführung jedes hierin offenbarte Verfahren zu implementieren.
Figurenliste
Einige Vorrichtungen und/oder Verfahren werden im Folgenden nur anhand von Beispielen und unter Bezugnahme auf die begleitenden Figuren beschrieben, in denen

1 ein konventionelles Dialogsystem zeigt;
2 einen beispielhaften Prozess von semantischem Parsing von der Spracheingabe eines Benutzers zeigt;
3 ein Beispiel eines API-Diagramms und Merkmalsextraktion im Einklang mit einem Aspekt zeigt;
4 ein Blockdiagramm eines beispielhaften Dialogsystems im Einklang mit einem Aspekt ist, und
5 ein Blockdiagramm eines beispielhaften Systems zum Implementieren des Dialogsystems im Einklang mit den hierin offenbarten Beispielen ist.

Detaillierte Beschreibung
Verschiedene Beispiele werden nun unter Bezugnahme auf die begleitenden Zeichnungen, in denen einige Beispiele dargestellt sind, ausführlicher beschrieben. In den Figuren kann die Dicke von Linien, Schichten und/oder Bereichen der Klarheit halber übertrieben sein.
Dementsprechend, während weitere Beispiele zu verschiedenen Modifikationen und alternativen Formen fähig sind, werden einige spezielle Beispiele davon in den Figuren gezeigt und anschließend ausführlich beschrieben. Diese detaillierte Beschreibung beschränkt jedoch weitere Beispiele nicht auf die beschriebenen speziellen Formen. Weitere Beispiele können alle Modifikationen, Äquivalente und Alternativen, die in den Geltungsbereich der Offenbarung fallen, abdecken. Gleiche Nummern beziehen sich in der ganzen Beschreibung der Figuren auf gleiche oder ähnliche Elemente, die identisch oder in modifizierter Form implementiert werden können, wenn sie miteinander verglichen werden, während die gleiche oder eine ähnliche Funktionalität bereitgestellt wird.
Es versteht sich, dass, wenn ein Element als mit einem anderen Element „verbunden“ oder „gekoppelt“ bezeichnet wird, die Elemente direkt oder über ein oder mehrere dazwischenliegende Elemente verbunden oder gekoppelt sein können. Wenn zwei Elemente A und B mit einem „oder“ kombiniert werden, ist dies so zu verstehen, dass alle möglichen Kombinationen offenbart werden, d. h. nur A, nur B sowie A und B. Eine alternative Formulierung für die gleichen Kombinationen ist „zumindest eines von A und B“. Das Gleiche gilt für Kombinationen von mehr als 2 Elementen.
Die hierin zum Zwecke des Beschreibens spezieller Beispiele verwendete Terminologie ist nicht beabsichtigt, für weitere Beispiele einschränkend zu sein. Wann immer eine Singularform, wie z. B. „ein, eine, eines“ und „der, die, das“, verwendet wird und die Verwendung nur eines einzelnen Elements weder explizit noch implizit als obligatorisch definiert ist, können weitere Beispiele auch Pluralelemente verwenden, um die gleiche Funktionalität zu implementieren. Ebenso, wenn eine Funktionalität anschließend als unter Verwendung mehrerer Elemente implementiert beschrieben wird, können weitere Beispiele die gleiche Funktionalität unter Verwendung eines einzelnen Elements oder einer einzelnen Verarbeitungseinheit implementieren. Es versteht sich ferner, dass die Ausdrücke „umfasst“, „umfassend“, „enthält“ und/oder „enthaltend“, wenn sie benutzt werden, das Vorhandensein der genannten Merkmale, Ganzzahlen, Schritte, Operationen, Prozesse, Handlungen, Elemente und/oder Komponenten angeben, aber nicht das Vorhandensein oder die Hinzufügung von ein oder mehreren Merkmalen, Ganzzahlen, Schritten, Operationen, Prozessen, Handlungen, Elementen, Komponenten und/oder eine beliebige Gruppe davon ausschließen.
Wenn nicht anders definiert, werden alle Ausdrücke (einschließlich technischer und wissenschaftlicher Ausdrücke) hierin in ihrer normalen Bedeutung der Technik, zu denen die Beispiele gehören, verwendet.
Die hierin offenbarten Beispiele bieten neuartige technische Lösungen, um reicheres Semantik-Verständnis-Mapping zwischen Benutzerabsichten und Kontext und verfügbaren Maschinenservices (z. B. APIs) zu modellieren. Die Beispiele werden die Benutzererfahrung in einem Dialogsystem, wie z. B. einem Sprachdialogsystem, als Kern von Personal Assistant-Anwendungen erheblich verbessern. Als allgemeiner Rahmen können die hierin offenbarten Beispiele auf beliebige Anwendungen angewandt werden, um menschliche Semantik direkt auf Maschinenservices abzubilden.
Die Beispiele bieten auch eine intelligente Servicekomposition, z. B. Aufbauen eines Dialogsystems, das mehrere Maschinenservices (z. B. APIs ) als eine Antwortaktion auswählen kann.
2 zeigt einen beispielhaften Prozess von semantischem Parsing von der Spracheingabe eines Benutzers. Ein Benutzer äußert eine Sprachanfrage (z. B. „Such KFC“). Ein Spracherkennungsmodul (z. B. Cognitive Service) wandelt die Spracheingabe des Benutzers in eine Textzeichenfolge um. Ein Semantikverständnismodul (z. B. Microsoft Language Understanding Intelligent Service (LUIS)) kann die Textzeichenfolge in menschliche Semantik, wie z. B. Einheit, Absicht oder dergleichen, aufgliedern. Eine API (z. B. HERE Maps API, usw.) kann dann aufgerufen werden, um eine Ausgabe zu erzeugen. In diesem Beispiel können Breitengrad, Längengrad, Entfernung oder andere Parameter des Standorts des KFC-Ladens ausgegeben werden.
Üblicherweise wird das Semantikmodell normal mit Hilfe eines Etiketts (z. B. Einheit und Absicht) trainiert, das auf der Basis der Semantik durch einen Menschen vordefiniert wird. Um mit Service-APIs/Maschinenservices auf der Basis der menschlichen Semantik umzugehen, wäre die Leistung optimal, wenn sie direkt mit verfügbaren Service-APIs/Maschinenservices gekennzeichnet werden würde. Das Mapping von menschlicher Semantik auf Maschinenservices kann optimal laufen, wenn das System direkt mit den verfügbaren Services trainiert wird. Außerdem können häufig mehrere APIs/Maschinenservicekompositionen benötigt werden, um die einzelne Anfrage des Benutzers, die durch einen natürlichen menschlichen Satz oder eine Phrase repräsentiert wird, zu erfüllen. Nachdem neue Service-APIs/Maschinenservices erzeugt oder existierende APIs/Maschinenservices modifiziert oder entfernt worden sind, müssen die Modelle adaptiv trainiert werden. Im Folgenden werden die Ausdrücke „API“ und „Maschinenservices“ austauschbar verwendet.
In hierin offenbarten Beispielen kann das Dialogsystem direkt auf API-Sequenzauswahl eingelernt und trainiert werden, anstatt durch menschliche Semantikdefinition gekennzeichnet zu werden.
In Beispielen können APIs und Aktionen als Diagramm strukturiert werden, z. B. ein Resource Description Framework (RDF)-Diagramm, und mehrere API-Aufrufe können als Merkmale unter Verwendung des Diagramms codiert werden. Jede API kann in einem Web Service Description Language (WSDL) Extensible Mark-up Language (XML)-Format geschrieben werden, das Eingangsparameter, Ausgangsparameter, Beschreibung usw. enthält. WSDL ist eine Schnittstellendefinitionssprache auf XML-Basis, die zum Beschreiben der Funktionalität verwendet wird, die von einem Webdienst geboten wird. Eine Antwort zur Bestätigung oder eine weitere Frage kann als eine spezielle API behandelt werden. Eine Art von Antwort kann einer API entsprechen.
Das RDF-Diagramm wird mit Knoten und Kanten (d. h. Verbindungen) erstellt. In Beispielen, beim Erstellen des RDF-Diagramms, ist eine API ein Knoten, und eine Verbindung (d. h. Beziehung) zwischen APIs wird definiert. Beispielsweise kann eine Verbindung von „API i“ zu „API j“ definiert werden, wenn eine der Ausgaben von „API i“ mit einer der Eingaben von „API j“ übereinstimmt. Diagrammknoten können hinzugefügt werden, um unterschiedliche Arten von Direkteingaben von einem Benutzer und nicht von Ergebnissen eines beliebigen API-Aufrufs zu repräsentieren (wie z. B. Namenseinheiten, Benutzer-ID usw.), die als eine spezielle API behandelt werden können. Jedem Knoten in dem Diagramm wird ein eindeutiger Index gegeben. Inferenzregeln werden erzeugt. Beispielsweise, damit ein API-Aufruf gültig ist, müssen alle erforderlichen Eingangsparameter präsentiert werden.
Merkmalsextraktion wird benötigt, um eine Maschinen-API-Aufrufsequenz in Merkmale umzuwandeln, die durch den maschinellen Lernalgorithmus modelliert werden können. Während der Trainingsphase wird das Mapping von dem Merkmal der menschlichen Semantik auf das Merkmal der API-Aufrufsequenz gelernt. Merkmalsextraktion wird durchgeführt, um das Mapping von menschlicher Semantik auf Maschinen-API zu trainieren. Für einen einzelnen API-Aufruftyp werden Indexe von Eingangsparametern und der Index des API-Aufrufs als Merkmal extrahiert. Mehrfache API-Aufrufe werden als eine Sequenz von Merkmalen einzelner API-Aufrufe behandelt, d. h. Merkmale eines ersten API-Aufrufs, Merkmale eines zweiten API-Aufrufs, ..., die Merkmale des letzten API-Aufrufs.
In Realität sind möglicherweise mehrere Aktionen für eine Reaktion notwendig. Wenn beispielsweise ein Benutzer das System auffordert „Führe mich zu einem Laden, damit ich auf dem Heimweg Milch kaufen kann“, muss das System die Wohnadresse kennen und dann eine oder mehrere Route(n) zur Wohnung finden, dann muss es einen Laden für Milch auf der (den) gefundenen Route(n) suchen und dann eine Ladenadresse zu dem Navigationssystem senden. Alle obigen Informationen können von verschiedenen APIs erhalten werden. Beispielsweise kann die Wohnadresse des Benutzers von einer API abgefragt werden, die eine Adresse auf der Basis einer Benutzer-ID ausgibt (z. B. eine benutzergelernte Ziel-API), eine Route zur Wohnung kann von einer API abgefragt werden, die Routing-Informationen auf der Basis einer gegebenen Adresse ausgibt (z. B. eine Persönliche Route-API), und ein Laden entlang der Route kann von einer Ortssuche-API erhalten werden (z. B. HERE Places API). Die „HERE Places API“ ist eine API, die es gestattet, Applikationen zu erstellen, wo Benutzer nach Orten suchen und detaillierte Informationen über ausgewählte Orte erhalten können. Eine Fahrzeugkommunikations-API kann den Ladenstandort (z. B. ferngesteuert über Cloud) senden, um die Navigation im Fahrzeug einzustellen. Der Begriff „Fahrzeug“ schließt jede Art von Transportmittel ein, unter anderem auch ein Auto, einen Bus, einen Lastwagen, ein Sport Utility Vehicle, ein Wohnmobil, ein Boot, ein Motorrad oder dergleichen.
3 zeigt ein Beispiel eines API-Diagramms und Merkmalsextraktion im Einklang mit einem Aspekt. Für die beispielhafte obige Aufforderung „Führe mich zu einem Laden, damit ich auf dem Heimweg Milch kaufen kann“ ist die API-Aufrufsequenz eventuell wie folgt: Gelerntes Ziel-API → Persönliche Route-API → Ortssuche-API → Fahrzeugkommunikations-API.
Die Benutzeridentität API 302 kann eine Benutzer-ID für einen gegebenen Benutzer ausgeben. Die Gelerntes Ziel-API 304 kann eine Adresse (z. B. eine Wohnadresse) der gegebenen Benutzer-ID ausgeben. Die Persönliche Route-API 306 kann Routing-Informationen für die Adresse ausgeben, die von der Gelerntes Ziel-API 304 bereitgestellt wurde (in diesem Beispiel Routing-Informationen für die Wohnung). Die Kategorie-API 308 kann Kategorieinformationen für eine Eingabe ausgeben (in diesem Beispiel die Kategorie des Ladens zum Kaufen von Milch, z. B. Lebensmittel). Die Ortssuche-API 310 kann entlang der durch die Persönliche Route-API 306 bereitgestellten Route einen Ort suchen, der zu der durch die Kategorie-API 304 bereitgestellten Kategorie gehört (in diesem Beispiel die Standortinformationen des gefundenen Ladens entlang der Route zur Wohnung). Die Fahrzeugidentitäts-API 312 kann eine Fahrzeug-ID ausgeben. Die Fahrzeugkommunikations-API 314 kann die durch die Ortssuche-API 310 bereitgestellten Standortinformationen zu dem durch die Fahrzeugidentitäts-API 312 bereitgestellten Fahrzeug senden.
In diesem Beispiel kann die zugeordnete Merkmalssequenz wie folgt sein: 2, 100, 2, 101, 3, 102, 1, 103, d. h. (Benutzeridentität) → (Zu Gelerntes Ziel-API) → (Benutzeridentität, Von Gelerntes Ziel-API) → (Zu Persönliche Route-API) → (Kategorie, Von Persönliche Route-API) → (Zu Ortssuche-API) → (Fahrzeugidentität, Von Ortssuche-API) → (Zu Fahrzeugkommunikations- API).
4 ist ein Blockdiagramm eines beispielhaften Dialogsystems 400 im Einklang mit einem Aspekt. Das System 400 enthält eine Schnittstelle 402, um mit einem Benutzer zu kommunizieren (z. B. durch Sprache, Text usw.). Ein Spracherkenner 404 wandelt die Sprache eines Benutzers in eine Textzeichenfolge um. Die Anfrage eines Benutzers kann durch Text (z. B. eine Textnachricht, eine E-Mail usw.) empfangen werden. Ein Semantikextraktor 406 extrahiert die Semantik der Benutzeranfrage (z. B. Absicht, Kontext, Einheiten der Anfrage usw.) aus der Textzeichenfolge. Die Ausgaben des Spracherkenners 402 und des Semantikextraktors 404 sind Textsequenzen, die in hochdimensionalen Räumen eingebettet sein können. Beispielsweise kann der Spracherkenner 402 Spracheinbettung direkt ausgeben, die mit Texteinbettung als Merkmal kombiniert werden kann. Die Einbettungsmerkmalssequenzen sind Eingaben des API-Mappers 408. Einbettung ist die kollektive Bezeichnung für einen Satz von Sprachmodellierungs- und Merkmalslerntechniken in natürlicher Sprachverarbeitung, bei der Wörter oder Phrasen aus dem Vokabular Vektoren von realen Zahlen zugeordnet werden, die die algorithmische Operation oder Berechnung erleichtern.
Ein API-Mapper 408 (z. B. ein rekurrentes Neuronalnetz (RNN)-Modul, ein Reinforcement Learning-Modul oder ein beliebiges Maschinenlernmodul) kann verwendet werden, um die Dialogrichtlinienauswahl auf der Basis der menschlichen Semantik der Benutzeranfrage zu modellieren. Die Ausgabe des API-Mappers 408 sind Aktionsmerkmalssequenzen (z. B. die Merkmalssequenz in 3: (Benutzeridentität) → (Zu Gelerntes Ziel-API) → (Benutzeridentität, Von Gelerntes Ziel-API) → (Zu Persönliche Route-API) → (Kategorie, Von Persönliche Route-API) → (Zu Ortssuche-API) → (Fahrzeugidentität, Von Ortssuche-API) → (Zu Fahrzeugkommunikations-API)). Im Gegensatz zu vorwärtsgekoppelten Neuronalnetzen können RNNs ihren internen Zustand (Speicher) verwenden, um Sequenzen von Eingaben, die für das Lernziel geeignet sind, zu verarbeiten, in diesem Fall das Semantikmapping zum Finden der optimalen Servicesequenz, mit einer variablen Länge, um den Bedarf eines Benutzers anzusprechen.
Der Aktionssequenzoptimierer 410 kann Inferenzkapazität des RDF-Diagramms verwenden, um fehlende Teile der Merkmalssequenz zu finden. Wenn beispielsweise einige der erforderlichen Eingaben für einen API-Aufruf fehlen, kann der Aktionssequenzoptimierer 410 die fehlenden Eingaben finden und die Sequenz vervollständigen. Der Aktionssequenzoptimierer 410 kann den API-Aufruf gemäß den Benutzerkonfigurationen optimieren. Beispielsweise können für eine API mehrere alternative APIs von anderen Anbietern vorhanden sein. Der Aktionssequenzoptimierer 410 kann diese gemäß den Benutzerkonfigurationen durch die kostengünstigste oder leistungsstärkste Alternative ersetzen. Das API-Aufrufmodul 412 führt dann eine Sequenz von APIs aus, um eine Antwort 414 für den Benutzer zu erzeugen.
Das Dialogsystem 400 kann in einem Benutzergerät (z. B. einem Mobiltelefon, einem Tablet, einem tragbaren Benutzergerät, einem Personal Computer, einem Laptop usw.) implementiert werden, und die Aktion kann über ein Netzwerk (d. h. Cloud) ferngesteuert zu einem Zielgerät (z. B. einem Fahrzeug) gesendet werden. Alternativ dazu kann das Dialogsystem in dem Zielsystem (z. B. in einem Fahrzeug) enthalten sein.
Die Komponenten des Dialogsystems 400 können für Optimierung trainiert werden. Daten werden zum Training gesammelt. Die Trainingsdatenbank sollte genügend Proben enthalten, die durch mehrfache API-Aufrufstypen gekennzeichnet sind. Die Daten können anfänglich von manuell gekennzeichneten Daten verbunden werden, z. B. überwachtes oder halbüberwachtes Training.
Der API-Mapper 408 kann trainiert werden, indem zuerst alle Spracheingaben und Antworten in Merkmale umgewandelt werden, wie oben beschrieben, und dann die Sprachmerkmale und die entsprechenden Antworten als Eingabesequenz zu Zielsequenzpaaren organisiert werden. Ein überwachtes Sequenz-zu-Sequenz-Training kann dann angewandt werden, um die Parameter des API-Mappers 408 (z. B. RNN-Modul) zu trainieren und zu optimieren. Das Training des API-Mappers 408, z. B. des RNN-Moduls, kann unter Verwendung beliebiger konventioneller Techniken durchgeführt werden.
5 ist ein Blockdiagramm eines beispielhaften Systems (oder Gerätes) zum Implementieren des Dialogsystems im Einklang mit den hierin offenbarten Beispielen. Das Gerät 500 kann ein Mobilgerät sein. Das Gerät 500 umfasst einen Prozessor 510, einen Arbeitsspeicher/Massenspeicher 520, ein Drahtloskommunikationsmodul 530 einschließlich eines Basisbandmoduls und eines Funk-Frontendmoduls (nicht gezeigt), ein Standortmodul 540, ein Display 550, einen Displaytreiber 560, Sensoren 570, einen Lautsprecher 570, ein Mikrofon 580 usw. In einigen Aspekten kann der Prozessor 510 zum Beispiel ein oder mehrere Zentraleinheit (CPU)-Kerne und ein oder mehrere Cache-Speicher umfassen. Das Drahtloskommunikationsmodul 530 kann Drahtloskommunikation des Gerätes 500 im Einklang mit beliebigen Drahtloskommunikationsprotokollen, wie z. B. Third Generation (3G), Fourth Generation (4G), Fifth Generation (5G), WiFi, Bluetooth oder beliebigen Drahtloskommunikationsstandards, unterstützen. Zusätzlich kann das Gerät auch ein verdrahtetes Kommunikationsmodul enthalten. Der Arbeitsspeicher/Massenspeicher 520 kann Codes oder Daten, wie z. B. Benutzerprofildaten usw., speichern. Die Sensoren 570 sind enthalten, um verschiedene Aktivitäten des Benutzers zu erfassen. Beispielsweise können die Sensoren 570 einen Beschleunigungsmesser, ein Gyroskop usw. einschließen. Das Standortmodul 540 kann den Standort, z. B. den Global Positioning System (GPS)-Standort, des Gerätes 500 erkennen.
Der Arbeitsspeicher 520 (d. h. ein maschinenlesbares Speichermedium) speichert durch den Prozessor 510 auszuführende Codes. Die Codes, wenn sie ausgeführt werden, sind dazu ausgelegt, eine Anfrage von einem Benutzer zu empfangen, die Semantik der Anfrage, die zumindest ein Element von Einheiten, Absicht oder Kontext der Anfrage enthält, zu extrahieren, eine Sequenz von Aktionsmerkmalen auf der Basis der extrahierten Semantik auszuwählen, und eine Sequenz von Maschinenservices, die der Sequenz von Aktionsmerkmalen entspricht, auszuführen. Die Codes, wenn sie ausgeführt werden, können dazu ausgelegt sein, die Sequenz von Aktionsmerkmalen auf der Basis der Benutzerkonfiguration zu optimieren. Die Codes, wenn sie ausgeführt werden, können dazu ausgelegt sein, Spracheingaben und Antworten in Merkmale umzuwandeln, die Merkmale der Spracheingaben und entsprechenden Antworten als eingegebenes Sequenz-zu-Ziel-Sequenzpaar zu organisieren, und überwachtes Sequenz-zu-Sequenz-Training durchzuführen, um Parameter des rekurrenten Neuronalnetzes zu trainieren und zu optimieren.
Die hierin offenbarten Beispiele stellen eine neuartige technische Lösung bereit, um ein reicheres Semantik-Verständnis-Mapping zwischen Benutzerabsichten und verfügbaren Services zu modellieren, welche die Benutzererfahrung in dem Sprachdialogsystem als Kern des persönlichen Assistenten erheblich verbessern werden. Die Beispiele können die Benutzererfahrung in dem persönlichen Assistenten verbessern, so dass der Benutzer das Gefühl hat, mit einem Menschen anstatt einer Maschine zu kommunizieren, da das Dialogsystem mit menschlicher Semantik dienen kann, anstatt API durch API, die von Entwicklern für Maschinen definiert wurden. Die Leistung kann optimiert werden, da das Mapping direkt von menschlicher Semantik mit Service-API anstatt über menschlich definierte Semantikeinheiten gelernt wird. Die hierin offenbarten Beispiele können auf andere Anwendungen angewandt werden, um menschliche Semantik direkt auf Maschinenservices abzubilden.
Ein anderes Beispiel ist ein Computerprogramm, das Programmcode aufweist, um zumindest eines der hierin beschriebenen Verfahren durchzuführen, wenn das Computerprogramm auf einem Computer, einem Prozessor oder einer programmierbaren Hardwarekomponente ausgeführt wird. Ein anderes Beispiel ist ein maschinenlesbarer Massenspeicher, der maschinenlesbare Anweisungen enthält, die, wenn sie ausgeführt werden, ein Verfahren implementieren oder eine Vorrichtung realisieren, wie hierin beschrieben. Ein weiteres Beispiel ist ein maschinenlesbares Medium, das Code enthält, der, wenn er ausgeführt wird, eine Maschine veranlasst, ein beliebiges der hierin beschriebenen Verfahren durchzuführen.
Die Aspekte und Merkmale, die zusammen mit ein oder mehreren der zuvor detaillierten Beispiele und Figuren erwähnt und beschrieben wurden, können ebenfalls mit ein oder mehreren der anderen Beispiele kombiniert werden, um ein gleiches Merkmal des anderen Beispiels zu ersetzen, oder um das Merkmal zusätzlich in das andere Beispiel einzuführen.
Beispiele können ferner ein Computerprogramm sein oder darauf bezogen sein, das Programmcode aufweist, um eines oder mehrere der obigen Verfahren durchzuführen, wenn das Computerprogramm auf einem Computer oder Prozessor ausgeführt wird. Schritte, Operationen oder Prozesse der verschiedenen oben beschriebenen Verfahren können durch programmierte Computer oder Prozessoren durchgeführt werden. Beispiele können auch Programmspeichervorrichtungen, wie z. B. digitale Datenspeichermedien, abdecken, die von einer Maschine, einem Prozessor oder einem Computer lesbar sind und von einer Maschine, einem Prozessor oder einem Computer ausführbare Programme von Anweisungen codieren. Die Anweisungen führen einige oder alle der Handlungen der oben beschriebenen Verfahren durch oder veranlassen deren Durchführung. Die Programmspeichervorrichtungen können zum Beispiel digitale Speicher, magnetische Speichermedien, wie z. B. Magnetdisks und Magnetbänder, Festplatten, oder optisch lesbare digitale Datenspeichermedien umfassen oder darstellen. Weitere Beispiele können auch Computer, Prozessoren oder Steuereinheiten abdecken, die dazu programmiert sind, die Handlungen der oben beschriebenen Verfahren durchzuführen, oder (im Feld) programmierbare Logikarrays ((F)PLAs) oder (im Feld) programmierbare Gatearrays ((F)PGAs), die dazu programmiert sind, die Handlungen der oben beschriebenen Verfahren durchzuführen.
Die Beschreibungen und Zeichnungen veranschaulichen lediglich die Prinzipien der Offenbarung. Außerdem sind alle hierin aufgeführten Beispiele prinzipiell und ausdrücklich nur für pädagogische Zwecke vorgesehen, um dem Leser zu helfen, die Prinzipien der Offenbarung und die Konzepte zu verstehen, die durch den (die) Erfinder zur Förderung der Technik beigetragen wurden. Alle hierin angegebenen Erklärungen, die Prinzipien, Aspekte und Beispiele der Offenbarung sowie konkrete Beispiele davon anführen, sind beabsichtigt, Äquivalente davon zu umfassen.
Ein funktionaler Block, der als „Mittel für...“ gekennzeichnet ist, um eine bestimmte Funktion durchzuführen, kann auf eine Schaltung verweisen, die dazu ausgelegt ist, eine bestimmte Funktion durchzuführen. Daher kann ein „Mittel für etwas“ als ein „Mittel, das für etwas ausgelegt oder geeignet ist“ implementiert werden, wie z. B. ein Gerät oder eine Schaltung, das (die) für die jeweilige Aufgabe ausgelegt oder geeignet ist.
Funktionen von verschiedenen in den Figuren gezeigten Elementen, die mit „Mittel“, „Mittel zum Bereitstellen eines Sensorsignals“, „Mittel zum Erzeugen eines Sendesignals“ usw. bezeichnete funktionale Blöcke einschließen, können in der Form von dedizierter Hardware, wie z. B. „einem Signalanbieter“, „einer Signalverarbeitungseinheit“, „einem Prozessor“, „einem Controller“ usw., sowie als Hardware implementiert werden, die fähig ist, Software in Verbindung mit geeigneter Software auszuführen. Wenn durch einen Prozessor bereitgestellt, können die Funktionen durch einen einzelnen dedizierten Prozessor, durch einen einzelnen gemeinsam genutzten Prozessor, oder durch eine Vielzahl von individuellen Prozessoren bereitgestellt werden, von denen einige oder alle gemeinsam genutzt werden können. Der Begriff „Prozessor“ oder „Controller“ ist bei weitem nicht auf Hardware beschränkt, die ausschließlich zum Ausführen von Software fähig ist, sondern kann Digitalsignalprozessor (DSP)-Hardware, Netzwerkprozessor, anwendungsspezifische integrierte Schaltung (ASIC), feldprogrammierbares Gatearray (FPGA), Nur-Lese-Speicher (ROM) zum Speichern von Software, Direktzugriffsspeicher (RAM) und nichtflüchtigen Speicher umfassen. Andere Hardware, konventionell und/oder benutzerdefiniert, kann ebenfalls enthalten sein.
Ein Blockdiagramm kann zum Beispiel einen hochrangigen Schaltplan darstellen, der die Prinzipien der Offenbarung implementiert. Ebenso kann ein Ablaufdiagramm, ein Flussdiagramm, ein Zustandsübergangsdiagramm, ein Pseudocode und dergleichen verschiedene Prozesse, Operationen oder Schritte repräsentieren, die zum Beispiel im Wesentlichen in einem computerlesbaren Medium repräsentiert sein können und daher durch einen Computer oder Prozessor ausgeführt werden können, ohne Rücksicht darauf, ob ein solcher Computer oder Prozessor ausdrücklich gezeigt wird oder nicht. In der Spezifikation oder in den Ansprüchen offenbarte Verfahren können durch ein Gerät implementiert werden, das über Mittel verfügt, um jede der jeweiligen Handlungen dieser Verfahren durchzuführen.
Es versteht sich, dass die Offenbarung mehrerer Handlungen, Prozesse, Operationen, Schritte oder Funktionen, die in der Spezifikation oder den Ansprüchen offenbart werden, nicht unbedingt als innerhalb der spezifischen Reihenfolge befindlich ausgelegt werden, wenn nicht explizit oder implizit anders angegeben, zum Beispiel aus technischen Gründen. Daher beschränkt die Offenbarung mehrerer Handlungen oder Funktionen diese nicht auf eine spezielle Reihenfolge, es sei denn, solche Handlungen oder Funktionen sind aus technischen Gründen nicht austauschbar. Außerdem können in einigen Beispielen einzelne Handlungen, Funktionen, Prozesse, Operationen oder Schritte jeweils mehrere Teil-Handlungen, - Funktionen, -Prozesse, -Operationen oder -Schritte enthalten oder in solche unterteilt werden. Solche Teil-Handlungen können inbegriffen und Teil der Offenbarung dieser einzelnen Handlung sein, wenn sie nicht ausdrücklich ausgeschlossen werden.
Außerdem werden die folgenden Ansprüche hierdurch in die detaillierte Beschreibung einbezogen, wobei jeder Anspruch als ein getrenntes Beispiel eigenständig sein kann. Während jeder Anspruch als ein getrenntes Beispiel eigenständig sein kann, ist darauf hinzuweisen, dass - obwohl ein abhängiger Anspruch in den Ansprüchen auf eine spezifische Kombination mit einem oder mehreren anderen Ansprüchen verweisen kann - andere Beispiele ebenfalls eine Kombination des abhängigen Anspruchs mit dem Gegenstand jedes anderen abhängigen oder unabhängigen Anspruchs enthalten können. Solche Kombinationen werden hierin ausdrücklich vorgeschlagen, es sei denn es wird angegeben, dass eine spezifische Kombination nicht beabsichtigt ist. Außerdem ist beabsichtigt, auch Merkmale eines Anspruchs in einen beliebigen anderen Anspruch einzubeziehen, selbst wenn dieser Anspruch nicht direkt von dem unabhängigen Anspruch abhängig gemacht wird.

Claims

Dialogsystem, das Folgendes umfasst: eine Schnittstelle, die dazu ausgelegt ist, eine Anfrage von einem Benutzer zu empfangen; einen Semantikextraktor, der dazu ausgelegt ist, die Semantik der Anfrage, die zumindest ein Element von Einheiten, Absicht oder Kontext der Anfrage enthält, zu extrahieren; einen Anwendungsprogrammierschnittstelle (API)-Mapper, der dazu ausgelegt ist, eine Sequenz von Aktionsmerkmalen auf der Basis der extrahierten Semantik auszuwählen; und ein API-Aufrufmodul, das dazu ausgelegt ist, eine Sequenz von APIs, die der Sequenz von Aktionsmerkmalen entspricht, auszuführen.
Dialogsystem nach Anspruch 1, das ferner Folgendes umfasst: einen Aktionssequenzoptimierer, der dazu ausgelegt ist, die Sequenz von Aktionsmerkmalen auf der Basis der Benutzerkonfiguration zu optimieren.
Dialogsystem nach Anspruch 1, wobei die Anfrage eine Sprachanfrage ist und die Schnittstelle einen Spracherkenner enthält, der dazu ausgelegt ist, eine Sprachanfrage in eine Textzeichenfolge umzuwandeln.
Dialogsystem nach Anspruch 1, wobei die Anfrage als Textanfrage empfangen wird.
Dialogsystem nach Anspruch 1, wobei die Sequenz von Aktionsmerkmalen als Ressourcengrafik organisiert wird.
Dialogsystem nach Anspruch 1, wobei der API-Mapper mit einem rekurrenten Neuronalnetz implementiert wird.
Dialogsystem nach Anspruch 6, wobei das rekurrente Neuronalnetz durch Umwandeln von Reden und Antworten in Merkmale, Organisieren der Merkmale der Reden und entsprechenden Antworten als eingegebenes Sequenz-zu-Ziel-Sequenzpaar, und Durchführen von überwachtem Sequenz-zu-Sequenz-Training trainiert wird, um Parameter des rekurrenten Neuronalnetzes zu trainieren und zu optimieren.
Dialogsystem nach Anspruch 1, wobei mehrere APIs als Antwort auf die Anfrage aufgerufen werden.
Dialogsystem nach Anspruch 1, wobei die Anfrage von einem Benutzergerät empfangen wird.
Verfahren zum Implementieren eines Dialogsystems, wobei das Verfahren Folgendes umfasst: Empfangen einer Anfrage von einem Benutzer; Extrahieren der Semantik der Anfrage, die zumindest ein Element von Einheiten, Absicht oder Kontext der Anfrage enthält; Auswählen einer Sequenz von Aktionsmerkmalen auf der Basis der extrahierten Semantik; und Ausführen einer Sequenz von Maschinenservices, die der Sequenz von Aktionsmerkmalen entspricht.
Verfahren nach Anspruch 10, das ferner Folgendes umfasst: Optimieren der Sequenz von Aktionsmerkmalen auf der Basis der Benutzerkonfiguration.
Verfahren nach Anspruch 10, wobei die Anfrage eine Sprachanfrage ist, und die Sprachanfrage in eine Textzeichenfolge umgewandelt wird.
Verfahren nach Anspruch 10, wobei die Anfrage als Textanfrage empfangen wird.
Verfahren nach Anspruch 10, wobei die Sequenz von Aktionsmerkmalen als Ressourcengrafik organisiert wird.
Verfahren nach Anspruch 10, wobei die Sequenz von Aktionsmerkmalen durch ein rekurrentes Neuronalnetz ausgewählt wird.
Verfahren nach Anspruch 15, wobei das rekurrente Neuronalnetz durch Folgendes trainiert wird: Umwandeln von Reden und Antworten in Merkmale; Organisieren von Merkmalen der Reden und entsprechenden Antworten als ein eingegebenes Sequenz-zu-Ziel-Sequenzpaar, und Durchführen von überwachtem Sequenz-zu-Sequenz-Training, um Parameter des rekurrenten Neuronalnetzes zu trainieren und zu optimieren.
Verfahren nach Anspruch 10, wobei mehrere Anwendungsprogrammierschnittstellen als Antwort auf die Anfrage aufgerufen werden.
Verfahren nach Anspruch 10, wobei die Anfrage von einem Benutzergerät empfangen wird.
Nicht-transitorischer maschinenlesbarer Speicher, der maschinenlesbare Anweisungen enthält, die, wenn sie ausgeführt werden, ein Verfahren wie in Anspruch 10 implementieren.