Full-duplex dialogue interruption and recovery method for vehicle-mounted voice interaction

Abstract

The invention discloses a vehicle-mounted full-duplex voice conversation interruption and recovery method, and belongs to the technical field of vehicle-mounted voice interaction. The method comprises the following steps: triggering a dialogue interruption event in response to a user interruption instruction which is detected in response to a preset condition during a dialogue; semantic mark information corresponding to the interrupt event is generated, and a context snapshot containing the dialogue history and the execution state is generated based on the semantic mark information; when a dialogue recovery request is received, retrieving the context snapshot according to the semantic marking information, and executing context reconstruction based on the retrieved context snapshot; and according to a context reconstruction result, controlling a dialogue management state machine to perform state transition so as to recover execution from the dialogue node when the interruption event occurs. According to the invention, the conversation state is saved and seamlessly recovered, and the problems of context loss and disordered recovery logic caused by interruption in the prior art are solved.

Description

Technical Field

[0001] This invention relates to the field of in-vehicle voice interaction technology, and in particular to a method and system for interrupting and resuming full-duplex voice dialogue in vehicles, which is especially suitable for application scenarios such as smart cockpits and in-vehicle voice assistants. Background Technology

[0002] With the rapid development of smart cockpit technology, in-vehicle voice interaction has become a core method of human-vehicle interaction. Full-duplex voice dialogue technology allows users to interrupt the system's broadcast at any time, improving the naturalness and efficiency of the interaction. However, existing technologies have the following problems in practical applications:

[0003] Context loss issue: When a user interrupts the system broadcast, existing solutions often fail to fully save the dialogue state at the moment of interruption, resulting in the need to re-perform semantic parsing and task planning after recovery, causing a disjointed user experience.

[0004] Confused recovery logic: Existing technologies lack standardized recovery mechanisms, and recovery strategies are inconsistent in different scenarios, which can easily lead to incorrect state transitions or repeated execution. Summary of the Invention

[0005] In view of the technical defects and drawbacks existing in the prior art, the present invention provides a method and system for interrupting and resuming full-duplex voice dialogue in vehicles to overcome the above problems or at least partially solve the above problems. The specific solution is as follows:

[0006] A method for interrupting and resuming full-duplex dialogue in in-vehicle voice interaction includes the following steps:

[0007] In response to the detection of a user interruption command that meets preset conditions during the conversation, a conversation interruption event is triggered;

[0008] Generate semantic tagging information corresponding to the interruption event, and generate a context snapshot containing dialogue history and execution state based on the semantic tagging information;

[0009] When a dialogue resumption request is received, the context snapshot is retrieved based on the semantic tagging information, and context reconstruction is performed based on the retrieved context snapshot;

[0010] Based on the results of context reconstruction, the control dialogue management state machine performs state transitions to resume execution from the dialogue node at the time the interruption event occurred.

[0011] In some embodiments, the preset conditions include at least one of the following conditions:

[0012] The detected voice command successfully matched a keyword in the preset interruption keyword library;

[0013] The detected voice signal energy exceeds the preset energy threshold and the duration reaches the preset time threshold.

[0014] In some embodiments, the semantic tagging information includes session ID, breakpoint ID, dialogue round, semantic role, intent type, and break status;

[0015] The session ID is used to uniquely identify a complete dialogue session. The interruption point ID is generated by combining the session ID and the dialogue round and is used to uniquely identify an interruption event within the session. The semantic role is used to distinguish whether the speaker at the time of interruption is a user or the system. The intent type is used to identify the core task category of the interrupted dialogue. The interruption status is used to characterize the operation phase that the system is executing at the time of interruption.

[0016] In some embodiments, the context snapshot includes the following content determined by the semantic tagging information:

[0017] The session identifier corresponding to the session ID;

[0018] The interrupt point identifier corresponding to the interrupt point ID;

[0019] The most recent N rounds of dialogue history corresponding to the aforementioned dialogue round, wherein each round record includes the dialogue characters, dialogue content, and corresponding intent;

[0020] Current task information corresponding to the intent type and interruption status includes task identifier, task status, and execution progress;

[0021] User information corresponding to the current user;

[0022] The speaker identifier corresponding to the semantic role is used to identify whether the speaker at the time of the interruption is a user or a system.

[0023] In some embodiments, the dialogue recovery request includes an active recovery request and a passive recovery request;

[0024] The active recovery request is triggered by the user through voice command or touch operation, while the passive recovery request is automatically triggered by the system when it detects preset recovery conditions, which include system restart completion, network connection restoration, or application restart.

[0025] In some embodiments, the context reconstruction includes a semantic completion process, specifically including:

[0026] Based on the session identifier and breakpoint identifier in the context snapshot, locate the corresponding breakpoint;

[0027] Based on the dialogue history in the context snapshot, restore the dialogue context before the interruption;

[0028] Based on the current task information in the context snapshot, restore the task execution status and execution progress;

[0029] The current speaker is determined based on the semantic roles in the context snapshot;

[0030] Based on the restored dialogue context, task execution state, and current speaker, the state of the dialogue management state machine is reconstructed. The dialogue management state machine includes a waiting for user input state, a task execution state, and a TTS broadcast state.

[0031] In some embodiments, the semantic completion process further includes fault tolerance processing to ensure the continued execution of the reconstruction process under the following abnormal scenarios, specifically including:

[0032] When the dialogue history in the context snapshot is missing or corrupted, the most recent N rounds of dialogue records are retrieved from the dialogue history storage module according to the dialogue rounds in the semantic tagging information.

[0033] When the current task information in the context snapshot is missing or corrupted, the current task information is retrieved again from the task management module according to the intent type and interruption status in the semantic tagging information.

[0034] When the semantic roles in the context snapshot are missing or corrupted, the current speaker is re-determined based on the semantic roles in the semantic tagging information;

[0035] When user information in the context snapshot is missing or corrupted, the user identity information is retrieved again based on the current user login status.

[0036] In some embodiments, based on the result of context reconstruction, the dialogue management state machine is controlled to perform state transitions to resume execution from the dialogue node at the time of the interruption event, specifically including:

[0037] Based on the task execution status and progress recovered in the context reconstruction, determine the current execution stage of the task;

[0038] Based on the current speaker determined in the context reconstruction, determine the starting state of the state transition;

[0039] Based on the dialogue context recovered during the context reconstruction and the current task information, determine the target state for state transition;

[0040] Based on the initial state and the target state, the dialogue management state machine is driven to perform state transitions, which include the following five core state transitions:

[0041] The process transitions from the waiting for user input state to the task execution state, allowing the interrupted task to resume.

[0042] The task execution state transitions to the user input waiting state, which is used to wait for user confirmation or additional information.

[0043] The process transitions from the task execution state to the TTS broadcast state, which is used to broadcast the task execution results to the user.

[0044] The system transitions from a TTS broadcast state to a waiting-for-user-input state to await user response.

[0045] The process transitions from TTS broadcast status to task execution status, allowing for the continuation of subsequent tasks.

[0046] After the state transition is completed, the dialogue management state machine resumes execution from the dialogue node at the time the interruption event occurred.

[0047] In some embodiments, for weak network environments, the method further includes the following optimization measures:

[0048] When generating the context snapshot, a local caching priority strategy is adopted, which prioritizes storing the context snapshot in the vehicle's local storage module and asynchronously backs it up to cloud storage when the network connection is restored.

[0049] During the context reconstruction process, if a network connection anomaly is detected, the context snapshot is read from the vehicle's local storage module, and the semantic completion process is executed using an offline semantic parsing engine.

[0050] After execution resumes, if network connectivity is detected to be restored, the dialogue history and task execution status are automatically synchronized to cloud storage, and the state of the dialogue management state machine is updated.

[0051] In some embodiments, for multi-user scenarios, the method further includes the following features:

[0052] When generating the semantic tagging information, the user identifier of the current user is obtained through the voiceprint recognition module, and the user identifier is used as the user information in the semantic tagging information;

[0053] The context snapshot records personalized conversation preferences and task execution history corresponding to the user identifier;

[0054] During the context reconstruction process, the corresponding dialogue strategy and task execution parameters are loaded from the personalized configuration database based on the user identifier;

[0055] After execution resumes, the personalized dialogue preferences and task execution history are updated based on the user identifier, and the response strategy of the dialogue management state machine is adjusted based on the personalized configuration.

[0056] The present invention has the following beneficial effects:

[0057] This invention discloses a method for interrupting and resuming full-duplex voice dialogue in vehicles. When a user interruption command meeting preset conditions is detected during a dialogue, semantic tagging information is generated and a context snapshot is created. When a dialogue resumption request is received, the context snapshot is retrieved based on the semantic tagging information, and context reconstruction is performed. The dialogue management state machine is controlled to perform state transitions, resuming execution from the interruption point. This invention, through semantic tagging and context snapshot mechanisms, achieves accurate saving and seamless recovery of the dialogue state, solving the problems of context loss and chaotic recovery logic caused by interruptions in existing technologies. Attached Figure Description

[0058] Figure 1 A flowchart illustrating a full-duplex dialogue interruption and recovery method for in-vehicle voice interaction provided in an embodiment of the present invention;

[0059] Figure 2 This invention provides an active recovery context backtracking timing diagram.

[0060] Figure 3 This is a schematic diagram of the optimization measures for weak network environments provided in an embodiment of the present invention;

[0061] Figure 4 This is a schematic diagram of a process optimized for multi-user scenarios provided in an embodiment of the present invention;

[0062] Figure 5 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0063] To enable those skilled in the art to better understand the technical solutions of the present invention, exemplary embodiments of the present invention are described below in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0064] Where there is no conflict, the various embodiments of the present invention and the features thereof may be combined with each other.

[0065] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0066] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Terms such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0067] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having the meaning consistent with their meaning in the context of the relevant art and the invention, and will not be interpreted as having an idealized or overly formal meaning unless expressly so defined herein.

[0068] In the technical solution of this invention, the collection, storage, use, processing, transmission, provision, and disclosure of user personal information all comply with relevant laws and regulations and do not violate public order and good morals. The use of user data in this technical solution follows relevant national laws and regulations (e.g., the "Information Security Technology - Personal Information Security Specification"). For example: appropriate measures are taken for personal information access control; restrictions are imposed on the display of personal information; the purpose of using personal information does not exceed the scope of direct or reasonable association; and explicit identity targeting is eliminated when using personal information to avoid precisely locating a specific individual.

[0069] To address at least one of the technical problems existing in the aforementioned related technologies, the present invention provides a method for interrupting and resuming full-duplex dialogue in in-vehicle voice interaction. Figure 1 A flowchart illustrating a full-duplex dialogue interruption and recovery method for in-vehicle voice interaction provided by an embodiment of the present invention includes the following steps:

[0070] S1. In response to detecting a user interruption command that meets preset conditions during the dialogue, a dialogue interruption event is triggered;

[0071] S2. Generate semantic tagging information corresponding to the interruption event, and generate a context snapshot containing dialogue history and execution state based on the semantic tagging information;

[0072] S3. When a dialogue resumption request is received, the context snapshot is retrieved based on the semantic tagging information, and context reconstruction is performed based on the retrieved context snapshot;

[0073] S4. Based on the result of context reconstruction, control the dialogue management state machine to perform state transitions to resume execution from the dialogue node at the time of the interruption event.

[0074] This invention utilizes two core mechanisms: "semantic tagging information" and "context snapshot." The system can capture a "high-fidelity snapshot" of the dialogue process, containing all key parameters, ensuring that the interruption is completely preserved and laying a data foundation for accurate recovery. By clearly dividing the recovery process into three core stages—"recovery request triggering," "context reconstruction," and "state transition recovery"—the logic is clear and the responsibilities are well-defined, transforming the recovery process from a temporary and error-prone response into a controllable and reliable system behavior.

[0075] The following description uses a specific embodiment to illustrate the technology in a particular scenario and with specific parameters.

[0076] Scenario Description: A user is driving and interacting with the navigation system. While the system is providing route details, the user temporarily interrupts to inquire about the weather and then requests navigation to resume.

[0077] Detailed implementation process:

[0078] S1. Interrupt detection and triggering:

[0079] The system announced: "Three routes have been planned for you. The first route passes through the Third Ring Road..."

[0080] User interrupted: "Pause, what's the weather like today?" (Voice energy -38dB, duration 300ms, containing the keyword "pause").

[0081] The system detects an interrupt command that meets preset conditions and immediately triggers a dialogue interruption event.

[0082] S2. Semantic Tagging and Snapshot Storage:

[0083] The system instantly generates semantic tagging information (including session_id, interrupt_point_id, intent_type: navigation, interrupt_state: tts_playing, etc.).

[0084] Based on this, the system generates a context snapshot within ≤50ms, which includes the current broadcast content, progress (60%), dialogue history, etc., and persists it for storage.

[0085] S3. Resumption Trigger and Context Reconstruction:

[0086] After the system answered the weather question, the user said, "Continue with the navigation."

[0087] The system has received this recovery request.

[0088] The system retrieves the corresponding context snapshot based on the previously stored semantic tagging information and performs context reconstruction to accurately restore the state to "navigation intent, TTS broadcasting in progress, progress 60%".

[0089] S4. State Transition and Dialogue Resumption:

[0090] The system controls the dialogue management state machine to perform state transitions, switching from the "processing weather query" state back to the "TTS broadcast" state.

[0091] The system resumed execution from the interruption point and continued broadcasting: "...After passing the Third Ring Road, we will enter the Airport Expressway, with an estimated total journey time of 45 minutes."

[0092] In some embodiments, the preset conditions include at least one of the following conditions:

[0093] The detected voice command successfully matched a keyword in the preset interruption keyword library;

[0094] The detected voice signal energy exceeds the preset energy threshold and the duration reaches the preset time threshold.

[0095] In the above embodiments, the introduction of a dual-judgment mechanism significantly improves the accuracy and reliability of interruption detection in complex in-vehicle noise environments, effectively reducing the false trigger rate. Specifically: keyword matching ensures the clarity of the interruption intent, avoiding misjudging ordinary statements in daily conversations as interruption commands; energy-duration dual-threshold judgment ensures the signal validity of the interruption behavior, effectively filtering out brief, sudden noises (such as the sound of a car door closing or a horn honking). Only when the voice signal strength is sufficient and lasts for a certain period of time is it considered a valid user interruption attempt.

[0096] The following are preferred settings for the energy threshold and time threshold in the preset conditions provided in this embodiment.

[0097] Preset energy threshold: Determined based on extensive testing of typical in-vehicle ambient noise levels. Test scenarios included urban roads (noise approximately 65dB), highways (noise approximately 75dB), and underground parking lots (noise approximately 50dB). Statistical analysis showed that setting the energy threshold to -45dB effectively distinguished between valid user voice commands (energy typically above -45dB) and ambient background noise (energy typically below -50dB) in over 90% of the test scenarios.

[0098] Preset time threshold: set to 200 milliseconds. This duration is sufficient to filter out most transient impact noises (such as bumps, falling objects, etc., which usually last less than 100 milliseconds), while ensuring a rapid response to the first words of a user's normal speech (whose energy stability usually lasts for more than 200 milliseconds).

[0099] The following is a detailed workflow of an interrupt provided in this embodiment:

[0100] After the vehicle-mounted microphone array acquires the voice signal, the system performs two judgments in parallel:

[0101] Automatic speech recognition (ASR: Automatic Speech Recognition, refers to the technology of converting human speech signals into text, supporting real-time streaming recognition and offline recognition) is performed to convert speech into text and determine whether the text contains words from a preset interruption keyword library (such as "pause", "stop" etc.).

[0102] At the same time, the strength of the voice signal is monitored to determine whether it exceeds the -45dB threshold for 200 consecutive milliseconds.

[0103] If at least one of the above two conditions is met, the system will determine it as a valid interrupt instruction and trigger subsequent semantic marking and interrupt procedures.

[0104] In some embodiments, the semantic tagging information includes session ID, breakpoint ID, dialogue round, semantic role, intent type, and break status;

[0105] The session ID is used to uniquely identify a complete dialogue session; the interruption point ID is generated by combining the session ID and the dialogue round, and is used to uniquely identify an interruption event within the session; the semantic role is used to distinguish whether the speaker at the time of interruption is a user or the system; the intent type is used to identify the core task category of the interrupted dialogue; and the interruption state is used to characterize the operation phase that the system is executing at the time of interruption.

[0106] In some embodiments, the context snapshot includes the following content determined by the semantic tagging information:

[0107] The session identifier corresponding to the session ID;

[0108] The interrupt point identifier corresponding to the interrupt point ID;

[0109] The most recent N rounds of dialogue history corresponding to the aforementioned dialogue round, wherein each round record includes the dialogue characters, dialogue content, and corresponding intent;

[0110] Current task information corresponding to the intent type and interruption status includes task identifier, task status, and execution progress;

[0111] User information corresponding to the current user;

[0112] The speaker identifier corresponding to the semantic role is used to identify whether the speaker at the time of the interruption is a user or a system.

[0113] In the above embodiments, by defining six-element semantic tags (session ID, breakpoint ID, dialogue turn, semantic role, intent type, and breakpoint state), the system can take a "snapshot" of the dialogue process containing all key parameters, ensuring that the complete scene of the breakpoint can be accurately located during recovery, thus solving the problem of context loss or ambiguous location in the prior art. By clarifying that the content of the context snapshot is directly determined by the semantic tag information, this design makes the recovery process no longer a simple "replay," but an intelligent reconstruction based on structured data. The system can automatically understand which task needs to be recovered, from which node to start, and in what state to continue, greatly reducing the need for manual intervention by the user.

[0114] The following description, based on a specific technical scenario and parameters, uses a concrete example.

[0115] Scenario description: While the vehicle is in motion, the driver is having a navigation conversation with the system. When the system is announcing the route (third round of conversation), the user interrupts the conversation and instructs the user to adjust the air conditioning.

[0116] The specific implementation process is as follows:

[0117] (1) Triggering interrupts and generating semantic tags

[0118] When the user said "Pause, turn on the air conditioner to 24 degrees", the system detected that the voice energy was -35dB (exceeding the -45dB threshold) and lasted for 250ms. It also recognized the keyword "pause" and determined it to be a valid interruption.

[0119] The system immediately generates semantic tagging information, a specific example of which is as follows:

[0120] Session ID (session_id):

[0121] "session_123e4567-e89b-12d3-a456-426614174000" (Globally unique identifier for this navigation session)

[0122] Interrupt point ID: "session_123e4567_3" (composed of the session ID and the 3rd round of dialogue, uniquely identifying this interrupt point within the session)

[0123] Dialogue turn: 3 (The interruption occurred precisely in the 3rd dialogue turn).

[0124] Semantic role: "assistant" (precisely records when the system is speaking during an interruption)

[0125] Intent type: "navigation" (This explicitly states that the core task being interrupted is navigation)

[0126] Interrupt state: "tts_playing" (Accurately records whether the system was in the TTS playback phase when the interrupt occurred)

[0127] This step uniquely and precisely defines the "5W1H" (when, where, who, what, and what state) of the interruption event, providing an indisputable basis for tracing the source of subsequent recovery.

[0128] (2) Build a context snapshot

[0129] Based on the semantic tagging information generated in (1), the system automatically constructs a structured context snapshot. This snapshot is a data object containing multiple fields, the content of which is directly determined or generated by association with the corresponding fields in the semantic tagging information, specifically including:

[0130] Session and interruption identifiers: Identifiers recorded in the snapshot that completely correspond to the session ID and interruption point ID in the semantic tagging information, ensuring that the snapshot is uniquely bound to a specific dialogue session and interruption event.

[0131] Dialogue History: The system extracts the most recent N rounds (default N=5, configurable) of interaction records from the dialogue history based on the dialogue rounds in the semantic tagging information. Each round record contains three key elements: dialogue role (user or system), dialogue content (raw text), and corresponding intent.

[0132] Task status information: The snapshot saves the current task details corresponding to the intent type and interruption status in the semantic tagging information. This includes the task's unique identifier, task status (such as in TTS broadcast, task in progress), and specific execution progress (e.g., voice broadcast is 60% complete).

[0133] User identity information: The snapshot also records the identity information corresponding to the current user, which usually includes the user ID obtained through the voiceprint recognition module and the user role (such as driver and passenger).

[0134] After the context snapshot is generated, it is persisted using a dual strategy of "local caching first, cloud storage backup". The snapshot is first stored in the vehicle's local cache (such as Redis, with an expiration time set to 30 minutes) to ensure fast reading in weak network or offline environments; then, when network conditions permit, it is asynchronously backed up to the cloud object storage service to prevent data loss due to factors such as vehicle restart.

[0135] In some embodiments, the dialogue recovery request includes an active recovery request and a passive recovery request;

[0136] The active recovery request is triggered by the user through voice command or touch operation, while the passive recovery request is automatically triggered by the system when it detects preset recovery conditions, which include system restart completion, network connection restoration, or application restart.

[0137] In the above embodiments, by supporting explicit "active recovery requests" (such as "continue"), the user's interaction intent is respected, and a direct sense of control is provided. Through the "passive recovery request" mechanism, the system can automatically judge and trigger recovery after specific conditions are met (such as short task completion), reducing redundant user commands and making the interaction process smoother and more "seamless". The mechanism that combines active and passive approaches can flexibly adapt to scenarios ranging from explicit user-led scenarios to system-assisted automated scenarios, thereby enhancing the practical application value of the solution.

[0138] In some embodiments, the context reconstruction includes a semantic completion process, specifically including:

[0139] Based on the session identifier and breakpoint identifier in the context snapshot, locate the corresponding breakpoint;

[0140] Based on the dialogue history in the context snapshot, restore the dialogue context before the interruption;

[0141] Based on the current task information in the context snapshot, restore the task execution status and execution progress;

[0142] The current speaker is determined based on the semantic roles in the context snapshot;

[0143] Based on the restored dialogue context, task execution state, and current speaker, the state of the dialogue management state machine is reconstructed. The dialogue management state machine includes a waiting for user input state, a task execution state, and a TTS broadcast state.

[0144] In the above embodiments, through the semantic completion process, the system can accurately restore the dialogue state, task progress and speaking role at the moment of interruption based on the structured context snapshot, and achieve "seamless resume" from the breakpoint, rather than a simple restart, which greatly improves the smoothness of the user experience.

[0145] See Figure 2 The diagram shown illustrates a sequence diagram for an active context recovery backtracking method provided in an embodiment of the present invention. The process includes:

[0146] In response to a user interruption command that meets preset conditions detected during the conversation → the user issues a resumption command.

[0147] When a dialogue resumption request is received → the ASR module passes the recognized text to the DM (DialogManagement, which refers to the technology of tracking the context of multi-turn dialogues, disambiguating intents, and filling slots, and supports end-to-end cloud collaborative dialogue state management) module;

[0148] Based on the semantic tagging information, retrieve the context snapshot → CR module (i.e., context backtracking module) queries SMS module (i.e., semantic tagging storage module) to obtain the snapshot;

[0149] Controlling the dialogue management state machine to perform state transitions → State interaction between the DM module and the DSM module;

[0150] The context snapshot includes the following content determined by the semantic tagging information: structured snapshot data returned by the SMS module;

[0151] Session identifier, breakpoint identifier, conversation history, etc. → Complete contextual information contained in the snapshot.

[0152] The dialogue resumption request includes an active resumption request—the user actively triggers the resumption via voice command.

[0153] The recovery command is actively triggered by the user via voice command or touch operation → The ASR module recognizes and processes the recovery command.

[0154] The context reconstruction includes a semantic completion process → the CR module calls NLU for completion parsing.

[0155] Based on the semantic roles in the context snapshot, determine the current speaker → Snapshot-based reconstruction logic

[0156] Rebuild the state of the dialogue management state machine → State machine transition control.

[0157] In some embodiments, the semantic completion process further includes fault tolerance processing to ensure the continued execution of the reconstruction process under the following abnormal scenarios, specifically including:

[0158] When the dialogue history in the context snapshot is missing or corrupted, the most recent N rounds of dialogue records are retrieved from the dialogue history storage module according to the dialogue rounds in the semantic tagging information.

[0159] When the current task information in the context snapshot is missing or corrupted, the current task information is retrieved again from the task management module according to the intent type and interruption status in the semantic tagging information.

[0160] When the semantic roles in the context snapshot are missing or corrupted, the current speaker is re-determined based on the semantic roles in the semantic tagging information;

[0161] When user information in the context snapshot is missing or corrupted, the user identity information is retrieved again based on the current user login status.

[0162] In the above embodiments, the defined fault-tolerant processing mechanism ensures that even in the event of partial loss or corruption of snapshot data, the system can still reconstruct the data using backup data sources (such as semantic tagging information and online modules). This significantly reduces the probability of recovery failure due to data issues and guarantees service continuity. This mechanism, through localized and structured data processing, reduces real-time reliance on cloud services or complex calculations (especially in fault-tolerant mode), thereby reducing system load and controlling the average response time for dialogue recovery to within 300 milliseconds, meeting the real-time requirements of in-vehicle scenarios.

[0163] The following description uses a specific embodiment to illustrate the technology in a particular scenario and with specific parameters.

[0164] The scenario describes a driver navigating to the airport when the system interrupts the navigation (third round of conversation) while the system is announcing the route. After the user adjusts the air conditioning, the system attempts to resume navigation but discovers that the stored context snapshot of the "conversation history" is corrupted due to a momentary malfunction in the vehicle's infotainment system.

[0165] The specific implementation process is as follows:

[0166] Semantic completion:

[0167] After receiving the recovery command, the system initiates the semantic completion process:

[0168] Locating the interruption point: The system reads session_id: "session_123e4567" and interrupt_point_id: "session_123e4567_3" from the snapshot and accurately locates the interruption point of the third round of dialogue.

[0169] Restore the dialog context: The system attempts to read the dialog_history from the snapshot, but finds that the field is corrupted. At this point, the fault tolerance mechanism of claim 7 is triggered (see step 2).

[0170] Restore task status: The system reads the current_task_info from the snapshot and successfully obtains task_id: "nav_001", task_status: "tts_playing", and progress: "60%". Based on this, the system determines that it needs to continue from the 60% progress point indicated in the navigation broadcast.

[0171] Determine the speaker: The system reads the semantic_role "assistant" from the snapshot, confirming that the system was speaking when the interruption occurred, so the system should continue broadcasting after the interruption.

[0172] Reconstructing the state machine: Based on the above information, the system reconstructs the dialogue management state machine to the TTS broadcast state and associates it with the navigation task nav_001.

[0173] This completion process fully digitizes and structures the decision information needed to restore the context (where to start, what to continue, and who to say it), making the restoration action precise and reliable, and increasing the context restoration success rate to 92%.

[0174] Fault tolerance:

[0175] When corrupted history is detected during the "Restore Dialogue Context" step, the system performs fault tolerance processing:

[0176] Based on the semantic tag information dialog_turn: 3, the system initiates a new query request to the dialogue history storage module. Based on the session_id and round information, the module returns the complete dialogue history of the last 5 rounds (including the user command "navigate to the airport" and the system response) within 100 milliseconds.

[0177] This fault tolerance mechanism ensures that the success rate of the recovery process remains above 85% even when the snapshot data is incomplete (in contrast, without a fault tolerance mechanism, such anomalies would cause the recovery to fail directly).

[0178] The fault tolerance mechanism provides a "safety net" for the semantic completion process. Through multi-path data backup and verification, it significantly enhances the system's anti-interference capability and reduces the recovery failure rate caused by data anomalies from 15% to 3%.

[0179] The system utilizes the complete context obtained after completion and fault tolerance to drive the state machine to continue execution from the TTS broadcast state, seamlessly continuing the broadcast of the navigation route. The interruption recovery process perceived by the user is smooth and natural.

[0180] In some embodiments, based on the result of context reconstruction, the dialogue management state machine is controlled to perform state transitions to resume execution from the dialogue node at the time of the interruption event, specifically including:

[0181] Based on the task execution status and progress recovered in the context reconstruction, determine the current execution stage of the task;

[0182] Based on the task execution state recovered during the context reconstruction and the determined current speaker, the starting state of the state transition is determined comprehensively.

[0183] Based on the dialogue context recovered during the context reconstruction and the current task information, determine the target state for state transition;

[0184] Based on the initial state and the target state, the dialogue management state machine is driven to perform state transitions, which include the following five core state transitions:

[0185] The process transitions from the waiting for user input state to the task execution state, allowing the interrupted task to resume.

[0186] The task execution state transitions to the user input waiting state, which is used to wait for user confirmation or additional information.

[0187] The process transitions from the task execution state to the TTS broadcast state, which is used to broadcast the task execution results to the user.

[0188] The system transitions from a TTS broadcast state to a waiting-for-user-input state to await user response.

[0189] The process transitions from TTS broadcast status to task execution status, allowing for the continuation of subsequent tasks.

[0190] After the state transition is completed, the dialogue management state machine resumes execution from the dialogue node at the time the interruption event occurred.

[0191] In the above embodiments, by explicitly defining five core state transition paths, it is ensured that regardless of the stage of the dialogue where the interruption occurs (user listening, system broadcasting, task execution), the recovery process follows a preset and reasonable state transition logic, completely avoiding state confusion or jump errors, and making system behavior highly predictable. The system can "understand" the dialogue context before the interruption and select the most appropriate recovery starting point based on this context. For example, whether to start from "continue broadcasting" or "wait for user confirmation." This mimics the ability of humans to naturally continue topics in conversation. The state-based recovery mechanism allows the system to accurately initialize the required service modules (such as the TTS engine and task executor), avoiding unnecessary resource loading and initialization processes. Testing has shown that this mechanism stabilizes the response time for state recovery and task continuation within 300 milliseconds, meeting the stringent real-time requirements of the in-vehicle environment.

[0192] The following description uses a specific embodiment to illustrate the technology in a particular scenario and with specific parameters.

[0193] Scenario Description: User command: "Turn on the air conditioning and navigate to the airport." The system first executes the task of turning on the air conditioning, and then begins to broadcast the navigation route via TTS. When broadcasting "The first route passes through the Third Ring Road, and the estimated travel time is 45 minutes" (TTS broadcast status, progress 60%), the user interrupts and says "Pause for a moment."

[0194] The recovery process is as follows:

[0195] Context reconstruction results input: After the user says "Continue navigation", the system completes context reconstruction and the output results include:

[0196] Task execution status: tts_playing (TTS broadcasting in progress)

[0197] Execution progress: 60%

[0198] Current speaker: assistant (system)

[0199] Intent type: navigation

[0200] State transition decision and execution:

[0201] Determine the starting and target states: Based on the reconstruction results, the system determines that it is currently in the TTS broadcasting state, and the goal of recovery is to continue broadcasting navigation information. According to the defined migration path, at this time, the system should trigger the transition from the TTS broadcasting state to the task execution state to continue executing subsequent tasks.

[0202] Driving state machine transition: Based on this instruction, the dialogue management state machine transitions from the TTS broadcast state to the task execution state. During this process, the state machine carries key contextual information (such as the broadcast content index and progress position).

[0203] Precise resumption of execution: After entering task execution state, the system does not restart the navigation process. Instead, it precisely calls the TTS engine from the last interrupted node (60% progress) to continue broadcasting the remaining navigation information. System output: "...After passing the Third Ring Road, via the Airport Expressway, the entire journey takes 45 minutes. Navigation for you will now begin."

[0204] In the above embodiments, the recovery process is extremely efficient because the state machine avoids re-performing semantic parsing and task planning from the dialogue starting point (such as "turn on the air conditioner").

[0205] See Figure 3 As shown, in some embodiments, the method further includes the following optimization measures for weak network environments:

[0206] When generating the context snapshot, a local caching priority strategy is adopted, which prioritizes storing the context snapshot in the vehicle's local storage module and asynchronously backs it up to cloud storage when the network connection is restored.

[0207] During the context reconstruction process, if a network connection anomaly is detected, the context snapshot is read from the vehicle's local storage module, and the semantic completion process is executed using an offline semantic parsing engine.

[0208] After execution resumes, if network connectivity is detected to be restored, the dialogue history and task execution status are automatically synchronized to cloud storage, and the state of the dialogue management state machine is updated.

[0209] In the above embodiments, by prioritizing the storage of key context snapshots locally in the vehicle and introducing an offline semantic parsing engine, the core interaction link of dialogue interruption and resumption can still operate independently even in the event of a complete network outage (such as in underground parking lots or remote areas), improving the functional availability in weak network environments. The path between local storage and computation is much shorter than that to the cloud, reducing the latency of reading and parsing context snapshots from the common 1-2 seconds in weak network conditions to a stable less than 100 milliseconds, making users almost unaware of the stuttering caused by network fluctuations and achieving a smooth "offline" recovery experience. Through an asynchronous backup mechanism, local data is automatically synchronized to the cloud after the network is restored, which not only avoids write failures in weak network conditions but also ensures the integrity and traceability of dialogue history, providing a data foundation for multi-device synchronization and big data analysis.

[0210] The following description uses a specific embodiment to illustrate the technology in a particular scenario and with specific parameters.

[0211] Scenario description: The vehicle enters an underground parking lot with extremely poor network signal. The user is listening to the system's navigation information when the navigation is interrupted. The user then operates on the vehicle settings. After the operation is completed, the user requests that the navigation be restored.

[0212] The specific implementation process is as follows:

[0213] Interrupts and Local Storage:

[0214] When a user's connection is interrupted, the system detects that the network signal strength is below -95dBm and determines it to be a weak network environment.

[0215] The system immediately implements optimization measures: the generated context snapshot (approximately 5KB in size) is prioritized and stored only in the vehicle's local ROM storage, with a write time of ≤20ms. The system records a "pending synchronization to cloud" status.

[0216] Offline recovery execution:

[0217] After the user issues the "continue navigation" command, the system detects that the network is still unavailable.

[0218] The system does not wait for the network and directly reads the context snapshot from the local ROM, which takes ≤30ms.

[0219] The system calls the built-in offline semantic parsing engine (which occupies about 50MB of memory) to reconstruct the context, and the parsing time is ≤150ms.

[0220] The entire recovery process, from the end of the command to the start of the system's resuming broadcast, has a total response time of ≤200ms, providing a user experience identical to when online.

[0221] Network recovery and asynchronous synchronization:

[0222] Once the vehicle leaves the parking lot, the network is restored. The system detects the network connection in the background and automatically synchronizes the locally stored context snapshot and recovery records to the cloud with a delay (set to within 30 seconds), completing the data archiving.

[0223] See Figure 4 As shown, in some embodiments, for multi-user scenarios, the method further includes the following features:

[0224] When generating the semantic tagging information, the user identifier of the current user is obtained through the voiceprint recognition module, and the user identifier is used as the user information in the semantic tagging information;

[0225] The context snapshot records personalized conversation preferences and task execution history corresponding to the user identifier;

[0226] During the context reconstruction process, the corresponding dialogue strategy and task execution parameters are loaded from the personalized configuration database based on the user identifier;

[0227] After execution resumes, the personalized dialogue preferences and task execution history are updated based on the user identifier, and the response strategy of the dialogue management state machine is adjusted based on the personalized configuration.

[0228] In the above embodiments, through voiceprint recognition technology, the system can accurately distinguish the commands of different users such as the driver and passenger, ensuring that each user maintains an independent and pure dialogue context, which will improve the accuracy of context recovery in multi-user scenarios. Based on user identity, the system can load and apply their exclusive dialogue style preferences, commonly used function settings, etc. (such as the driver prefers concise broadcasts, and the passenger prefers detailed explanations), making the interactive experience more personalized. Through identity differentiation, the permissions of different users can be associated (such as only the driver can operate vehicle driving-related settings), avoiding the risk of misoperation and meeting the high security requirements of the in-vehicle system.

[0229] The following description uses a specific embodiment to illustrate the technology in a particular scenario and with specific parameters.

[0230] Scenario Description: Driver A is setting navigation to the office. During the journey, passenger B interrupts to ask about the weather. Driver A then requests to resume their navigation conversation.

[0231] The specific implementation process is as follows:

[0232] User differentiation and contextual tagging:

[0233] User A (driver) says, "Navigate to XX company." The voiceprint recognition module extracts voice features in real time and identifies user_id: "driver_001" with a confidence level of 98%. The system generates and stores semantic tags and context snapshots bound to this ID.

[0234] User B (passenger) interrupts, saying, "How's the weather today?" The voiceprint recognition module identifies a distinct voiceprint feature: user_id: "passenger_001". The system immediately creates a snapshot of driver_001's navigation conversation and pauses it, then processes passenger_001's weather request.

[0235] Personalized recovery:

[0236] User A says, "Continue the navigation." Voiceprint recognition confirms the user's identity as driver_001.

[0237] Based on this user_id, the system accurately retrieves and loads the context snapshot (including the context of navigation to the company) that is specific to driver_001.

[0238] At the same time, the system loads the preference settings of driver_001 from the personalized configuration database, such as "broadcast mode: concise", and applies them to this recovery session.

[0239] Precise recovery execution:

[0240] The system is based on the independent context of driver_001, and the navigation broadcast can be seamlessly resumed from the point of interruption. The broadcast style is in line with its "simple" preference.

[0241] User B's (passenger_001) weather query context is fully preserved and does not interfere with each other. The entire user switching and recovery response time is ≤100ms.

[0242] Based on the same inventive concept, embodiments of the present invention also provide an in-vehicle full-duplex voice dialogue interruption and recovery system, including:

[0243] The semantic tagging module is used to generate semantic tagging information in response to the detection of a user interruption command that meets preset conditions during the dialogue.

[0244] The context snapshot module is used to create a context snapshot based on the semantic tagging information;

[0245] The context reconstruction module is used to retrieve the context snapshot based on the semantic tagging information and perform context reconstruction when a dialogue resumption request is received.

[0246] The state machine management module is used to control the dialogue management state machine to perform state transitions and resume execution from the point of interruption.

[0247] In some embodiments, the system further includes:

[0248] The voiceprint recognition module is used to obtain the current user's identifier through voiceprint recognition.

[0249] The personalized configuration module is used to store and manage personalized dialogue preferences and task execution parameters corresponding to user identifiers;

[0250] An offline semantic parsing engine is used to perform semantic completion when network connectivity is abnormal.

[0251] Based on the same inventive concept, embodiments of the present invention also provide an electronic device. Figure 5 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Figure 5 As shown, an embodiment of the present invention provides an electronic device including: one or more processors 101, a memory 102, and one or more I / O interfaces 103. The memory 102 stores one or more programs, which, when executed by the one or more processors, enable the one or more processors to implement a full-duplex dialogue interruption and recovery method for in-vehicle voice interaction as described in any of the above embodiments; the one or more I / O interfaces 103 are connected between the processor and the memory, configured to enable information interaction between the processor and the memory.

[0252] The processor 101 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 102 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read / write interface) 103 is connected between the processor 101 and the memory 102, and can realize information interaction between the processor 101 and the memory 102, including but not limited to a data bus (Bus).

[0253] In some embodiments, the processor 101, memory 102, and I / O interface 103 are interconnected via bus 104, and thus connected to other components of the computing device.

[0254] In some embodiments, the one or more processors 101 include a field-programmable gate array.

[0255] This invention also provides a computer-readable medium. The computer-readable medium stores a computer program, which, when executed by a processor, implements a full-duplex dialogue interruption and resumption method for in-vehicle voice interaction as described in any of the above embodiments. The computer-readable storage medium can be volatile or non-volatile.

[0256] This invention also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code. When the computer-readable code is run in the processor of an electronic device, the processor in the electronic device executes any of the above-described methods for full-duplex dialogue interruption and recovery in in-vehicle voice interaction.

[0257] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0258] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0259] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0260] The computer program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing state information from the computer-readable program instructions. This electronic circuitry can execute the computer-readable program instructions to implement various aspects of the invention.

[0261] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0262] Various aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0263] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0264] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0265] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0266] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of the invention as set forth in the appended claims.

Claims

1. A method for interrupting and resuming full-duplex dialogue in in-vehicle voice interaction, characterized in that, Includes the following steps: In response to the detection of a user interruption command that meets preset conditions during the conversation, a conversation interruption event is triggered; Generate semantic tagging information corresponding to the interruption event, and generate a context snapshot containing dialogue history and execution state based on the semantic tagging information; When a dialogue resumption request is received, the context snapshot is retrieved based on the semantic tagging information, and context reconstruction is performed based on the retrieved context snapshot; Based on the results of context reconstruction, the control dialogue management state machine performs state transitions to resume execution from the dialogue node at the time the interruption event occurred.

2. The method according to claim 1, characterized in that, The preset conditions include at least one of the following conditions: The detected voice command successfully matched a keyword in the preset interruption keyword library; The detected voice signal energy exceeds the preset energy threshold and the duration reaches the preset time threshold.

3. The method according to claim 1, characterized in that, The semantic tagging information includes session ID, breakpoint ID, dialogue round, semantic role, intent type, and break status; The session ID is used to uniquely identify a complete dialogue session. The interruption point ID is generated by combining the session ID and the dialogue round and is used to uniquely identify an interruption event within the session. The semantic role is used to distinguish whether the speaker at the time of interruption is a user or the system. The intent type is used to identify the core task category of the interrupted dialogue. The interruption status is used to characterize the operation phase that the system is executing at the time of interruption.

4. The method according to claim 3, characterized in that, The context snapshot contains the following content determined by the semantic tagging information: The session identifier corresponding to the session ID; The interrupt point identifier corresponding to the interrupt point ID; The most recent N rounds of dialogue history corresponding to the aforementioned dialogue round, wherein each round record includes the dialogue characters, dialogue content, and corresponding intent; Current task information corresponding to the intent type and interruption status includes task identifier, task status, and execution progress; User information corresponding to the current user; The speaker identifier corresponding to the semantic role is used to identify whether the speaker at the time of the interruption is a user or a system.

5. The method according to claim 4, characterized in that, The dialogue resumption request includes active resumption requests and passive resumption requests; The active recovery request is triggered by the user through voice command or touch operation, while the passive recovery request is automatically triggered by the system when it detects preset recovery conditions, which include system restart completion, network connection restoration, or application restart.

6. The method according to claim 4, characterized in that, The context reconstruction includes a semantic completion process, specifically including: Based on the session identifier and breakpoint identifier in the context snapshot, locate the corresponding breakpoint; Based on the dialogue history in the context snapshot, restore the dialogue context before the interruption; Based on the current task information in the context snapshot, restore the task execution status and execution progress; The current speaker is determined based on the semantic roles in the context snapshot; Based on the restored dialogue context, task execution state, and current speaker, the state of the dialogue management state machine is reconstructed. The dialogue management state machine includes a waiting for user input state, a task execution state, and a TTS broadcast state.

7. The method according to claim 6, characterized in that, The semantic completion process also includes fault tolerance processing to ensure the continued execution of the reconstruction process under the following abnormal scenarios, specifically including: When the dialogue history in the context snapshot is missing or corrupted, the most recent N rounds of dialogue records are retrieved from the dialogue history storage module according to the dialogue rounds in the semantic tagging information. When the current task information in the context snapshot is missing or corrupted, the current task information is retrieved again from the task management module according to the intent type and interruption status in the semantic tagging information. When the semantic roles in the context snapshot are missing or corrupted, the current speaker is re-determined based on the semantic roles in the semantic tagging information; When user information in the context snapshot is missing or corrupted, the user identity information is retrieved again based on the current user login status.

8. The method according to claim 6, characterized in that, Based on the context reconstruction results, the dialogue management state machine is controlled to perform state transitions to resume execution from the dialogue node at the time of the interruption event, specifically including: Based on the task execution status and progress recovered in the context reconstruction, determine the current execution stage of the task; Based on the current speaker determined in the context reconstruction, determine the starting state of the state transition; Based on the dialogue context recovered during the context reconstruction and the current task information, determine the target state for state transition; Based on the initial state and the target state, the dialogue management state machine is driven to perform state transitions, which include the following five core state transitions: The process transitions from the waiting for user input state to the task execution state, allowing the interrupted task to resume. The task execution state transitions to the user input waiting state, which is used to wait for user confirmation or additional information. The process transitions from the task execution state to the TTS broadcast state, which is used to broadcast the task execution results to the user. The system transitions from a TTS broadcast state to a waiting-for-user-input state to await user response. The process transitions from TTS broadcast status to task execution status, allowing for the continuation of subsequent tasks. After the state transition is completed, the dialogue management state machine resumes execution from the dialogue node at the time the interruption event occurred.

9. The method according to claim 1, characterized in that, For weak network environments, the method also includes the following optimization measures: When generating the context snapshot, a local caching priority strategy is adopted, which prioritizes storing the context snapshot in the vehicle's local storage module and asynchronously backs it up to cloud storage when the network connection is restored. During the context reconstruction process, if a network connection anomaly is detected, the context snapshot is read from the vehicle's local storage module, and the semantic completion process is executed using an offline semantic parsing engine. After execution resumes, if network connectivity is detected to be restored, the dialogue history and task execution status are automatically synchronized to cloud storage, and the state of the dialogue management state machine is updated.

10. The method according to claim 1, characterized in that, For multi-user scenarios, the method also includes the following features: When generating the semantic tagging information, the user identifier of the current user is obtained through the voiceprint recognition module, and the user identifier is used as the user information in the semantic tagging information; The context snapshot records personalized conversation preferences and task execution history corresponding to the user identifier; During the context reconstruction process, the corresponding dialogue strategy and task execution parameters are loaded from the personalized configuration database based on the user identifier; After execution resumes, the personalized dialogue preferences and task execution history are updated based on the user identifier, and the response strategy of the dialogue management state machine is adjusted based on the personalized configuration.

Images