Voice dialogue execution method, electronic device, and storage medium
By generating semantic information for voice requests and determining the target execution domain, the problem of insufficient cross-scenario integration capabilities in in-vehicle human-machine dialogue is solved, achieving efficient voice dialogue processing and flexible switching between multi-turn dialogues, thus improving the user experience.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-11-24
- Publication Date
- 2026-04-10
AI Technical Summary
Existing in-vehicle human-machine dialogue scenarios lack cross-scenario integration capabilities. Voice dialogues typically do not support transitions before the task is completed, which raises the barrier for users to use multi-turn voice dialogues and limits interactive functions.
By generating semantic request information corresponding to voice requests, the target execution domain is determined, and the dialogue results of this round of dialogue are generated based on the target execution domain. The dialogue engine stores user voice requests and dialogue context, supporting cross-scenario voice jumps and flexible switching between multi-round dialogues.
It improves the efficiency of the dialogue engine in processing user voice requests, lowers the barrier for users to use multi-turn voice dialogue, enriches interactive functions, and supports cross-scenario voice jumps and flexible switching of multi-turn dialogues.
Smart Images

Figure CN115862619B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present disclosure relates to the technical field of voice interaction, and in particular, to a voice dialogue execution method, an electronic device, and a storage medium. BACKGROUND
[0002] Current vehicle-mounted man-machine dialogue scenarios are single and lack cross-scene integration capabilities. Voice dialogue usually does not support jumping before the current task is completed, and even if individual scenarios can jump, they cannot achieve switching and returning of voice dialogue. SUMMARY
[0003] The present disclosure provides a voice dialogue execution method, device, electronic device, and storage medium.
[0004] According to an aspect of the present disclosure, a voice dialogue execution method is provided, comprising:
[0005] In response to a voice request of a user, generating semantic request information corresponding to the voice request, the semantic request information comprising intent information;
[0006] According to the semantic request information, determining a target execution domain;
[0007] Generating a dialogue result of the current dialogue based on the target execution domain.
[0008] According to another aspect of the present disclosure, an electronic device is provided, comprising:
[0009] at least one processor; and
[0010] a memory in communication with the at least one processor; wherein
[0011] The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the method in any embodiment of the present disclosure.
[0012] According to another aspect of the present disclosure, a non-transitory computer-readable storage medium having computer instructions is provided, the computer instructions being used to make a computer execute the method in any embodiment of the present disclosure.
[0013] According to the technology of the present disclosure, semantic request information containing intent information can be generated according to a voice request of a user, a target execution domain for executing the current dialogue is determined in the dialogue engine, the dialogue result is quickly obtained, the efficiency of the dialogue engine processing the voice request of the user and the flexibility of voice jumping are improved, the threshold for using multi-turn voice dialogue by the user is reduced, and the interactive function is enriched.
[0014] It should be understood that nothing in this section is intended to limit the scope of the embodiments of the present disclosure. Other aspects of the present disclosure will become apparent to those of ordinary skill in the art upon reviewing the description of the embodiments of the present disclosure. BRIEF DESCRIPTION OF DRAWINGS
[0015] The accompanying drawings are included to provide a further understanding of the present application, and are incorporated in and constitute a part of this specification. The drawings illustrate embodiments of the present application and, together with the description, serve to explain the principles of the present application.
[0016] Figure 1 is a flowchart of a voice dialogue execution method according to an embodiment of the present disclosure Figure 1 ;
[0017] Figure 2 is a flowchart of a voice dialogue execution method according to an embodiment of the present disclosure Figure 2 ;
[0018] Figure 3 is a flowchart of a voice dialogue execution method according to an embodiment of the present disclosure Figure 3 ;
[0019] Figure 4 is a flowchart of a voice dialogue execution method according to an embodiment of the present disclosure Figure 4 ;
[0020] Figure 5 is a flowchart of a voice dialogue execution method according to an embodiment of the present disclosure Figure 5 ;
[0021] Figure 6 According to an embodiment of the present disclosure, a user interaction structure diagram with a dialogue engine implementing an embodiment of the present application is shown;
[0022] Figure 7 and Figure 8 According to an embodiment of the present disclosure, a multi-turn dialogue flowchart after the dialogue engine is started for the first time is shown;
[0023] Figure 9 is a block diagram of an electronic device for implementing a dialogue execution method according to an embodiment of the present disclosure. DETAILED DESCRIPTION
[0024] Exemplary embodiments of the present disclosure are described herein with reference to the accompanying drawings, which include various details of the embodiments of the present disclosure to assist in the understanding of the present disclosure. They should be considered in a descriptive sense only and not for purposes of limiting the scope of the present disclosure. As such, various changes and modifications will become apparent to those of ordinary skill in the art upon reading the description of the embodiments of the present disclosure, and it is intended to embrace all such changes and modifications as fall within the scope of the present disclosure.
[0025] In the related art, multi-turn voice dialogues usually do not support jumping before a task is completed. Even if some scenarios can achieve jumping, they cannot guarantee switching back. For example, a current multi-turn voice dialogue is for a navigation task, a user voice instruction is "navigate to the Oriental Pearl", an interface displays three recommended routes for the user to select, but the user does not continue the related voice instruction for navigation, but suddenly instructs "call Zhang San", thereby initiating a new multi-turn voice dialogue. Since multi-turn voice dialogues often involve complex scenarios, they may need to process multiple messages such as confirmation or cancellation, therefore, in order to avoid semantic conflicts during jumping or task execution failures caused by jumping, there are usually two processing methods to solve this problem.
[0026] One processing method is to prohibit jumping to a new multi-turn voice dialogue in a multi-turn voice dialogue, such as switching from a navigation multi-turn voice dialogue to a call multi-turn voice dialogue. Another processing method is to perform jumping to a new multi-turn voice dialogue, but prohibit switching back to the original multi-turn voice dialogue, such as switching from a navigation multi-turn voice dialogue to a call multi-turn voice dialogue, prompting the user "Zhang San has two numbers, do you want to call the first number", if the user voice instruction confirms, the number is directly called to perform the call task, after the user completes the call, switching back to the previous navigation interface is prohibited, the previous navigation multi-turn voice dialogue has ended, and the user needs to reinitiate the dialogue, thereby avoiding the navigation task from being unable to continue to be correctly executed due to switching.
[0027] The above processing methods set corresponding restrictions on jumping of multi-turn voice dialogues, increase the threshold for users to use multi-turn voice dialogues, greatly limit interactive functions, and reduce user experience.
[0028] Figure 1 FIG. 1 is a flow diagram of a voice dialogue execution method according to an embodiment of the present disclosure, which can include the following steps.
[0029] S110, in response to a voice request of a user, generating semantic request information corresponding to the voice request, the semantic request information including intent information;
[0030] S120, determining a target execution domain according to the semantic request information;
[0031] S130, generating a dialogue result of the current dialogue based on the target execution domain.
[0032] In an embodiment of the present application, the scene can be a vehicle end dialogue scene, such as dialogue in a vehicle control scene, dialogue in a driving scene, dialogue in an audio and video entertainment scene, dialogue in a navigation scene, etc. Among them, vehicle control can be understood as control of vehicle body components, such as opening the door, opening the window, turning on the light, adjusting the seat, etc. The driving scene can be understood as a scene related to vehicle driving, such as adjusting the suspension, controlling the electrical park brake (EPB), shifting gears, etc.
[0033] Among them, the scene domain can be preset for each scene. Exemplarily, the scene domain includes a plurality of execution domains and a plurality of public keys; wherein the execution domain is generated by logically arranging at least one to-be-executed task, and the to-be-executed task is generated by modally arranging modal data in at least one scope; each modal data in the same scope has the same or associated data type. Details are explained below.
[0034] (1) Scope
[0035] The scope can include a parameter domain (Param), a signal domain (Signal), a service domain (Service), a request domain (Request), a hidden domain (Mask), a response domain (Response), and a sandbox domain (Sandbox), etc.
[0036] Exemplarily, the parameter domain can be used to store parameters transmitted by the scene domain, the execution domain, the to-be-executed task, etc. when running across block scheduling. The signal domain can be used to carry modal data of a vehicle perception system, modal data of a vehicle to everything (V2X) system, modal data of a wearable device, etc., and is a kind of signal pool that can be arranged, observed (monitored or listened to), and scheduled. Therefore, the signal domain is a container for massive signals, and the producers of the signals continuously register signals to the signal pool, and the consumers (listeners / active dialogue / passive dialogue) of the signals subscribe to the signals of interest from the signal domain. For example: vehicle speed as a kind of modal data, the vehicle speed changes continuously, and the execution domain that registers the signal can monitor the change of the vehicle speed, or when registering the signal, a trigger condition of the change of the vehicle speed is preset, and when the change of the vehicle speed meets the trigger condition, the execution domain will be notified.
[0037] The situational dialogue and interactive scene script need to call the application programming interface (API) of the in-system application and the service outside the system, and the service domain is used to encapsulate the calling details of the service and arrange the data returned by the service. Among them, the in-system application can include navigation, multimedia, frequency modulation (FM), account, digital car, etc., and the service outside the system can be a scene service of the vehicle enterprise, such as Geek World, or a third-party service, such as an artificial intelligence (AI) service irobot.
[0038] The request domain can be used in passive dialogue, and a request domain is generated based on a single semantic input of a user. The modal data of the request domain can be encoded by an encoder into data that can be arranged by a hidden domain. The response domain can be used to carry the response result of generating active dialogue, passive dialogue, interactive dialogue, timeline, listener, etc. business by a decoder according to the modal data in the hidden domain bound with the execution domain. The hidden domain can be used to carry the dialogue context corresponding to the current semantic input, specifically including the semantic request information of the user and the corresponding semantic response information, which is reused or regenerated by the dialogue and interactive scene as needed, and the hidden domain is bound with the execution domain. Each execution domain will bind a hidden domain for carrying the dialogue context of the execution domain. The sandbox domain can carry the global dialogue context of a certain device or a certain user, that is, carry all the hidden domains corresponding to a certain device or a certain user, and is used to isolate the arrangeable data of different devices or different users, which is a super context.
[0039] It can be understood that data will be generated during the task execution of the execution domain, and these data are stored in the hidden domain as dialogue context, and the hidden domain is bound with the execution domain to record this dialogue. The global dialogue context is stored in the sandbox domain, including all dialogue contexts.
[0040] (2) Scene domain
[0041] The same type of business is aggregated to form a scene domain, and the scene domain is composed of multiple execution domains and other auxiliary components. The execution domain in it can be a simple domain and / or a complex domain. The scene domain can be divided into different scenes according to the business type, such as driving scene, audio-visual entertainment scene, navigation scene, vehicle control scene, etc.
[0042] (3) Execution domain
[0043] The to-be-executed task is generated by modal arrangement of the modal data in at least one scope. The modal arrangement can determine how to run the modal data in the scope, and the operators can include comparison operations, inclusion operations, assignment operations, etc. Each operator can be called when generating the to-be-executed task. During the modal arrangement (operation), the symbols of the modal data in each scope can be preset to be called, for example, the modal data in the parameter domain can be called by ( : ), the modal data in the label domain can be called by (! ), the modal data in the signal domain can be called by ( ~ ), the modal data in the service domain can be called by ( @ ), the modal data in the request domain can be called by ( % ), the modal data in the hidden domain can be called by ( $ ), the modal data in the response domain can be called by ( ^ ), and the modal data in the sandbox domain can be called by ( * ). The to-be-executed task is a basic dialogue or business scenario unit, which cannot be executed independently and is the smallest unit of the execution domain. The to-be-executed task can be a standard task, that is, a task composed of a condition group and an execution group, or a logic task, that is, a logic block task composed of if, elseif, else, foreach and other logic conditions, or a simple task, that is, a task of quickly finding an assignment (value) through a key, and the state becomes end (END) or return (RETURN).
[0044] Therefore, the business developer can determine the to-be-executed task according to the business requirement, call the modal data in the corresponding scope according to the task requirement of the to-be-executed task, and perform operations to generate the to-be-executed task. Further, one or more to-be-executed tasks are logically arranged to generate an execution domain.
[0045] According to different logical arrangement forms, the execution domain can include a simple domain and a complex domain.
[0046] The simple domain includes one or more first to-be-executed tasks, wherein the first to-be-executed task is used to implement a single round dialogue business, that is, the simple domain is used to carry out an executable single round dialogue or a simple active business scenario or passive business scenario. The complex domain includes one or more second to-be-executed tasks, and the second to-be-executed task is used to implement a multi-round dialogue business, that is, the complex domain is used to carry out an executable multi-round scenario dialogue or a complex interactive business scenario.
[0047] Exemplarily, in step S130, specifically includes:
[0048] The to-be-executed task in the target execution domain is executed to generate semantic response information of the current round of dialogue;
[0049] In the case that the hidden domain corresponding to the target execution domain exists in the sandbox domain, the semantic request information and the semantic response information of the current round of dialogue are recorded in the hidden domain, and the dialogue tag of the current round of dialogue is determined based on the registration information of the hidden domain in the sandbox domain;
[0050] The semantic response information and the dialogue tag are taken as the dialogue result of the current round of dialogue.
[0051] It can be understood that, according to the foregoing introduction of the scopes in the dialogue engine, the hidden domain bound by each execution domain is carried in the sandbox domain, and the hidden domain is used to carry the semantic request information obtained according to the user voice request and the semantic response information corresponding to the semantic request, as the dialogue context.
[0052] If the hidden domain corresponding to the target execution domain already exists in the sandbox domain, it indicates that the semantic request information of the dialogue scene before the current round of dialogue has involved the target execution domain, and the semantic request information and the semantic response information of the current round of dialogue are only recorded in the hidden domain corresponding to the target execution domain, and the registration information of the hidden domain in the sandbox domain is obtained as the dialogue tag of the current round of dialogue.
[0053] In an implementation, the process performed in step S130 also exists in the case that the hidden domain corresponding to the target execution domain does not exist in the sandbox domain, and specifically includes:
[0054] The target execution domain is executed to generate the semantic response information of the current round of dialogue;
[0055] In the case that the hidden domain corresponding to the target execution domain does not exist in the sandbox domain, the hidden domain corresponding to the target execution domain is created and registered in the sandbox domain, the semantic request information and the semantic response information of the current round of dialogue are recorded in the hidden domain, and the dialogue tag of the current round of dialogue is determined based on the registration information of the hidden domain in the sandbox domain.
[0056] The semantic response information and the dialogue tag are taken as the dialogue result of the current round of dialogue.
[0057] It can be understood that, in the case that the hidden domain corresponding to the target execution domain does not exist in the sandbox domain, it indicates that the semantic request information obtained after the dialogue engine is started this time does not involve the target execution domain, and the hidden domain corresponding to the target execution domain has not been created. In this case, the hidden domain corresponding to the target execution domain needs to be created and registered in the sandbox domain, and then the semantic request information and the semantic response information are recorded, and the dialogue tag of the current round of dialogue is obtained.
[0058] The semantic request information and the semantic response information corresponding to the user voice received and processed by the dialogue engine each time after the dialogue engine is started are stored in a hidden field in the sandbox field as a dialogue context, and if the semantic request information of the subsequent dialogue involves an existing hidden field, the subsequent dialogue can continue to use the existing hidden field, so that repeated work is avoided, and the processing efficiency of the dialogue engine is improved.
[0059] Specifically, the step S110 includes:
[0060] The voice request is parsed to obtain intent information and field information corresponding to the voice request.
[0061] The dialogue tag of the previous dialogue is obtained.
[0062] The semantic request information is generated based on the intent information, the field information, and the dialogue tag of the previous dialogue.
[0063] It can be understood that the dialogue engine needs to process the voice request into semantic request information that can be understood by the machine when receiving the voice request of the user. The processing process can include noise reduction and suppression, voice recognition, and semantic understanding. The noise reduction and suppression can eliminate interference factors and improve the accuracy of machine voice recognition. The voice recognition translates the voice request of the user into text. Further, the semantic understanding translates the text into semantic request information that can be recognized and understood by the machine.
[0064] In the embodiments of the present application, according to the above-mentioned related explanations of the preset scene field and the execution field, the semantic request information for machine recognition and understanding at least needs to include field information for determining the scene field and intent information for determining the execution field in the scene field. The field information can include vehicle control field, navigation field, telephone field, audio and video entertainment field, etc. The intent information can be “open / close the vehicle door”, “open / close the vehicle window”, “play a certain movie / TV series”, “navigate to a certain place”, etc.
[0065] In addition, if the current dialogue is not the first dialogue after the dialogue engine is started, the semantic request information should also include the dialogue tag of the previous dialogue, which is used to search the hidden field in the sandbox field to store the context of the previous dialogue, so as to facilitate the subsequent judgment of the continuation relationship between the current dialogue and the previous dialogue.
[0066] The method of the above-mentioned embodiments converts the voice request of the user into semantic request information containing intent information and field information, and the dialogue tag of the previous dialogue, so as to facilitate the dialogue engine to quickly determine the execution field corresponding to the current dialogue, and improve the processing efficiency of the machine.
[0067] Specifically, as shown in Figure 2 the step S120 includes:
[0068] S201, determine a first hidden field based on a dialogue label of a previous round of dialogue in the semantic request information;
[0069] S202, in a case where the intent information in the semantic request information matches the first hidden field, determine a first execution field corresponding to the first hidden field as a target execution field.
[0070] Exemplarily, the dialogue label of the previous round of dialogue contains a storage location of a hidden field corresponding to the previous round of dialogue in the sandbox field, that is, the first hidden field determined based on the dialogue label of the previous round of dialogue is the hidden field corresponding to the previous round of dialogue. If the intent information in the semantic request information matches the first hidden field, it indicates that the current round of dialogue and the previous round of dialogue have a continuation relationship, and the intent of the two dialogues has not changed, and the first execution field corresponding to the first hidden field, that is, the execution field of the previous round of dialogue, is still used as the target execution field of the current round of dialogue.
[0071] In an embodiment, as shown in FIG. 2, Figure 3 after step S201, the method can further include:
[0072] S301, in a case where the intent information in the semantic request information does not match the first hidden field, determine a second hidden field matching the intent information;
[0073] S302, determine a second execution field corresponding to the second hidden field as the target execution field.
[0074] It can be understood that if the intent information does not match the first hidden field, it indicates that there is no continuation relationship between the current round of dialogue and the previous round of dialogue, and the user's intent has changed compared with the previous round of dialogue. However, the sandbox field still stores hidden fields corresponding to other execution fields involved in the current start of the dialogue engine, so it can be determined in the other hidden fields stored in the sandbox field whether there is a second hidden field matching the intent information. If there is, it indicates that the second execution field corresponding to the second hidden field is involved in the previous dialogue, and the second hidden field records the context of the previous dialogue with the same intent as the current round of dialogue. The second execution field corresponding to the second hidden field is determined as the target execution field, which can jump back to the dialogue scene before the current round of dialogue according to the recognized intent information, and refer to the context information of the previous dialogue to more accurately respond to the user's voice.
[0075] By using the method in the above embodiment, since the hidden domain in the sandbox domain stores the context information of the dialogue involved after the dialogue engine is started, the intent information can be compared with the first hidden domain corresponding to the last round of dialogue according to the dialogue tag of the last round of dialogue in the semantic request information, whether the current round of dialogue is a continuation of the last round of dialogue is judged, if the intent information does not match the first hidden domain, the intent information is compared with other hidden domains in the sandbox domain, the user voice can be more intelligently processed, the continuation relationship of the dialogue is accurately recognized and the dialogue jump function is provided, the dialogue not ended before is continued, the threshold for using the multi-round voice dialogue by the user is reduced, and the interactive function is enriched.
[0076] In an implementation manner, as shown in FIG. 7, after step S201, the method can further include: Figure 4
[0077] S401, in the case where there is no second hidden domain matching the intent information, determining a target scene domain in a plurality of preset scene domains according to the domain information in the semantic request information;
[0078] S402, determining a third execution domain corresponding to the intent information in a plurality of preset execution domains of the target scene domain;
[0079] S403, determining a voice jump strategy based on the first execution domain, the target scene domain and the third execution domain;
[0080] S404, in the case where the voice jump strategy is to allow jump, determining the third execution domain as the target execution domain.
[0081] It can be understood that, if there is no hidden domain in the sandbox domain matching the intent information, it indicates that the intent information of the current round of dialogue is different from the intent information of the dialogue before, the target scene domain corresponding to the user voice request is determined in the preset scene domain according to the domain information in the semantic request information, and the third execution domain corresponding to the intent information is determined in the plurality of preset execution domains of the target scene domain.
[0082] Based on the foregoing introduction to the scene domain and the execution domain, the execution domain includes a simple domain for implementing a single round of dialogue and a complex domain for implementing a multi-round dialogue. In the embodiment of the present application, based on the scene domain, the dialogue jump can be divided into intra-scene jump and cross-scene jump. Based on the execution domain, the dialogue jump can be further divided into single round to single round, single round to multi round, multi round to single round, multi round to multi round and the like on the basis of intra-scene jump or cross-scene jump.
[0083] In step S403, the first scene domain to which the first execution domain belongs can be further determined based on the first execution domain, the voice jump strategy can be determined based on the first scene domain, the first execution domain, the target scene domain and the third execution domain, and the first scene domain and the target scene domain can be the same scene domain.
[0084] It can be understood that the dialogue engine preconfigures rules of corresponding scene jump and multi-turn, single-turn dialogue jump based on functions and security performance, and the voice jump strategy is determined by the dialogue engine according to the preconfigured rules and corresponding scene domains and execution domains of the current dialogue and the previous dialogue.
[0085] In an implementation, after step S403, the method further includes:
[0086] In the case that the voice jump strategy is the prohibited jump, the first execution domain is determined as the target execution domain.
[0087] It can be understood that, in the case that the voice jump strategy is the prohibited jump, it indicates that there is a jump limit between the scene domain corresponding to the current dialogue and the scene domain of the previous dialogue, or there is a jump limit between the execution domains of the current dialogue and the previous dialogue. In this case, the previous dialogue needs to be executed first, and therefore the first execution domain corresponding to the previous dialogue is determined as the target execution domain, that is, the previous dialogue is determined as a new current dialogue for continuous execution.
[0088] The determination of the voice jump strategy is exemplified as follows:
[0089] 1) If the scene domain of the previous dialogue is the telephone domain, the scene domain corresponding to the intent information of the current dialogue is the audio-visual entertainment domain, and it is configured by default that there is a jump limit between the telephone domain and the audio-visual entertainment domain, the first execution domain corresponding to the previous dialogue in the telephone domain is determined as the target execution domain.
[0090] 2) If the scene domain of the previous dialogue is the navigation domain, the user voice input is “close the window”, that is, the scene domain corresponding to the intent information of the current dialogue is the vehicle control domain, and it is configured by default that there is no jump limit between the navigation domain and the vehicle control domain, the execution domain for executing “close the window” in the vehicle control domain is determined as the target execution domain.
[0091] 3) If the scene domains corresponding to the intent information of the previous dialogue and the current dialogue are both the vehicle control domain, the execution domain of the previous dialogue is used for “close the air conditioner”, and the execution domain of the current dialogue is used for “close the window” to achieve the execution domain of the single-turn dialogue. It is configured by default that there is no jump limit between the single-turn dialogues, and therefore the execution domain for executing “close the window” in the vehicle control domain is determined as the target execution domain.
[0092] 4) If the scenario domains corresponding to the intent information of the previous and current rounds of dialogue are both in the vehicle control domain, and the execution domain of the previous round of dialogue is used for "adjusting the air conditioning temperature," the tasks to be executed in this execution domain include "determining the air conditioning position to be adjusted (front and / or rear seats)" and "determining the adjusted temperature," etc., which belong to the execution domain for implementing multi-round dialogue. The execution domain of the current round of dialogue is used for "closing the windows," which is the execution domain for implementing single-round dialogue. By default, there are no jump restrictions when inserting single-round dialogues into multi-round dialogues. Therefore, the execution domain in the vehicle control scenario domain used to execute "closing the windows" is determined as the target execution domain.
[0093] 4) If the scenario domains corresponding to the intent information of the previous and current rounds of dialogue are both in the vehicle control domain, and the execution domain of the previous round of dialogue is used for "adjusting the air conditioning temperature," the tasks to be executed in this execution domain include "determining the air conditioning position to be adjusted (front and / or rear seats)" and "determining the adjusted temperature," etc., which belong to the execution domain for implementing multi-round dialogue. The execution domain of the current round of dialogue is used for "closing the windows," which is the execution domain for implementing single-round dialogue. By default, there are no jump restrictions when inserting single-round dialogues into multi-round dialogues. Therefore, the execution domain in the vehicle control scenario domain used to execute "closing the windows" is determined as the target execution domain.
[0094] 5) If the scenario domains corresponding to the intent information of the previous and current rounds of dialogue are both in the vehicle control domain, and the execution domain of the previous round of dialogue is used for "adjusting the air conditioning temperature", the tasks to be executed in this execution domain include "determining the air conditioning position to be adjusted (front and / or rear)" and "determining the adjusted temperature", etc., it belongs to the execution domain for realizing multi-round dialogue. The execution domain of the current round of dialogue is used for "adjusting the air conditioning fan speed", and the tasks to be executed in this execution domain can include "determining the air conditioning position to be adjusted (front and / or rear)" and "determining the adjusted fan speed", etc., it also belongs to the execution domain for realizing multi-round dialogue. Therefore, the dialogue jump scenario in this case belongs to multi-round dialogue to multi-round dialogue, and further judgment is needed based on the pre-configured rules. If the default configuration does not have jump restrictions for the two execution domains of "adjusting the air conditioning temperature" and "adjusting the air conditioning fan speed", then the execution domain in the vehicle control scenario domain used to execute "closing the windows" can be determined as the target execution domain.
[0095] The above description of the jump strategy and pre-configured jump rules is only an example and is not intended to limit the embodiments of this application. In actual execution, it can be flexibly configured according to the functional safety requirements of the dialogue engine.
[0096] In an implementation, no matter whether the execution domain is used to support a multi-turn dialogue scenario or a single-turn dialogue scenario, if the semantic response information generated by executing the to-be-executed task in the execution domain meets the preset execution completion condition, it can be considered that the user request related to the execution domain has been completely processed, and subsequent task execution does not need to continue to refer to the dialogue context in the hidden domain corresponding to the execution domain. In this case, the hidden domain corresponding to the execution domain that meets the preset execution completion condition can be unregistered in the sandbox domain, reducing the storage burden of the sandbox domain and improving the efficiency of subsequent dialogue jump matching.
[0097] For example, in the scene domain corresponding to the vehicle control field, the execution domain of "adjusting the air conditioner temperature" supports a multi-turn dialogue scenario. If the air conditioner position to be adjusted by the user and the adjusted air conditioner temperature have been obtained through multi-turn dialogue interaction, the dialogue engine can generate semantic response information indicating that the user request has been received and the air conditioner temperature will be adjusted. In this case, the execution domain corresponding to "adjusting the air conditioner temperature" meets the preset execution completion condition, and the hidden domain corresponding thereto can be unregistered in the sandbox domain.
[0098] For another example, in the scene domain corresponding to the vehicle control field, the execution domain of "turning on the wiper" supports a single-turn dialogue scenario. The hidden domain corresponding to "turning on the wiper" can be directly unregistered in the sandbox domain after the execution of "turning on the wiper".
[0099] In an implementation, as shown in FIG. 12, step S120 can further include: Figure 5
[0100] S501, in the case where the dialogue tag of the previous turn dialogue does not exist in the semantic request information, determining the target scene domain in a plurality of preset scene domains according to the domain information in the semantic request information;
[0101] S502, determining the target execution domain corresponding to the intent information in the semantic request information in a plurality of preset execution domains of the target scene domain.
[0102] It can be understood that the reason why the dialogue tag of the previous turn dialogue does not exist in the semantic request information can be that the current turn dialogue is the first turn dialogue after the dialogue engine is started, and there is no previous turn dialogue. In this case, without considering the dialogue jump situation, the target scene domain and the target execution domain can be directly determined according to the domain information and the intent information in the semantic request information.
[0103] In an implementation, the execution domain of the previous turn dialogue can meet the preset execution completion condition, that is, the hidden domain corresponding to the execution domain of the previous turn dialogue has been unregistered. In this case, the dialogue tag of the previous turn dialogue can still be obtained in the process of generating the semantic request information, but the address information contained in the dialogue tag is empty, and the dialogue engine needs to directly match the intent information in the semantic request information with other hidden domains stored in the sandbox domain.
[0104] Figure 6 An interaction structure diagram of a user and a dialog engine executing an embodiment of the present application is shown.
[0105] As shown in Figure 6 , the user issues a voice request to the dialog engine, and the dialog engine performs noise reduction and suppression, speech recognition, semantic understanding, and other analysis processes on the voice request of the user, and finally generates semantic request information including domain information, intent information, a dialog tag of a previous round of dialog, and a word slot. The word slot can be specifically used for machine understanding of the voice request, facilitating execution of a to-be-executed task in the execution domain. The domain information is used to determine a scenario domain, the intent information is used to determine an execution domain in the scenario domain, and the dialog tag of the previous round of dialog is used to locate a hidden domain storing a context of the previous round of dialog in a sandbox domain. The dialog engine executes a dialog execution method of an embodiment of the present application based on the semantic request information, and feeds back semantic response information to the user.
[0106] Figure 7 And Figure 8 The voice dialog execution method of an embodiment of the present application is further explained by taking a plurality of rounds of dialog between the dialog engine and the user after the dialog engine is started for the first time.
[0107] As shown in Figure 7 :
[0108] 1) After the car machine is powered on, the user wakes up the dialog engine and inputs a voice request "navigate to Renmin Square". The dialog engine generates semantic request information according to the voice request, determines a scenario domain of the current round of dialog as a navigation domain according to domain information in the semantic request information, determines a corresponding execution domain in the scenario domain according to intent information in the semantic request information, registers and creates a hidden domain bound to the execution domain in a sandbox domain, records a context of the current round of dialog, and then executes a to-be-executed task in the execution domain to generate semantic response information "Please confirm the navigation mode (shortest time consuming / least toll / high-speed priority, etc.)", and determines a dialog tag of the current round of dialog based on registration information of the hidden domain in the sandbox domain.
[0109] 2) The user inputs a voice request "shortest time consuming" again. The dialog engine locates the hidden domain of the previous round of dialog in the sandbox domain according to the dialog tag of the previous round of dialog, and determines that the hidden domain matches the previous round of dialog according to the intent information in the semantic request information. Therefore, it can be determined that the current round of dialog continues to be executed by the execution domain of the previous round of dialog, a to-be-executed task in the execution domain is executed to generate semantic response information, and the dialog tag of the current round of dialog is determined based on the registration information of the hidden domain in the sandbox domain (the dialog tag of the current round of dialog is the same as the dialog tag of the previous round of dialog, that is, the dialog tag is unchanged).
[0110] 3.1) The user inputs a voice request "open sunroof", the dialogue engine locates the hidden domain of the last round of dialogue in the sandbox domain according to the dialogue label of the last round of dialogue, and determines that the intent information in the semantic request information does not match the hidden domain of the last round of dialogue according to the intent information in the semantic request information. Since the sandbox domain has not registered and stored other hidden domains after the dialogue engine is started this time, it is determined that the scene domain of the current round of dialogue is the car control domain according to the domain information in the semantic request information, and the corresponding execution domain is further determined in the scene domain according to the intent information in the semantic request information. In addition, the hidden domain bound with the execution domain is registered and created in the sandbox domain, the context of the current round of dialogue is recorded, and then the semantic response information is generated by executing the to-be-executed task in the execution domain, and the dialogue label of the current round of dialogue is determined based on the registration information of the hidden domain in the sandbox domain.
[0111] 3.2) If other hidden domains are registered and stored in the sandbox domain, and the hidden domain containing the intent information is matched, the execution domain of the current round of dialogue is determined according to the matched hidden domain, the semantic response information is generated by executing the to-be-executed task in the execution domain, and the dialogue label of the current round of dialogue is determined based on the registration information of the hidden domain in the sandbox domain.
[0112] Figure 8 For Figure 7 the continuation of the dialogue engine workflow after executing the voice request "open" the sunroof, as shown in Figure 8
[0113] 4) The user inputs a voice request "open the sunroof", since the execution domain corresponding to "open the sunroof" in the last round of dialogue supports the implementation of a single round of dialogue, the hidden domain corresponding to it may have been unregistered in the sandbox domain after the car machine completes the "open the sunroof" action. Therefore, the dialogue label of the last round of dialogue in the semantic request information is empty, and it is necessary to directly match other hidden domains in the sandbox domain. According to the intent information in the semantic request information, it is judged that "open the sunroof" and the hidden domain corresponding to "navigate to the People's Square" are not matched, so it is necessary to determine the scene domain and the execution domain corresponding to "open the sunroof" again. The semantic response information is generated by executing the to-be-executed task in the execution domain, and the dialogue label of the current round of dialogue is determined based on the registration information of the hidden domain in the sandbox domain.
[0114] 5) The user inputs a voice request "play music", the dialogue engine locates the hidden domain of the last round of dialogue in the sandbox domain according to the dialogue label of the last round of dialogue, and determines that the intent information in the semantic request information does not match the hidden domain of the last round of dialogue and the hidden domains stored in the sandbox domain also do not match the intent information according to the intent information in the semantic request information, so the scene domain and the execution domain corresponding to "play music" are re-determined. And since the scene domain corresponding to "play music" is the audio-visual entertainment field, and the execution domain supports the implementation of multi-round dialogue, the scene domain corresponding to "open the window" is the vehicle control field, and the execution domain supports the implementation of multi-round dialogue. Therefore, the current dialogue jumps to a cross-scene multi-round dialogue. If it is judged according to the preset jump rule that the jump strategy is allowed to jump, the current round of dialogue is executed based on the scene domain and the execution domain corresponding to "play music", the to-be-executed task in the execution domain is generated, the semantic response information is generated, and the dialogue label of the current round of dialogue is determined based on the registration information of the hidden domain in the sandbox domain. If it is judged according to the preset jump rule that the jump strategy is prohibited to jump, the execution domain corresponding to the hidden domain determined according to the dialogue label of the last round of dialogue (that is, the execution domain of the last round of dialogue) is determined as the execution domain of the current round of dialogue, the to-be-executed task in the execution domain is executed to generate semantic response information, and the dialogue label of the current round of dialogue is determined based on the registration information of the hidden domain in the sandbox domain.
[0115] The specific settings and implementation manners of the embodiments of the application are described from different angles above. By using the method provided by the above embodiments, the business scene is simplified based on the underlying logic, complex human-computer dialogue can be supported, the efficiency of the dialogue engine processing user voice requests and the flexibility of voice jumping are improved, the threshold for users to use multi-round voice dialogue is reduced, and the interactive function is enriched.
[0116] In the technical solutions of the present disclosure, the acquisition, storage and application of user personal information comply with relevant laws and regulations and do not violate public order and good customs.
[0117] According to the embodiments of the present disclosure, the present disclosure further provides an electronic device and a readable storage medium.
[0118] Figure 9 A structural block diagram of an electronic device according to an embodiment of the present application is shown. As shown in FIG. 1, the electronic device includes a processor 100, a memory 200, a communication interface 300, and a display 400. Figure 9As shown, the device includes a memory 901 and a processor 902, with the memory 901 storing instructions that are executable on the processor 902. The processor 902 implements any of the methods in the above embodiments when executing the instructions. The number of memories 901 and processors 902 can be one or more. The terminal or server is intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The terminal or server can also represent various forms of mobile devices, such as personal digital assistants, cellular telephones, smartphones, wearable devices, and other similar computing devices. The components shown here, their connections and relationships, and their functions, are meant to be examples only, and are not meant to limit the present application described and / or claimed in this document to that which is described here.
[0119] The device can also include a communication interface 903 for communicating with external devices, transmitting and receiving data. The various devices are interconnected, and can be installed on a common motherboard or other installation medium, or can be installed in other ways as needed. The processor 902 can process instructions for execution within the terminal or server, including instructions stored in the memory or on the memory to display graphical information for a GUI on an external input / output device, such as a display device coupled to the interface. In other implementations, multiple processors and / or multiple buses can be employed as needed, as well as multiple memories and memory types. Also, multiple terminals or servers can be connected, with various devices providing portions of the necessary operations (e.g., as a server array, a group of blade servers, or multiple processor systems). The buses can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 9 Only one thick line is used in the figure to represent the buses, but this does not mean that there is only one bus or only one type of bus.
[0120] Optionally, if the memory 901, the processor 902 and the communication interface 903 are integrated on a chip, the memory 901, the processor 902 and the communication interface 903 can communicate with each other through an internal interface.
[0121] It should be appreciated that the above processor can be a central processing unit (CPU), and can also be other general-purpose processors, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc. It is worth noting that the processor can be a processor supporting an advanced RISC machine (ARM) architecture.
[0122] The computer readable storage medium (such as the memory 901 described above) of the embodiments of the present application stores computer instructions, and the program is executed by the processor to implement the method provided in the embodiments of the present application.
[0123] Optionally, the memory 901 can include a program storage area and a data storage area, wherein the program storage area can store an operating system and at least one application required by a function; the data storage area can store data created according to the use of the terminal or server, etc. In addition, the memory 901 can include a high-speed random access memory, and can also include a non-transitory memory, such as at least one magnetic disk storage device, a flash memory device, or other non-transitory solid-state memory device. In some embodiments, the memory 901 can optionally include a memory disposed remotely with respect to the processor 902, and these remote memories can be connected to the terminal or server through a network. Examples of the above network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof.
[0124] In the description of the present specification, the description of the terms "one embodiment", "some embodiments", "an example", "a specific example", or "some examples" and the like means that the specific features, structures, materials or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present application. Moreover, the specific features, structures, materials or characteristics described can be combined in any appropriate manner in any one or more embodiments or examples. In addition, the person skilled in the art can combine and combine the different embodiments or examples described in the present specification and the features of the different embodiments or examples without contradiction.
[0125] In addition, the terms "first", "second", etc. are used herein only to describe different instances, and cannot be construed as indicating or implying relative importance or an indicated number of the technical features. Thus, the features defined with "first", "second", etc. can explicitly or implicitly include at least one of the features. In the description of the present application, the meaning of "plurality" is two or more, unless otherwise specifically limited.
[0126] Any process or method descriptions or descriptions of the flow diagrams described herein can be understood as representing code modules, segments, or portions of code which include one or more executable instructions for performing specific logic functions or steps in the process. And the various embodiments of the application can include additional or fewer steps or processes in addition to or other than those of the specific embodiments described.
[0127] The logic and / or steps represented in the flow diagrams described herein, for example, can be considered as a sequence of executable instructions, which can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor- based system, or other system that can fetch the instructions from a medium and execute the instructions.
[0128] It should be understood that various parts of the present application can be implemented in hardware, software, firmware, or a combination thereof. In the above-described embodiments, a plurality of steps or methods can be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system. All or part of the steps of the above-described embodiment methods can be instructed by a program to complete the relevant hardware, and the program can be stored in a computer-readable storage medium, and when executed, includes one or a combination of steps of the method embodiments.
[0129] In addition, each functional unit in each embodiment of the present application can be integrated in one processing module, or each unit can be physically present separately, or two or more units can be integrated in one module. The above-mentioned integrated module can be realized in the form of hardware or in the form of a software function module. The above-mentioned integrated module, if realized in the form of a software function module and sold or used as an independent product, can also be stored in a computer-readable storage medium. The storage medium can be a read-only memory, a magnetic disk or an optical disk, etc.
[0130] The above merely provides the specific implementation of the present application, but the protection scope of the present application is not limited to this. Any person skilled in the art can easily think of various changes or replacements within the technical range disclosed by the present application, and these should be covered in the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.
Claims
1. A voice dialogue execution method characterized by, The method comprises the following steps: In response to a voice request of a user, semantic request information corresponding to the voice request is generated, and the semantic request information comprises intention information; the generation of the semantic request information corresponding to the voice request comprises: analyzing the voice request to obtain intention information and domain information corresponding to the voice request; A dialogue label of a previous round of dialogue is obtained; The semantic request information is generated based on the intention information, the domain information and the dialogue label of the previous round of dialogue; A target execution domain is determined according to the semantic request information; A dialogue result of a current round of dialogue is generated based on the target execution domain, which comprises: A task to be executed in the target execution domain is executed to generate semantic response information of the current round of dialogue; In a case where a hidden domain corresponding to the target execution domain exists in a sandbox domain, the semantic request information and the semantic response information of the current round of dialogue are recorded in the hidden domain, and a dialogue label of the current round of dialogue is determined based on registration information of the hidden domain in the sandbox domain; The hidden domain is used to carry a dialogue context corresponding to a current semantic input, which comprises semantic request information of a user and corresponding semantic response information; The sandbox domain serves as a super-context container and carries a global dialogue context and stores all registered hidden domains; The dialogue label is generated based on registration information of the hidden domain in the sandbox domain; The target execution domain is a domain finally determined to execute a task to be executed in the current round of dialogue, and the execution domain is generated by logically editing at least one task to be executed; The semantic response information and the dialogue label are taken as the dialogue result of the current round of dialogue.
2. The method of claim 1, wherein, The generation of the dialogue result of the current round of dialogue based on the target execution domain further comprises: The task to be executed in the target execution domain is executed to generate the semantic response information of the current round of dialogue; In a case where the hidden domain corresponding to the target execution domain does not exist in the sandbox domain, a hidden domain corresponding to the target execution domain is created and registered in the sandbox domain, the semantic request information and the semantic response information of the current round of dialogue are recorded in the hidden domain, and a dialogue label of the current round of dialogue is determined based on registration information of the hidden domain in the sandbox domain; The semantic response information and the dialogue label are taken as the dialogue result of the current round of dialogue.
3. The method of claim 1, wherein, The determination of the target execution domain according to the semantic request information comprises: A first hidden domain is determined based on a dialogue label of a previous round of dialogue in the semantic request information; In a case where intention information in the semantic request information matches the first hidden domain, a first execution domain corresponding to the first hidden domain is determined as a target execution domain.
4. The method of claim 3, wherein, Further comprising: In a case where the intention information in the semantic request information does not match the first hidden domain, a second hidden domain matching the intention information is determined; A second execution domain corresponding to the second hidden domain is determined as a target execution domain.
5. The method of claim 4, wherein, Further comprising: In a case where there is no second hidden domain matching the intention information, a target scene domain is determined in a plurality of preset scene domains according to domain information in the semantic request information; The same type of services are aggregated together to form a scene domain, and the scene domain is composed of multiple execution domains and other auxiliary components; determining a third execution domain corresponding to the intent information in multiple preset execution domains of the target scene domain; determining a voice jump strategy based on the first execution domain, the target scene domain, and the third execution domain; in the case that the voice jump strategy is allowed to jump, determining the third execution domain as a target execution domain.
6. The method of claim 5, wherein, Also includes: in the case that the voice jump strategy is prohibited to jump, determining the first execution domain as a target execution domain.
7. The method of claim 1, wherein, The target execution domain is determined according to the semantic request information, and the method further comprises: in the case that there is no dialogue label of the last round of dialogue in the semantic request information, determining a target scene domain in multiple preset scene domains according to domain information in the semantic request information; determining a target execution domain corresponding to intent information in the semantic request information in multiple preset execution domains of the target scene domain.
8. An electronic device comprising: at least one processor; and a memory connected in communication with the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-7.
9. A non-transitory computer readable storage medium having stored thereon computer instructions, wherein, The computer instructions are used to make the computer execute the method according to any one of claims 1-7.
Citation Information
Patent Citations
Speech control method and device
CN106157955A
Conversation content generation method and device, storage medium and terminal
CN115186147A
Voice scene task execution method and device, equipment and storage medium
CN115705842A