Voice arbitration method and device, electronic equipment and vehicle
By building an arbitration decision tree for step by step arbitration, the problem of lack of sequence logic in the existing pronunciation arbitration methods is solved, and a more efficient pronunciation arbitration process and better maintenance are achieved.
Patent Information
- Application Number
- CN202410223725.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-02-28
- Publication Date
- 2025-08-29
AI Technical Summary
The existing pronunciation arbitration methods lack logical judgments, resulting in poor arbitration flexibility and unfavorable maintenance.
By building an arbitration decision tree, arbitration nodes are determined using pre-written script programs to conduct step by step arbitration, including identification, matching, judgment and execution of intent instructions.
The voice arbitration architecture has been optimized, the multi-level judgment logic has been clarified, the arbitration flexibility and maintenance convenience have been improved, and signaling overhead has been reduced.
Smart Images

Figure CN120564705A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of vehicle technology, and in particular to a voice arbitration method, device, electronic equipment, and vehicle. Background Art
[0002] Voice arbitration is a crucial component of the voice chain. Its purpose is to identify, judge, and execute or reject large amounts of conversational information, making decisions based on the foreground application and the current screen usage. However, in practice, each voice message undergoes multiple sentence judgments in the arbitration module. Without a clear precedence logic between these judgments, the arbitration module becomes overwhelmed with judgment statements, resulting in limited flexibility and maintenance issues for voice arbitration. Summary of the Invention
[0003] In view of this, the present application provides a voice arbitration method, device, electronic device and vehicle, which can improve the problems of the current voice arbitration method that has no judgment sequence logic, has poor arbitration flexibility and is not conducive to maintenance.
[0004] In a first aspect, the present application provides a voice arbitration method, comprising:
[0005] Receiving voice interaction information and identifying intended instructions in the voice interaction information;
[0006] Using the intention instruction, a target script corresponding to the intention instruction is matched in a pre-stored script; the script is a pre-written script program, which includes an arbitration node for determining the arbitration type and can determine the corresponding arbitration node according to different intentions; the target script is used to determine the arbitration node required for the intention instruction;
[0007] Based on the arbitration nodes determined by the target scenario, arbitration is performed step by step in a pre-constructed arbitration decision tree to obtain an arbitration result; the decision tree includes n levels, n is greater than or equal to 1, and each level includes a number of arbitration nodes;
[0008] The intention instruction is executed in combination with the arbitration result.
[0009] Optionally, the arbitration nodes determined based on the target script are arbitrated step by step in a pre-constructed arbitration decision tree to obtain an arbitration result, including: obtaining first-level arbitration information; the first-level arbitration information includes the current vehicle scenario mode and the sound source position of the voice interaction information; judging whether the intention instruction is executable under the current scenario mode based on the arbitration decision tree; if the intention instruction is executable, determining the sound source position of the intention instruction; according to the preset control authority of the sound source position, determining at least one vehicle-mounted screen that can be controlled by the sound source position; and determining the execution screen of the intention instruction among the vehicle-mounted screens.
[0010] Optionally, after determining the execution screen of the intention instruction, the method further includes: using the arbitration decision tree to perform secondary arbitration on the intention instruction, querying whether the execution of the intention instruction needs to be based on the vehicle-mounted screen, and obtaining a secondary arbitration result; wherein, the secondary arbitration result includes dependence on the vehicle-mounted screen and non-dependence on the vehicle-mounted screen.
[0011] Optionally, after obtaining the secondary arbitration result, the method further includes: when the secondary arbitration result is dependent on the vehicle-mounted screen, unlocking the execution screen and executing the intention instruction through the execution screen; when the secondary arbitration result is not dependent on the vehicle-mounted screen, executing the intention instruction when the execution screen is not unlocked.
[0012] Optionally, after obtaining the secondary arbitration result, the method further includes: using the arbitration decision tree to perform a third-level arbitration on the intention instruction, searching for the target application in the acquired applications of the execution screen; if the target application is not available in the acquired applications of the execution screen, downloading the target application from the application source of the execution screen; if the target application cannot be found in the application source of the execution screen, using the default application as the target application.
[0013] Optionally, the pre-constructed arbitration decision tree includes three arbitration levels;
[0014] The arbitration nodes determined based on the target script are arbitrated step by step in a pre-constructed arbitration decision tree to obtain an arbitration result, including: using the arbitration decision tree to perform a first-level arbitration on the intention instruction to determine the first-level arbitration result; the first-level arbitration result includes judging whether the intention instruction is executable and determining the execution screen of the intention instruction; if the first-level arbitration result is that the intention instruction is executable, performing a second-level arbitration on the intention instruction to determine the second-level arbitration result; the second-level arbitration result includes determining the dependency of the intention instruction on the vehicle screen; after determining the second-level arbitration result, performing a third-level arbitration on the intention instruction to determine the third-level arbitration result; the third-level arbitration result includes determining the target application for executing the intention instruction.
[0015] In a second aspect, the present application provides a voice arbitration device, comprising:
[0016] a receiving unit configured to receive voice interaction information and identify an intended instruction in the voice interaction information;
[0017] A matching unit is configured to use the intention instruction to match a target script corresponding to the intention instruction in a pre-stored script; the script is a pre-written script program, the script program includes an arbitration node for determining an arbitration type, and can determine the corresponding arbitration node according to different intentions; the target script is used to determine the arbitration node required for the intention instruction;
[0018] An arbitration unit is configured to perform arbitration step by step in a pre-constructed arbitration decision tree based on the arbitration nodes determined by the target scenario to obtain an arbitration result; the decision tree includes n levels, where n is greater than or equal to 1, and each level includes a number of arbitration nodes;
[0019] The execution unit is configured to execute the intended instruction in combination with the arbitration result.
[0020] In a third aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the voice arbitration method described in the first aspect.
[0021] In a fourth aspect, the present application provides an electronic device, comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor implements the voice arbitration method described in the first aspect when executing the computer program.
[0022] In a fifth aspect, the present application provides a vehicle, comprising the voice arbitration device as mentioned in the second aspect or the electronic device as mentioned in the fourth aspect.
[0023] Based on the above technical solution, the present application provides a voice arbitration method, device, electronic device, and vehicle. The method first receives voice interaction information and identifies an intended command. Using the intended command, the method then matches a pre-stored script with a target script corresponding to the intended command. The script is a pre-written script program containing arbitration nodes for determining the arbitration type, which can determine the corresponding arbitration node based on different intents. The target script is used to determine the arbitration node to be executed for the intended command. Based on the arbitration nodes determined by the target script, arbitration is then performed step by step within a pre-constructed arbitration decision tree to obtain an arbitration result. The decision tree comprises n levels, where n is greater than or equal to 1, and each level comprises a number of arbitration nodes. Finally, based on the obtained arbitration result, the intended command is executed. Compared to related technologies, the present application clarifies multi-level judgment logic by setting up an arbitration decision tree. Furthermore, through multiple pre-set scripts, the corresponding arbitration node to be executed can be determined for each intended command. Finally, based on the arbitration node, the required arbitration logic can be found within the arbitration decision tree. This optimizes the existing voice arbitration architecture and arbitration logic, addressing the issues of current voice arbitration methods that lack a sequential judgment logic, resulting in poor arbitration flexibility and inconvenient maintenance.
[0024] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS
[0025] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.
[0026] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.
[0027] Figure 1 A flow chart of a voice arbitration method provided in an embodiment of the present application is shown;
[0028] Figure 2 A processing logic diagram of a voice arbitration method provided in an embodiment of the present application is shown;
[0029] Figure 3 A schematic structural diagram of a voice arbitration device provided in an embodiment of the present application is shown. DETAILED DESCRIPTION
[0030] In order to be able to more clearly understand the above-mentioned purposes, features and advantages of the present application, the scheme of the present application will be further described below. It should be noted that, in the absence of conflict, the embodiments of the present application and the features in the embodiments can be combined with each other. In addition, in order to be able to understand the characteristics and technical content of the embodiments of the present disclosure in more detail, the implementation of the embodiments of the present disclosure is described in detail below in conjunction with the accompanying drawings. The accompanying drawings are for reference only and are not used to limit the embodiments of the present disclosure. In the following technical description, for the sake of convenience of explanation, a full understanding of the disclosed embodiments is provided through a plurality of details. However, in the absence of these details, one or more embodiments can still be implemented. In other cases, to simplify the drawings, well-known structures and devices can be simplified for display.
[0031] The voice arbitration method provided in this embodiment is applied to a voice arbitration device, which can be installed in an ECU (Electronic Control Unit) in a vehicle or integrated into an in-vehicle screen with processing capabilities to execute any of the voice arbitration methods provided in the embodiments of this application.
[0032] Specifically, from the perspective of the modules on the entire voice link, the arbitration module used to arbitrate intention instructions can be located between the dialogue central control module (voice module) and the vertical domain management module. The central control module transmits the session information to the arbitration module. After the arbitration module performs a series of arbitration logic judgments such as mode interception and filtering, the arbitration result is passed back to the central control module. The central control module will perform further processing based on the session information.
[0033] In order to improve the problem that the current voice arbitration method does not have a judgment order logic, has poor arbitration flexibility and is not conducive to maintenance, this embodiment proposes a voice arbitration method. Figure 1 As shown, the method includes:
[0034] S101, receiving voice interaction information and identifying intended instructions in the voice interaction information.
[0035] Voice interaction information can be initiated by the user at any location in the car. These voice interaction information include some execution instructions, such as instructing the vehicle to close the windows, and some inquiry interaction scenarios, such as identifying the user's corresponding intention instructions after multiple inquiries to the vehicle.
[0036] S102, using the intention instruction, matching the target script corresponding to the intention instruction in the pre-stored scripts.
[0037] A pre-written script contains arbitration nodes for determining the arbitration type, allowing for different intents to determine the corresponding arbitration node. The target script determines the arbitration node for the intended instruction. Determining the arbitration node determines the subsequent arbitration type and branch to be taken in the arbitration decision tree. Pre-written scripts are tailored to various scenarios, ensuring that each intent instruction can find a corresponding target script.
[0038] Here is an example:
[0039] "action":"appstore / install",
[0040] "decision":
[0041] {"decisionType":"wiki_common_decision",
[0042] "decisionSecondNodeType":"dependent_driver_screen_end_business",
[0043] "decisionNodeType":"default_system_app"
[0044] "decisions":[
[0045] "mediaPackage":"com.lixiang.appstore"
[0046] "mediaType":"appstore"
[0047] "mediaName":"App Store"
[0048] In the above script, the decisionType arbitration type is the first-level arbitration node, which is divided according to the domain arbitration module and the corresponding arbitration strategy, such as: default_decision default arbitration, default_vehicle_decision default vehicle control arbitration, common_decision common arbitration, etc.
[0049] The decisionSecondNodeType is a secondary arbitration node that determines screen dependencies. For example, dependent_screen depends on the screen, dependent_screen_opened depends on screen opening, and dependent_screen_part_target depends on the screen. Partial target dependency means that for the same action, whether the instruction depends on the screen depends on the target.
[0050] decisionNodeType: The arbitration node type is a third-level arbitration node, which is determined to be the target application or the default application.
[0051] S103, based on the arbitration nodes determined by the target scenario, arbitration is performed step by step in the pre-built arbitration decision tree to obtain an arbitration result.
[0052] The arbitration decision tree consists of n levels, where n is greater than or equal to 1, and each level includes several arbitration nodes. The arbitration decision tree is a logical architecture with a sequential order of judgment. After arbitration of an intent command at each level, the arbitration result for that intent command is obtained. The addition of sequential judgment logic to the arbitration decision tree optimizes the existing voice arbitration architecture and arbitration logic.
[0053] S104: Execute the voice interaction information based on the arbitration result.
[0054] In this embodiment, voice interaction information is first received and an intended instruction is identified. Using the intended instruction, a target script corresponding to the intended instruction is matched against a pre-stored script. Here, a script is a pre-written script program containing arbitration nodes for determining the arbitration type, which can determine the corresponding arbitration node based on different intents. The target script is used to determine the arbitration node required for the intended instruction. Based on the arbitration nodes determined by the target script, arbitration is then performed step by step within a pre-constructed arbitration decision tree to obtain an arbitration result. The decision tree comprises n levels, where n is greater than or equal to 1, and each level includes a number of arbitration nodes. Finally, based on the obtained arbitration result, the intended instruction is executed. Compared to related technologies, this application clarifies multi-level judgment logic by setting up an arbitration decision tree. Furthermore, through multiple pre-set scripts, the corresponding arbitration node required for each intended instruction can be determined. Finally, based on the arbitration node, the required arbitration logic can be found within the arbitration decision tree. This optimizes the existing voice arbitration architecture and arbitration logic, addressing the issues that current voice arbitration methods lack a sequential judgment logic, resulting in poor arbitration flexibility and inconvenient maintenance.
[0055] In some embodiments, whether the intended instruction is executable in the current scenario mode is determined based on the arbitration decision tree; if the intended instruction is executable, the sound source position of the intended instruction is determined; according to the preset control authority of the sound source position, at least one vehicle-mounted screen that can be controlled by the sound source position is determined; among the vehicle-mounted screens, the execution screen of the intended instruction is determined.
[0056] In this embodiment, the purpose of the first-level arbitration includes determining whether the intended instruction is executable and determining the execution screen of the intended instruction. The purpose of the first-level arbitration of the intended instruction is to determine whether the intended instruction can be executed in the current vehicle scenario mode. If the intended instruction is not supported in the current mode, a rejection message and related prompts are directly returned, thereby eliminating the subsequent judgment steps and reducing signaling overhead. At the same time, when the vehicle scenario mode is determined, if the current mode can support the intended instruction, the subsequent judgment process can be further clarified in a specific vehicle scenario mode. For example, if the scenario mode is driving mode, most entertainment instructions can be implemented in this mode. After determining that the vehicle is in driving mode, subsequent judgments can be provided based on the requirements of the driving mode, and voice arbitration judgments for non-driving modes are no longer performed.
[0057] Intended commands can be initiated by the user from anywhere in the vehicle, and can be on one or more of the vehicle's in-car screens. For example, a user in the passenger seat initiates an intent command, which is simultaneously received by the three in-car screens located in the driver's seat, passenger seat, and rear seats. Based on pre-set control permissions, the passenger seat screen has control authority, so the passenger seat screen is selected as the screen to execute the user's intent command. The scenario mode indicates whether the vehicle is currently operating in a special scenario. In these operating modes, some commands may not be executed. The decision on whether a command can be executed is determined by a script and an arbitration decision tree. Special operating modes include nap mode, screen cleaning mode, auto show mode, test drive mode, and some dependent situations, such as the absence of a rear screen, the rear screen being turned off, and unsupported in R gear. There are also special rejection situations, such as when some intent commands cannot be executed due to temporary development or vehicle model differences. For example, voice decision-making is generally not performed in auto show mode.
[0058] In some embodiments, after determining the execution screen of the intention instruction, the method also includes: using the arbitration decision tree to perform secondary arbitration on the intention instruction, querying whether the execution of the intention instruction needs to be based on the vehicle-mounted screen, and obtaining a secondary arbitration result; wherein the secondary arbitration result includes dependence on the vehicle-mounted screen and not dependence on the vehicle-mounted screen.
[0059] Furthermore, after obtaining the secondary arbitration result, the method also includes: when the secondary arbitration result is dependent on the vehicle-mounted screen, unlocking the execution screen and executing the intention instruction through the execution screen; when the secondary arbitration result is not dependent on the vehicle-mounted screen, executing the intention instruction when the execution screen is not unlocked.
[0060] In this embodiment, the main purpose of the secondary arbitration is to determine whether the execution of the intended instruction requires dependence on the screen. For example, watching a movie requires unlocking the screen, while playing music does not require unlocking the screen. At the same time, the execution screen has been determined in the primary arbitration, so the secondary arbitration is to determine whether to unlock the execution screen. For example, the instruction to "play a certain music through application A" or the instruction to communicate via Bluetooth phone does not require unlocking the screen. The primary arbitration determines that the instruction is executable and determines the corresponding execution screen. The secondary arbitration determines whether the instruction requires unlocking the execution screen. It should be noted that unlocking is only for the use of the screen. Other functions can also be realized without unlocking, such as checking the weather.
[0061] In some embodiments, after obtaining the secondary arbitration result, the method also includes: using the arbitration decision tree to perform three-level arbitration on the intent instruction, searching for the target application in the acquired applications of the execution screen; if there is no target application in the acquired applications of the execution screen, downloading the target application from the application source of the execution screen; if the target application cannot be found in the application source of the execution screen, using the default application as the target application.
[0062] For example, when the second-level arbitration result is that the screen needs to be unlocked, that is, the execution of the voice command depends on the screen (the voice command is to play a movie through application A on the co-pilot), a third-level arbitration is performed based on the arbitration decision tree, and application A is searched for in the acquired applications of the execution platform. If it is available, the movie is played using application A; if not, application A is downloaded from the application source of the execution screen (such as an application store or cloud store). If the application source cannot find application A, the movie is played through the default application (such as the player built into the execution platform).
[0063] In this embodiment, the purpose of three-level arbitration is to determine the target application. Specifically, this may include searching for the target application among the acquired applications. If the target application exists, execution is performed using the target application; if not, execution is performed using a cloud-based or default application. Furthermore, it may include determining the target application's current state, whether it is currently playing other content, and whether to switch to another application, thereby increasing arbitration flexibility.
[0064] In some embodiments, a pre-built arbitration decision tree includes three arbitration levels. In this case, based on the arbitration nodes determined by the target scenario, arbitration is performed level by level within the pre-built arbitration decision tree to obtain an arbitration result, including: using the arbitration decision tree to conduct a first-level arbitration on the intent instruction and determine the first-level arbitration result; the first-level arbitration result includes determining whether the intent instruction is executable and determining the execution screen of the intent instruction; if the first-level arbitration result is that the intent instruction is executable, the intent instruction is subjected to a second-level arbitration to determine the second-level arbitration result; the second-level arbitration result includes determining the dependency of the intent instruction on the vehicle screen; after determining the second-level arbitration result, the intent instruction is subjected to a third-level arbitration to determine the third-level arbitration result; the third-level arbitration result includes determining the target application for executing the intent instruction.
[0065] In this embodiment, a voice command from a user is first received and the current vehicle scenario is retrieved. Using a pre-stored script and scenario, the voice command undergoes a first-level arbitration process to determine whether the command is executable. If the command is determined to be executable, the command undergoes a second-level arbitration process to determine a second-level arbitration result, which includes determining the command's dependency on the vehicle's display. After the second-level arbitration result is determined, the command undergoes a third-level arbitration process to determine a third-level arbitration result, which includes determining the target application for executing the command. The command is then executed based on the first, second, and third-level arbitration results. Compared to related technologies, this embodiment abstracts complex, multi-level judgment statements into three levels of arbitration logic, performing comprehensive arbitration based on command supportability, screen dependency, and application feasibility. This optimizes the existing voice arbitration architecture and logic, making them clearer and more concise, eliminating the need for multiple rounds of judgment. This improves existing voice arbitration methods, which suffer from poor arbitration flexibility and poor maintenance.
[0066] In terms of script program implementation, an example of the data structure of an arbitration decision tree is given, such as Figure 2As shown, a binary tree structure is employed, consisting of branch nodes and leaf nodes, and the arbitration decision logic is implemented using XML. Each node is also an arbitration node. A pre-written script (including code) matches the corresponding arbitration node, and arbitration is performed step by step to reach the final arbitration result. Root nodes 2 and 3 and leaf node 1 represent the results of the first-level arbitration. For example, root node 2 represents scenario A, indicating that the instruction is executable; root node 3 represents scenario B, indicating that the instruction is executable; and leaf node 1 represents that the instruction is not supported in the current scenario. Root nodes 4 and 5 and leaf nodes 2 and 3 represent the second-level arbitration results, while leaf nodes 4-7 represent the third-level arbitration results. Each leaf node requires a corresponding script to execute the result. The voice arbitration process traverses the tree from top to bottom, going through three levels of arbitration until a leaf node is found and arbitration is completed. The decision result is contained in the code of each leaf node.
[0067] Faced with an ever-increasing volume of voice commands, the aforementioned strategy structure allows for a more convenient entry into the arbitration world than the previously used, step-by-step approach. Furthermore, from a maintenance perspective, the arbitration world, layered with if-else statements, is like a stacked tower. Through the interplay of factors such as the width and strength of the underlying bricks, the distribution and balance of gravity, and the cohesion between the bricks, it is possible to remove or add one brick at a time without causing the entire structure to collapse. The same applies to arbitration logic, and this structure enables scalability, flexibility, and security.
[0068] Further, as Figure 1 and Figure 2 The specific implementation of the method shown in this embodiment provides a voice arbitration device, such as Figure 3 As shown, the device includes: a receiving unit 301, a matching unit 302, an arbitration unit 303 and an execution unit 304.
[0069] The receiving unit 301 is configured to receive voice interaction information and identify an intended instruction in the voice interaction information;
[0070] The matching unit 302 is configured to use the intention instruction to match a target script corresponding to the intention instruction in a pre-stored script; the script is a pre-written script program, the script program includes an arbitration node for determining an arbitration type, and can determine the corresponding arbitration node according to different intentions; the target script is used to determine the arbitration node required for the intention instruction;
[0071] The arbitration unit 303 is configured to perform arbitration step by step in a pre-built arbitration decision tree based on the arbitration nodes determined by the target scenario to obtain an arbitration result; the decision tree includes n levels, where n is greater than or equal to 1, and each level includes a number of arbitration nodes;
[0072] The execution unit 304 is configured to execute the intended instruction in combination with the arbitration result.
[0073] In a specific application scenario, the arbitration unit 303 is further configured to obtain first-level arbitration information; the first-level arbitration information includes the current vehicle scenario mode and the sound source position of the voice interaction information; based on the arbitration decision tree, it is determined whether the intended instruction is executable in the current scenario mode; if the intended instruction is executable, the sound source position of the intended instruction is determined; according to the preset control authority of the sound source position, at least one vehicle-mounted screen that can be controlled by the sound source position is determined; and among the vehicle-mounted screens, the execution screen of the intended instruction is determined.
[0074] In a specific application scenario, the arbitration unit 303 is further configured to use the arbitration decision tree to perform secondary arbitration on the intention instruction, query whether the execution of the intention instruction needs to be based on the vehicle-mounted screen, and obtain a secondary arbitration result; wherein, the secondary arbitration result includes dependence on the vehicle-mounted screen and non-dependence on the vehicle-mounted screen.
[0075] In a specific application scenario, the arbitration unit 303 is further configured to unlock the execution screen and execute the intended instruction through the execution screen when the secondary arbitration result is dependent on the vehicle-mounted screen; and to execute the intended instruction when the secondary arbitration result is independent of the vehicle-mounted screen and the execution screen is not unlocked.
[0076] In a specific application scenario, the arbitration unit 303 is further configured to perform three-level arbitration on the intention instruction using the arbitration decision tree, and search for the target application in the acquired applications of the execution screen; if the target application is not available in the acquired applications of the execution screen, download the target application from the application source of the execution screen; if the target application cannot be found in the application source of the execution screen, use the default application as the target application.
[0077] In a specific application scenario, the arbitration unit 303 is further configured to use the arbitration decision tree to perform a first-level arbitration on the intended instruction and determine a first-level arbitration result; the first-level arbitration result includes determining whether the intended instruction is executable and determining an execution screen for the intended instruction;
[0078] If the primary arbitration result is that the intention instruction is executable, performing secondary arbitration on the intention instruction to determine the secondary arbitration result; the secondary arbitration result includes determining the dependency relationship between the intention instruction and the vehicle-mounted screen;
[0079] After the secondary arbitration result is determined, a tertiary arbitration is performed on the intention instruction to determine a tertiary arbitration result; the tertiary arbitration result includes determining a target application for executing the intention instruction.
[0080] Based on the above Figure 1 and Figure 2 The method shown in FIG. 1 is a method for performing the above-mentioned steps. Accordingly, this embodiment further provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the computer program can realize the above-mentioned steps. Figure 1 and Figure 2 The method shown.
[0081] Based on this understanding, the technical solution of the present application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, USB flash drive, mobile hard disk, etc.), and includes a number of instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute the methods of various implementation scenarios of the present application.
[0082] Based on the above Figure 1 and Figure 2 The method shown, and Figure 3 In order to achieve the above-mentioned purpose, the embodiment of the present application further provides an electronic device that can be configured on a computer terminal side or a vehicle terminal side, etc. The device includes a storage medium and a processor; the storage medium is used to store a computer program; the processor is used to execute the computer program to achieve the above-mentioned Figure 1 and Figure 2 The method shown.
[0083] Based on the above electronic device, the embodiment of the present application further provides a vehicle, which may specifically include: Figure 3 The device shown or the electronic device as described above. The vehicle can be a new energy vehicle or a traditional vehicle.
[0084] Optionally, the physical device may further include a user interface, a network interface, a camera, a radio frequency (RF) circuit, a sensor, an audio circuit, a Wi-Fi module, etc. The user interface may include a display, an input unit such as a keyboard, etc., and may optionally include a USB interface, a card reader interface, etc. The network interface may optionally include a standard wired interface, a wireless interface (such as a Wi-Fi interface), etc.
[0085] Those skilled in the art will understand that the above-mentioned physical device structure provided in this embodiment does not constitute a limitation on the physical device, and may include more or fewer components, or a combination of certain components, or different component arrangements.
[0086] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages the hardware and software resources of the physical device, supporting the execution of information processing programs and other software and / or programs. The network communication module is used to enable communication between components within the storage medium, as well as with other hardware and software within the physical information processing device.
[0087] Through the description of the above implementation methods, those skilled in the art can clearly understand that the present application can be implemented by means of software plus the necessary general hardware platform, or by hardware. Applying the solution of this embodiment, first receive voice interaction information and identify the intention instruction, use the intention instruction to match the target script corresponding to the intention instruction in the pre-stored script, the script here is a pre-written script program, the script program contains an arbitration node for determining the arbitration type, and can determine the corresponding arbitration node according to different intentions; the target script is used to determine the arbitration node that the intention instruction needs to perform. Then, based on the arbitration node determined by the target script, step-by-step arbitration is performed in the pre-constructed arbitration decision tree to obtain an arbitration result; wherein the decision tree includes n levels, n is greater than or equal to 1, and each level includes a number of arbitration nodes. Finally, based on the obtained arbitration result, the intention instruction is executed. Compared with related technologies, this application clarifies the multi-level judgment logic by setting up an arbitration decision tree, and then through multiple pre-set scripts, it can determine the corresponding arbitration node to be performed for each intention instruction. Finally, based on the arbitration node, the arbitration logic to be performed can be found in the arbitration decision tree, which optimizes the existing voice arbitration architecture and arbitration logic, and improves the current voice arbitration method that does not set the judgment sequence logic, has poor arbitration flexibility and is not conducive to maintenance.
[0088] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the term "comprises" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device that includes a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a..." do not exclude the presence of other identical elements in the process, method, article or device that includes the elements.
[0089] The above description is only a specific embodiment of the present application, which enables those skilled in the art to understand or implement the present application. Various modifications to these embodiments will be obvious to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments described herein, but will conform to the widest scope consistent with the principles and novel features of the present application.
[0090] The above description and accompanying drawings sufficiently illustrate the embodiments of the present disclosure to enable those skilled in the art to practice them. Other embodiments may include structural, logical, electrical, process, and other changes. The embodiments represent only possible variations. Unless expressly required, individual components and functions are optional, and the order of operations may vary. Portions and features of some embodiments may be included in or replaced with portions and features of other embodiments. As used in this application, the term "and / or" means including any and all possible combinations of one or more associated listed items. In addition, when used in this application, the term "comprise" and its variations "comprises" and / or comprising refer to the presence of the stated features, wholes, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components, and / or groups thereof. Without further limitation, an element defined by the phrase "comprises a..." does not exclude the presence of other identical elements in the process, method, or device that includes the element. In this document, each embodiment may focus on the differences from other embodiments, and similar parts between the embodiments can be referenced. For methods, devices, etc. disclosed in the embodiments, if they correspond to the method part disclosed in the embodiments, then the relevant parts can be referenced in the description of the method part.
[0091] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software may depend on the specific application and design constraints of the technical solution. The technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the embodiments of the present disclosure. The technicians will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.
[0092] In the embodiments disclosed herein, the disclosed methods and products (including but not limited to devices, equipment, etc.) can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the units can be merely a logical functional division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between each other shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, and can be electrical, mechanical or other forms. The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the units may be selected to implement this embodiment according to actual needs. In addition, the functional units in the embodiments of the present disclosure may be integrated into a processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
[0093] The flowcharts and block diagrams in the accompanying drawings show the possible implementation architectures, functions and operations of the systems, methods and computer program products according to the embodiments of the present disclosure. In this regard, each box in the flowchart or block diagram can represent a module, program segment or part of the code, and the module, program segment or part of the code contains one or more executable instructions for implementing the specified logical functions. In some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, or they can sometimes be executed in the opposite order, which can depend on the functions involved. In the descriptions corresponding to the flowcharts and block diagrams in the accompanying drawings, the operations or steps corresponding to different boxes can also occur in an order different from that disclosed in the description, and sometimes there is no specific order between different operations or steps. For example, two consecutive operations or steps can actually be executed substantially in parallel, or they can sometimes be executed in the opposite order, which can depend on the functions involved. Each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a dedicated hardware-based system that performs the specified function or action, or may be implemented by a combination of dedicated hardware and computer instructions.
Claims
1. A voice arbitration method, characterized in that: include: Receiving voice interaction information and identifying intended instructions in the voice interaction information; Using the intention instruction, matching a target script corresponding to the intention instruction in a pre-stored script; the script is a pre-written script program, and the script program includes an arbitration node for determining the arbitration type, and can determine the corresponding arbitration node according to different intentions; The target script is used to determine the arbitration node where the intention instruction needs to be performed; Based on the arbitration nodes determined by the target scenario, arbitration is performed step by step in a pre-built arbitration decision tree to obtain an arbitration result; The decision tree includes n levels, where n is greater than or equal to 1, and each level includes a number of arbitration nodes; The intention instruction is executed in combination with the arbitration result.
2. The method according to claim 1, characterized in that The arbitration nodes determined based on the target scenario are arbitrated step by step in a pre-built arbitration decision tree to obtain an arbitration result, including: Obtaining first-level arbitration information; the first-level arbitration information includes the current vehicle scene mode and the sound source location of the voice interaction information; Determine whether the intended instruction is executable in the current scenario mode based on the arbitration decision tree; If the intended instruction is executable, determining a sound source position of the intended instruction; According to the preset control authority of the sound source position, determining at least one vehicle-mounted screen that can be controlled by the sound source position; In the in-vehicle screen, an execution screen for the intended instruction is determined.
3. The method according to claim 2, characterized in that After determining the execution screen of the intended instruction, the method further includes: Performing secondary arbitration on the intention instruction using the arbitration decision tree, querying whether the execution of the intention instruction needs to be based on the vehicle screen, and obtaining a secondary arbitration result; The secondary arbitration results include reliance on the vehicle-mounted screen and non-reliance on the vehicle-mounted screen.
4. The method according to claim 3, characterized in that After obtaining the secondary arbitration result, the method further includes: If the secondary arbitration result is to rely on the vehicle screen, unlock the execution screen and execute the intended instruction through the execution screen; When the secondary arbitration result is not dependent on the vehicle-mounted screen, the intention instruction is executed when the execution screen is not unlocked.
5. The method according to claim 3 or 4, characterized in that After obtaining the secondary arbitration result, the method further includes: Performing three-level arbitration on the intended instruction using the arbitration decision tree, and searching for a target application in the acquired applications on the execution screen; If the target application is not present in the acquired applications on the execution screen, downloading the target application from the application program source on the execution screen; In the case that the target application cannot be found in the application source of the execution screen, a default application is used as the target application.
6. The method according to claim 1, characterized in that The pre-built arbitration decision tree includes three arbitration levels; The arbitration nodes determined based on the target scenario are arbitrated step by step in a pre-built arbitration decision tree to obtain an arbitration result, including: Using the arbitration decision tree, performing a first-level arbitration on the intended instruction and determining a first-level arbitration result; the first-level arbitration result includes determining whether the intended instruction is executable and determining an execution screen for the intended instruction; If the primary arbitration result is that the intention instruction is executable, performing secondary arbitration on the intention instruction to determine the secondary arbitration result; the secondary arbitration result includes determining the dependency relationship between the intention instruction and the vehicle-mounted screen; After the secondary arbitration result is determined, a tertiary arbitration is performed on the intention instruction to determine a tertiary arbitration result; the tertiary arbitration result includes determining a target application for executing the intention instruction.
7. A voice arbitration device, characterized in that: include: a receiving unit configured to receive voice interaction information and identify an intended instruction in the voice interaction information; A matching unit is configured to use the intention instruction to match a target script corresponding to the intention instruction in a pre-stored script; the script is a pre-written script program, the script program includes an arbitration node for determining an arbitration type, and can determine the corresponding arbitration node according to different intentions; The target script is used to determine the arbitration node where the intention instruction needs to be performed; An arbitration unit is configured to perform arbitration step by step in a pre-built arbitration decision tree based on the arbitration nodes determined by the target scenario to obtain an arbitration result; The decision tree includes n levels, where n is greater than or equal to 1, and each level includes a number of arbitration nodes; The execution unit is configured to execute the intended instruction in combination with the arbitration result.
8. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.
9. An electronic device comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein: When the processor executes the computer program, the method according to any one of claims 1 to 6 is implemented.
10. A vehicle, characterized in that: include: The apparatus according to claim 7, or the electronic device according to claim 9.
Citation Information
Patent Citations
Device arbitration for listening devices
CN107004412A
Speech processing method, decision tree model training method and device, equipment, and storage medium
CN113724738A
Voice response system test method and device, electronic equipment and storage medium
CN114528203A
Attribute-based audio channel arbitration
US20150170665A1
Method, apparatus, and computer program products for hierarchical model feature analysis and decision support
US20210133605A1
Cited By
Intelligent terminal interaction method and system based on semantic intention and scene arbitration
CN121277460A