Driving processing method and device, storage medium and electronic equipment

Abstract

The embodiment of the invention discloses a driving processing method and device, a storage medium and electronic device.The method comprises the steps that in response to a voice recording instruction of a target user in the vehicle driving process, the voice stream of the target user is collected, driving context data is generated, the voice stream of the target user is converted into a target transliteration text, and the target transliteration text is sent to the storage medium; based on the target transcription text and the driving context data, a driving processing large model is adopted to carry out record event analysis to obtain event element fragments, and based on the driving context data, event semantic completion is carried out on the event element fragments to obtain event record information, based on the event record information, performing data mapping by adopting a pre-equipment-forgetting event data model to generate an event task execution script and an event task record, displaying the event task record to the target user, and responding to a record confirmation instruction of the target user. And starting an event task corresponding to the event task record based on the event task execution script.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a driving processing method, device, storage medium, and electronic device. Background Technology

[0002] Currently, most in-vehicle systems offer voice recognition or simple memo functions, but these are primarily one-way processes of "voice transcription - manual editing." When drivers need to record critical information such as trip schedules or call reminders while driving, they still need to manually complete, confirm, or edit the information during breaks in the vehicle. This increases the risk of distraction and can easily lead to inaccurate execution of subsequent tasks due to missing information. Summary of the Invention

[0003] This specification provides a driving processing method, apparatus, storage medium, and electronic device, the technical solutions of which are as follows:

[0004] Firstly, embodiments of this specification provide a driving processing method, the method comprising:

[0005] In response to a voice recording command from a target user during vehicle driving, the system collects the target user's voice stream and generates driving context data, then converts the target user's voice stream into target transcribed text.

[0006] Based on the target transcribed text and the driving context data, a large driving processing model is used to parse the recorded events to obtain event element fragments. Based on the driving context data, the event element fragments are used to perform event semantic completion to obtain event record information. Based on the event record information, a pre-set forget event data model is used to perform data mapping to generate event task execution scripts and event task records.

[0007] The event task record is displayed to the target user, and in response to the target user's record confirmation command, the event task corresponding to the event task record is started based on the event task execution script.

[0008] In one feasible implementation, the step of performing event semantic completion on the event element fragments based on the driving context data to obtain event record information includes:

[0009] The target user behavior knowledge graph is updated based on the driving context data using the driving processing big model.

[0010] Based on the target user behavior knowledge graph, missing data entries in the event element fragments are filled in to obtain event record information after missing data completion.

[0011] In one feasible implementation, the step of performing missing data completion processing on the missing data entries in the event element fragment based on the target user behavior knowledge graph to obtain the event record information after missing data completion processing includes:

[0012] The missing bitmap and the missing data list corresponding to the missing bitmap are obtained by performing feature gap detection on the event feature fragments;

[0013] Based on the missing data entries in the missing data list, the missing data is inferred using the target user behavior knowledge graph to obtain the filler element data corresponding to the missing data entries. The missing bitmap is then filled based on the filler element data until the missing data list no longer contains the missing data entries.

[0014] In one feasible implementation, the step of using the target user behavior knowledge graph to perform missing data reasoning based on the missing data entries in the missing data list to obtain the filler element data corresponding to the missing data entries includes:

[0015] A query vector is constructed by encoding the semantic embedding representation of the event element fragments, missing data entries, and driving context data.

[0016] Retrieve a set of candidate nodes that match the query vector from the target user behavior knowledge graph;

[0017] Determine the combined confidence level of each candidate node in the candidate node set with the event element fragment;

[0018] Query the target candidate nodes whose combined confidence value is not lower than the dynamic threshold, and use the entity attributes of the target candidate nodes as the filler feature data corresponding to the missing data entries.

[0019] In one feasible implementation, the step of generating event task execution scripts and event task records by data mapping using a pre-set forget event data model based on the event record information includes:

[0020] The task categories in the event log information are parsed, and the compatibility score between each script template and the task category is calculated.

[0021] Select the target script template with the highest adaptation score from the script template library, and fill the placeholders in the target script template based on the event record information to obtain the event task execution script;

[0022] Event task records are obtained by performing event task description processing based on the event task execution script.

[0023] In one feasible implementation, after filling the placeholders in the target script template based on the event log information to obtain the event task execution script, the method further includes:

[0024] Obtain the vehicle's current speed, driver attention index, and road risk level, and calculate the script's executable threshold;

[0025] When the executable threshold of the script is lower than the safety threshold, a delayed execution instruction is inserted into the event task execution script and the status field of the event task record is set to the delayed execution type.

[0026] When the executable threshold of the script is not lower than the security threshold, the event task execution script is marked as a normal execution type.

[0027] In one feasible implementation, the step of displaying the event task record to the target user, and in response to the target user's record confirmation instruction, starting the event task corresponding to the event task record based on the event task execution script, includes:

[0028] The event task record is output via voice at the vehicle's human-machine interface;

[0029] If a record confirmation instruction is received from the target user, the event task corresponding to the event task record will be started based on the event task execution script;

[0030] If a user voice editing command is received, the event task record and the event task execution script corresponding to the event task record are updated in real time based on the voice editing content using the driving processing big model.

[0031] Secondly, embodiments of this specification provide a driving processing device, the device comprising:

[0032] The instruction monitoring module is used to respond to the voice recording instruction of the target user during vehicle driving, collect the target user's voice stream and generate driving context data, and convert the target user's voice stream into target transcribed text;

[0033] The driving processing module is used to parse recorded events based on the target transcribed text and the driving context data using a driving processing big model to obtain event element fragments, perform event semantic completion on the event element fragments based on the driving context data to obtain event record information, and perform data mapping based on the event record information using a pre-set forget event data model to generate event task execution scripts and event task records.

[0034] The recording processing module is used to display the event task record to the target user, and in response to the target user's record confirmation instruction, to start the event task corresponding to the event task record based on the event task execution script.

[0035] In one feasible implementation, the step of performing event semantic completion on the event element fragments based on the driving context data to obtain event record information includes:

[0036] The target user behavior knowledge graph is updated based on the driving context data using the driving processing big model.

[0037] Based on the target user behavior knowledge graph, missing data entries in the event element fragments are filled in to obtain event record information after missing data completion.

[0038] In one feasible implementation, the step of performing missing data completion processing on the missing data entries in the event element fragment based on the target user behavior knowledge graph to obtain the event record information after missing data completion processing includes:

[0039] The missing bitmap and the missing data list corresponding to the missing bitmap are obtained by performing feature gap detection on the event feature fragments;

[0040] Based on the missing data entries in the missing data list, the missing data is inferred using the target user behavior knowledge graph to obtain the filler element data corresponding to the missing data entries. The missing bitmap is then filled based on the filler element data until the missing data list no longer contains the missing data entries.

[0041] In one feasible implementation, the step of using the target user behavior knowledge graph to perform missing data reasoning based on the missing data entries in the missing data list to obtain the filler element data corresponding to the missing data entries includes:

[0042] A query vector is constructed by encoding the semantic embedding representation of the event element fragments, missing data entries, and driving context data.

[0043] Retrieve a set of candidate nodes that match the query vector from the target user behavior knowledge graph;

[0044] Determine the combined confidence level of each candidate node in the candidate node set with the event element fragment;

[0045] Query the target candidate nodes whose combined confidence value is not lower than the dynamic threshold, and use the entity attributes of the target candidate nodes as the filler feature data corresponding to the missing data entries.

[0046] In one feasible implementation, the step of generating event task execution scripts and event task records by data mapping using a pre-set forget event data model based on the event record information includes:

[0047] The task categories in the event log information are parsed, and the compatibility score between each script template and the task category is calculated.

[0048] Select the target script template with the highest adaptation score from the script template library, and fill the placeholders in the target script template based on the event record information to obtain the event task execution script;

[0049] Event task records are obtained by performing event task description processing based on the event task execution script.

[0050] In one feasible implementation, after filling the placeholders in the target script template based on the event log information to obtain the event task execution script, the method further includes:

[0051] Obtain the vehicle's current speed, driver attention index, and road risk level, and calculate the script's executable threshold;

[0052] When the executable threshold of the script is lower than the safety threshold, a delayed execution instruction is inserted into the event task execution script and the status field of the event task record is set to the delayed execution type.

[0053] When the executable threshold of the script is not lower than the security threshold, the event task execution script is marked as a normal execution type.

[0054] In one feasible implementation, the step of displaying the event task record to the target user, and in response to the target user's record confirmation instruction, starting the event task corresponding to the event task record based on the event task execution script, includes:

[0055] The event task record is output via voice at the vehicle's human-machine interface;

[0056] If a record confirmation instruction is received from the target user, the event task corresponding to the event task record will be started based on the event task execution script;

[0057] If a user voice editing command is received, the event task record and the event task execution script corresponding to the event task record are updated in real time based on the voice editing content using the driving processing big model.

[0058] Thirdly, embodiments of this specification provide a computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the above-described method steps.

[0059] Fourthly, embodiments of this specification provide an electronic device that may include: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to execute the above-described method steps.

[0060] The beneficial effects of the technical solutions provided in some embodiments of this specification include at least the following:

[0061] In one or more embodiments of this specification, the electronic device, based on the target user's voice recording command, collects the target user's voice stream and generates driving context data, converts the target user's voice stream into target transcribed text, and uses a driving processing big data model to parse recorded events to obtain event element fragments based on the target transcribed text and driving context data. Based on the driving context data, it performs event semantic completion on the event element fragments to obtain event recording information, and uses a pre-set forgotten event data model to perform data mapping to generate an event task execution script and event task record. The event task record is displayed to the target user, and in response to the target user's recording confirmation command, the event task corresponding to the event task record is started based on the event task execution script. This achieves a closed-loop process during vehicle driving, starting from the user's voice command and sequentially completing voice content collection and transcription, semantic parsing and completion, event task structured modeling, script generation, user confirmation, and task execution. It effectively solves the problems of users' inability to fully express themselves, operational limitations, and reliance on contextual reasoning in driving scenarios, improving the intelligence and automation capabilities of in-vehicle voice interaction, and significantly enhancing information recording efficiency, execution accuracy, and driving safety during driving. Attached Figure Description

[0062] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0063] Figure 1 This is a schematic flowchart of a driving processing method provided in the embodiments of this specification;

[0064] Figure 2 This is a schematic diagram of an event semantic completion process provided in the embodiments of this specification;

[0065] Figure 3 This is a schematic diagram of a missing data completion process provided in the embodiments of this specification;

[0066] Figure 4This is a schematic diagram of a data mapping process provided in the embodiments of this specification;

[0067] Figure 5 This is a schematic diagram of an event handling process provided in an embodiment of this specification;

[0068] Figure 6 This is a schematic diagram of the structure of a driving processing device provided in the embodiments of this specification;

[0069] Figure 7 This is a schematic diagram of the structure of an electronic device provided in the embodiments of this specification;

[0070] Figure 8 This is a schematic diagram of the operating system and user space structure provided in the embodiments of this specification;

[0071] Figure 9 yes Figure 8 Architecture diagram of the Android operating system in China;

[0072] Figure 10 yes Figure 8 Architecture diagram of the iOS operating system. Detailed Implementation

[0073] The technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this specification.

[0074] In the description of this specification, it should be understood that the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. In the description of this specification, it should be noted that, unless otherwise expressly specified and limited, "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices. Those skilled in the art can understand the specific meaning of the above terms in this specification based on the specific circumstances. Furthermore, in the description of this specification, unless otherwise stated, "multiple" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0075] The present specification will now be described in detail with reference to specific embodiments.

[0076] In one embodiment, such as Figure 1 As shown, a driving processing method is proposed, which can be implemented using a computer program and can run on a driving processing device based on the von Neumann architecture. This computer program can be integrated into an application or run as a standalone utility application. The driving processing device can be an electronic device, including but not limited to: personal computers, tablets, handheld devices, in-vehicle devices, wearable devices, computing devices, or other processing devices connected to a wireless modem. In different networks, terminal devices can be called by different names, such as: user equipment, access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication device, user agent or user equipment, cellular phone, cordless phone, device in a 5G network or future evolved network, etc.

[0077] Specifically, the driving handling method includes:

[0078] S102: In response to the voice recording instruction of the target user during vehicle driving, collect the target user's voice stream and generate driving context data, and convert the target user's voice stream into target transcribed text;

[0079] Voice recording command: This refers to a triggering statement issued by the target user in natural language, carrying semantic intent, to activate the vehicle's voice recording function. This statement can be a fixed template (such as "Help me record this") or a command with a synonymous expression (such as "Make a note" or "Write a reminder").

[0080] Target user voice stream: refers to the voice content continuously spoken by the user after issuing the recording instruction. It usually contains key information about the matter to be recorded (such as task content, time, contact person, etc.), and is the main audio data collected and processed in this step.

[0081] Driving context data: refers to dynamic data related to vehicle operating status and environmental conditions collected by the in-vehicle system when the recording command is triggered, including but not limited to: GPS positioning information, vehicle speed, current time, navigation status, driving mode, traffic conditions, driver operating status (such as hands on the steering wheel, head orientation), etc.

[0082] Target Transcription: refers to the natural language text form obtained by converting user speech streams through speech recognition technology, which serves as the basic input for subsequent semantic analysis and event generation.

[0083] In a schematic manner, the electronic device continuously monitors the vehicle system. When it detects a voice recording command from the target user with a triggering intent, it enters a recording session mode and assigns a unique session identifier to the recording session. In this mode, the current voice channel is temporarily locked, and unnecessary prompts are paused to ensure voice input quality. After the recording session mode is activated, the onboard microphone array captures the target user's voice signal stream using beamforming and sound source localization technologies. To improve the signal-to-noise ratio, the system can concurrently invoke a noise reduction model or an adaptive filtering module based on noise spectrum estimation to filter out ambient background noise (such as engine noise, air conditioning noise, road noise, etc.).

[0084] In addition, the electronic devices simultaneously acquire context data in parallel with the voice stream acquisition. The vehicle control system obtains and caches the following driving context information to construct a time-aligned context data packet (CTX) for subsequent large model processing. Acquisition examples include:

[0085] GPS coordinates: Eg 139.76°E, 35.67°N

[0086] Vehicle speed: Eg The current vehicle speed is 47km / h

[0087] Current system time: Eg2025-06-12 10:58:24

[0088] Navigation status: Eg. Distance to destination 15km, estimated arrival time 11:15

[0089] Traffic conditions: Eg. The current road congestion level is moderate.

[0090] Driving status: Eg The driver is actively driving, in single-person mode.

[0091] Furthermore, the electronic device invokes an Automatic Speech Recognition (ASR) model specifically designed for in-vehicle voice environments to perform endpoint detection, speech segmentation, feature extraction, and speech decoding on the acquired speech stream, ultimately outputting the target transcribed text T1. This model supports processing inputs containing ambiguous expressions, abbreviated sentences, and natural spoken language features, ensuring that the transcription results accurately reproduce the user's intent.

[0092] This step not only achieves accurate capture and text conversion of the user's natural speech input, but also obtains driving context data that is highly coupled with the speech input behavior. This provides key support for semantic reasoning, time and location completion, and task script generation in subsequent steps, effectively improving the completeness and context relevance of task records, while reducing the user's interaction burden and enhancing the overall user experience and driving safety.

[0093] S104: Based on the target transcribed text and the driving context data, the driving processing big model is used to record event parsing to obtain event element fragments. Based on the driving context data, the event element fragments are used to perform event semantic completion to obtain event record information. Based on the event record information, the pre-set forget event data model is used to perform data mapping to generate event task execution scripts and event task records.

[0094] Recording event parsing (processing): In this manual, it can be understood as understanding the semantic intent and decomposing it in a structured manner based on natural language transcribed text and vehicle operating status, and identifying the key components of the event to be recorded through a large model.

[0095] Event element fragments: These refer to the set of the smallest structural units containing semantic functions parsed from the target transcribed text. They often include fields such as action verbs (e.g., remind, call), objects (contacts, matters), time, location, and priority. Due to objective factors such as users, there may be missing items or ambiguous expressions.

[0096] Event semantic completion (processing): In this specification, it can be understood as, when there are incomplete or ambiguous expressions in the parsed event elements, using information such as driving context data and user behavior knowledge graphs, reasoning to generate clear semantic content completion elements to form a complete event record.

[0097] Event log information: In this specification, it can be understood as event data with a complete semantic structure obtained after semantic completion, which serves as the direct input for subsequent script generation and task scheduling.

[0098] Pre-defined memo event data model: To meet the needs of in-vehicle task management, a pre-defined standardized data structure template for memo tasks is used to store event record information and convert it into corresponding task scripts and records.

[0099] Event task execution script: is a sequence of instructions that describes the triggering conditions, action content and execution method of an event task in a structured manner, and is used to realize the automatic scheduling and execution of tasks.

[0100] Event task logs: These are standard event entries built upon and persistently stored based on event log information, possessing unique identification and lifecycle management capabilities.

[0101] In this step, based on the target transcribed text and the corresponding driving context data obtained in the previous step, a large driving processing model deployed on the vehicle or cloud is invoked to perform semantic parsing operations on the target transcribed text, so as to achieve preliminary semantic recognition and structured decomposition of the recorded event and obtain event element fragments.

[0102] Specifically, the driving processing model combines natural language understanding and context awareness to perform multiple rounds of encoding and semantic extraction on the target transcribed text, identifying the target user's recording intent and its task components. These task components typically include, but are not limited to, event action types (e.g., reminders, making phone calls, scheduling), involved parties (e.g., contacts, task content), time expressions (e.g., "tomorrow morning," "before arriving home"), and triggering conditions. Through this process, fragments of event elements that may still have some missing fields or unclear expressions can be obtained.

[0103] Next, the driving processing model performs gap detection on the event element fragments based on their structural integrity, identifying currently missing or ambiguous semantic fields. Based on this, semantic completion processing is performed on the event element fragments using collected driving context data. This driving context data includes, but is not limited to, the vehicle's current location, estimated arrival time, current speed, navigation status, timestamp information, and driver behavior status, providing a basis for parsing ambiguous expressions. For example, taking "Remind me to call Li before I get home" as an example, the system can infer the estimated arrival time based on the current navigation path and remaining travel time, thus completing the relative time expression into a specific time point. If the target object is unclear, such as when there are people with the same name, the system can further combine user behavior knowledge graphs to identify the contact entity most relevant to the current context to complete the contact element completion.

[0104] After semantic completion, the event element fragments in the driving processing big data model form complete event record information, possessing various information fields required for structured task execution. Subsequently, the driving processing big data model performs field mapping processing on this event record information based on a pre-defined memo event data model. Specifically, this includes archiving and organizing elements such as task name, triggering conditions, execution method, target object, and priority in the event record information according to the field definitions of the data model into a unified data structure, generating standardized event task records.

[0105] Simultaneously, the driving processing model, based on the task type and target object in the event task record, calls the task script generation engine to select the corresponding execution template. The execution template defines the trigger condition judgment logic, execution action sequence, and exception handling process for different task types. The system generates an event task execution script that can be scheduled and executed by the vehicle task management module by filling the parameter bits in the template with the fields from the event record information.

[0106] This step not only completes the semantic transformation and data modeling from natural language expression to structured event tasks, but also generates executable script files, providing an instruction basis for subsequent tasks such as event reminders, automatic dialing, and schedule recall, ensuring that tasks are executed accurately and promptly while meeting driving safety requirements.

[0107] Optionally, the following illustrates the model training process for a large driving processing model:

[0108] In some embodiments, a pre-trained basic large language model can be obtained and adapted to a knowledge-based driving processing scenario to obtain a large driving processing model. However, directly applying the basic large language model to a driving processing scenario is often difficult to adapt to new driving processing scenarios. Therefore, the basic large language model is first obtained to create an initial large driving processing model, and sample data for the new driving processing scenario is obtained. This sample data includes sample transcribed text and sample driving context data. Since the basic large language model is usually a pre-trained open-source AIGC model with content generation capabilities, this specification only needs to adapt it to the driving processing scenario. Specifically, the sample data can be used to fine-tune the initial large driving processing model. After the model fine-tuning training is completed, a large driving processing model adapted to the driving processing scenario is obtained.

[0109] Model creation: Obtain the basic large language model, create an initial driving processing scenario plugin model for driving processing scenarios, and form an initial driving processing large model based on the basic large language model and the initial driving processing scenario plugin model; the basic large language model (MLLM) includes, but is not limited to, the DeepSeek large model, the GPT series large models, etc.

[0110] Sample data acquisition: Acquire sample data for new driving processing scenarios, which consists of sample transcribed text and sample driving context data for the driving processing scenarios.

[0111] Sample data annotation: Based on the driving processing requirements of the driving processing scenario, the corresponding event task execution script tags and event task record tags are annotated.

[0112] Model training process: Input sample data into the initial driving processing large model for at least one round of model training. During the forward training process: Based on the sample transcribed text and sample driving context data, the initial driving processing large model is used to parse recorded events to obtain predicted event element fragments. Based on the sample driving context data, the predicted event element fragments are used to perform event semantic completion to obtain predicted event record information. Based on the predicted event record information, the pre-set forgotten event data model is used to perform data mapping to generate predicted event task execution scripts and predicted event task records.

[0113] During the model reverse training process, a first model loss value is determined based on the predicted event task execution script and the event task execution script label using the model loss function. A second model loss value is determined based on the predicted event task record and the labeled event task record. The first and second model loss values ​​are combined to obtain the final model loss value. Based on this model loss value, the model parameters of the initial driving processing scenario plugin model in the initial driving processing large model are adjusted to maintain the model structure of the basic large language model. This process continues until the model training termination condition is met, resulting in the basic large language model and the driving processing scenario plugin model. This completes the model fusion of the basic large language model and the driving processing scenario plugin model, resulting in the trained driving processing large model.

[0114] As an illustration, the initial driving processing scenario plug-in model can be created based on a machine learning model.

[0115] Model fusion of the basic large language model and the driving processing scenario plugin model: This involves fusing the model structure layer weights of the driving processing scenario plugin model with the weights of the basic large language model. By determining the target model structure layer corresponding to the model structure layer weights in the basic large language model, the model structure layer parameters of this target model structure layer are fused with the model structure layer weights. The model structure layer weights of the driving processing scenario plugin model may only correspond to a portion of all model structure layers in the basic large language model. By updating the parameters of the model structure layer based on the model structure layer weights for this portion of the target model structure layer, and so on, the reference update process for the weights of all model structure layers is completed, thus obtaining the large driving processing model.

[0116] Optionally, the model's training termination conditions may include, for example, the loss function value being less than or equal to a preset loss function threshold, or the number of iterations reaching a preset threshold. Specific training termination conditions can be determined based on actual circumstances and are not specifically limited here.

[0117] It should be noted that the machine learning models involved in one or more embodiments of this specification include, but are not limited to, fitting one or more of the following machine learning models: Convolutional Neural Network (CNN) model, Deep Neural Network (DNN) model, Recurrent Neural Networks (RNN) model, embedding model, Gradient Boosting Decision Tree (GBDT) model, Logistic Regression (LR) model, etc.

[0118] S106: Display the event task record to the target user, and in response to the target user's record confirmation instruction, start the event task corresponding to the event task record based on the event task execution script.

[0119] In this step, after the electronic device system completes the event task recording and generates the corresponding event task execution script, it outputs the content of the event task record to the target user for final confirmation. The display process can employ one or more combined methods, such as voice broadcasting, in-vehicle screen graphical interface, and head-up display system, to ensure that the information presentation in the driving scenario is perceptible and low-interference.

[0120] In one feasible implementation, the electronic device extracts core field information from the generated event task record, including but not limited to task name, trigger time or trigger condition, execution action, and associated objects, to construct a user-oriented interactive summary. For example, in a scenario where the generated event task record is "Call contact person Li ten minutes before arriving at home's geofence," the system can output a prompt via voice, such as "Task recorded for you: You will be automatically called Li ten minutes before arriving home. Confirm?" This summary information can be generated based on template rules to ensure natural language and clear structure.

[0121] While outputting an event task record summary, the electronic device enters a confirmation listening state. This confirmation listening state is used to receive record confirmation commands from the target user. These commands can be issued via voice confirmation (such as "confirm," "okay"), gesture recognition, steering wheel control buttons, or central control screen touchscreen. Upon receiving the user's confirmation command, the system updates the current event task record status from pending confirmation to active status.

[0122] After an event task record is activated, the electronic device performs task scheduling and trigger control according to the associated event task execution script. The event task execution script includes definitions of trigger conditions, such as time, geographical location, and vehicle status. The electronic device continuously monitors vehicle operating data and environmental conditions, and executes the specified task action when the trigger conditions are met. For example, in the phone call task, when the vehicle enters the home geofence area and the current time meets the condition of being ten minutes ahead of time, the electronic device will automatically initiate a phone call, or it may first issue a prompt and then require user confirmation before dialing.

[0123] If the user does not confirm the event task record after receiving the event task record display content, the system can repeatedly prompt for confirmation within the set time window or mark the event task record as pending confirmation. When the safe interaction conditions are met, the system will issue another reminder to ensure that critical tasks are not missed due to driving interference.

[0124] Through this step, after semantic parsing and script generation, the electronic device introduces a clear user participation element, realizing a closed-loop confirmation process from machine generation to user authorization of event recording. On the one hand, this enhances the controllability and user trust of event tasks; on the other hand, through an intelligent task activation and scheduling mechanism, task execution can be highly integrated with the vehicle's operating status, thereby achieving timely and automated triggering and completion of tasks while ensuring driving safety.

[0125] In the embodiments of this specification, the electronic device, based on the target user's voice recording command, collects the target user's voice stream and generates driving context data, converts the target user's voice stream into target transcribed text, and uses a large driving processing model to parse recorded events to obtain event element fragments based on the target transcribed text and driving context data. Based on the driving context data, it performs event semantic completion on the event element fragments to obtain event recording information. Based on the event recording information, it uses a pre-set forgotten event data model to perform data mapping to generate an event task execution script and event task record, displays the event task record to the target user, and, in response to the target user's recording confirmation command, initiates the event task corresponding to the event task record based on the event task execution script. This achieves a closed-loop process during vehicle driving, starting from the user's voice command and sequentially completing voice content collection and transcription, semantic parsing and completion, event task structured modeling, script generation, user confirmation, and task execution. It effectively solves the problems of users' inability to fully express themselves, operational limitations, and reliance on contextual reasoning in driving scenarios, improving the intelligence and automation capabilities of in-vehicle voice interaction, and significantly enhancing information recording efficiency, execution accuracy, and driving safety during driving.

[0126] Please see Figure 2 , Figure 2 This is a flowchart illustrating an event semantic completion process proposed in this specification. Specifically, the process of performing event semantic completion on the event element fragments based on the driving context data to obtain event record information can be carried out in the following ways:

[0127] S202: Update the target user behavior knowledge graph based on the driving context data using the driving processing big model;

[0128] The target user behavior knowledge graph is a user behavior model organized in a graph structure. Its nodes include entity information related to the user's driving behavior and voice interaction behavior, such as frequently used contacts, frequently visited locations, preferred time periods, common task types, and habitual expressions. The relationships between nodes are defined by edges, such as contact frequency, geographical association, temporal co-occurrence probability, and contextual relevance. This graph can be continuously enriched through model self-learning during long-term user use and maintain dynamic adaptability through structural updates.

[0129] In this step, a large-scale driving processing model deployed on the vehicle or cloud is invoked. Based on the currently collected driving context data, the behavioral knowledge graph of the target user is updated to build a more personalized semantic reasoning foundation that is more in line with the real-time scenario.

[0130] In one feasible implementation, the update operation of the behavioral knowledge graph is performed in the following way:

[0131] First, the driving context data is vectorized using a large-scale driving processing model and semantically associated with behavioral nodes in the user's existing knowledge graph. For example, when the system detects that the current vehicle is approaching a geofence that the user has frequently encountered in the past (such as "company" or "residence"), and the user is making a voice recording request containing keywords such as "reminder" or "call," the system infers a contextual relationship between the behavior and existing location nodes based on the current context, and updates the time weight and interaction frequency attributes of that node accordingly.

[0132] Secondly, when the driving processing model identifies new entity information (such as a contact, task objective, or event description appearing for the first time) in the current session, it introduces this entity information as a new node into the knowledge graph and establishes semantic edges with related nodes in the current context, such as "first recorded at home fence" or "frequently mentioned during evening rush hour," and assigns initial edge weights. If this type of entity is mentioned multiple times in subsequent use, its weight in the graph will gradually increase, thereby enhancing its likelihood of being selected by inference.

[0133] Finally, by adjusting the existing edge weights based on the changing trends of contextual relevance in the large-scale driving processing model, the user behavior knowledge graph can reflect the dynamic changes in user behavior patterns under different scenarios, times, and semantic intentions. Through this update mechanism, the behavior knowledge graph maintains a high degree of adaptability to user behavior, providing more accurate and personalized knowledge support for subsequent semantic completion.

[0134] By executing this step, the target user's behavioral knowledge graph can dynamically adapt to the interaction background in the current driving scenario, effectively improving the accuracy and contextual fit of the system in subsequent steps for missing element reasoning and semantic completion, while reducing reliance on explicit user input and enhancing the intelligence level of the in-vehicle voice interaction system.

[0135] S204: Based on the target user behavior knowledge graph, perform missing data completion processing on the missing data entries in the event element fragment to obtain the event record information after missing data completion processing.

[0136] In this step, after updating the target user behavior knowledge graph, the system uses the user's personalized knowledge and behavioral preference information provided by the graph to perform reasoning and completion processing on the missing data entries in the event element fragments, so as to generate event record information with complete structure and clear semantics.

[0137] Specifically, the driving processing model first performs a gap identification operation on the event element fragments to be processed. That is, for fields in the semantic structure that do not yet have a clear value or are ambiguous in expression, a list of missing data entries is generated. The missing data entries typically include, but are not limited to, the following types: time elements (such as "later", "before arriving home"), location elements (such as "that coffee shop"), contact entities (such as nickname expressions), task priorities, etc.

[0138] For each missing data entry, the driving processing big model constructs a semantic vector for inference queries. This semantic vector is composed of event semantic context information, current driving context data, and semantic descriptions of the missing fields. This vector is then used as the basis for querying semantic retrieval in the target user behavior knowledge graph.

[0139] During semantic retrieval, a large-scale driving processing model is used to calculate the similarity of candidate nodes in the graph corresponding to the missing field type. The matching degree between the candidate nodes and the current event scenario is comprehensively evaluated based on multiple factors such as node frequency, contextual co-occurrence, and historical triggering scenarios recorded in the graph, generating a confidence score for each candidate node. The node with the highest confidence score can be preferentially selected as the candidate entity to complete the corresponding missing data entry.

[0140] For example, if the missing data entry is "time" and the event statement contains the vague expression "before arriving home", the driving processing big model compares the estimated arrival time in the current navigation path with the time periods in the past when the user issued similar tasks in the same geographical area, infers the most likely specific reminder time, and writes this time into the event log information as the completion result of the time field.

[0141] For example, in the case of missing contact entities, the driving processing big model can match contacts in the graph that users have historically used for this type of task based on the task type (such as "returning a call") and semantic keywords involved in the event content, and select the one with the highest similarity as the object to complete the contact field.

[0142] After all missing data entries are completed, the updated semantic element fields are aggregated into a complete event semantic structure through the driving processing big model, forming event record information with clear action type, target object, trigger time and execution method, and providing standardized data input for subsequent task script generation and scheduling execution.

[0143] This step fully utilizes the individual behavioral preferences, expression habits, and historical interaction data contained in the target user behavior knowledge graph through the driving processing big model. It completes the accurate completion of the semantic structure of events without requiring users to re-enter, significantly improving the efficiency and intelligence level of voice interaction recording, and enhancing the semantic understanding and scene adaptability of the in-vehicle voice assistant in complex driving environments.

[0144] In this specification, through the processing of steps S202 to S204, the system dynamically updates the target user behavior knowledge graph using driving context data, and performs personalized reasoning and completion on missing data entries in event element fragments based on this graph. It can intelligently restore the semantic structure of the event and generate complete event record information when the user's expression is incomplete or semantically ambiguous, thereby significantly improving the accuracy and context adaptability of semantic completion, reducing the user's interaction burden during driving, and enhancing the practicality and intelligence level of the voice recording function.

[0145] In one possible implementation, please refer to Figure 3 , Figure 3 This is a flowchart illustrating a missing data completion process. Specifically, the missing data entries in the event element fragment are completed based on the target user behavior knowledge graph to obtain the event record information after missing data completion. The following methods can be used as a reference:

[0146] S3002: Perform element gap detection on the event element fragment to obtain a missing bitmap and a missing data list corresponding to the missing bitmap;

[0147] In this step, the electronic device uses a large-scale driving processing model to perform field completeness checks on the event element fragments output by the event semantic parsing module, identifying missing or ambiguous field items in the semantic structure. The detection process compares fields based on a predefined standard structure model of event elements. If a field is empty or contains vague expressions (such as "later" or "someone"), it is identified as a missing field.

[0148] The electronic device constructs a missing bitmap based on the detection results. The missing bitmap is an identifier structure representing the completeness status of each field, usually marked in binary form, where a value of one indicates that the field is missing, and a value of zero indicates that the field has explicit semantic content.

[0149] Simultaneously, a missing data list is generated based on the missing bitmap using the large-scale driving processing model. This list contains all fields to be completed, including field type, field position in the semantic fragment, and contextual description. This list serves as the input set for subsequent inference processing, guiding the order of knowledge graph completion calls.

[0150] S3004: Based on the missing data entries in the missing data list, the missing data is inferred using the target user behavior knowledge graph to obtain the filling element data corresponding to the missing data entries, and the missing bitmap is filled based on the filling element data until the missing data list does not contain the missing data entries.

[0151] In this step, inference processing is performed sequentially for each missing data entry, according to the order in the missing data list. Specifically, this includes the following operations:

[0152] First, a semantic query vector is constructed based on the current missing field type using the large driving processing model. The vector is composed of the semantic context of the current event element fragment, driving context data, and field type, and is used to describe the semantic features of the missing field in the current context.

[0153] Next, using the semantic query vector as the retrieval basis, the system locates matching candidate entity nodes in the target user behavior knowledge graph through the driving processing big data model. The system scores the candidate nodes based on multiple dimensions such as semantic similarity, node historical frequency, contextual co-occurrence relationship, and task type suitability, and selects the candidate node with the highest comprehensive score as the filling value for the missing field.

[0154] Subsequently, the completed feature data is written into the corresponding fields of the event feature fragment using the driving processing big data model, and the flag bits of the corresponding fields in the missing bitmap are updated simultaneously. If the confidence level of the inferred completion result is lower than a preset threshold, the system can mark the field as "pending confirmation" to prompt the user to manually confirm or revise it later.

[0155] The above reasoning and filling process is continuously executed through the large driving processing model until all fields in the missing data list have been completed, thereby forming a semantically complete event record information structure with the semantic foundation to support task modeling and script generation.

[0156] Through the gap detection and item-by-item completion processing of this embodiment, the semantic elements in incomplete speech expressions can be automatically completed intelligently while maintaining real-time performance and safety. This effectively reduces the cost of driving interaction and improves the intelligence and practicality of the in-vehicle voice task system.

[0157] Optionally, the process of performing missing data reasoning based on the missing data entries in the missing data list using the target user behavior knowledge graph to obtain the filler element data corresponding to the missing data entries can be performed in the following manner:

[0158] A2: Construct a query vector by encoding the semantic embedding representation of the event element fragments, missing data entries, and driving context data;

[0159] First, the large-scale driving processing model extracts the overall semantic embedding representation of the current event element fragment for the missing data entry to be completed. This representation is then combined with the entry's field type information (e.g., "time," "contact," or "location") and the currently collected driving context data (including current location, speed, navigation information, timestamp, etc.) through a multi-layer neural representation model for joint encoding, generating a query vector representing the current semantic environment for completion. This query vector comprehensively reflects the task intent, environmental state, and semantic missing background, providing input for subsequent graph retrieval.

[0160] A4: Retrieve a set of candidate nodes that match the query vector in the target user behavior knowledge graph;

[0161] Based on the generated query vector, the driving processing model invokes a semantic indexing engine within the target user behavior knowledge graph to locate a set of nodes semantically relevant to the query vector. This knowledge graph is a personalized structure built from the user's long-term driving behavior, interaction preferences, and historical tasks. Its nodes represent contact entities, location entities, time preference nodes, and other information, with edges representing behavioral relationships and contextual connections between them. The system calculates the similarity between the node embeddings and the query vector to retrieve a set of candidate nodes, which serve as inference candidates for missing fields.

[0162] A6: Determine the combined confidence level of each candidate node in the candidate node set with the event element fragment;

[0163] In this step, for each node in the candidate node set, a combined confidence score is calculated based on its degree of matching with the semantic scene of the current event. The calculation of the combined confidence score comprehensively considers the following factors:

[0164] The first is semantic similarity, which is the cosine similarity between the embedding vector of the candidate node and the query vector;

[0165] Second, the behavior frequency indicator, which is the frequency of the occurrence of the node in the user's historical tasks;

[0166] Third is the context co-occurrence weight, which is the probability of the node co-occurring with the current navigation path, time period, or task type;

[0167] Fourth is the user behavior priority level, which is the preference weight of the node in the user knowledge graph.

[0168] The combined confidence score is obtained by weighting the above multiple factors, and reflects the credibility of the candidate node as a missing field filler value.

[0169] A8: Query the target candidate node whose highest combined confidence value is not lower than the dynamic threshold, and use the entity attribute of the target candidate node as the filler feature data corresponding to the missing data entry.

[0170] In a schematic representation, the system sorts the combined confidence scores of candidate nodes using a large-scale driving processing model, and pre-sets a dynamic confidence threshold. This dynamic threshold is adjusted based on factors such as current driving load, interaction environment stability, and field sensitivity to achieve a balance between safety and accuracy. If a candidate node's confidence score exceeds this threshold, the system selects the candidate node with the highest confidence score as the target node, extracts its corresponding entity attributes as filler values ​​for the currently missing data entry, and writes them into the event element fragment.

[0171] If the confidence level of all candidate nodes does not reach the threshold, the large-scale control driving processing model will not directly write the fill value, but will set the missing data entry to a "pending confirmation" status, retain the completion suggestion and wait for subsequent user confirmation or interaction instructions.

[0172] In the embodiments described in this specification, the query construction, graph retrieval, and confidence filtering mechanisms described in this embodiment can accurately infer semantic completion results that conform to user habits and scenario requirements by combining personalized behavioral graphs and contextual environments for fields not explicitly expressed in the user's natural language input, thereby enhancing the integrity of the event record structure and improving the accuracy of semantic understanding.

[0173] Optional, please see Figure 4 , Figure 4 This is a flowchart illustrating a data mapping process. Specifically, based on the event record information, a pre-set forgettable event data model is used to generate event task execution scripts and event task records through data mapping. The following methods can be used as a reference:

[0174] S4002: Parse the task category in the event log information and calculate the compatibility score between each script template and the task category;

[0175] The fit score is determined by a set of matching rules or a similarity calculation method learned through a model, evaluating the degree of matching between the current event record information and each script template in terms of semantic structure, field content, and execution method. This score is used to filter the script template that best matches the current task type, ensuring that the generated script is executable and logically consistent.

[0176] As illustrated, the task type field in the event log information is parsed using a large-scale driving processing model. The task type field typically includes, but is not limited to, reminder tasks, phone call tasks, navigation tasks, and scheduling tasks. Based on the parsing results, the task type is matched against each script template in a pre-defined script template library, and the fit score between each script template and the current task type is calculated.

[0177] S4004: Select the target script template with the highest adaptation score from the script template library, and fill the placeholders in the target script template based on the event record information to obtain the event task execution script;

[0178] Based on the comparison results of the fit scores, the target script template that best matches the current task category is selected from the script template library. The target script template is a structured script framework that contains a series of predefined logical structures, trigger conditions, operation actions, and placeholder fields for receiving input.

[0179] Under the control of the driving process, the various elements and fields in the event log information—including task name, trigger time, trigger location, target object, action type, execution constraints, etc.—are written into the corresponding placeholder positions in the target script template according to preset mapping rules. After filling, a complete event task execution script with scheduling conditions and execution logic is obtained.

[0180] This event task execution script describes the running conditions and actions of the event task and serves as the basic instruction unit for subsequent task scheduling and automatic execution.

[0181] S4006: Based on the event task execution script, perform event task description processing to obtain event task records.

[0182] After generating the event task execution script, the driving processing big data model uses the core content of the script to descriptively process the event task and construct an event task record. The event task record, as a standardized task data object, includes the following fields: task identifier, task title, task summary, trigger condition description, target operation description, execution status flag, etc.

[0183] Event task records are not only used for user display and confirmation before task execution, but also serve as interface data between the task scheduling module and the historical task archiving module for the management and retrieval of task lifecycles.

[0184] Through script template matching, semantic field filling, and standard task modeling in this embodiment, the structural transformation process from natural language event expression to executable task instructions is realized, ensuring the standardization of task description and the clarity of execution logic, and improving the automation level of task execution and the adaptability of system response.

[0185] In one feasible implementation, after filling the placeholders in the target script template based on the event log information to obtain the event task execution script, the method further includes:

[0186] B2: Obtain the vehicle's current speed, driver attention index, and road risk level, and calculate the script's executable threshold;

[0187] In this step, to achieve intelligent assessment of the feasibility of executing scripts for event tasks, a driving processing big model reasoning mechanism driven by a preset script executability threshold calculation prompt is introduced. The preset script executability threshold calculation prompt is used to perform semantic fusion and comprehensive judgment on vehicle operating status, driver behavior status and road environment information using the driving processing big model, and outputs the execution feasibility score of the current task, which is called the script executability threshold.

[0188] Specifically, after generating the event task execution script, the following driving status elements are collected as input information sources: vehicle current speed: provided in real time by the vehicle chassis bus, used to represent whether the vehicle is in a low-speed, medium-speed, or high-speed driving state; driver attention index: obtained by the driving behavior monitoring subsystem through cameras, infrared sensors, or eye-tracking devices, including parameters such as driver's facial orientation, gaze direction, and blink frequency, and concentration analysis is performed; road risk level: calculated based on factors such as navigation attributes of the road segment where the vehicle is located (e.g., urban roads, highways, tunnel entrances), traffic event information (e.g., congestion, construction, accident alerts), and environmental conditions (e.g., weather, lighting).

[0189] After obtaining the above state data, standardized preset scripts are constructed to execute threshold calculation prompts, which serve as task processing prompts for the large-scale driving processing model.

[0190] For example, prompts may include, but are not limited to: "Current speed is × kilometers per hour, driver attention index is ×, road type is ×, is it appropriate to immediately perform the following task: [Task Summary]?"

[0191] The prompt is automatically generated and combined with the task content of the event task execution script (such as making a phone call, voice reminder, etc.), organized in natural language to construct the input context, and calls the driving processing big model to perform semantic understanding and comprehensive judgment.

[0192] The large-scale driving processing model outputs a feasibility judgment result for the current task execution conditions based on the semantics of prompt words, contextual cues, and its pre-trained knowledge. This judgment result can be represented in the form of confidence scores, classification labels, or instructional statements, where the confidence score is defined as the script executability threshold.

[0193] For example, if the output of the large model is "The task is currently safe to execute, and it is recommended to trigger it immediately", the system will parse the execution threshold as high; if the output is "The current driving environment is complex, and it is recommended to postpone execution", the system will parse the threshold as low.

[0194] Compared to traditional rule engines, this mechanism has stronger environmental understanding and semantic reasoning capabilities, making it particularly suitable for scenarios with complex interaction conditions, multi-source ambiguous information, or unpredictable factors.

[0195] By constructing a script-executable threshold evaluation path using a prompt-word-driven large model approach, not only is the context-awareness and dynamic adaptability of the judgment results improved, but the dependence on fixed-weight rule systems is also reduced, making the scheduling of event tasks more intelligent, safe, and in line with user context expectations, providing strong support for human-machine collaboration in complex driving scenarios.

[0196] B4: When the executable threshold of the script is lower than the safety threshold, insert a delayed execution instruction into the event task execution script and set the status field of the event task record to the delayed execution type;

[0197] If the evaluation results show that the current script's executable threshold is lower than a preset safety threshold, indicating that the current vehicle operating state is not suitable for immediately triggering the execution of the event task, a delayed execution instruction will be inserted into the event task execution script. The delayed execution instruction may include conditions such as waiting for the driving to stabilize, reducing vehicle speed, increasing driver attention, or leaving a high-risk road section.

[0198] Simultaneously, the status field in the event task record is updated to "delayed execution," indicating that the task has been registered but is not yet ready for execution, and will be scheduled for execution once a safe execution state is reached. This status is used by the task scheduling module for risk avoidance and execution delay handling.

[0199] B6: When the executable threshold of the script is not lower than the security threshold, the event task execution script is marked as a normal execution type.

[0200] If the executable threshold of the script is not lower than the safety threshold, it indicates that the current vehicle operating environment is under control. The script executing the event task is marked as a normal execution type, and the original triggering logic remains unchanged. At this time, the status field in the event task record is also set to "can be executed immediately" or "normal scheduling", and the task will be scheduled by the system on time according to the triggering conditions in its script.

[0201] In this specification, by introducing a dynamic safety assessment mechanism based on driving status, the execution process of event tasks not only depends on semantic logic and script conditions, but also takes into account vehicle operation safety. This enables voice tasks to be generated intelligently while taking into account driving safety, significantly improving the intelligence level and operational reliability of event task scheduling.

[0202] Optional, please see Figure 5 , Figure 5 This is a flowchart illustrating an event handling process. Specifically, it involves displaying the event task record to the target user, responding to the target user's record confirmation command, and initiating the event task corresponding to the event task record based on the event task execution script. The following approach can be referenced:

[0203] S5002: Output the event task record via voice on the vehicle's human-machine interface;

[0204] After the event task execution script is generated, the system outputs task confirmation information to the target user through the in-vehicle human-machine interface. Specifically, the system selects key fields from the event task record, including task content, triggering conditions, target object, execution method, etc., generates a speech summary text, and calls the speech synthesis module to broadcast the summary information in the vehicle.

[0205] The voice output process takes place during driving, using a concise and clear expression to avoid cognitive load on the driver from lengthy content. For example, if the event task record involves "calling contact Li Ming 10 minutes before arriving home", the system announcement could be: "A reminder task to call Li Ming 10 minutes before arriving home will be set for you. Please confirm whether to save."

[0206] Voice prompts can be supplemented with optional on-screen or head-up display prompts to enhance perceptibility, while also supporting multimodal input responses.

[0207] S5004: If a record confirmation instruction from the target user is received, the event task corresponding to the event task record is started based on the event task execution script;

[0208] After the voice broadcast is completed, the system enters a listening state, waiting for a response from the target user. If a confirmation command is detected, such as "confirm," "save," or "okay," or if a confirmation signal is sent via in-vehicle control buttons or steering wheel operation, the status field of the current event task record is updated to active, and the task is scheduled to the task management module.

[0209] At the same time, based on the execution script associated with the event task record, the corresponding trigger listening conditions (such as geographical location, time point, driving behavior status) are configured, and the task instructions are automatically executed according to the predetermined logic after the trigger conditions are met, such as sending reminders, making phone calls, starting navigation and other operations.

[0210] S5006: If a user voice editing command is received, the event task record and the event task execution script corresponding to the event task record are updated in real time based on the voice editing content using the driving processing big model.

[0211] If the system receives a voice editing command from the target user, such as "It's not Li Ming, it's Zhang Wei", "Change the reminder time to 7 o'clock", or "Change it to call when you get to the company", the system will automatically exit the confirmation process and enter the editing process.

[0212] In this process, the system transcribes the user's voice editing commands and constructs semantic input based on the context. By invoking the driving processing model, it dynamically updates the original event task records, including but not limited to modifying the target contact, adjusting the trigger time, and changing the task type. Simultaneously, based on the updated event record information, the system re-executes the script template population operation to generate a new event task execution script.

[0213] After the update is complete, the system can output a voice summary again and wait for user confirmation, forming an interactive closed loop of task confirmation-revision-reconfirmation.

[0214] By implementing this method, the system not only achieves a user-initiated confirmation mechanism for event tasks before execution, but also supports rapid revision driven by natural language, ensuring that task execution conforms to the user's true intentions and the current scenario, while improving interaction efficiency and the intelligent feedback capability of the voice system without increasing the driver's manual operation burden.

[0215] This manual introduces a voice broadcast display, user confirmation response, and semantically driven dynamic editing mechanism after the event task is generated, constructing a closed-loop process of human-machine confirmation and revision from task generation to pre-execution. This process not only ensures the consistency between task execution and the user's true intention, but also improves the flexibility and fault tolerance of voice interaction, avoiding incorrect task execution due to misidentification or unclear user expression. Simultaneously, it reduces operational interference during driving, enhancing the safety, accuracy, and user trust in task management.

[0216] The following will combine Figure 6 This specification provides a detailed description of the driving processing device provided in the embodiments. It should be noted that... Figure 6 The driving processing device shown is used to execute the instructions in this manual. Figures 1-5 The methods shown in the embodiments are illustrated for ease of explanation, showing only the parts related to the embodiments of this specification. For specific technical details not disclosed, please refer to this specification. Figures 1-5 The example shown.

[0217] Please see Figure 6 This diagram illustrates the structure of a driving processing device according to an embodiment of this specification. The driving processing device 1 can be implemented as all or part of a device through software, hardware, or a combination of both. According to some embodiments, the driving processing device 1 includes a driving processing module 11, a driving processing module 12, and a driving processing module 13, specifically used for:

[0218] Command monitoring module 11 is used to respond to the voice recording command of the target user during vehicle driving, collect the voice stream of the target user and generate driving context data, and convert the voice stream of the target user into target transcribed text;

[0219] The driving processing module 12 is used to parse the recorded events based on the target transcribed text and the driving context data using a driving processing big model to obtain event element fragments, perform event semantic completion on the event element fragments based on the driving context data to obtain event record information, and perform data mapping based on the event record information using a pre-set forget event data model to generate event task execution scripts and event task records.

[0220] The recording processing module 13 is used to display the event task record to the target user, and in response to the target user's record confirmation instruction, to start the event task corresponding to the event task record based on the event task execution script.

[0221] In one feasible implementation, the step of performing event semantic completion on the event element fragments based on the driving context data to obtain event record information includes:

[0222] The target user behavior knowledge graph is updated based on the driving context data using the driving processing big model.

[0223] Based on the target user behavior knowledge graph, missing data entries in the event element fragments are filled in to obtain event record information after missing data completion.

[0224] In one feasible implementation, the step of performing missing data completion processing on the missing data entries in the event element fragment based on the target user behavior knowledge graph to obtain the event record information after missing data completion processing includes:

[0225] Perform feature gap detection on the event element fragments to obtain a missing bitmap and a list of missing data corresponding to the missing bitmap;

[0226] Based on the missing data entries in the missing data list, the missing data is inferred using the target user behavior knowledge graph to obtain the filler element data corresponding to the missing data entries. The missing bitmap is then filled based on the filler element data until the missing data list no longer contains the missing data entries.

[0227] In one feasible implementation, the step of using the target user behavior knowledge graph to perform missing data reasoning based on the missing data entries in the missing data list to obtain the filler element data corresponding to the missing data entries includes:

[0228] A query vector is constructed by encoding the semantic embedding representation of the event element fragments, missing data entries, and driving context data.

[0229] Retrieve a set of candidate nodes that match the query vector from the target user behavior knowledge graph;

[0230] Determine the combined confidence level of each candidate node in the candidate node set with the event element fragment;

[0231] Query the target candidate nodes whose combined confidence value is not lower than the dynamic threshold, and use the entity attributes of the target candidate nodes as the filler feature data corresponding to the missing data entries.

[0232] In one feasible implementation, the step of generating event task execution scripts and event task records by data mapping using a pre-set forget event data model based on the event record information includes:

[0233] The task categories in the event log information are parsed, and the compatibility score between each script template and the task category is calculated.

[0234] Select the target script template with the highest adaptation score from the script template library, and fill the placeholders in the target script template based on the event record information to obtain the event task execution script;

[0235] Event task records are obtained by performing event task description processing based on the event task execution script.

[0236] In one feasible implementation, after filling the placeholders in the target script template based on the event log information to obtain the event task execution script, the method further includes:

[0237] Obtain the vehicle's current speed, driver attention index, and road risk level, and calculate the script's executable threshold;

[0238] When the executable threshold of the script is lower than the safety threshold, a delayed execution instruction is inserted into the event task execution script and the status field of the event task record is set to the delayed execution type.

[0239] When the executable threshold of the script is not lower than the security threshold, the event task execution script is marked as a normal execution type.

[0240] In one feasible implementation, the step of displaying the event task record to the target user, and in response to the target user's record confirmation instruction, starting the event task corresponding to the event task record based on the event task execution script, includes:

[0241] The event task record is output via voice at the vehicle's human-machine interface;

[0242] If a record confirmation instruction is received from the target user, the event task corresponding to the event task record will be started based on the event task execution script;

[0243] If a user voice editing command is received, the event task record and the event task execution script corresponding to the event task record are updated in real time based on the voice editing content using the driving processing big model.

[0244] It should be noted that the driving processing device provided in the above embodiments is only illustrated by the division of the above functional modules when executing the driving processing method. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the driving processing device and the driving processing method embodiments provided in the above embodiments belong to the same concept, and the implementation process can be found in the method embodiments, which will not be repeated here.

[0245] The example numbers in this specification are for descriptive purposes only and do not represent the superiority or inferiority of the examples.

[0246] In the embodiments of this specification, the electronic device, based on the target user's voice recording command, collects the target user's voice stream and generates driving context data, converts the target user's voice stream into target transcribed text, and uses a large driving processing model to parse recorded events to obtain event element fragments based on the target transcribed text and driving context data. Based on the driving context data, it performs event semantic completion on the event element fragments to obtain event recording information. Based on the event recording information, it uses a pre-set forgotten event data model to perform data mapping to generate an event task execution script and event task record, displays the event task record to the target user, and, in response to the target user's recording confirmation command, initiates the event task corresponding to the event task record based on the event task execution script. This achieves a closed-loop process during vehicle driving, starting from the user's voice command and sequentially completing voice content collection and transcription, semantic parsing and completion, event task structured modeling, script generation, user confirmation, and task execution. It effectively solves the problems of users' inability to fully express themselves, operational limitations, and reliance on contextual reasoning in driving scenarios, improving the intelligence and automation capabilities of in-vehicle voice interaction, and significantly enhancing information recording efficiency, execution accuracy, and driving safety during driving.

[0247] This specification also provides a computer storage medium that can store multiple instructions adapted to be loaded and executed by a processor as described above. Figures 1-5 The driving processing method described in the illustrated embodiment can be found in the following document for a detailed execution process. Figures 1-5 The specific details of the illustrated embodiments will not be elaborated here.

[0248] This specification also provides a computer program product that stores at least one instruction, said at least one instruction being loaded and executed by the processor as described above. Figures 1-5 The driving processing method described in the illustrated embodiment can be found in the following document for a detailed execution process. Figures 1-5 The specific details of the illustrated embodiments will not be elaborated here.

[0249] Please refer to Figure 7 This diagram illustrates a structural block diagram of an electronic device provided in an exemplary embodiment of this specification. The electronic device in this specification may include one or more components such as a processor 110, a memory 120, an input device 130, an output device 140, and a bus 150. The processor 110, memory 120, input device 130, and output device 140 may be connected via the bus 150.

[0250] Processor 110 may include one or more processing cores. Processor 110 connects to various parts of the electronic device using various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 120, and by calling data stored in memory 120. Optionally, processor 110 may be implemented using at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), or programmable logic array (PLA). Processor 110 may integrate one or more of the following: central processing unit (CPU), graphics processing unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the displayed content; and the modem handles wireless communication. It is understood that the modem may also not be integrated into processor 110 and may be implemented separately using a communication chip.

[0251] The memory 120 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 120 may include a non-transitory computer-readable storage medium. The memory 120 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 120 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for implementing at least one function (such as touch functionality, sound playback functionality, image playback functionality, etc.), instructions for implementing the various method embodiments described below, etc. The operating system may be the Android system, including systems deeply developed based on the Android system, the iOS system developed by Apple Inc., including systems deeply developed based on the iOS system, or other systems. The data storage area may also store data created by the electronic device during use, such as phonebook data, audio and video data, chat log data, etc.

[0252] See Figure 8As shown, the memory 120 can be divided into operating system space and user space. The operating system runs in the operating system space, while native and third-party applications run in the user space. To ensure that different third-party applications can achieve good running performance, the operating system allocates corresponding system resources for each application. However, different application scenarios within the same third-party application have different requirements for system resources. For example, in local resource loading scenarios, third-party applications have higher requirements for disk read speed; in animation rendering scenarios, third-party applications have higher requirements for GPU performance. Since the operating system and third-party applications are independent of each other, the operating system often cannot promptly perceive the current application scenario of a third-party application, resulting in the operating system's inability to adapt system resources accordingly to the specific application scenario of the third-party application.

[0253] In order for the operating system to distinguish the specific application scenarios of third-party applications, it is necessary to establish data communication between the third-party applications and the operating system. This would allow the operating system to obtain the current scenario information of the third-party applications at any time, and then perform targeted system resource adaptation based on the current scenario.

[0254] Taking the Android operating system as an example, the programs and data stored in memory 120 are as follows: Figure 9As shown, the memory 120 can store the Linux kernel layer 320, the system runtime library layer 340, the application framework layer 360, and the application layer 380. The Linux kernel layer 320, system runtime library layer 340, and application framework layer 360 belong to the operating system space, while the application layer 380 belongs to the user space. The Linux kernel layer 320 provides low-level drivers for various hardware components of the electronic device, such as display drivers, audio drivers, camera drivers, Bluetooth drivers, Wi-Fi drivers, and power management. The system runtime library layer 340 provides support for key features of the Android system through several C / C++ libraries. For example, the SQLite library provides database support, the OpenGL / ES library provides 3D graphics support, and the Webkit library provides browser kernel support. The system runtime library layer 340 also provides the Android runtime library, which mainly provides core libraries that allow developers to write Android applications using the Java language. The Application Framework Layer 360 provides various APIs that may be used when building applications. Developers can also use these APIs to build their own applications, such as activity management, window management, view management, notification management, content provider, package management, call management, resource management, and location management. At least one application runs in the Application Layer 380. These applications can be native applications that come with the operating system, such as contacts, SMS, clock, and camera apps; or third-party applications developed by third-party developers, such as games, instant messaging, and photo editing apps.

[0255] Taking the operating system as an example (iOS), the programs and data stored in memory 120 are as follows: Figure 10As shown, the iOS system includes: Core OS layer 420, Core Services layer 440, Media layer 460, and Cocoa Touch layer 480. Core OS layer 420 includes the operating system kernel, drivers, and low-level program frameworks. These low-level program frameworks provide hardware-level functionality for use by the program frameworks located in Core Services layer 440. Core Services layer 440 provides system services and / or program frameworks required by applications, such as Foundation framework, account framework, advertising framework, data storage framework, network connectivity framework, geolocation framework, motion framework, etc. Media layer 460 provides applications with audiovisual interfaces, such as interfaces related to graphics and images, audio technology, video technology, and AirPlay (wireless playback of audio and video transmission technologies). Cocoa Touch layer 480 provides various commonly used interface-related frameworks for application development and is responsible for user touch interaction on electronic devices. Examples include local notification services, remote push services, advertising frameworks, game tool frameworks, message user interface (UI) frameworks, UIKit frameworks, map frameworks, and so on.

[0256] exist Figure 10 The framework shown includes, but is not limited to, the base framework in the core service layer 440 and the UIKit framework in the touchable layer 480. The base framework provides many basic object classes and data types, offering the most basic system services to all applications, and is independent of the UI. The UIKit framework, on the other hand, provides a basic UI class library for creating touch-based user interfaces. iOS applications can use the UIKit framework to provide their UI, thus providing the application's infrastructure for building user interfaces, drawing, handling user interaction events, responding to gestures, and so on.

[0257] The methods and principles for implementing data communication between third-party applications and the operating system in the iOS system can be found in the Android system, and will not be repeated here.

[0258] The input device 130 is used to receive input instructions or data, and includes, but is not limited to, a keyboard, mouse, camera, microphone, or touch device. The output device 140 is used to output instructions or data, and includes, but is not limited to, a display device and a speaker. In one example, the input device 130 and the output device 140 can be combined into a touch screen, which is used to receive touch operations from the user using a finger, stylus, or any suitable object on or near it, and to display the user interface of various applications. The touch screen is usually located on the front panel of the electronic device. The touch screen can be designed as a full-screen, curved screen, or irregularly shaped screen. The touch screen can also be designed as a combination of a full-screen and a curved screen, or a combination of an irregularly shaped screen and a curved screen; this specification does not limit this aspect.

[0259] In addition, those skilled in the art will understand that the structure of the electronic device shown in the above figures does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements. For example, the electronic device may also include radio frequency circuits, input units, sensors, audio circuits, wireless fidelity (WiFi) modules, power supplies, Bluetooth modules, etc., which will not be described in detail here.

[0260] In the embodiments of this specification, the executing entity for each step can be the electronic device described above. Optionally, the executing entity for each step can be the operating system of the electronic device. The operating system can be Android, iOS, or other operating systems; this specification does not limit this.

[0261] The electronic device described in this specification can also be equipped with a display device. This display device can be any device capable of displaying information, such as a cathode ray tube display (CR), a light-emitting diode display (LED), an e-ink screen, a liquid crystal display (LCD), or a plasma display panel (PDP). Users can use the display device on the electronic device to view displayed text, images, videos, and other information. The electronic device can be a smartphone, tablet computer, gaming device, AR (Augmented Reality) device, automobile, data storage device, audio playback device, video playback device, laptop, desktop computing device, or wearable device such as a smartwatch, smart glasses, smart helmet, smart bracelet, smart necklace, or smart clothing.

[0262] exist Figure 7 In the illustrated electronic device, which can be a terminal, the processor 110 can be used to call the application stored in the memory 120 and specifically perform the following operations:

[0263] In response to a voice recording command from a target user during vehicle driving, the system collects the target user's voice stream and generates driving context data, then converts the target user's voice stream into target transcribed text.

[0264] Based on the target transcribed text and the driving context data, a large driving processing model is used to parse the recorded events to obtain event element fragments. Based on the driving context data, the event element fragments are used to perform event semantic completion to obtain event record information. Based on the event record information, a pre-set forget event data model is used to perform data mapping to generate event task execution scripts and event task records.

[0265] The event task record is displayed to the target user, and in response to the target user's record confirmation command, the event task corresponding to the event task record is started based on the event task execution script.

[0266] In one feasible implementation, the step of performing event semantic completion on the event element fragments based on the driving context data to obtain event record information includes:

[0267] The target user behavior knowledge graph is updated based on the driving context data using the driving processing big model.

[0268] Based on the target user behavior knowledge graph, missing data entries in the event element fragments are filled in to obtain event record information after missing data completion.

[0269] In one feasible implementation, the step of performing missing data completion processing on the missing data entries in the event element fragment based on the target user behavior knowledge graph to obtain the event record information after missing data completion processing includes:

[0270] The missing bitmap and the missing data list corresponding to the missing bitmap are obtained by performing feature gap detection on the event feature fragments;

[0271] Based on the missing data entries in the missing data list, the missing data is inferred using the target user behavior knowledge graph to obtain the filler element data corresponding to the missing data entries. The missing bitmap is then filled based on the filler element data until the missing data list no longer contains the missing data entries.

[0272] In one feasible implementation, the step of using the target user behavior knowledge graph to perform missing data reasoning based on the missing data entries in the missing data list to obtain the filler element data corresponding to the missing data entries includes:

[0273] A query vector is constructed by encoding the semantic embedding representation of the event element fragments, missing data entries, and driving context data.

[0274] Retrieve a set of candidate nodes that match the query vector from the target user behavior knowledge graph;

[0275] Determine the combined confidence level of each candidate node in the candidate node set with the event element fragment;

[0276] Query the target candidate nodes whose combined confidence value is not lower than the dynamic threshold, and use the entity attributes of the target candidate nodes as the filler feature data corresponding to the missing data entries.

[0277] In one feasible implementation, the step of generating event task execution scripts and event task records by data mapping using a pre-set forget event data model based on the event record information includes:

[0278] The task categories in the event log information are parsed, and the compatibility score between each script template and the task category is calculated.

[0279] Select the target script template with the highest adaptation score from the script template library, and fill the placeholders in the target script template based on the event record information to obtain the event task execution script;

[0280] Event task records are obtained by performing event task description processing based on the event task execution script.

[0281] In one feasible implementation, after filling the placeholders in the target script template based on the event log information to obtain the event task execution script, the method further includes:

[0282] Obtain the vehicle's current speed, driver attention index, and road risk level, and calculate the script's executable threshold;

[0283] When the executable threshold of the script is lower than the safety threshold, a delayed execution instruction is inserted into the event task execution script and the status field of the event task record is set to the delayed execution type.

[0284] When the executable threshold of the script is not lower than the security threshold, the event task execution script is marked as a normal execution type.

[0285] In one feasible implementation, the step of displaying the event task record to the target user, and in response to the target user's record confirmation instruction, starting the event task corresponding to the event task record based on the event task execution script, includes:

[0286] The event task record is output via voice at the vehicle's human-machine interface;

[0287] If a record confirmation instruction is received from the target user, the event task corresponding to the event task record will be started based on the event task execution script;

[0288] If a user voice editing command is received, the event task record and the corresponding event task execution script are updated in real time based on the voice editing content using the driving processing big model. Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory, or random access memory, etc.

[0289] The above-disclosed embodiments are merely preferred embodiments of this specification and should not be construed as limiting the scope of this specification. Therefore, any equivalent variations made in accordance with the claims of this specification shall still fall within the scope of this specification.

Claims

1. A driving processing method, characterized in that, The method comprises: In response to a voice recording command from a target user during vehicle driving, the system collects the target user's voice stream and generates driving context data, then converts the target user's voice stream into target transcribed text. Based on the target transcribed text and the driving context data, a large driving processing model is used to parse the recorded events to obtain event element fragments. Based on the driving context data, the event element fragments are used to perform event semantic completion to obtain event record information. Based on the event record information, a pre-set forget event data model is used to perform data mapping to generate event task execution scripts and event task records. The event task record is displayed to the target user, and in response to the target user's record confirmation command, the event task corresponding to the event task record is started based on the event task execution script.

2. The method according to claim 1, characterized in that, The process of obtaining event record information by performing event semantic completion on the event element fragments based on the driving context data includes: The target user behavior knowledge graph is updated based on the driving context data using the driving processing big model. Based on the target user behavior knowledge graph, missing data entries in the event element fragments are filled in to obtain event record information after missing data completion.

3. The method according to claim 2, characterized in that, The missing data completion process performed on the missing data entries in the event element fragment based on the target user behavior knowledge graph to obtain the event record information after missing data completion includes: The missing bitmap and the missing data list corresponding to the missing bitmap are obtained by performing feature gap detection on the event feature fragments; Based on the missing data entries in the missing data list, the missing data is inferred using the target user behavior knowledge graph to obtain the filling element data corresponding to the missing data entries. The missing bitmap is then filled based on the filling element data until the missing data list no longer contains the missing data entries.

4. The method according to claim 3, characterized in that, The process of obtaining the filler element data corresponding to the missing data entries based on the missing data entries in the missing data list using the target user behavior knowledge graph includes: A query vector is constructed by encoding the semantic embedding representation of the event element fragments, missing data entries, and driving context data. Retrieve a set of candidate nodes that match the query vector from the target user behavior knowledge graph; Determine the combined confidence level of each candidate node in the candidate node set with the event element fragment; Query the target candidate nodes whose combined confidence value is not lower than the dynamic threshold, and use the entity attributes of the target candidate nodes as the filler feature data corresponding to the missing data entries.

5. The method according to claim 1, characterized in that, The process of generating event task execution scripts and event task records by using a pre-set forget event data model based on the event record information includes: The task categories in the event log information are parsed, and the compatibility score between each script template and the task category is calculated. Select the target script template with the highest adaptation score from the script template library, and fill the placeholders in the target script template based on the event record information to obtain the event task execution script; Event task records are obtained by performing event task description processing based on the event task execution script.

6. The method according to claim 5, characterized in that, After filling the placeholders in the target script template with the event log information to obtain the event task execution script, the method further includes: Obtain the vehicle's current speed, driver attention index, and road risk level, and calculate the script's executable threshold; When the executable threshold of the script is lower than the safety threshold, a delayed execution instruction is inserted into the event task execution script and the status field of the event task record is set to the delayed execution type. When the executable threshold of the script is not lower than the security threshold, the event task execution script is marked as a normal execution type.

7. The method according to claim 1, characterized in that, The step of displaying the event task record to the target user, and responding to the target user's record confirmation command, starting the event task corresponding to the event task record based on the event task execution script, includes: The event task record is output via voice at the vehicle's human-machine interface; If a record confirmation instruction is received from the target user, the event task corresponding to the event task record will be started based on the event task execution script; If a user voice editing command is received, the event task record and the event task execution script corresponding to the event task record are updated in real time based on the voice editing content using the driving processing big model.

8. A driving processing device, characterized in that, The device comprises: The instruction monitoring module is used to respond to the voice recording instruction of the target user during vehicle driving, collect the target user's voice stream and generate driving context data, and convert the target user's voice stream into target transcribed text; The driving processing module is used to parse recorded events based on the target transcribed text and the driving context data using a driving processing big model to obtain event element fragments, perform event semantic completion on the event element fragments based on the driving context data to obtain event record information, and perform data mapping based on the event record information using a pre-set forget event data model to generate event task execution scripts and event task records. The recording processing module is used to display the event task record to the target user, and in response to the target user's record confirmation instruction, to start the event task corresponding to the event task record based on the event task execution script.

9. A computer storage medium, characterized in that, The computer storage medium stores a plurality of instructions, which are adapted to be loaded by a processor and executed as method steps as claimed in any one of claims 1 to 7.

10. An electronic device, characterized in that, include: A processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and executed the method steps as claimed in any one of claims 1 to 7.

Images