DE102017125001A1 - Streaming-Dialogmanagement in Echtzeit - Google Patents

Streaming-Dialogmanagement in Echtzeit Download PDF

Info

Publication number
DE102017125001A1
DE102017125001A1 DE102017125001.8A DE102017125001A DE102017125001A1 DE 102017125001 A1 DE102017125001 A1 DE 102017125001A1 DE 102017125001 A DE102017125001 A DE 102017125001A DE 102017125001 A1 DE102017125001 A1 DE 102017125001A1
Authority
DE
Germany
Prior art keywords
dialog
candidate
response
list
path
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
DE102017125001.8A
Other languages
English (en)
Inventor
David Elson
Raj Agarwal
Crista Wimberley
Benjamin Ross
David Eisenberg
Kevin Chavez
Sudeep Gandhe
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Google LLC
Original Assignee
Google LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Google LLC filed Critical Google LLC
Publication of DE102017125001A1 publication Critical patent/DE102017125001A1/de
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G06F16/33—Querying
    • G06F16/332—Query formulation
    • G06F16/3329—Natural language query formulation or dialogue systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/20—Natural language analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G06F16/33—Querying
    • G06F16/3331—Query processing
    • G06F16/334—Query execution
    • G06F16/3344—Query execution using natural language analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/16—Sound input; Sound output
    • G06F3/167—Audio in a user interface, e.g. using voice commands for navigating, audio feedback
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/30—Semantic analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/40—Processing or translation of natural language
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
    • G06F9/4498—Finite state machines
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00—Machine learning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G10—MUSICAL INSTRUMENTS; ACOUSTICS
    • G10L—SPEECH ANALYSIS TECHNIQUES OR SPEECH SYNTHESIS; SPEECH RECOGNITION; SPEECH OR VOICE PROCESSING TECHNIQUES; SPEECH OR AUDIO CODING OR DECODING
    • G10L15/00—Speech recognition
    • G10L15/22—Procedures used during a speech recognition process, e.g. man-machine dialogue
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/02—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail using automatic reactions or user delegation, e.g. automatic replies or chatbot-generated messages
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/20—Natural language analysis
    • G06F40/205—Parsing

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Computational Linguistics (AREA)
  • Data Mining & Analysis (AREA)
  • Artificial Intelligence (AREA)
  • Health & Medical Sciences (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Databases & Information Systems (AREA)
  • Mathematical Physics (AREA)
  • Human Computer Interaction (AREA)
  • Business, Economics & Management (AREA)
  • Software Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Strategic Management (AREA)
  • Human Resources & Organizations (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Multimedia (AREA)
  • Acoustics & Sound (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • General Business, Economics & Management (AREA)
  • Tourism & Hospitality (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Computing Systems (AREA)
  • Evolutionary Computation (AREA)
  • Medical Informatics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • User Interface Of Digital Computer (AREA)
  • Machine Translation (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Systeme und Verfahren stellen ein Dialogmanagement in Echtzeit anstelle eines Sprecherwechsels bereit. Ein beispielhaftes Verfahren umfasst ein Erzeugen von ersten Kandidatenantworten auf ein Auslöseereignis. Das Auslöseereignis kann ein Empfang eines Live-Stream-Stücks für den Dialog oder ein Empfang einer Backend-Antwort auf eine vorherige Backend-Anforderung für ein Dialogschema sein. Das Verfahren umfasst zudem ein Aktualisieren einer Liste von Kandidatenantworten, die akzeptiert oder ausstehend sind, mit mindestens einer der ersten Kandidatenantworten und ein Bestimmen für das Auslöseereignis, ob die Liste von Kandidatenantworten eine Kandidatenantwort enthält, die eine Vertrauenspunktzahl aufweist, die eine Auslöseschwelle erfüllt. Das Verfahren umfasst zudem ein Warten auf ein nächstes Auslöseereignis, ohne eine Kandidatenantwort zu liefern, wenn die Liste keine Kandidatenantwort enthält, die eine Vertrauenspunktzahl aufweist, die die Auslöseschwelle erfüllt.

Description

  • Verwandte Anmeldung
  • Diese Anmeldung beansprucht das Prioritätsrecht der vorläufigen US-Patentanmeldung Nr. 62/459820 mit dem Titel „Streaming Real-Time Dialog Management“, die am 16. Februar 2017 eingereicht worden ist und deren Offenbarung hier durch Bezugnahme vollständig mit aufgenommen ist.
  • Hintergrund
  • Dialogmanagement ist das Problem, der Konversation eines Anwenders mit einem elektronischen Assistenten zu folgen. Der Assistent wartet darauf, dass der Anwender mit dem Sprechen fertig ist, berechnet eine Antwort und liefert dann die Antwort. Solch ein Ablauf wird als Sprecherwechsel bezeichnet, da der Anwender einen Beitrag liefert, der Assistent einen Beitrag liefert und dann der Anwender einen Beitrag liefert usw. Die meisten elektronischen Assistenten behandeln jeweils ein Schema nach dem anderen, wobei ein Schema einer Aufgabe oder einem Konversationsthema ähnlich ist, wie etwa Kochen, Wetter, Einstellen eines Zeitgebers usw. Assistenten, die mit mehreren Schemas umgehen können, arbeiten dennoch in einem Ablauf mit Sprecherwechsel.
  • Zusammenfassung
  • Implementierungen stellen ein Dialogmanagement in Echtzeit anstelle des Sprecherwechsels bereit. Ein System, das einen Echtzeit-Dialogmanagement-Rahmen verwendet, kann an einer natürlichen bidirektionalen Echtzeitkonversation mit einem Anwender teilnehmen. Das Echtzeit-Dialogmanagement unterscheidet sich von dem Sprecherwechsel, da das System ständig Streaming-Audio abhört und Entscheidungen darüber trifft, was der Anwender zu sagen beabsichtigt, welche Antworten geeignet sind und wann eine Antwort geeigneterweise zu liefern ist. Beim Sprecherwechsel erzeugt das System eine Antwort und antwortet auf eine spezifische Anforderung des Anwenders. Es besteht keine Unsicherheit darüber, ob eine Antwort gegeben werden soll. Im Gegensatz dazu kann das System beim Echtzeit-Dialogmanagement versuchen, eine geeignete Antwort vorherzusagen, bevor es eine vollständige Anforderung von dem Anwender empfängt, z. B. eine Anforderung, die nach einer Zeit des Schweigens des Anwenders impliziert ist. Beim Vorhersagen muss das System mehrere Dialogpfade behandeln, die aktualisiert, gestutzt und erzeugt werden, wenn das System weitere Eingaben von dem Anwender erhält. Der Echtzeit-Dialogmanagement-Rahmen findet einen Kompromiss zwischen Verarbeitungsbetriebsmitteln (vergeudeten Verarbeitungszyklen, die eine Antwort berechnen, die niemals geliefert wird) und der Verzögerung. Ein Echtzeit-Dialogmanagement-Rahmen kann es einem elektronischen Assistenten ermöglichen, Antworten schneller zu formulieren als bei dem Sprecherwechsel, um in geeigneten Momenten eine Rückkanal-Rückmeldung zu liefern, und kann unterstützende Antworten, oder mit anderen Worten vorhersagende Antworten, die den Gedanken eines Anwenders vervollständigen, anbieten. Ein Echtzeit-Dialogmanagement-Rahmen simuliert daher natürliche Konversationen besser als ein Dialog mit Sprecherwechsel. Ein Echtzeit-Dialogmanagement-Rahmen, der einen Dialogmischer enthält, der mehrere Schemas behandelt, verbessert die Simulation einer natürlicheren Konversation. Ein Dialog, der in Echtzeit abläuft, sowie bidirektional und vorhersagend ist, verbessert die Schnittstelle des elektronischen Assistenten.
  • Gemäß bestimmten Aspekten umfasst ein Verfahren, das von einem oder mehreren Prozessoren implementiert werden kann, ein Erzeugen von ersten Kandidatenantworten auf ein Auslöseereignis. Das Auslöseereignis kann ein Empfang eines Live-Stream-Stücks für den Dialog oder ein Empfang einer Backend-Antwort auf eine vorherige Backend- Anforderung für ein Dialogschema sein. Eine „Backend-Antwort“ ist eine Antwort von einem Backend-System und/oder einem Dialogmanager. Das Verfahren umfasst auch ein Aktualisieren einer Liste von Kandidatenantworten, die akzeptiert oder ausstehend sind, mit mindestens einer der ersten Kandidatenantworten und ein Bestimmen für das Auslöseereignis, ob die Liste von Kandidatenantworten eine Kandidatenantwort enthält, die eine Vertrauenspunktzahl aufweist, die eine Auslöseschwelle erfüllt. Das Verfahren umfasst auch ein Warten auf ein nächstes Auslöseereignis, ohne eine Kandidatenantwort zu liefern, wenn die Liste keine Kandidatenantwort enthält, die eine Vertrauenspunktzahl aufweist, die die Auslöseschwelle erfüllt.
  • Gemäß bestimmten Aspekten umfasst ein Verfahren, das von einem oder mehreren Prozessoren implementiert werden kann, Folgendes: als Antwort auf ein Empfangen eines Stücks aus einem Echtzeit-Dialogstrom, Liefern des Stücks an einen Dialogmischer, Empfangen von Antwortkandidaten für das Stück aus dem Dialogmischer, wobei jeder Antwortkandidat eine Systemantwort für ein Dialogschema oder eine Backend-Anforderung für ein Dialogschema ist, und Aktualisieren einer rotierenden Liste von Antwortkandidaten unter Verwendung von mindestens einem der Antwortkandidaten für das Stück. Das Verfahren umfasst ferner: Einstufen der Antwortkandidaten in der Liste, wobei jeder Antwortkandidat eine jeweilige Vertrauenspunktzahl aufweist, Bestimmen, ob die rotierende Liste einen Antwortkandidaten mit einer Vertrauenspunktzahl, die einen Auslöseschwellenwert erfüllt, enthält, und dann, wenn die rotierende Liste keinen Antwortkandidaten mit einer Vertrauenspunktzahl, die die Auslöseschwelle erfüllt, enthält, Initiieren einer Backend-Anforderung, die durch einen Antwortkandidaten in der Liste repräsentiert wird, der eine Vertrauenspunktzahl, die eine Einstufungsschwelle erfüllt, aufweist und der noch kein akzeptierter Dialogzustand ist.
  • Gemäß bestimmten Aspekten umfasst ein Verfahren, das von einem oder mehreren Prozessoren implementiert werden kann, Folgendes: Empfangen eines Auslöseereignisses für einen Echtzeit-Dialog, wobei der Echtzeit-Dialog einen zugeordneten Dialogstrahl mit einem ersten Pfad aufweist, wobei der Dialogstrahl Dialogzustände für einen Echtzeit-Dialog mit einem Anwender repräsentiert, Bestimmen, dass das Auslöseereignis einen neuen Pfad in dem Dialogstrahl startet, und Zurückfallen in dem ersten Pfad bis zu einem Vorgängerknoten in dem Dialogstrahl. Das Verfahren umfasst zudem: Beginnen des neuen Pfads in dem Dialogstrahl von dem Vorgängerknoten aus durch Erzeugen von Antwortkandidaten unter Verwendung eines durch den Vorgängerknoten repräsentierten Basiszustands und von Informationen aus dem Auslöseereignis, wobei ein Pfad in dem Dialogstrahl ein oder mehrere akzeptierte oder ausstehende Antwortkandidaten enthält, wobei ein Antwortkandidat eine Systemantwort ist, die durch ein Dialogschema oder eine Backend-Anforderung für ein Dialogschema erzeugt wird.
  • Gemäß bestimmten Aspekten umfasst ein Rechensystem mindestens einen Prozessor und einen Speicher, der Befehle speichert, die, wenn sie von dem mindestens einen Prozessor ausgeführt werden, die Rechenvorrichtung dazu veranlassen, eines/n der offenbarten Verfahren, Vorgänge oder Prozesse durchzuführen.
  • Gemäß bestimmten Aspekten enthält ein Computerprogrammprodukt, das auf einer computerlesbaren Speichervorrichtung verkörpert ist, Befehle, die, wenn sie von mindestens einem in einem Substrat ausgebildeten Prozessor ausgeführt werden, eine Rechenvorrichtung dazu veranlassen, eines/n der offenbarten Verfahren, Vorgänge oder Prozesse durchzuführen. Ein weiterer allgemeiner Aspekt umfasst ein System und/oder ein Verfahren für ein Streaming-Multischema-Dialogmanagement in Echtzeit zur Verbesserung von Echtzeit-Konversationen mit einem Anwender, wie es im Wesentlichen in Verbindung mit mindestens einer der Figuren gezeigt und/oder beschrieben ist und wie es vollständiger in den Ansprüchen dargelegt ist.
  • Eine oder mehrere der Implementierungen des hierin beschriebenen Gegenstandes können implementiert werden, um einen oder mehrere der folgenden Vorteile zu verwirklichen. Zum Beispiel berechnen Implementierungen Antworten schneller als sprecherwechselbasierte Dialogmanager. In einigen Implementierungen kann das System Kandidaten innerhalb von 10 Millisekunden erzeugen. Dies ist viel schneller als bei herkömmlichen Sprecherwechselmanagementsystemen, die typischerweise eine gewisse Zeitspanne (z. B. 0,5 Millisekunden) warten, bevor sie überhaupt beginnen, den Anwenderdialogbeitrag zu verarbeiten. Als ein weiteres Beispiel bieten Implementierungen eine genauere Konversation mit dem Anwender, da das System Rückkanal-Rückmeldungen liefern kann und Unterstützung bieten kann, und dies schneller erfolgen kann als beim Sprecherwechsel. Folglich wird der Aufruf von dem Anwender wahrscheinlich schneller abgeschlossen als bei sprecherwechselbasierten Dialogmanagern, weil die Zeit zum Erzeugen von Kandidatenantworten reduziert wird und/oder weil die verständlicheren/genaueren Antworten, die geliefert werden, die Notwendigkeit, dass der Anwender einen Teil seiner Rede wiederholen muss oder neu formulieren muss, weil dieser von dem elektronischen Assistenten falsch gedeutet oder missverstanden wurde, beseitigen (oder zumindest deutlich reduzieren). Dies reduziert die Zeitspanne, für die dem Aufruf Netzbetriebsmittel zugewiesen werden, reduziert den Energieverbrauch durch die Vorrichtung des Anwenders (besonders vorteilhaft, wenn der Anwender eine batteriebetriebene Vorrichtung besitzt) usw. Die Bereitstellung einer genaueren/natürlichen Konversation macht einen elektronischen Assistenten zudem anwenderfreundlicher und einfacher zu bedienen. Darüber hinaus kann das System mehrere Langzeitdialoge führen, da das System unterschiedliche Pfade verfolgen und pflegen kann. Implementierungen sind zudem für Fern-Prozeduraufrufe nichtblockierend, wodurch das Vorrichtungsleistungsvermögen weiter verbessert wird.
  • Die Einzelheiten einer oder mehrerer Implementierungen sind in den beigefügten Zeichnungen und der nachfolgenden Beschreibung dargelegt. Weitere Merkmale ergeben sich aus der Beschreibung und den Zeichnungen sowie aus den Ansprüchen.
  • Figurenliste
    • 1 ist ein Blockdiagramm, das ein beispielhaftes System gemäß dem offenbarten Gegenstand darstellt.
    • 2 ist ein Blockdiagramm, das ein weiteres beispielhaftes System gemäß dem offenbarten Gegenstand darstellt.
    • 3 zeigt ein Ablaufdiagramm eines beispielhaften Prozesses zum Managen eines Echtzeit-Dialogs gemäß offenbarten Implementierungen.
    • 4 ist ein Blockdiagramm, das einen beispielhaften Echtzeit-Dialogstrahl, der von einem Dialog-Host gemanagt wird, gemäß dem offenbarten Gegenstand darstellt.
    • 5 zeigt ein Beispiel einer Computervorrichtung, die verwendet werden kann, um die beschriebenen Techniken zu implementieren.
    • 6 zeigt ein Beispiel einer verteilten Computervorrichtung, die verwendet werden kann, um die beschriebenen Techniken zu implementieren.
  • Gleiche Bezugszeichen in den verschiedenen Zeichnungen bezeichnen gleiche Elemente.
  • Genaue Beschreibung
  • Implementierungen umfassen Systeme und Verfahren, die eine Echtzeit-Streaming-Eingabe, z. B. in Stücken, lesen, eine Liste von Antwortkandidaten für die Eingabe führen und entscheiden, wann einer der Antwortkandidaten an den Anwender zurückgegeben werden soll. Die Liste der Antwortkandidaten ist insofern eine dynamische Liste, als sie durch Hinzufügen eines oder mehrerer neuer Antwortkandidaten und/oder Entfernen (oder „Stutzen“) eines oder mehrerer Antwortkandidaten aus der Liste fortlaufend aktualisiert wird, und wird als „rotierende“ Liste bezeichnet. Ein Dialog-Host ruft bei einem Auslöseereignis, bei dem es sich um eine Backend-Anforderung, den Empfang einer neuen Streaming-Eingabe oder den Ablauf eines Zeitfensters handeln kann (falls innerhalb des Fensters kein anderes Auslöseereignis aufgetreten ist), einen Dialogmischer auf. Der Dialog-Host managt einen oder mehrere Pfade in einem Dialogstrahl, managt divergierende Pfade, stutzt Pfade mit niedrigen A-posteriori-Wahrscheinlichkeiten und geht zurück, um bei Bedarf einen neuen Pfad zu starten. Streaming-Eingaben sind Eingaben, die in Echtzeit empfangen werden und eine unvollständige Anforderung enthalten können. Mit anderen Worten beginnen Implementierungen mit der Erzeugung von Antwortkandidaten, noch bevor der Anwender das Sprechen beendet hat. Da der Dialog-Host mit der Formulierung einer Antwort beginnt, bevor der Anwender mit dem Sprechen fertig ist, erhöht der Dialog-Host die Geschwindigkeit, mit der der elektronische Assistent auf den Anwender reagieren kann. Der Dialog-Host weist eine Einstufungs- und Auslösefähigkeit auf, um zu entscheiden, welche Dialogantworten gegebenenfalls als Teil einer Konversation an den Anwender geliefert werden sollen. Das Entscheiden, wann geantwortet werden soll, also beispielsweise nicht auf ein bestimmtes Auslöseereignis zu antworten, ist eine wichtige Funktion, damit der elektronische Assistent nicht unangemessen unterbricht oder vorschnelle Vorschläge liefert. Implementierungen verfolgen einen Dialogzustand für jeden Pfad eines Dialogstrahls und sind in der Lage, zurückzugehen oder einen neuen Pfad für den Dialog zu starten, wenn zusätzliche Eingaben den Kontext des Dialogs ändern.
  • 1 ist ein Blockdiagramm eines Echtzeit-Dialogmanagementsystems gemäß einer beispielhaften Implementierung. Das System 100 kann verwendet werden, um eine natürliche Konversation mit einem Anwender korrekter zu simulieren, um hilfreichere Antworten zu liefern und um schneller Antworten zu geben, als dies bei herkömmlichen Sprecherwechsel-Dialogmanagern der Fall ist. Das System 100 kann auch dazu ausgelegt sein, Kandidatenantworten aus mehreren Dialogschemata bereitzustellen, wobei Schemata kombiniert werden, wenn dies angemessen ist. Das System 100 kann Echtzeit-Streaming-Eingaben von dem Anwender verarbeiten, anstatt darauf zu warten, Eingaben zu verarbeiten, nachdem der Anwender einen Befehl oder eine Anfrage abgeschlossen hat. Die Darstellung des Systems 100 in 1 ist eine einzelne Rechenvorrichtung, aber Implementierungen können auch einige der Komponenten auf einen Server verlagern, was das System 100 zu einem Client-Server-System macht, wie es genauer in 2 dargestellt ist. Zusätzlich können eine oder mehrere Komponenten in einem einzelnen Modul oder einer einzigen Maschine kombiniert werden und einige Fähigkeiten der dargestellten Komponenten können durch separate Engines ausgeführt werden. In einigen Implementierungen kann ein Anwender der Rechenvorrichtung angeben, dass Teile der Verarbeitung auf einem Server ausgeführt werden sollen. Daher sind die Implementierungen nicht auf die genauen Konfigurationen, die dargestellt sind, beschränkt.
  • Das Echtzeit-Dialogmanagementsystem 100 enthält eine Rechenvorrichtung 105. Die Rechenvorrichtung kann in einem PC implementiert sein, beispielsweise einem Laptop-Computer, einem Smartphone, einer am Körper tragbaren Vorrichtung (einer intelligenten Uhr, intelligenten Brille usw.), einer Spielekonsole, einem Haushaltsgerät usw. Die Rechenvorrichtung 105 kann ein Beispiel der Rechenvorrichtung 500 sein, wie sie in 4 dargestellt ist. Die Rechenvorrichtung 105 kann einen oder mehrere Prozessoren enthalten, die in einem Substrat (nicht dargestellt) ausgebildet sind und dazu ausgelegt sein, um einen oder mehrere maschinenausführbare Befehle oder Teile von Software, Firmware oder einer Kombination davon auszuführen. Die Prozessoren können halbleiterbasiert sein - das heißt, die Prozessoren können Halbleitermaterial enthalten, das digitale Logik ausführen kann. Die Rechenvorrichtung 105 kann auch einen oder mehrere Computerspeicher enthalten. Die Speicher, z. B. ein Hauptspeicher, können dazu ausgelegt sein, ein oder mehrere Datenstücke entweder temporär, permanent oder semipermanent zu speichern oder eine Kombination davon. Die Speicher können irgendeine Art von Speichervorrichtung enthalten, die Informationen in einem Format speichert, das von dem einen oder den mehreren Prozessoren gelesen und/oder ausgeführt werden kann. Die Speicher können einen flüchtigen Speicher, einen nichtflüchtigen Speicher oder eine Kombination davon enthalten und Module oder Engines speichern, die, wenn sie von dem einen oder den mehreren Prozessoren ausgeführt werden, bestimmte Operationen durchführen. In einigen Implementierungen können die Module in einer externen Speichervorrichtung gespeichert sein und in den Speicher der Computervorrichtung 105 geladen werden.
  • Die Rechenvorrichtung 105 kann Dialog-Eingabe-/Ausgabe-Vorrichtungen 110 enthalten. Die Dialog-Eingabe-/Ausgabe-Vorrichtungen 110 können Hardware enthalten, die es dem Dialog-Host 120 ermöglicht, Eingaben von dem Anwender 180 zu empfangen oder eine Antwort an den Anwender 180 zu liefern. Eingaben von dem Anwender können mündlich sein, z. B. in Form von Sprache. Sprache kann als Streaming-Eingabe unter Verwendung herkömmlicher Techniken wie Stückelung bereitgestellt werden. Die Eingaben von dem Anwender können auch nichtmündlich sein, z. B. Text, Tippvorgänge usw., die von dem Anwender bereitgestellt werden. Die Ausgaben können in ähnlicher Weise sprachbasiert oder textbasiert sein. Ein Beispiel der Eingabe-/Ausgabe-Vorrichtungen 110 kann ein Mikrofon und einen Lautsprecher enthalten. Ein anderes Beispiel der Eingabe-/Ausgabe-Vorrichtungen 100 kann eine Tastatur (virtuell oder physisch) und eine Anzeige sein. Die Eingabe-/Ausgabe-Vorrichtungen 110 können auch Module zum Umwandeln von durch das Mikrofon erfassten Tönen in Streaming-Eingaben enthalten. Das Echtzeit-Dialogmanagementsystem 100 wird hauptsächlich im Zusammenhang mit einer gesprochenen Konversation unter Verwendung eines Mikrofons und eines Lautsprechers diskutiert, aber Implementierungen umfassen andere Konversationsarten, wie etwa diejenigen, die in einer Nachrichtenübermittlungsanwendung enthalten sind.
  • Die Module des Echtzeit-Dialogmanagementsystems 100 können einen Dialog-Host 120 umfassen. Der Dialog-Host 120 kann dazu ausgelegt sein, Eingaben von den Eingabe-/Ausgabe-Vorrichtungen 110 zu erhalten oder zu empfangen. Die Eingaben können eine Streaming-Eingaben umfassen. Streaming-Eingaben erfassen die Stimme (Sprache) des Anwenders als eine Reihe von Stücken, die z. B. einige Sekunden lang sind, und liefern die Stücke als eine Datei an den Dialog-Host 120. Streaming-Eingaben werden als verbale Eingabe betrachtet. Der Dialog-Host 120 betrachtet jede neue Datei als ein Auslöseereignis und ruft einen Dialogmischer 130 für jede neue Eingabe auf. Die Eingabe kann ein gleitendes Fenster von Stücken umfassen. Zum Beispiel kann das Fenster die neu empfangene Datei und eine Menge von zuvor empfangenen Dateien enthalten, wenn diese vorhanden sind. Das Fenster kann die Dauer der Eingabe darstellen, für die sich das System noch nicht auf ein semantisches Verständnis oder eine Antwort festgelegt hat. Mit anderen Worten kann das Fenster den „instabilen“ Teil der Eingabe darstellen, den das System verwendet, um unterschiedliche Pfade zu bestimmen, und daher könnte das System immer noch zurückfallen oder einen neuen Pfad beginnen usw. Sobald das System eine Antwort liefert, hat sich das System auf die bereitgestellte Eingabe festgelegt und diese Eingabe wird „stabil“. In einigen Implementierungen kann das Fenster als beliebige Eingabestücke, die nach dem Liefern einer jüngsten Antwort empfangen werden, definiert sein. In einigen Implementierungen kann das Fenster unter Bezugnahme auf eine Zeitspanne definiert sein, z. B. Sekunden, Bruchteile einer Sekunde usw. Somit werden ältere Dateien zu alt, um in dem Fenster enthalten zu sein.
  • Der Dialog-Host 120 kann dazu ausgelegt sein, eine nonverbale Eingabe als ein Auslöseereignis zu erkennen. Nonverbale Eingaben können eine Textzeichenfolge, Tippeingaben oder Auswahlen enthalten, die von dem Anwender unter Verwendung der Eingabe-/Ausgabe-Vorrichtungen 110 erhalten werden. Der Dialog-Host 120 betrachtet solche nonverbalen Eingaben als Auslöseereignis und ist dazu ausgelegt, den Dialogmischer 130 für jede neue nonverbale Eingabe aufzurufen. Der Dialog-Host 120 kann auch einen Umschreibkandidaten als Auslöseereignis betrachten. In einigen Implementierungen kann das System den aktuellen Eingabekontext an eine Maschine liefern, die verschiedene Arten der Auflösung, z. B. Koreferenz, Ellipse usw. an der Eingabe durchführt. Diese Engine kann eine Funktion sein, die von dem Dialog-Host 120 oder einem der Dialogmanager 170 bereitgestellt wird. Die Engine kann einen Umschreibkandidaten liefern, wobei der Dialog-Host 120 den Umschreibkandidaten wie eine Backend-Antwort behandeln kann. Der Dialog-Host 120 ist dazu ausgelegt, den Dialogmischer 130 mit dem Umschreibkandidaten als neuer Eingabe aufzurufen.
  • Der Dialog-Host 120 erkennt auch einen Empfang einer Backend-Antwort als Auslöseereignis. Der Dialog-Host 120 ist dazu ausgelegt, den Dialogmischer 130 für jede empfangene Backend-Antwort anzurufen. Eine „Backend-Antwort“ stellt Daten dar, die unter Verwendung eines Dialogmanagers 170 erzeugt werden und die auf einer oder mehreren durchsuchbaren Datenbestände, z. B. Backend-Systemen 190, basieren können. Die Daten sind zur Ausgabe durch die Eingabe-/Ausgabe-Vorrichtung 110 vorgesehen. Eine Backend-Antwort kann von einem Dialogmanager 170 als Antwort auf eine an den Dialogmanager 170 gesendete Anforderung geliefert werden. Die Backend-Antwort repräsentiert somit ein Suchergebnis, das durch das Schema geliefert wird, mit dem der jeweilige Dialogmanager 170 arbeitet. Mit anderen Worten initiiert in dieser Ausführungsform eine „Backend-Anforderung“ an einen Dialogmanager 170 eine Suche des Schemas, das von dem Dialogmanager 170 gemanagt wird, unter Verwendung der Eingabe. Die „Backend-Antwort“, die von dem Dialogmanager 170 zurückgegeben wird, enthält die Ergebnisse der Suche. Die Backend-Antwort kann auf eine Anforderung sein, die von dem Dialog-Host 120 getätigt wird. Die Backend-Antwort kann auch auf eine Anforderung sein, die von dem Dialog-Host 120 nicht getätigt wird. Zum Beispiel kann in einigen Implementierungen ein Dialogmanager 170a einen oder mehrere andere Dialogmanager (z. B. 170b und / oder 170n) mit Ressourcen, z. B. Informationen oder Daten, die als Antwort auf eine Anforderung erhalten werden, versehen und die anderen Dialogmanager können einige oder alle der Ressourcen verwenden, um eine zusätzliche Backend-Antwort zu liefern. Die Backend-Antwort enthält eine vorgeschlagene Systemantwort auf die Backend-Anforderung. Die Systemantwort kann eine verbale Ausgabe sein, die von den Eingabe-/Ausgabe-Vorrichtungen 110 an den Anwender geliefert wird. Die Systemantwort kann alternativ auch mit einer Aktion verbunden sein, die die Rechenvorrichtung durchführt, wenn die Antwort bereitgestellt wird. Zum Beispiel kann die Systemantwort veranlassen, dass die Rechenvorrichtung eine Anwendung öffnet und irgendeine Funktion in der Anwendung, z. B. ein Hinzufügen eines neuen Kalenderereignisses, durchführt.
  • Der Dialog-Host 120 kann dazu ausgelegt sein, um den Dialogmischer 130 in Abwesenheit anderer Auslöseereignisse periodisch aufzurufen. Wenn beispielsweise keine neuen Eingaben und keine Backend-Antworten innerhalb einer Zeitspanne von beispielsweise 100 Millisekunden empfangen werden, kann der Dialog-Host 120 dieses Verstreichen von Zeit als ein Auslöseereignis betrachten und den Dialogmischer 130 aufrufen. Dies ermöglicht es dem Dialog-Host 120, die rotierende Liste von Kandidaten zu aktualisieren und eine neue Entscheidung darüber zu treffen, ob einer der Kandidaten über die Dialog-Eingabe-/Ausgabe-Vorrichtungen 110 als Antwort an den Anwender geliefert werden soll.
  • Der Dialog-Host 120 managt eine rotierende Liste von Kandidatenantworten 150. Jede Kandidatenantwort kann als ein Dialog bezeichnet werden. In einer Echtzeit-Streaming-Dialogumgebung kann ein Dialog als ein Pfad in einem Dialogstrahl repräsentiert werden. Ein Dialogstrahl ist eine Strahlsuche, bei der Dialogantworten Dialogzuständen zugeordnet werden. Ein Pfad in einem Dialogstrahl repräsentiert die Dialogzustände, die für die gleiche Eingabe (z. B. Anfrage) aus demselben Basiszustand erzeugt werden. Da das System Eingaben in Echtzeit überwacht, ist der beabsichtigte Dialog des Anwenders nicht immer bekannt. Daher managt der Dialog-Host 120 mehrere mögliche Dialoge auf einmal, die in der Kandidatenliste 150 repräsentiert sind. Der Dialog-Host 120 stutzt Pfade in dem Dialogstrahl, die irrelevant oder veraltet werden, und fügt nach Bedarf neue Pfade hinzu. Jeder Kandidat ist einem Dialogzustand zugeordnet. Der Zustand kann durch eine Datenstruktur repräsentiert sein. Die Zustandsdatenstruktur kann die Frage beinhalten, die beantwortet wird und z. B. aus den Eingaben (z. B. dem Eingabefenster) entnommen wird. Die Zustandsdatenstruktur kann den aktuellen Konversationskontext, eine Historie der Anwendereingaben/-anforderungen, Systemdeutungen der Eingaben, eine Chronik von Antworten, die an den Anwender geliefert werden, andere relevante Ereignisse wie etwa eingehende Benachrichtigungen, Daten, die für eine Aufgabenvorhersage relevant sind, z. B. Daten, die der Rechenvorrichtung dabei helfen, eine Aufgabe zu bestimmen oder vorherzusagen, die der Anwender erfüllen möchte (wie etwa ein Buchen eines Restauranttisches), den Aufmerksamkeitszustand des Anwenders (wie etwa eine Person oder einen Ort, auf die/den sich der aktuelle Dialog bezieht) usw. umfassen. Die Zustandsdatenstruktur kann auch Information über den Typ von Informationen enthalten, die für den Dialog angefordert werden. Zum Beispiel kann ein Kalenderdialog ein Datum, eine Zeit, einen Ereignisnamen usw. erfordern. Die Zustandsdatenstruktur kann verfolgen, welche Arten von Werten erforderlich sind und ob die Werte geliefert worden sind. Der Dialogzustand kann auch Angaben von vorherigen Antworten als akzeptierte Systemantworten (z. B. an den Anwender gelieferte Antworten) enthalten. Die Kandidatenliste 150 wird in dem Speicher gespeichert und von dem Dialog-Host 120 gepflegt. Die Kandidatenliste 150 repräsentiert Kandidatenantworten und ihre entsprechenden Zustände, die von dem Dialogmischer 130 empfangen werden.
  • Eine Kandidatenantwort in der Kandidatenliste 150 kann eine Systemantwort sein, die eine durchzuführende Aktion und/oder eine an den Anwender zu liefernde Antwort bereitstellt. Eine Kandidatenantwort kann auch eine auszuführende Backend-Anforderung sein. Die Backend-Anforderung kann einem Dialogschema, oder mit anderen Worten einem bestimmten Dialogmanager 170, zugeordnet sein. Beispielsweise können ein Dialogmanager 170a für das Kochen, ein Dialogmanager 170b für lokale Wegbeschreibungen, ein Dialogmanager 170c für Musik, ein Dialogmanager 170d für die Zeit usw. vorhanden sein. Der Dialogmanager 170 kann somit eine beliebige Anzahl verschiedener Dialogmanager (z. B. 170a bis 170n) enthalten. Der Dialog-Host 120 kann die Einstufungs-Engine 122 und/oder die Auslöse-Engine 124 verwenden, um zu bestimmen, ob die Backend-Anforderung ausgeführt werden soll oder nicht. Wenn beispielsweise die Anforderung in dem Musikschema nach „Cry“ suchen soll, kann dies eine Suche darstellen, die wahrscheinlich keine einzige Antwort liefert und somit eine Verschwendung von Ressourcen darstellt, da das Ziel eines Dialog-Hosts darin besteht, eine einzige relevante Antwort zu liefern. Alternativ kann der Dialog-Host 120 dann, wenn die Anforderung lautet, in Musik „Cry me a river“ zu suchen, entscheiden, die Anforderung auszuführen, was zu einer Backend-Antwort führen wird, die an den Dialog-Host 120 geliefert wird. Die Zustandsdatenstruktur kann verfolgen, ob der Kandidat eine Anforderung oder eine Antwort ist, was es dem Dialog-Host 120 ermöglicht, zu bestimmen, ob Anforderungen unerledigt sind oder nicht.
  • Der Dialog-Host 120 enthält eine Einstufungs-Engine 122 und eine Auslöse-Engine 124. Die Einstufungs-Engine 122 kann Kandidatenantworten, die von dem Dialogmischer 130 geliefert werden, einstufen. Die Einstufungs-Engine 122 kann Kandidatenantworten mit einer niedrigen A-posteriori-Wahrscheinlichkeit stutzen. Mit anderen Worten kann Einstufungs-Engine 122 bestimmen, ob es unwahrscheinlich ist, dass eine bestimmte Kandidatenantwort als eine gute Antwort ausgewählt wird und an den Anwender geliefert wird. Zum Beispiel liefert der Dialogmischer 130 in einigen Implementierungen einen Ausfallkandidaten und einen Backend-Anforderungs-Kandidaten an den gleichen Dialogmanager, z. B. den Dialogmanager 170a, und die Einstufungs-Engine 122 kann den Ausfallkandidaten niedrig einstufen und den Kandidaten stutzen, das die Backend-Anforderung noch nicht ausgeführt worden ist und daher der Ausfallkandidat zu früh kommt. Das Stutzen des Kandidaten bedeutet das Entfernen des Kandidaten aus der Liste der Kandidaten. In einigen Implementierungen behält die Einstufungs-Engine 122 den Ausfallkandidaten bei, bis die entsprechende Backend-Antwort empfangen wird, dieser erhält jedoch bei jedem Einstufungsereignis eine niedrige Einstufung, bevor die entsprechende Backend-Antwort empfangen wird.
  • Die Einstufungs-Engine 122 kann ein maschinengelerntes Modell enthalten, das als Eingaben die Kandidatenantworten in der Kandidatenliste 150 und Vermerke über die Kandidatenantworten nimmt und das als Ausgabe eine Einstufung für jede der Kandidatenantworten liefert. In einigen Implementierungen kann das Einstufungsmodell ein maschinell gelerntes Modell sein. Zum Beispiel kann das Einstufungsmodell ein neuronales Netz mit einem langen Kurzzeitgedächtnis (LSTM), ein neuronales Vorwärtskopplungsnetz, ein Stützvektormaschinen-Klassifizierer (SVM-Klassifizierer) usw. sein, das unter Vorgabe einer Menge von Einstufungssignalen in Form von Vermerken zu den Kandidaten vorhersagen kann, ob ein Kandidat wahrscheinlich für die Präsentation an den Anwender ausgewählt wird. In einigen Implementierungen kann das Einstufungsmodell auf einem Server trainiert und an die Rechenvorrichtung 105 geliefert werden. In einigen Implementierungen kann der Dialog-Host 120 dazu ausgelegt sein, das Einstufungsmodell mit Anwenderantworten auf Kandidaten, die an den Anwender geliefert werden, weiter zu trainieren. Wenn beispielsweise ein Kandidat ausgewählt wird und dem Anwender präsentiert wird, der Anwender jedoch Ablehnung zeigt, kann der Kandidat (und sein entsprechender Zustand, einschließlich Vermerken) als negatives Trainingsbeispiel für das Modell gekennzeichnet werden. Ebenso kann das System Antworten, für die der Anwender Zustimmung zeigt, als positive Trainingsbeispiele verwenden. Die Einstufungspunktzahl kann als eine Vertrauenspunktzahl betrachtet werden, die angibt, wie zuversichtlich das Modell ist, dass der Antwortkandidat eine relevante Antwort von hoher Qualität ist.
  • Die Vermerke können Eigenschaften des Echtzeit-Streaming-Stücks enthalten, die durch Sprachanalyse erhalten werden. Zum Beispiel können die Vermerke angeben, ob das Stück eine steigende Intonation enthält. Als ein weiteres Beispiel können die Vermerke angeben, ob der Sprecher aufgehört hat, zu sprechen, und wenn ja, wie lange. Als ein weiteres Beispiel können die Vermerke angeben, ob das Stück einen Fülllaut enthält oder wie viel des Stücks Fülllaut ist. Ein Fülllaut ist ein Laut, der signalisiert, dass der Sprecher in Wirklichkeit pausiert. Zum Beispiel ist [ähm] ein verbaler Fülllaut. Als ein weiteres Beispiel kann ein Vermerk die Lautstärke der Sprache angeben, z. B. eine Angabe, ob der Sprecher schreit oder anderweitig Frustration vermittelt. Das System kann eine herkömmliche Sprachanalyse des Stücks verwenden, um die Vermerke bereitzustellen.
  • Die Einstufungs-Engine 122 kann auch Antwortkandidaten aus der Kandidatenliste stutzen. Die Einstufungs-Engine 122 kann einen Kandidaten, der zu alt ist, stutzen. Die Einstufungs-Engine 122 kann auch einen Backend-Anforderungs-Kandidaten stutzen, der rechenintensiv ist, aber wenig Erfolgschancen hat, z. B. weil die Suche zu breit ist. Die Einstufungs-Engine 122 kann einen Kandidaten stutzen, der nicht passt, z. B. einen Ausfallkandidaten. Ein Ausfallkandidat ist eine Kandidatenantwort, die als Standardantwort bereitgestellt wird und angibt, dass der bestimmte Dialogmanager die Anforderung nicht verstehen konnte oder keine bessere Antwort liefern konnte. Im Allgemeinen kann das System jegliche Antwortkandidaten stutzen, bei denen das System davon überzeugt ist, dass sie übertroffen werden. Die Einstufungs-Engine 122 kann auch alle Kandidaten, die aufgrund von neuen Informationen (z. B. zusätzlichen Eingaben) wahrscheinlich nicht korrekt sind, stutzen. Mit anderen Worten kann die Einstufungs-Engine 122, sobald das System von einer Interpretation überzeugt ist, Kandidatenantworten, die sich auf die anderen Interpretationen beziehen, stutzen.
  • Der Dialog-Host 120 kann auch eine Auslöse-Engine 124 enthalten. Die Auslöse-Engine 124 kann entscheiden, ob tatsächlich einer der Top-Kandidaten als Antwort an den Anwender geliefert wird, z. B. über die Eingabe-/Ausgabe-Vorrichtungen 110. Wenn die Auslöse-Engine 124 eine Antwort liefert, kann sie einen Basiszustand für den Dialog aktualisieren. Der Basiszustand repräsentiert einen Zustand, auf den sich das System festgelegt hat, z. B. einen Zustand, für den das System eine Antwort geliefert hat. Sobald die Auslöse-Engine 124 eine Antwort liefert, kann sie somit den vorläufigen Zustand des Kandidaten, der als Antwort auf den Basiszustand an den Anwender geliefert wird, verschieben oder befördern. In einigen Implementierungen kann die Auslöse-Engine 124 ein maschinengelerntes Modell sein. Zum Beispiel kann die Auslöse-Engine 124 ein neuronales Netz mit einem langen Kurzzeitgedächtnis (LSTM), ein neuronales Vorwärtskopplungsnetz, ein Stützvektormaschinen-Klassifizierer (SVM-Klassifizierer) usw. sein, der entweder keine Aktion auswählt oder eine Antwort unter den Kandidatenantworten auswählt. Die Auslöse-Engine 124 kann als eine gültige Antwort auf ein Auslöseereignis keine Aktion oder mit anderen Worten keine Antwort auswählen. Ob die Auslöse-Engine 124 keine Aktion auswählt, hängt von dem Kontext des Auslöseereignisses und den Kandidatenantworten in der Kandidatenliste ab. Die Auslöse-Engine 124 kann auch einen der Systemantwortkandidaten in der Kandidatenliste als Antwort auf ein Auslöseereignis auswählen. Wenn das Modell einen Kandidaten auswählt, kann die Auslöse-Engine 124 die ausgewählte Systemantwort zur Präsentation für den Anwender an die Eingabe-/Ausgabe-Vorrichtungen 110 liefern. Die Präsentation für den Anwender kann eine Aktion umfassen, die von der Rechenvorrichtung 105 ausgeführt wird, wie beispielsweise ein Abspielen von Audiodateien, ein Abspielen von Videodateien, ein Bereitstellen von Text auf einer Anzeige und/oder ein Aufrufen einer Anwendung. Als Beispiel kann ein Bereitstellen eines Kandidaten mit einer Systemantwort [Abspielen von Cry me a river] veranlassen, dass das Rechensystem 105 eine Audioausgabe [Abspielen von Cry me a river] liefert, eine Medienanwendung öffnet und beginnt, ein Lied mit dem Titel „Cry me a river“ abzuspielen.
  • Abhängig von der Antwort kann das Liefern des Kandidaten als Antwort andere Aktionen umfassen, wie z. B. ein Hinzufügen eines Kalenderereignisses, ein Einstellen eines Zeitgebers, ein Hinzufügen eines Kontakts, ein Einstellen eines Alarms, ein Abspielen eines Films, ein Abspielen eines Hörbuchs usw.
  • Das Echtzeit-Dialogmanagementsystem 100 enthält einen Dialogmischer 130. Der Dialogmischer 130 ist dazu ausgelegt, als Eingaben einen Basiszustand und Informationen über ein Auslöseereignis (z. B. eine Backend-Antwort, eine neue Eingabe, ein Verstreichen einer Zeit) zu nehmen. Der Basiszustand umfasst den aktuellen Konversationskontext einschließlich Dialogzuständen (z. B. aus den Zustandsdatenstrukturen) für alle zuletzt akzeptierten Kandidaten in dem Pfad des Dialogstrahls. Die Informationen über das Auslöseereignis können Text von dem Anwender, beispielsweise aus einem Eingabestromfenster oder über ein Textfeld usw., enthalten. Die Informationen über das Auslöseereignis können auch einen Zeitstempel für das Ereignis enthalten.
  • Der Dialogmischer 130 liefert als Ausgabe eine oder mehrere Kandidatenantworten. Eine Kandidatenantwort kann eine Systemantwort sein. Bei einer Systemantwort handelt es sich um Text, der als Teil der Konversation bereitgestellt werden soll, und beliebige Aktionen, die das System 100 vornehmen soll. Eine Systemantwort ist optional und ist nicht immer in den von dem Dialogmischer 130 gelieferten Kandidaten enthalten. Eine Kandidatenantwort kann eine Backend-Anforderung sein, deren Ausführung durch den Host von dem Dialogmischer 130 gewollt ist. Die Backend-Anforderung identifiziert das Schema oder den Dialogmanager, an den die Anforderung gerichtet ist, sowie die Anfrage, die ausgeführt werden soll. In einigen Implementierungen wird die Anfrage als eine Strahlsuche verarbeitet. Eine Backend-Anforderung ist ebenfalls optional und ist nun immer in den Kandidaten, die durch den Dialogmischer 130 geliefert werden, enthalten. Der Dialogmischer 130 liefert allerdings mindestens eine Systemantwort oder eine Backend-Anforderung für jedes Auslöseereignis. Für jede Kandidatenantwort stellt der Dialogmischer 130 auch einen vorläufigen Dialogzustand bereit. Der vorläufige Zustand kann die hierin erörterte Zustandsdatenstruktur verwenden. Der vorläufige Zustand kann als Teil eines Basiszustands, der an den Dialogmischer130 geliefert wird, in einem folgenden Aufruf an den Dialogmischer 130 verwendet werden, wenn der Kandidat akzeptiert wird. Zum Beispiel wird der mit einer Backend-Anforderung bereitgestellte vorläufige Zustand als Basiszustand für eine Backend-Antwort auf die Backend-Anforderung bereitgestellt. Zuletzt stellt der Dialogmischer 130 auch für jede Kandidatenantwort Vermerke über die Kandidaten bereit. Die Vermerke werden als Signale zum Einstufen verwendet und können auch beim Protokollieren verwendet werden.
  • Wenn der Dialogmischer 130 aufgerufen wird, akzeptiert er die Basisdialogzustände, die in der Eingabe bereitgestellt werden. Wenn das Auslöseereignis eine neue Eingabe ist, bestimmt der Dialogmischer 130, ob der Anwender einen neuen Dialog auslöst. Ein neuer Dialog entspricht einem neuen Dialogmanager, beispielsweise einem neuen Schema oder einer neuen Suche in einem Dialogschema. Wenn der Anwender einen neuen Dialog auslöst, greift der Dialogmischer 130 auf das entsprechende Schema zurück und startet den Dialogmanager für das Schema. Der Dialogmischer 130 verteilt dann die Ausgabe des Parsers für natürliche Sprache, der auch als Analysator bezeichnet wird, an alle Dialogmanager. Wenn das Auslöseereignis eine Backend-Antwort ist, lädt der Dialogmischer 130 den Dialogmanager, der der Backend-Antwort entspricht, und wendet die Backend-Antwort jeweils auf die Dialogmanager an, die sie anfordert. Der Dialogmischer 130 kann die Dialogmanager um Backend-Anforderungen und neue Zustands-Token bitten. Jeder aufgeforderte Dialogmanager erzeugt irgendeine Antwort, selbst wenn es ein Fehler oder eine fehlerhafte Antwort ist. In einigen Implementierungen kann der Dialogmanager 130 auch eine Backend-Anforderung ausgeben. Der Dialogmischer 130 krempelt jede Ausgabe eines Dialogmanagers, ob es eine Systemantwort oder eine Backend-Anforderung ist, in einen Antwortkandidaten um. Jeder Kandidat weist eine Kombination aus einer oder mehreren Systemantworten und/oder Backend-Anforderungen und einem vorläufigen Dialogzustand auf. In einigen Implementierungen kann der Dialogmischer 130 eine zweite Phase der Kandidatenerzeugung durchführen. In der zweiten Phase der Kandidatenerzeugung kann der Dialogmischer 130 eine zusammengesetzte Kandidatenantwort aus zwei oder mehr individuellen Schemata ableiten. Der Dialogmischer 130 liefert die Kandidatenantwort(en), einen jeweiligen Dialogzustand für jede Kandidatenantwort und Vermerke für jede Kandidatenantwort zurück an den Dialog-Host 120, in dem die Antworten eingestuft werden, gestutzt werden und möglicherweise eine Antwort ausgelöst wird und an die Eingabe-/Ausgabe-Vorrichtungen 110 geliefert wird.
  • Das Echtzeit-Dialogmanagementsystem 100 kann auch mehrere Dialogmanager 170a-170n enthalten. Jeder Dialogmanager ist für einen einzelnen Dialogstrang verantwortlich und stellt ein durchsuchbares Schema dar. Zum Beispiel kann der Dialogmanager 170a ein Musikdialog zum Durchsuchen einer digitalen Musikbibliothek sein. Der Dialogmanager 170b kann ein lokaler Dialog zum Durchsuchen lokaler Interessensbereiche, z. B. „Restaurants in meiner Nähe“, und zum Bereitstellen von Wegbeschreibungen für ein bestimmtes Gebiet von Interesse sein. Der Dialogmanager 170c kann ein Kalenderdialog sein, der dazu in der Lage ist, Termine zu finden, neue Termine zu vereinbaren, Erinnerungen für einen Termin zu platzieren etc. Jeder Dialogmanager ist dazu ausgelegt, die bereitgestellte Eingabe zu betrachten und zu bestimmen, ob die Eingabe dem Schema entspricht. Zum Beispiel kann die Eingabe [Bring mich zu] für einen Essensdialogmanager nicht ähnlich genug sein, um eine Suche in dem Schema auszulösen, doch sie kann für einen lokalen Dialogmanager und einen Musikdialogmanager ähnlich genug sein, um Backend-Anforderungen auszulösen und auszugeben.
  • Das Echtzeit-Dialogmanagementsystem 100 kann Backend-Systeme 190 enthalten. Die Backend-Systeme 190 stellen durchsuchbare Datenbestände dar, die Antworten für einen bestimmten Dialogmanager bereitstellen. Zum Beispiel kann der Musikdialogmanager 170a einen Musikserver aufrufen, um nach Titeln, Künstlern, Alben etc. zu suchen, und kann Musik aus den Beständen abspielen. In einigen Implementierungen sind die Bestände lokal für die Rechenvorrichtung, wie es in 1 gezeigt ist. In einigen Implementierungen sind die Bestände entfernt, z. B. befinden sie auf einem oder mehreren Servern, wie es in 2 gezeigt ist.
  • 2 ist ein Blockdiagramm, das ein weiteres beispielhaftes System 100 gemäß dem offenbarten Gegenstand zeigt. In dem Beispiel von 2 enthält das Echtzeit-Dialogmanagementsystem 100 einen Server 210, der eine oder mehrere Rechenvorrichtungen, die die Form einer Reihe von verschiedenen Vorrichtungen annehmen können, wie beispielsweise ein Standardserver, eine Gruppe solcher Server oder ein Rack-Serversystem sein kann. Zum Beispiel kann der Server 210 auf eine verteilte Weise über mehrere Rechenvorrichtungen hinweg implementiert sein. Zusätzlich kann der Server 210 in einem PC wie beispielsweise einem Laptop-Computer implementiert sein. Der Server 210 kann ein Beispiel einer Rechenvorrichtung 500, wie sie in 5 gezeigt ist, oder eines Systems 600, wie es in 6 gezeigt ist, sein. Das Echtzeit-Dialogmanagementsystem kann eine Clientvorrichtung 205 enthalten. Die Clientvorrichtung 205 ist ähnlich der in Bezug auf 1 beschriebenen Clientvorrichtung 105. Somit enthält die Clientvorrichtung 205 die Dialog-Eingabe-/Ausgabe-Vorrichtungen 110, den Dialog-Host 120, den Dialogmischer 130 und die Kandidatenliste 150. In dem Beispiel von 2 enthält der Server 210 die Dialogmanager 170 und die Backend-Systeme 190. In dem Beispiel von 2 kommuniziert der Clientserver 205 mit dem Server 210 und mit den anderen Clientvorrichtungen 190 über das Netz 140. Das Netz 140 kann beispielsweise das Internet sein oder das Netz 140 kann ein drahtgebundenes oder drahtloses lokales Netz (LAN), ein Weitbereichsnetz (WAN) etc. sein, das beispielsweise unter Verwendung von Gateway-Vorrichtungen, Brücken, Schaltern und/oder so weiter implementiert ist. Über das Netz 140 kann der Server 210 mit der Clientvorrichtung 205 kommunizieren und Daten an die/aus der Clientvorrichtung 205 übermitteln.
  • Das Echtzeit-Dialogmanagementsystem 100 von 1 und von 2 repräsentiert beispielhaft Konfigurationen, aber Implementierungen können andere Konfigurationen beinhalten. Zum Beispiel können einige Implementierungen nur die Backend-Systeme 190 auf dem Server 210 aufweisen oder können einige der Backendsysteme 190 auf dem Server 210 und einige auf der Clientvorrichtung 205 aufweisen. Einige Implementierungen können einige der Dialogmanager 170 auf der Clientvorrichtung 205 und einige auf dem Server 210 aufweisen. Einige Implementierungen können den Dialogmischer 130 oder einige Funktionalitäten des Dialogmischers 130 auf den Server 210 verschieben. Einige Implementierungen können den Dialog-Host 120 auf den Server 210 verschieben. Einige Implementierungen können die Dialog-Eingabe-/Ausgabe-Vorrichtungen 110, den Dialog-Host und /oder den Dialogmischer 130 und die Dialogmanager 170 in einem einzigen Modul oder einer einzigen Anwendung kombinieren.
  • In dem Maß, in dem das Echtzeit-Dialogmanagementsystem 100 anwenderspezifische Daten sammelt und speichert oder Gebrauch von persönlichen Informationen machen kann, kann der Anwender mit der Möglichkeit ausgestattet werden, zu steuern, ob Programme oder Merkmale Anwenderinformationen sammeln, oder zu steuern, ob und/oder wie Inhalt empfangen werden soll, der für den Anwender relevanter sein kann. Zusätzlich können bestimmte Daten auf eine oder mehrere Weisen behandelt werden, bevor sie gespeichert oder verwendet werden, so dass personenbezogene Informationen entfernt werden. Zum Beispiel können Suchaufzeichnungen so behandelt werden, dass keine personenbezogenen Informationen bestimmt werden können, und/oder ein geografischer Ort eines Anwenders kann verallgemeinert werden, wobei Ortsinformationen (wie beispielsweise eine Stadt, Postleitzahl oder Landesebene) so erhalten werden, dass ein bestimmter Ort eines Anwenders nicht bestimmt werden kann. Somit kann der Anwender Kontrolle darüber haben, wie Informationen über den Anwender gesammelt und durch ein Echtzeit-Dialogmanagementsystem 100 verwendet werden.
  • 3 zeigt ein Ablaufdiagramm eines beispielhaften Prozesses 300 zum Managen eines Echtzeit-Dialogs gemäß offenbarten Implementierungen. Der Prozess 300 kann durch ein Echtzeit-Dialogmanagementsystem wie etwa das System 100 von 1 und 2 durchgeführt werden. In einigen Implementierungen wird der Prozess 300 durch einen Dialog-Host wie etwa den Dialog-Host 120 ausgeführt. Der Prozess 300 kann dazu verwendet werden, einen Dialogmischer als Antwort auf ein Auslöseereignis aufzurufen, um zu bestimmen, welche Eingabe an den Dialogmischer geliefert wird, eine Liste von Kandidaten aus Kandidaten, die durch den Dialogmischer bereitgestellt werden, zu managen und zu entscheiden, ob eine Kandidatenantwort an den Anwender geliefert werden soll oder ob sich ruhig verhalten und auf weitere Eingaben gewartet werden soll.
  • Der Prozess 300 kann eine Hauptschleife für ein Echtzeit-Dialogmanagementsystem repräsentieren. Somit kann der Prozess 300 kontinuierlich laufen, während das Dialogsystem aktiv ist. Der Prozess 300 kann einen Wartemodus umfassen, in dem das System auf ein Auslöseereignis wartet (305). Der Wartemodus kann durch ein Auslöseereignis unterbrochen werden (310-320). Ein Auslöseereignis ist ein Empfang einer Backend-Antwort (310). Die Backend-Antwort ist eine Systemantwort, die durch eine Backend-Anforderung erzeugt wird. Die Backend-Antwort enthält die Systemantwort und identifiziert einen Dialogmanager, der die Anforderung handhabt. Ein anderes Auslöseereignis ist der Empfang einer neuen Eingabe (315). Die Eingabe kann Sprache sein, die von dem Anwender in einem gleitenden Fenster aufgenommen wird. Die Eingabe kann Text sein, der durch den Anwender eingegeben wird. Die Eingabe kann eine durch den Anwender vorgenommene Auswahl sein. Während der Anwender spricht, kann das System periodisch, beispielsweise alle 100 Millisekunden, eine neue Eingabe bereitstellen. Das gleitende Fenster kann bis zu einer vorbestimmten Anzahl vorheriger Eingaben beinhalten. Somit kann beispielsweise eine anfängliche Eingabe für das gleitende Fenster „spiel Cry“ sein und eine nächste Eingabe für das gleitende Fenster kann „me a river“ sein, was die Eingabe „spiel Cry me a river“ für das gleitende Fenster ergibt. Ein weiteres Auslöseereignis ist der Ablauf einer Zeit (320). Das System kann dieses Ereignis auslösen, wenn keine Backend-Antwort und keine neue Eingabe innerhalb einer vorbestimmten Zeitspanne empfangen worden ist. Dieses Auslöseereignis ermöglicht es dem System, den Dialog bei Abwesenheit anderer Auslöseereignisse voranzubringen.
  • Als Antwort auf ein Auslöseereignis kann das System den Basiszustand für das Auslöseereignis bestimmen (330). Der Basiszustand beschreibt den aktuellen Konversationskontext für ein Auslöseereignis. Der Basiszustand kann ein einzelner Dialogzustand oder mehrere Dialogzustände sein. Der Basiszustand umfasst die Dialogzustände von allen akzeptierten Kandidaten in der Kandidatenliste für einen bestimmten Dialogpfad. Ein Systemantwort-Kandidat wird akzeptiert, wenn er ausgelöst wird oder mit anderen Worten als Antwort an den Anwender geliefert wird. Ein Backend-Anforderungs-Kandidat wird akzeptiert, wenn die Backend-Anforderung ausgeführt wird. Ein Dialogpfad startet mit einem Stammzustand und umfasst jeden Kandidaten, der akzeptiert ist oder aussteht, bis das System zurückfällt. Sobald das System zu einem Vorgängerknoten in dem Pfad zurückfällt, der den Basiszustand für den neuen Pfad darstellt, zweigt der neue Dialogpfad von dem aktuellen Pfad in dem Vorgängerknoten ab. Der Vorgängerkonten kann der Stammknoten in dem Dialogstrahl sein, muss aber nicht der Stammkonten sein.
  • Als Teil des Bestimmens des Basiszustands des Auslöseereignisses muss das System bestimmen, welcher Dialogpfad dem Auslöseereignis entspricht. Dies kann ein aktueller Pfad sein oder kann ein neuer Pfad sein, der gestartet wird, weil das System sich dazu entscheidet, zurückzufallen. Zum Beispiel startet das System einen zweiten Dialogpfad, wenn eine zusätzliche Eingabe ändert, was die Anforderung, die an einen oder mehreren Dialogmanager geliefert wird, ist (z. B. wird der Strahlsuchestring aktualisiert). Der Dialogpfad gabelt sich in dem Vorgängerknoten, auf den das System zurückfällt, oder zweigt dort von dem aktuellen Pfad ab. Das System kann somit mehrere Pfade managen, die von irgendeinem Basiszustand abzweigen, und kann Entscheidungen (z. B. Einstufungs- und Auslöse-Entscheidungen) zwischen den Pfaden treffen. Das System kann zudem einen Pfad stutzen, wenn die Kandidaten in dem Pfad veraltet oder niedrig eingestuft werden. Die Dialogzustände können eine Angabe enthalten, zu welchem Pfad der Zustand gehört. Der Dialogpfad kann konkurrierende Kandidaten aus verschiedenen Dialogmanagern enthalten, so dass der Basiszustand mehr als einen Dialogzustand, z. B. jeweils einen anderen Dialogzustand für verschiedene Dialogmanager, umfasst. Der Dialogzustand kann in einer Zustandsdatenstruktur gespeichert sein, die oben in Bezug auf 1 beschrieben wurde.
  • Der Dialog-Host kann den Basiszustand und die Auslöseereignisinformationen an den Dialogmischer senden (335). Die Auslöseereignisinformationen hängen von dem Typ des Auslöseereignisses ab. Zum Beispiel enthalten die Auslöseereignisinformationen dann, wenn das Auslöseereignis eine Backend-Antwort ist, die empfangene Backend-Antwort. Wenn das Auslöseereignis der Empfang einer neuen Eingabe ist, sind die Auslöseereignisinformationen die empfangene Eingabe, eine Eingabe in einem gleitenden Fenster (wobei das Fenster die empfangene Eingabe enthält), ein empfangener Text oder eine andere empfangene Eingabe. Wenn das Auslöseereignis der Ablauf der Zeit ist, kann die Eingabe ein aktueller Zeitstempel sein.
  • Das System kann dann potentielle Kandidaten von dem Dialogmischer empfangen. Ein potentieller Kandidat kann eine Systemantwort sein. Eine Systemantwort ist etwas, das das System sagt (z. B. über eine Ausgabevorrichtung bereitstellt) und/oder tut (z. B. ein Lied abspielen, einen Zeitgeber setzen, einen Gegenstand kaufen etc.). Ein potentieller Kandidat kann eine Backend-Anforderung sein. Eine Backend-Anforderung kann eine Anfrage in einem bestimmten Dialogschema darstellen. Somit kann eine Backend-Anforderung an einen Dialogmanager für das Schema geliefert werden. Der Dialogmanager kann die Anfrage an ein Backend-System übermitteln und eine Antwort formulieren. Ein Empfang der Antwort durch den Dialog-Host ist ein Auslöseereignis. Somit enthält ein Backend-Anforderungs-Kandidat eine Kennung, die dazu verwendet wird, die Antwort an den jeweiligen Kandidaten anzupassen. Jeder potentielle Kandidat weist einen entsprechenden vorläufigen Dialogzustand auf. Jeder potentielle Kandidat kann auch jeweilige Vermerke oder Metadaten aufweisen, die durch das System zum Einstufen und Stutzen potentieller Kandidaten verwendet werden können. Die Vermerke oder Metadaten können auch beim Protokollieren verwendet werden.
  • Das System stuft die potentiellen Kandidaten ein, wobei schlechte Kandidaten gestutzt werden (345). Das Einstufen findet über alle Zweige hinweg statt, nicht nur in dem Zweig, der in Schritt 330 ausgewählt wurde. Das Einstufen kann ein maschinengelerntes Modell umfassen, das die Vermerke und Metadaten über die potentiellen Kandidaten als Eingabe hernimmt und einen Wert für jeden potentiellen Kandidaten ausgibt. Das Modell kann dazu trainiert sein, als Eingabe eine Liste potentieller Kandidaten in allen Zweigen, ihre Zustände und die Vermerke zu verwenden. Die Einstufung führt dazu, dass einige Kandidaten gestutzt werden. Ein gestutzter Kandidat kann von der Kandidatenliste entfernt werden. Ein gestutzter Kandidat kann auch als gestutzt oder nicht aktiv gekennzeichnet werden. Ein Kandidat kann gestutzt werden, weil er zu alt ist, weil er ein Duplikat eines anderen Kandidaten ist, weil er zu rechenintensiv ist (z. B. weil die Anfrage zu weitläufig ist und der Anwender immer noch spricht). All dies kann zu einer schlechten Einstufungspunktzahl führen, also beispielsweise einer, die einer Einstufungsschwelle nicht genügt (z. B. diese nicht erreicht oder überschreitet). Ein gestutzter Kandidat wird in der Liste der Kandidaten nicht mehr beachtet, d. h. er wird nicht mehr als Antwortkandidat betrachtet.
  • Das System entscheidet dann, ob einer der Kandidaten in der Liste von Kandidaten ausgelöst wird (350). Die Auslöseentscheidung kann auch ein maschinengelerntes Modell verwenden, das jedem der Kandidaten in der Liste eine Vertrauenspunktzahl zuweist. In einigen Implementierungen kann die Vertrauenspunktzahl die dem Kandidaten zugordnete Einstufung sein. Die Vertrauenspunktzahl kann repräsentieren, wie sicher sich das System ist, dass der Kandidat zu dem Zeitpunkt ein angemessener ist. Mit anderen Worten besteht für das System eine Unsicherheit darüber, ob es überhaupt einen Kandidaten als Antwort liefern soll. Dies unterscheidet sich von einem Sprecherwechsel-Dialogsystem, bei dem das System immer einen der Antwortkandidaten für ein Auslöseereignis liefert. In dem Echtzeit-Dialogsystem ist das System fortlaufend daran zu bestimmen, ob es antworten soll, wobei die Option, gar nicht zu antworten, eine gültige Bestimmung ist. Das System kann eine Vielzahl von Eingabesignalen verwenden, um eine Vertrauenspunktzahl für jeden Kandidaten zu berechnen. Die Eingabesignale können beinhalten, ob die letzte verbale Eingabe von dem Anwender eine ansteigende Intonation hatte. Eine ansteigende Intonation ist ein Faktor, um anzugeben, dass der Anwender eine Frage beendet hat. Die Eingabesignale können beinhalten, wie lange der Anwender still gewesen ist. Eine kurze Stille kann bedeuten, dass der Anwender nachdenkt.
  • Eine längere Stille kann anzeigen, dass der Anwender auf irgendeine Antwort wartet oder Hilfe benötigt. Zum Beispiel hat, wenn die Eingabe des gleitenden Fensters [Spiel das Lied von Boston aus dem Jahr 1978 mit dem Namen] ist, kann das System schon eine Kandidaten-Systemantwort [More than a feeling abspielen] erzeugt haben. Wenn der Anwender allmählich verstummt, weil er beispielsweise versucht, an den Titel zu denken, kann das System den Kandidaten auslösen. Die Eingabesignale können die Länge des gleitenden Fensters umfassen oder wie lange der Anwender gesprochen hat, ohne eine Antwort auszulösen. Wenn der Anwender eine Zeit lang gesprochen hat, ohne eine Antwort auszulösen, kann das System einen Rückkanal-Kandidaten auslösen. In einigen Implementierungen kann die Liste der Kandidaten einen Rückkanal-Rückmeldungskandidaten als Standardkandidaten enthalten. Der Rückkanal-Kandidat repräsentiert eine beliebige Rückmeldung durch das System, die angibt, dass das System zuhört, wobei der Dialog allerdings hauptsächlich in eine Richtung geht, d. h. der Anwender spricht. Zum Beispiel kann ein Rückkanal-Rückmeldungskandidat [aha], [hmm] oder [stimmt] oder irgendein anderer Ausdruck sein, der Aufmerksamkeit oder Verständnis anzeigt.
  • Das System kann einen Systemantwort-Kandidaten auslösen, wenn der Systemantwort-Kandidat eine Vertrauenspunktzahl aufweist, die eine Auslöseschwelle erfüllt (erreicht oder überschreitet). Das System kann den Systemantwort-Kandidaten auch auslösen, wenn der Systemantwort-Kandidat eine Einstufung hat, die die Auslöseschwelle erfüllt. Wenn das System entscheidet, keinen Antwortkandidaten auszulösen (350, Nein), kann das System irgendwelche Backend-Anforderungen initiieren, z. B. ausführen, die Kandidaten sind und noch nicht akzeptiert worden sind (355). Alle Backend-Anforderungen, die zu diesem Zeitpunkt noch in der Kandidatenliste sind, werden akzeptiert. In einigen Implementierungen kann das System (z. B. über einen Merker in der Kandidatenliste) zurückverfolgen, welche Backend-Anforderungen noch ausstehend sind. Das System kann dann in den Wartezustand zurückkehren (305).
  • Wenn das System entscheidet, einen Kandidaten auszulösen (350, Ja), kann das System die Systemantwort durchführen (360). Nur ein Kandidat, der eine Systemantwort ist, kann ausgelöst werden, weil nur die Systemantworten eine Ausgabe zum Liefern an den Anwender aufweisen. Die Ausgabe kann etwas sein, das an eine Ausgabevorrichtung geliefert wird, wie beispielsweise gesprochener oder angezeigter Text. Die Ausgabe kann eine Aktion sein, die die Rechenvorrichtung durchführt, wie beispielsweise das Abspielen einer Mediendatei. Ein Systemantwort-Kandidat, der ausgelöst wird, ist ein akzeptierter Kandidat. Wenn der ausgelöste Kandidat ein Rückkanal-Kandidat ist (365, Ja), kann das System wie oben erklärt irgendwelche akzeptierte Backend-Anforderungen initiieren (355), so dass das System darauf warten kann, dass der Anwender weiterredet, und entscheiden kann, ob es später eine konkretere Antwort bereitstellt. Wenn der ausgelöste Kandidat kein Rückkanal-Kandidat ist (365, Nein), kann das System alle nicht ausgelösten Zweige bereinigen (370). Dies kann ein Setzen eines neuen Stammzustands oder neuen Basiszustands und ein Entfernen der Kandidaten von der Liste umfassen. Das System kann dann in den Wartezustand (505) für das nächste Auslöseereignis eintreten.
  • Das Folgende ist ein Beispiel-Echtzeitdialog, um den Prozess 300 zu veranschaulichen. In dem Beispiel ist eine durch den Anwender gelieferte Eingabe (z. B. über ein Mikrofon oder eine Tastatur) in eckigen Klammern [ ] dargestellt, genau wie die Audioausgabe, die von dem System geliefert wird. Durch das System vorgenommene Aktionen sind in geschweiften Klammern { } dargestellt. Dieses Beispiel ist nur zum Zweck der Veranschaulichung bereitgestellt. In dem vorliegenden Beispiel beginnt der Dialog-Host mit einer leeren Kandidatenliste, daher ist der Stammzustand null oder leer. Anfangs empfängt der Dialog-Host ein Streaming-Stück [Bring mich zur Kirche] als aktuelle Eingabe beispielsweise bei 315. Da es keine Kandidaten in der Liste gibt, ist der Basiszustand null. Somit sendet der Dialog-Host einen leeren Basiszustand oder Null-Basiszustand und die Eingabe „Bring mich zur Kirche“ an den Dialogmischer. Der Dialogmischer bestimmt, dass die Eingabe zu zwei Dialogmanagern passt; einem Mediendialogmanager und einem Lokal-Dialogmanager. Der Dialogmischer stellt wie in Tabelle 1 gezeigt vier potentielle Kandidaten bereit. Alle Kandidaten von Tabelle 1 sind in Pfad 1, weil sie aus demselben Basiszustand (z. B. dem Nullzustand) stammen und dieselbe Eingabe (z. B. „Bring mich zur Kirche“) suchen. Tabelle 1
    Pfad Kandidat Dialogzustand Dialogmanager Kennung
    1 LokalSuche („Bring mich zur Kirche“) L1 Lokal Lokal1
    1 MedienSuche („Bring mich zur Kirche“) M1 Medien Medien1
    1 [Leider kein Nachschlagen von Wegbeschreibungen möglich] L2 Lokal Lokal2
    1 [Leider kein Nachschlagen in deinen Medien möglich] M2 Medien Medien2
  • Der Dialog-Host stuft die vier potentiellen Kandidaten Lokal1, Lokal2, Medien1 und Medien2 ein. Das Einstufen kann über ein maschinengelerntes Modell, das die vier Kandidaten und die jeweiligen Eigenschaften betrachtet, geschehen. Das Modell entscheidet, dass die Kandidaten Lokal2 und Medien2, die Ausfallkandidaten für die jeweiligen Dialogmanager repräsentieren, schlechte Kandidaten sind, weil die anderen zwei Kandidaten Backend-Anforderungen repräsentieren, die noch nicht übermittelt oder ausgeführt sind. Diese zwei Kandidaten haben schlechte Einstufungen und der Dialog-Host stutzt die Kandidaten Lokal2 und Medien2. Somit enthält die Kandidatenliste nun nur die zwei Backend-Anforderungs-Kandidaten, d. h. Lokal1 und Medien1. Der Dialog-Host bestimmt, dass kein Kandidat zum Auslösen auswählbar ist, weil sie Backend-Anforderungen sind und keine Systemantworten. Wenn die Backend-Anforderungen eine Einstufung aufweisen, die hoch genug ist, beginnt der Dialog-Host ein Ausführen der Backend-Anforderung Lokal1 und der Backend-Anforderung Medien1. Das Beginnen der Ausführung einer Backend-Anforderung ist eine Akzeptanz des Kandidaten. Somit sind der Dialogzustand L1 und der Dialogzustand M1 akzeptierte Zustände. Die Backend-Anforderung Lokal1 entspricht dem Lokal-Dialogmanager, der Wegbeschreibungen und Sehenswürdigkeiten bereitstellt. Der Kandidat Lokal1 repräsentiert eine Suche für die Eingabe (z. B. für „Bring mich zur Kirche“) in dem Lokalschema dar. Ähnlich entspricht der Kandidat Medien1 einem Medien-Dialogmanager, der eine Medienbibliothek durchsucht. Der Kandidat Medien1 repräsentiert eine Suche nach der Eingabe in dem Medienschema. Sobald der Dialog-Host mit der Ausführung der zwei Backend-Anforderungen startet, wartet der Dialog-Host auf ein weiteres Auslöseereignis.
  • Das nächste Auslöseereignis ist die Antwort für den Kandidaten Medien1. Mit anderen Worten gibt der Medien-Dialogmanager ein Ergebnis aus, das der Medien1-Anforderung entspricht. Der Dialog-Host bestimmt, dass die Antwort dem Kandidaten Medien1 entspricht, der Teil von Pfad 1 ist, und bestimmt, dass der Basiszustand den Dialogzustand L1 und den Dialogzustand M1 enthält. Der Zustand L1 ist enthalten, weil die Lokalsuche aussteht, so dass der Dialogzustand L1 noch aktiv ist. Somit liefert der Dialog-Host die Backend-Antwort (eine Backend-Antwort. die dem Kandidaten Medien1 entspricht) und den Basiszustand von L1, M1, an den Dialogmischer. Als Antwort stellt der Dialogmischer wie in Tabelle 2 gezeigt drei potentielle Kandidaten bereit: Tabelle 2
    Pfad Kandidat Dialogzustand Dialogmanager Kennung
    1 LokalSuche („Bring mich zur Kirche“) L3 Lokal Lokal3
    1 [Spiele Bring mich zur Kirche] {Spiel „Bring mich zur Kirche“} M3 Medien Medien3
    1 [Leider kein Nachschlagen von Wegbeschreibungen möglich] L4 Lokal Lokal4
  • Die Kandidat Medien3 ist eine Systemantwort, die an den Anwender die Ausgabe [Spiele Bring mich zur Kirche] liefert und eine Aktion initiiert, die den Medienabspieler dazu veranlasst, zu beginnen, eine entsprechende Medien-Audio- oder Videodatei, die in der Antwort identifiziert ist, abzuspielen. In einigen Implementierungen ersetzt der Dialog-Host den Kandidaten Medien1 in der Kandidatenliste mit dem Kandidaten Medien3, weil der Kandidat Medien3 die Antwort ist, die durch Ausführen der durch den Kandidaten Medien1 repräsentierten Anforderung empfangen wird. In einigen Implementierungen wird der Kandidat Medien1 als abgeschlossen gekennzeichnet, bleibt aber aktiv. Der Dialog-Host stutzt der Kandidaten Lokal3, weil er ein Duplikat des Kandidaten Lokal1 ist, der noch ausgeführt wird. In einigen Implementierungen kann der Dialogmischer erkennen, dass der Kandidat Lokal3 ein Duplikat ist, und kann Lokal3 nicht als potentiellen Kandidaten bereitstellen. Der Dialog-Host stuft den Kandidaten Lokal4 als schlecht ein, weil die Anforderung Lokal1 noch ausgeführt wird. Somit stutzt der Dialog-Host den Kandidaten Lokal4. Dies lässt Lokal1 und Medien3 in der Kandidatenliste übrig. Medien3 ist eine Systemantwort, die zum Auslösen auswählbar ist, doch der Kandidat Medien3 weist eine niedrige Einstufung auf, weil der Anwender noch spricht, der Anwender keine explizite Abspielintention hatte, d. h. die Eingabe war nicht [Spiel Bring mich zur Kirche] war, und eine noch ausstehende Anforderung existiert. Der Dialog-Host entscheidet daher, nicht zu antworten, und löst die Antwort Medien3 nicht aus. Das bedeutet, dass der Kandidat Medien3 nicht akzeptiert wird; vielmehr ist der Kandidat Medien3 ausstehend. Es gibt keine Backend-Anforderungen zum Ausführen, so dass der Dialog-Host auf ein anderes Auslöseereignis wartet.
  • Das nächste Auslöseereignis ist die Ankunft eines weiteren Streaming-Stücks. Die nächste Eingabe ist ein Streaming-Stück [Bring mich mit dem Fahrrad zur Kirche]. Dieses Streaming-Stück repräsentiert ein gleitendes Fenster, das die vorherige Eingabe enthält. Der Dialog-Host bestimmt, dass die neue Eingabe eine neue Strahlsuche sein soll. Mit anderen Worten bestimmt der Dialog-Host, dass die Anfrage spezifischer ist, und beginnt einen zweiten Pfad in dem Dialogstrahl. Der Basiszustand für den neuen Pfad ist leer, d. h. das System fällt auf den Stammzustand zurück und beginnt einen neuen Pfad von dem Stamm aus mit den neuen Suchkriterien „Bring mich mit dem Fahrrad zur Kirche“. Somit sendet der Dialog-Host einen leeren oder Null-Basiszustand und die Eingabe „Bring mich mit dem Fahrrad zur Kirche“ an den Dialogmischer. Der Dialogmischer bestimmt, dass die Eingabe zu dem Lokal-Dialogmanager passt. Der Dialogmischer löst den Medien-Dialogmanager nicht aus, weil die Eingabe sich nicht wie eine Medienanforderung anhört. Somit stellt der Dialogmischer wie in Tabelle 3 gezeigt zwei potentielle Kandidaten bereit. Diese Kandidaten sind in der Kandidatenliste mit den noch aktiven und ausstehenden Kandidaten aus dem ersten Pfad enthalten: Tabelle 3
    Pfad Kandidat Dialogzustand Dialogmanager Kennung
    1 LokalSuche („Bring mich mit dem Fahrrad zur Kirche“) LB1 Lokal LokalB1
    1 [Leider kein Nachschlagen von Wegbeschreibungen möglich] LB2 Lokal LokalB2
    1 [Spiele Bring mich zur Kirche] {Spiel „Bring mich zur Kirche“} M3 Medien Medien3
    1 LokalSuche („Bring mich zur Kirche“) L1 Lokal Lokal1
  • Der Dialog-Host stuft die vier Kandidaten Lokal1, LokalB1, Medien3 und LokalB2 ein. Die Einstufung des Kandidaten LokalB2 ist schlecht und der Dialog-Host stutzt den Kandidaten, weil die Suche LokalB1 noch keine Antwort geliefert hat oder abgelaufen ist. Der Kandidat Medien3 löst nicht aus, weil er nicht auf die Eingabe anspricht, beispielsweise ist sie für Pfad 1 und nicht Pfad 2. Der Dialog-Host hat daher keine Systemantwort zum Auslösen und beginnt ein Ausführen der Anforderung für den Kandidaten Lokals1. Somit ist der Dialogzustand LB1 ein akzeptierter Zustand in Pfad 2 und der Dialogmanager wartet auf das nächste Auslöseereignis.
  • Das nächste Auslöseereignis ist die Antwort, die der Backend-Anforderung Lokal1 entspricht. Der Dialog-Host kann bestimmen, dass diese Antwort dem Kandidaten Lokal1 entspricht und in Pfad 1 und nicht in Pfad 2 ist. Somit bestimmt der Dialog-Host, dass der Basiszustand den Dialogzustand L1 und den Dialogzustand M1 enthält, die die jüngsten akzeptierten Zustände in Pfad 1 sind. Der Dialogzustand M3 ist kein akzeptierter Zustand, weil der Kandidat nicht ausgelöst worden ist. Dieser Basiszustand wird mit der Backend-Antwort an den Dialogmischer geliefert. Der Dialogmischer stellt drei Kandidaten als Antwort bereit. Die drei Kandidaten werden der Kandidatenliste hinzugefügt, die in Tabelle 4 gezeigt ist: Tabelle 4
    Pfad Kandidat Dialogzustand Dialogmanager Kennung
    2 LokalSuche („Bring mich mit dem Fahrrad zur Kirche“) LB1 Lokal LokalB1
    1 [Leider kein Nachschlagen in deinen Medien möglich] M5 Lokal Medien5
    1 [Spiele Bring mich zur Kirche] {Spiel „Bring mich zur Kirche“} M3 Medien Medien3
    1 Mediensuche („Bring mich zur Kirche“) M4 Lokal Medien4
    1 [Hier ist die Wegbeschreibung zur Kirche von Turning per Auto] L5 Lokal Lokal5
  • Der Dialog-Host stuft den Kandidaten Medien4 niedrig ein und stutzt den Kandidaten, weil er ein Duplikat ist. In einigen Implementierungen kann der Dialogmischer erkennen, dass der Kandidat ein Duplikat des akzeptierten Kandidaten Medien1 ist und kann Medien4 nicht einmal als Kandidat bereitstellen. Der Dialog-Host stuft auch den Kandidaten Medien5 niedrig ein und stutzt den Kandidaten. Die Kandidaten Lokal5 und Medien3 sind Systemantworten, aber haben niedrige Einstufungen, weil es noch eine ausstehende Backend-Anforderung (z. B. LokalB1) gibt. Somit ist der Dialogzustand L5 noch kein akzeptierter Zustand. Der Dialog-Host wählt somit, als Antwort auf das Auslöseereignis nichts zu tun, und wartet auf das nächste Auslöseereignis.
  • Das nächste Auslöseereignis ist die Antwort, die der Backend-Anforderung LokalB1 entspricht. Der Dialog-Host kann bestimmen, dass diese Antwort dem Kandidaten LokalB1 entspricht und in Pfad 2 und nicht in Pfad 1 ist. Somit bestimmt der Dialog-Host, dass der Basiszustand den Dialogzustand LB1 enthält, der der jüngste akzeptierte Zustand in Pfad 2 ist. Die Zustände L1 und M1 sind nicht Pfad 2 zugeordnet und daher nicht in dem Basiszustand enthalten, der an den Dialogmischer geliefert wird. Dieser Basiszustand wird mit der Backend-Antwort an den Dialogmischer geliefert. Der Dialogmischer stellt einen Kandidaten als Antwort bereit. Der Kandidat wird der Kandidatenliste hinzugefügt, die in Tabelle 5 gezeigt ist: Tabelle 5
    Pfad Kandidat Dialogzustand Dialogmanager Kennung
    2 [Hier ist die Wegbeschreibung zur Kirche von Turning per Fahrrad] LB3 Lokal LokalB3
    1 [Spiele Bring mich zur Kirche] {Spiel „Bring mich zur Kirche“} M3 Medien Medien3
    1 [Hier ist die Wegbeschreibung zur Kirche von Turning per Auto] L5 Lokal Lokal5
  • Der Dialog-Host kann den Kandidaten LokalB3 hoch einstufen, weil er auf die gesamte Anfrage anspricht, und das System kann Metadaten haben, die angeben, dass der Anwender das Sprechen beendet hat etc. Der Kandidat Lokal5 ist niedriger eingestuft, weil er nicht die gesamte Anfrage berücksichtigt, und der Kandidat Medien3 ist schlecht eingestuft. Der Dialog-Host entscheidet, den Kandidaten LokalB3 auszulösen. Das Auslösen des Kandidaten LokalB3 veranlasst das System dazu, den Basiszustand für den Dialogstrahl auf den Dialogzustand LB3 zu aktualisieren, also beispielsweise den Dialogzustand L3 zu einem Stammzustand zu machen und die Antwort auszugeben und ihre entsprechenden Aktionen auszuführen.
  • 4 ist ein beispielhaftes Blockdiagramm, das den Dialogstrahl 400 für das oben dargestellte Beispiel zeigt. Der Baum startet mit einem Stammdialogzustand 405, der leer ist. Mit anderen Worten gibt es keine ausstehenden Anforderungen und Antworten und die Kandidatenliste ist leer. Das erste Auslöseereignis DM-Auslöser 1 resultiert in den vier in Tabelle 1 gezeigten Dialogzuständen. Zwei der Dialogzustände (L2 und M2) werden gestutzt und die anderen zwei (L1 und M1) werden akzeptiert. Alle vier Zustände sind Teil von Pfad 1, was in 4 durch durchgezogene Linien 410 gezeigt ist. Das zweite Auslöseereignis DM-Auslöser 2 resultiert in drei weiteren Dialogzuständen, von denen zwei (L3 und L4) gestutzt werden und von denen einer (M3) behalten, aber nicht akzeptiert wird. Somit ist M3 ein ausstehender Dialogzustand. Das nächste Auslöseereignis DM-Auslöser 3 veranlasst das System dazu, zurückzufallen und einen neuen Pfad zu beginnen, was mit den gepunkteten und gestrichelten Linien 450 in 4 gezeigt ist. Der DM-Auslöser 3 resultiert in zwei neuen Dialogzuständen, von denen einer gestutzt wird (LB2) und von denen einer akzeptiert wird (LB1). Das nächste Auslöseereignis DM-Auslöser 4 passt zu dem ersten Pfad und resultiert in einem neuen Dialogzustand L5, der behalten, aber nicht akzeptiert wird. Der Dialogzustand L5 ist ausstehend. Das nächste Auslöseereignis DM-Auslöser 5 passt zu dem zweiten Pfad und resultiert in einem neuen Dialogzustand LB3, der akzeptiert wird. Die Akzeptanz des Dialogzustands LB3 bewirkt, dass die ausstehenden Dialogzustände des ersten Pfads, d. h. L5 und M3, gestutzt werden.
  • 5 zeigt ein Beispiel einer generischen Rechenvorrichtung 500, die als Server 110 und/oder Client 150 von 1 betrieben werden kann, die mit den hier beschriebenen Techniken verwendet werden können. Die Rechenvorrichtung 500 soll verschiedene beispielhafte Formen von Rechenvorrichtungen repräsentieren, wie beispielsweise Laptops, Desktops, Arbeitsplatzrechner, persönliche digitale Assistenten, Mobiltelefone, Smartphones, Tablets, Server und andere Rechenvorrichtungen einschließlich am Körper tragbarer Vorrichtungen. Die hier gezeigten Komponenten, ihre Verbindungen und Beziehungen und ihre Funktionen sollen nur Beispiele sein und sollen Implementierungen der in diesem Dokument beschriebenen und/oder beanspruchten Erfindungen nicht einschränken.
  • Die Rechenvorrichtung 500 enthält einen Prozessor 502, einen Speicher 504, eine Speichervorrichtung 506 und Erweiterungsanschlüsse 510, die über eine Schnittstelle 508 angeschlossen sind. In einigen Implementierungen kann die Rechenvorrichtung 500 den Sendeempfänger 546, die Kommunikationsschnittstelle 544 und ein Empfängermodul für das globale Positionsbestimmungssystem (GPS-Empfängermodul) 548 neben anderen Komponenten enthalten, die über die Schnittstelle 508 angeschlossen sind. Die Vorrichtung 500 kann drahtlos über die Kommunikationsschnittstelle 544 kommunizieren, die falls nötig eine Digitalsignalverarbeitungsschaltung enthalten kann. Jede der Komponenten 502, 504, 506, 508, 510, 540, 544, 546 und 548 kann auf einer gemeinsamen Hauptplatine oder auf andere geeignete Weise montiert sein.
  • Der Prozessor 502 kann Befehle zur Ausführung in der Rechenvorrichtung 500 verarbeiten, was Befehle umfasst, die in dem Speicher 504 oder auf der Speichervorrichtung 506 gespeichert sind, um grafische Informationen für eine GUI auf einer externen Eingabe-/Ausgabe-Vorrichtung wie etwa der Anzeige 516 anzuzeigen. Die Anzeige 516 kann ein Monitor oder eine Berührungsflachbildschirm-Anzeige sein. In einigen Implementierungen können gegebenenfalls mehrere Prozessoren und/oder mehrere Busse zusammen mit mehreren Speichern und Speichertypen verwendet werden. Außerdem können mehrere Rechenvorrichtungen 500 verbunden sein, wobei jede Vorrichtung Teile der notwendigen Operationen bereitstellt (z. B. als eine Serverbank, eine Gruppe von Blade-Servern oder ein Multiprozessorsystem).
  • Der Speicher 504 speichert Informationen innerhalb der Rechenvorrichtung 500. In einer Implementierung ist der Speicher 504 eine oder mehrere flüchtige Speichereinheiten. In einer weiteren Implementierung ist der Speicher 504 eine oder mehrere nichtflüchtige Speichereinheiten. Der Speicher 504 kann auch eine andere Form eines computerlesbaren Mediums sein, beispielsweise eine magnetische oder optische Platte. In einigen Implementierungen kann der Speicher 504 einen Erweiterungsspeicher enthalten, der durch eine Erweiterungsschnittstelle bereitgestellt wird.
  • Die Speichervorrichtung 506 kann einen Massenspeicher für die Rechenvorrichtung 500 bereitstellen. In einer Implementierung kann die Speichervorrichtung 506 ein computerlesbares Medium wie beispielsweise eine Diskettenvorrichtung, eine Festplattenvorrichtung, eine optische Plattenvorrichtung oder eine Bandvorrichtung, ein Flash-Speicher oder eine andere ähnliche Festkörperspeichervorrichtung oder eine Anordnung von Vorrichtungen, die Vorrichtungen in einem Speicherbereichsnetz oder andere Konfigurationen enthält, sein. Ein Computerprogrammprodukt kann in einem solchen computerlesbaren Medium konkret verkörpert sein. Das Computerprogrammprodukt kann auch Befehle enthalten, die, wenn sie ausgeführt werden, ein oder mehrere Verfahren wie etwa die oben beschriebenen durchführen. Das computer- oder maschinenlesbare Medium ist eine Speichervorrichtung wie etwa der Speicher 504, die Speichervorrichtung 506 oder ein Speicher auf dem Prozessor 502.
  • Die Schnittstelle 508 kann ein Hochgeschwindigkeitscontroller, der bandbreitenintensive Operationen für die Rechenvorrichtung 500 verwaltet, oder ein Niedergeschwindigkeitscontroller, der weniger bandbreitenintensive Operationen verwaltet, oder eine Kombination solcher Controller sein. Eine externe Schnittstelle 540 kann bereitgestellt sein, um eine Nahbereichskommunikation der Vorrichtung 500 mit anderen Vorrichtungen zu ermöglichen. In einigen Implementierungen kann der Controller 508 mit der Speichervorrichtung 506 und dem Erweiterungsanschluss 514 gekoppelt sein. Der Erweiterungsanschluss, der verschiedene Kommunikationsanschlüsse (z. B. USB, Bluetooth, Ethernet, drahtloses Ethernet) umfassen kann, kann mit einer oder mehreren Eingabe-/Ausgabe-Vorrichtungen wie etwa einer Tastatur, einer Zeigevorrichtung, einem Scanner oder einer Vernetzungsvorrichtung wie etwa einem Switch oder Router z. B. über einen Netzadapter verbunden sein.
  • Die Rechenvorrichtung 500 kann in einer Reihe verschiedener Formen implementiert sein, wie es in der Figur gezeigt ist. Zum Beispiel kann sie als ein Standardserver 530 oder mehrere Male in einer Gruppe solcher Server implementiert sein. Sie kann auch als Teil eines Rack-Server-Systems implementiert sein. Zusätzlich kann sie in einer Rechenvorrichtung wie etwa einem Laptop-Computer 532, einem PC 534 oder einem Tablet/Smartphone 536 implementiert sein. Ein gesamtes System kann aus mehreren Rechenvorrichtungen 500 bestehen, die miteinander kommunizieren. Andere Konfigurationen sind möglich.
  • 6 zeigt ein Beispiel einer generischen Rechenvorrichtung 600, die der Server 110 von 1 sein kann, der mit den hier beschriebenen Techniken verwendet werden kann. Die Rechenvorrichtung 600 soll verschiedene beispielhafte Formen von großen Datenverarbeitungsvorrichtungen etwa Servern, Blade-Servern, Datenzentren, Großrechnern und anderen großen Rechenvorrichtungen repräsentieren. Die Rechenvorrichtung 600 kann ein verteiltes System mit mehreren Prozessoren sein, das möglicherweise netzangebundene Speicherknoten enthält, die durch ein oder mehrere Kommunikationsnetze miteinander verbunden sind. Die hier gezeigten Komponenten, ihre Verbindungen und Beziehungen und ihre Funktionen sollen nur Beispiele sein und sollen Implementierungen der in diesem Dokument beschriebenen und/oder beanspruchten Erfindungen nicht einschränken.
  • Das verteilte Rechensystem 600 kann eine beliebige Anzahl von Rechenvorrichtungen 680 enthalten. Die Rechenvorrichtungen 680 können einen Server oder Rack-Server, Großrechner usw. umfassen, die über ein lokales Netz oder Weitbereichsnetzwerk, dedizierte optische Verbindungen, Modems, Brücken, Router, Switches, drahtgebundene oder drahtlose Netze usw. kommunizieren.
  • In einigen Implementierungen kann jede Rechenvorrichtung mehrere Racks enthalten. Zum Beispiel enthält die Rechenvorrichtung 680a mehrere Racks 658a-658n. Jedes Rack kann einen oder mehrere Prozessoren enthalten, beispielsweise die Prozessoren 652a-652n und 662a-662n. Die Prozessoren können Datenprozessoren, netzangebundene Speichervorrichtungen und andere computergesteuerte Vorrichtungen umfassen. In einigen Implementierungen kann ein Prozessor als Master-Prozessor arbeiten und die Planungs- und Datenverteilungsaufgaben steuern. Prozessoren können über einen oder mehrere Rack-Switches 658 miteinander verbunden sein und ein oder mehrere Racks können über den Switch 678 verbunden sein. Der Switch 678 kann die Kommunikation zwischen mehreren verbundenen Rechenvorrichtungen 680 handhaben.
  • Jedes Rack kann einen Speicher wie beispielsweise einen Speicher 654 und einen Speicher 664, und einen Ablagespeicher wie etwa 656 und 666 enthalten. Die Ablagespeicher 656 und 666 können einen Massenspeicher bereitstellen und können flüchtigen oder nichtflüchtigen Speicher wie etwa Disketten, Festplatten, optische Platten, Bänder, Flash-Speicher oder andere ähnliche Halbleiterspeichervorrichtungen oder eine Anordnung von Vorrichtungen, die Vorrichtungen in einem Speicherbereichsnetz oder anderen Konfigurationen enthält, enthalten. Der Ablagespeicher 656 oder 666 kann von mehreren Prozessoren, mehreren Racks oder mehreren Rechenvorrichtungen gemeinsam genutzt werden und kann ein computerlesbares Medium enthalten, das Befehle speichert, die von einem oder mehreren der Prozessoren ausführbar sind. Die Speicher 654 und 664 können z. B. eine oder mehrere flüchtige Speichereinheiten, eine oder mehrere nichtflüchtige Speichereinheiten und/oder andere Formen von computerlesbaren Medien wie z. B. magnetische oder optische Platten, Flash-Speicher, Cache, Direktzugriffsspeicher (RAM), Nur-Lese-Speicher (ROM) und Kombinationen davon enthalten. Der Speicher, beispielsweise der Speicher 654, kann auch unter den Prozessoren 652a-652n gemeinsam genutzt werden. Datenstrukturen wie etwa ein Index können beispielsweise über den Ablagespeicher 656 und den Speicher 654 hinweg gespeichert werden. Die Rechenvorrichtung 680 kann andere nicht gezeigte Komponenten wie z. B. Controller, Busse, Eingabe- / Ausgabe-Vorrichtungen, Kommunikationsmodule usw. enthalten.
  • Ein gesamtes System wie beispielsweise das System 100 kann aus mehreren Rechenvorrichtungen 680 bestehen, die miteinander kommunizieren. Zum Beispiel kann die Vorrichtung 680a mit den Vorrichtungen 680b, 680c und 680d kommunizieren und diese können kollektiv als das System 100 bekannt sein. Zum Beispiel kann das System von 1 kann eine oder mehrere Rechenvorrichtungen 680 enthalten. Einige der Rechenvorrichtungen können geographisch nahe beieinander liegen und andere können geographisch entfernt sein. Die Gestaltung des Systems 600 ist nur ein Beispiel und das System kann andere Gestaltungen oder Konfigurationen annehmen.
  • Gemäß bestimmten Aspekten der Offenbarung enthält eine mobile Vorrichtung mindestens einen Prozessor und einen Speicher, der Anweisungen speichert, die, wenn sie von dem mindestens einen Prozessor ausgeführt werden, veranlassen, dass die Rechenvorrichtung Operationen ausführt. Die Operationen umfassen ein Erzeugen von ersten Kandidatenantworten auf ein Auslöseereignis. Das Auslöseereignis kann der Empfang eines Live-Stream-Stücks für den Dialog oder der Empfang einer Backend-Antwort auf eine vorherige Backend-Anforderung für ein Dialogschema sein. Die Operationen umfassen auch ein Aktualisieren einer Liste von Kandidatenantworten, die akzeptiert oder ausstehend sind, mit mindestens einer der ersten Kandidatenantworten und ein Bestimmen für das Auslöseereignis, ob die Liste von Kandidatenantworten eine Kandidatenantwort enthält, die eine Vertrauenspunktzahl aufweist, die eine Auslöseschwelle erfüllt. Die Operationen umfassen auch ein Warten auf ein nächstes Auslöseereignis, ohne eine Kandidatenantwort zu liefern, wenn die Liste keine Kandidatenantwort enthält, die eine Vertrauenspunktzahl aufweist, die die Auslöseschwelle erfüllt.
  • Diese und andere Aspekte können eines oder mehrere der folgenden Merkmale umfassen. Zum Beispiel kann mindestens eine der ersten Kandidatenantworten eine höchste Einstufung der ersten Kandidatenantworten haben. Als ein weiteres Beispiel kann jeder Kandidat in der Kandidatenliste entweder eine Systemantwort oder eine Backend-Anforderung sein und jeder Kandidat in der Kandidatenliste weist einen jeweiligen Dialogzustand auf und ist einem Pfad in einem Dialogstrahl zugeordnet. Als ein weiteres Beispiel können die ausstehenden Kandidatenantworten Systemantworten sein, die nicht als Antwort auf ein Auslöseereignis bereitgestellt worden sind, und die Operationen umfassen zudem: Bestimmen eines Pfads in einem Dialogstrahl, dem das Auslöseereignis entspricht, Bestimmen eines Basiszustands für das Auslöseereignis; wobei der Basiszustand Dialogzustände von akzeptierten Kandidaten in der Kandidatenliste für den Pfad enthält, und Erzeugen der ersten Kandidatenantworten unter Verwendung von Informationen aus dem Auslöseereignis und dem Basiszustand. Als ein weiteres Beispiel kann eine der Kandidatenantworten in der Liste von Kandidatenantworten eine Rückkanalrückmeldung repräsentieren. Als ein weiteres Beispiel kann eine akzeptierte Antwort eine Backend-Anforderung sein, die initiiert worden ist. Als ein weiteres Beispiel ist eine ausstehende Antwort eine Systemantwort, die nicht an den Anwender geliefert worden ist. Als ein weiteres Beispiel ist das Auslöseereignis ein erstes Auslöseereignis und die Kandidaten in der Liste von Kandidaten entsprechen alle einem ersten Pfad in einem Dialogstrahl und die Operationen umfassen zudem: Empfangen eines zweiten Auslöseereignisses, Bestimmen, dass das zweite Auslöseereignis einen zweiten Pfad in einem Dialogstrahl benötigt, Setzen eines Basiszustands für den zweiten Pfad, wobei der Basiszustand für den zweiten Pfad ein Basiszustand für einen Vorgängerknoten in dem ersten Pfad eines aktuellen Basiszustands des ersten Pfads ist, Erzeugen von zweiten Kandidatenantworten unter Verwendung des Basiszustands für den zweiten Pfad und von Informationen für das zweite Auslöseereignis und Aktualisieren der Liste von Kandidatenantworten, die akzeptiert oder ausstehend sind, mit mindestens einer der zweiten Kandidatenantworten. Als ein weiteres Beispiel kann das Aktualisieren der Liste ein Stutzen von Kandidatenantworten, die eine Einstufungsschwelle nicht erfüllen, umfassen.
  • In einem weiteren Aspekt umfasst ein Verfahren: als Antwort auf ein Empfangen eines Stücks aus einem Echtzeit-Dialogstrom, Liefern des Stücks an einen Dialogmischer, Empfangen von Antwortkandidaten für das Stück aus dem Dialogmischer, wobei jeder Antwortkandidat eine Systemantwort für ein Dialogschema oder eine Backend-Anforderung für ein Dialogschema ist, und Aktualisieren einer rotierenden Liste von Antwortkandidaten unter Verwendung von mindestens einem der Antwortkandidaten für das Stück. Das Verfahren umfasst ferner: Einstufen der Antwortkandidaten in der Liste, wobei jeder Antwortkandidat eine jeweilige Vertrauenspunktzahl aufweist, Bestimmen, ob die rotierende Liste einen Antwortkandidaten mit einer Vertrauenspunktzahl, die einen Auslöseschwellenwert erfüllt, enthält, und dann, wenn die rotierende Liste keinen Antwortkandidaten mit einer Vertrauenspunktzahl, die die Auslöseschwelle erfüllt, enthält, Initiieren einer Backend-Anforderung, die durch einen Antwortkandidaten in der Liste repräsentiert wird, der eine Vertrauenspunktzahl, die eine Einstufungsschwelle erfüllt, aufweist und der noch kein akzeptierter Dialogzustand ist.
  • Diese und andere Aspekte können eines oder mehrere der folgenden Merkmale umfassen. Zum Beispiel kann jeder Antwortkandidat in der Liste entsprechende Vermerke und einen jeweiligen Dialogzustand aufweisen und das Einstufen der Antwortkandidaten kann ein Liefern der Vermerke mit der Liste an ein maschinengelerntes Modell umfassen, wobei das maschinengelernte Modell die Vermerke und die Antwortkandidaten in der Liste verwendet, um die jeweiligen Vertrauenspunktzahlen zu bestimmen. In solchen Implementierungen können die Vermerke Merkmale des Stücks enthalten, die durch Sprachanalyse erhalten werden. Als ein weiteres Beispiel kann jeder Antwortkandidat in der Liste von Antwortkandidaten einen entsprechenden Dialogzustand haben. Als ein weiteres Beispiel kann das Verfahren zudem ein Aktualisieren der Antwortkandidaten in der Liste umfassen, was ein Stutzen von Kandidaten mit einer Vertrauenspunktzahl umfasst, die eine Einstufungsschwelle nicht erfüllt. Als ein weiteres Beispiel kann jeder Antwortkandidat in der Liste von Antwortkandidaten einen entsprechenden Dialogzustand aufweisen und ist einem Pfad in einem Dialogstrahl zugeordnet, wobei der Dialogstrahl mindestens zwei Pfade enthält. In solchen Implementierungen kann das Verfahren dann, wenn die rotierende Liste einen Antwortkandidaten mit einer Vertrauenspunktzahl, die die Auslöseschwelle erfüllt, enthält, auch umfassen: Bestimmen eines Pfades, der dem Antwortkandidaten mit der Vertrauenspunktzahl zugeordnet ist, die die Auslöseschwelle erfüllt, und Stutzen von Antwortkandidaten aus der Liste, die nicht dem Pfad zugeordnet sind.
  • In einem weiteren Aspekt umfasst ein Verfahren: Empfangen eines Auslöseereignisses für einen Echtzeit-Dialog, wobei der Echtzeit-Dialog einen zugeordneten Dialogstrahl mit einem ersten Pfad aufweist, wobei der Dialogstrahl Dialogzustände für einen Echtzeit-Dialog mit einem Anwender repräsentiert, Bestimmen, dass das Auslöseereignis einen neuen Pfad in dem Dialogstrahl beginnt, und Zurückfallen in dem ersten Pfad bis zu einem Vorgängerknoten in dem Dialogstrahl. Das Verfahren umfasst zudem: Beginnen des neuen Pfads in dem Dialogstrahl von dem Vorgängerknoten aus durch Erzeugen von Antwortkandidaten unter Verwendung eines durch den Vorgängerknoten repräsentierten Basiszustands und von Informationen aus dem Auslöseereignis, wobei ein Pfad in dem Dialogstrahl ein oder mehrere akzeptierte oder ausstehende Antwortkandidaten enthält, wobei ein Antwortkandidat eine Systemantwort ist, die durch ein Dialogschema oder eine Backend-Anforderung für ein Dialogschema erzeugt wird.
  • Diese und andere Aspekte können eines oder mehrere der folgenden Merkmale umfassen. Der Vorgängerknoten kann beispielsweise ein Stammknoten sein, der einen leeren Basiszustand darstellt. Als ein weiteres Beispiel kann der Antwortkandidat einen entsprechenden Dialogzustand aufweisen und ist einem der Dialogpfade zugeordnet. Als ein weiteres Beispiel kann das Verfahren zudem umfassen: Bestimmen als Reaktion auf ein zweites Auslöseereignis, dass ein Antwortkandidat in dem neuen Pfad eine Systemantwort mit einer Vertrauenspunktzahl, die eine Auslöseschwelle erfüllt, ist, Liefern des Antwortkandidaten an den Anwender und Stutzen des ersten Pfades aus dem Dialogstrahl.
  • Verschiedene Implementierungen können eine Implementierung in einem oder mehreren Computerprogrammen umfassen, die auf einem programmierbaren System ausführbar und/oder interpretierbar sind, das mindestens einen programmierbaren Prozessor enthält, der speziellen oder allgemeinen Zwecken dienen kann und der zum Empfangen von Daten und Befehlen und zum Senden von Daten und Befehlen mit einem Speichersystem, mindestens einer Eingabevorrichtung und mindestens einer Ausgabevorrichtung gekoppelt ist.
  • Diese Computerprogramme (auch bekannt als Programme, Software, Softwareanwendungen oder Code) enthalten Maschinenbefehle für einen programmierbaren Prozessor und können in einer prozeduralen Hochsprache und/oder objektorientierten Programmiersprache und/oder in Assembler-/Maschinensprache implementiert sein. Wie hierin verwendet bezieht sich der Begriff „maschinenlesbares Medium“ oder „computerlesbares Medium“ auf irgendein nichttransitorisches Computerprogrammprodukt, eine Einrichtung und/oder eine Vorrichtung (z. B. Magnetplatten, optische Platten, Speicher (einschließlich Lesezugriffsspeicher, programmierbare Logikvorrichtungen (PLDs)) zum Bereitstellen von Maschinenbefehlen und/oder Daten für einen programmierbaren Prozessor.
  • Die hier beschriebenen Systeme und Techniken können in einem Computersystem implementiert werden, das eine Backend-Komponente, z. B. als Datenserver, oder eine Middleware-Komponente, z. B. einen Anwendungsserver, oder eine Frontend-Komponente, z. B. einen Clientcomputer mit einer grafischen Anwenderoberfläche oder einem Webbrowser, über den ein Anwender mit einer Implementierung des in dieser Beschreibung beschriebenen Gegenstands interagieren kann, oder eine beliebige Kombination aus einer oder mehreren solchen Backend-, Middleware- oder Frontend-Komponenten enthält. Die Komponenten des Systems können über jede Form oder jedes Medium der digitalen Datenkommunikation, z. B. ein Kommunikationsnetz, miteinander verbunden sein. Beispiele von Kommunikationsnetzen umfassen ein lokales Netz („LAN“) und ein Weitbereichsnetz („WAN“), z. B. das Internet.
  • Das Computersystem kann Clients und Server enthalten. Ein Client und ein Server sind im Allgemeinen voneinander entfernt und interagieren typischerweise über ein Kommunikationsnetz. Die Beziehung von Client und Server entsteht durch Computerprogramme, die auf den jeweiligen Computern laufen und eine Client-Server-Beziehung zueinander haben.
  • Eine Reihe von Implementierungen ist beschrieben worden. Nichtsdestotrotz können verschiedene Abwandlungen vorgenommen werden, ohne von dem Gedanken und dem Umfang der Erfindung abzuweichen. Zudem erfordern die in den Figuren dargestellten logischen Abläufe nicht die speziell gezeigte Reihenfolge oder eine sequentielle Reihenfolge, um erwünschte Ergebnisse zu erzielen. Zusätzlich können andere Schritte bereitgestellt werden oder Schritte können aus den beschriebenen Abläufen weggelassen werden und andere Komponenten können zu den beschriebenen Systemen hinzugefügt oder daraus entfernt werden. Dementsprechend liegen andere Implementierungen innerhalb des Umfangs der folgenden Ansprüche.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • US 62459820 [0001]

Claims (20)

  1. Rechenvorrichtung, die dazu ausgelegt ist, einen Echtzeitdialog mit einem Anwender zu führen, wobei die Rechenvorrichtung enthält: mindestens einen Prozessor; und einen Speicher, der Befehle speichert, die, wenn sie von dem mindestens einen Prozessor ausgeführt werden, die Rechenvorrichtung zu Folgendem veranlassen: Erzeugen von ersten Kandidatenantworten auf ein Auslöseereignis, wobei das Auslöseereignis ein Empfang eines Live-Stream-Stücks für den Dialog oder ein Empfang einer Backend-Antwort auf eine vorherige Backend-Anforderung für ein Dialogschema ist; Aktualisieren einer Liste von Kandidatenantworten, die akzeptiert oder ausstehend sind, mit mindestens einer der ersten Kandidatenantworten; Bestimmen für das Auslöseereignis, ob die Liste von Kandidatenantworten eine Kandidatenantwort enthält, die eine Vertrauenspunktzahl aufweist, die eine Auslöseschwelle erfüllt; und Warten auf ein nächstes Auslöseereignis, ohne eine Kandidatenantwort zu liefern, wenn die Liste keine Kandidatenantwort enthält, die eine Vertrauenspunktzahl aufweist, die die Auslöseschwelle erfüllt.
  2. Rechenvorrichtung nach Anspruch 1, wobei die mindestens eine der ersten Kandidatenantworten eine höchste Einstufung der ersten Kandidatenantworten aufweist.
  3. Rechenvorrichtung nach Anspruch 1 oder 2, wobei jeder Kandidat in der Kandidatenliste entweder eine Systemantwort oder eine Backend-Anforderung ist und jeder Kandidat in der Kandidatenliste einen jeweiligen Dialogzustand aufweist und einem Pfad in einem Dialogstrahl zugeordnet ist.
  4. Rechenvorrichtung nach Anspruch 1 oder 2, wobei die ausstehenden Kandidatenantworten Systemantworten sind, die nicht als Antwort auf ein Auslöseereignis bereitgestellt worden sind, und der Speicher ferner Befehle speichert, die, wenn sie von dem mindestens einen Prozessor ausgeführt werden, die Rechenvorrichtung zu Folgendem veranlassen: Bestimmen eines Pfads in einem Dialogstrahl, dem das Auslöseereignis entspricht; Bestimmen eines Basiszustands für das Auslöseereignis; wobei der Basiszustand Dialogzustände von akzeptierten Kandidaten in der Kandidatenliste für den Pfad enthält; und Erzeugen der ersten Kandidatenantworten unter Verwendung von Informationen aus dem Auslöseereignis und dem Basiszustand.
  5. Rechenvorrichtung nach einem der vorhergehenden Ansprüche, wobei eine der Kandidatenantworten in der Liste von Kandidatenantworten eine Rückkanal-rückmeldung repräsentiert.
  6. Rechenvorrichtung nach einem der vorhergehenden Ansprüche, wobei eine akzeptierte Antwort eine Backend-Anforderung ist, die initiiert worden ist.
  7. Rechenvorrichtung nach einem der vorhergehenden Ansprüche, wobei eine ausstehende Antwort eine Systemantwort ist, die nicht an den Anwender geliefert worden ist.
  8. Rechenvorrichtung nach einem der vorhergehenden Ansprüche, wobei das Auslöseereignis ein erstes Auslöseereignis ist und die Kandidaten in der Liste von Kandidaten alle einem ersten Pfad in einem Dialogstrahl entsprechen und der Speicher ferner Befehle speichert, die, wenn sie von dem mindestens einen Prozessor ausgeführt werden, die Rechenvorrichtung zu Folgendem veranlassen: Empfangen eines zweiten Auslöseereignisses; Bestimmen, dass das zweite Auslöseereignis einen zweiten Pfad in einem Dialogstrahl benötigt; Setzen eines Basiszustands für den zweiten Pfad, wobei der Basiszustand für den zweiten Pfad ein Basiszustand für einen Vorgängerknoten in dem ersten Pfad eines aktuellen Basiszustands des ersten Pfads ist, Erzeugen von zweiten Kandidatenantworten unter Verwendung des Basiszustands für den zweiten Pfad und von Informationen für das zweite Auslöseereignis; und Aktualisieren der Liste von Kandidatenantworten, die akzeptiert oder ausstehend sind, mit mindestens einer der zweiten Kandidatenantworten.
  9. Rechenvorrichtung nach einem der vorhergehenden Ansprüche, wobei das Aktualisieren der Liste ein Stutzen von Kandidatenantworten, die eine Einstufungsschwelle nicht erfüllen, umfasst.
  10. Verfahren, das umfasst: als Antwort auf ein Empfangen eines Stücks aus einem Echtzeit-Dialogstrom, Liefern des Stücks an einen Dialogmischer; Empfangen von Antwortkandidaten für das Stück aus dem Dialogmischer, wobei jeder Antwortkandidat eine Systemantwort für ein Dialogschema oder eine Backend-Anforderung für ein Dialogschema ist; und Aktualisieren einer Liste von Antwortkandidaten unter Verwendung von mindestens einem der Antwortkandidaten für das Stück; Einstufen der Antwortkandidaten in der Liste, wobei jeder Antwortkandidat eine jeweilige Vertrauenspunktzahl aufweist; Bestimmen, ob die Liste einen Antwortkandidaten mit einer Vertrauenspunktzahl, die einen Auslöseschwellenwert erfüllt, enthält; und dann, wenn die Liste keinen Antwortkandidaten mit einer Vertrauenspunktzahl, die die Auslöseschwelle erfüllt, enthält, Initiieren einer Backend-Anforderung, die durch einen Antwortkandidaten in der Liste repräsentiert wird, der eine Vertrauenspunktzahl, die eine Einstufungsschwelle erfüllt, aufweist und der noch kein akzeptierter Dialogzustand ist.
  11. Verfahren nach Anspruch 10, wobei jeder Antwortkandidat in der Liste entsprechende Vermerke und einen jeweiligen Dialogzustand aufweist und das Einstufen der Antwortkandidaten umfasst: Liefern der Vermerke mit der Liste an ein maschinengelerntes Modell, wobei das maschinengelernte Modell die Vermerke und die Antwortkandidaten in der Liste verwendet, um die jeweiligen Vertrauenspunktzahlen zu bestimmen.
  12. Verfahren nach Anspruch 11, wobei die Vermerke Eigenschaften des Stücks enthalten, die durch Sprachanalyse erhalten werden.
  13. Verfahren nach Anspruch 10, 11 oder 12, wobei jeder Antwortkandidat in der Liste von Antwortkandidaten einen entsprechenden Dialogzustand aufweist.
  14. Verfahren nach einem der Ansprüche 10 bis 13, wobei das Aktualisieren der Antwortkandidaten in der Liste ein Stutzen von Kandidaten mit einer Vertrauenspunktzahl, die eine Einstufungsschwelle nicht erfüllt, umfasst.
  15. Verfahren nach einem der Ansprüche 10 bis 14, wobei jeder Antwortkandidat in der Liste von Antwortkandidaten einen entsprechenden Dialogzustand aufweist und einem Pfad in einem Dialogstrahl zugeordnet ist, wobei der Dialogstrahl mindestens zwei Pfade enthält.
  16. Verfahren nach Anspruch 15, wobei das Verfahren dann, wenn die Liste einen Antwortkandidaten mit einer Vertrauenspunktzahl, die die Auslöseschwelle erfüllt, enthält, ferner umfasst: Bestimmen eines Pfades, der dem Antwortkandidaten mit der Vertrauenspunktzahl zugeordnet ist, die die Auslöseschwelle erfüllt, und Stutzen von Antwortkandidaten aus der Liste, die nicht dem Pfad zugeordnet sind.
  17. Verfahren, das umfasst: Empfangen eines Auslöseereignisses für einen Echtzeit-Dialog, wobei der Echtzeit-Dialog einen zugeordneten Dialogstrahl mit einem ersten Pfad aufweist, wobei der Dialogstrahl Dialogzustände für einen Echtzeit-Dialog mit einem Anwender repräsentiert; Bestimmen, dass das Auslöseereignis einen neuen Pfad in dem Dialogstrahl beginnt, und Zurückfallen in dem ersten Pfad bis zu einem Vorgängerknoten in dem Dialogstrahl; und Beginnen des neuen Pfads in dem Dialogstrahl von dem Vorgängerknoten aus durch Erzeugen von Antwortkandidaten unter Verwendung eines durch den Vorgängerknoten repräsentierten Basiszustands und von Informationen aus dem Auslöseereignis, wobei ein Pfad in dem Dialogstrahl ein oder mehrere akzeptierte oder ausstehende Antwortkandidaten enthält, wobei ein Antwortkandidat eine Systemantwort ist, die durch ein Dialogschema oder eine Backend-Anforderung für ein Dialogschema erzeugt wird.
  18. Verfahren nach Anspruch 17, wobei der Vorgängerknoten ein Stammknoten ist, der einen leeren Basiszustand repräsentiert.
  19. Verfahren nach Anspruch 17 oder 18, wobei der Antwortkandidat einen jeweiligen Dialogzustand aufweist und einem der Dialogpfade zugeordnet ist.
  20. Verfahren nach Anspruch 17, 18 oder 19, das ferner umfasst: Bestimmen als Antwort auf ein zweites Auslöseereignis, dass ein Antwortkandidat in dem neuen Pfad eine Systemantwort mit einer Vertrauenspunktzahl, die eine Auslöseschwelle erfüllt, ist; Liefern des Antwortkandidaten an den Anwender; und Stutzen des ersten Pfades aus dem Dialogstrahl.
DE102017125001.8A 2017-02-16 2017-10-25 Streaming-Dialogmanagement in Echtzeit Ceased DE102017125001A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201762459820P 2017-02-16 2017-02-16
US62/459,820 2017-02-16

Publications (1)

Publication Number Publication Date
DE102017125001A1 true DE102017125001A1 (de) 2018-08-16

Family

ID=60481740

Family Applications (2)

Application Number Title Priority Date Filing Date
DE202017106466.2U Active DE202017106466U1 (de) 2017-02-16 2017-10-25 Streaming-Dialogmanagement in Echtzeit
DE102017125001.8A Ceased DE102017125001A1 (de) 2017-02-16 2017-10-25 Streaming-Dialogmanagement in Echtzeit

Family Applications Before (1)

Application Number Title Priority Date Filing Date
DE202017106466.2U Active DE202017106466U1 (de) 2017-02-16 2017-10-25 Streaming-Dialogmanagement in Echtzeit

Country Status (6)

Country Link
US (4) US10860628B2 (de)
EP (1) EP3571649A1 (de)
CN (2) CN108446290B (de)
DE (2) DE202017106466U1 (de)
GB (1) GB2559829A (de)
WO (1) WO2018151766A1 (de)

Families Citing this family (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10860628B2 (en) 2017-02-16 2020-12-08 Google Llc Streaming real-time dialog management
WO2018156978A1 (en) 2017-02-23 2018-08-30 Semantic Machines, Inc. Expandable dialogue system
WO2018167830A1 (ja) * 2017-03-13 2018-09-20 日本電気株式会社 対話装置、対話システム、及びコンピュータ読み取り可能な記録媒体
US10429798B2 (en) * 2017-05-09 2019-10-01 Lenovo (Singapore) Pte. Ltd. Generating timer data
US10497370B2 (en) 2017-08-18 2019-12-03 2236008 Ontario Inc. Recognition module affinity
US10984788B2 (en) 2017-08-18 2021-04-20 Blackberry Limited User-guided arbitration of speech processing results
US10964318B2 (en) * 2017-08-18 2021-03-30 Blackberry Limited Dialogue management
US11132499B2 (en) * 2017-08-28 2021-09-28 Microsoft Technology Licensing, Llc Robust expandable dialogue system
US11074911B2 (en) * 2017-09-05 2021-07-27 First Advantage Corporation Digital assistant
US20190163331A1 (en) * 2017-11-28 2019-05-30 International Business Machines Corporation Multi-Modal Dialog Broker
US11455986B2 (en) 2018-02-15 2022-09-27 DMAI, Inc. System and method for conversational agent via adaptive caching of dialogue tree
EP3753014A4 (de) * 2018-02-15 2021-11-17 DMAI, Inc. System und verfahren zur prädiktionsbasierten präemptiven erzeugung von dialoginhalten
WO2019161229A1 (en) 2018-02-15 2019-08-22 DMAI, Inc. System and method for reconstructing unoccupied 3d space
US10706086B1 (en) * 2018-03-12 2020-07-07 Amazon Technologies, Inc. Collaborative-filtering based user simulation for dialog systems
US10831442B2 (en) * 2018-10-19 2020-11-10 International Business Machines Corporation Digital assistant user interface amalgamation
US10878805B2 (en) * 2018-12-06 2020-12-29 Microsoft Technology Licensing, Llc Expediting interaction with a digital assistant by predicting user responses
CN109842546B (zh) * 2018-12-25 2021-09-28 创新先进技术有限公司 会话表情处理方法以及装置
US11288459B2 (en) * 2019-08-01 2022-03-29 International Business Machines Corporation Adapting conversation flow based on cognitive interaction
US11749265B2 (en) * 2019-10-04 2023-09-05 Disney Enterprises, Inc. Techniques for incremental computer-based natural language understanding
CN111107156A (zh) * 2019-12-26 2020-05-05 苏州思必驰信息科技有限公司 用于主动发起对话的服务端处理方法及服务器、能够主动发起对话的语音交互系统
CN111538802B (zh) * 2020-03-18 2023-07-28 北京三快在线科技有限公司 会话处理方法、装置、电子设备
WO2021222452A1 (en) * 2020-04-28 2021-11-04 Leela AI, Inc. Learning agent
CN112530437B (zh) * 2020-11-18 2023-10-20 北京百度网讯科技有限公司 语义识别方法、装置、设备以及存储介质
CN112700768B (zh) * 2020-12-16 2024-04-26 科大讯飞股份有限公司 语音识别方法以及电子设备、存储装置
US20220207392A1 (en) * 2020-12-31 2022-06-30 International Business Machines Corporation Generating summary and next actions in real-time for multiple users from interaction records in natural language
CN112883184A (zh) * 2021-03-22 2021-06-01 深圳前海微众银行股份有限公司 对话管理方法、设备、计算机可读存储介质及程序产品
US11430446B1 (en) * 2021-08-12 2022-08-30 PolyAI Limited Dialogue system and a dialogue method
CN115982336B (zh) * 2023-02-15 2023-05-23 创意信息技术股份有限公司 动态对话状态图学习方法、装置、系统及存储介质

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003044088A (ja) * 2001-07-27 2003-02-14 Sony Corp プログラム、記録媒体、並びに音声対話装置および方法
US8031206B2 (en) 2005-10-12 2011-10-04 Noregin Assets N.V., L.L.C. Method and system for generating pyramid fisheye lens detail-in-context presentations
WO2012047532A1 (en) 2010-09-28 2012-04-12 International Business Machines Corporation Providing answers to questions using hypothesis pruning
US9679568B1 (en) * 2012-06-01 2017-06-13 Google Inc. Training a dialog system using user feedback
US20140006012A1 (en) 2012-07-02 2014-01-02 Microsoft Corporation Learning-Based Processing of Natural Language Questions
CA2823835C (en) * 2012-08-15 2018-04-24 Homer Tlc, Inc. Voice search and response based on relevancy
US10282419B2 (en) 2012-12-12 2019-05-07 Nuance Communications, Inc. Multi-domain natural language processing architecture
US9875494B2 (en) 2013-04-16 2018-01-23 Sri International Using intents to analyze and personalize a user's dialog experience with a virtual personal assistant
US10176167B2 (en) 2013-06-09 2019-01-08 Apple Inc. System and method for inferring user intent from speech inputs
JP6187359B2 (ja) 2014-03-31 2017-08-30 マツダ株式会社 変速機のブレーキ装置
US10885129B2 (en) 2014-12-10 2021-01-05 Google Llc Using frames for action dialogs
US9836452B2 (en) 2014-12-30 2017-12-05 Microsoft Technology Licensing, Llc Discriminating ambiguous expressions to enhance user experience
EP3243200B1 (de) 2015-01-05 2021-05-19 Google LLC Verarbeitung multimodaler benutzereingaben
US10255921B2 (en) 2015-07-31 2019-04-09 Google Llc Managing dialog data providers
US10319042B2 (en) * 2015-10-20 2019-06-11 Mastercard International Incorporated Computerized-methods and systems for identifying duplicate entries in a database of merchant data
CN106227779A (zh) * 2016-07-18 2016-12-14 深圳追科技有限公司 一种客服系统的人机交互方法
US10860628B2 (en) 2017-02-16 2020-12-08 Google Llc Streaming real-time dialog management

Also Published As

Publication number Publication date
GB2559829A (en) 2018-08-22
EP3571649A1 (de) 2019-11-27
CN108446290A (zh) 2018-08-24
GB201717421D0 (en) 2017-12-06
CN108446290B (zh) 2022-02-25
US20240134893A1 (en) 2024-04-25
US11860913B2 (en) 2024-01-02
WO2018151766A1 (en) 2018-08-23
US20230132020A1 (en) 2023-04-27
US20180232436A1 (en) 2018-08-16
US20210089565A1 (en) 2021-03-25
CN114547263A (zh) 2022-05-27
US10860628B2 (en) 2020-12-08
DE202017106466U1 (de) 2018-01-22
US11537646B2 (en) 2022-12-27

Similar Documents

Publication Publication Date Title
DE102017125001A1 (de) Streaming-Dialogmanagement in Echtzeit
DE102017122513B4 (de) Erleichtern der Erzeugung und Wiedergabe von durch den Anwender aufgezeichneten Audiosignalen
DE112014003653B4 (de) Automatisch aktivierende intelligente Antworten auf der Grundlage von Aktivitäten von entfernt angeordneten Vorrichtungen
DE202017105844U1 (de) Bereitstellen einer Eingabeaufforderung in einer automatisierten Dialogsitzung basierend auf ausgewähltem Inhalt von vorherigen automatisierten Dialogsitzungen
DE202016008203U1 (de) Spracherkennungssystem
DE202016008217U1 (de) Automatisch augmentierende Nachrichenaustauschthreads besierend auf der Nachrichtenklassifizierung
DE102011107992A1 (de) System und Verfahren zum Anmelden zu Ereignissen auf der Grundlage von Schlagwörtern
DE102016125508A1 (de) Auffindbarkeitssystem für Sprachaktionen
DE112020003306T5 (de) Unterscheiden von sprachbefehlen
DE102017119601A1 (de) Verwenden einer Anwendereingabe, um Suchergebnisse, die für die Darstellung für den Anwender bereitgestellt werden, anzupassen
DE202016008173U1 (de) Einbindung von auswählbaren Anwendungsverknüpfungen in Nachrichtenaustausch-Threads
DE112016002370T5 (de) Lokales persistent machen von daten für eine selektiv offline taugliche sprachaktion in einer sprachfähigen elektronischen vorrichtung
DE112020002531T5 (de) Emotionsdetektion unter verwendung der sprechergrundlinie
DE202017106616U1 (de) Sprachmodellbeeinflussungssystem
DE112017000131T5 (de) Rückmeldungssteuerung für Datenübertragungen
DE112015005269T5 (de) Erweitern einer Informationsanforderung
DE202016008323U1 (de) Das Einbeziehen auswählbarer Anwendungslinks in Konversationen mit persönlichen Assistenz-Modulen
EP1926081A1 (de) Verfahren zur Dialoganpassung und Dialogsystem zur Durchführung
DE102015211101A1 (de) Spracherkennungssystem sowie Verfahren zum Betreiben eines Spracherkennungssystems mit einer mobilen Einheit und einem externen Server
DE202016008225U1 (de) Unterstützung bei der semantischen Offline-Bearbeitung durch ein Gerät mit begrenzten Möglichkeiten
DE202016008204U1 (de) Suchergebnis unter vorherigem Abrufen von Sprachanfragen
DE212017000068U1 (de) Einrichten von audio-basierten Netzwerksitzungen mit nicht registrierten Ressourcen
DE202017106609U1 (de) Kontextuelles Eindeutigmachen von Anfragen
CN106844538A (zh) 一种应用于物联网搜索的多属性排序方法与装置
DE112020004925T5 (de) Aktualisieren und umsetzen eines dokuments aus einem audiovorgang

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R082 Change of representative

Representative=s name: VENNER SHIPLEY LLP, DE

R016 Response to examination communication
R002 Refusal decision in examination/registration proceedings
R003 Refusal decision now final