DE102020200455A1 - Method, computer program and device for processing user input - Google Patents

Abstract

The present invention relates to a method, a computer program with instructions and a device for processing user input. The invention further relates to a means of locomotion in which a method according to the invention or a device according to the invention is used. In a first step, user input is received (10). At least one entity is then extracted from the user input (11). Data for the at least one entity are then queried from a knowledge base (12). The data requested from the knowledge base are evaluated (13). Finally, using the results of the evaluation (13), a response to the user input is generated (14).

Description

The present invention relates to a method, a computer program with instructions and a device for processing user input. The invention further relates to a means of locomotion in which a method according to the invention or a device according to the invention is used.

Voice-based approaches for user interaction are increasingly being implemented in modern motor vehicles. Voice inputs from a user are processed and information is output to the user in natural language.

For example, describes EP 3 392 878 A1 a method of operating a speech recognition device. In the process, a voice command is received via a microphone. When the received voice command corresponds to a keyword command stored in advance, an operation corresponding to the keyword command is performed. If the received voice command does not correspond to a previously stored keyword command, voice data including the voice command is transmitted to a voice server.

US 7,398,209 B2 describes a method that reacts to a user-generated speech utterance in natural language. In the method, the user-generated speech utterance is first received in natural language. A domain for the utterance is then determined. Based on the determined domain, at least one domain agent is then selected to process the utterance. The domain agent is a stand-alone executable file that receives, processes, and responds to a query or command.

With advances in speech recognition, it is now possible for automatic speech recognition systems to recognize natural language user statements such as “Find Italian restaurants nearby!”, “I want lasagna” or “How did Borussia Dortmund play”. However, due to the limited capabilities of the components currently available in motor vehicles for understanding natural language, better known as Natural Language Understanding (NLU), the voice assistant is not always able to understand the user's intention.

An inherent factor that contributes to the limitation of the capabilities of NLU components in the vehicle is that they are primarily intended to support only typical functions required in the vehicle, such as route planning, the operation of an infotainment system or the Making phone calls. In addition, because of the cost of capturing natural language user utterances, only a limited number of user utterances are used in training models for understanding language. However, since the spoken language is spontaneous and varied, ultimately every large data set will not be able to cover all possible formulations of user utterances. As a result, the current NLU components in the vehicle can only understand a limited set of entities. This in turn forces the user to only use certain phrases.

Current NLU components in the vehicle are able to process typical user requests. The system can respond to a voice input “Find Italian restaurants nearby!” With the voice output “OK, I have found the following three Italian restaurants in the area”. The associated results can then be shown on a display. This is possible because the categories for Points of Interest (POI), such as restaurant, and the different cuisines, such as Italian or Vietnamese, are limited, manageable sets of entities and can be made available to an NLU component.

A much more difficult task is understanding utterances that mention certain dishes. The system should also respond to a voice input “I want lasagne” with the voice output “OK, I have found the following three Italian restaurants in the area”. However, the system has no knowledge of the “Lasagna” entity, as it was not part of its training. A user familiar with the response to the above explicit question about Italian restaurants may be disappointed that the system cannot understand the request for lasagna.

With the increasing spread of smart voice assistants, e.g. on the smartphone or in the user's home, their use is becoming more and more common. As a result, user expectations are increasing. Therefore, situations will often arise in which the voice inputs exceed the range of functions of the wizards. An example of such a voice input for an assistant in a vehicle that exceeds the functionality of the assistant and cannot be correctly interpreted by the assistant is “How did Borussia Dortmund play?” A typical answer to this question would be the unspecific rejection “Sorry, I did not understand you.". Alternatively, there may be a mistake that leads to an answer of the type “The route to Dortmund, Borussiastraße is started. ”leads. Both reactions are not optimal. With the unspecific rejection, it remains unclear to the user whether the input was not correctly understood acoustically, the selected formulation was not understood or the function is not supported by the assistant at all. The mistake may lead to an unwanted action by the assistant, which the user must then correct. The cause of the mix-up also remains unclear. The user does not find out whether there is an error or whether the function is not supported.

The desired behavior of the wizard is that the wizard can provide a specific answer. Even if the answer is a rejection, the assistant appears more intelligent and the user learns something about the functionality of the assistant. A specific answer to the question "How did Borussia Dortmund play?" Could be, for example, "Unfortunately, I cannot help you on the subject of sports".

One approach to the above problem is that the NLU models and dialog models are implemented for more than the functionally supported domains of the voice assistant in order to be able to handle inquiries regarding certain expected functions that do not exist. For example, an assistant for an infotainment system could understand inquiries about the weather and specifically reject them because the “weather” domain was taken into account in the NLU and dialogue development, although no weather service was planned. However, with this approach, the development effort increases with each domain.

The above statements also apply analogously to user input in text form, e.g. text-based messages by means of SMS (SMS: Short message service), chat message or email to a chatbot of a service provider.

It is an object of the invention to provide improved solutions for processing user input.

This object is achieved by a method with the features of claim 1, by a computer program with instructions according to claim 8 and by a device with the features of claim 9. Preferred embodiments of the invention are the subject of the dependent claims.

• - Empfangen einer Nutzereingabe;
• - Extrahieren zumindest einer Entität aus der Nutzereingabe;
• - Abfragen von Daten für die zumindest eine Entität aus einer Wissensbasis;
• - Auswerten der aus der Wissensbasis abgefragten Daten; und
• - Generieren einer Antwort auf die Nutzereingabe unter Verwendung von Ergebnissen der Auswertung.

According to a first aspect of the invention, a method for processing a user input comprises the steps:

• - receiving user input;
• Extracting at least one entity from the user input;
• - Querying data for the at least one entity from a knowledge base;
• - Evaluation of the data requested from the knowledge base; and
• - Generating a response to the user input using the results of the evaluation.

• - Empfangen einer Nutzereingabe;
• - Extrahieren zumindest einer Entität aus der Nutzereingabe;
• - Abfragen von Daten für die zumindest eine Entität aus einer Wissensbasis;
• - Auswerten der aus der Wissensbasis abgefragten Daten; und
• - Generieren einer Antwort auf die Nutzereingabe unter Verwendung von Ergebnissen der Auswertung.

According to a further aspect of the invention, a computer program contains instructions which, when executed by a computer, cause the computer to carry out the following steps for processing user input:

• - receiving user input;
• Extracting at least one entity from the user input;
• - Querying data for the at least one entity from a knowledge base;
• - Evaluation of the data requested from the knowledge base; and
• - Generating a response to the user input using the results of the evaluation.

The term computer is to be understood broadly. In particular, it also includes control devices, integrated systems and other processor-based data processing devices.

The computer program can, for example, be provided for electronic retrieval or can be stored on a computer-readable storage medium.

• - ein Empfangsmodul zum Empfangen einer Nutzereingabe;
• - ein Extraktionsmodul zum Extrahieren zumindest einer Entität aus der Nutzereingabe;
• - ein Abfragemodul zum Abfragen von Daten für die zumindest eine Entität aus einer Wissensbasis; und
• - ein Verarbeitungsmodul zum Auswerten der aus der Wissensbasis abgefragten Daten und zum Generieren einer Antwort auf die Nutzereingabe unter Verwendung von Ergebnissen der Auswertung.

According to a further aspect of the invention, a device for processing a user input has:

• a receiving module for receiving user input;
• an extraction module for extracting at least one entity from the user input;
• a query module for querying data for the at least one entity from a knowledge base; and
• a processing module for evaluating the data requested from the knowledge base and for generating a response to the user input using the results of the evaluation.

According to the invention, the restriction of current NLU components described at the beginning when processing a user input, e.g. a voice input or a text-based user input, is overcome in that the NLU component has knowledge about entities about the relationships between the entities by means of a knowledge base. This knowledge can be used to still assign entities that are not known to the NLU component to a domain and to determine a user intention that is covered by the functional scope of the wizard. If the determined user intention lies outside the functional scope of the assistant, at least a meaningful rejection or a rejection that is understandable for the user can be generated as a response.

According to one aspect of the invention, the data queried from the knowledge base comprise relational attributes of the at least one entity. The relational attributes can be, for example, the information that the entity is an occurrence of another entity, or that another entity is part of the extracted entity. Such attributes can be used by an NLU component for meaningful conclusions.

According to one aspect of the invention, the data queried from the knowledge base are determined by querying a knowledge graph. Such queries can easily be used to verify whether an entity is an expression of an abstract entity. In the simplest case, it can be checked, for example, whether the entity is connected to the abstract entity by a property path "Subclass-of" or "Instance-of".

According to one aspect of the invention, a class for the at least one entity is determined on the basis of the data queried from the knowledge base. The class can be used to easily determine which domain an entity falls into. The set of classes can be derived manually or algorithmically from the relational hierarchy between the entities and the abstract types in a hierarchical knowledge base.

According to one aspect of the invention, it is determined on the basis of the class whether the at least one entity belongs to a supported domain or an unsupported domain. Manually or algorithmically created and maintained lists of classes can be kept for the supported domains and the unsupported domains. The list of unsupported domains can in particular include domains that are outside the scope of functions of a digital assistant, but for which inquiries from the user are calculated. If the entity belongs to a class which in turn belongs to a supported domain, a positive system response can be generated. If, on the other hand, the entity falls into an unsupported domain, at least a specific rejection for this domain can be generated as a response.

According to one aspect of the invention, it is determined on the basis of the data queried from the knowledge base whether the at least one entity lies outside a predetermined application area. Since both the number of supported domains and the number of default unsupported domains are limited, it is possible that the entity does not belong to any of these domains. It is then outside the specified scope. In this case, a non-specific rejection can still be generated as a response. A number of possible interpretations for the entity are determined by querying the knowledge base. These interpretations can be used to generate different intelligent system responses. The assistant can learn algorithmically which of the alternatives is better suited for human understanding. Such an algorithm can use knowledge specified by the system developer, for example. Alternatively or additionally, the algorithm can automatically learn from general knowledge about the world, or even use the reaction of the user to the selected system reaction in order to learn whether the reaction was appropriate for the user.

According to one aspect of the invention, when evaluating the data queried from the knowledge base, a comparison with results of a non-knowledge-based language processing is carried out. This makes it possible to disambiguate the hypotheses of the knowledge base and to select the correct type of entity if the knowledge base provides several results.

A method according to the invention or a device according to the invention is preferably used in a (partially) autonomous or manually controlled means of locomotion. The means of transport can in particular be a motor vehicle, but also a ship, a manned or unmanned aircraft, e.g. a drone or a Volocopter, etc. Of course, the solution according to the invention can also be used in other application scenarios, e.g. in a dialog system or in a user terminal. Examples of such user terminals are smartphones, tablets or portable and stationary computers.

• 1 zeigt schematisch ein Verfahren zum Verarbeiten einer Nutzereingabe;
• 2 zeigt eine erste Ausführungsform einer Vorrichtung zum Verarbeiten einer Nutzereingabe;
• 3 zeigt eine zweite Ausführungsform einer Vorrichtung zum Verarbeiten einer Nutzereingabe;
• 4 stellt schematisch ein Fortbewegungsmittel dar, in dem eine erfindungsgemäße Lösung realisiert ist;
• 5 zeigt eine Möglichkeit der Repräsentation von Weltwissen;
• 6 zeigt einen bekannten Ansatz zur Repräsentation von Wissen in einer NLU-Komponente;
• 7 zeigt einen erfindungsgemäß genutzten Ansatz zur Repräsentation von Wissen in einer NLU-Komponente; und
• 8 zeigt schematisch ein Systemdiagram eines erfindungsgemäßen NLU-Frameworks.

Further features of the present invention will become apparent from the following description and the appended claims in conjunction with the figures.

• 1 shows schematically a method for processing a user input;
• 2 shows a first embodiment of an apparatus for processing user input;
• 3 shows a second embodiment of an apparatus for processing user input;
• 4th shows schematically a means of locomotion in which a solution according to the invention is implemented;
• 5 shows a way of representing world knowledge;
• 6th shows a known approach to representing knowledge in an NLU component;
• 7th shows an approach used according to the invention for representing knowledge in an NLU component; and
• 8th schematically shows a system diagram of an NLU framework according to the invention.

For a better understanding of the principles of the present invention, embodiments of the invention are explained in more detail below with reference to the figures. It goes without saying that the invention is not restricted to these embodiments and that the features described can also be combined or modified without departing from the scope of protection of the invention as defined in the appended claims.

1 shows schematically a method for processing a user input. In a first step, user input is received 10 , e.g. a voice input or a text-based user input. At least one entity is then extracted from the user input 11 . The input variable for this step is a text sequence, for example when receiving 10 the user input was generated from a voice utterance. Data for the at least one entity are then queried from a knowledge base 12th . For example, the data queried from the knowledge base include relational attributes of the at least one entity. These can be determined by querying a knowledge graph. The data requested from the knowledge base are evaluated 13th . It can happen that in the crotch 11 no entity could be recognized. In this case, of course, no data can be queried from a knowledge base 12th . However, the knowledge that the user input did not contain an entity can also be used as part of the evaluation 13th can be used to make an informed decision. Using the results of the evaluation 13th a response to the user input is finally generated 14th . The answer can be, for example, a voice output or a text output. When evaluating 13th For example, a class can be determined for the at least one entity. Based on the class, it can be determined whether the at least one entity belongs to a supported domain or an unsupported domain. When evaluating 13th it can furthermore be determined whether the at least one entity lies outside a predetermined application area. In addition, a comparison can be made with the results of non-knowledge-based language processing.

2 shows a simplified schematic representation of a first embodiment of a device 20th to process user input NE . The device 20th has an entrance 21 , via which a receiving module 22nd a user input NE can receive, for example a voice input or a text-based user input. An extraction module 23 extracts at least one entity from the user input NE . Input variable for the extraction module 23 is a text string, for example from the receiving module 22nd was generated from a voice utterance when the user input was received. A query module 24 the device 20th queries data for the at least one entity from a knowledge base 51 from. For this purpose, the query module 24 via an interface 27 on the knowledge base 51 access. For example, the data queried from the knowledge base include relational attributes of the at least one entity. These can be determined by querying a knowledge graph. A processing module 25th evaluates those from the knowledge base 51 queried data and generates a response to the user input NE using the results of this evaluation. The generated response can then be sent through the interface 27 are issued. The answer can be, for example, a voice output or a text output. It can happen that the extraction module 23 no entity could be recognized. In this case, of course, no data can be queried from a knowledge base. However, the knowledge that the user input did not contain an entity can also be used by the processing module 25th can be used to make an informed decision. The processing module 25th can be set up to determine a class for the at least one entity during the evaluation. Based on the class, it can be determined whether the at least one entity belongs to a supported domain or an unsupported domain. The processing module 25th can also determine whether the at least one entity is outside of a predetermined scope. In addition, the processing module 25th be set up to carry out a comparison with the results of a non-knowledge-based language processing.

The receiving module 22nd , the extraction module 23 , the query module 24 and the processing module 25th can from a control module 26th being controlled. Via a user interface 29 If necessary, settings of the receiving module can be made 22nd , the extraction module 23 , of the query module 24 , the processing module 25th or the control module 26th be changed. The one in the device 20th Accruing data can be stored in a memory if required 28 the device 20th be stored, for example for a later evaluation or for use by the components of the device 20th . The receiving module 22nd , the extraction module 23 , the query module 24 , the processing module 25th as well as the control module 26th can be implemented as dedicated hardware, for example as integrated circuits. Of course, they can also be partially or completely combined or implemented as software that runs on a suitable processor, for example on a GPU. The entrance 21 and the interface 27 can be implemented as separate interfaces or as a combined bidirectional interface.

3 shows a simplified schematic representation of a second embodiment of a device 30th to process user input. The device 30th assigns a processor 32 and a memory 31 on. The device is, for example 30th a computer, workstation or control device. In the storage room 31 instructions are stored that the device 30th when executed by the processor 32 cause the steps to be carried out in accordance with one of the methods described. The ones in memory 31 Stored instructions are thus embodied by the processor 32 executable program which implements the method according to the invention. The device has an entrance 33 for receiving user input and information from a knowledge database. From the processor 32 generated data is via an output 34 provided. In addition, they can be in memory 31 be filed. The entrance 33 and the exit 34 can be combined to form a bidirectional interface.

The processor 32 may comprise one or more processor units, for example microprocessors, digital signal processors or combinations thereof.

The memory 28 , 31 of the described embodiments can have volatile and / or non-volatile storage areas and comprise a wide variety of storage devices and storage media, for example hard disks, optical storage media or semiconductor memories. Information can also be stored in a cloud.

4th shows schematically a means of locomotion 40 represents, in which a solution according to the invention is implemented. In this example it is the means of transportation 40 to a motor vehicle. The motor vehicle has a number of assistance systems 41 one of which is shown as an example. In addition, there is a sensor system 42 available from the assistance systems 41 is used and can be recorded through the information about the environment of the motor vehicle. Operation of the motor vehicle can be partially voice-based. The motor vehicle therefore has a device according to the invention 20th to process user input from a driver or another user. Further components of the motor vehicle are, for example, a navigation system 43 and a data transmission unit 44 . By means of the data transmission unit 44 can connect to a service provider 50 be built, in particular to a provider of a knowledge database. The knowledge database can be an offline service that is in the means of transport 40 running, or an online service, e.g. a cloud service or simply a website. A memory is used to store data 45 available. The data exchange between the various components of the motor vehicle takes place via a network 46 .

In the following, further details of a solution according to the invention will be given on the basis of 5 to 8th explained.

According to the invention, the above-described limitation of current NLU components is overcome in that the knowledge of the NLU component is expanded in such a way that it can understand a large number of entities, such as courts or sports clubs, for example. It should be noted that the world is constantly changing. New entities emerge every day, making it almost impossible to keep an internal vocabulary up-to-date without great expense. In addition, the system should not only have knowledge about entities available, but also knowledge about the relationships between the entities. For this reason, a dynamic and structured approach to maintaining system knowledge is used.

In this context, the online knowledge database Wikidata [1] provides a structured knowledge resource that contains millions of entities and their relationships, is continuously updated, collaboratively edited and checked and is under the control of millions of users around the world. 5 illustrates how world knowledge of the foods “lasagna” and “pho” is recorded. In the present case, the relational attributes “subclass-of”, “instance-of”, “country of origin” and “has part” are of particular importance. These attributes can be used by an NLU component can be used for meaningful conclusions. The framework presented is generic and scalable so that any other similar knowledge base can also be used.

If the existing NLU framework in the vehicle is to support a user request such as “I want to Pho.”, Then a new “dishes” vocabulary list must be set up for storing dishes and the dishes must also be assigned to the corresponding “kitchen”. This well-known approach is in 6th shown. A user request such as “I want Pho.” Can be processed by first identifying the mention of an entity (x): = Pho from the list of dishes and then using the mappings to the list of kitchens to infer that the User about the kitchen: = speaks Vietnamese. As mentioned at the beginning, however, this approach does not scale if the user mentions a dish that does not exist in the vocabulary.

The approach used according to the invention for representing knowledge is in 7th shown. The approach involves a new way of inferring knowledge about an entity. In the simplest case, this requires that a given entity x is a type of an abstract entity Y, eg Y: = {food, soup, artist, album, place}. The set of abstract entities is motivated by the class of entities in the scope of the system functions. The set of classes can be derived manually or algorithmically from the relational hierarchy between the entities and the abstract types in a hierarchical knowledge base. Whether x is a type or a subclass or instance of an abstract entity can be verified by querying the knowledge graph. In the simplest case, such queries check whether x is connected to Y by a property path “subclass-of” or “instance-of”. For entity (x): = Pho it can be derived from Wikidata that subclass-of (x, Y): = food applies. That is, pho is a type of food.

In addition, the “Country of origin” attribute of the entities of the type food in the knowledge base can be used to infer the type of kitchen. It can also be the case that the property “kitchen” is explicitly recorded in the knowledge base. Specifically, for the entity (x): = Pho the knowledge from Wikidata that subclass-of (x): = food and country of origin (x): = Vietnam applies, can be used to infer that the user is looking for Vietnamese Restaurants is interested. This corresponds to a search function in the vehicle with place-of-interest (p): = restaurant and kitchen (p): = Vietnamese.

The approach described scales with the size of the knowledge base. With the simple logic of inferring the type of an entity using a hierarchically structured knowledge base and using various properties, the NLU component in the vehicle is able to identify every dish and cuisine mentioned in the knowledge base.

The approach described above for expanding the NLU capabilities of the voice assistants for use cases in the vehicle is based on the identification of the entities named by the user and the respective type. The ability of an NLU component to understand all kinds of named entities is also useful for handling user requests that are beyond the capabilities of the wizard. The range of functions of a voice assistant, i.e. supported domains, intentions or entities, is usually not known to the user. A voice assistant in the vehicle can support the areas of navigation, media, telephone, vehicle functions, etc., but cannot answer questions about sports results. As already explained at the beginning, to the question “How did Borussia Dortmund play?” The system answer “Unfortunately, I cannot help you on the subject of sports” would be more appropriate.

With the approach according to the invention, this can be achieved with little effort. The starting point is the identification of the entity named by the user, i.e. entity (x): = Borussia Dortmund. The type of x is then derived from the actual type of (x) query to the knowledge base. In the above-mentioned list of abstract classes Y: = {food, soup, artist, album, location} for the supported domains (in-domain classes), it is expected that the query actual-type-of (x, Y) returns null. This is not necessarily helpful. However, using the same approach, a list of abstract classes for unsupported domains (out-of-domain classes) can be created and maintained manually or algorithmically, e.g. O: = {sports, news}. In this case, a query of the actual type of (x, O) to the knowledge database would result in the fact that the actual type of (x, O): = sport applies.

Using the inferred knowledge that the user named an entity from a class of an unsupported domain, namely sports, the voice assistant can respond to the user in a smarter way, such as "Sorry, I don't know much about sports." . In this way, the system can convey that it is able to understand user requests even if they are not within the scope of the system.

We now have to consider the case where the user mentions something that does not belong to either the supported domains classes or the unsupported domains classes. Such statements by the user represent requests outside the scope. For example, such a request to a digital assistant in the vehicle could be “Can you tell me something about Game of Thrones?”. A typical answer to this would be "Sorry, I didn't understand you." As before, such a system response is not clear enough: the user does not know if something went wrong with the communication channel or if the system is unable to talk about TV series. For example, a more appropriate system response would be "Sorry, I don't know much about TV series."

If the NLU component is unable to determine the type of an entity x using one of the two approaches as the type of a class of the supported domains (lst-type-of (x, Y)) or the type of a class of the unsupported domains ( To identify is-type-of (x, O)), it can mark the request as out of scope and query the knowledge base only with regard to the type of entity, ie, is-type-of (x). For a hierarchical knowledge base in which an entity is linked to other types in a hierarchical form, such a query provides the various possible class types of x. The shortcuts in 5 For example, it can be seen that Pho is a subclass of soup and dish, that soup is a subclass of liquid, and that dish is a subclass of food. A corresponding query thus provides the actual type of (x): = {dish, food, soup, liquid}. This essentially represents that pho is a dish, that pho is also a food, that pho is actually a soup, and that pho is a liquid.

All of these interpretations are correct according to the knowledge base, the degree of description varying and the fact that Pho is a liquid is likely too abstract for a meaningful system answer. However, this approach to the NLU component offers several possible interpretations.

For the above question about "Game of Thrones", ie Entity (x): = Game of Thrones, the NLU component receives a series of interpretations by querying a knowledge base, eg actual type of (x): = {TV series , Series, tv show, brand}. These interpretations can be used to generate different intelligent system responses. Possible answers would be, for example, “Sorry, I don't know a lot about TV shows”, “Sorry, I don't know a lot about series” or “Sorry, I don't know a lot about the brand.” An intelligent assistant can algorithmically learn which one Alternatives are more appropriate for human understanding. Such an algorithm can use knowledge specified by the system developer, for example. Alternatively or additionally, the algorithm can automatically learn from general knowledge about the world, or even use the reaction of the user to the selected system reaction in order to learn whether the reaction was appropriate for the user.

8th schematically shows a system diagram of an NLU framework according to the invention 60 . A number of processing modules are used to extract and resolve named entities such as “Lasagne” or “Borussia Dortmund” using a structured knowledge base. An extraction module 61 is used to recognize the entities that are being spoken about in a phrase. A conventional NLU module 62 is able to recognize user intent and functional area with regard to in-vehicle applications. A knowledge-based NLU module 63 searches for entities found in an external knowledge base and retrieves their properties. The result of the conventional NLU module 62 can be used to disambiguate the hypotheses of the knowledge base and select the correct type of entity when the knowledge base provides multiple results. For example, the knowledge base can provide two search results for “lasagne”. The first is a food and the second is a family name. The conventional NLU module classified the intention of the utterance as a "call". Application-specific logic in this case selects the second result, i.e. the family name, based on the compatibility between entity and intention. Conversely, the conventional NLU module 62 from the knowledge-based NLU module 63 benefit from disambiguating his own understanding of speech. A fusion module 64 eventually merged the results. If the result of the conventional NLU module 62 has a high rating and the entities retrieved from the knowledge base are compatible with this result, the results are merged.

Example: "Find a place where lasagne is served" Conventional NLU result: Domain = Navigation, Intent = Search_POI Knowledge-based NLU result: Food = Lasagne, Country of origin = Italy Combined NLU result: Domain = Navigation, Intent = Search_POI, Food = lasagna, country of origin = Italy

If the result of the conventional NLU module 62 has a low rating and a named entity was found in the knowledge base, the properties of that entity can be can be used to generate an intelligent rejection.

Example: “How did Borussia Dortmund play?” Conventional NLU result: domain = media Knowledge-based NLU result: sports club = Borussia Dortmund, property = sport Combined NLU result: domain = sport

credentials

[1] https://www.wikidata.org

List of reference symbols

10

Receiving user input

11

Extract at least one entity from the user input

12th

Retrieving data for the at least one entity from a knowledge base

13th

Evaluation of the data requested from the knowledge base

14th

Generate a response to user input

20th

contraption

21

Entrance

22nd

Receiving module

23

Extraction module

24

Query module

25th

Processing module

26th

Control module

27

interface

28

Storage

29

User interface

30th

contraption

31

Storage

32

processor

33

Entrance

34

Exit

40

Means of transportation

41

Assistance system

42

Sensors

43

navigation system

44

Data transmission unit

45

Storage

46

network

50

Service provider

51

Knowledge base

60

NLU framework

61

Extraction module

62

Conventional NLU module

63

Knowledge-based NLU module

64

Fusion module

NE

User input

QUOTES INCLUDED IN THE DESCRIPTION

This list of the documents listed by the applicant was generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Patent literature cited

• EP 3392878 A1 [0003]
• US 7398209 B2 [0004]

Claims (11)

Method for processing a user input (NE), with the steps: - Receiving (10) a user input (NE); - Extracting (11) at least one entity from the user input (NE); - Querying (12) of data for the at least one entity from a knowledge base (51); - Evaluation (13) of the data requested from the knowledge base (51); and - Generating (14) a response to the user input (NE) using the results of the evaluation (13). Procedure according to Claim 1 , the user input (NE) being a voice input or a text-based user input. Procedure according to Claim 1 or 2 wherein the data queried from the knowledge base (51) comprise relational attributes of the at least one entity. Method according to one of the preceding claims, wherein the data queried from the knowledge base (51) are determined by querying a knowledge graph. Method according to one of the preceding claims, wherein a class for the at least one entity is determined on the basis of the data queried from the knowledge base (51). Procedure according to Claim 5 wherein it is determined based on the class whether the at least one entity belongs to a supported domain or an unsupported domain. Method according to one of the Claims 1 to 4th wherein, on the basis of the data queried from the knowledge base (51), it is determined whether the at least one entity lies outside a predetermined application area. Method according to one of the preceding claims, wherein during the evaluation (13) of the data queried from the knowledge base (51) a comparison with results of a non-knowledge-based language processing is carried out. Computer program with instructions which, when executed by a computer, enable the computer to carry out the steps of a method according to one of the Claims 1 to 8th cause a user input (NE) to be processed. Device (20) for processing a user input (NE), with: - A receiving module (22) for receiving (10) a user input (NE); - An extraction module (23) for extracting (11) at least one entity from the user input (NE); - A query module (24) for querying (12) data for the at least one entity from a knowledge base (51); and - A processing module (25) for evaluating (13) the data requested from the knowledge base (51) and for generating (14) a response to the user input (NE) using the results of the evaluation (13). Means of locomotion (40), characterized in that there is a device (20) according to Claim 10 has or is set up, a method according to one of the Claims 1 to 8th to process a user input (NE).

Images