Voice interaction method, vehicle, server, and storage medium

Abstract

The application discloses a voice interaction method, comprising: when receiving a wake-up voice request for waking up a vehicle voice function in a vehicle cabin, confirming a wake-up sound area corresponding to the wake-up voice request; in the case that the vehicle voice function is woken up, if a first voice request with a different interaction sound area from the wake-up sound area is received, confirming a rejection mode adopted for the first voice request, and processing the first voice request according to the rejection mode, so as to complete voice interaction. The voice interaction method of the application, for the scene of continuous dialogue in multiple sound areas in the vehicle cabin, in the case that the interaction sound area where the current voice request is generated is different from the wake-up sound area of the voice assistant, needs to confirm what kind of rejection mode is adopted for the voice request first, and then the voice request is processed subsequently, so that the user experience in the corresponding scene is improved.

Description

Technical Field

[0001] This application relates to the field of transportation, and in particular to a voice interaction method, a vehicle, a server, and a computer-readable storage medium. Background Technology

[0002] In-vehicle voice assistants offer numerous conveniences to users in the cabin, allowing them to control software or vehicle components through voice interaction. Since the vehicle interior is a shared environment, once a user activates the voice assistant and initiates a continuous dialogue, conversations may arise between the user and the voice assistant, as well as between users themselves. How to handle these multi-voice requests to enable the voice assistant to better serve users has become a pressing issue. Summary of the Invention

[0003] In view of this, this application provides a voice interaction method, a vehicle, a server, and a computer-readable storage medium.

[0004] This application provides a voice interaction method for a vehicle, including:

[0005] When a wake-up voice request to activate the vehicle's voice function is received in the vehicle's cabin, the wake-up voice zone corresponding to the wake-up voice request is confirmed.

[0006] When the vehicle's voice function is activated, if a first voice request with an interaction voice zone different from the activation voice zone is received, the rejection mode applied to the first voice request is confirmed, and the first voice request is processed according to the rejection mode to complete the voice interaction.

[0007] Therefore, in scenarios involving continuous dialogue across multiple voice zones within a vehicle cabin, the voice interaction method of this application needs to first determine which rejection mode to apply to the voice request when the interactive voice zone generating the voice request differs from the wake-up voice zone of the voice assistant before proceeding with further processing. Different rejection modes may handle the same voice request differently. This allows for the permission to allow voice requests with genuine interaction needs with the voice assistant, while blocking voice requests such as casual conversations between users that do not involve interaction with the voice assistant, thus improving the user experience in the relevant scenarios.

[0008] If a first voice request is received that differs from the wake-up voice region, confirming the rejection mode applied to the first voice request includes:

[0009] Based on the first voice request and the historical dialogue information after the vehicle's voice function is activated, the rejection mode is confirmed for the first voice request.

[0010] In this way, by combining the first voice request with the historical dialogue information after the voice assistant is activated, the rejection mode adopted for the first voice request is confirmed, thereby improving accuracy.

[0011] The step of confirming the rejection mode applied to the first voice request based on the first voice request and the historical dialogue information after the vehicle's voice function is activated includes:

[0012] If the first voice request or the interactive audio area contains a first category of voice request within a predetermined interaction round before the first voice request, the first rejection mode is confirmed to be applied to the first voice request.

[0013] If there are no voice requests of the first category in the first voice request and the interactive audio area within a predetermined number of interaction rounds before the first voice request, it is confirmed that the second rejection mode is adopted for the first voice request. The second rejection mode has a higher rejection level for voice requests than the first rejection mode.

[0014] Therefore, if a voice request of a predetermined category exists within the predetermined interaction rounds including and prior to the first voice request, it can be considered that the probability of the user interacting with the voice assistant is relatively high, and a more lenient rejection mode is adopted for the first voice request. If no voice request of the predetermined category exists within the predetermined interaction rounds including and prior to the first voice request, then a more lenient rejection mode is adopted for the first voice request.

[0015] The step of confirming the rejection mode applied to the first voice request based on the first voice request and the historical dialogue information after the vehicle's voice function is activated includes:

[0016] If the first voice request or the interactive audio area has a first type of voice request within a predetermined time before the first voice request, confirm that the first voice request is subject to the first rejection mode.

[0017] If there is no voice request of the first type in the first voice request or the interactive audio area within a predetermined time before the first voice request, it is confirmed that the second rejection mode is adopted for the first voice request. The second rejection mode has a higher rejection level for the voice request than the first rejection mode.

[0018] Therefore, if there are voice requests of the predetermined category within the time frame including the first voice request and the time frame preceding the first voice request, it can be assumed that the probability of the user interacting with the voice assistant is relatively high, and a more lenient rejection mode is adopted for the current round of voice requests. If there are no voice requests of the predetermined category within the time frame including the first voice request and the time frame preceding the first voice request, then a more lenient rejection mode is adopted for the first voice request.

[0019] The method further includes:

[0020] If a first voice request is received that is the same as the wake-up voice region, the first rejection mode is confirmed to be used for the first voice request.

[0021] Therefore, for the first voice request where the interaction voice area and the wake-up voice area are the same, it can be assumed that the user in that voice area is more likely to continue interacting after waking up the voice assistant, and a rejection mode with a more lenient rejection level can be adopted.

[0022] This application also provides a voice interaction method for a server, wherein the voice interaction method is based on a rejection mode adopted for the first voice request as confirmed by the above-described voice interaction method, characterized in that it includes:

[0023] Receive the first voice request forwarded by the vehicle and the rejection mode adopted for the first voice request;

[0024] The voice interaction is completed by confirming the rejection result of the first voice request based on the first voice request and the rejection mode.

[0025] Thus, in scenarios involving continuous dialogue across multiple audio zones within the vehicle cabin, if the interactive audio zone generating the voice request differs from the voice assistant's wake-up audio zone, it's necessary to first determine which rejection mode to apply to the voice request. The server combines the current voice request (the first voice request) with the previously determined rejection mode to determine the rejection result for the first voice request—that is, whether to allow or reject the voice request—and proceed with subsequent processing to complete the voice interaction. Different rejection modes may handle the same voice request differently. This allows for the allowance of voice requests with genuine interaction needs with the voice assistant while preserving normal user communication within the cabin, and blocks voice requests such as casual conversations between users that do not involve interaction with the voice assistant, thereby improving the user experience in relevant scenarios.

[0026] The step of confirming the rejection result of the first voice request based on the first voice request and the rejection mode includes:

[0027] Confirm the validity classification of the first voice request;

[0028] If the first voice request is a valid voice request, the rejection result of the first voice request is confirmed according to the rejection mode.

[0029] Thus, based on the results of the validity classification of the current voice request, and if the first voice request is a valid voice request, the rejection result of the first voice request is confirmed according to the previously confirmed rejection mode.

[0030] The classification of the validity of the first voice request includes:

[0031] The validity classification of the first voice request is determined based on the semantic validity of the first voice request, the intent of the first voice request, the intent relevance of the first voice request to historical dialogue information, and / or the inheritability of the first voice request to historical dialogue information.

[0032] Thus, the validity classification of voice requests can be comprehensively determined based on the semantic validity of the voice request, the intent of the first voice request, the intent relevance of the first voice request to historical dialogue information, and the inheritability of the first voice request to historical dialogue information, thereby improving the accuracy of validity classification.

[0033] If the first voice request is a valid voice request, confirming the rejection result of the first voice request according to the rejection mode includes:

[0034] If the first voice request is a valid voice request, then confirm that the first voice request is allowed.

[0035] In this way, valid voice requests are further subdivided. If a valid voice request falls into the first category, it can be considered an interaction with the voice assistant, and the request is allowed to proceed with further processing.

[0036] If the first voice request is a valid voice request, confirming the rejection result of the first voice request according to the rejection mode includes:

[0037] If the first voice request is a second valid voice request, and the rejection mode is the first rejection mode, then confirm that the first voice request is allowed.

[0038] If the first voice request is a second valid voice request, and the rejection mode is the second rejection mode, then the rejection of the first voice request is confirmed. The rejection level of the second rejection mode is higher than that of the first rejection mode.

[0039] Thus, if the voice request is a valid voice request of the second category, the rejection result of the first voice request needs to be further confirmed by combining the previously confirmed rejection mode. If it is the first rejection mode, the first voice request will be allowed and subsequent processing will be carried out. If it is the second rejection mode, the first voice request will be rejected and blocked without further processing.

[0040] The step of confirming the rejection result of the first voice request based on the first voice request and the rejection mode includes:

[0041] If the first voice request is invalid, the first voice request is rejected.

[0042] Thus, for invalid voice requests, regardless of the rejection mode used in the initial confirmation, the first voice request will be rejected directly.

[0043] This application also provides a vehicle that includes a memory and a processor. The memory stores a computer program, which, when executed by the processor, implements the above-described voice interaction method.

[0044] Therefore, in this application, for scenarios involving continuous dialogue across multiple audio zones within the vehicle cabin, if the interactive audio zone generating the voice request differs from the voice assistant's wake-up audio zone, it is necessary to first determine which rejection mode to apply to the voice request before proceeding with further processing. Different rejection modes may handle the same voice request differently. This allows for the permission to allow voice requests with genuine interaction needs with the voice assistant, while blocking voice requests such as casual conversations between users that do not involve interaction with the voice assistant, thus improving the user experience in the relevant scenarios.

[0045] This application also provides a server, which includes a memory and a processor. The memory stores a computer program, and when the computer program is executed by the processor, it implements the above-described voice interaction method.

[0046] Therefore, in this application, for scenarios involving continuous dialogue across multiple audio zones within the vehicle cabin, if the interactive audio zone generating the voice request differs from the voice assistant's wake-up audio zone, it is necessary to first determine which rejection mode to apply to the voice request. The server combines the current voice request (the first voice request) with the previously determined rejection mode to determine the rejection result of the first voice request—that is, whether to allow or reject the voice request—and then proceed with subsequent processing to complete the voice interaction. Different rejection modes may handle the rejection or allowance of the same voice request differently. This allows for the allowance of voice requests with genuine interaction needs with the voice assistant while preserving normal communication within the cabin, and blocks voice requests such as chat between users that are not interactions with the voice assistant, thus improving the user experience in the corresponding scenarios.

[0047] This application also provides a computer-readable storage medium storing a computer program that, when executed by one or more processors, implements the above-described voice interaction method.

[0048] Therefore, in this application, for scenarios involving continuous dialogue across multiple audio zones within the vehicle cabin, if the interactive audio zone generating the voice request differs from the voice assistant's wake-up audio zone, it's necessary to first determine which rejection mode to apply to the voice request. The server combines the current voice request (the first voice request) with the previously determined rejection mode to determine the rejection result for the first voice request—that is, whether to allow or reject the voice request—and then proceed with subsequent processing to complete the voice interaction. Different rejection modes may handle the same voice request differently. This allows for the allowance of voice requests with genuine interaction needs with the voice assistant while preserving normal communication within the cabin, and blocks voice requests such as casual conversations between users that do not involve interaction with the voice assistant, thus improving the user experience in the relevant scenarios.

[0049] Additional aspects and advantages of this application 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 this application. Attached Figure Description

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

[0051] Figure 1 This is a flowchart illustrating the interaction method of this application;

[0052] Figure 2 This is a schematic diagram of the rejection mode state switching of the interaction method in this application;

[0053] Figure 3This is a flowchart illustrating the interaction method of this application;

[0054] Figure 4 This is a schematic diagram illustrating the connection state between the computer-readable storage medium and the processor in this application. Detailed Implementation

[0055] The present application is described in detail below, and examples of embodiments 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 following description with reference to the accompanying drawings is exemplary and is only used to explain the present application, and should not be construed as limiting the present application.

[0056] In-vehicle voice assistants offer numerous conveniences to users in the cabin, allowing them to control software or vehicle components through voice interaction. For ease of interaction, voice assistants support continuous dialogue; that is, after a single activation, the user and voice assistant can engage in multi-turn conversations similar to natural language communication until the dialogue ends, without requiring a separate activation for each interaction. However, to ensure vehicle safety, some technologies only grant voice interaction privileges to the driver. This means only the driver can perform voice interactions within the cabin, and other users can only request these functions through the driver. This can potentially distract the driver and compromise driving safety. If permissions are granted to all users in the cabin, allowing all users to converse after the voice assistant is activated, the voice assistant may receive conversations from different users and between different users, as the in-car space is a shared environment. How to accurately process the received voice requests without limiting the interaction environment, and determine which voice requests need to be responded to, in order to better serve the user, will determine the user experience of voice interaction.

[0057] For rejection of voice requests in a single voice region, a semantic-based rejection method is typically employed. This method requires a clear definition of the effective semantic range supported by the rejection. However, if the defined semantic range is too narrow, rejection can easily lead to missed responses to more flexible expressions, meaning that valid voice requests are incorrectly identified as invalid, manifesting as the voice assistant not responding to the user's voice request. If the defined semantic range is too broad, rejection can easily lead to false responses to noise, meaning that invalid voice requests are incorrectly identified as valid, manifesting as the voice assistant interrupting or giving irrelevant responses. In dialogue systems, rejection is primarily used to determine which voice requests are spoken to the voice assistant and which are not, filtering out non-spoken requests as noise to ensure that only valid voice requests from the user are responded to.

[0058] It's understandable that in multi-zone continuous dialogue scenarios—that is, scenarios where, after the voice assistant is activated, users in different locations within the cabin can engage in multiple rounds of dialogue with it—multiple users may interact with each other on the same topic with a high degree of freedom. Some of these interactions may be with the voice assistant, while others may be between users, making it more complex than in a single-zone scenario. Using only semantic rejection-based methods is insufficient to simultaneously meet the requirements of low false negative recall in the currently interacting zone and low false positive recall in the non-interacting zone during multi-zone continuous dialogue.

[0059] Please see Figure 1 This application provides a voice interaction method for vehicles, comprising the following steps:

[0060] 01: When a wake-up voice request to activate the vehicle's voice function is received in the vehicle's cabin, confirm the wake-up voice zone corresponding to the wake-up voice request;

[0061] 02: When the vehicle's voice function is activated, if a first voice request is received that is different from the wake-up voice area, the rejection mode of the first voice request is confirmed, and the first voice request is processed according to the rejection mode to complete the voice interaction.

[0062] This application also provides a vehicle, and the voice interaction method of this application can be implemented by the vehicle. The vehicle includes a memory and a processor. The memory stores a computer program, and the processor is used to, when receiving a wake-up voice request to wake up the vehicle's voice function in the vehicle cabin, identify the wake-up tone zone corresponding to the wake-up voice request, and, when the vehicle's voice function is woken up, if a first voice request is received that differs from the wake-up tone zone, identify the rejection mode adopted for the first voice request, and process the first voice request according to the rejection mode, thereby completing the voice interaction.

[0063] Activating the vehicle's voice function means activating the vehicle's voice assistant. The activation voice request can be set by the manufacturer or a user-defined wake-up word. After the voice assistant is activated, the user in the cabin can engage in multiple rounds of dialogue with it. The dialogue ends when the set threshold of rounds is reached, or when no voice request is received from the user within a predetermined time.

[0064] The cockpit is divided into different sound zones based on the area where users might make sounds. These could include the driver's sound zone, the front passenger's sound zone, the left rear left sound zone, and the right rear right sound zone. Multiple voice pickup devices can be installed in the cockpit to determine the location of the user making the voice request based on the status information of the received voice request.

[0065] The wake-up voice zone is the voice zone where the user making the voice request is located. For example, if the driver wakes up the voice assistant, then the wake-up voice zone is the driver's voice zone.

[0066] The first voice request is a user voice request received by the voice assistant after it is activated. The "first" is only used to distinguish it from the wake-up voice request, and is not a limitation on the number of rounds or the content. In this application, the first voice request has a different voice region than the wake-up voice request; that is, the first voice request is a voice request in a non-wake-up voice region.

[0067] This application does not directly employ a semantic-based rejection scheme, but rather provides multiple rejection modes, each supporting a different semantic range. Upon receiving a voice request from a region different from the wake-up voice region, the first step is to determine which rejection method to use, followed by further processing. Different rejection modes can be flexibly scheduled based on the actual situation of the first voice request, satisfying the need for high recall in the currently interacting voice region and low false recall in the region not in the interacting voice region during multi-region continuous dialogue.

[0068] The method for confirming the rejection mode of the first voice request can be to assign a default rejection mode to the first voice request based on the difference between the voice region of the first voice request and the wake-up voice region, and then further confirm whether the default rejection mode needs to be switched based on the relevant information of the first voice request. Alternatively, the confirmation method can be to directly confirm which rejection mode to use based on the relevant information of the first voice request; this is not limited here.

[0069] In summary, the voice interaction method of this application, in scenarios involving continuous dialogue across multiple voice zones within a vehicle cabin, requires first determining the appropriate rejection mode for the voice request when the interaction voice zone generating the voice request differs from the wake-up voice zone of the voice assistant, before proceeding with further processing. Different rejection modes may handle the same voice request differently. This allows for the permission of voice requests that genuinely require interaction with the voice assistant, while blocking voice requests such as casual conversations between users that do not involve interaction with the voice assistant, thus improving the user experience in the relevant scenarios.

[0070] Step 02 includes:

[0071] 021: Based on the first voice request and the historical dialogue information after the vehicle's voice function is activated, confirm the rejection mode adopted for the first voice request.

[0072] The processor is used to determine the rejection mode adopted for the first voice request based on the first voice request and the historical dialogue information after the vehicle's voice function is activated.

[0073] Understandably, if the first voice request is relatively clear, then the rejection mode applied to the first voice request can be directly confirmed. However, if the first voice request is in a continuous scenario, it may be necessary to combine the previous rounds or even the previous N rounds of voice requests, that is, to rely on the historical dialogue information after the voice assistant is activated, in order to more accurately confirm the rejection mode applied to the first voice request.

[0074] It should be noted that the historical dialogue information is the dialogue information that is traced back to a predetermined number of rounds or a predetermined time from the first voice request, rather than tracing backward from the moment the voice assistant is activated.

[0075] It should also be noted that in a continuous dialogue scenario, the voice state of the wake-up voice request is the active state, the voice state of the voice request in the round following the wake-up round is the first round state, and all voice requests after the first round are in a continuous dialogue state. For voice requests in the first round state, this application does not employ any rejection mode; that is, any voice request in the first round state will be recalled. Therefore, historical dialogue information does not trace the voice request information in the first round state, but only refers to the voice request information in the continuous dialogue state. The first voice request is also assumed to be in a continuous dialogue state, regardless of whether it is in the first round state.

[0076] In this way, by combining the first voice request with the historical dialogue information after the voice assistant is activated, the rejection mode adopted for the first voice request is confirmed, thereby improving accuracy.

[0077] Step 021 includes:

[0078] 0210: If a first type of voice request exists in the first voice request or interactive audio area within a predetermined interaction round before the first voice request, confirm that the first voice request adopts the first rejection mode;

[0079] 0211: If there is no first type of voice request in the first voice request and interactive audio area within the predetermined interaction rounds before the first voice request, confirm that the second rejection mode is adopted for the first voice request.

[0080] The processor is configured to, if a first type of voice request exists in the first voice request or the interactive audio area within a predetermined number of interaction rounds prior to the first voice request, confirm that a first rejection mode is adopted for the first voice request; and if no first type of voice request exists in the first voice request or the interactive audio area within the predetermined number of interaction rounds prior to the first voice request, confirm that a second rejection mode is adopted for the first voice request, wherein the second rejection mode has a higher degree of rejection for the voice request than the first rejection mode.

[0081] In this application, the rejection mode for the first voice request is determined based on the validity of the first voice request and historical dialogue information. Validity is a hierarchical definition of the voice request based on the intensity of intent, and can be divided into valid and invalid. For example, "open the car window" or "car window" are considered valid, while "hahaha" or "what" are considered invalid. The first category of voice requests are valid voice requests.

[0082] It should be noted that the historical dialogue information only refers to the historical dialogue information in the same voice region as the first voice request, and does not refer to the historical dialogue information in other voice regions. That is, it refers to the voice request information in the predetermined interaction rounds before the first voice request in the interactive voice region corresponding to the first voice request.

[0083] In this example, the validity of the current round of voice requests and the voice requests of the predetermined rounds preceding the current round determines whether to apply a first rejection mode or a second rejection mode to the first voice request. The predetermined rounds can be integers greater than or equal to 0, but the value should not be too large; the larger the value, the weaker its reference significance. For example, it could be 2, 3, 5, etc., without limitation. Of course, it can also be 0, meaning that the rejection mode is determined solely based on the current round, i.e., the first voice request.

[0084] In actual processing, if a valid voice request exists in the first voice request and the voice requests in the corresponding pre-defined rounds, the first voice request is confirmed to be subject to a first rejection mode, which is a rejection mode with a relatively lenient rejection level. If no valid voice request exists in the first voice request and the voice requests in the corresponding pre-defined rounds, the first voice request is confirmed to be subject to a second rejection mode, which is a rejection mode with a relatively strict rejection level.

[0085] Therefore, if a voice request of a predetermined category exists within the predetermined interaction rounds including and prior to the first voice request, it can be considered that the probability of the user interacting with the voice assistant is relatively high, and a more lenient rejection mode is adopted for the first voice request. If no voice request of the predetermined category exists within the predetermined interaction rounds including and prior to the first voice request, then a more lenient rejection mode is adopted for the first voice request.

[0086] Step 021 includes:

[0087] 0212: If a first type of voice request exists in the first voice request or interactive audio area within a predetermined time before the first voice request, confirm that the first voice request adopts the first rejection mode;

[0088] 0213: If there is no first-category voice request in the first voice request or interactive audio zone within a predetermined time before the first voice request, confirm that the second rejection mode is adopted for the first voice request.

[0089] The processor is configured to confirm that a first rejection mode is applied to the first voice request if a first type of voice request exists in the first voice request or interactive audio area within a predetermined time before the first voice request, and to confirm that a second rejection mode is applied to the first voice request if no first type of voice request exists in the first voice request or interactive audio area within a predetermined time before the first voice request.

[0090] In this example, the validity of the current round of voice requests and voice requests within a predetermined time period prior to the current round determines whether to apply a first rejection mode or a second rejection mode to the first voice request. The predetermined time period can be an integer greater than or equal to 0, but its value should not be too large; a larger value weakens its reference significance. For example, it could be 5, 10, 20, 30, etc., without limitation. Alternatively, it can be 0, meaning the rejection mode is determined solely based on the current round, i.e., the first voice request.

[0091] In actual processing, if there is a valid voice request among the first voice request and the voice requests in the corresponding audio region within the predetermined time period, the first voice request is confirmed to be subject to the first rejection mode, which is a rejection mode with a relatively lenient rejection level. If there is no valid voice request among the first voice request and the voice requests in the corresponding audio region within the predetermined time period, the first voice request is confirmed to be subject to the second rejection mode, which is a rejection mode with a relatively strict rejection level.

[0092] In practical processing, the number of rounds and time can be combined as a reference. Meeting either condition allows the first voice request to be rejected. Understandably, if only the number of rounds is considered, voice requests from earlier rounds in the same interactive area may be too far removed from the current round, resulting in weak relevance. Similarly, if only time is considered, the interactive area may have a large number of rounds within that time period, leading to weak relevance between earlier rounds and the current round, thus limiting its reference value.

[0093] Please see Figure 2The method for confirming the rejection mode of the first voice request can be based on the difference between the voice region of the first voice request and the wake-up voice region, assigning the first voice request a default rejection mode, namely the second rejection mode. Further, if there is a valid voice request among the voice requests in the first voice request and its corresponding voice region within a predetermined number of rounds, or if there is a valid voice request among the voice requests in the first voice request and its corresponding voice region within a predetermined time period, the second rejection mode is switched back to the first rejection mode. If there is no valid voice request among the voice requests in the first voice request and its corresponding voice region within a predetermined number of rounds, and also no valid voice request among the voice requests in the first voice request and its corresponding voice region within a predetermined time period, the system will switch back to the second rejection mode.

[0094] Therefore, if there are voice requests of the predetermined category within the time frame including the first voice request and the time frame preceding the first voice request, it can be assumed that the probability of the user interacting with the voice assistant is relatively high, and a more lenient rejection mode is adopted for the current round of voice requests. If there are no voice requests of the predetermined category within the time frame including the first voice request and the time frame preceding the first voice request, then a more lenient rejection mode is adopted for the first voice request.

[0095] Interaction methods also include:

[0096] If a first voice request is received that is the same as the wake-up voice zone, the first rejection mode is confirmed for the first voice request.

[0097] The processor is used to confirm that a first rejection mode is adopted for the first voice request when it receives a first voice request that is the same as the interaction voice zone and the wake-up voice zone.

[0098] During processing, if the first voice request received comes from the wake-up voice zone, then the first rejection mode is directly adopted, which is a rejection mode with a relatively lenient rejection level. Furthermore, if the first voice request received comes from the wake-up voice zone, historical dialogue information is no longer considered, and the first rejection mode is always adopted.

[0099] Therefore, for the first voice request where the interaction voice area and the wake-up voice area are the same, it can be assumed that the user in that voice area is more likely to continue interacting after waking up the voice assistant, and a rejection mode with a more lenient rejection level can be adopted.

[0100] Please see Figure 3 This application also provides a voice interaction method for a server, based on the rejection mode adopted for the first voice request confirmed by the above-mentioned voice interaction method for vehicles, the method comprising:

[0101] 03: Receive the first voice request forwarded by the vehicle and the rejection mode adopted for the first voice request;

[0102] 04: Confirm the rejection result of the first voice request based on the first voice request and the rejection mode to complete the voice interaction.

[0103] This application also provides a server, which can implement the voice interaction method of this application. The server includes a memory and a processor. The memory stores a computer program, and the processor is used to receive a first voice request forwarded by a vehicle and a rejection mode applied to the first voice request, and to confirm the rejection result of the first voice request based on the first voice request and the rejection mode, so as to complete the voice interaction.

[0104] The vehicle sends the first voice request and the determined rejection mode for the first voice request to the vehicle's server. The server processes the request further and confirms the rejection result. The rejection result is either to reject or allow the first voice request. If allowed, the server can provide appropriate feedback to the user based on the result of natural language understanding processing; if rejected, no response is given.

[0105] As mentioned earlier, the rejection mode for confirming a voice request primarily relies on the validity of the first voice request and its historical dialogue information in the corresponding audio region. As long as a valid voice request is confirmed, a relatively lenient semantic rejection mode is adopted. However, the server does not directly confirm the rejection result for the first voice request based solely on the allowance range defined by the semantic rejection mode. Instead, it performs further processing to improve the accuracy of the rejection result.

[0106] Thus, in scenarios involving continuous dialogue across multiple audio zones within the vehicle cabin, if the interactive audio zone generating the voice request differs from the voice assistant's wake-up audio zone, it's necessary to first determine which rejection mode to apply to the voice request. The server combines the current voice request (the first voice request) with the previously determined rejection mode to determine the rejection result for the first voice request—that is, whether to allow or reject the voice request—and proceed with subsequent processing to complete the voice interaction. Different rejection modes may handle the same voice request differently. This allows for the allowance of voice requests with genuine interaction needs with the voice assistant while preserving normal user communication within the cabin, and blocks voice requests such as casual conversations between users that do not involve interaction with the voice assistant, thereby improving the user experience in relevant scenarios.

[0107] Step 04 includes:

[0108] 040: Confirm the validity classification of the first voice request;

[0109] 041: If the first voice request is a valid voice request, confirm the rejection result of the first voice request according to the rejection mode.

[0110] The processor is used to determine the validity classification of the first voice request, and to determine the rejection result of the first voice request according to the rejection mode if the first voice request is a valid voice request.

[0111] In actual processing, the server will reclassify the validity of the first voice request. This server-side validity classification will incorporate more factors to confirm the validity of the first voice request; the confirmation method will be detailed below. This reclassification categorizes the validity of voice requests into three types: strongly valid, partially valid, and invalid. Both strongly valid and weakly valid voice requests are valid, but different rejection modes will result in different rejection outcomes for valid voice requests.

[0112] For strong valid voice requests, both rejection modes will allow the request; for weak valid voice requests, the rejection result will differ depending on the rejection mode.

[0113] Thus, based on the results of the validity classification of the current voice request, and if the first voice request is a valid voice request, the rejection result of the first voice request is confirmed according to the previously confirmed rejection mode.

[0114] Step 040 includes:

[0115] 0400: The validity classification of the first voice request is confirmed based on the semantic validity of the first voice request, the intent of the first voice request, the intent relevance of the first voice request to historical dialogue information, and / or the inheritability of the first voice request to historical dialogue information.

[0116] The processor is used to determine the validity classification of the first voice request based on the semantic validity of the first voice request, the intent of the first voice request, the intent relevance of the first voice request to historical dialogue information, and / or the inheritability of the first voice request to historical dialogue information.

[0117] In this application, the semantic validity of the first voice request, whether the first voice request has the intent of a natural voice request, whether the historical dialogue information has the intent of natural voice understanding, whether the intent of the first voice request and the historical information belong to the same domain, whether the intents are the same, whether the first voice request and the historical dialogue information are inheritable, and whether the inheritability occurs in the same voice region, will be comprehensively considered to jointly confirm the validity classification of the first voice request.

[0118] Semantic validity includes strong validity, weak validity, and invalidity. It can be confirmed by combining historical dialogue information within the same interactive voice region. Specifically, if the previous round's semantics were invalid, then semantic validity is confirmed only based on the current round's voice request.

[0119] For example, if the previous voice request was "mmm," which is invalid semantics, and the current voice request is "it's pretty good," which is also invalid semantics, it will ultimately be confirmed as invalid semantics.

[0120] The previous voice request was "Where are you going?", which is invalid semantics. The current voice request is "Going to the restroom", which is weakly valid semantics. It was ultimately confirmed to be weakly valid semantics.

[0121] The previous voice request was "to 4 o'clock," which was invalid semantics. The current voice request is "air conditioner at level 2," which is strongly valid semantics. It was ultimately confirmed as strongly valid semantics.

[0122] If the previous round was a weakly valid semantic and the current round is also a weakly valid semantic, the combination of the two may strengthen it into a strongly valid semantic. If the current round is a strongly valid semantic or an invalid semantic, it will not be strengthened.

[0123] For example, if the current voice request is "air conditioner", it is weakly valid if we only consider this round. However, if the voice request in the previous round in the same vocal range was "turn on", then combined with the previous voice request, it becomes "turn on the air conditioner". In this case, the current round can be strengthened into a strongly valid semantic.

[0124] The previous voice request was "Open," a weakly valid semantic, while the current voice request is "What?", an invalid semantic. It was ultimately confirmed to be invalid semantic.

[0125] The previous voice request was "navigate to," a weakly valid semantic term. The current voice request is "Zhongguancun," also a weakly valid semantic term. Ultimately, it was confirmed as a strongly valid semantic term.

[0126] The previous voice request was "Play a song," a weakly valid semantic expression. The current voice request is "Open the car window," a strongly valid semantic expression. It was ultimately confirmed as a strongly valid semantic expression.

[0127] If the current round has strong semantic validity, then the semantic validity is directly confirmed based on the current round's voice request.

[0128] For example, the previous voice request was "What's the weather like tomorrow?", which is a strongly valid semantic. The current voice request is "Open the trunk", which is also a strongly valid semantic. Ultimately, it was confirmed as a strongly valid semantic.

[0129] If the previous round was strongly valid, then the semantic validity is directly confirmed based on the current round's voice request.

[0130] For example, the previous voice request was "open the car window," which is a strongly valid semantic, while the current voice request is "Friday," which is a weakly valid semantic. Ultimately, it was confirmed as a weakly valid semantic.

[0131] The previous voice request was "Navigate to Guangzhou Tower," a strongly valid semantic term. The current voice request is "Air conditioning," a weakly valid semantic term. It was ultimately confirmed to be a weakly valid semantic term.

[0132] Further combining the domain and intent recognition results of Natural Language Understanding (NLP), the domain is the broad functional classification of the voice request. Intent is the classification result of the voice request within the domain. For example, navigation, music, and air conditioning are all domain types, while "turn on the air conditioner" is an intent within the air conditioning domain. NLP classifies each voice request, but the classification result does not represent semantic validity. For example, a user saying "Go home" is usually classified as the intent for navigation home, which is weakly valid semantics. "Navigate home" is also a navigation intent, but with stronger semantics, making it strongly valid semantics. Intent and semantic validity are combined. If the voice request has an intent recognized by NLP, it is semantically valid and further classified based on other factors. If no corresponding intent exists, it is rejected as an invalid request. Of course, the absence of a corresponding intent usually also indicates invalid semantics.

[0133] Further, considering the inheritability of historical dialogue information, it should be noted that this differs from the aforementioned methods of confirming the existence of a first-category voice request by referring to the same vocal range and confirming semantic validity by referring to the previous round of voice requests in the same vocal range. In considering inheritability, we can simultaneously refer to whether there is inheritability with previous rounds in the current vocal range or previous rounds in other vocal ranges. If inheritability exists, the current round of voice request is rewritten, and its validity classification is finally confirmed based on the rewritten voice request. For example, in a dialogue scenario, after the driver wakes up the voice assistant, there are the following multi-round dialogues:

[0134] Driver: Turn on the air conditioning;

[0135] Passenger: Lower it a little more;

[0136] Driver's seat: Keep the temperature a little lower;

[0137] Passenger: Lower it a little more.

[0138] In this example, the passenger's last "lower" can be inherited from the driver's "lower temperature," and the rewritten voice request becomes "lower temperature." The validity classification of "lower temperature" is then confirmed. It can be understood that the original "lower temperature" was classified as a weakly valid voice request, while the rewritten version is a strongly valid voice request.

[0139] Effective voice requests are typically clear, unambiguous, and use standardized sentence structures that are highly relevant to vehicle functions. Examples include: turn on the air conditioning, straighten the seat back, turn up the instrument panel lights, play a song, open the music interface, and turn up the volume.

[0140] Weak, effective voice requests are typically characterized by unclear intent, potential ambiguity, non-standard sentence structure, and weak relevance to vehicle functions. Examples include: "Will it rain tomorrow?", "Why is the battery dead?", "What song is this?", "Where do I add windshield washer fluid?", "Turn up the volume?", "Air conditioning?", etc.

[0141] Invalid voice requests are usually due to unclear intent, potential ambiguity, casual phrasing, or weak or no relevance to vehicle functions. Examples include: "Whatever," "Our family," "I want to buy this car, can I get a loan?", "Hurry up and get out," "Open the window," "Change gears."

[0142] Thus, the validity classification of voice requests can be comprehensively determined based on the semantic validity of the voice request, the intent of the first voice request, the intent relevance of the first voice request to historical dialogue information, and the inheritability of the first voice request to historical dialogue information, thereby improving the accuracy of validity classification.

[0143] Step 041 includes:

[0144] 0410: If the first voice request is the first valid voice request, confirm that the first voice request is allowed.

[0145] The processor is configured to confirm that the first voice request is allowed if the first voice request is a first valid voice request.

[0146] The first valid voice request is the one that is confirmed as strongly valid in the validity classification. For strongly valid voice requests, regardless of the rejection mode used in the initial confirmation, they are allowed to proceed for further processing, and feedback is given to the user.

[0147] In this way, valid voice requests are further subdivided. If a valid voice request belongs to the first category, it can be considered as an interaction with the voice assistant, and it is allowed to proceed for further processing.

[0148] Step 041 includes:

[0149] 0411: If the first voice request is the second valid voice request, and the rejection mode is the first rejection mode, confirm that the first voice request is allowed;

[0150] 0412: If the first voice request is the second valid voice request, and the rejection mode is the second rejection mode, confirm that the first voice request is rejected. The rejection level of the second rejection mode is higher than that of the first rejection mode.

[0151] The processor is configured to, when the first voice request is a second valid voice request and the rejection mode is a first rejection mode, confirm that the first voice request is allowed, and to, when the first voice request is a second valid voice request and the rejection mode is a second rejection mode, confirm that the first voice request is rejected.

[0152] The second rejection mode rejects voice requests more severely than the first rejection mode. The degree of rejection refers to the range of supported semantics. Different rejection levels result in different rejection outcomes for voice requests of varying validity. Specifically, the first rejection mode only rejects invalid voice requests, while the second rejection mode rejects both weakly valid and invalid voice requests. However, both the first and second rejection modes allow strongly valid voice requests.

[0153] In other words, the first rejection mode allows strongly valid and weakly valid voice requests, while rejecting invalid voice requests, supporting a wider semantic range. The second rejection mode allows strongly valid voice requests, while rejecting weakly valid and invalid voice requests, supporting a narrower semantic range.

[0154] Therefore, when the first voice request is confirmed to be a second valid voice request or a weakly valid voice request, the rejection result should be confirmed by combining the rejection mode. If it is the first rejection mode, the first voice request will be allowed; if it is the second rejection mode, the first voice request will be rejected.

[0155] Thus, if the voice request is a valid voice request of the second category, the rejection result of the first voice request needs to be further confirmed by combining the previously confirmed rejection mode. If it is the first rejection mode, the first voice request will be allowed and subsequent processing will be carried out. If it is the second rejection mode, the first voice request will be rejected and blocked without further processing.

[0156] Step 04 includes:

[0157] 042: If the first voice request is invalid, confirm that the first voice request is rejected.

[0158] The processor is used to confirm that the first voice request is invalid if the first voice request is invalid.

[0159] If the voice request is invalid, the first voice request will be rejected.

[0160] Thus, for invalid voice requests, regardless of the rejection mode used in the initial confirmation, the first voice request will be rejected directly.

[0161] The following specific example will be used to explain this application:

[0162] Scene 1:

[0163]

[0164] After entering continuous dialogue mode, the interactive voice area for "The weather is nice, how about we go hiking?" is in the left rear voice area, which is an invalid voice request category. The confirmation rejection mode is the second rejection mode. After confirmation validity classification, it is still considered an invalid voice request, and the confirmation rejection result is rejection. Similarly, the interactive voice area for "Sure" is in the right rear voice area, which is an invalid voice request category. The confirmation rejection mode is the second rejection mode. After confirmation validity classification, it is still considered an invalid voice request, and the confirmation rejection result is rejection.

[0165] "Okay," the interactive voice area is the driver's voice area, confirming the rejection mode as the first rejection mode, the validity is confirmed as invalid voice request, and the rejection result is rejection.

[0166] "Go to Fragrant Hills," the interactive voice zone is the driver's voice zone, the confirmation rejection mode is the first rejection mode, the validity is confirmed as a weakly valid voice request, and the rejection result is permission granted. The voice assistant can then provide feedback such as "Do you want to navigate to Fragrant Hills?" to interact with the user.

[0167] Please see Figure 4 This application also provides a computer-readable storage medium 100 containing a computer program 101. When the computer program 101 is executed by one or more processors 200, the one or more processors 200 perform the control method of any of the above embodiments.

[0168] This invention also provides a computer-readable storage medium. One or more non-volatile computer-readable storage media storing a computer program, when executed by one or more processors, implement the interactive method of any of the above embodiments. Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related software. The program can be stored in a non-volatile computer-readable storage medium, and when executed, the program can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), etc.

[0169] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with an embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0170] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more steps 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 should be understood by those skilled in the art to which embodiments of this application pertain.

[0171] Although this application has 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 for a vehicle, characterized in that, include: When a wake-up voice request to activate the vehicle's voice function is received in the vehicle's cabin, the wake-up voice zone corresponding to the wake-up voice request is confirmed. When the vehicle voice function is activated, if a first voice request with an interaction voice area different from the activation voice area is received, the rejection mode adopted for the first voice request is confirmed, and the first voice request is processed according to the rejection mode to complete the voice interaction. If a first voice request is received that differs from the wake-up voice region, confirming the rejection mode applied to the first voice request includes: Based on the first voice request and the historical dialogue information after the vehicle's voice function is activated, the rejection mode adopted for the first voice request is confirmed. The step of confirming the rejection mode applied to the first voice request based on the first voice request and the historical dialogue information after the vehicle's voice function is activated includes: If the first voice request or the interactive audio area contains a first category of voice request within a predetermined interaction round before the first voice request, the first rejection mode is confirmed to be applied to the first voice request. If there are no voice requests of the first category in the first voice request and the interactive audio area within a predetermined number of interaction rounds before the first voice request, it is confirmed that the second rejection mode is adopted for the first voice request. The second rejection mode has a higher rejection level for voice requests than the first rejection mode.

2. The method according to claim 1, characterized in that, The step of confirming the rejection mode applied to the first voice request based on the first voice request and the historical dialogue information after the vehicle's voice function is activated includes: If the first voice request or the interactive audio area has a first type of voice request within a predetermined time before the first voice request, confirm that the first voice request is subject to the first rejection mode. If there is no voice request of the first type in the first voice request or the interactive audio area within a predetermined time before the first voice request, it is confirmed that the second rejection mode is adopted for the first voice request. The second rejection mode has a higher rejection level for the voice request than the first rejection mode.

3. The method according to claim 1, characterized in that, The method further includes: If a first voice request is received that is the same as the wake-up voice region, the first rejection mode is confirmed to be used for the first voice request.

4. A voice interaction method for a server, said voice interaction method being based on a rejection mode adopted for the first voice request as confirmed by the voice interaction method according to any one of claims 1-3, characterized in that, include: Receive the first voice request forwarded by the vehicle and the rejection mode adopted for the first voice request; The voice interaction is completed by confirming the rejection result of the first voice request based on the first voice request and the rejection mode.

5. The method according to claim 4, characterized in that, The step of confirming the rejection result of the first voice request based on the first voice request and the rejection mode includes: Confirm the validity classification of the first voice request; If the first voice request is a valid voice request, the rejection result of the first voice request is confirmed according to the rejection mode.

6. The method according to claim 5, characterized in that, The classification of the validity of the first voice request includes: The validity classification of the first voice request is determined based on the semantic validity of the first voice request, the intent of the first voice request, the intent relevance of the first voice request to historical dialogue information, and / or the inheritability of the first voice request to historical dialogue information.

7. The method according to claim 5, characterized in that, If the first voice request is a valid voice request, confirming the rejection result of the first voice request according to the rejection mode includes: If the first voice request is a valid voice request, then confirm that the first voice request is allowed.

8. The method according to claim 7, characterized in that, If the first voice request is a valid voice request, confirming the rejection result of the first voice request according to the rejection mode includes: If the first voice request is a second valid voice request, and the rejection mode is the first rejection mode, then confirm that the first voice request is allowed. If the first voice request is a second valid voice request, and the rejection mode is the second rejection mode, then the rejection of the first voice request is confirmed. The rejection level of the second rejection mode is higher than that of the first rejection mode.

9. The method according to claim 5, characterized in that, The step of confirming the rejection result of the first voice request based on the first voice request and the rejection mode includes: If the first voice request is invalid, the first voice request is rejected.

10. A vehicle, characterized in that, The vehicle includes a memory and a processor, the memory storing a computer program that, when executed by the processor, implements the method according to any one of claims 1-3.

11. A server, characterized in that, The server includes a memory and a processor, the memory storing a computer program that, when executed by the processor, implements the method according to any one of claims 4-9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by one or more processors, implements the method as described in any one of claims 1-9.

Images