Voice interaction method, server and readable storage medium

Abstract

The application discloses a voice interaction method, a server and a nonvolatile computer readable storage medium containing a computer program. The method comprises the following steps: receiving a current round voice request forwarded by a vehicle; performing slot identification on the current round voice request to obtain a slot identification result; determining target input information according to the current round voice request, the slot identification result, a historical round voice request and a natural language understanding result of the historical round voice request; determining an intent label of the current round voice request according to the target input information; and completing voice interaction according to the intent label. In this way, the target input information is determined in combination with the current round voice request, the slot identification result, the historical round voice request and the understanding result of the historical round voice request, the intent of the target input information is identified, the weak intent voice request of the user is accurately identified, the misunderstanding of the user request is reduced, the probability of an incorrect response is reduced, the experience of the user is improved, and the interaction is more natural and smooth.

Description

Technical Field

[0001] This invention relates to the field of voice interaction technology, and in particular to a voice interaction method, a server, and a non-volatile computer-readable storage medium containing a computer program. Background Technology

[0002] In related technologies, when users make voice requests with weak semantics, such as vague or incomplete expressions, they typically use classification models to identify the intent and then process the voice request. However, this often fails to accurately identify voice requests with weak user intent, resulting in a poor user experience. Summary of the Invention

[0003] The present invention provides a voice interaction method, a server, and a non-volatile computer-readable storage medium containing a computer program.

[0004] This invention provides a voice interaction method, the method comprising:

[0005] Receive the current round's voice request forwarded by the vehicle;

[0006] Slot identification is performed on the current round of voice requests to obtain the slot identification result;

[0007] Based on the current round of voice requests, the slot recognition result, the historical rounds of voice requests, and the natural language understanding result of the historical rounds of voice requests, the target input information is determined;

[0008] Based on the target input information, determine the intent tag of the current round of voice request;

[0009] Complete the voice interaction based on the intent label.

[0010] Thus, this invention provides a voice interaction method. First, it receives a voice request for the current round forwarded by a vehicle. Then, the server performs slot recognition on the current round voice request and obtains the slot recognition result. Next, the server determines the target input information based on the current round voice request, the slot recognition result, historical round voice requests, and the natural language understanding results of historical round voice requests. Then, the server determines the intent tag of the current round voice request based on the target input information. Finally, the server completes the voice interaction based on the intent tag. In this way, by combining the current round voice request, the slot recognition result, historical round voice requests, and their understanding results to determine the target input information and performing intent recognition on this target input information, the method accurately identifies weak intent voice requests from users, reduces misunderstandings of user requests, lowers the probability of erroneous responses, thereby improving the user experience and making the interaction more natural and smooth.

[0011] In some implementations, determining the target input information based on the current round of voice requests, the slot recognition result, historical rounds of voice requests, and the natural language understanding results of the historical rounds of voice requests includes:

[0012] The preset marker, the current round voice request, the slot recognition result, the historical round voice requests, and the natural language understanding result are concatenated to determine the first temporary input information;

[0013] The first temporary input information is subjected to position encoding processing to determine the second temporary input information;

[0014] Based on the round information of the current round of voice request and the round information of the historical rounds of voice request, the third temporary input information is determined;

[0015] The target input information is obtained based on the first temporary input information, the second temporary input information, and the third temporary input information.

[0016] In this way, the server concatenates the preset markers, the current round's voice request, the slot recognition result, the historical round's voice requests, and the natural language understanding result to determine the first temporary input information. Next, the server performs positional encoding on the first temporary input information to determine the second temporary input information. Then, based on the round information of the current round's voice request and the round information of the historical round's voice requests, the server determines the third temporary input information. Finally, the server obtains the target input information based on the first, second, and third temporary input information. This improves the understanding of the dialogue context and enhances the model's understanding of the positional relationships of elements in the input sequence, improving the model's ability to process sequence data and ensuring that the server can accurately capture the user's intent and contextual information, thus guaranteeing the coherence and accuracy of the dialogue.

[0017] In some implementations, completing the voice interaction based on the intent tag includes:

[0018] When the intent label is the first intent label, the application interface parameter filling is performed according to the slot recognition result and the application interface of the historical round voice request, and the execution result is sent to the vehicle to complete the voice interaction.

[0019] Thus, when the intent label is the first intent label, the server, based on the slot recognition result and the application programming interface (API) of the historical voice requests, performs API parameter filling and outputs the execution result to the vehicle to complete the voice interaction. This end-to-end architecture reduces latency in the vehicle system and improves response speed to user commands. Furthermore, by incorporating additional features from the slot recognition result of the user's voice request and the API of the historical voice requests, it can accurately identify the user's intent and required parameters, and call the correct API to execute the corresponding operation, thereby meeting vehicle control needs.

[0020] In some implementations, based on the slot identification result and the application programming interface (API) of the historical round voice request, the API parameter filling is performed, and the execution result is output and sent to the vehicle to complete the voice interaction, including:

[0021] The target parameters for slot filling are determined based on the current round of voice requests, the slot identification results, the application programming interfaces (APIs) of the historical rounds of voice requests, and the API types of the historical rounds of voice requests.

[0022] Based on the slot recognition result and the target parameter, the application interface parameter is filled, and the execution result is sent to the vehicle to complete the voice interaction.

[0023] In this way, the server determines the target parameters for slot filling based on the current round of voice requests, the slot recognition results, the application programming interfaces (APIs) of historical rounds of voice requests, and the API types of historical rounds of voice requests. Next, based on the slot recognition results and target parameters, the server executes the API parameter filling, outputs the execution result, and sends it to the vehicle to complete the voice interaction. This method, by selecting the predicted API based on the slot recognition results and target parameters, executing the API parameter filling, and directly outputting the execution result to the vehicle to complete the voice interaction, reduces the latency of the in-vehicle system and improves the response speed to user commands.

[0024] In some implementations, determining the target parameters for slot filling based on the current round of voice requests, the slot identification result, the application programming interface (API) of the historical rounds of voice requests, and the API type of the historical rounds of voice requests includes:

[0025] The first feature vector is obtained by concatenating the current round voice request and the slot value of the slot recognition result as a text sequence and encoding them.

[0026] The slot type of the slot identification result is mapped to a first identity identifier, and the first identity identifier is converted into a second feature vector;

[0027] Map the application interface type of the historical round voice request to a second identity identifier, and convert the second identity identifier into a third feature vector;

[0028] The parameters of the application interface for the historical rounds of voice requests are mapped to a third identity identifier, and the third identity identifier is converted into a fourth feature vector;

[0029] The first feature vector, the second feature vector, the third feature vector, and the fourth feature vector are processed using a slot filling model to determine the target parameters.

[0030] Thus, the server concatenates the slot values ​​of the current round's voice request and slot recognition result into a text sequence and encodes it to obtain the first feature vector. Next, the server maps the slot type of the slot recognition result to a first identifier and converts the first identifier into a second feature vector. Subsequently, the server maps the application interface type of the historical round's voice request to a second identifier and converts the second identifier into a third feature vector. Then, the server maps the parameters of the application interface of the historical round's voice request to a third identifier and converts the third identifier into a fourth feature vector. Finally, the server uses a slot filling model to process the first, second, third, and fourth feature vectors to determine the target parameters. In this way, by incorporating features such as the slot type, application interface type, and application interface parameters of the user's slot recognition result, the accuracy of the slot filling task can be significantly improved, thereby improving the precision of the application interface parameter filling task.

[0031] In some implementations, completing the voice interaction based on the intent tag includes:

[0032] When the intent label is the second intent label and the current round of voice request is the first round of voice request, the application programming interface (API) prediction is performed on the current round of voice request based on a preset database.

[0033] Based on the slot recognition results and the predicted application interface, the application interface parameters are filled in, and the execution results are sent to the vehicle to complete the voice interaction.

[0034] Thus, when the intent label is the second intent label and the current round of voice request is the first round of voice request, the server predicts the application programming interface (API) for the current round of voice request based on a preset database. Then, based on the slot recognition result and the predicted API, the server performs API parameter filling and outputs the execution result to the vehicle to complete the voice interaction. In this way, by predicting the API based on the preset database, the server can obtain the necessary commands or operations when the intent label is the second intent label, thereby enabling human-computer interaction and providing a convenient and natural user experience.

[0035] In some implementations, completing the voice interaction based on the intent tag includes:

[0036] If the intent tag is the second intent tag and the current round of voice request is not the first round of voice request, the current round of voice request will be rejected.

[0037] Thus, if the intent label is a second intent label and the current round of voice request is not a first-round voice request, the server will reject the current round of voice request. In this way, when the server cannot determine the user's intent, to avoid providing an incorrect response, the server will choose not to process the non-first-round voice request, thereby improving the user experience.

[0038] In some implementations, completing the voice interaction based on the intent tag includes:

[0039] When the intent label is a third intent label, the application programming interface (API) prediction is performed on the current round of voice request;

[0040] Based on the slot recognition results and the predicted application interface, the application interface parameters are filled in, and the execution results are sent to the vehicle to complete the voice interaction.

[0041] Thus, when the intent label is the third intent label, the server predicts the application programming interface (API) for the current round of voice requests. Next, based on the slot recognition result and the predicted API, the server performs API parameter filling and outputs the execution result to the vehicle to complete the voice interaction. This end-to-end architecture reduces latency in the vehicle system and improves response speed to user commands. Furthermore, by incorporating additional features from the slot recognition result and predicted API of the user's voice request, it can accurately identify the user's intent and required parameters, and call the correct API to execute the corresponding operation, thereby meeting vehicle control needs.

[0042] The present invention also provides a server. The server includes a processor and a memory, wherein a computer program is stored in the memory, and when the computer program is executed by the processor, the voice interaction method described in any of the above embodiments is implemented.

[0043] The present invention also provides a non-volatile computer-readable storage medium containing a computer program. When the computer program is executed by one or more processors, it implements the voice interaction method described in any of the above embodiments.

[0044] Additional aspects and advantages of embodiments of the present invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0045] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, wherein:

[0046] Figure 1 This is one of the flowcharts illustrating the voice interaction method according to an embodiment of this application;

[0047] Figure 2 This is a second flowchart illustrating the voice interaction method according to an embodiment of this application;

[0048] Figure 3 This is a flowchart illustrating an example of a voice interaction method according to an embodiment of this application;

[0049] Figure 4 This is the third flowchart illustrating the voice interaction method according to the embodiments of this application;

[0050] Figure 5 This is the fourth flowchart illustrating the voice interaction method according to the embodiments of this application;

[0051] Figure 6 This is the fifth flowchart illustrating the voice interaction method according to the embodiments of this application;

[0052] Figure 7 This is the sixth flowchart illustrating the voice interaction method according to the embodiments of this application;

[0053] Figure 8 This is the seventh flowchart illustrating the voice interaction method according to the embodiments of this application;

[0054] Figure 9 This is the eighth flowchart illustrating the voice interaction method according to the embodiments of this application. Detailed Implementation

[0055] Embodiments of the present invention are described in detail below, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the embodiments of the present invention, and should not be construed as limiting the embodiments of the present invention.

[0056] In related technologies, when a user makes a weak intent voice request, the intent is usually identified through a classification model, and then the voice request is processed.

[0057] Classification models provide a clear decision boundary, enabling the system to accurately determine the strength of intent and respond accordingly. Furthermore, classification models are relatively simple, easy to implement and train, and can quickly classify sentences to determine whether they represent weak intents. In addition, the performance of classification models can be intuitively evaluated using metrics such as precision, recall, and F1 score, facilitating optimization and improvement. Once trained, classification models can be easily extended to new domains or applications; simply retraining or fine-tuning the model is sufficient, demonstrating good scalability.

[0058] However, classification models may face the problem of low classification accuracy, especially when dealing with ambiguous or highly ambiguous sentences. The model may incorrectly classify strong intents as weak intents, or vice versa. Furthermore, classification models may fail to fully utilize contextual information, resulting in an insufficient understanding of the sentence's intent and thus affecting recognition accuracy. In short, in such cases, traditional classification models may not be able to effectively handle weak user intent commands because they rely on explicit, complete instructions to make accurate predictions. This can lead to a poor user experience, as the system fails to understand the user's true intent or executes the user's command incorrectly.

[0059] Weak intent refers to a user's expression of intent that is not clear, complete, or direct enough. Such intent may be difficult for the system to accurately understand and respond to due to vague wording, missing information, or unclear context. For example, a user might say "I'm a little cold" instead of explicitly requesting an adjustment to the air conditioning temperature; or a user might say "Play a certain song" without providing the specific song title.

[0060] Based on the above issues, please refer to Figure 1 This application provides a voice interaction method, the method including:

[0061] 01: Receive the current round's voice request forwarded by the vehicle;

[0062] 02: Perform slot identification on the current round of voice requests and obtain the slot identification results;

[0063] 03: Determine the target input information based on the current round of voice requests, slot recognition results, historical rounds of voice requests, and the natural language understanding results of historical rounds of voice requests;

[0064] 04: Determine the intent label of the current round of voice request based on the target input information;

[0065] 05: Complete voice interaction based on intent tags.

[0066] This invention also provides a server. The server includes a memory and a processor. The voice interaction method of this application can be implemented by the server of this application. Specifically, the memory stores a computer program, and the processor is used to receive the current round voice request forwarded by the vehicle, and to perform slot recognition on the current round voice request to obtain the slot recognition result. It also determines the target input information based on the current round voice request, the slot recognition result, historical round voice requests, and the natural language understanding results of historical round voice requests. The processor is further used to determine the intent label of the current round voice request based on the target input information, and to complete the voice interaction based on the intent label.

[0067] Specifically, the current round of voice request refers to the voice command or request issued by the user in the current interaction round.

[0068] Slot recognition refers to extracting specific information segments from user input, commonly referred to as "slots." Slots typically contain crucial information necessary to complete a task or request, such as time, location, or object. For example, if a user's voice request is "What's the temperature tomorrow?", slot recognition would yield the following slot information: ["tomorrow" - Date]. This means the slot information includes both the slot value and the slot type, where "tomorrow" is the value and the date is the type. Similarly, if a user's voice request is "Navigate to Zhongguancun," slot recognition would yield the following slot information: ["Zhongguancun" - Place]. Here, "Zhongguancun" is the slot value, and the place name is the type.

[0069] Slot recognition results refer to the named entities obtained by slot recognition of voice requests. Examples include the slot information ["tomorrow" - date] and the slot information ["Zhongguancun" - place name].

[0070] Historical voice requests refer to the set of voice commands or requests issued by a user in previous interaction rounds within a dialogue system. It should be noted that this application describes the voice interaction method of this application using the voice request preceding the current voice request as the historical voice request. In some embodiments, historical voice requests can indicate voice requests from more rounds, which is not limited here.

[0071] The natural language understanding results of historical voice requests include the corresponding API calls or operations of the previous voice request, the user's original voice request from the previous round, and the named entities obtained from the user's previous voice request.

[0072] Intent labels refer to the classifications obtained by the label generation model through intent recognition processing of the current round of voice requests, including first intent label, second intent label, and third intent label.

[0073] Generative labeling models are a class of models in machine learning and artificial intelligence that can generate new data instances. These models learn the underlying distribution of data and generate new data accordingly. This means they can generate not only new instances similar to the training data, but also entirely new instances not present in the training data. Generative models can be applied to a variety of tasks, such as image generation, text generation, and audio synthesis.

[0074] The label generation model refers to the generative model obtained by fine-tuning a pre-trained model such as BERT in the embodiments of this application. The BERT training model is a pre-trained language representation model that can understand text simultaneously from left to right and from right to left, thereby capturing deep bidirectional contextual information in the text.

[0075] When a user speaks a sentence, the vehicle's voice recognition system receives the user's voice input, converts it into text information, and then forwards the text information to the server. The voice recognition system is the server mentioned above. For example, if a user says in the vehicle, "Please adjust the air conditioning temperature to 25 degrees," the voice recognition system will convert the voice input into the text: "Please adjust the air conditioning temperature to 25 degrees."

[0076] The server receives the current round of voice requests forwarded by the vehicle, then performs slot identification on the current round of voice requests and obtains the slot identification results. That is, the server analyzes the current round of voice requests and identifies key information. For example, the slot identification results are ["air conditioning" - equipment] and ["25 degrees" - temperature].

[0077] Next, the server determines the target input information based on the current round of voice requests, slot recognition results, historical rounds of voice requests, and the natural language understanding results of those historical rounds. This allows the server to better understand the user's overall intent and context. Then, based on the target input information, the server determines the intent label for the current round of voice requests. Finally, the server completes the voice interaction based on the intent label.

[0078] It should be noted that, in some implementations, the server is deployed in the cloud and communicates with the vehicle via a communication protocol. In other implementations, the server is deployed inside the vehicle.

[0079] In this way, by combining the voice request of the current round, the slot recognition result, the voice requests of the previous rounds and their understanding results, the target input information is determined, and the intent of the target input information is recognized. This accurately identifies the user's weak intent voice request, reduces misunderstanding of the user's request, lowers the probability of erroneous response, thereby improving the user experience and making the interaction more natural and smooth.

[0080] Please see Figure 2 In some implementations, step 03 (determining the target input information based on the current round's voice request, slot recognition results, historical round's voice requests, and the natural language understanding results of historical round's voice requests) includes:

[0081] 031: The preset markers, the current round's voice request, the slot recognition result, the historical round's voice request, and the natural language understanding result are concatenated to determine the first temporary input information;

[0082] 032: Perform position encoding processing on the first temporary input information to determine the second temporary input information;

[0083] 033: Determine the third temporary input information based on the round information of the current round of voice request and the round information of the historical rounds of voice request;

[0084] 034: Based on the first temporary input information, the second temporary input information, and the third temporary input information, the target input information is obtained.

[0085] The processor is also used to concatenate preset markers, the current round of voice requests, slot recognition results, historical rounds of voice requests, and natural language understanding results to determine first temporary input information. It also performs position encoding on the first temporary input information to determine second temporary input information. The processor is further used to determine third temporary input information based on the round information of the current round of voice requests and the round information of historical rounds of voice requests. Finally, it obtains the target input information based on the first, second, and third temporary input information.

[0086] Specifically, preset tokens refer to special tokens or symbols used for specific purposes in model input, including CLS tokens (Class Tokens) and special tokens, etc.

[0087] CLS tags are special tags added to the beginning of each input sequence to aggregate global information about the entire sequence, and are often used in classification tasks.

[0088] The special token is used to record the start and end positions of a slot. For example, if the user's voice command is "open the car window," then the car window is represented by a token. <device> and< / device> Mark it. Among them... <device> Represents the starting point of the device.< / device> This represents the endpoint of the device.

[0089] Position encoding processing refers to the process in the Transformer model where, based on the position of the slot recognition result in the current round of the voice request, the first temporary input information is position-encoded to confirm the second temporary input information. For example, if the voice request is "open the car window," then the slot recognition result "car window" is located between positions 2 and 3 in the voice request "open the car window." Correspondingly, in the second temporary input information, the slot recognition result "car window" must also be located between positions 2 and 3.

[0090] The server concatenates the preset tags, the current round's voice request, the slot recognition result, the previous round's voice request, and the natural language understanding result of the previous round's voice request to form a comprehensive input information, namely the first temporary input information. This helps the server better understand the context of the entire dialogue.

[0091] Next, in order to understand the positional relationships of the elements in the input sequence, the server performs positional encoding on the concatenated first temporary input information to determine the second temporary input information. This helps in understanding the relative or absolute positions of the elements in the sequence.

[0092] Then, the server determines the third temporary input information based on the current round of voice request and the round information of the previous round of voice request, so as to take into account the temporal characteristics of the dialogue.

[0093] Finally, the server combines the first, second, and third temporary input information to generate the target input information. This target input information will be used as the input for intent recognition.

[0094] Please see Figure 3 In one example, the default label is "CLS". <singer> and< / singer>The current round's voice request is "Cao Cao," and the slot recognition result is "[{Singer: Cao Cao, pos: [1,2]}]." The previous round's voice request was "Play Jay Chou," and the natural language understanding result of the previous round's voice request was "[last-api: SingSong], [last-arguments: {singer: Jay Chou, pos: [6,7]}]." The preset token, the current round's voice request, the slot recognition result, the previous round's voice request, and the natural language understanding result of the previous round's voice request are concatenated to obtain the token-embedding, which is the first temporary input signal. Next, the server encodes the token-embedding based on the location of the voice request to obtain the pos-embedding, which is the second temporary input information. Then, the server calculates the wakeup-embedding based on the round information of the current voice request and the previous voice request. In this example, the current voice request is the second round of dialogue, with a round information of 1, and the previous voice request was the first round of dialogue, with a round information of 0. Finally, the server combines the first, second, and third temporary input information to generate the target input information.

[0095] This improves the ability to understand the context of the dialogue and enhances the model's understanding of the positional relationships of elements in the input sequence, thereby improving the model's ability to process sequence data and ensuring that the system can accurately capture the user's intent and contextual information, thus guaranteeing the coherence and accuracy of the dialogue.

[0096] Please see Figure 4 In some implementations, step 05 (completing voice interaction based on intent tags) includes:

[0097] 051: When the intent label is the first intent label, based on the slot recognition result and the application interface of the historical round voice request, execute the application interface parameter filling, output the execution result and send it to the vehicle to complete the voice interaction.

[0098] The processor is also used to perform application interface parameter filling based on the slot recognition result and the application interface of the historical round voice request when the intent label is the first intent label, and output the execution result to the vehicle to complete the voice interaction.

[0099] Specifically, in some implementations, the determination process for the first intent label can be as follows: First, a pre-defined generative model performs intent recognition processing on the data information corresponding to the current round of voice requests in the input target information, determining that the current round of voice requests is a weak intent. Next, intent recognition processing is performed on the data information corresponding to the current round of voice requests, the data information corresponding to the previous round of voice requests, and the natural language understanding results, determining that the current round of voice requests is related to the previous round of voice requests, and that the previous round of voice requests outputs a corresponding application programming interface. This confirms the intent label as the first intent label. Other implementations may have different confirmation processes, which are not limited here.

[0100] For example, if the previous voice request was "I want to listen to 'Rice Fragrance'", and the current voice request is "Cao Cao", then simply having "Cao Cao" alone, which might refer to the historical figure Cao Cao or the Cao Cao from movies and TV shows, wouldn't be enough for the server to identify what information is needed. However, based on the previous voice request, it can be identified that the user is more likely wanting the song "Cao Cao". Thus, the current voice request alone might seem like a weak intent, but because it can be identified by combining it with the previous voice request, it indicates that the intent label for the current voice request is the primary intent label.

[0101] Please refer to the following: Figure 3 The server first performs intent recognition on the user's voice request to determine the user's intent, that is, to determine the intent label of the current voice request. Continuing the example above, after analyzing the generated target input information according to the label generation model, the server will obtain an intent label, which can mark which of the three intent labels—first intent label, second intent label, and third intent label—the current voice request belongs to.

[0102] In this scenario, if the identified intent label is the primary intent label, the system will enter a specific processing flow. Specifically, it uses the slot recognition result of the current round and the voice request information from previous rounds to determine the application programming interface (API) to be called. The slot recognition result provides the location and content of key information in the user request, while the voice requests from previous rounds provide contextual information about the dialogue. Then, the server executes API parameter population based on the slot recognition result and the API of the voice requests from previous rounds. This means the system will use the identified key information to populate the parameters required for the API call. Finally, the server sends the execution result to the vehicle, which then performs the corresponding operation based on these instructions, thus completing the voice interaction.

[0103] Please refer to the following: Figure 3Continuing the example above, the server uses the model to predict "SingSong(singer = Cao Cao)", concluding that the current voice request is more likely to play the song "Cao Cao". Therefore, the final NLU result is "Api-name: SingSong; arguments: {Name: Singer, Type, string, value: Cao Cao]}". The server sends this NLU result to the vehicle, which then performs the corresponding operation based on these instructions, thus completing the voice interaction.

[0104] Thus, adopting an end-to-end architecture can reduce the latency of the in-vehicle system and improve the response speed to user commands. At the same time, by incorporating additional features of the slot recognition results of user voice requests and the application programming interface of historical voice requests, it can accurately identify the user's intent and required parameters, and call the correct application programming interface to perform the corresponding operation, thereby meeting the vehicle control requirements.

[0105] Please see Figure 5 In some implementations, step 051 (based on the slot identification result and the application programming interface (API) of the historical round voice request, performing API parameter filling, and outputting the execution result to the vehicle to complete the voice interaction) includes:

[0106] 0511: Determine the target parameters for slot filling based on the current round of voice requests, slot recognition results, application programming interfaces (APIs) of historical rounds of voice requests, and the API types of historical rounds of voice requests;

[0107] 0512: Based on the slot recognition results and target parameters, perform application interface parameter filling, output the execution results and send them to the vehicle to complete the voice interaction.

[0108] The processor is also used to determine the target parameters for slot filling based on the current round's voice request, slot recognition results, application programming interfaces (APIs) of historical rounds' voice requests, and the API types of historical rounds' voice requests. Based on the slot recognition results and target parameters, it performs API parameter filling and outputs the execution results to the vehicle to complete the voice interaction.

[0109] Specifically, given that the previous round's voice request was "I want to listen to Daoxiang" and the current round's voice request is "Cao Cao", the slot recognition result is: ["Cao Cao" - singer]. The corresponding application programming interface (API) type is "Song Playback (SingSong)". After filling "Cao Cao" from the slot recognition result into the SingSong API, the corresponding song playback operation can be executed, thus completing the voice interaction.

[0110] In this way, based on the results of slot recognition and target parameters, the predicted application interface is selected to perform application interface parameter filling, and the execution result is directly output to the vehicle to complete the voice interaction. This can reduce the latency of the vehicle system and improve the response speed to user commands.

[0111] Please see Figure 6 In some implementations, step 0511 (determining the target parameters for slot filling based on the current round of voice requests, slot identification results, application programming interfaces (APIs) of historical rounds of voice requests, and API types of historical rounds of voice requests) includes:

[0112] 05111: The first feature vector is obtained by concatenating the slot values ​​of the current round's voice request and slot recognition result as a text sequence and encoding them.

[0113] 05112: Map the slot type of the slot identification result to the first identity identifier, and convert the first identity identifier into the second feature vector;

[0114] 05113: Map the application interface type of the voice request in the historical rounds to the second identity identifier, and convert the second identity identifier into the third feature vector;

[0115] 05114: Map the parameters of the application interface for voice requests in historical rounds to a third identity identifier, and convert the third identity identifier into a fourth feature vector;

[0116] 05115: The first, second, third, and fourth eigenvectors are processed using the slot filling model to determine the target parameters.

[0117] The processor is also used to concatenate the slot values ​​of the current round's voice request and slot recognition result into a text sequence for encoding to obtain a first feature vector. It also maps the slot type of the slot recognition result to a first identifier and converts the first identifier into a second feature vector. Furthermore, it maps the application programming interface (API) type of the historical round's voice request to a second identifier and converts the second identifier into a third feature vector. The processor is further used to map the parameters of the API of the historical round's voice request to a third identifier and convert the third identifier into a fourth feature vector. Finally, it processes the first, second, third, and fourth feature vectors using a slot-filling model to determine target parameters.

[0118] Specifically, firstly, the user's input voice request and the slot value of the slot recognition result are concatenated and encoded as a text sequence to obtain the first feature vector "Query[SEP]slot value". For example, slot recognition of the user's voice request "What will the temperature be tomorrow?" can yield the slot recognition result as ["tomorrow" - date (Date)]. That is, the slot recognition result includes the slot value and the slot type, where "tomorrow" is the slot value and the date (Date) is the slot type. In other words, this invention can obtain the first feature vector "[CLS]What will the temperature be tomorrow?[SEP]Tomorrow [SEP]" by concatenating the user's voice request and the slot value using a word embedding matrix.

[0119] Then, a slot type mapping and an API type mapping are constructed. The embedding matrix used in this invention to map slot types and API types is an extra embedding matrix. This invention uses the extra embedding matrix to map the slot type of the slot identification result to a first identity identifier (slot-type), and converts the first identity identifier (slot-type) into a second feature vector; it maps the predicted application interface type to a second identity identifier (api-type), and converts the second identity identifier (api-type) into a third feature vector; it maps the predicted application interface parameters to a third identity identifier (agrument-type), and converts the third identity identifier (agrument-type) into a fourth feature vector. The second, third, and fourth feature vectors are used as extra feature vectors.

[0120] Finally, the first, second, third, and fourth eigenvectors are processed using the slot-filling model to determine the target parameters. The slot-filling model outputs argument filing logits, which can be used to determine the target parameters.

[0121] Thus, by incorporating features such as slot type, application interface type, and application interface parameters from the user slot identification results, the accuracy of slot filling tasks can be significantly improved, thereby enhancing the precision of application interface parameter filling tasks.

[0122] Please see Figure 7 In some implementations, step 05 (completing voice interaction based on intent tags) includes:

[0123] 052: When the intent label is the second intent label and the current round of voice request is the first round of voice request, perform application interface prediction on the current round of voice request based on the preset database;

[0124] 053: Based on the slot recognition results and the predicted application interface, perform application interface parameter filling, output the execution results and send them to the vehicle to complete the voice interaction.

[0125] The processor is also used to predict the application programming interface (API) for the current round of voice requests based on a preset database, when the intent label is the second intent label and the current round of voice requests is the first round of voice requests. Based on the slot recognition results and the predicted API, the processor performs API parameter filling and outputs the execution results to the vehicle to complete the voice interaction.

[0126] Specifically, in some implementations, the determination process for the second intent label can be as follows: First, a preset generative model performs intent recognition processing on the data information corresponding to the current round of voice requests in the input target information, determining that the current round of voice requests is a weak intent. Next, intent recognition processing is performed on the data information corresponding to the current round of voice requests, the data information corresponding to the previous round of voice requests, and the natural language understanding results, determining that the current round of voice requests is not related to the previous round of voice requests, or that the previous round of voice requests did not output a corresponding application programming interface. This confirms the intent label as the second intent label. Other implementations may have different confirmation processes, which are not limited here.

[0127] For example, if the previous voice request was "open the car window," and the current voice request is "Cao Cao," then the server cannot identify the single word "Cao Cao," which could refer to the historical figure Cao Cao or the Cao Cao from movies or TV shows. Furthermore, based on the previous voice request, the server cannot identify the user's intent because the relevance is weak. Alternatively, if the previous voice request was "Cao Cao," and the current voice request is "confession balloon," then the server cannot identify the single word "confession balloon," and it cannot provide any information. Again, the server cannot identify the user's intent based on the previous voice request, and no other application interfaces are invoked. Or, in the current voice interaction cycle, the user has only performed one voice interaction, meaning there are no previous voice requests. And if the current voice request is "Cao Cao," which could refer to the historical figure Cao Cao or the Cao Cao from movies or TV shows, the server cannot identify the information. In such cases, if the current voice request is considered a weak intent, and it cannot be identified in conjunction with the previous voice request, then the intent label of the current voice request is a secondary intent label.

[0128] The pre-set database refers to a database that is pre-configured to respond to user voice requests when the intent label is the second intent label and the current round of voice requests is the first round of voice requests. This database is used to improve user experience. The server may need to respond to user voice requests, but the user's voice requests are not specific.

[0129] When the intent label is the second intent label and the current round of voice request is the first round of voice request, the server performs application programming interface (API) prediction for the current round of voice request based on a preset database. By predicting the API, the server can prepare commands or operations that may need to be executed in advance, thereby improving response speed and interaction efficiency.

[0130] Next, based on the slot identification results and the predicted application interface (API), the server performs API parameter population. By populating the parameters required by the API, the server ensures that it can accurately execute the user's requested operation.

[0131] Finally, the server outputs the execution results to the vehicle, which then performs the corresponding operations based on these instructions, such as adjusting the air conditioning temperature or navigating to a designated location.

[0132] In this way, based on the preset database, the application interface is predicted, and the server can obtain the command or operation to be executed when the intent label is the second intent label, thereby enabling human-computer interaction and providing a convenient and natural user experience.

[0133] Please see Figure 8 In some implementations, step 05 (completing voice interaction based on intent tags) includes:

[0134] 054: If the intent label is the second intent label and the current round of voice request is not the first round of voice request, the current round of voice request will be rejected.

[0135] The processor is also used to reject the current round of voice request when the intent label is the second intent label and the current round of voice request is not the first round of voice request.

[0136] Specifically, in some cases, non-first-round voice requests may heavily rely on previous conversational context. If the server fails to understand or loses this contextual information, it may misunderstand the user's intent. To avoid this, when the intent label is a second intent label and the current round of voice requests is a non-first-round request, the server may be designed not to provide a response. This is because in some cases, providing an incorrect response may be worse than not providing a response if the server cannot determine the user's intent; denial handling can prevent confusion or discomfort for the user.

[0137] Thus, when the server cannot determine the user's intent, it will choose not to process the non-first-round voice request to avoid providing an incorrect response, thereby improving the user experience.

[0138] Please see Figure 9 In some implementations, step 05 (completing voice interaction based on intent tags) includes:

[0139] 055: When the intent label is the third intent label, perform application interface prediction for the current round of voice request;

[0140] 056: Based on the slot recognition results and the predicted application interface, perform application interface parameter filling, output the execution results and send them to the vehicle to complete the voice interaction.

[0141] The processor is also used to predict the application programming interface (API) for the current round of voice requests when the intent label is a third intent label. Based on the slot recognition result and the predicted API, it performs API parameter filling and outputs the execution result to the vehicle to complete the voice interaction.

[0142] Specifically, in some implementations, the determination process for the third intent label can be as follows: a preset generative model first performs intent recognition processing on the data information in the input target information that corresponds to the current round of voice request, and determines that the current round of voice request is a strong intent. In other implementations, there may be other confirmation processes, which are not limited here.

[0143] First, the server receives user voice requests forwarded by vehicles and performs slot recognition on the user voice requests. For example, if the current user's voice request is "What will the temperature be tomorrow?", the server can receive the user voice request forwarded by the vehicle as "What will the temperature be tomorrow?".

[0144] Then, slot recognition is performed on the user's voice request "What will the temperature be tomorrow?" to obtain the slot recognition results. The slot recognition results include information on entities such as weather and location covering all vertical domains in the user's voice request.

[0145] Taking the result of slot recognition as weather entity information as an example, for instance, recognizing a user's voice request "What will the temperature be tomorrow?" yields slot information including ["tomorrow" - date (Date)]. That is, slot information includes the slot value and slot type, where "tomorrow" is the slot value and "Date" is the slot type. Understandably, user voice requests often contain a wealth of information, which can supplement application interface (API) types and slot information. Slot type is also crucial for parameter filling, as slot types and API parameters often have a fixed mapping relationship. For example, a "Date" slot type is highly likely to fill time or date parameters in certain APIs, while for other types of parameters, such as "temperature," the probability of filling that parameter is very small. Therefore, slot type often exists as a strong feature, significantly affecting the accuracy of API parameter filling tasks. In other words, the voice interaction method of this invention incorporates additional features from the current user's voice input and the slot type recognized by slot recognition, effectively improving the accuracy of API parameter filling tasks.

[0146] Taking the location entity information as the result of slot recognition as an example, the slot information obtained by recognizing the user's voice request "Navigate to Zhongguancun" is ["Zhongguancun" - Place Name (Place)], where "Zhongguancun" is the slot value and Place Name (Place) is the slot type.

[0147] In other words, the architecture adopted in this invention is an end-to-end architecture that does not distinguish between vertical domains and does not require training models within each vertical domain, thereby reducing the large amount of manpower and data costs required for separate design of each vertical domain.

[0148] Next, application programming interface (API) prediction is performed on the user's voice request. For example, the API prediction for the user's voice request "What will the temperature be tomorrow?" is API A for temperature query. The API prediction for the user's voice request "Navigate to Zhongguancun" is API B for navigation.

[0149] Finally, based on the slot recognition results and the predicted application interface, the predicted application interface is selected to perform application interface parameter filling, and the execution result is output and sent to the vehicle to complete the voice interaction.

[0150] Thus, adopting an end-to-end architecture can reduce the latency of the in-vehicle system and improve the response speed to user commands. At the same time, by incorporating the slot recognition results of user voice requests and the additional features of predicted application programming interfaces (APIs), it can accurately identify the user's intent and required parameters, and call the correct APIs to perform the corresponding operations, thereby meeting the vehicle control requirements.

[0151] This application also provides a non-volatile computer-readable storage medium containing a computer program. When the computer program is executed by one or more processors, it causes the one or more processors to perform the method of this application.

[0152] It is understood that a computer program includes computer program code. Computer program code can be in the form of source code, object code, executable files, or some intermediate form. Computer-readable storage media can include: any entity or device capable of carrying computer program code, recording media, USB flash drives, external hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), and software distribution media, etc.

[0153] In the description of this specification, the terms "specifically," "furthermore," "particularly," "understandably," etc., refer to specific features, structures, materials, or characteristics described in connection with embodiments or examples that are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms are not intended to be considered as identical embodiments or examples. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0154] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the function involved, as will be understood by those skilled in the art to which embodiments of this application pertain.

[0155] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A voice interaction method, characterized in that, The method includes: Receive the current round's voice request forwarded by the vehicle; Slot identification is performed on the current round of voice requests to obtain the slot identification result; The preset marker, the current round voice request, the slot recognition result, the historical round voice requests, and the natural language understanding result of the historical round voice requests are concatenated to determine the first temporary input information; The first temporary input information is subjected to position encoding processing to determine the second temporary input information; Based on the round information of the current round of voice request and the round information of the historical rounds of voice request, the third temporary input information is determined; The target input information is obtained based on the first temporary input information, the second temporary input information, and the third temporary input information; Based on the target input information, determine the intent tag of the current round of voice request; Complete the voice interaction based on the intent label.

2. The method according to claim 1, characterized in that, The step of completing voice interaction based on the intent tag includes: The preset generative model performs intent recognition processing on the data information corresponding to the current round of voice request in the input target information, and determines that the current round of voice request is a weak intent; When the current round of voice request is a weak intent, intent recognition processing is performed on the data information corresponding to the current round of voice request, the data information corresponding to the previous round of voice request, and the natural language understanding result. It is determined that the current round of voice request is related to the previous round of voice request, and the previous round of voice request outputs the corresponding application programming interface. The intent tag is confirmed as the first intent tag. When the intent label is the first intent label, the application interface parameter filling is performed according to the slot recognition result and the application interface of the historical round voice request, and the execution result is sent to the vehicle to complete the voice interaction.

3. The method according to claim 2, characterized in that, The process of filling application interface parameters and outputting the execution result to the vehicle to complete the voice interaction, based on the slot recognition result and the historical round voice request, includes: The target parameters for slot filling are determined based on the current round of voice requests, the slot identification results, the application programming interfaces (APIs) of the historical rounds of voice requests, and the API types of the historical rounds of voice requests. Based on the slot recognition result and the target parameter, the application interface parameter is filled, and the execution result is sent to the vehicle to complete the voice interaction.

4. The method according to claim 3, characterized in that, The step of determining the target parameters for slot filling based on the current round of voice requests, the slot identification result, the application programming interface (API) of the historical rounds of voice requests, and the API type of the historical rounds of voice requests includes: The first feature vector is obtained by concatenating the current round voice request and the slot value of the slot recognition result as a text sequence and encoding them. The slot type of the slot identification result is mapped to a first identity identifier, and the first identity identifier is converted into a second feature vector; Map the application interface type of the historical round voice request to a second identity identifier, and convert the second identity identifier into a third feature vector; The parameters of the application interface for the historical rounds of voice requests are mapped to a third identity identifier, and the third identity identifier is converted into a fourth feature vector; The first feature vector, the second feature vector, the third feature vector, and the fourth feature vector are processed using a slot filling model to determine the target parameters.

5. The method according to claim 1, characterized in that, The step of completing voice interaction based on the intent tag includes: The pre-defined generative model first performs intent recognition processing on the data information in the input target information that corresponds to the current round of voice request, and determines that the current round of voice request is a weak intent; When the current round of voice request is a weak intent, intent recognition processing is performed on the data information corresponding to the current round of voice request, the data information corresponding to the previous round of voice request, and the natural language understanding result. It is determined that the current round of voice request is not related to the previous round of voice request, or that the previous round of voice request did not output the corresponding application interface, and the intent tag is confirmed as the second intent tag. When the intent label is the second intent label and the current round of voice request is the first round of voice request, the application programming interface (API) prediction is performed on the current round of voice request based on a preset database. Based on the slot recognition results and the predicted application interface, the application interface parameters are filled in, and the execution results are sent to the vehicle to complete the voice interaction.

6. The method according to claim 5, characterized in that, The step of completing voice interaction based on the intent tag includes: If the intent tag is the second intent tag and the current round of voice request is not the first round of voice request, the current round of voice request will be rejected.

7. The method according to claim 1, characterized in that, The step of completing voice interaction based on the intent tag includes: The preset generative model performs intent recognition processing on the data information corresponding to the current round of voice request in the input target information, and determines that the current round of voice request is a strong intent; If the current round of voice request is a strong intent, the intent tag is determined to be a third intent tag; When the intent label is a third intent label, the application programming interface (API) prediction is performed on the current round of voice request; Based on the slot recognition results and the predicted application interface, the application interface parameters are filled in, and the execution results are sent to the vehicle to complete the voice interaction.

8. A server, characterized in that, The server includes a processor and a memory, the memory storing a computer program that, when executed by the processor, implements the voice interaction method according to any one of claims 1-7.

9. A non-volatile computer-readable storage medium containing a computer program, characterized in that, When the computer program is executed by one or more processors, it implements the voice interaction method according to any one of claims 1-7.

Images