Voice interaction method and device, readable storage medium and electronic equipment
By recognizing user intent through a voice interaction model and flexibly configuring tool behavior parameters, the problem of waiting delays in the voice interaction process is solved, natural language voice feedback is achieved, and the smoothness and adaptability of the interaction are improved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-04-16
- Publication Date
- 2026-06-26
AI Technical Summary
The waiting delay and interaction stutter caused by tool calls during voice interaction, especially when performing time-consuming tasks, result in users experiencing a noticeable waiting delay and an unsmooth interaction experience.
By recognizing user intent through a voice interaction model, flexibly configuring the tool's behavior parameters, executing tasks in an asynchronous non-blocking or synchronous blocking manner, and determining the timing of feedback information based on the behavior parameters, natural language voice feedback is achieved.
It reduces waiting delays during voice interaction, improves the smoothness of interaction, simulates the natural interaction experience of "speaking and doing at the same time," and enhances the adaptability and fluency of voice interaction.
Smart Images

Figure CN122290591A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to voice interaction technology, and in particular to a voice interaction method, apparatus, readable storage medium, and electronic device. Background Technology
[0002] With the development of artificial intelligence technology, voice assistants have become an important interaction method for various systems. When users interact with voice assistants, they need to invoke various tools (such as navigation tools, device control tools, information query tools, etc.). When executing these tool invocations, the voice assistant typically needs to wait for the tool to complete before outputting voice feedback based on the execution result. When the tool execution time is too long, it can cause interaction stuttering. Therefore, how to shorten the waiting delay for invoking tools during voice interaction and improve the smoothness of the interaction is an urgent problem to be solved. Summary of the Invention
[0003] To address the aforementioned technical problems, this disclosure provides a voice interaction method, apparatus, readable storage medium, and electronic device to resolve the issues of large waiting delays and frequent stuttering when calling tools during voice interaction.
[0004] A first aspect of this disclosure provides a voice interaction method, comprising: recognizing an input user voice signal using a voice interaction model to obtain user intent information; determining a tool to be invoked based on the user intent information; acquiring behavioral parameters of the tool and controlling the tool to execute a task corresponding to the user intent information based on the behavioral parameters, wherein the behavioral parameters are used to instruct the tool to execute the task in a synchronous blocking mode or an asynchronous non-blocking mode; determining the timing for the voice interaction model to generate feedback information based on the behavioral parameters; and generating feedback information for providing feedback to the user in response to the current timing for generating feedback information.
[0005] A second aspect of this disclosure provides a voice interaction device, comprising: a recognition module, configured to recognize an input user voice signal using a voice interaction model to obtain user intent information; a first determination module, configured to determine a tool to be invoked based on the user intent information; an execution module, configured to acquire behavioral parameters of the tool and control the tool to execute a task corresponding to the user intent information based on the behavioral parameters, wherein the behavioral parameters are used to instruct the tool to execute the task in a synchronous blocking mode or an asynchronous non-blocking mode; a second determination module, configured to determine the timing for the voice interaction model to generate feedback information based on the behavioral parameters; and a generation module, configured to generate feedback information for feedback to be given to the user in response to the current timing for generating feedback information.
[0006] A third aspect of this disclosure is to provide a computer-readable storage medium storing a computer program that, when executed, implements the above-described voice interaction method.
[0007] A fourth aspect of this disclosure provides an electronic device comprising: a processor; a memory for storing processor-executable instructions; and a processor for reading executable instructions from the memory and executing the instructions to implement the aforementioned voice interaction method.
[0008] A fifth aspect of this disclosure provides a computer program product including computer program instructions that, when executed by an instruction processor, perform the aforementioned voice interaction method.
[0009] Based on the voice interaction method, apparatus, readable storage medium, and electronic device provided in this disclosure, a voice interaction model is used to recognize the input user voice signal to obtain user intent information; based on the user intent information, the tool to be invoked is determined; the behavior parameters of the tool are obtained, and the tool is controlled to execute the task corresponding to the user intent information based on the behavior parameters; based on the behavior parameters, the timing for the voice interaction model to generate feedback information is determined; in response to the current timing that meets the requirements for generating feedback information, feedback information for feedback to be given to the user is generated. This enables flexible configuration of behavior parameters for the tools to be invoked during the voice interaction process. According to the behavior parameters, the tool can be flexibly controlled to execute tasks in an asynchronous non-blocking or synchronous blocking manner, so that the way the tool executes tasks can be more matched with the actual scenario, which helps to reduce the waiting delay during the voice interaction process and improve the fluency of the voice interaction. Attached Figure Description
[0010] Figure 1 This is a flowchart illustrating a voice interaction method provided in an exemplary embodiment of this disclosure; Figure 2 This is a flowchart illustrating a voice interaction method provided in another exemplary embodiment of this disclosure; Figure 3 This is a flowchart illustrating a voice interaction method provided in yet another exemplary embodiment of this disclosure; Figure 4 This is a flowchart illustrating a voice interaction method provided in yet another exemplary embodiment of this disclosure; Figure 5 This is a structural diagram of a voice interaction device provided in an exemplary embodiment of the present disclosure; Figure 6 This is a structural diagram of a voice interaction device provided in another exemplary embodiment of this disclosure; Figure 7 This is a structural diagram of an electronic device provided in an exemplary embodiment of this disclosure. Detailed Implementation
[0011] To explain this disclosure, exemplary embodiments of the disclosure will now be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the disclosure, and not all of them. It should be understood that the disclosure is not limited to exemplary embodiments.
[0012] It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values of the components and steps set forth in these embodiments do not limit the scope of this disclosure.
[0013] Application Overview When in-vehicle voice assistants execute tool calls (such as setting navigation, adjusting air conditioning, or querying information), they need to wait for the tool to complete its task before providing voice feedback. When tool execution takes a long time (e.g., route planning takes 2-3 seconds, geocoding takes 1-2 seconds), users will experience noticeable delays, stuttering, and unsmooth interactions. The sequential process of "receiving instructions → executing tools → reporting results" fails to achieve a natural "speak and do" interactive experience. When multiple tool calls need to be executed (e.g., geocoding followed by route planning), the sequential execution leads to an accumulation of total delays, resulting in excessively long waiting times for users.
[0014] The embodiments disclosed herein aim to solve the above-mentioned problems and provide a voice interaction method that can flexibly configure the behavior parameters of the tools to be called during the voice interaction process. Based on the behavior parameters, the tools can be flexibly controlled to execute tasks in an asynchronous non-blocking or synchronous blocking manner, so that the way the tools execute tasks can be more matched with the actual scenario, which helps to reduce the waiting delay during the voice interaction process and improve the fluency of the voice interaction.
[0015] Exemplary methods Figure 1 This is a flowchart illustrating a voice interaction method provided in an exemplary embodiment of this disclosure. This embodiment can be applied to various scenarios supporting voice interaction and can be executed by various types of electronic devices. For example, it can be applied to a vehicle and executed by the vehicle's smart cockpit controller. Figure 1 As shown, the method includes the following steps: Step 101: Using a voice interaction model, the input user voice signal is recognized to obtain user intent information.
[0016] The voice interaction model can be pre-built based on various related neural network models (such as large language models). Typically, the user's voice signal is first converted into text, and then the voice interaction model is used to understand the user's natural language input, identify the user's intent (such as navigation, query, control, etc.), and obtain the user's intent information.
[0017] As an example, when a user inputs "navigate to People's Square" via voice, the electronic device first converts the user's voice signal into text, and then uses a voice interaction model to recognize the user's intention to "set navigation".
[0018] Step 102: Based on the user intent information, determine the tools that need to be invoked.
[0019] Electronic devices can further break down complex tasks into at least one simple task based on the identified user intent information, and the execution of each task requires calling the corresponding tool.
[0020] Continuing with the example above, the user intent is "set up navigation," and the tool to be invoked is the navigation tool.
[0021] Step 103: Obtain the behavior parameters of the tool, and control the tool to execute the task corresponding to the user intent information based on the behavior parameters.
[0022] The behavior parameter instructs the tool to execute tasks in a synchronous blocking or asynchronous non-blocking manner. Behavior parameters can use default configurations or be set by the user in real-time.
[0023] Using the behavior parameters mentioned above, you can control the tool to execute tasks in either synchronous blocking or asynchronous non-blocking mode.
[0024] In BLOCKING mode, the caller waits for the tool to complete its execution before continuing. This mode is suitable for scenarios where results must be obtained immediately, such as service modules in vehicle control. During the execution of the service module, the voice interaction model's thread is blocked and cannot handle other tasks. In an instance, the tool's execute() method can be called, which synchronously returns the task execution result.
[0025] In NON_BLOCKING mode, the caller can immediately return a pending state, and the tool executes asynchronously in the background. The voice interaction model can continue processing other tasks without being blocked. Once the tool completes its execution, it notifies the voice interaction model via an event mechanism. This mode is suitable for time-consuming operations such as geocoding, route planning, network requests, and database queries. In one example, the tool's `execute_async()` method can be called, which immediately returns a Future object, allowing the tool to execute the task in parallel within a separate thread or coroutine.
[0026] Step 104: Based on behavioral parameters, determine when the voice interaction model generates feedback information.
[0027] Based on the task execution method represented by the behavior parameters, the voice interaction model can be configured with different feedback timings. For example, if the behavior parameter is BLOCKING, the voice interaction model generates feedback information when the tool completes the task. If the behavior parameter is NON_BLOCKING, the voice interaction model generates feedback information at the current moment.
[0028] Step 105: In response to the current opportune moment for generating feedback information, generate feedback information to be sent to the user.
[0029] For example, if the behavior parameter is BLOCKING, the voice interaction model needs to wait for the tool to complete execution before generating feedback information. If the behavior parameter is NON_BLOCKING, the tool generates feedback information immediately upon being invoked, informing the user that a task is being performed.
[0030] Feedback information can be of various types and output in various formats. For example, using TTS (Text-to-Speech) technology, the results returned by the tool after completing a task can be converted into natural and fluent speech output. It can also support multiple timbre and speech rate adjustments to achieve personalized speech expression. Furthermore, a visual interactive interface can display recognition results, system status, navigation information, and more.
[0031] In this embodiment, the voice interaction model can realize natural language generation function, converting the structured tool execution results into natural and fluent speech, or converting the current task execution status of the tool into speech according to a preset template.
[0032] The voice interaction method provided in this disclosure utilizes a voice interaction model to recognize the input user voice signal and obtain user intent information; based on the user intent information, it determines the tool to be invoked; it obtains the tool's behavior parameters and controls the tool to execute the task corresponding to the user intent information based on the behavior parameters; based on the behavior parameters, it determines the timing for the voice interaction model to generate feedback information; and in response to the current timing that meets the requirements for generating feedback information, it generates feedback information to be given to the user. This method enables flexible configuration of behavior parameters for the tools to be invoked during voice interaction. According to the behavior parameters, the tool can be flexibly controlled to execute tasks in an asynchronous non-blocking or synchronous blocking manner, thereby making the way the tool executes tasks more compatible with the actual scenario, helping to reduce waiting latency during voice interaction and improve the fluency of voice interaction.
[0033] In some alternative implementations, such as Figure 2 As shown, step 104 includes: Step 1041: If the behavior parameter indicates that the tool uses a synchronous blocking method to execute the task, determine the moment when the tool completes the task as the timing for the voice interaction model to generate feedback information.
[0034] In other words, if the behavior parameter is BLOCKING, the voice interaction model needs to wait for the tool to complete execution before generating feedback information. Synchronous blocking is suitable for scenarios that require immediate results, where the user explicitly requests immediate feedback, and the result directly affects subsequent dialogue. For example, vehicle control tools can use synchronous blocking to execute tasks.
[0035] By setting the behavior parameters to execute tasks in a synchronous blocking mode, the voice interaction model can be made to wait temporarily in scenarios where task execution results need to be obtained in a short time. This avoids delays in the output of execution results caused by the voice interaction model generating feedback information during the tool's task execution, thus improving the real-time response performance of the interaction.
[0036] In some alternative implementations, such as Figure 2 As shown, step 104 includes: Step 1042: If the behavior parameter indicates that the tool uses an asynchronous non-blocking method to execute the task, determine the moment when the tool starts executing the task as the timing for the voice interaction model to generate feedback information.
[0037] That is, in asynchronous non-blocking mode, once the tool is invoked, the system returns a pending status flag to the voice interaction model. Upon receiving the pending status flag, the voice interaction model determines the timing for generating feedback information and then immediately generates the feedback information.
[0038] Step 1043: Determine the scheduling parameters corresponding to the tool.
[0039] The scheduling parameter indicates when the tool should provide feedback on the execution results after the task is completed.
[0040] The scheduling parameters described above allow you to control whether the tool provides feedback on its execution results using either the IMMEDIATE or WHEN_IDLE method. In the IMMEDIATE scheduling method, the tool immediately transmits the execution result to the voice interaction model via an event mechanism after execution, without waiting for the voice interaction model to become idle. This scheduling method is suitable for high-priority tasks or scenarios where the user explicitly requests immediate feedback. The task execution result is immediately fed back to the voice interaction model, which then immediately generates feedback information. In one example, after the tool completes execution, a callback function is immediately invoked to pass the execution result to the voice interaction model.
[0041] In the WHEN_IDLE scheduling mode, after the tool completes execution, the results are temporarily stored in a buffer, waiting to be delivered to the voice interaction model when it becomes idle. This is suitable for low-priority tasks and background tasks, avoiding interruption of the user's current interaction. When the voice interaction model is detected to be idle (the current voice output is completed or the user stops input), the buffered execution results are then delivered to the voice interaction model in batches. In one example, after the tool completes execution, the results are placed in a result queue, and the voice interaction model checks the queue and retrieves the execution results when idle.
[0042] Step 1044: If the scheduling parameter indicates immediate feedback of the execution result, determine the moment when the tool generates the execution result as the timing for the voice interaction model to generate feedback information.
[0043] That is, if the scheduling parameter is IMMEDIATE, the voice interaction model can immediately generate feedback information after the tool finishes executing the task.
[0044] Step 1045: If the scheduling parameters indicate that the execution result will not be fed back immediately, the moment when the tool has generated the execution result and the voice interaction model is in an idle state is taken as the time when the voice interaction model generates feedback information.
[0045] That is, if the scheduling parameter is WHEN_IDLE, and the voice interaction model is currently in a non-idle state, the execution result is cached and the system waits for the voice interaction model to become idle. When the voice interaction model becomes idle, it can immediately generate feedback information.
[0046] In this embodiment, when the tool is executing tasks in an asynchronous non-blocking mode, the timing for generating feedback information can be set at the start of task execution. Then, based on the scheduling parameters, the timing for generating feedback information can be adaptively determined after the task is completed. This allows for the simulation of a "talk and do" interaction mode after the tool starts executing tasks, avoiding long waiting times for users, improving the smoothness of interaction, and enhancing the adaptability of voice interaction to real-world scenarios.
[0047] In some alternative implementations, such as Figure 2 As shown, step 105 includes: Step 1051: At the moment when the tool starts performing the task, the voice interaction model is used to generate the first feedback information to prompt the user that the tool is performing the task.
[0048] After step 1042 above, since the moment the tool starts executing the task is not yet the time for the voice interaction model to generate feedback information, step 1051 can continue to be executed at this point. For example, after receiving the pending status indicator, the voice interaction model immediately generates the first feedback information: "Okay, setting up navigation to People's Square for you."
[0049] Step 1052: In response to the completion of the task by the tool, if the scheduling parameters indicate that the execution result should be fed back immediately, the execution result generated by the tool is sent to the voice interaction model, which then generates a second feedback message to prompt the user that the task has been completed.
[0050] Following step 1044 above, if the scheduling parameter is IMMEDIATE, since the moment the tool generates the execution result coincides with the moment the voice interaction model generates feedback information, step 1052 can proceed. That is, immediately after the tool finishes its task, the execution result is transmitted to the voice interaction model, which then generates second feedback information based on the result. For example, the second feedback information might be: "The route has been planned; it is estimated to arrive at People's Square in 18 minutes, a total distance of 5.2 kilometers."
[0051] Optionally, after the tool completes its task, a pre-registered callback function can be invoked to pass the execution result. The callback function includes parameters such as the tool name, execution status, result data, and error information. The callback function executes in a separate thread and does not block the thread used by the tool. The callback function is responsible for passing the result to the voice interaction model and determining the timing of this passing based on the aforementioned parameters.
[0052] Step 1053: In response to the completion of the tool's task execution, if the scheduling parameters indicate that the execution result will not be fed back immediately, the execution result generated by the tool is stored in a preset cache, and when the voice interaction model is idle, the execution result is sent to the voice interaction model, which then generates the second feedback information.
[0053] After step 1045 above, if the scheduling parameter is WHEN_IDLE, since the tool has already generated the execution result and the voice interaction model is in an idle state, this is the time for the voice interaction model to generate feedback information. Therefore, step 1053 can continue to be executed at this time. That is, after the tool finishes executing the task and the voice interaction model is idle, the cached execution result is passed to the voice interaction model. The voice interaction model generates second feedback information based on the execution result and outputs the second feedback information to prompt the user that the task has been completed.
[0054] This embodiment, in conjunction with the aforementioned optional embodiments, allows for the generation of feedback information at the start of task execution when the tool is executing tasks in an asynchronous, non-blocking manner. This enables a simulated "speak and do" interaction after the tool begins task execution, avoiding prolonged user waiting and improving interaction fluency. Then, based on scheduling parameters, feedback information is adaptively generated according to the state of the voice interaction model after the task is completed. This further enhances the adaptability of voice interaction to real-world scenarios, making the voice interaction process smoother.
[0055] In some alternative implementations, where the tool executes tasks asynchronously and non-blockingly, the method also includes: During the execution of a task by the tool, determine the current task execution state of the tool; determine the feedback strategy corresponding to the task execution state; and generate third feedback information to prompt the user about the current task execution state.
[0056] Specifically, during task execution, the tool can return the current task execution status in real time. For example, after being invoked, the tool can return a Future object, which represents the asynchronous execution status. The voice interaction model can query the tool's execution status (including four states: pending, executing, completed, and failed) through the Future object. The Future objects corresponding to each tool constitute a list of Future objects, which allows tracking of all currently executing tools.
[0057] The tool can use a state machine to implement various state transitions. For example, state transitions follow strict rules: waiting → task execution → task completion / failure. The system can also record timestamps of state transitions for performance analysis and troubleshooting. The tool's execution state can also be synchronized using thread-safe data structures (such as Pythonthreading.Lock, asyncio.Lock, etc.) to ensure consistency in a multi-threaded environment. When a state changes, the tool can publish a state change event via a bus to notify relevant modules.
[0058] As an example, the feedback strategy for the waiting state is as follows: When a tool call is first triggered, the feedback template is a confirmatory response, informing the user that the system has received the instruction and begun processing. Examples include: "Okay, working on {action}", "Received, {action} soon", "Understood, {action} in progress". {action} is filled in according to the tool type, such as "Set navigation", "Query information", "Adjust temperature", etc. This feedback strategy for the waiting state corresponds to the strategy for generating feedback information at the time described in step 1042 above.
[0059] The task execution status feedback strategy is as follows: the tool is executing and has not yet completed. The feedback template is a progress indicator, informing the user that the system is working. For example, "In action {}", "{action}, please wait", "In action for you {action}". Task execution feedback is suitable for tools with longer execution times (e.g., >1 second). For fast tools (e.g., <1 second), task execution feedback can be skipped, and the user can directly wait for the task completion status.
[0060] The task completion status feedback strategy is as follows: The tool has successfully completed execution, and the feedback template is a result-oriented feedback, informing the user of the execution result. Examples include, "Route planned, estimated arrival time {eta_minutes} minutes," "Set to {temperature} degrees," and "Query result: {result}." The task completion status feedback should include specific result information so that the user understands the execution effect. The task completion status feedback strategy corresponds to the strategy for generating feedback information as described in steps 1044 or 1045 above.
[0061] The task failure status feedback strategy is as follows: the feedback template should be an error message, informing the user of the reason for the failure and providing suggestions. For example, "Sorry, location {place} was not found. Please confirm the location name or provide a more detailed address," "Sorry, network connection failed. Please try again later," or "Sorry, {action} failed, {error_reason}." The task failure status feedback should clearly explain the reason for the failure and provide solutions to guide the user to try again.
[0062] This embodiment improves the overall fluency of voice interaction by setting a feedback strategy corresponding to the execution status of the tool and enabling real-time feedback on the execution progress to the user during the tool's task execution.
[0063] Based on the above embodiments, in one application scenario of this method, the following process can be executed: (1) When the user inputs “Navigate to People’s Square”, the electronic device uses a voice-to-text conversion method to transcribe the voice signal into text.
[0064] (2) The voice interaction model recognizes the user's intent as "set navigation" and decides to call the setting navigation tool.
[0065] (3) Obtain the behavior and scheduling parameters of the navigation tool: behavior = NON_BLOCKING, scheduling = WHEN_IDLE.
[0066] (4) The system immediately returns a pending status to the voice interaction model.
[0067] (5) The voice interaction model immediately generates a pending status feedback “Okay, setting up navigation to People’s Square for you”, and the TTS (Text-to-Speech) module plays the voice (takes about 2 seconds).
[0068] (6) At the same time, the navigation tool is set to run asynchronously in the background. First, the geocoding API (Application Programming Interface) is called to query the coordinates of "People's Square" (takes about 1 second), and then the route planning API is called to calculate the route (takes about 2 seconds).
[0069] (7) The navigation tool is set to complete (total time is about 3 seconds), and the execution result is returned, including route information (total distance 5.2 kilometers, estimated time 18 minutes).
[0070] (8) When the voice interaction model is in an idle state (after the pending feedback has been played), it receives the above execution result.
[0071] (9) The voice interaction model generates a completed status feedback “The route has been planned and it is expected to reach People’s Square in 18 minutes. The total distance is 5.2 kilometers”. The TTS module plays the voice.
[0072] (10) The vehicle control module displays the planned route on the map.
[0073] In this scenario, after the user issues a command, they immediately hear confirmation feedback, "Okay, setting up navigation for you," within approximately 0.1 seconds, without experiencing any noticeable delay. About 2 seconds later, they hear supplementary feedback, "Route planned," allowing them to understand the outcome. The entire interaction is smooth and natural, conforming to human conversational habits.
[0074] In some optional implementations, the above-mentioned feedback strategy for determining the task execution status includes: Determine the task execution time of the tool; based on the task execution time, determine the corresponding feedback strategy.
[0075] The correspondence between task execution time and feedback strategy can be preset.
[0076] As an example, based on the time required for a tool to execute a task, various tools can be divided into fast tools (execution time less than 1 second), medium-speed tools (execution time 1-3 seconds), and slow tools (execution time greater than 3 seconds).
[0077] For quick tools, the feedback strategy is to not generate status feedback during task execution, but directly wait for the task to complete. Users will not perceive any execution delay and no intermediate feedback is needed. For example, quick tools such as window control and headlight control will directly provide feedback such as "windows are open" or "headlights are on".
[0078] For medium-speed tools, the feedback strategy is to generate brief status updates during task execution, such as "Processing" or "Please wait." This avoids giving the user the impression that the system is unresponsive, but detailed progress information is not provided. For example, medium-speed tools such as geocoding and simple queries would first provide feedback like "Searching for address information," and then provide feedback like "Address found" upon completion.
[0079] For slow-moving tools, the feedback strategy is to generate detailed task execution status feedback and update the progress regularly. This lets users know the system is working and avoids anxiety. For example, for slow tools such as complex route planning and big data queries, the initial feedback is "Planning a route, please wait," followed by a progress update every 2 seconds showing "Calculating the optimal route," and finally, a feedback "Route planned."
[0080] This embodiment achieves adaptive and dynamic setting of feedback strategies by setting the feedback strategy corresponding to the task execution time of the tool, thereby improving the adaptability of the feedback strategy to the actual interaction scenario and further enhancing the smoothness of the interaction.
[0081] In some optional implementations, the task execution time of the tool is determined, including: Obtain the historical execution time of the tool, and predict the execution time of the current task based on the historical execution time.
[0082] Historical execution duration can be the execution duration recorded for the target historical period (i.e., a period of preset duration before the current moment). Predicting task execution duration can be achieved using various methods, such as using a pre-trained machine learning model with historical execution duration and tool execution status information within the target historical period as input parameters to output the predicted task execution duration; or directly calculating the average of historical execution durations as the predicted task execution duration, etc.
[0083] By using dynamic prediction tools to forecast task execution time, the resulting feedback strategies can be more adaptable to actual interaction scenarios, resulting in higher accuracy and smoothness in the interaction process.
[0084] In some alternative implementations, step 1042 includes: Determine the priority level of the tool and, based on the priority level, determine the scheduling parameters of the tool.
[0085] The priority of a task can be determined by factors such as tool priority, user interaction status, and system load. Optionally, a priority can be pre-set for each tool, with the priority indicating the degree of priority. Alternatively, priority can be combined with factors such as user interaction status and system load to determine the degree of priority. For example, if the user's voice signal contains words like "immediately" or "right away," the priority of the corresponding service module can be increased; conversely, when the system load is too high (i.e., too many tasks are being executed), the priority of unexecuted tasks can be decreased.
[0086] For tools with high priority (exceeding the priority threshold), the scheduling parameter can be set to IMMEDIATE; for tasks with low priority (not exceeding the priority threshold), the scheduling parameter can be set to WHEN_IDLE.
[0087] This embodiment achieves flexible scheduling strategy configuration by determining the priority of tool execution, and the task execution is more accurately matched with the actual scenario, thus improving the scenario adaptability of task scheduling.
[0088] In some alternative implementations, step 103 above can be performed as follows: First, if the behavior parameters indicate that the tool uses an asynchronous, non-blocking method to execute tasks, then based on a preset concurrency pool, asynchronous execution resources are allocated to the tool, and these resources are used to control the tool to execute the tasks corresponding to the user's intent information in an asynchronous manner.
[0089] The concurrency pool is used to execute asynchronous tool calls. In this embodiment, the concurrency pool can include a thread pool and a coroutine pool. The size of the thread pool can be dynamically adjusted according to system resources to avoid resource exhaustion caused by creating too many threads. The coroutine pool is suitable for I / O-intensive tools (such as network requests), while the thread pool is suitable for CPU-intensive tools (such as data processing).
[0090] Then, in response to the tool completing the task, a pre-registered callback function is invoked, and the execution result is generated using the callback function.
[0091] After the tool completes its task, it can call a pre-registered callback function to pass the execution result. The callback function includes parameters such as the tool name, execution status, result data, and error information. The callback function can execute in an independent thread without blocking the tool thread. The callback function is responsible for passing the result to the voice interaction model, determining the timing of the pass based on scheduling parameters.
[0092] This embodiment, by setting up a concurrency pool and callback functions, can better support the tool to execute tasks in an asynchronous concurrent manner, thereby improving task execution efficiency.
[0093] In some alternative implementations, step 103 can be performed as follows: First, if the tool to be called performs at least two tasks, determine the dependencies and execution order between the at least two tasks.
[0094] Electronic devices can generate task dependency graphs based on user intent information, representing the dependencies between different tasks. For example, route planning depends on geocoding results, and POI (Point of Interest) queries depend on route planning results. Task dependency graphs can be directed acyclic graphs, where nodes represent tasks and edges represent dependencies. Dependencies can be dynamically updated to adapt to changes in tasks.
[0095] Optionally, in addition to predefined dependencies, dependencies can also be automatically identified by analyzing the input and output parameters of tasks. For example, if the input parameters of task B depend on the output of task A, a dependency edge A→B is automatically added. Dynamic dependency identification can employ data flow analysis techniques to track the source and destination of parameters.
[0096] Electronic devices can execute topological sorting algorithms (such as Kahn's algorithm or DFS algorithm) to calculate the execution order of each task.
[0097] Then, based on dependencies and execution order, at least two tasks are scheduled to execute the task corresponding to the user intent information.
[0098] Specifically, the in-degree of each task (the number of its predecessor tasks) can be calculated, and tasks with an in-degree of 0 can be added to the task queue. Tasks are then retrieved from the task queue and submitted to the corresponding tools for execution. After execution, the in-degree of subsequent tasks is updated, and tools with a new in-degree of 0 are added to the task queue. This process is repeated until all tasks are completed.
[0099] Optionally, the electronic device can record the execution process of the task call chain in real time, including the start time, end time, execution status, and dependencies of each task node. It can also provide visualization tools to display the execution flow and dependencies of the task call chain, facilitating debugging and optimization. Execution logs can be exported for performance analysis and troubleshooting.
[0100] This embodiment achieves orderly and efficient task scheduling by constructing dependencies and execution order between tasks, thereby improving the efficiency of voice interaction.
[0101] In some alternative implementations, at least two tasks can be scheduled separately based on dependencies and execution order to execute the task corresponding to the user intent information, as follows: Based on dependencies and execution order, tasks that can be executed in parallel are determined from the tasks corresponding to user intent information, and these tasks are executed simultaneously.
[0102] Specifically, in the task queue mentioned above, tasks with an in-degree of 0 can be executed in parallel, making full use of system resources and improving task execution efficiency. For example, multiple geocoding tasks without dependencies can be executed in parallel, significantly reducing the overall latency. As an example, the navigation service module subscribes to service call event information and receives three geocoding tasks. The three tasks are executed in parallel, with a total time of approximately 1 second (each task takes approximately 1 second, and the time taken for parallel execution is not cumulative).
[0103] In one application scenario of this method, a user says, "Go to xx, via yy and zz." The system needs to execute three geocoding tasks and one route planning task. Using asynchronous orchestration of tool call chains maximizes parallel execution. The execution flow is as follows: (1) The voice interaction model recognizes user intent and requires the use of three geocoding tools (geocode_xx, geocode_yy, geocode_zz) and one route planning tool (route_planning).
[0104] (2) System construction task dependency graph: The three geocoding tasks have no dependencies and can be executed in parallel; the path planning depends on the three geocoding results.
[0105] (4) The system uses a topology sorting algorithm for scheduling: calculate the in-degree, the in-degree of the three geocoding tasks is 0, and the in-degree of the path planning task is 3.
[0106] (5) Add the three geocoding tasks to the ready queue and submit them to the thread pool for execution in parallel.
[0107] (6) The voice interaction model generates pending feedback “Okay, planning a route for you, passing through yy and zz, destination xx”, and TTS plays the voice prompt.
[0108] (7) The three geocoding tasks are executed in parallel, each taking about 1 second, for a total of about 1 second (the parallel execution does not accumulate).
[0109] (8) After the three geocodings are completed, the in-degree of the path planning task becomes 0 and it is added to the ready queue for execution.
[0110] (9) Path planning is executed, which takes about 2 seconds. It calculates the optimal route from the current position, passing through yy and zz, and finally reaching xx.
[0111] (10) Once the route planning is complete, send the execution results, which include route information (total distance 8.5 km, estimated time 25 minutes).
[0112] (11) The voice interaction model generates the completed feedback "The route has been planned, passing through yy and zz, and is expected to arrive at xx in 25 minutes, with a total distance of 8.5 kilometers", and TTS plays the voice prompt.
[0113] In this application scenario, the total latency = 3 geocodes executed in parallel (1 second) + route planning (2 seconds) = 3 seconds. If serial execution is used, the total latency = 3 geocodes executed serially (3 seconds) + route planning (2 seconds) = 5 seconds. Therefore, the user's waiting time is significantly reduced.
[0114] In some alternative implementations, at least two tasks can be scheduled separately based on dependencies and execution order to execute the task corresponding to the user intent information, as follows: First, determine the priority of at least two tasks.
[0115] Specifically, the priority of each task executed by each tool can be predefined. For example, the priority can be divided into three levels: high, medium, and low, corresponding to three priority queues.
[0116] As an example, tasks in the high-priority queue can include safety-related tasks (such as emergency braking, window control, hazard warnings, and other safety functions) and tools explicitly requested by the user (such as navigation settings, air conditioning control, and other direct commands). High-priority tools have priority in obtaining execution resources and can preempt low-priority tools.
[0117] Tasks in the medium-priority queue can include information query tasks (such as nearby POI queries, weather queries, traffic condition queries, and other information services) and vehicle control tasks (such as seat adjustment, ambient lighting control, and other comfort functions). Medium-priority tasks are executed after high-priority tasks and cannot preempt high-priority tasks.
[0118] Tasks in the low-priority queue can include background task tools (such as background services like logging, statistical analysis, and cache clearing) and preloading tools (such as optimization tasks like resource preloading and data synchronization). Low-priority tasks are executed when the system is idle and can be preempted by high- and medium-priority tasks.
[0119] Priority can be automatically assigned based on task type. For example: safety tasks → high priority, navigation tasks → medium priority, vehicle control tasks → high priority, query tasks → medium priority, and record tasks → low priority. Users can also dynamically specify priorities, overriding the default configuration.
[0120] Then, based on priority, each of the at least two tasks is added to its corresponding task queue.
[0121] Finally, based on dependencies and execution order, tasks are extracted from each task queue and executed.
[0122] Specifically, when executing tasks, tasks are first retrieved from the high-priority queue. If the high-priority queue is empty, tasks are retrieved from the medium-priority queue, and if the medium-priority queue is empty, tasks are retrieved from the low-priority queue. The queues follow a FIFO (First-In, First-Out) order, and tools of the same priority are executed in the order they were submitted.
[0123] Preemptive scheduling can also be used. When a high-priority task arrives, if system resources are full (such as a full thread pool), a low-priority task can be paused, releasing execution resources to the high-priority task. The paused low-priority task is then re-added to the queue, waiting to resume execution when resources become available. This preemptive mechanism ensures timely response to critical functions and avoids being blocked by background tasks.
[0124] An aging mechanism can also be used to prevent low-priority tasks from remaining unexecuted for extended periods. If a task waits in the queue for too long, its priority will gradually increase. For example, a low-priority task waiting more than 10 seconds will be promoted to medium priority; waiting more than 30 seconds will be promoted to high priority. The aging mechanism ensures that all tools are eventually executed.
[0125] This embodiment sets up task queues with different priorities, enabling dynamic tool invocation based on task importance, thereby improving task execution efficiency and scenario adaptability.
[0126] In some alternative implementations, at least two tasks can be scheduled separately based on dependencies and execution order to execute the task corresponding to the user intent information, as follows: First, in response to the fact that at least two of the target tasks have failed to execute, determine the reason for the failure of the target task.
[0127] The reason for failure can be determined by the failure message returned after the task fails. For example, the reason for failure may include network timeout, geocoding failure, query failure, etc.
[0128] Then, based on the reasons for the execution failure and the type of the target task, the corresponding failure response strategy is determined.
[0129] Among them, failure handling strategies include, but are not limited to, at least one of the following: interruption strategy, skip strategy, degradation strategy, retry strategy, and rollback strategy.
[0130] The interruption strategy means that all successor nodes of a failed node are marked as failed and will no longer be executed.
[0131] A skip strategy refers to the ability to skip the target task and continue with subsequent processes when a specific type of exception occurs.
[0132] Degradation strategies refer to using simplified algorithms or approximate results to replace the execution results of the target task when a specific type of exception occurs.
[0133] Retry strategies address temporary anomalies, such as network timeouts. For temporary anomalies, the tool can regain control and re-execute the target task. Retry strategies can include fixed-delay retries, exponential backoff retries, etc. For unrecoverable failed tasks (such as non-existent locations), compensation mechanisms can be used, such as prompting the user to re-enter the information or using a similar location as a substitute.
[0134] A rollback strategy refers to undoing an executed task and restoring it to its initial state.
[0135] Finally, based on the failure handling strategy, at least two tasks are rescheduled to execute the task corresponding to the user intent information.
[0136] Optionally, when some tasks in the task queue succeed and some fail, feedback information indicating the success of some tasks can be generated. For example, if two out of three geocoding tasks succeed and one fails, the above degradation strategy can be adopted, and route planning can still be performed (using the two successful locations), and feedback information can be generated to inform the user of the location where the coding failed.
[0137] This embodiment enables targeted responses to the failure of some tasks, thereby reducing the risk of overall task failure and improving the stability of the interaction by setting failure handling strategies.
[0138] In one application scenario, a user says "Navigate to XYZ," where XYZ is a non-existent location. Geocoding fails, and the system clearly informs the user of the reason for the failure through dynamic voice feedback. The specific execution flow is as follows: (1) The voice interaction model recognizes the user's intent and calls the amap_geocode_place tool with the parameters place="XYZ"behavior=NON_BLOCKING.
[0139] (2) The system returns a pending status, and the voice interaction model generates feedback "Okay, querying the location of XYZ" and the TTS module plays the feedback information.
[0140] (3) The geocoding tool runs in the background and calls the map API to query “XYZ”.
[0141] (4) The API returned an error, the location was not found, the tool failed to execute, and the status was set to failed.
[0142] (5) The tool sends a response: status=failed, error="The location was not found".
[0143] (6) The voice interaction model receives a failure response and generates a failed feedback: "Sorry, the location XYZ was not found. Please confirm the location name or provide a more detailed address, such as the area or nearby landmarks."
[0144] (7) The TTS module plays the failed feedback so that the user can understand the reason for the failure.
[0145] (8) The user re-enters "Navigate to People's Square", and the system re-executes.
[0146] In this application scenario, after the user issues a command, they immediately hear a confirmation message, "Querying." Approximately one second later, they hear a failure message, clearly understanding the reason for the failure and receiving suggested solutions. The user can then re-enter the command based on the suggestions to avoid repeating the failure. The entire process is transparent and clear, preventing user confusion or anxiety.
[0147] In some alternative implementations, step 105 can be performed as follows: Obtain the current context information of the vehicle; based on the context information, generate feedback information corresponding to the context information.
[0148] Contextual information refers to the current state of the vehicle. This information can be collected by sensors on the vehicle or obtained from a remote server based on the vehicle's location. For example, contextual information may include at least one of the following: vehicle status information (e.g., location information, motion status information, energy status information, in-vehicle equipment status information), environmental information (e.g., weather information, road condition information, time information, etc.), navigation information (e.g., destination information, waypoint information, route information, current road segment information, etc.), and surrounding facility information (e.g., gas station information, charging station information, service area information, parking lot information, etc.).
[0149] Voice interaction models can incorporate contextual information to enrich feedback and provide more personalized information that is relevant to the current environment. For example, when setting navigation, the voice interaction model combines the current location and traffic information to provide feedback such as, "From your current location, it is estimated that you will arrive in 18 minutes. Traffic conditions are good."
[0150] Based on the tool's execution results and the user context, the voice interaction model can also adjust the emotional tone of the feedback information. Positive expressions (such as "Great!" or "No problem") are used when the task is successfully completed, sympathetic expressions (such as "Sorry!" or "I'm sorry") are used when the task fails, and reassuring expressions (such as "Please wait a moment" or "It will be ready soon") are used when there is a long wait.
[0151] This embodiment combines the vehicle's contextual information with at least one task to be performed, thereby enhancing the context of the task, adjusting the execution details of the task, and improving the relevance and accuracy of voice interaction task execution.
[0152] In some alternative implementations, such as Figure 3 As shown, step 103 includes: Step 1031: Based on the preset associated tool information, determine the associated tool corresponding to the tool.
[0153] The relationships between tools can be preset, and based on these relationships, the associated tools corresponding to the currently used tool can be determined. For example, if the currently used tool is a search tool that performs the task of searching for nearby gas stations, then its associated tool is a navigation tool, indicating that the user may set up navigation after searching for gas stations.
[0154] Step 1032: Obtain the current context information of the vehicle.
[0155] The context information is the same as that described in the above embodiments, and will not be repeated here.
[0156] Step 1033: In response to the context information matching the preset target context triggering conditions corresponding to the associated tool, the corresponding tasks are executed by the control tool and the associated tool based on the behavior parameters.
[0157] The target scenario trigger conditions can be preset. For example, the target scenario trigger conditions can be "driving + vehicle speed greater than the set speed + fuel level less than 30%", meaning that the navigation tool will only be triggered to execute the task of setting navigation to a gas station when the current scenario information meets the target scenario trigger conditions.
[0158] This embodiment achieves more accurate prediction of user interaction needs and improves the accuracy of voice interaction by setting the association between tools and the contextual triggering conditions.
[0159] In some alternative implementations, such as Figure 4 As shown, prior to step 1031, the method further includes: Step 401: Obtain the historical tool call records recorded in the target historical period, as well as the corresponding historical context information.
[0160] The target historical period can be a preset duration preceding the current moment, such as the last 30 days.
[0161] Step 402: Based on historical tool call records, predict the call correlation between different tools to obtain related tool information.
[0162] Predicting the correlation between tool calls can be achieved using relevant algorithms. For example, the PrefixSpan (Prefix-Projected Sequential Pattern Mining) algorithm can be used to mine frequent sequence patterns. The algorithm steps include: (1) extracting tool call sequences from historical tool call records; (2) setting a minimum support threshold (e.g., 20%) and mining frequent sequences with support greater than the threshold; (3) constructing a pattern tree, where each node represents a tool, the edges represent the call order, and the node weights represent the support. For example, the mined frequent sequence pattern is "query nearby gas stations → set navigation" (support 80%), indicating that in 80% of cases, the user will set navigation after querying gas stations.
[0163] Step 403: Based on historical context information, set the context triggering conditions for the associated tools indicated by the associated tool information.
[0164] Specifically, the target historical context information corresponding to the related tools when performing tasks can be extracted. From the target historical context information, information that appears frequently can be identified, thereby determining the context triggering conditions for the related tools. For example, the context triggering conditions corresponding to each group of related tools may include time information (time features such as weekday / weekend, morning / evening), location information (location features such as home / office / highway), and vehicle status information (status features such as driving / parking, high / low fuel level).
[0165] Optionally, the relevance of user tools can change over time, so the relationship database can be updated periodically. For example, a sliding window mechanism can be used to perform sequence pattern mining using only historical data from the most recent N days (e.g., 30 days) and update the pattern tree. Incremental updates of patterns can also be supported; when new data arrives, the pattern support is updated to avoid excessive resource consumption caused by full-scale updates.
[0166] This embodiment can effectively uncover users' tool usage habits by pre-predicting the call correlations between different tools and setting corresponding contextual trigger conditions, thereby more accurately predicting the tools users want to call and improving the accuracy of interactive task prediction.
[0167] In some alternative implementations, prior to step 1033, the method further includes: Determine the resources required by the associated tools to perform the task, and preload the resources.
[0168] As an example, for navigation tools, map data such as address details and route planning data can be preloaded. For query tools, query results such as POI details and rating data can be preloaded. Preloading is done asynchronously in the background, without affecting the current interaction. Preloaded resources are cached in memory and used directly when actually called, reducing latency.
[0169] By preloading the resources required by associated tools, the time spent loading resources by the tools can be effectively reduced, thereby improving the efficiency of the tools in performing tasks.
[0170] Exemplary device Figure 5 This is a schematic diagram of the structure of a voice interaction device provided in an exemplary embodiment of this disclosure. This embodiment can be applied to various scenarios supporting voice interaction, and the device can be installed on various types of electronic devices, such as... Figure 5 As shown, the voice interaction device includes: a recognition module 501, used to recognize the input user voice signal using a voice interaction model to obtain user intent information; a first determination module 502, used to determine the tool to be invoked based on the user intent information; an execution module 503, used to obtain the behavior parameters of the tool and control the tool to execute the task corresponding to the user intent information based on the behavior parameters, wherein the behavior parameters are used to instruct the tool to execute the task in a synchronous blocking mode or an asynchronous non-blocking mode; a second determination module 504, used to determine the timing for the voice interaction model to generate feedback information based on the behavior parameters; and a generation module 505, used to generate feedback information to be fed back to the user in response to the current timing that meets the requirements for generating feedback information.
[0171] Reference Figure 6 , Figure 6 This is a schematic diagram of the structure of a voice interaction device provided in another exemplary embodiment of this disclosure.
[0172] In some optional implementations, the second determining module 504 is further configured to: if the behavior parameter indicates that the tool uses a synchronous blocking mode to execute the task, determine the moment when the tool completes the task as the timing for the voice interaction model to generate feedback information.
[0173] In some optional implementations, the second determining module 504 includes: a first determining unit 5041, used to determine the moment when the tool starts executing the task as the timing for the voice interaction model to generate feedback information if the behavior parameter indicates that the tool uses an asynchronous non-blocking method to execute the task; a second determining unit 5042, used to determine the scheduling parameter corresponding to the tool, wherein the scheduling parameter is used to indicate the timing for the tool to provide feedback on the execution result after the task is completed; a third determining unit 5043, used to determine the moment when the tool generates the execution result as the timing for the voice interaction model to generate feedback information if the scheduling parameter indicates that the execution result is not immediately provided; and a fourth determining unit 5044, used to determine the moment when the tool has generated the execution result and the voice interaction model is in an idle state as the timing for the voice interaction model to generate feedback information if the scheduling parameter indicates that the execution result is not immediately provided.
[0174] In some optional implementations, the generation module 505 includes: a first generation unit 5051, used to generate a first feedback message to prompt the user that the tool is performing a task when the tool starts executing the task; and a second generation unit 5052, used to, in response to the completion of the tool's task, if the scheduling parameter indicates immediate feedback of the execution result, send the execution result generated by the tool to the voice interaction model, and have the voice interaction model generate a second feedback message to prompt the user that the task has been completed; if the scheduling parameter indicates no immediate feedback of the execution result, store the execution result generated by the tool in a preset cache, and send the execution result to the voice interaction model when the voice interaction model is idle, and have the voice interaction model generate the second feedback message.
[0175] In some optional implementations, the generation module 505 further includes: a fifth determining unit 5053, used to determine the current task execution state of the tool during task execution; and a third generation unit 5054, used to determine the feedback strategy corresponding to the task execution state and generate third feedback information to prompt the user about the current task execution state.
[0176] In some optional implementations, the third generation unit 5054 is further used to: determine the task execution time of the tool; and determine the corresponding feedback strategy based on the task execution time.
[0177] In some optional implementations, the third generation unit 5054 is further used to: obtain the historical execution time of the tool, and predict the execution time of the current task based on the historical execution time.
[0178] In some optional implementations, the second determining unit 5042 is further used to: determine the priority level of the tool, and determine the scheduling parameters of the tool based on the priority level.
[0179] In some optional implementations, the execution module 503 includes: a first execution unit 5031, which, if the behavior parameters indicate that the tool uses an asynchronous non-blocking method to execute the task, allocates asynchronous execution resources to the tool based on a preset concurrency pool, and uses the asynchronous execution resources to control the tool to execute the task corresponding to the user intent information in an asynchronous manner; and a fourth generation unit 5032, which, in response to the completion of the tool's task execution, calls a pre-registered callback function and uses the callback function to generate the execution result.
[0180] In some optional implementations, the execution module 503 includes: a sixth determining unit 5033, used to determine the dependency relationship and execution order between at least two tasks if the number of tasks to be executed by the tool to be called is at least two; and a scheduling unit 5034, used to schedule the at least two tasks respectively based on the dependency relationship and execution order to execute the task corresponding to the user intent information.
[0181] In some optional implementations, the scheduling unit 5034 is further used to: determine the tasks that can be executed in parallel from the tasks corresponding to the user intent information based on dependencies and execution order, and execute the tasks that can be executed in parallel at the same time.
[0182] In some optional implementations, the scheduling unit 5034 is further configured to: determine the priorities of at least two tasks respectively; add each of the at least two tasks to its corresponding task queue based on the priority; and extract and execute tasks from each task queue based on dependencies and execution order.
[0183] In some optional implementations, the scheduling unit 5034 is further configured to: determine the reason for the execution failure of the target task in response to the existence of a target task that has failed to execute among at least two tasks; determine the corresponding failure handling strategy based on the reason for execution failure and the type of the target task, wherein the failure handling strategy includes at least one of the following: interruption strategy, skip strategy, degradation strategy, retry strategy and rollback strategy; and reschedule at least two tasks based on the failure handling strategy to execute the task corresponding to the user intent information.
[0184] In some optional implementations, the generation module 505 includes: a first acquisition unit 5055, used to acquire the current context information of the vehicle; and a fifth generation unit 5056, used to generate feedback information corresponding to the context information based on the context information.
[0185] In some optional implementations, the execution module 503 includes: a seventh determining unit 5035, used to determine the associated tool corresponding to the tool based on preset associated tool information; a second obtaining unit 5036, used to obtain the current context information of the vehicle; and a second execution unit 5037, used to control the tool and the associated tool to perform corresponding tasks based on behavioral parameters in response to the context information meeting the preset target context triggering conditions corresponding to the associated tool.
[0186] In some optional implementations, the device further includes: an acquisition module 506, used to acquire historical tool call records recorded in the target historical period and corresponding historical context information; a prediction module 507, used to predict the call correlation between different tools based on the historical tool call records to obtain associated tool information; and a setting module 508, used to set the context triggering conditions of the associated tools indicated by the associated tool information based on the historical context information.
[0187] In some alternative implementations, the execution module 503 is further configured to: determine the resources required when the associated tool performs the task, and preload the resources.
[0188] The exemplary embodiments of this device correspond to the exemplary method section described above in terms of implementation. The corresponding content between the two can be referenced, combined, and cited, and will not be repeated here. The beneficial technical effects corresponding to the exemplary embodiments of this device can be found in the corresponding beneficial technical effects of the exemplary method section described above, and will not be repeated here.
[0189] Exemplary electronic devices Figure 7 The present disclosure provides a structural diagram of an electronic device 700, which includes at least one processor 701 and a memory 702.
[0190] The processor 701 may be a central processing unit (CPU) or other form of processing unit with data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device 700 to perform desired functions.
[0191] The memory 702 may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and / or cache memory. Non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor 701 may execute one or more computer program instructions to implement the voice interaction methods and / or other desired functions of the various embodiments of this disclosure described above.
[0192] In one example, the electronic device 700 may also include an input device 703 and an output device 704, which are interconnected via a bus system and / or other forms of connection mechanism (not shown).
[0193] The input device 703 may also include, for example, a keyboard, a mouse, etc.
[0194] The output device 704 can output various information to the outside, including, for example, a display, a speaker, a printer, and a communication network and its connected remote output devices, etc.
[0195] Of course, for the sake of simplicity, Figure 7 Only some of the components of the electronic device 700 relevant to this disclosure are shown, omitting components such as buses, input / output interfaces, etc. In addition, the electronic device 700 may include any other suitable components depending on the specific application.
[0196] Exemplary computer program products and computer-readable storage media In addition to the methods and devices described above, embodiments of this disclosure may also provide a computer program product, including computer program instructions that, when executed by a processor, cause the processor to perform the steps of the voice interaction methods of the various embodiments of this disclosure described in the "Exemplary Methods" section above.
[0197] Computer program products can be written in any combination of one or more programming languages to perform the operations of embodiments of this disclosure. These programming languages include object-oriented programming languages such as Java and C++, as well as conventional procedural programming languages such as C or similar languages. The program code can be executed entirely on a user's computing device, partially on a user's computing device, as a standalone software package, partially on a user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.
[0198] Furthermore, embodiments of this disclosure may also be computer-readable storage media storing computer program instructions thereon, which, when executed by a processor, cause the processor to perform the steps of the voice interaction methods of the various embodiments of this disclosure described in the "Exemplary Methods" section above.
[0199] Computer-readable storage media may take the form of any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may include, but is not limited to, systems, apparatuses, or devices that are electrical, magnetic, optical, electromagnetic, infrared, or semiconductor, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.
[0200] The basic principles of this disclosure have been described above with reference to specific embodiments. However, the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.
[0201] Various modifications and variations can be made to this disclosure without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this disclosure and their equivalents, this disclosure is also intended to include such modifications and variations.
Claims
1. A voice interaction method, comprising: By using a voice interaction model, the input user voice signal is recognized to obtain user intent information; Based on the user intent information, determine the tool that needs to be invoked; The tool's behavior parameters are obtained, and the tool is controlled to execute the task corresponding to the user intent information based on the behavior parameters. The behavior parameters are used to instruct the tool to execute the task in a synchronous blocking mode or an asynchronous non-blocking mode. Based on the behavioral parameters, the timing for the voice interaction model to generate feedback information is determined. In response to the current timing that warrants the generation of the feedback information, feedback information is generated for use in providing feedback to the user.
2. The method according to claim 1, wherein, Determining the timing for the voice interaction model to generate feedback information based on the behavioral parameters includes: If the behavioral parameters indicate that the tool uses a synchronous blocking method to execute the task, the moment when the tool completes the task is determined as the timing for the voice interaction model to generate feedback information.
3. The method according to claim 1, wherein, Determining the timing for the voice interaction model to generate feedback information based on the behavioral parameters includes: If the behavioral parameters indicate that the tool executes the task in an asynchronous, non-blocking manner, the moment when the tool starts executing the task is determined as the timing for the voice interaction model to generate feedback information. Determine the scheduling parameters corresponding to the tool, wherein the scheduling parameters are used to indicate when the tool should provide feedback on the execution result after the task is completed; If the scheduling parameter indicates immediate feedback of the execution result, the moment when the tool generates the execution result is determined as the timing when the voice interaction model generates feedback information. If the scheduling parameter indicates that the execution result is not immediately fed back, the moment when the tool has generated the execution result and the voice interaction model is in an idle state is taken as the time when the voice interaction model generates feedback information.
4. The method according to claim 3, wherein, The response, in response to a current time that meets the criteria for generating the feedback information, generates feedback information for sending to the user, including: At the moment when the tool begins to perform a task, the voice interaction model is used to generate first feedback information to prompt the user that the tool is performing a task. In response to the completion of the task by the tool, if the scheduling parameter indicates immediate feedback of the execution result, the execution result generated by the tool is sent to the voice interaction model, and the voice interaction model generates a second feedback message to prompt the user that the task has been completed; if the scheduling parameter indicates no immediate feedback of the execution result, the execution result generated by the tool is stored in a preset cache, and when the voice interaction model is idle, the execution result is sent to the voice interaction model, and the voice interaction model generates the second feedback message.
5. The method according to claim 4, wherein, The method further includes: During the execution of a task by the tool, determine the current task execution state of the tool; Determine the feedback strategy corresponding to the task execution status, and generate third feedback information to prompt the user about the current task execution status.
6. The method according to claim 5, wherein, The step of determining the feedback strategy corresponding to the task execution state includes: Determine the task execution duration of the tool; Based on the task execution time, a corresponding feedback strategy is determined.
7. The method according to claim 6, wherein, Determining the task execution time of the tool includes: Obtain the historical execution time of the tool, and predict the execution time of the current task based on the historical execution time.
8. The method according to claim 3, wherein, Determining the scheduling parameters corresponding to the tool includes: The priority level of the tool is determined, and the scheduling parameters of the tool are determined based on the priority level.
9. The method according to claim 1, wherein, The step of controlling the tool to execute the task corresponding to the user intent information based on the behavioral parameters includes: If the behavior parameter indicates that the tool executes the task in an asynchronous non-blocking manner, based on a preset concurrency pool, asynchronous execution resources are allocated to the tool, and the asynchronous execution resources are used to control the tool to execute the task corresponding to the user intent information in an asynchronous manner. In response to the completion of the task by the tool, a pre-registered callback function is invoked, and the execution result is generated using the callback function.
10. The method according to claim 1, wherein, The step of controlling the tool to execute the task corresponding to the user intent information based on the behavioral parameters includes: If the tool to be invoked performs at least two tasks, determine the dependencies and execution order between at least two tasks; Based on the dependencies and the execution order, the at least two tasks are scheduled to execute the task corresponding to the user intent information.
11. The method according to claim 10, wherein, The step of scheduling the at least two tasks based on the dependency relationship and the execution order to execute the task corresponding to the user intent information includes: Based on the dependencies and the execution order, tasks that can be executed in parallel are determined from the tasks corresponding to the user intent information, and the tasks that can be executed in parallel are executed simultaneously.
12. The method according to claim 10, wherein, The step of scheduling the at least two tasks based on the dependency relationship and the execution order to execute the task corresponding to the user intent information includes: Determine the priority of each of the at least two tasks; Based on the priority, each of the at least two tasks is added to the corresponding task queue; Based on the dependencies and the execution order, tasks are extracted from each task queue and executed.
13. The method according to claim 10, wherein, The step of scheduling the at least two tasks based on the dependency relationship and the execution order to execute the task corresponding to the user intent information includes: In response to the existence of a target task that has failed to execute among the at least two tasks, the reason for the failure of the target task is determined; Based on the reasons for execution failure and the type of the target task, a corresponding failure handling strategy is determined, wherein the failure handling strategy includes at least one of the following: interruption strategy, skip strategy, degradation strategy, retry strategy and rollback strategy; Based on the failure handling strategy, the at least two tasks are rescheduled to execute the task corresponding to the user intent information.
14. The method according to claim 1, wherein, The generation of feedback information for sending to the user includes: Obtain the vehicle's current context information; Based on the context information, feedback information corresponding to the context information is generated.
15. The method according to claim 1, wherein, The step of controlling the tool to execute the task corresponding to the user intent information based on the behavioral parameters includes: Based on the preset associated tool information, determine the associated tool corresponding to the tool; Obtain the vehicle's current context information; In response to the context information matching the preset target context triggering conditions corresponding to the associated tool, the tool and the associated tool are controlled to perform corresponding tasks based on the behavioral parameters.
16. The method according to claim 15, wherein, Before determining the associated tool corresponding to the tool based on preset associated tool information, the method further includes: Retrieve historical tool call records for the target historical period, along with the corresponding historical context information; Based on the historical tool call records, the call correlation between different tools is predicted to obtain related tool information; Based on the historical context information, the context triggering conditions for the associated tools indicated by the associated tool information are set.
17. The method according to claim 15, wherein, Before controlling the tool and the associated tool to execute corresponding tasks based on the behavioral parameters in response to the context information meeting a preset target context triggering condition corresponding to the associated tool, the method further includes: Determine the resources required by the associated tool when it performs the task, and preload the resources.
18. A voice interaction device, comprising: The recognition module is used to recognize the input user voice signal using a voice interaction model to obtain user intent information; The first determining module is used to determine the tool to be invoked based on the user intent information; An execution module is used to acquire the behavior parameters of the tool and control the tool to execute the task corresponding to the user intent information based on the behavior parameters, wherein the behavior parameters are used to instruct the tool to execute the task in a synchronous blocking mode or an asynchronous non-blocking mode; The second determining module is used to determine the timing for the voice interaction model to generate feedback information based on the behavioral parameters. The generation module is used to generate feedback information for sending to the user in response to the current timing that meets the requirements for generating the feedback information.
19. A computer-readable storage medium storing a computer program, which, when executed, implements the voice interaction method according to any one of claims 1-17.
20. An electronic device, the electronic device comprising: processor; Memory used to store the processor's executable instructions; The processor is configured to read the executable instructions from the memory and execute the instructions to implement the voice interaction method according to any one of claims 1-17.